RE: Issue: AAA Key Caching effectively prohibited?
From: Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjirimotorola.com)
Date: Wed, 2 Nov 2005 12:44:22 -0500 (EST)
 > 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
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
> 

Results generated by Tiger Technologies using MHonArc.