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 > > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
