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: Thursday, January 19, 2006 11:02 AM
To: Nakhjiri Madjid-MNAKHJI1; Bernard Aboba; eap [at] frascone.com
Subject: RE: [eap] Proposed Resolution to Issue 323: AAA Key Cache

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


Madjid2>>In the PMIP example, the MN does not need to have access to the
PMIP-key. It is to be shared between the PMN and HA. And yes, the way we
envisioning it, only one PMN is to hold the key (you may want to call
that anchoring).
Please see, 
http://www.ietf.org/internet-drafts/draft-nakhjiri-pmip-key-01.txt

For more info.

> [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>>not without unnecessary additional steps. You still need to send
the same key to two different places, regardless of how many levels of
hierarchy you generate, unless you say, 
I have to generate a parent-key (Kp) and child-key (Kc) and use Kc for
my application (say PMIP). To comply with deleting the transported key,
you will derive Kc from Kp and send the Kc over to one agent, you must
delete Kc now, then you send Kp to another agent and make sure the
second agent knows _EXACTLY_ how to generate Kc from Kp and at the end,
agent1 and agent 2 can share Kc.
All this seems to be very unnecessary, just because we require
transported key to be deleted.

Madjid