Hi Yoshi, Sorry for the very late response. I think the issue was whether methods generate EMSK or not, there was not a discussion of usage. Now, some method do generate EMSK and some don't. The same way that some EAP method did one-way authentication and some did mutual authentication.
It is the job of the security engineer to pick the right EAP method, more clearly, if he/she needs EMSK and the method does not give it, he/she picks something else, there is no rocket science here. R, Madjid -----Original Message----- From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] Sent: Sunday, November 19, 2006 5:36 AM To: Madjid Nakhjiri Cc: 'Yoshihiro Ohba'; 'Blumenthal, Uri'; [EMAIL PROTECTED]; [email protected] Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Hi Madjid, The problem we are facing with EMSK is that the key and its usage were not defined *at one time". For this reason, I don't agree with mandating the use of EMSK for all implementations. Only making use of EMSK optional makes sense to me, regardless of how it is going to be used. 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
