Subject: Re: [eap] issue: key separation

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 02 Dec 2005 07:34:13 -0800

>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.

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.

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.

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

---

From: "Salowey, Joe" <[email-masked]>
Date: Sun, 4 Dec 2005 21:53:29 -0800

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Friday, December 02, 2005 7:34 AM
> To: [email-masked]
> Cc: [email-masked]
> 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
> 
> 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 
> 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. 

> 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 
> 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.
> 
> 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):