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

[Joseph Salowey (jsalowey]

eap-admin [at] frascone.com 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
>>>> 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?
> 
> 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.


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

> 
> --Jari
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap