Re: [Emu] Re: [Hokeyp] MSK but no EMSK

[Charles Clancy <clancy at cs.umd.edu>]

Hao,

I think you meant to say it would require replacing all existing EAP 
*method* implementations.  EAP implementations will have to change 
anyway to support derivation of keys within the hierarchy.  If you're 
updating clients and servers already, rev-ing the method implementations 
to bring them up to spec seems like a reasonable thing to do. 
Engineering new standards around broken implementations of old standards 
seems like a bad set of design constraints.

--
t. charles clancy, ph.d.  |  tcc at umd.edu  |  www.cs.umd.edu/~clancy


Hao Zhou (hzhou) wrote:
> I pointed in the meeting that even EAP RFC mandates EMSK, however I
> don't know any existing EAP implementation actually generates and
> exports EMSK (especially the popular ones, like EAP-TLS, PEAP, EAP-FAST,
> EAP-TTLS, etc.) So if we build our key hierarchy on top of EMSK, we will
> require replacing all existing EAP implementations, both from the server
> and client side. If we cold use MSK, then we only need to replace EAP
> lower layer that wants to support handover.
>
> > -----Original Message-----
> > From: Lakshminath Dondeti [mailto:ldondeti at qualcomm.com] 
> > Sent: Thursday, November 16, 2006 12:38 PM
> > To: Yoshihiro Ohba; Alper Yegin
> > Cc: hokeyp at opendiameter.org; emu at ietf.org
> > Subject: Re: [Emu] Re: [Hokeyp] MSK but no EMSK
> >
> > At 06:27 AM 11/16/2006, Yoshihiro Ohba wrote:
> > > I made one comment around this in the HOKEY session.  The 
> > intent of my 
> > > comment was that use of EMSK is optional.
> > Hi Yoshi,
> >
> > Which document says that the "use" of EMSK is optional?
> >
> > > There would be an
> > > interoperability issue if peer and server do not negotiate 
> > on the use 
> > > of EMSK before actually using it.
> > The interoperability issue would only come up if there is 
> > ambiguity or options.
> >
> > Lakshminath
> >
> >
> > > Yoshihiro Ohba
> > >
> > >
> > > On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote:
> > > > I remember someone in Hokey WG meeting mentioned that not all 
> > > > methods generate EMSK (even though they generate MSK). Is 
> > that accurate?
> > > > Despite this RFC 3748 text?
> > > >
> > > >    In order to provide keying material for use in a
> > > >    subsequently negotiated ciphersuite, an EAP method 
> > supporting key
> > > >    derivation MUST export a Master Session Key (MSK) of 
> > at least 64
> > > >    octets, and an Extended Master Session Key (EMSK) of 
> > at least 64
> > > >    octets.
> > > >
> > > > Alper
> > > >
> > > >
> > > > _______________________________________________
> > > > Hokeyp mailing list
> > > > Hokeyp at opendiameter.org
> > > > http://www.opendiameter.org/mailman/listinfo/hokeyp
> > > _______________________________________________
> > > Emu mailing list
> > > Emu at ietf.org
> > > https://www1.ietf.org/mailman/listinfo/emu
> >
> > _______________________________________________
> > Emu mailing list
> > Emu at ietf.org
> > https://www1.ietf.org/mailman/listinfo/emu
>
> _______________________________________________
> Emu mailing list
> Emu at ietf.org
> https://www1.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu