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.
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?
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
