eap Mailing List: Identity Protection and fast-reconnect

[Florent Bersani (florent.bersani]

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 :-(