eap Mailing List: RE: Identity Protection and fast-reconnect

[henry.haverinen (henry.haverinen]

Florent,

The implementation of identity management in general
seems to vary quite much between EAP methods. Many people think 
the EAP-Respose/Identity packet should be used for AAA routing purposes 
only, and the actual user identity should be transmitted within 
the method-specific messages. EAP-SIM and EAP-AKA also support this, 
while they can make use of EAP-Response/Identity too.

I believe the concept of re-authentication identity is specific
to EAP-SIM and EAP-AKA. These methods are very conservative
in their use of round trips, hence the special identity.
If a method only uses EAP-Response/Identity for AAA routing,
then the next EAP response can contain any method-specific
context information, which is not limited to the identity.
In this case, there might not be need for the concept of
a "re-authentication identity".

Best regards,
Henry


> -----Original Message-----
> From: eap-admin [at] frascone.com 
> [mailto:eap-admin [at] frascone.com]On Behalf Of
> ext Florent Bersani
> Sent: 29 December, 2003 19:42
> To: eap [at] frascone.com
> Subject: [eap] Identity Protection and fast-reconnect
> 
> 
> Hi,
> 
> During my review of EAP-SIMv12 and the subsequent interactions with 
> Henry Haverinen, we've come to discuss topics that seemed not to be 
> EAP-SIM specific but rather general about EAP and EAP methods, hence 
> this mail.
> 
> Apologies in advance if it seems too EAP method oriented (out 
> of scope) 
> or useless giberrish.
> 
> First thing discussed seems to be old folklore: identity protection.
> I won't get into arguing whether identity protection is a 
> useful feature 
> or not since the answer must have already been given somewhere, 
> something like: being conservative is no sin in network 
> security and if 
> you don't want it, don't implement it when it is an optional feature.
> I also won't recall the vulnerability of most identity protection 
> schemes within a "symmetric" EAP method ("asymmetric" EAP 
> methods such 
> as PEAP+? are not subject to the same vulnerability) due to the trade 
> off between functionality (allowing a peer and an AAA server 
> to resync) 
> and security (allowing an active attacker to force identity 
> disclosure) 
> and the hassle of temporary identity management.
> I will just stress the conclusion that identity protection and fast 
> reconnect are orthogonal features: you can have all the flavors (no 
> identity protection, no fast reconnect), (no identity 
> protection, fast 
> reconnect), (identity protection, no fast reconnect), (identity 
> protection, fast reconnect)
> 
> Second thing discussed was fast reconnect.
> 
> The first point on fast reconnect was that, although identity 
> protection 
> and fast reconnect are orthogonal (see above), some fast reconnect 
> schemes went into similar trouble as identity protection by proving 
> one-time fast reconnect identities. Why is that? Henry provided some 
> very clear answers: the fast reconnect identity serves to 
> identify the 
> peer, indicate that it wants to fast reconnect and help the 
> AAA server 
> identify the context (the security association) the peer refers to in 
> its will to fast reconnect.
> 
> The second point on fast reconnect was: why provide fast reconnect 
> features? Here, after re-reading EAP's latest version, I still think 
> that it might be worth a little more discussion. EAP states 
> that "fast 
> reconnect"  is "The ability, in the case where a security association 
> has been previously established, to create a new or refreshed 
> security 
> association in a smaller number of round-trips. ". I guess here that 
> this leaves aside an important motivation for fast reconnect which is 
> processing power consumption: for example, with TLS, resuming 
> a session 
> might save some asymmetric cryptography calculations which 
> are known to 
> be pretty heavy. This might also be the case for EAP methods (eg. 
> EAP-TLS). I also tend to think that we could discuss another 
> aspect of 
> fast reconnect which is the "depth" or "distance" of the round trips 
> rather than their number (this must have been done somewhere 
> else in AAA 
> or wherever - I hope not within EAP ;-), please feel free to mention 
> your pointers, I'll go and start with reading the irtf 
> aaaarch-handoff 
> mentioned in EAPKMF after I am finished with this post): 
> typically if we 
> consider a roamer, his first authentication has to be 
> forwarded by the 
> visited AAA server to the home AAA server (which might be far 
> away), but 
> we could imagine then that the fast reconnect procedures 
> could save time 
> or money by reducing or even better suppressing the contacts 
> between the 
> peer and the home AAA server (for instance, the home AAA server would 
> delegate to the visited AAA server some parts of - when not all - the 
> fast reconnect exchanges). Some proposed EAP methods (IIRC EAP-SRP or 
> EAP-SKE) had the roaming situation in mind (H-AAA and V-AAA). 
> However, 
> this does not seem to be the direction taken by the group if I 
> understand well the current draft for the EAP key management 
> framework. 
> Do you think that it would be interesting to investigate this 
> matter or 
> merely state explicitly the decision that has been made 
> regarding this 
> point in the WG documents (for the sake of clarity)? I think 
> this point 
> is also related to fast handoffs, maybe we could provide a little 
> guidance/discussion on fast reconnect vs. fast handoff in the EAPKMF?
> 
> The third point on fast reconnect was whether fast reconnect 
> identities 
> could be created by the peer. The answer seems to be more closed and 
> negative since the peer would possibly not know how to indicate the 
> context to which it refers in it fast reconnect attempt. Henry also 
> mentioned that the fact that the AAA server provided the peer with a 
> fast reconnect identity could be interpreted as a hint that the AAA 
> server supports fast reconnect whereas absence of such an 
> identity would 
> lead the peer to believe the AAA server doesn't support fast 
> reconnect 
> and thus, not propose to fast reconnect. Maybe the more general point 
> behind this third point was fast reconnect identities 
> generation rules, 
> but I don't think that we want to go into it within EAP, do we?
> 
> Please feel free to make any comment/suggestion.
> 
> Regards,
> Florent, who fears he should have RTFMAs a little more :-(
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>