At 11:29 AM 5/3/2006, Salowey, Joe wrote:
>
>
> > -----Original Message-----
> > From: Lakshminath Dondeti [mailto:ldondeti qualcomm.com]
> > Sent: Wednesday, May 03, 2006 11:06 AM
> > To: Salowey, Joe; eapfrascone.com
> > Subject: RE: [eap] Issue: section 2.1 AAA key
caching
> >
> > 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.
> >
>
>[Joe] yes, but my point is that separation does not
prevent reuse. You
>can have separate keys and if you don't take reuse into
account in the
>design of your lower layer protocol then you will have a
reuse problem.
>One example is allowing a counter to wrap or reset under
certain
>conditions.
So then you are saying that the TSKs must be
cryptographically
separate from each other and that they must not be reused.
(I would
have thought it's automatic, but clarification is fine with
me).
regards,
Lakshminath
> > 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: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
|