eap Mailing List: RE: Issue: AMSK generation?

[Bernard Aboba (bernard_aboba]

> The
> authenticator keys are calculated from not just AMSK but also AAA-key.

The terminology could use some cleaning up, but the idea is that the AAA 
layer uses an AMSK as the root of its key hierarchy, and creates additional 
keys from the AMSK.    Specifically, in the formulas cited, the AAA server 
is creating cryptographically separate keys for use by authenticators to 
which the EAP peer might connect in the future.

> We are stating, if a key is shipped to authenticator it must be deleted,
> so that means neither AMSK nor MSK can be shipped to authenticator.

The MSK could still be shipped to the original authenticator, I think.  
Since the EMSK and MSK are cryptographically separate, transporting the MSK 
does not compromise the EMSK or any AMSK derived from it.  But it is true 
that the AMSK from which multiple keys are derived needs to be cached within 
the AAA layer and never transported, so that other keys can be calculated 
from it.

> For every handover you HAVE to go to the AAA server

To date, we have had proposals for "Key Request" and "Pre-emptive Keying" 
support. In "Key Request" the EAP peer contacts the AAA server, proves 
possession of the AMSK, and asks that a key derived from it be sent to an 
authenticator that it may potentially connect to.  In "Pre-emptive Keying" 
the AAA server derives a key from the AMSK and sends it to the NAS without 
contacting the EAP peer.  So in both cases, the AAA server is involved.

The "Key Request" approach has the advantage that it is compatible with 
roaming scenarios, since the key distribution is controlled by the EAP peer, 
which has the best knowledge of potential roaming candidates.  The 
"Pre-emptive Keying" approach only works in situations where the AAA server 
has developed knowledge of the network topology through experience;  in 
practice this only works well in intra-domain scenarios. Also, in 
"Pre-emptive Keying" the EAP peer and AAA server only mutually authenticate 
during the initial EAP conversation.  This implies that the AAA server may 
end up sending keys to authenticators which the EAP peer is unlikely to ever 
contact.

> And also remember that Bernard said 802.11r and others have multiple
> layers of hierarchy. I like to think that it means the BS/ AP gets
> another key derived from AAA-key-B, so you called-station-ID cannot
> really be the BS/ AP id, but the authenticator ID.

Right.  The issue is not really handover between BSSIDs, it's handover 
between authenticators.

> Yes, but when you generate one AMSK and delete EMSK
> immediately, how do you delete further AMSKs?

It's possible to generate multiple AMSKs from a single EMSK.  It's also 
possible to cache one AMSK, and transport another one.  The AAA layer can 
create as many keys as it needs to from the cached AMSK.