RE: Proposed Resolution to Issue 323: AAA Key Cache
From: Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjirimotorola.com)
Date: Wed, 11 Jan 2006 08:56:58 -0800 (PST)
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:bernard_aboba [at] hotmail.com] 
Sent: Tuesday, January 10, 2006 3:58 PM
To: Nakhjiri Madjid-MNAKHJI1; eap [at] frascone.com
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.



Results generated by Tiger Technologies using MHonArc.