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. For a future method that will be defined after we define an EMSK usage, I agree that we can definetly mandate use of EMSK. 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
