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