Subject: RE: [eap] Issue: section 2.1 AAA key caching

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 3 May 2006 11:06:04 -0700

With this particular text I wanted to make sure a key wasn't reused, ie
the TSKs are derived using some mechanism provides reasonable protection
from reuse.  Separation typically means that knowledge of one key does
not provide any knowledge of other keys.  I think in some circumstances
these two things are related, but I am not sure that one implies the
other.  In particular I don't think you need to have separation to
provide reuse.  I could also imagine schemes where you could provide
separation by segmenting the MSK, but the actual TSK selection allows
for reuse of TSK segments. 

It could be that I am missing some connection between the two, but it
seems they are different. 

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Tuesday, May 02, 2006 5:15 PM
> To: Salowey, Joe; [email-masked]
> Subject: RE: [eap] Issue: section 2.1 AAA key caching
> 
> At 04:46 PM 5/2/2006, Salowey, Joe wrote:
> >The intent is to make sure that if you are going to re-use 
> the MSK that
> >you should have some making sure that the keys you derive 
> from it will
> >not be re-used if you re-use the MSK,  for example incorporating  the
> >peer and authenticator nonce's in the TSK derivation in the SAP.
> >Perhaps the following would be better:
> >
> >"If the AAA layer does cache an MSK then the derivation of 
> TSKs derived
> >from the MSK MUST prevent key reuse. "
> 
> There is an extra derived there :-).  But, I guess then you are 
> talking about key separation between TSKs.  So, why not say that TSKs 
> derived from the MSK must be cryptographically separate from 
> each other.
> 
> Perhaps I am missing the point completely? :-).
> 
> regards,
> Lakshminath
> 
> 
> > > -----Original Message-----
> > > From: Lakshminath Dondeti [mailto:[email-masked]]
> > > Sent: Tuesday, May 02, 2006 2:50 PM
> > > To: Salowey, Joe; [email-masked]
> > > Subject: Re: [eap] Issue: section 2.1 AAA key caching
> > >
> > > Hi Joe,
> > >
> > > I don't understand the last sentence: "If the AAA layer 
> does cache an
> > > MSK then the use of TSKs derived from the MSK MUST prevent
> > > key reuse. "
> > >
> > > The rest of the text looks good and covers the robustness
> > > considerations you bring up.
> > >
> > > regards,
> > > Lakshminath
> > >
> > > At 02:25 PM 5/2/2006, Salowey, Joe wrote:
> > > >Submitter name: Joe Salowey
> > > >Submitter email address: [email-masked]
> > > >Date first submitted: 05/02/06
> > > >Reference:
> > > >Document: Keying Framework
> > > >Comment type:  T
> > > >Priority:  2
> > > >Section: 2.1
> > > >Rationale/Explanation of issue:
> > > >
> > > >The Current draft states that keys may not be cached once
> > > transported. I
> > > >am wondering if this is too restrictive.  Perhaps keys 
> will be cached
> > > >for session recovery and availability purposes.
> > > >
> > > >Suggested Text:
> > > >
> > > >  "In order to avoid key reuse, the AAA layer SHOULD delete
> > > transported
> > > >   keys once they are sent.  The AAA layer SHOULD NOT retain
> > > keys that
> > > >   it has previously sent.  For example, a AAA layer that has
> > > >   transported the MSK SHOULD delete it.  If the AAA layer
> > > does cache an
> > > >MSK
> > > >   then the use of TSKs derived from the MSK MUST prevent
> > > key reuse. "
> > > >
> > > >_________________________________________________________________
> > > >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: Lakshminath Dondeti <[email-masked]>
Date: Wed, 03 May 2006 11:06:15 -0700

>for reuse of TSK segments.

So even if TSKs are segments of the MSK keying material, the 
cryptographic separation property holds, no?  Speaking very loosely, 
if IKEv2 PRF+ is used to generate the MSK, and if we further assume 
that each TSK is equivalent to or a portion of the values T1, T2 
etc., given T1, it is computationally infeasible to compute say T2 or 
any other of Ti, 1< i < 255.

regards,
Lakshminath