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

["Kroeselberg, Dirk" <dirk.kroeselberg at siemens.com>]

Hi all, 

the hokey charter under 3) seems to be clearly based on the current RFC 3748 text (mandating EMSK generation). So one effort is to think about the hierarchy below EMSK (and not whether EMSK is there at all), take into account existing uses of EMSK etc., right?
Possibly, another effort may focus on 'legacy methods' not (or not fully) describing EMSK generation (i.e. not compliant to 3748).

The remainder are implementations that - although the method spec specifies how EMSK generation happens - do not implement this. I would expect this to be out-of-scope for standardization.

Dirk

-----Ursprüngliche Nachricht-----
Von: hokeyp-bounces at opendiameter.org [mailto:hokeyp-bounces at opendiameter.org] Im Auftrag von Michael Ye
Gesendet: Freitag, 17. November 2006 04:45
An: 'Blumenthal, Uri'; hokeyp at opendiameter.org; emu at ietf.org
Betreff: Re: [Hokeyp] [Emu] Re: MSK but no EMSK


The discussion focuses on the problem EMSK is optional or mandatory.
RFC3578 defined EMSK is mandatory, but it is not used at all.  If EMSK must
be used, it is mandatory . if no, I think, it may be better that it is
optional. If EMSK is necessary for some "applications" in the future,  we
may still use it by option. If RFC3578 don't be taken into account , I
prefer to that it is optional.

Michael

  

> -----Original Message-----
> From: hokeyp-bounces at opendiameter.org 
> [mailto:hokeyp-bounces at opendiameter.org] On Behalf Of Blumenthal, Uri
> Sent: Friday, November 17, 2006 10:58 AM
> To: hokeyp at opendiameter.orgFrom emu-bounces at ietf.org Sat Nov 18 18:26:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GlZZB-0001In-LW; Sat, 18 Nov 2006 18:25:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkyvd-0003nC-TC
	for emu at ietf.org; Fri, 17 Nov 2006 03:18:29 -0500
Received: from gecko.sbs.de ([194.138.37.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkyvX-0003nk-B4
	for emu at ietf.org; Fri, 17 Nov 2006 03:18:29 -0500
Received: from mail2.sbs.de (localhost [127.0.0.1])
	by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kAH8IBJW028999;
	Fri, 17 Nov 2006 09:18:12 +0100
Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net
	[157.163.133.201])
	by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id kAH8I7OX006907;
	Fri, 17 Nov 2006 09:18:10 +0100
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by
	fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830);
	Fri, 17 Nov 2006 09:18:07 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: [Hokeyp] [Emu] Re: MSK but no EMSK
Date: Fri, 17 Nov 2006 09:18:06 +0100
Message-ID: <098B8E8384157645B6025978DB7EF75501867B6E at MCHP7IEA.ww002.siemens.net>
In-Reply-To: <001101c709fa$b226cdf0$4005a40a at china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK
Thread-Index: AccJzklxPwF5M9khTom054JMBfhApwAFuvawAAOTFmAAAIoXQAAKTX8g
From: "Kroeselberg, Dirk" <dirk.kroeselberg at siemens.com>
To: "Michael Ye" <yechengping at huawei.com>,
	"Blumenthal, Uri" <uri.blumenthal at intel.com>, <hokeyp at opendiameter.org>,
	<emu at ietf.org>
X-OriginalArrivalTime: 17 Nov 2006 08:18:07.0550 (UTC)
	FILETIME=[E97775E0:01C70A20]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500
Cc:
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

Hi all, 

the hokey charter under 3) seems to be clearly based on the current RFC 3748 text (mandating EMSK generation). So one effort is to think about the hierarchy below EMSK (and not whether EMSK is there at all), take into account existing uses of EMSK etc., right?
Possibly, another effort may focus on 'legacy methods' not (or not fully) describing EMSK generation (i.e. not compliant to 3748).

The remainder are implementations that - although the method spec specifies how EMSK generation happens - do not implement this. I would expect this to be out-of-scope for standardization.

Dirk

-----Ursprüngliche Nachricht-----
Von: hokeyp-bounces at opendiameter.org [mailto:hokeyp-bounces at opendiameter.org] Im Auftrag von Michael Ye
Gesendet: Freitag, 17. November 2006 04:45
An: 'Blumenthal, Uri'; hokeyp at opendiameter.org; emu at ietf.org
Betreff: Re: [Hokeyp] [Emu] Re: MSK but no EMSK


The discussion focuses on the problem EMSK is optional or mandatory.
RFC3578 defined EMSK is mandatory, but it is not used at all.  If EMSK must
be used, it is mandatory . if no, I think, it may be better that it is
optional. If EMSK is necessary for some "applications" in the future,  we
may still use it by option. If RFC3578 don't be taken into account , I
prefer to that it is optional.

Michael

  

> -----Original Message-----
> From: hokeyp-bounces at opendiameter.org 
> [mailto:hokeyp-bounces at opendiameter.org] On Behalf Of Blumenthal, Uri
> Sent: Friday, November 17, 2006 10:58 AM
> To: hokeyp at opendiameter.org; emu at ietf.org
> Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK
> 
> I happen to agree with Vidya on this.
> 
> It is not optional for new EAP methods to produce EMSK. 
> Whether EMSK gets used or not is totally besides the point.  
> (If we can conceive that EMSK would serve a need in some 
> distant future - we have to enforce its generation now. And 
> it is required by RFC 3748 :-)
> 
> What to do with the existing _old_ methods that aren't 
> compliant - I leave it for the group to decide.
> 
> -----Original Message-----
> From: hokeyp-bounces at opendiameter.org
> [mailto:hokeyp-bounces at opendiameter.org] On Behalf Of Narayanan, Vidya
> Sent: Thursday, November 16, 2006 9:35 PM
> To: Bernard Aboba; hokeyp at opendiameter.org; emu at ietf.org
> Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK
> 
> > 
> > It's worth keeping in mind that there are very few existing RFC 
> > 3748-compliant EAP implementations.  So most existing EAP method 
> > implementations do not generate an EMSK, and most existing EAP 
> > implementations would not do anything with the EMSK if it 
> were to be 
> > generated.
> > 
> 
> Well, the question is this - is the requirement to 
> interoperate with existing standards or existing 
> implementations? Given that we have a spec that says what it 
> does, it seems to make sense to interoperate with that. If we 
> are going by existing implementations, there is probably more 
> than one flavor and then there is the question of when the 
> MSK is directly delivered to the authenticator and when it 
> isn't and how the peer knows that. 
> 
> In this case, I tend to agree with Charles that it is better 
> to have to fix non-compliant implementations than try to 
> design around them. Also, if we choose to ignore the standard 
> and use the implementations that don't produce an EMSK as a 
> data point, the standard doesn't seem to be serving a purpose 
> then - perhaps, we should then consider revising
> RFC3748 to reflect what we want to use as a starting point 
> for requirements? 
> 
> Vidya
> _______________________________________________
> Hokeyp mailing list
> Hokeyp at opendiameter.org
> http://www.opendiameter.org/mailman/listinfo/hokeyp
> _______________________________________________
> Hokeyp mailing list
> Hokeyp at opendiameter.org
> http://www.opendiameter.org/mailman/listinfo/hokeyp
> 


_______________________________________________
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