On Wed, Nov 22, 2006 at 09:35:46AM -0800, Lakshminath Dondeti wrote: > At 03:46 AM 11/22/2006, Yoshihiro Ohba wrote: > >Hi Uri, > > > >On Wed, Nov 22, 2006 at 09:41:03AM -0500, Blumenthal, Uri wrote: > >> >The problem we are facing with EMSK is that the key and its usage were > >> >not defined *at one time". > >> > >> True, definition of EMSK has been done in advance, PRIOR to its usage - > >> so that by the time EMSK usage is defined, all the compliant methods > >> already have implemented EMSK generation and have it available. This is > >> not a problem. > >> > >> Especially since it is likely that most real-life implementations are > >> modular enough to allow component upgrades. > > > >For any method, how a compliant implementation and a non-compliant > >implementation can be distinguished? If they are indistinguishable, > >then there will be an interoperability problem. > > This is not rocket science! I have some second-hand experience with > IPsec interoperability; if implementation X does not interoperate > with implementation Y, people then figure out which one is > non-compliant and have that implementation fixed.
A HOKEY compliant implementation should be able to revert to the legacy mode of operation (i.e., use of MSK in the current way) so that it still interoperates with a HOKEY non-compliant implementation without ending up with a communication failure or changing the HOKEY non-compliant implementation. Note that a HOKEY non-compliant implementation is still RFC3748 compliant as long as it generates MSK and EMSK even if it does not use EMSK. > > > >For a future method that will be defined after we define an EMSK > >usage, I agree that we can definetly mandate use of EMSK. > > This is moot. EMSK derivation is already defined as mandatory. Are > you proposing something stronger than a MUST? "EMSK derivation is a MUST" does not mean that "use of EMSK is MUST". Yoshihiro Ohba > > Lakshminath > > >But > >ignoring the existing implementations does not make sense, considering > >the fact that some of them are already part of Wi-Fi certificate. > > > >Yoshihiro Ohba > > > > > >> > >> The problem is shortsightedness of some implementors, whose logic is "if > >> I don't need this feature NOW, no way I'll spend resources implementing > >> it". > >> > >> >For this reason, I don't agree with > >> >mandating the use of EMSK for all implementations. > >> > >> We cannot mandate what has not been defined yet. This is why we have > >> mandated only EMSK generation, not EMSK usage. > >> > >> Note the grammatic form of the verb: it IS a done deal, RFC 3578 IS a > >> standard. > >> > >> > Only making use of > >> >EMSK optional makes sense to me, regardless of how it is going to be > >> >used. > >> > >> There is no use of EMSK currently defined, neither optional nor > >> mandatory. So no need to make it anything. > >> > >> It is mandatory to generate EMSK and make it available for applications. > >> > >> How many times does is this dead horse going to be beaten? > >> > >> > >> Yoshihiro Ohba > >> > >> On Tue, Nov 21, 2006 at 08:50:46AM -0800, Madjid Nakhjiri wrote: > >> > Hi Yoshi, > >> > > >> > I don't quite agree with this. Defining the full functionality of a > >> new EAP > >> > method (including how it spits out MSK and EMSK) should be the job the > >> EAP > >> > method designer. 3748, EAP keying framework and hokey specs then > >> define how > >> > MSK or EMSK is used. This is modular design. People who use EMSK then > >> do not > >> > have to worry about the crypto behind EMSK generation. > >> > Using your analogy is "go buy the key and lock" but then wait to see > >> which > >> > door you want to install it on:) > >> > >> > I as a home owner do not need to know how to make locks. > >> > > >> > R, > >> > > >> > Madjid > >> > > >> > -----Original Message----- > >> > From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] > >> > Sent: Friday, November 17, 2006 11:36 AM > >> > To: Blumenthal, Uri > >> > Cc: [EMAIL PROTECTED]; [email protected] > >> > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > >> > > >> > Hi Uri, > >> > > >> > I have a different view. Mandating generation of EMSK without having > >> > defined its usage *when it was introduced* seems not much different > >> > from not having defining it at all. It looks like selling a key > >> > without a lock, make the lock later and say "You MUST use this key and > >> > lock for your car." Make sense?? > >> > > >> > Yoshihiro Ohba > >> > > >> > > >> > > >> > On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > >> > > >The discussion focuses on the problem EMSK is optional or > >> mandatory. > >> > > > >> > > I don't think this is a problem - GENERATION of EMSK is compulsoty > >> as > >> > > spelled out in RFC 3578. > >> > > > >> > > The problem is non-compliance. Some, er, people seem to think "the > >> > > standard says do A, but since I don't use A at the moment - I won't > >> > > bother." > >> > > > >> > > >RFC3578 defined EMSK is mandatory, > >> > > > >> > > And that should be the end of discussion. > >> > > > >> > > > but it is not used at all. > >> > > > >> > > First - do you know all the applications that use key-generating EAP > >> > > methods? But really - who cares? > >> > > > >> > > >If EMSK must be used, it is mandatory. if no, I think, > >> > > >it may be better that it is optional. > >> > > > >> > > VERY strongly disagree. Mandatory is what is explicitly specified as > >> > > mandatory, period. Otherwise many would implement just those pieces > >> and > >> > > features of the standard that his particular product needs today. > >> > > > >> > > (I'm proud of my restraint - not even once using a term "B*S*" :-) > >> > > _______________________________________________ > >> > > Hokeyp mailing list > >> > > [EMAIL PROTECTED] > >> > > http://www.opendiameter.org/mailman/listinfo/hokeyp > >> > > > >> > > >> > _______________________________________________ > >> > Emu mailing list > >> > [email protected] > >> > https://www1.ietf.org/mailman/listinfo/emu > >> > > >> > > >> > >> > > > >_______________________________________________ > >Emu mailing list > >[email protected] > >https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
