At 11:06 AM 5/3/2006, Salowey, Joe wrote:
>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.
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
>It could be that I am missing some connection between
the two, but it
>seems they are different.
>
> > -----Original Message-----
> > From: Lakshminath Dondeti [mailto:ldondeti qualcomm.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
|