Subject: Re: [eap] Identity Protection and fast-reconnect

From: Florent Bersani <[email-masked]>
Date: Mon, 12 Jan 2004 13:39:18 -0800

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?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Jan 2004 02:53:52 +0200

> advanced services to be provided later. What do you reckon?

I think I agree. Though there may be a difference between providing the EMSK
as a whole or some values derived from it.

However, in IETF-58 we agreed that material from Joe's draft
(draft-salowey-eap-key-deriv-02.txt) should be incorporated to
the EAP KMF draft. Some open issues were still being discussed
on the contents, but in any case. WHat you brought up above is
in fact clarified there:

      o The EMSK MSUT be maintained within the EAP server.  Only keys
         (AMSKs) derived according to this specification may be exported
         from the EAP server.

--Jari

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 14 Jan 2004 17:27:14 -0800

[email-masked] wrote:
> Florent Bersani wrote:
> 
>>>> or wherever - I hope not within EAP ;-), please feel free to
>>>> mention your pointers, I'll go and start with reading the irtf
>>>> 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. 
>>> 
>>> 
>>> 
>>> 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." 
>> 
>> 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?
> 
> I think I agree. Though there may be a difference between
> providing the EMSK as a whole or some values derived from it.
> 
> (draft-salowey-eap-key-deriv-02.txt) should be incorporated
> to the EAP KMF draft. Some open issues were still being
> discussed on the contents, but in any case. WHat you brought
> up above is in fact clarified there:
> 

[Joe] Yes, this was one of the motivations for the EMSK work.  By
coordinating the derivation of key material for different applications
(AMSK) so they are computationally independent from the root EMSK we can
derive keys for many different purposes including re-authentication,
channel-binding, handoff, etc.   

You do not want to release the EMSK itself because that could result in
the compromise of all keys if one is compromised.  There is probably
additional work to define how keys are requested and distributed for
various applications if necessary.  

I do still owe a list of issues to merge the key derivation draft into
the key framework draft which I will provide soon.