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

From: "Salowey, Joe" <[email-masked]>
Date: Sun, 15 Jan 2006 19:22:03 -0800

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Wednesday, January 11, 2006 8:56 AM
> To: Bernard Aboba; [email-masked]
> 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:[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.
> 
> 
> _________________________________________________________________
> 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

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 16 Jan 2006 18:46:25 -0800

[BA] I don't know why that would be necessary or desirable.  

[BA] That sounds reasonable.  Do you have some text to suggest?
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap