Issue: section 2.1 AAA key caching

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:ldondetiqualcomm.com] 
> Sent: Tuesday, May 02, 2006 5:15 PM
> To: Salowey, Joe; eapfrascone.com
> 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:ldondetiqualcomm.com]
> > > Sent: Tuesday, May 02, 2006 2:50 PM
> > > To: Salowey, Joe; eapfrascone.com
> > > 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: jsaloweycisco.com
> > > >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