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

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 5 May 2006 20:08:25 -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).
> 

The above would be my preference. 

Regards,
Vidya

> 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
> 
> At 01:29 AM 5/4/2006, Narayanan, Vidya wrote:
> 
> > >
> > > 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: Jari Arkko <[email-masked]>
Date: Mon, 08 May 2006 16:59:20 +0300

Re: caching of MSKs by IKEv2. I agree with Bernard that
this seems to go beyond what current RFCs say, and I also
suspect that there are issues that we'd like to understand
before such usage could be allowed. For instance, if my AAA
server gives you an MSK to use for IKEv2 login, letting you
use that key multiple times would create interesting
interactions with concurrent session tracking.

Re: EMSK lifetime spec. I don't see a fundamental problem
in specifying some general characteristics of the entire
key hierarchy in the keying framework doc, even if we
should develop some specific parts of the hierarchy in
some other documents. Personally, the current lifetime
text is appealing mainly because its so simple -- all derived
keys should expire latest when the exported material
expires. This is also good for cache management.

--Jari

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 08 May 2006 09:36:18 -0700

>interactions with concurrent session tracking.

Sure, but I'd argue that this may be a case of 'perfect' being the 
enemy of the 'good.'  Absent potentially strong keymat that might 
come from say an EAP exchange, PSK provisioning procedures 
(proprietary) might be all over the place, some result in strong keys 
and others not so strong keys!  I do understand that this issue might 
be out of scope for this draft and so might be addressed elsewhere.

>expires. This is also good for cache management.

That's true unless derived keys are passed to other entities.  If the 
exported keymat expires due to another EAP authentication, the server 
would have to contact all of those entities that received the derived 
keys and force key deletion.  It may be feasible in some cases and 
not in others.  It is also counter-intuitive if the keys are not 
compromised, and the EAP authentication was run due to policy changes 
that do not affect the derived key usage.

But, I can see how that can quickly get complex, but that kind of 
complexity seems to go hand-in-hand with EMSK usage.

regards,
Lakshminath

---

From: Jari Arkko <[email-masked]>
Date: Mon, 08 May 2006 20:15:08 +0300

Lakshminath Dondeti wrote:

> enemy of the 'good.'  Absent potentially strong keymat that might come
> from say an EAP exchange, PSK provisioning procedures (proprietary)
> might be all over the place, some result in strong keys and others not
> so strong keys!  I do understand that this issue might be out of scope
> for this draft and so might be addressed elsewhere.

Well, we do have the PSK provisioning process for the
IKEv2 if you assume there's an EAP credential that can
be used. Namely, EAP authentication in IKEv2 :-)

Of course, it has been in some cases argued that its
too slow and needs to be optimized. I'd be interested
in looking at data that says such optimizations are
needed -- given things like child SA creation,
MOBIKE or the "K" bit in Mobile IPv6, there's typically
no reason why the IKEv2 run needs to be rerun often.
In this area it would be useful to study whether
existing mechanisms are sufficient before we
create new ones.

Or are you thinking of semi-permanent PSK
provisioning? This may indeed need work. But
we should be able to do this in a different spec.

> keys and force key deletion.  It may be feasible in some cases and not
> in others.  It is also counter-intuitive if the keys are not

I agree, but I was thinking that the keymat expiration is
dependent on its lifetime, communicated/assumed when
its exported or transported. If expiration covers also re-
authentication then we may indeed have an issue.

--Jari