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

[Bernard Aboba (bernard_aboba]

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

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.

> [Joe] I'm not sure that we agree on AAA as a lower layer. But I have
> 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".

> [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 derived for the purpose of pre-emptive key distribution
> then things work out a bit better.

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.

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

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.

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

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

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

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.