eap Mailing List: RE: Re: issue 361: child key expiry

[Lakshminath Dondeti (ldondeti]

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.   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.

Once that is done, talking about derived key properties is ok.

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 [at] qualcomm.com]
> > Sent: Tuesday, May 02, 2006 6:34 PM
> > To: Narayanan, Vidya; Bernard Aboba; eap [at] frascone.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_aboba [at] hotmail.com]
> > > > Sent: Tuesday, May 02, 2006 12:19 PM
> > > > To: Dondeti, Lakshminath; eap [at] frascone.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
> > > >
> >
> >