eap Mailing List: RE: WGLC for eap-keying: EAP server-AAA server

[David Mitton (david]

While we're at it....

                 Where is the term "AMSK" defined?

Dave.

----- Original Message -----
From: "Salowey, Joe" <jsalowey [at] cisco.com>
To: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri [at] motorola.com>, "Bernard 
Aboba" <aboba [at] internaut.com>
Subject: RE: [eap] WGLC for eap-keying: EAP server-AAA server
Date: Tue, 1 Nov 2005 09:58:35 -0800

> 
> Hi Madjid,
> 
> Comments below.
> 
> >
> > > ***PMK definition should be generic.
> >
> > The term "PMK" was originally defined in IEEE 802.11 and is not used in 
> > [RFC3748].  Given this, I'm not clear that it would be appropriate to 
> > redefine it in this document.  As far as I can tell, everywhere the term 
> > "PMK" is used in both IEEE 802.11 and 802.16, it is equivalent to 
> > MSK(0,31). 
> > Madjid>> 802.16 D10 has already graduated to at least two PMKs:
> >
> > 1) EIK | PMK =truncate (MSK, 320)
> > 2) PMK2= truncate (MSK, 160)
> >
> > So I think a more generic definition of PMK is apt, that is IF a definition 
> > of PMK would really add value to this draft (rather than creating 
> > confusion). I personally think, if AMSK went to the extension draft, so 
> > should PMK.
> >
> [Joe] The derivation and use of the PMK is defined in the lower layer.
> It is possible to use the MSK without defining a PMK.  The AMSK is
> somewhat different.  It should not be possible to use the EMSK directly,
> but only use AMSKs derived from it.
> 
> 
> > > ***TEK and TSK both use the word "session keys" as the start of the > 
> > definition, whereas the mean completely different "session" (if you > will).
> >
> > It would probably help to make it clear that TEKs relate to the EAP 
> > conversation and TSKs relate to data.  I think that this may have been 
> > described in some of the material that was removed. Madjid>>The draft does 
> > have a "session ID" for EAP, so why not use it
> > when providing clarification?
> >
> > > Given that EAP methods produce MSK and EMSK and export (presumably to > 
> > the AAA server), it is probably the AAA server that creates the > AAA-key 
> > out of the MSK and send it over? Specially given that we say > EAP server 
> > dumps the MSK after export? Does it dump the MSK and keep > the AAA key 
> > then? Do we want to leave this to interpretation?
> >
> > In -08 the term "AAA-Key" is used only once, within the definition.  
> > Several 
> > commenters had felt that the term was confusing, so that it has been 
> > removed.  Perhaps it might be clearer if the following definition were used 
> > instead:
> >
> > AAA-Key
> >      The term "AAA-Key" is synonymous with MSK.  Given the above 
> > definition, 
> > the lower layer does not "create" the AAA-Key; it is passed down to it from 
> > the EAP Method.  There has been some discussion as to whether the lower 
> > layer "creates" AMSKs after receiving the EMSK from the EAP layer, or 
> > whether the EAP layer keeps the EMSK secret from the lower layer and 
> > calculates AMSKs from the EMSK based on a request from the lower layer. 
> > Madjid>>Given that the concept of AMSK seems so powerful and easy to
> > grasp, but I am not clear why it has to be created from EMSK, not MSK (can 
> > the lower layer cache the AMSK?) My personal confusion aside, it feels that 
> > AAA-key is here only for historical reason. Once you are completed the 
> > daunting task (may be a timely thing given that this is Oct 30 :) ) of 
> > understanding the key hierarchy of an EAP method and then SAP and all that, 
> > you then have to try to justify why another key that is btw synonymous with 
> > MSK is needed? And BTW what does "synonymous" mean with respective to RFC 
> > 2119?? Is every MUST for MSK, a MUST for AAA-key, and so forth??
> >
> 
> [Joe] The choice of AAA-Key term in the EAP RFC was unfortunate, it
> think it would have been better if we stuck just with the MSK.  Existing
> lower layers already use the MSK directly so I don't think defining
> AMSKs derived from this quantity is appropriate in this document.  I
> think it does make plenty of sense to define a key hierarchy in
> documents specifying lower layers.  In order to allow multiple keys to
> be derived independently for different purposes from EAP coordination
> key derivation is required.  This is the purpose of the EMSK and AMSK
> hierarchy.
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap