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

["Blumenthal, Uri" <uri.blumenthal at intel.com>]

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

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.




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





.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK
thread-index: AccKf75AK/U4IpvfSQiyB6o0NwUwrgABGVgQ
From: "Blumenthal, Uri" <uri.blumenthal at intel.com>
To: "Yoshihiro Ohba" <yohba at tari.toshiba.com>
X-OriginalArrivalTime: 17 Nov 2006 20:15:54.0439 (UTC)
	FILETIME=[2F553570:01C70A85]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500
Cc: hokeyp at opendiameter.org, emu at ietf.org
X-BeenThere: emu at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/emu>,
	<mailto:emu-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/emu>
List-Post: <mailto:emu at ietf.org>
List-Help: <mailto:emu-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/emu>,
	<mailto:emu-request at ietf.org?subject=subscribe>
Errors-To: emu-bounces at ietf.org

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

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.




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