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