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

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 1 Nov 2005 12:17:36 -0800

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, November 01, 2005 11:32 AM
> To: Salowey, Joe; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Nov 2005 09:39:03 +0200

>the AMSK is to keep one applications misuse of keys from harming
Right. This is what I believe we need to specify in the keying
framework. (And we can't probably specify much beyond that,
given that we don't even know what the applications are.)

>should not be computationally feasible to get the EMSK from and AMSK.  
I agree.

Note: "destroy EMSK as soon as possible" can be
interpreted in various ways. I don't think it would be appropriate
for the EAP server to get rid of the EMSK problem by delivering
it to the lower layer and forgetting about it. Essentially, the
EMSK needs to stay in the physical box where the EAP method
runs, but we have had troubly defining what that exactly
means. Also, it only needs to exist while there's a possibility that
AMSKs can be requested. This is another hard-to-specify part -
when can AMSKs be requested?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 06 Nov 2005 02:41:50 +0200

Bernard Aboba wrote:

>My own reservations with AAA server caching derive from the issues 
>surrounding "on demand" key creation:
>
>a. Presumably keys are created "on demand" only when requested by either 
>the EAP peer or authenticator.  This implies that the EAP peer or 
>authenticator keep track of which AAA server is caching which keys, so 
>that they can direct subsequent requests to a server capable of answering 
>them. 
>
>b. However, all EAP methods do not provide the Server-ID, which uniquely 
>identifies the EAP server which has produced a given key.  Also, an EAP 
>authenticator/AAA client may not necessarily control which AAA server it 
>is talking to; it just sends an Access-Request with an NAI in the 
>User-Name attribute and it is routed to a destination.  The Access-Accept 
>may not identify the originating AAA server well enough to allow the AAA 
>client to go back to that same AAA server again to request an "on demand" 
>key from it.  Given this, it is not clear to me how a "Key Request" mode 
>could be made to work with all EAP methods or AAA configurations. 
>  
>
These issues seem largely orthogonal to the question of
whether the caching applies to the EMSK, AMSK, or f(AMSK).

Having said that, I'm not sure its our task (in the keying
framework) to design key-req architecture. All we need
to do is to describe the current key usage (msk etc) and
provide a "handle" such as the emsk/amsk for potential
new designs, along with some basic rules for their usage.
The question in this thread has been whether preventing
emsk delivery to AAA or requiring deletion of keys sent
over AAA prohibits some useful designs. From what I can
see, the answer is "no" -- as has been demonstrated,
appropriate design of the key hierarchy appears to
make such designs possible even under these assumptions.
However, there might be additional issues not brought
up in the keying framework requirements that such designs
need to take into account - such as ability to locate the
right AAA server. That is no fault of the keying framework,
and hence does not need to be discussed in it. Very
important for extensions, though.

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://lists.frascone.com/mailman/listinfo/eap