eap Mailing List: Re: issue: key separation

[Bernard Aboba (bernard_aboba]

> 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