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

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Nov 2006 15:35:39 -0500

On Fri, Nov 17, 2006 at 03:15:46PM -0500, Blumenthal, Uri wrote:

(snip)

> Let's dispense with flawed analogies and stick to the point. Which is:
> the WG decided that the way EAP evolves it needs two cryptographically
> indpendent "generator keys" MSK and EMSK, with usage model for the 2nd
> one still being considered. It is obvious however that it is much better
> to have a key and not need to use it than the other way around - having
> a need for a cryptographically independent key and not having a source
> for it.

Agreed.

Yoshihiro Ohba

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 17 Nov 2006 15:15:46 -0500

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

Not it does not make sense. To me it's like saying you must make your
house doors such that they accept two locks, even though now people
either put no lock at all or are satisfied with just one.

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-masked]
> http://www.opendiameter.org/mailman/listinfo/hokeyp
> 

.com>
From: "Blumenthal, Uri" <[email-masked]>
To: "Yoshihiro Ohba" <[email-masked]>
Cc: [email-masked], [email-masked]

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

Not it does not make sense. To me it's like saying you must make your
house doors such that they accept two locks, even though now people
either put no lock at all or are satisfied with just one.

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-masked]
> http://www.opendiameter.org/mailman/listinfo/hokeyp
>