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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi Joe,

Thank you for your email.
On your comment on PMK, you are providing a better rephrasing of my
argument. I think following a generic and _only informational_
definition of PMK (a pair wise master key to be shared between the peer
and the pass-through authenticator), it should state
" The derivation and use of the PMK is defined in the lower layer" (your
sentence) and is out of scope of this document. I also agree that it is
possible (according to the current spec) for the lower layer to use MSK
for security association protocol without creating PMK, but I don't know
why we are mandating for the AAA layer (at least AAA server) to delete
MSK (section 2.3) after forwarding it to the passthrough authenticator.
The spec has nothing on AMSK. AMSK is now in the extension draft and is
calculated based EMSK, even though this draft states that EMSK cannot be
used to derive other keys....
 
"The EMSK is reserved for future use and MUST remain on the EAP
      peer and EAP server where it is derived; it MUST NOT be
      transported to, or shared with, additional parties, or used to
      derive any other keys."


On your comment on AAA-key, I think we need be rid of AAA-key in this
draft or define a precise relation between AAA-key and MSK. EAP RFC
talked about AAA-key transport, we are talking about MSK transport here
based on the fact that AAA-key and MSK are the same in existing
implementation (I think it is ok for an informational draft to talk
about existing implementations, but not for a standards track document).

As far as AMSK, I am ok with not including AMSK here (I guess:) ), but I
don't agree with this document providing conflicting guidelines with
extension draft. 
By not sending EMSK down and asking to delete MSK after transport, we
are tying the architects hands from creating new AMSK use cases or
having other documents creating key hierarchies feeding off EAP keys..


Madjid

-----Original Message-----
From: Salowey, Joe [mailto:jsalowey [at] cisco.com] 
Sent: Tuesday, November 01, 2005 11:59 AM
To: Nakhjiri Madjid-MNAKHJI1; Bernard Aboba
Cc: Jari Arkko; eap [at] frascone.com
Subject: RE: [eap] WGLC for eap-keying: EAP server-AAA server

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.