eap Mailing List: RE: Relationship between AAA-Key and MSK/EMSK

[Joseph Salowey (jsalowey]

> -----Original Message-----
> From: jrv [at] j.imap.itd.umich.edu 
> [mailto:jrv [at] j.imap.itd.umich.edu] On Behalf Of John Vollbrecht
> Sent: Friday, February 06, 2004 10:37 AM
> To: Joseph Salowey; 'Tschofenig Hannes'; eap [at] frascone.com
> Subject: RE: [eap] Relationship between AAA-Key and MSK/EMSK
> 
> 
> Thanks for the reply-
> 
> --On Friday, February 6, 2004 10:11 AM -0800 Joseph Salowey 
> <jsalowey [at] cisco.com> wrote:
> 
> >
> >
> > jrv [at] j.imap.itd.umich.edu wrote:
> > > This brings up a point that I haven't been able to understand
> > > - see below --On Friday, February 6, 2004 9:18 AM -0800 Joseph 
> > > Salowey <jsalowey [at] cisco.com> wrote:
> > >
> > >> Hi Hannes,
> > >>
> > >> I agree the definition of the AAA-key seems incomplete, 
> I think the 
> > >> definition is any key that is used by the authenticator and 
> > >> supplicant to derive keys for data traffic protection (I don't 
> > >> think AAA-key is the best name since it doesn't have to 
> involve a 
> > >> AAA in the basic case). In the case of standard 802.11 
> this AAA-Key 
> > >> the same as the MSK.  In the fast handoff example I believe 
> > >> additional AAA-keys are pushed to neighboring access points.  In 
> > >> order to provide computational independence from the MSK they 
> > >> should be derived from the EMSK.
> > >>
> > > I don't understand why we would derive a MSK and EMSK that are at 
> > > the same level, then use the MSK for the current AP but derive new
> > > keys from the
> > > EMSK for other APs.
> > >
> > > It seems to me that it would be more consistent to derive 
> all keys 
> > > the same
> > > way, perhaps from the MSK.   But then I don't understand the
> > > value of the
> > > EMSK, since everything can be derived from the MSK.
> > >
> > > I had thought that the MSK was meant to allow backward 
> compatibility 
> > > with existing Key mechanisms, and the EMSK would do future things.
> > > Perhaps this is the case, but it seems to me that 
> deriving everything
> > > the
> > > same way would
> > > be more consistent and easier to understand.
> > >
> > > Is the MSK mean to be equivalent to the EMSK except that 
> the MSK is 
> > > only used for existing implementations, or am I misunderstanding 
> > > something?
> > >
> >
> > [Joe] Basically you are correct.  The reason for the EMSK 
> is because 
> > existing schemes already use the MSK directly in specific ways 
> > (dynamic WEP for example).  If we could start over we could 
> just have 
> > one key and derive everything from that.  We could decide 
> to deprecate 
> > the MSK and derive everything from the EMSK.
> >
> 
> Why don't we just derive everything from the EMSK.  We could 
> derive the MSK 
> from the EMSK and then MSK' from the EMSK for a second AP, 
> and then MSK'' 
> for the third AP, and then MSK'' for some other application.  
> It seems to 
> make things conceptually simpler and easier to understand if 
> it is done 
> this way. Am I missing something?
> 

[Joe] This would be simpler, but it would break the way existing methods
derive keys. What I would like to see is we only use the MSK for its
current (legacy) usage.  For everything else we derive from the EMSK.  I
think this is feasible if the current consumers of EAP use it in this
way.  This is currently difficult since the EAP 2284bis does not define
how to use the EMSK.  There is also the problem of delivering the key
material to the NAS. RADIUS does not deifne a very flexible way to do
this and it doesn't appear that Diameter does either.