RE: [Hokeyp] [Emu] Re: MSK but no EMSK
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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:yohba at tari.toshiba.com] 
Sent: Friday, November 17, 2006 11:36 AM
To: Blumenthal, Uri
Cc: hokeyp at opendiameter.org; emu at ietf.org
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
> 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



_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.