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 18, 2006 10:51 AM
> To: Salowey, Joe; Bernard Aboba; eap [at] frascone.com
> Subject: RE: [eap] Proposed Resolution to Issue 323: AAA Key Cache
> 
> 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.
> 

[Joe] Ok, it seems this key would be different than the mobile nodes key
and that the PMNs don't all ned to share the same key. 

> > 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.
> 
[Joe] yes, you need to hold onto the key, but instead of transporting
the "cached" key you transport keys derived from the cached key.  Does
this meet the requirements of your 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
>