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

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 1 Nov 2005 11:23:16 -0800

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, November 01, 2005 10:56 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]
> 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
> [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: Tue, 01 Nov 2005 11:31:38 -0800

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

Keys can't simultaneously be transported and cached.  So either a given AMSK 
is cached, or it is transported, not both. Otherwise you end up with 
multiple parties in possession of the TSKs -- which violates one of the 
fundamental security goals.

This doesn't really seem like a big deal though, since a lower layer can 
request multiple AMSKs.  If it needs an AMSK for caching, it can ask for 
that, in addition to a separate AMSK that is transported.

>separate reservations about the caching

Can you describe your reservations?  In looking at AAA server caching, it 
seems to me like it could open up a lot of new security vulnerabilities, 
some of which we may not be able to anticipate.

For example, if a key exists in a AAA server cache, does the EAP peer know 
where that key is, and how to reference it?  If the EAP method doesn't 
export a Server-ID, I think the answer to this question is "no".

>keys from an AMSK derived for the purpose of pre-emptive key distribution

Right.  For example, the "Pre-emptive Keying" proposal could be rewritten to 
cache an AMSK and derive keys from that, rather than from the EMSK.

>services so it is possible to derive these AMSKs at the same time.

All these services exist within a single lower layer, right?  Presumably the 
lower layer knows that it will need these AMSKs, so it can ask the EAP layer 
for them.

>thousands of keys for ciphering, hand-off, buying auto-parts, etc.

Right.  The lower layer gets to define the appropriate caching behavior.

>be the case then AAA may need to have access to a KDF that has access to

I think you've proposed a solution to this -- caching of an AMSK from which 
"on demand" keys can be derived.  If things are done this way, then the 
lower layer does not require access to the EMSK.