RE: WGLC for eap-keying: EAP server-AAA server
From: Salowey, Joe (jsaloweycisco.com)
Date: Tue, 1 Nov 2005 12:53:04 -0500 (EST)
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. 


Results generated by Tiger Technologies using MHonArc.