>
> Speaking very loosely and at a high level, we say that
MSK is
> sent to the Authenticator and then TSKs are derived
using
> various protocols and go on to talk about TSK
properties.
> Likewise, we are talking
> about EMSK "usage" in the EAP keying FW
document.
But, the document does not talk about EMSK usage though.
> We say a bunch of
> things, all of which I am ok with and that the EMSK
MUST NOT
> be used to derive keys, which I am not ok with. There
are
> proposals to change that, so we might start revising
that
> statement to avoid having two RFCs in conflict with
each other.
>
Good point - we have a discussion from a while back on
removing this
text about not using EMSK to derive other keys, but seems
like we never
closed the loop on that one. Given that we pretty much have
a consensus
that EMSK will be used for key derivation, this text
doesn't make sense.
> Once that is done, talking about derived key properties
is ok.
>
This doesn't make sense to me still. What properties of
derived keys are
we going to talk about here? Just lifetime? Why not other
properties
then?
If at all this document should talk about any lifetimes, it
must be the
EMSK lifetime itself (assuming caching of EMSK is allowed,
on which
there has been a recent reversal in thinking from the
earlier notion of
no caching) - this is not addressed in the document and it
would make
sense to address this.
Regards,
Vidya
> Iff that is not done, sure I agree with you (if we MUST
NOT
> derive keys, what's the point in talking about the
properties
> of the derived keys?). But, I contend that that rule
needs
> to be revised.
>
> regards,
> Lakshminath
>
> At 08:05 PM 5/3/2006, Narayanan, Vidya wrote:
> >Hmmm..
> >
> >I gave this some more thought and am still not
convinced we need to
> >include this text here. The document talks about
TSKs and their
> >lifetimes, because the TSKs are derived from the
MSKs and
> the MSK usage
> >is fully covered by this document. However, it
makes sense
> to me that
> >the EMSK usage document be the one that defines the
lifetime
> guidelines
> >for the keys derived from the EMSK.
> >
> >While we are explicitly excluding any EMSK usage
text from this
> >document, why should this document cover lifetime
guidelines
> for child
> >keys of EMSK? All the rest of the child key
properties
> aren't covered
> >here - isn't lifetime a property too?
> >
> >Regards,
> >Vidya
> >
> >
> > > -----Original Message-----
> > > From: Lakshminath Dondeti
[mailto:ldondeti qualcomm.com]
> > > Sent: Tuesday, May 02, 2006 6:34 PM
> > > To: Narayanan, Vidya; Bernard Aboba; eapfrascone.com
> > > Subject: RE: [eap] Re: issue 361: child key
expiry
> > >
> > > Hi Vidya,
> > >
> > > After having thought about this some more, I
think we should have
> > > some text on EMSK to child key derivation in
the
> EAP-keying document
> > > along the lines of the 4 items listed
earlier. This is
> inline with
> > > the text on TSKs in 3.1(e) and perhaps
elsewhere in the document.
> > >
> > > regards,
> > > Lakshminath
> > >
> > > At 03:08 PM 5/2/2006, Narayanan, Vidya wrote:
> > > >Bernard, Lakshminath,
> > > >While this is an interesting discussion,
I feel that the
> > > EMSK specifics
> > > >with respect to caching and lifetime as
well as child key
> > > >properties need to be discussed in the
EMSK usage
> document. We can
> > > continue having
> > > >this discussion in light of the EMSK
usage document.
> > > >
> > > >For the purpose of EAP keying document,
can we not add that
> > > >sentence about a future EMSK usage
document and leave it at that?
> > > >
> > > >However, if there are things that need to
be clarified here with
> > > >respect to the MSK, we should certainly
do that in this document.
> > > >
> > > >Thanks,
> > > >Vidya
> > > >
> > > > > -----Original Message-----
> > > > > From: Bernard Aboba
[mailto:bernard_abobahotmail.com]
> > > > > Sent: Tuesday, May 02, 2006 12:19
PM
> > > > > To: Dondeti, Lakshminath; eapfrascone.com
> > > > > Subject: Re: [eap] Re: issue 361:
child key expiry
> > > > >
> > > > > >I wasn't thinking about PANA,
but thinking about the use
> > > > > case of client
> > > > > >authentication in IPsec remote
access using EAP.
> > > Whereas EAP can
> > > > > >be used every time, it is
plausible that the MSK is
> > > cached as the
> > > > > >IKEv2 Preshared key for future
authentication to avoid
> > > EAP latency.
> > > > >
> > > > > Perhaps we can say that RFC 4306
does not support key
> > > caching? It
> > > > > seems that an extension to IKEv2
would be required to
> > > support this,
> > > > > since otherwise the IKE initiator
and responder couldn't
> > > negotiate
> > > > > whether cached EAP keys are to be
used, and if so, which ones.
> > > > >
> > > > > >>Are you suggesting that
there might be situations
> in which EAP
> > > > > >>keys aren't used for key
derivation, but compromise might
> > > > > >>still
> > > > > be possible?
> > > > > >
> > > > > >No. I am asking if the
MSK/EMSK figures into the key
> > > > > derivation, say
> > > > > >only partially (say along with
DH), compromise of MSK/EMSK
> > > > > >means compromise of derived
keys. I was then saying perhaps
> > > that is too
> > > > > >restrictive, but I'd contend
not, unless there is a strong
> > > > > case made for the alternative.
> > > > >
> > > > > OK. If the MSK/EMSK were mixed
into the key derivation,
> > > then there
> > > > > might be some weakening of the key
derivation. How much
> > > depends on
> > > > > the algorithm.
> > > > >
> > > > > >If that's confusing too,
please let me know.
> > > > >
> > > > > I understand the point.... question
is how we make it
> > > clear in the
> > > > > text.
> > > > >
> > > > > >>Right. And by the same
logic, the MSK and EMSK
> might expire
> > > > > >>at different times. I'm
not sure that the key lifetime
> > > section takes
> > > > > >>that into account
adequately.
> > > > > >
> > > > > >That sounds right and the
clarification will be good.
> > > > >
> > > > > Suggestions welcome.
> > > > >
> > > > > >>This makes sense assuming
that the entity
> authentiation keys
> > > > > >>aren't themselves derived
from the EMSK.
> > > > > >
> > > > > >Even if entity authentication
keys are derived from the
> > > EMSK, the
> > > > > >guideline applies, I think.
Suppose the EMSK supports
> > > > > derivation of a
> > > > > >traffic key and a separate
entity authentication key,
> > > > > wouldn't it make
> > > > > >sense to say that, all other
things being equal, the traffic
> > > > > key will
> > > > > >have a shorter lifetime than
the entity authentication key,
> > > > > based on key usage?
> > > > >
> > > > > Yes, it would make sense. I guess
I'd distinguish between a
> > > > > key calculated
> > > > > from the EMSK (e.g. AMSK) and a
TSK. The AMSK formulas that
> > > > > have been suggested so far are
static -- that is,
> they are based
> > > > > on a key-label, but do not generate
a fresh key every
> time they
> > > > > are invoked on the same EMSK, in
the way that some TSK
> > > > > derivations do (e.g. 802.11i 4-way
handshake).
> > > > >
> > > > > Unless there is an ability to
generate fresh keys
> without an EAP
> > > > > re-authentication, then when the
derived keyexpires it is
> > > necessary
> > > > > to do an EAP re-authentication.
With TSKs it may be
> > > possible to do
> > > > > a re-key independent of EAP (e.g.
802.11i 4-way handshake).
> > > > >
> > > > >
> > > > >
>
____________________________________________________________
____
> > > > > _ 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
|