eap Mailing List: Re: EAP-SIM v12 review

[Florent Bersani (florent.bersani]

Hi Henry,

henry.haverinen [at] nokia.com wrote:

> Hi Florent,
>
>  
>
> > From: eap-admin [at] frascone.com 
> > [mailto:eap-admin [at] frascone.com]On Behalf Of
> > ext Florent Bersani
> >    
> >
> > To be constructive, if you really don't feel like relabeling 
> > the NONCES, 
> > may I then suggest to add to the clear statement in the 
> > attribute saying 
> > that NONCE X must be a random value, that you suggest and 
> > that is more 
> > or less already there, a paragraph to section 2 defining Nonce and 
> > warning the reader to check if the nonce must be random or not.
> >    
>
> I agree, and I think the definition in section 2 can already
> highlight that the nonces in this protocol are random.
> I modified your proposal to reflect this. Do you think 
> the following would be OK?
>
> Nonce: a value that is used at most once or that is never repeated 
> within the same cryptographic context. In general, a nonce can be predictable 
> (e.g. a counter) or unpredictable (e.g. a random value). 
> Since some cryptographic properties may depend on the randomness of 
> the nonce, attention should be paid to whether a nonce is required 
> to be random or not. In this document, the term nonce is only
> used to denote random nonces, and it is not used to denote counters.
>
>  
It looks great to me!

> > I agree that in you current draft wording you can implement 
> > re-authentication without identity protection.
> >
> > However, you still implement identity protection within your 
> > re-authentication scheme because your require a fresh new 
> > re-authentication id [we are also discussing this point in 
> > this thread, 
> > but I'll assume this is our current position] to be used after each 
> > re-authentication, the re-auth id that you send encrypted.
> >
> > Hence, while wishing to implement only re-authentication, you 
> > still have 
> > to go in the trouble of managing different identities, which 
> > reminds me 
> > very strongly of the identity protection hassle ;-)
> >
> > I therefore meant, why not use as a reauth-id always the same 
> > one: the 
> > permanent id (or the pseudonym if is implemented) flagged in 
> > a way (it 
> > could be something like IMSI.reauth [at] jjj.nnn or decoration of the 
> > username, NAI we want) or even the ordinary id but with a 
> > flag included 
> > elsewhere in the EAP method packet saying "hey I want to fast 
> > reconnect"
> >    
>
> It would probably be feasible to specify another option to 
> start a re-authentication exchange by a client-generated 
> re-authentication identity. However, I don't think specifying
> a new option would simplify the protocol, but rather to 
> ensure interoperability peers and servers would have to implement 
> two variants of re-authentication.
>  
That's right, I agree with you that we should not give too many options 
or else we would get into interoperability trouble :-(

> AT_NEXT_REAUTH_ID has several purposes. It also works as a capability
> flag that indicates the fact that the server supports re-authentication, 
> and that the server wants to continue using re-authentication within 
> the current context. These indications can save roundtrips, because
> the peer won't propose fast re-authentication if the server has indicated
> it doesn't want to.
>
> The re-authentication identity also has several purposes. In addition 
> to identifying the subscriber and indicating that the peer wants to use 
> re-authentication, the re-authentication identity identifies the full
> authentication context. So the server should be able to determine whether 
> its re-authentication state information comes from the same full authentication 
> as the client's state information. In load balancing scenarios, different servers 
> may have different re-authentication contexts, and the peer only has the most 
> recent one, so a context-specific re-authentication identity can help the server 
> to detect that its state doesn't match the peer's state.
> The server-generated re-authentication identity may also include a realm 
> to indicate the correct server, and to help the AAA infra route the authentication 
> to the correct server.
>  
This text clarifies a lot the purpose of AT_NEXT_REAUTH_ID: why not 
incorporate it (some parts of it) in the draft?

By the way, similarly, in a previous post, you explained to me the 
rationale behind the design of fast-reconnect in EAP-SIM:

"The re-authentication exchange is quite similar to the UMTS AKA 
exchange. The counter corresponds to the UMTS AKA sequence number, 
Nonce_S corresponds to RAND, and AT_MAC in 
EAP-Request/SIM/Re-authentication corresponds to AUTN, the AT_MAC in 
EAP-Response/SIM/Re-authentication corresponds to RES, 
AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter 
corresponds to the usage of the Anonymity Key.

Also the generation of random or fresh material is similar to UMTS AKA -- the server generates these values, and the peer only verifies that the counter value is fresh. The peer is required to check that the counter value is big enough."

Don't you think it would be worth including such an explanation somewhere in the draft since it seems to me that it helps in analyzing the security of EAP-SIM's fast-reconnect procedure?

> So I think the re-authentication identity should include a random portion
> selected by the server, just as 3GPP is specifying. We should mention this 
> in the EAP-SIM and EAP-AKA documents too.
>
> I'm not saying there wouldn't be ways to work around these issues
> with client-generated re-authentication identities. However, I think
> we shouldn't specify such an option, for the sake of simplicity.
>
>  
>
> > > 4. separate identities would allow an intermediate box, 
> > >      
> > located closer to 
> >    
> >
> > > the access network, to implement fast re-authentication. The 
> > >      
> > AAA server
> >    
> >
> > > could delegate re-authentications to an intermediate proxy.
> > > (I suppose this reason is not relevant currently.)
> > >
> > >
> > >      
> > OK, incidentally I am working on this also right now. I'll 
> > try and send 
> > a separate post on fast reconnect.
> >    
>
> OK. In the current 3GPP architecture, EAP-SIM or EAP-AKA 
> authentication is performed end-to-end. I also think local
> re-authentication shouldn't be specific to any EAP method.
> So this rationale does not seem relevant to EAP-SIM or EAP-AKA.
>
>  
I agree: I should have posted the announced general post about this to 
the EAP list before the new year...

> > However, I see a compatible way to have the draft comply to 
> > my changes: 
> > allow the server to always use the same fast-reconnect id for a peer, 
> > allow even the peer to derive his fast-reconnect id on his own [i.e 
> > define a constant flagging of the permanent and pseudonym 
> > identity] (and 
> > allow  a server not to resend this fast-reconnect id at each 
> > peer's fast 
> > reconnect if you care about unnecessary bandwidth consumption)
> >
> > What do you think of this ?
> >    
>
> To sum up the above, I think we don't need client-generated
> fast re-authentication identities. 
>
> My personal preference would be to keep the current specification 
> of AT_NEXT_REAUTH_ID. This way the server (= the operator) would 
> be able to control the re-use of re-authentication identities. 
> I'd welcome any comments from others in this...
>
> I think it could be OK to allow the server to allocate the same fast
> re-authentication identity to the peer during a full authentication
> context. But the identity should contain something context-specific.
> (Of course this would make the re-authentication identity predictable,
> so we should discuss the consequences.) 
>  
I've come to agree with you... except that if you relabel 
"re-authentication" with "fast-reconnect", you might want to change 
AT_NEXT_REAUTH_ID to AT_NEXT_FASTRECONNECT_ID ;-)

> Best regards,
> Henry
>  
Best regards,
Florent