Subject: RE: [eap] Re: issue 361: child key expiry

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 4 May 2006 01:29:45 -0700

> 
> 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:[email-masked]]
> > > Sent: Tuesday, May 02, 2006 6:34 PM
> > > To: Narayanan, Vidya; Bernard Aboba; [email-masked]
> > > 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:[email-masked]]
> > > > > Sent: Tuesday, May 02, 2006 12:19 PM
> > > > > To: Dondeti, Lakshminath; [email-masked]
> > > > > 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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 04 May 2006 01:36:31 -0700

Two things then:

First we need a clarification on what the EAP keying FW is going to 
say about EMSKs.  If it says EMSK usage is specified elsewhere (and 
deletes the EMSK MUST not be used for key derivation, for 
consistency), then you are indeed correct.  The EAP keying FW should 
stick to MSK and TSK lifetime discussion, which it does at length, 
and not talk about EMSK child keys (intuitively, if it doesn't 
describe EMSK usage, then properties of child keys do not belong in 
the EAP keying FW document).

If the document is to add a few notes on EMSK usage, then perhaps 
providing guidelines on child keys, freshness and other 
considerations do belong in it.

Can we agree to that and explore which of the above two might make sense?

Finally, apologies for side tracking your issue.  I think there was 
some confusion along the way and I am partly responsible for that.

regards,
Lakshminath