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

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 02 Nov 2005 06:59:45 -0800

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

I think the way that the architecture is specified now, it is not possible
to cache the EMSK.  Only lower layers are allowed to cache, and the lower
layer (including AAA) never obtains the EMSK, only AMSKs.

My assumption has been that AMSKs can only be requested by the lower layer
while the EAP method is running.  As Joe suggested, if there is a need for
*on demand* keys, this can be satisfied by deriving them from an AMSK.
Since the EAP layer does not cache keys, there is no way for a lower layer
to request an AMSK at some other time, since the EAP layer will not have
any keying material with which to carry out the request.

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.

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

---

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 2 Nov 2005 10:01:22 -0800

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Wednesday, November 02, 2005 9:44 AM
> To: Salowey, Joe; Bernard Aboba; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [eap] Issue: AAA Key Caching effectively prohibited?
> 
>  > 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. 
> 
> Madjid>> AAA can _use_? How about create and keep?
> 
[Joe] The AAA can keep the AMSK if that is what the application
specifies to be done.  Generating an AMSK from an EMSK is a more
specialized function that needs to exist outside of AAA since EAP does
not require AAA.

> 
> [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. 
> 
> Madjid>>Are you saying we create our application specific keys out of
> AMSK that is already called application master key? Not sure 
> what "rainy day" we are saving EMSK for? Why have so many key 
> levels, does anybody care about the CPU and battery 
> consumptions down at a tiny mobile device that may have to do 
> all this? 
> 
[Joe] The EMSK is the root of a key hierarchy used only to generate
AMSKs.  This is to ensure that application keys are cryptographically
separate from one another so that one application does not cause a
compromise in another.  If the EMSK is used by multiple applications
this opens you up to a catastrophic compromise if one application has a
problem.

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 2 Nov 2005 12:56:28 -0500

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.

Madjid>>Why not both? Please remember that as I said earlier, even if
the AAA server can listen to the exchanges leading to the TSK
generation, AAA server is still considered as the main source of trust
in many network architectures. 
We know that many SDOs and technologies today do key context transfer at
the edge, so I am not worried about keeping the cache at the AAA server,
especially knowing that the AAA server may be asked for it later. I need
a solution that work both mobility and security wise, so if the tradeoff
is to trust a AAA server I will take it.

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

Madjid>> The current specification needs to be clear on the boundaries
of EAP server and AAA server and what is done in EAP layer and what is
done through AAA protocol. Once we have a crisp spec, then we have a
crisp problem definition and such problems are typically easier to solve
and whether layer pollution is a severe violation. This is similar to
the channel binding problem.

Madjid

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 2 Nov 2005 13:09:46 -0500

Madjid>>You can prune the roots as much as you want, as long as there is
something left that becomes the root for the tree. Bonsai Trees live for
many many years that way:) Joking aside, if you destroy the EMSK, keep
AMSK, then AMSK becomes your most  key and main source of vulnerability,
so I am not sure what is achieved?

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

Madjid>>I like to at least initially assume that an application is
authorized by the AAA server, and hence there is a level of mutual
awareness here.

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 2 Nov 2005 18:38:10 -0500

I am not sure I understand this security model, if we are not trusting
EAP server or AAA server with not sniffing TSK derivation, or we have
issues with the server knowing the TSKs, how could we trust it to
actually go ahead and delete the keys?? 

What kind of security model is it that instead of hiding a secret to
begin with, ask the untrusted party to create it first and then delete
it really quickly??

Now all that aside, are we saying have an AMSK generated from EMSK, and
then pass AMSK down to the AAA server and then derive all application
keys from AMSK? 
Can the AAA server still keep the AMSK? What about the application keys?
Can it keep them even after sending them away, or the same security
philosophy applies here?

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2005 3:07 PM
To: Jari Arkko
Cc: Bernard Aboba; Nakhjiri Madjid-MNAKHJI1; [email-masked]
Subject: Re: Issue: AAA Key Caching effectively prohibited?

> From what I can recall, our earlier discussions about this focused on 
> the MSK. I'm not sure the same should apply on AMSKs, particularly 
> when we haven't defined what they are used for.

The principle is a general one -- if a key that is transported is to be
used for derivation of TSKs that are only to be known to the EAP peer
and authenticator, then that same key cannot also continue to be held by
the EAP server, or the fundamental security assumption is no longer
valid.  

As an example, the Secure Association Protocol relies on mutual proof of
possession of keying material to enable the EAP peer and authenticator
to determine that they are mutually authorized.  If the keying material
used for proof could also possessed by other parties then mutual
authorization is not demonstrated -- the EAP peer could be talking to
the AAA server or a proxy instead of the EAP authenticator.  

In this situation, the security model of EAP falls apart -- the EAP peer
and authenticator no longer demonstrate authorization; the keys are not
uniquely held;  Channel Bindings are subject to forgery;  the scope of
transported keys and TSKs is undefined.  About the only thing that can
still be asserted about the exchange is that the TSKs are fresh --
although it's questionable how valuable this is if the other properties
are absent. 

> But it seems possible to hand keys to lower layers (e.g. AAA server 
> side logic) that are themselves branching of to number of subkeys.
> E.g. "the master handoff key for session xyz". The entity holding such

> an AMSK can then branch it to, e.g., "the i:th handoff key for NAS 
> abc". There's a lot of room to do various designs, including proxy, 
> AAA-server etc. based caching.

Right.  I think this solves the problem. 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Vanderveen, Michaela" <[email-masked]>
Date: Thu, 3 Nov 2005 13:30:09 -0500

<snip>

> Also by deleting the transported 
>keys, the EAP authenticator and peer can derive other
>keys (the TSKs) 
>known 
>only to those parties and not to the AAA server

AAA server cannot derive TSKs even if it did not
delete the transported key because the secure
association protocol exchange involves other
parameters e.g. nonce, in the exchange that is known
just to the authenticator and the peer.

MCV>> The nonces are often sent over a wireless link, so
open for anyone (including a devious AAA server) to listen
to. 

So, what useful attack can the AAA server (which the
peer has a trust relationship with) do by holding
on to the transported key ? Even if it holds on to it
(erroneous or deliberate), but can never derive any
keys that will be used in the commuication between the
authenticator and the peer, would it not be okay ?
I understand that from security point of view, it
makes
no sense for three parties hold on to the same key.
But here the AAA server cannot do much with it
i guess. At least, it cannot send it to other NASes
as the peer can find it out as you have explained
below. Are there any other attacks we are concerned
about ? 

MCV>> I don't think there is any useful attack here.
I find it odd that the AAA server is trusted and then
all of a sudden (once keys get derived) becomes
"suspicious". The problem seems to be one of "access"
i.e. need-to-know basis. If the AAA server was truly
trusted, then if it did not need to know the transported
key, then it would be ok to keep the key from it. But
since it already knows it, it doesn't make sense to 
enforce that it deletes this key.

-mohan

