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

From: [email-masked] (Jari Arkko)
Date: Thu, 05 Jun 2003 12:27:21 +0300

Hello Sarvar,

(Speaking individually and as the author of EAP-AKA)

Your paper looks like a very useful analysis. First, I wonder
if you had done any similar work on EAP-AKA in addition to
EAP-SIM? If yes, I'd be very interested to hear your results.

And then to the EAP-SIM issues. It looks like the first
vulnerability that you describe is valid. I think I also
agree with the proposed solution.

As to the second vulnerability... if I'm not mistaken this
appears to be a property of the GSM authentication rather
than the EAP-SIM adaptation of that. With the same assumptions
you would be able to spoof yourself as a GSM network, no?
But not the user. Interestingly, AKA does not appear to have
the same vulnerability, given its replay protection mechanisms;
it was designed with stricter requirements. Actually, I wonder
how useful it is to try to search for a fix. It might be
easier to just document that EAP-SIM has that limitation
due to the underlying authentication scheme. You might or
might not be worried about the limitation. But if you are,
one answer is to upgrade to a USIM from a SIM and use
EAP-AKA authentication.

--Jari

---

From: [email-masked] (Joseph Salowey)
Date: Wed, 11 Jun 2003 20:42:45 -0700

Hi Savar,

Comments inline below.

> -----Original Message-----
> From: Sarvar Patel [mailto:[email-masked]] 
> Sent: Wednesday, June 04, 2003 1:10 PM
> To: 'EAP mailing List'; Joseph Salowey
> Cc: Blumenthal, Uri (Uri); sarvar
> Subject: Re: [eap] Re: submitting EAP-SIM document
> 
> 
> 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.
>

[Joe] Within EAP-SIM SRES is secret so it would help.  This is something
I would like to consider when we upgrade the version of the protocol
since it would not be a backward compatable change.
 
> > 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. 

[Joe] EAP-SIM builds mutual authenticaiton on top of the underlying GSM
values.  GSM does not provide mutual authentication so comparisons are
difficult to make.  As you know this is the root of the problem you
describe.

> 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)

[Joe] I agree that a much better protocol could be chosen if we had
access to Ki. I especially like the suggestion of using something along
the lines of Bellare-Rogaway protocol, I have used this in other
contexts.

> 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.

[Joe] Yes, one could just create a secure protocol around a few static
triplets.  This is somewhat undesireable because it creates another
entity in the network which maintains long term subscriber credentials
in addition to the HLR.  It also leaves the HLR/AuC out of the
authentication/authorization loop. I think it might be beneficial to
move more in the direction of EAP-AKA as it becomes more widely
available.  You might want to have a look at that specification as well
(http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-09.txt)

> 
> >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.
> > >
> > >
> >
> >
>