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

[Salowey, Joe (jsalowey]

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri [at] motorola.com] 
> Sent: Wednesday, January 11, 2006 8:56 AM
> To: Bernard Aboba; eap [at] frascone.com
> Subject: RE: [eap] Proposed Resolution to Issue 323: AAA Key Cache
> 
> 
> 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. 
> 

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

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