eap Mailing List: RE: EAP-SIM v12 review

[henry.haverinen (henry.haverinen]

Florent,

Thanks for your response. I agree with your proposed
clarifications, it makes sense to include some rationale
in the documents. 

I'll incorporate your comments in the next versions of the
documents.

Best regards,
Henry

> -----Original Message-----
> From: ext Florent Bersani [mailto:florent.bersani [at] francetelecom.com]
> Sent: 29 December, 2003 19:39
> To: Haverinen Henry (NES/Jyvaskyla)
> Cc: eap [at] frascone.com
> Subject: Re: [eap] EAP-SIM v12 review
> 
> 
> 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
>