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

[Michael Ye <yechengping at huawei.com>]

The discussion focuses on the problem EMSK is optional or mandatory.
RFC3578 defined EMSK is mandatory, but it is not used at all.  If EMSK must
be used, it is mandatory . if no, I think, it may be better that it is
optional. If EMSK is necessary for some "applications" in the future,  we
may still use it by option. If RFC3578 don't be taken into account , I
prefer to that it is optional.

Michael

  

> -----Original Message-----
> From: hokeyp-bounces at opendiameter.org 
> [mailto:hokeyp-bounces at opendiameter.org] On Behalf Of Blumenthal, Uri
> Sent: Friday, November 17, 2006 10:58 AM
> To: hokeyp at opendiameter.org; emu at ietf.org
> Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK
> 
> I happen to agree with Vidya on this.
> 
> It is not optional for new EAP methods to produce EMSK. 
> Whether EMSK gets used or not is totally besides the point.  
> (If we can conceive that EMSK would serve a need in some 
> distant future - we have to enforce its generation now. And 
> it is required by RFC 3748 :-)
> 
> What to do with the existing _old_ methods that aren't 
> compliant - I leave it for the group to decide.
> 
> -----Original Message-----
> From: hokeyp-bounces at opendiameter.org
> [mailto:hokeyp-bounces at opendiameter.org] On Behalf Of Narayanan, Vidya
> Sent: Thursday, November 16, 2006 9:35 PM
> To: Bernard Aboba; hokeyp at opendiameter.org; emu at ietf.org
> Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK
> 
> > 
> > It's worth keeping in mind that there are very few existing RFC 
> > 3748-compliant EAP implementations.  So mribe>
Errors-To: emu-bounces at ietf.org


I don't understand why was a unused key defined in advance ?

  Michael

> -----Original Message-----
> From: hokeyp-bounces at opendiameter.org 
> [mailto:hokeyp-bounces at opendiameter.org] On Behalf Of Yoshihiro Ohba
> Sent: Friday, November 17, 2006 6:57 AM
> To: Lakshminath Dondeti
> Cc: Yoshihiro Ohba; Alper Yegin; hokeyp at opendiameter.org; emu at ietf.org
> 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
> > >> > > Hokeyp at opendiameter.org
> > >> > > http://www.opendiameter.org/mailman/listinfo/hokeyp
> > >> > >
> > >> >
> > >> >_______________________________________________
> > >> >Emu mailing list
> > >> >Emu at ietf.org
> > >> >https://www1.ietf.org/mailman/ost existing EAP method 
> > implementations do not generate an EMSK, and most existing EAP 
> > implementations would not do anything with the EMSK if it 
> were to be 
> > generated.
> > 
> 
> Well, the question is this - is the requirement to 
> interoperate with existing standards or existing 
> implementations? Given that we have a spec that says what it 
> does, it seems to make sense to interoperate with that. If we 
> are going by existing implementations, there is probably more 
> than one flavor and then there is the question of when the 
> MSK is directly delivered to the authenticator and when it 
> isn't and how the peer knows that. 
> 
> In this case, I tend to agree with Charles that it is better 
> to have to fix non-compliant implementations than try to 
> design around them. Also, if we choose to ignore the standard 
> and use the implementations that don't produce an EMSK as a 
> data point, the standard doesn't seem to be serving a purpose 
> then - perhaps, we should then consider revising
> RFC3748 to reflect what we want to use as a starting point 
> for requirements? 
> 
> Vidya
> _______________________________________________
> Hokeyp mailing list
> Hokeyp at opendiameter.org
> http://www.opendiameter.org/mailman/listinfo/hokeyp
> _______________________________________________
> 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