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

Hi Jari,
Many thanks for your answer and sorry for the delay in my reply: a few 
more thoughts inline.
Florent
Jari Arkko wrote:
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 agree I oversimplified a bit but what I meant is that we have two 
fundamental different cases depending on the possibility to set up a 
protected channel before real identity exchange occurs. Using a group 
key (which is a good example) raises several problems: either the group 
is small and you offer little identity protection since belonging to the 
group almost reveals your identity or the group is big and then you have 
the group key management headache or the attacks from insiders...  
Anyway, this is not the WG's concern, isn't it?

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.

Your proposed new definitions looks great to me.
FMI, what is AUTH48?
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.
I agree about the timeliness issue and the impossibility to cater for 
everything hence the hooks.
May I then however reformulate my remark: in the latest version of the 
EAP KMF (02b), the EMSK is defined in section 2.2 page 16 as "Additional 
keying material derived between the EAP client and server that is 
exported by the EAP method.  The EMSK is at least 64 octets in length. 
The EMSK is reserved for future uses that are not defined yet and is not 
provided to a third party."
My concern is that, as I understand the last part, not providing the 
EMSK to a third party precludes the interaction between the visited AAA 
and the home AAA I described. My recommendation would thus be: delete 
"and is not provided to a third party" to provide some tools to allow 
advanced services to be provided later. What do you reckon?

Re: Identity Protection and fast-reconnect	<– Date –> <– Thread –>
From: Florent Bersani (florent.bersanifrancetelecom.com)
Date: Mon, 12 Jan 2004 16:31:36 -0500 (EST)

eap Mailing List
View Index by: Date - Thread - Author