eap Mailing List: RE: Proposed Resolution to Issue 323: AAA Key Cache

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi,

I am not sure whether I should post an issue of my own, or respond to
the proposal provided by Bernard to resolve this issue. I have two
issues with revising the text the way Bernard suggested: 

1)Why do we mean by "existing implementations" and why does it matter?
This document should provide requirements going forward. Is "caching
MSK/EMSK" a MUST NOT, a SHOULD NOT, or something else? And why are we
making a requirement based on the statement on "existing
implementations"?

2) The text requires deleting of a key (I am assuming this includes
AMSK) after transport to avoid key reuse. While, Yoshihiro's issue on
this text is that he assumes existence of a key holder (KDC) in the
architecture. 
        2a) I am not sure why a KDC is better trusted than a AAA layer
entity (specifically a AAA client or a AAA server).  
        2b) This means you cannot use EAP keying for bootstrapping keys
for a network protocol such as MIP, because after transport to the first
entity you must delete it. We did have a discussion on this in last
IETF. Unless, you actually move the AMSK to a non-AAA layer entity (such
as KDC) you cannot do that. I personally think the KDC should either be
a AAA client or in touch with one, if it is to receive keys from the AAA
infrastructure. Plus removing keys after transport is really different
from not caching them at all (I don't agree with either), as Yoshiro has
asked in his issue text.

This actually forces people to introduce a KDC in the network. Is that
the intention?

Thanks,

Madjid

Text from Yoshihiro
 The following text in section 2.3 of eap-keying draft talks about not
caching the keys at AAA layer, but mostly in terms of AAA servers.  I
think the text should be revised so that any AAA layer entity
including AAA client and AAA proxy does not cache the keys.  (Note: I
explicitly mention that AAA proxy does not cache the keys as well.
This might be related to the ongoing hokey discussion where KDC in the
visiting domain is going to be introduced.  Having said that, I think
that the KDC, which is expected to cache the keys, should be defined
outside the AAA layer.)

-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
Sent: Sunday, January 08, 2006 12:38 PM
To: eap [at] frascone.com
Subject: [eap] Proposed Resolution to Issue 323: AAA Key Cache

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