eap Mailing List: RE: Issue: AAA Key Caching effectively prohibited?

[Salowey, Joe (jsalowey]

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
> Sent: Tuesday, November 01, 2005 10:56 AM
> To: bernard_aboba [at] hotmail.com; Madjid.Nakhjiri [at] motorola.com; 
> aboba [at] internaut.com
> Cc: jari.arkko [at] piuha.net; eap [at] frascone.com
> Subject: [eap] Issue: AAA Key Caching effectively prohibited?
> 
> I would like to point out one other consequence of preventing 
> lower layers (including AAA) from accessing the EMSK.  It 
> appears to me that this severely restricts implementation of 
> a key cache on the AAA server.
> 
> 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. 

> 2. We've talked about how the EMSK cannot be passed down to 
> the lower layer (including AAA).  Therefore the EMSK also 
> cannot be cached by the AAA layer.

[Joe] I'm not sure that we agree on AAA as a lower layer. But I have
separate reservations about the caching 

> 
> 3. Given 1) and 2) what keys *can* be cached in the AAA 
> layer?  Limited answers appear to be available.  Caching of 
> MSKs does not make much sense, even if they are not 
> transported in a particular application, because some 
> applications *do* transport MSKs.
> 
> It would be possible for the AAA layer to request more than 
> one AMSK, then cache the AMSKs that are not transported.
> 
> However, this approach does not appear to enable 
> implementation of schemes such as "Key Request" and 
> "Pre-emptive Key Distribution", both of which appear to 
> require the AAA layer to calculate AMSKs *on demand*.
> 

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

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


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