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

[Jari Arkko (jari.arkko]

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.

--Jari