I don't understand why was a unused key defined in advance ? Michael
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Yoshihiro Ohba > Sent: Friday, November 17, 2006 6:57 AM > To: Lakshminath Dondeti > Cc: Yoshihiro Ohba; Alper Yegin; [EMAIL PROTECTED]; [email protected] > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > On Thu, Nov 16, 2006 at 10:54:20AM -0800, Lakshminath Dondeti wrote: > > At 10:30 AM 11/16/2006, Yoshihiro Ohba wrote: > > >Hi Lakshminath, > > > > > >RFC 3748 says: > > > > > >" > > > Extended Master Session Key (EMSK) > > > Additional keying material derived between the EAP client and > > > server that is exported by the EAP method. The EMSK > is at least > > > 64 octets in length. The EMSK is not shared with the > > > authenticator or any other third party. The EMSK is > reserved for > > > future uses that are not defined yet. > > >" > > > > > >Since EMSK usage is not defined yet, the use of EMSK is virtually > > >optional at this momement. Since it was not mandated in the > > >beginning, it is not possible to change it mandatory for a > particular > > >use in a future without loss of interoperability with the existing > > >deployment. > > > > I read it differently. The EMSK is reserved for future > uses. It is > > of course mandatory to derive the EMSK, but the use of it is simply > > not defined. It is not optional to use. It is not > mandatory either, > > it simply is unused. When the EMSK is defined for a specific use > > case, then the question of whether the use is optional, > recommended or > > mandatory comes up. > > I agree that this is more precise reading. However, even > after defining a usage of EMSK, it is difficult to assume > that all peers and servers will always support the usage of > EMSK unless we can upgrade the existing EAP implementations > which do not use EMSK to the new ones *at one time*. Thus, > as a proactive answer to the question, I don't really believe > that a specific use of EMSK can be mandated without breaking > interoperability with existing EAP implementations. > > Yoshihiro Ohba > > > > > > Lakshminath > > > > > > >Am I missing something? > > > > > >Yoshihiro Ohba > > > > > > > > >On Thu, Nov 16, 2006 at 09:38:10AM -0800, Lakshminath > Dondeti wrote: > > >> 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 PROTECTED] > > >> > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > >> > > > > >> > > > >> >_______________________________________________ > > >> >Emu mailing list > > >> >[email protected] > > >> >https://www1.ietf.org/mailman/listinfo/emu > > >> > > >> _______________________________________________ > > >> Hokeyp mailing list > > >> [EMAIL PROTECTED] > > >> http://www.opendiameter.org/mailman/listinfo/hokeyp > > >> > > >_______________________________________________ > > >Hokeyp mailing list > > >[EMAIL PROTECTED] > > >http://www.opendiameter.org/mailman/listinfo/hokeyp > > > > > _______________________________________________ > Hokeyp mailing list > [EMAIL PROTECTED] > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
