Subject: [Fwd: Re: [eap] Re: submitting EAP-SIM document]

From: [email-masked] (Uri Blumenthal)
Date: Fri, 06 Jun 2003 16:38:01 -0400

Sorry, this reply from Sarvar didn't get forwarded to the list,
so I'm remeding it.

-------- Original Message --------
Date: Wed, 4 Jun 2003 16:10:21 -0400
From: "Sarvar Patel" <[email-masked]>
To: "EAP mailing List"

Hi Joe,
     thanks for your response. My comments are inline.

 > With respect to only 64 bits of security this is indeed a problem that
 > has been overlooked (at least by me).  I think the appropriate action
 > would be to revise the draft to require the client to check to make sure
 > the RAND values within a request are different.

What are your thoughts about including SRES in the MK calculation, since it
would add more secret material to the MK even in the case of a single
triplet, possibly providing 96 bit of security. This is possible since, as I
understand it, the SRES is never exposed in the EAP-SIM protocol. The
EAP-Response/SIM/Challenge message creates and sends the MAC of EAP|n*SRES
but does not include the SRES values themselves.

 > Also EAP-SIM most definitely relies upon the secrecy of Kcs to maintain
 > session independence.  As you point out, we must require that all
 > triplets remain secret, because if an attacker obtains RAND and Kc then
 > he or she can act as the network.  This is discussed in several sections
 > in the draft, but stronger wording on this fundamental assumption is
 > probably warranted.

I did notice your discussion on the need to keep triplets secret which I
found to be in tension with the requirement for fresh triplets for every new
instance of the protocol. Let me explain: As I understand the EAP-SIM, like
the GSM, protocol specifies that at each different instance of the protocol
the authenticator would solicit fresh new triplets to be used in
authentication and session key generation with the client. If so then it
implies that the EAP-SIM protocol is looking for session independence at the
level of triplets like in the GSM world where even if past triplets are
compromised or revealed, it has no impact on future sessions.

But this triplet independence is not true of the EAP-SIM protocol and as you
specify all the triplets need to be kept secret. This then prompts the
question, why have the requirement that fresh triplets are needed for every
new instance of the protocol? Here are two possible solutions which do not
require fresh triplets and will work assuming that the authenticator is
trusted:
1) Share the Ki with the authenticator and run a secure mutual
authentication and session key agreement protocol (e.g. Bellare-Rogaway
protocol)
2) If sharing Ki is not possible, then share n triplets once with the
authenticator and the reuse the triplets even with new instances of
protocols in the following manner. The authenticator first shares the RANDs
values with the client and they both run a secure mutual authentication and
session key agreement protocol (e.g. Bellare-Rogaway protocol) using Kc's as
the root key. A protocol like Bellare-rogaway would send its own random
challenges to be used in creating the responses and session key, unlike the
current EAP-SIM protocol which uses the RANDs as both a way to specify Kc
value and as challenges to use in response verifications.

I suppose the point is that if one cares about session independence at the
triplet level, I don't know how to achieve that. However, if one does not
care about session independence at the triplet level (that is the
authenticator is trusted) then one could specify  a protocol where fresh
triplets are not needed. The current EAP-SIM would be inefficient in the
sense that even though it does not provide session independence at the
triplet level, it still requires fresh triplets. At this point, I just
wanted to make us aware of these possibilities.

 >In general I am less concerned about Kc exposure on
 > the authenticator side than on the client side.  This is because with
 > EAP-SIM triplets do not have to leave the home domain to facilitate
 > roaming authentication (EAP-SIM typically terminates in the home
 > network) which is different than the VLR model in GSM.  On the client
 > side there are implementations that perform EAP-SIM calculations on the
 > SIM card that prevent triplet exposure.  Nonetheless it is still a
 > serious consideration.

Hmm, why are you worried about the client side revealing Kc? Is there an
incentive for the client to find out the Kc, may be you are thinking that an
attacker who temporarily gets the SIM card can find out the Kc and use it
later to attack the client. I guess my understanding is limitied on the
exact EAP-SIM use, but if Kc being compromised at the client is alsoan issue
then the above discussion has to be changed accordingly.

thanks
Sarvar

 > Once again thanks for your time.  I expect we will be updating the draft
 > to address your comments in the near future.
 >
 > Regards,
 >
 > Joe
 > > -----Original Message-----
 > > From: [email-masked] [mailto:[email-masked]]
 > > On Behalf Of Uri Blumenthal
 > > Sent: Thursday, May 29, 2003 11:30 AM
 > > To: EAP mailing List
 > > Cc: Sarvar Patel; 'S.Mizikovsky'
 > > Subject: [eap] Re: submitting EAP-SIM document
 > >
 > >
 > > Folks,
 > >
 > > My colleange Sarvar Patel asked me to post his analysis
 > > of EAP-SIM draft. Here's the summary in short, and since
 > > the entire paper (in PDF) is only 16 KB, I'm attaching
 > > it to this posting.
 > >
 > > EAP-SIM specifies a mechanism for mutual authentication and
 > > session key
 > > agreement using the GSM-SIM and by proposing enhancement to the GSM
 > > authentication procedures.  Unfortunately, as we show it does not
 > > succeed in its goal of providing 128 bit security from the current 64
 > > bit security of GSM. Furthermore, it does not provide session
 > > independence between different sessions. For the first
 > > problem, we are
 > > able to provide solutions, but the second problem does not
 > > seem solvable
 > > in practice.
 > >
 > >
 >
 >