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

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Thu, 16 Nov 2006 12:55:55 -0500

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:[email-masked]] 
> Sent: Thursday, November 16, 2006 12:38 PM
> To: Yoshihiro Ohba; Alper Yegin
> Cc: [email-masked]; [email-masked]
> 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
> > > [email-masked]
> > > http://www.opendiameter.org/mailman/listinfo/hokeyp
> > >
> >
> >_______________________________________________
> >Emu mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/emu
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/emu
> 

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Charles Clancy <[email-masked]>
Date: Thu, 16 Nov 2006 13:07:48 -0500

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.  |  [email-masked]  |  www.cs.umd.edu/~clancy