> For example, if the AAA server does not delete
> transported keys, and resends 
> them to another NAS, if the NAS is properly
> identified in the SAP exchange, 
> then the peer can determine that it has access to
> keys that it is not 
> authorized to possess.  If the keys are bound to
> their context, then the 
> peer can detect a binding mismatch.
> 
> For example, on Yoshi's proposed "Channel Bindings"
> proposal, it is not 
> possible for the AAA server to send the same key to
> multiple NASes and have 
> the EAP peer successfully negotiate use of that key,
> because the key is 
> bound only to the NAS that the EAP peer believes it
> should be communicating 
> with.
> 
> 
> 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Thu, 3 Nov 2005 17:30:45 -0500

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Wednesday, November 02, 2005 11:52 AM
To: Nakhjiri Madjid-MNAKHJI1; [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.

Agreed.

Madjid2>> Say, I need two keys for two authenticators, do I create a K1
and K2 from AMSK at the AAA layer?
If yes, then do I have to delete K1 after sending it to authenticator 1?

If no, and K1 and K2 are considered AMSK1 and AMSK2, do I have to send a
request for two keys to EAP server, before it deletes the EMSK?
On the top of all this,last time I looked at extensions draft,
definition of AMSK includes both EMSK and AAA key, 
>Madjid>> AAA can _use_? How about create and keep?

The AAA layer cannot create an AMSK because it does not have access to
the EMSK. So it can only receive an AMSK.

Madjid2>> See previous question, please

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

Right.  This makes sense.

Madjid2>> The word of "Pre-emptive" is dangerous here? Does it mean the
AAA server pre-emptively asks for multiple AMSKs from EMSK? 
For Handover, this will not work, you have to anticipate all the
moves... 

>AMSK that is already called application master key?

No.  We are saying that the AMSK is used as the root of a lower layer
key hierarchy.

>Not sure what "rainy day" we are saving EMSK for? Why have so many key 
>levels, does anybody care about the CPU and battery consumptions down 
>at a tiny mobile device that may have to do all this?

The EMSK is not cached, so there is no "rainy day" that it is being
saved for -- it is used to calculate AMSKs passed to the lower layer and
then is lost.

Madjid2>> By "rainy day", I was referring to "for future use" in 
	"The EMSK is reserved for future use and MUST remain on the EAP
      peer and EAP server where it is derived;"
In the 08 draft. And by the way this conflicts "deleting EMSK right
away..."

BTW, a concern about key hierarchy depth and handoff does not appear to
be shared by the organizations that are designing those protocols.  IEEE
802.11r, for example, had three layers of key hierarchy last time I
looked.

Madjid2>>Well, I am advocating for several layers as well, that is why I
am asking for AMSK clarfications and delete requirements. May your
latest look was later than mine and 11r is a happier family than
WiMAX/16e:) but at least in WiMAX, nobody knew about the latest "delete
key" requirements until very recently and that is why I started my
review. I don't want to deal with a hierarchy that chops itself off
prematurely..

>Madjid>> I gave 3 examples in my previous email. Are we now creating 
>Madjid>> yet
>another entity in the protocol?

No other entities have been discussed so far.

>What is a KDF in relation to EAP server and AAA server?

KDF = Key Distribution Function.   This is a cryptographic function used
to 
calculate AMSKs.  It is not an entity.

Madjid2>> I think people have already started inserting a Kerberos into
the mix, so KDF is more than a function ;)
_______________________________________________
eap mailing list
[email-masked]
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Tue, 8 Nov 2005 17:21:02 -0500

Ok, let me think loud, EMSK is not cached, can I use AMSK to design some
sort of EAP-method independent fast re-authentication procedure without
worrying if the method I am using has fast re-auth or not?  

To answer to the other points, re-authentication may have to be done
even when you are not doing HO. Anyway, regardless of that point, Having
to go to AAA server once is different from doing a full EAP-TLS exchange
involving several roundtrips.

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Saturday, November 05, 2005 6:18 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]
Subject: Re: Issue: AAA Key Caching effectively prohibited?

Nakhjiri Madjid-MNAKHJI1 wrote:

>Several EAP methods (EAP-AKA) are adding fast re-authentication 
>procedures, based on the knowledge of master key (have to read the 
>draft again, to see which key is needed) after the initial 
>authentication. If you delete the key, you cannot perform fast
re-authentications.
Methods do indeed have fast re-auth schemes. However, the keys they use
are internal to the methods (TEKs) and not exported or visible to the
EAP layer, lower layer, or AAA.
That is, they do not need EMSK or AMSK support.
Caching of TEKs is allowed by the keying framework.
Section 3.3 says:

   EAP methods may cache local keying material which may persist for
   multiple EAP conversations when fast reconnect is used [RFC 3748].
   For example, EAP methods based on TLS (such as EAP-TLS [RFC2716])
   derive and cache the TLS Master Secret, typically for substantial
   time periods.

Anyway, the use of such fast re-auth schemes helps with expensive auth
procedures (such as in TLS) or when there's a potentially high volume of
operations to the long-term secret that you may wish to optimize (such
as in SIM/AKA). However, this does not help minimize AAA transactions to
the home network. That is, its not a fast handoff mechanism if "fast
handoff" is defined as an operation that does not need another
transaction all the way back to the home network.

--Jari