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

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

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

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





ov 2006 18:58:01 -0800
Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1])
	by fmsmga001.fm.intel.com with ESMTP; 16 Nov 2006 18:57:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: i="4.09,431,1157353200";
	d="scan'208"; a="165222249:sNHT32163817"
Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by
	fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830);
	Thu, 16 Nov 2006 18:57:57 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK
Date: Thu, 16 Nov 2006 21:57:45 -0500
Message-ID: <279DDDAFA85EC74C9300A0598E704056F91552 at hdsmsx412.amr.corp.intel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK
thread-index: AccJzklxPwF5M9khTom054JMBfhApwAFuvawAAOTFmAFrom: "Blumenthal, Uri" <uri.blumenthal at intel.com>
To: <hokeyp at opendiameter.org>,
	<emu at ietf.org>
X-OriginalArrivalTime: 17 Nov 2006 02:57:57.0463 (UTC)
	FILETIME=[2F5CCE70:01C709F4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
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

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

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