Subject: [eap] Proposed Resolution to Issue 323: AAA Key Cache

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 08 Jan 2006 10:37:54 -0800

The text of Issue 323 is available here:
http://www.drizzle.com/~aboba/EAP/eapissues3.html#Issue%20323

The proposed resolution is as follows:

Change the text in Section 2.3 to the following:

"AAA

Existing AAA client, proxy and server implementations supporting RADIUS/EAP 
[RFC3579] or Diameter
EAP [RFC4072] do not support caching of EAP keying material or
parameters.  In existing AAA client, proxy and server implementations, 
exported EAP
keying material (MSK, EMSK and IV) as well as parameters and
derived keys are not cached and MUST be presumed lost after the AAA
exchange completes.

In order to avoid key reuse, the AAA layer MUST delete transported
keys once they are sent.  The AAA layer MUST NOT retain keys that
it has previously sent.  For example, a AAA
layer that has transported the MSK MUST delete it, and keys MUST
NOT be derived from the MSK from that point forward."

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 11 Jan 2006 11:55:32 -0500

If caching of MSK/EMSK is a MUST NOT for 4072 and 3579 and not for 3748,
then why don't we state it so? And why do we make the caching a MUST NOT
in a general case?

Also, if the focus is document the existing behavior of the 3 RFCs
below, rather than providing guidance for future uses of EAP keying,
then the document should not state:

"This document specifies an Internet standards track protocol for the
   Internet community,..."
On the front page. 
Because the way it is, it is not very accommodating for future uses of
EAP keying framework. Having to remove the cache of a key after
transport of say from AAA server to AAA client, will not allow the AAA
server to use that key for further keying. A simple example is if you
want to bootstrap a key for two agents, each of them behind one separate
AAA client (take an AR and an HA in MIPv6 example), 

Agent 1<--AAA client1<------AAA server---->AAA client 2---->agent 2
if you have RADIUS and move the key based on the request from one
client, you have to delete it, then you cannot send it to the second AAA
client. 

Is there anywhere in the AAA key management requirement that says AAA
server cannot be trusted with the keys?

Madjid
-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Tuesday, January 10, 2006 3:58 PM
To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
Subject: RE: [eap] Proposed Resolution to Issue 323: AAA Key Cache

>1)Why do we mean by "existing implementations" and why does it matter?

The focus of  this work item is on describing the behavior of RFC 3748,
4072 and 3579 implementations.

>This document should provide requirements going forward. Is "caching 
>MSK/EMSK" a MUST NOT, a SHOULD NOT, or something else?

Caching of MSK/EMSK is a MUST NOT for RFC 4072 and 3579 implementations.

>2) The text requires deleting of a key (I am assuming this includes
>AMSK) after transport to avoid key reuse.

The text refers to any key that is transported, so yes it would also
apply to an AMSK.  This follows from the security assumptions and AAA
Key Management requirements.  Unless those requirements are met, this
document will not be approved by the IESG.

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 18 Jan 2006 13:50:51 -0500

Hi Joe,  

-----Original Message-----
From: Salowey, Joe [mailto:[email-masked]] 
Sent: Sunday, January 15, 2006 9:22 PM
To: Nakhjiri Madjid-MNAKHJI1; Bernard Aboba; [email-masked]
Subject: RE: [eap] Proposed Resolution to Issue 323: AAA Key Cache

> want to bootstrap a key for two agents, each of them behind one 
> separate AAA client (take an AR and an HA in MIPv6 example),
> 
> Agent 1<--AAA client1<------AAA server---->AAA client 2---->agent 2 if

> you have RADIUS and move the key based on the request from one client,

> you have to delete it, then you cannot send it to the second AAA 
> client.
> 

[Joe] Why do you want to use the same key in both places?

Madjid>>Think the Proxy Mobile IP example. We need a shared key between
the proxy mobile node, PMN (an entity within the network, not the peer)
and home agent, HA. So that the PMN can send authenticated messages to
the HA and vice versa.

> server cannot be trusted with the keys?

[Joe] If I understand the current text correctly it is stating that an
entity should not simultaneously cache and transport a key.  In general
this is good practice because it prevents reuse of a key, if you are
going to give someone else a key for a specific purpose you should not
hold onto it for another use.  While I don't  agree with a MUST NOT
cache transported keys, I would question why you would want to do this.
It seems that the current text allows one to cache a key and export keys
derived from it.  Perhaps the text should explicitly say so. 

Madjid>> Well this is an example why you do need to hold on to it (not
for another use however). I think these strict requirements should be
put to test for each specific usage scenario.

---

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 19 Jan 2006 09:02:22 -0800

> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Wednesday, January 18, 2006 10:51 AM
> To: Salowey, Joe; Bernard Aboba; [email-masked]

[Joe] Ok, it seems this key would be different than the mobile nodes key
and that the PMNs don't all ned to share the same key. 

> put to test for each specific usage scenario.
[Joe] yes, you need to hold onto the key, but instead of transporting
the "cached" key you transport keys derived from the cached key.  Does
this meet the requirements of your usage scenario?

---

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 24 Jan 2006 23:49:03 -0800

How about:

"In order to prevent keys from exposure beyond their intended usage a
key should not typically be both transported and cached by an entity.
An entity may cache a key for the purpose of deriving additional keys
for other uses.  In this case they cached key should only be used for
key derivation purposes and the key derivation function should provide
cryptographic separation between the derived keys and the cached key."

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, January 16, 2006 6:46 PM
> To: Salowey, Joe; [email-masked]
> [BA] I don't know why that would be necessary or desirable.  
> 
> [BA] That sounds reasonable.  Do you have some text to suggest?
>

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 25 Jan 2006 16:51:21 -0500

Hi Joe, 

-----Original Message-----
From: Salowey, Joe [mailto:[email-masked]] 
Sent: Thursday, January 19, 2006 11:02 AM
To: Nakhjiri Madjid-MNAKHJI1; Bernard Aboba; [email-masked]
Subject: RE: [eap] Proposed Resolution to Issue 323: AAA Key Cache

> the proxy mobile node, PMN (an entity within the network, not the 
> peer) and home agent, HA. So that the PMN can send authenticated 
> messages to the HA and vice versa.
> 

Madjid2>>In the PMIP example, the MN does not need to have access to the
PMIP-key. It is to be shared between the PMN and HA. And yes, the way we
envisioning it, only one PMN is to hold the key (you may want to call
that anchoring).
Please see, 
http://www.ietf.org/internet-drafts/draft-nakhjiri-pmip-key-01.txt

For more info.

Madjid>>not without unnecessary additional steps. You still need to send
the same key to two different places, regardless of how many levels of
hierarchy you generate, unless you say, 
I have to generate a parent-key (Kp) and child-key (Kc) and use Kc for
my application (say PMIP). To comply with deleting the transported key,
you will derive Kc from Kp and send the Kc over to one agent, you must
delete Kc now, then you send Kp to another agent and make sure the
second agent knows _EXACTLY_ how to generate Kc from Kp and at the end,
agent1 and agent 2 can share Kc.
All this seems to be very unnecessary, just because we require
transported key to be deleted.

Madjid