Subject: RE: [eap] Issue: AAA Key Caching effectively prohibited?

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 2 Nov 2005 12:43:34 -0500

> 1. We've talked about deletion of transported keys from the AAA 
> server.  So if an MSK (or AMSK) is calculated within the AAA layer and

> subsequently transported, that key is destroyed and cannot be cached.
> 
[Joe] I don't think we have said that the AMSK must be deleted or cannot
be cached.  It should be the contrary, the AMSK is a quantity that an
application such as AAA can use for the purpose it has defined. 

Madjid>> AAA can _use_? How about create and keep?

[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? 

> To be able to do this, it would seem like the AAA server would need to

> have access to the EMSK -- since the EAP layer doesn't cache EMSKs, 
> how else could AMSKs be calculated once EAP authentication completes?

> In the case of roaming systems it is not feasible to ask the EAP layer

> to calculate every conceivable AMSK that could be useful -- there 
> could be thousands of them.
> 
[Joe] An AMSK is an application specific master key.  Typically there
are a few applications for key material that will be invoked for a
particular EAP transaction.  For example you might have L2 ciphering,
preemptive hand-off and Joe's service activation.  Each of these would
get their own AMSKs, in addition my assumptions is that in many cases
you know if you have the capability or the desire to perform these
services so it is possible to derive these AMSKs at the same time.
These AMSK's may be cached by entities that will then use them derive
thousands of keys for ciphering, hand-off, buying auto-parts, etc.  

Are there cases where we really have 1000's of different applications or
where the application is not known ahead of time.  If this turns out to
be the case then AAA may need to have access to a KDF that has access to
the EMSK. 

Madjid>> I gave 3 examples in my previous email. Are we now creating yet
another entity in the protocol? What is a KDF in relation to EAP server
and AAA server?

> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 02 Nov 2005 09:52:08 -0800

>application such as AAA can use for the purpose it has defined.

Agreed.

>Madjid>> AAA can _use_? How about create and keep?

The AAA layer cannot create an AMSK because it does not have access to the 
EMSK. So it can only receive an AMSK.

>then things work out a bit better.

Right.  This makes sense.

>AMSK that is already called application master key?

No.  We are saying that the AMSK is used as the root of a lower layer key 
hierarchy.

>Not sure what "rainy day" we are saving EMSK for? Why have so many key 
>levels, does anybody

The EMSK is not cached, so there is no "rainy day" that it is being saved 
for -- it is used to calculate AMSKs passed to the lower layer and then is 
lost.

BTW, a concern about key hierarchy depth and handoff does not appear to be 
shared by the organizations that are designing those protocols.  IEEE 
802.11r, for example, had three layers of key hierarchy last time I looked.
>another entity in the protocol?

No other entities have been discussed so far.

>What is a KDF in relation to EAP server and AAA server?

KDF = Key Distribution Function.   This is a cryptographic function used to 
calculate AMSKs.  It is not an entity.