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

[Jari Arkko (jari.arkko]

Thanks for your comments Florent. They are very useful!
Some discussion inline:

> 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.

Yes, though, I am not sure this is a fundamental distinction. Or perhaps
its not the symmetric/asymetric difference that causes this. It would seem
that even a symmetric method could avoid the active attackers, if both end
points were able to "commit" to an identity. This adds some (possibly
tough) requirements on the end point implementations, but it would
prevent active attackers from going back to the original identity,
at worst the previously used temporary identity would have to be revealed.
With group keys for identity protection, you could have a symmetric method
and no active attacks at all, from outsiders.

> 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)

Agreed.

> 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.

Yes.

> 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 

I agree with all your points above. While I think that the RFC 2284bis
should not include guidance for all possible new features that one's
methods could do, it would still be good to clarify the definition
of fast reconnect. I think a better definition would be:

   Fast reconnect
             The ability, in the case where a security association has
             been previously established, to create a new or refreshed
             security association more efficiently or in a smaller number
             of round-trips.

I'll tell Bernard and Henrik to remember this when we get to AUTH48
on the document.

> 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.

Well, there may be a difference between allowing something vs.
providing all the tools and guidance for something. Timing-wise
it may not be possible to provide guidance on all possible fast
handoff, fast reauthentication, and other advanced designs. Particularly
when the field is under active research. However, the draft does provide
some tools and hooks that allow such things to be made later, in
other documents. For instance, the EMSK can be helpful in many of
these schemes.

> 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?

See above.

--Jari