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 11:32 AM
> To: Salowey, Joe; Madjid.Nakhjiri [at] motorola.com; aboba [at] internaut.com
> Cc: jari.arkko [at] piuha.net; eap [at] frascone.com
> Subject: RE: [eap] Issue: AAA Key Caching effectively prohibited?
> 
> >[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] The applications define how they use AMSKs.  They could define two
different AMSKs for caching and transport if that was what was required.
There are lots of ways an application can misuse keys. The purpose of
the AMSK is to keep one applications misuse of keys from harming
another. 

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

[Joe] Mostly I have reservations about caching the EMSK.  The EMSK is
the root of a hierarchy and if you can obtain that then all uses derived
from it are compromised.  Therefore it would be good to destroy it as
soon as possible.  AMSKs should be cryptographically independent and it
should not be computationally feasible to get the EMSK from and AMSK.  

> 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] Some of this needs to be defined in the application usage of the
AMSK.  It is an interesting question as to what information an
application needs to reference a key.  I'm not sure we have discussed a
good answer for this yet.  


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

[Joe] These are all different applications that in general don't know
about one another, however the entity that is requesting the
authentication (EAP Authenticator system) has an idea of what
applications will be used.  It could potentially deliver keys to
multiple different applications/lower layers if necessary.   The lower
layer may be intimately involved in some aspects such as ciphering, but
for others it may have no knowledge.   There could be multiple lower
layers or enhanced services provided by a lower layer that operate
independently.  

It could also be possible for applications to be initiated independent
of the lower layer that the authenticator is unaware of.  This would
probably require some configuration of this applications within the
backend and the client. It could also be possible to negotiate these
between EAP peer and EAP server. 

> >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.
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>