eap Mailing List

View Index by: Date - Thread - Author
Re: Identity Protection and fast-reconnect
From: Florent Bersani (florent.bersanifrancetelecom.com)
Date: Wed, 31 Dec 2003 13:07:17 -0600 (CST)
Henry,

I think you are perfectly right: I have unfortunately mixed things up a little in my e-mail (for instance by talking too much of fast reconnect identities which are rather EAP-SIM specific).

Here is a tentative clarification of the issues I am looking forward to getting feedback/advice on:

My main point which IMHO concerns EAP: discuss motivations for fast reconnect (defined in RFC 2284bis) and provide "guidance" on fast reconnect vs. fast handoff (in EAP Key management framework).

Additional points, rather related to EAP methods and thus, out of the direct WG scope, are:
1) Discuss the different ways how fast reconnect could be implemented (flags, session identifiers, fast reconnect identities) and the relevant technical issues
2) Clarify the identity protection (which incidentally has been mentioned in issue 208 proposed resolution IIRC), the two flavors of identity protection ("symmetric" eg. EAP-SIM like and "asymmetric" eg. PEAP+? like) and the respective security concerns...

I consider these points really as additional compared to my main point.
Moreover, it is not clear to me where they should be discussed (if they should ever be discussed).
However, I do think that, since these two features are considered generally in RFC 2284bis, it would be worth that EAP method designers get together to compare their different approaches and why not, reach a consensus for the benefit of EAP users and implementors :-) ...

BR and happy new year!

Florent

henry.haverinen [at] nokia.com wrote:

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







Results generated by Tiger Technologies using MHonArc.