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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi Joe,  

-----Original Message-----
From: Salowey, Joe [mailto:jsalowey [at] cisco.com] 
Sent: Sunday, January 15, 2006 9:22 PM
To: Nakhjiri Madjid-MNAKHJI1; Bernard Aboba; eap [at] frascone.com
Subject: RE: [eap] Proposed Resolution to Issue 323: AAA Key Cache
> 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.
> 

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

> Is there anywhere in the AAA key management requirement that says AAA
> 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.

> 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.
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

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