eap Mailing List: RE: issue: key separation

[Salowey, Joe (jsalowey]

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
> Sent: Friday, December 02, 2005 7:34 AM
> To: eap [at] frascone.com
> Cc: aboba [at] internaut.com
> Subject: Re: [eap] issue: key separation
> 
> >Yes. I guess my basic comment boils down to: how should EAP 
> key mgmt be 
> >done "tomorrow"? I.e. how do we provide things such as key 
> separation, 
> >seamless inter access handover, etc. From what I now understand, it 
> >seems that EAP itself may not be a good place to specify 
> this sort of 
> >more "advanced" things.
> >
> >/Mats
> 
> That is a difficult question.  Here are some (semi-random) thoughts:
> 
> 1. With the increasing emphasis on "crypto-agility" we cannot 
> utilize hard-coded algorithms; every cryptographic algorithm 
> has to be negotiable.  
> Since within EAP methods ciphersuite negotiation is 
> restricted to what is necessary for the EAP method itself 
> (not the data or subsequent lower layer key derivation), EAP 
> itself cannot provide the required crypto-agility.
>
[Joe] EAP methods can provide crypto agility.  I don't see a need for
the lower layer to be involved. 
 
> However lower layers can provide the required agility.  The 
> implication seems to be that the algorithm used to generate 
> AMSKs from the EMSK needs to be negotiated in the lower 
> layer, and therefore the AMSK generation 
> algorithm cannot be hard coded  in the EAP layer.   If AMSK 
> generation 
> occurs in the EAP layer, this creates the prospect of 
> continually having to upgrade the EAP implementation every 
> time a new lower layer defines a new KDF for AMSK generation. 
>  This would seem to violate the principle of media independence.
> 

[Joe] The lower layer must not define the KDF for AMSK generation.  AMSK
generation must be independent of the lower layer.  The KDF for AMSK
generation should use an method dependent one or define its own. 


> This problem does not exist if the EMSK is passed down to the 
> lower layer, which can then generate AMSKs itself.  If a new 
> lower layer defines a different algorithm for AMSK 
> generation, then only that lower layer needs to change;  the 
> EAP implementation does not need to be upgraded.
> 

[Joe] The EMSK must not be passed down to the lower layer. 

> 2. IEEE 802.11r has developed a "fast BSS transition" scheme 
> which depends 
> only on the MSK.   The scheme does appear to be compatible 
> with much of the 
> "AAA Key Management" document, yet it does not require the 
> use of the EMSK.  
>   Here is how it works.
> 
> Something called the "PMK-R1" is derived from the MSK.  The 
> PMK-R1s are cryptographically separate from each other, and a 
> different PMK-R1 is derived for each port.  Note that within 
> IEEE 802.11r only a single authenticator (known as the 
> "Mobility Domain Controller") obtains the MSK 
> (PMK-R0), which is never shared with other authenticators.   
> At various 
> points there has been discussion of deleting the MSK (PMK-R0) 
> once the PMK-R1s are derived from it, although that is not in 
> the current document.
> 
> >From what I can tell, IEEE 802.11r does provide many of the required
> security properties, including key lifetime negotiation, 
> authenticator 
> identification, TSK freshness, ciphersuite and KDF/PRF 
> negotiation, etc.   
> It is true that compromise of the MSK will compromise the 
> entire "mobility domain".  However, it is possible to 
> configure the mobility domain so that it corresponds to a 
> single authenticator (e.g. a single WLAN switch).
> 
> Even where the "mobility domain" corresponds to multiple 
> authenticators, compromise of any authenticator that is not 
> also the Mobility Domain Controller does not lead to 
> cascading vulnerabilities.  In other words, obtaining one 
> PMK-R1 does not help you obtain other PMK-R1s or the MSK.  If 
> the MSK were to be deleted after PMK-R1 calculation, 
> compromise of a Mobility Domain Controller after PMK-R1 
> distribution would not lead to compromise of other 
> authenticators.  Only possession of the MSK would permit that.
> 
> There is still more work to be done with IEEE 802.11r 
> (Version 1.0 only issued recently), but it is well worth 
> reading.  Any IETF participant can participate in the ballot 
> process as a non-voter.  Here is a pointer to the document 
> (ask for the archive password if you don't already have it):
> http://grouper.ieee.org/groups/802/11/private/Draft_Standards/
> 11r/P802.11r-D1.0.pdf
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>