Subject: RE: [eap] Issue: AMSK generation?

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Thu, 3 Nov 2005 17:46:21 -0500

Refreshing the subject to do something constructive with the thread.
Before everybody wears out, lets look if we can work on the AMSK recipe
:)

Madjid

[Joe] The AAA can keep the AMSK if that is what the application
specifies to be done.  Generating an AMSK from an EMSK is a more
specialized function that needs to exist outside of AAA since EAP does
not require AAA.

Madjid2>>Outside AAA? Where? In EAP layer. Ok, lets see the latest
definition of AMSK I have seen (in draft-Aboba-eap-keying-extens-00.txt)
do not really give a clean separation of AMSK from MSK/EMSK. The
authenticator keys are calculated from not just AMSK but also AAA-key. 

     AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments",
                  length)

      AAA-Key-B = prf(AMSK(0,63),"EAP AAA-Key derivation for
                  multiple attachments", AAA-Key, B-Called-Station-Id,
                  Calling-Station-Id,length)
	AAA-Key-C = prf(AMSK(0,63),"EAP AAA-Key derivation for
                  multiple attachments",AAA-Key, C-Called-Station-Id,
                  Calling-Station-Id, length)

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, so
they must stay at the AAA server, which means for every handover you
HAVE to go to AAAs server.
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.

> 
> [Joe] This depends on how you define your key hierarchy.  If you 
> derive your keys directly from the EMSK you have a problem.  If you 
> define your keys from an AMSK derive for the purpose of pre-emptive 
> key distribution then things work out a bit better.
> 
> Madjid>>Are you saying we create our application specific keys out of
> AMSK that is already called application master key? Not sure what 
> "rainy day" we are saving EMSK for? Why have so many key levels, does 
> anybody care about the CPU and battery consumptions down at a tiny 
> mobile device that may have to do all this?
> 
[Joe] The EMSK is the root of a key hierarchy used only to generate
AMSKs.  This is to ensure that application keys are cryptographically
separate from one another so that one application does not cause a
compromise in another.  If the EMSK is used by multiple applications
this opens you up to a catastrophic compromise if one application has a
problem. 

Madjid>> Yes, but when you generate one AMSK and delete EMSK
immediately, how do you delete further AMSKs?
_______________________________________________
eap mailing list
[email-masked]
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 03 Nov 2005 15:06:23 -0800

>The

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.

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

>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

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.