From emu-bounces@ietf.org Sun Apr 01 23:23:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYD8J-0006hr-AW; Sun, 01 Apr 2007 23:23:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWuVB-0001fF-TK for emu@ietf.org; Thu, 29 Mar 2007 09:17:17 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWuVA-0001l8-1p for emu@ietf.org; Thu, 29 Mar 2007 09:17:17 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2TDGvEK027373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Mar 2007 15:16:58 +0200 X-Hashcash: 1:22:070329:password-auth@josefsson.org::a5VeuSPkiAAjYCie:GZzj From: Simon Josefsson To: Madjid Nakhjiri , emu@ietf.org References: <004d01c76122$9e512990$2f01a8c0@china.huawei.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070329:emu@ietf.org::VQVD05v6Qr0ANSug:88n X-Hashcash: 1:22:070329:mnakhjiri@huawei.com::xkWfAQnC2mtMfmRj:2kw Date: Thu, 29 Mar 2007 15:16:57 +0200 In-Reply-To: <004d01c76122$9e512990$2f01a8c0@china.huawei.com> (Madjid Nakhjiri's message of "Wed\, 07 Mar 2007 17\:39\:30 -0800") Message-ID: <87odmcp4ty.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Sun, 01 Apr 2007 23:22:58 -0400 Cc: password-auth@josefsson.org Subject: [Emu] Re: Looking for WG input: Password based method requirements X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi! I have not been following the EMU WG closely, but I noticed that you are working on password-based authentication. I'm gauging interest in an effort to do a password-based protocol that supports both GSS-API and SASL, see: http://www.ietf.org/internet-drafts/draft-josefsson-password-auth-00.txt http://yxa.extundo.com/pipermail/password-auth/2007-March/000000.html http://josefsson.org/password-auth/ One idea that occurred to me was to make this a triple GSS-API/SASL/EAP mechanism. I don't know whether it is feasible. Some of the requirements you mentioned may argue otherwise (e.g., supporting transmission of password). However, the document might change to accommodate new ideas. One thing that is required is someone with more EAP involvement than me to help make sure it works fine for EAP. Consider this a cross-WG fertilization plea. :) Comments appreciated, Simon _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 02 15:36:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSJm-0007Ci-Sj; Mon, 02 Apr 2007 15:35:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSJk-0007Ca-Ce for emu@ietf.org; Mon, 02 Apr 2007 15:35:52 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSJi-0005sr-VH for emu@ietf.org; Mon, 02 Apr 2007 15:35:52 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 12:35:50 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l32JZol5007964; Mon, 2 Apr 2007 12:35:50 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l32JZfAS006799; Mon, 2 Apr 2007 19:35:50 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 12:35:49 -0700 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: [Emu] Thoughts on Password-based EAP Methods Date: Mon, 2 Apr 2007 12:35:42 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Thoughts on Password-based EAP Methods Thread-Index: AcdwgbyDI98ve6UoRfCi/RnvnE2MHAE2mL2Q From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 02 Apr 2007 19:35:49.0639 (UTC) FILETIME=[1E23D970:01C7755E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2679; t=1175542550; x=1176406550; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20Thoughts=20on=20Password-based=20EAP=20Method s |Sender:=20; bh=2CzTpE8qZnDesVDIQEygwg8p7DBwWj60X6o5e534SdE=; b=aYOHJfOvHOWiNDYvHeiODfUJDgN9v6p40ojEMFiZ7fbRCD76JRLekyJW/dW/vCzjbOjG0sE/ d++/g3nALYEWzGqjZ7DuQvS+Hz/dE1nLjr+TiejRS7Q089MuEC6dljKP; Authentication-Results: sj-dkim-5; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I'm not sure that adding yet another version to TTLS specifically for supporting passwords will make things better for customers. Multiple versions certainly has caused quite a confusion in PEAP. =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, March 27, 2007 8:07 AM > To: emu@ietf.org > Subject: [Emu] Thoughts on Password-based EAP Methods >=20 > After listening to the IETF 68 presentation on a=20 > password-based EAP method, I would like to voice some concerns. >=20 > Today we already have an "over abundance" of such methods. =20 > These include=20 > PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my=20 > discussions=20 > with customers, I invariably hear complaints about this=20 > explosion, and about various interoperability and=20 > compatibility problems that it causes. Simply put, customers=20 > do not want "yet another password-based EAP method"; they=20 > want a single method that is widely implemented and interoperable. >=20 > I am concerned that by defining yet another password-based=20 > authentication=20 > mechanism, EMU WG will be making this problem worse, not=20 > better. Creating=20 > yet another mechanism which differs little from the existing=20 > ones also seems to have very little chance of being implemented. >=20 > There is a better alternative that EMU WG should consider.=20 > This is to choose an existing method for inclusion on the=20 > IETF Standards Track, rather than creating a new one. In=20 > order to maintain backward compatibility, this would require=20 > that the owners give up change control to the IETF. >=20 > I would suggest that the best candidate for this would be=20 > EAP-TTLSv0, since it is very widely implemented, and has an=20 > existing certification program in=20 > WFA. Also, EAP-TTLSv0 had previously been on the Standards=20 > Track in the=20 > PPPEXT WG, before work on EAP methods was removed from the=20 > PPPEXT WG charter and the EAP WG was formed. >=20 > In terms of steps to be taken, this would require the=20 > following actions: >=20 > a. Review and publication of the existing EAP-TTLSv0=20 > specification as an RFC. The goal here would be to document=20 > EAP-TTLSv0 as it exists today. >=20 > b. Agreement by the authors to give up change control to the IETF. >=20 > c. EMU WG efforts to publish an EAP-TTLSv0 "bis" document,=20 > specifying additional capabilities (such as Channel Bindings). >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 02 15:49:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSWb-0000gr-9G; Mon, 02 Apr 2007 15:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSWa-0000gm-CC for emu@ietf.org; Mon, 02 Apr 2007 15:49:08 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSWW-0008Gy-WF for emu@ietf.org; Mon, 02 Apr 2007 15:49:08 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 2 Apr 2007 12:49:04 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.25; Mon, 2 Apr 2007 12:49:04 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Mon, 2 Apr 2007 12:49:03 -0700 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: [Emu] Thoughts on Password-based EAP Methods Date: Mon, 2 Apr 2007 12:48:16 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004ADDE24@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Thoughts on Password-based EAP Methods Thread-Index: AcdwgbyDI98ve6UoRfCi/RnvnE2MHAE2mL2QAADg76A= References: From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , Bernard Aboba , X-OriginalArrivalTime: 02 Apr 2007 19:49:03.0883 (UTC) FILETIME=[F78BDDB0:01C7755F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I believe there were many issues with how PEAP progressed, if we are careful we could prevent the same things from happening with TTLS. Ryan -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Monday, April 02, 2007 12:36 PM To: Bernard Aboba; emu@ietf.org Subject: RE: [Emu] Thoughts on Password-based EAP Methods I'm not sure that adding yet another version to TTLS specifically for supporting passwords will make things better for customers. Multiple versions certainly has caused quite a confusion in PEAP. =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, March 27, 2007 8:07 AM > To: emu@ietf.org > Subject: [Emu] Thoughts on Password-based EAP Methods >=20 > After listening to the IETF 68 presentation on a=20 > password-based EAP method, I would like to voice some concerns. >=20 > Today we already have an "over abundance" of such methods. =20 > These include=20 > PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my=20 > discussions=20 > with customers, I invariably hear complaints about this=20 > explosion, and about various interoperability and=20 > compatibility problems that it causes. Simply put, customers=20 > do not want "yet another password-based EAP method"; they=20 > want a single method that is widely implemented and interoperable. >=20 > I am concerned that by defining yet another password-based=20 > authentication=20 > mechanism, EMU WG will be making this problem worse, not=20 > better. Creating=20 > yet another mechanism which differs little from the existing=20 > ones also seems to have very little chance of being implemented. >=20 > There is a better alternative that EMU WG should consider.=20 > This is to choose an existing method for inclusion on the=20 > IETF Standards Track, rather than creating a new one. In=20 > order to maintain backward compatibility, this would require=20 > that the owners give up change control to the IETF. >=20 > I would suggest that the best candidate for this would be=20 > EAP-TTLSv0, since it is very widely implemented, and has an=20 > existing certification program in=20 > WFA. Also, EAP-TTLSv0 had previously been on the Standards=20 > Track in the=20 > PPPEXT WG, before work on EAP methods was removed from the=20 > PPPEXT WG charter and the EAP WG was formed. >=20 > In terms of steps to be taken, this would require the=20 > following actions: >=20 > a. Review and publication of the existing EAP-TTLSv0=20 > specification as an RFC. The goal here would be to document=20 > EAP-TTLSv0 as it exists today. >=20 > b. Agreement by the authors to give up change control to the IETF. >=20 > c. EMU WG efforts to publish an EAP-TTLSv0 "bis" document,=20 > specifying additional capabilities (such as Channel Bindings). >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 02 17:33:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYU9l-00025v-0S; Mon, 02 Apr 2007 17:33:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYU9j-00025b-VQ for emu@ietf.org; Mon, 02 Apr 2007 17:33:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYU9i-0003vC-Hi for emu@ietf.org; Mon, 02 Apr 2007 17:33:39 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2007 17:33:39 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l32LXckg015839; Mon, 2 Apr 2007 17:33:38 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l32LXFla002205; Mon, 2 Apr 2007 21:33:38 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 17:33:25 -0400 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: [Emu] Thoughts on Password-based EAP Methods Date: Mon, 2 Apr 2007 17:33:22 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B7041F9AF6@xmb-rtp-212.amer.cisco.com> In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004ADDE24@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Thoughts on Password-based EAP Methods Thread-Index: AcdwgbyDI98ve6UoRfCi/RnvnE2MHAE2mL2QAADg76AAASqTcA== References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004ADDE24@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: "Hao Zhou \(hzhou\)" To: "Ryan Hurst" , "Joseph Salowey \(jsalowey\)" , "Bernard Aboba" , X-OriginalArrivalTime: 02 Apr 2007 21:33:25.0878 (UTC) FILETIME=[8BFC7960:01C7756E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4325; t=1175549618; x=1176413618; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20\(hzhou\)=22=20 |Subject:=20RE=3A=20[Emu]=20Thoughts=20on=20Password-based=20EAP=20Method s |Sender:=20 |To:=20=22Ryan=20Hurst=22=20, =0A=20=20=20=20=20 =20=20=20=22Joseph=20Salowey=20\(jsalowey\)=22=20, =0A= 20=20=20=20=20=20=20=20=22Bernard=20Aboba=22=20 ,=20; bh=y6M0Ja+XYVRq7XnQo/ac4XucS3T6r/vZ2+irzExLrOM=; b=wSh1rTJO407wR54a1zfLZ9z0NM3qeU+4COXzdXT/uf83g+pLQeI9fnWofX8ln1q2G0xp0JEQ HNP0aJUlELHtD1PPhrr+8cUjs0wEkvS9hM1THsaEvKy9a7Ft7cTeQ5AT; Authentication-Results: rtp-dkim-2; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org What is the difference between defining a new method vs. a new version of the existing EAP method that is not backward compatible? I don't see how the implementation issue will go away. Some one still needs to implement it and customers need to deploy it. Might be more confusing to define another version of TTLS, as there are two version defined already, version 0 and 1. It seems to me much cleaner to start from a standard based EAP method handling password-only, and gradually extending it over time. > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > Sent: Monday, April 02, 2007 3:48 PM > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] Thoughts on Password-based EAP Methods >=20 > I believe there were many issues with how PEAP progressed, if=20 > we are careful we could prevent the same things from=20 > happening with TTLS. >=20 > Ryan >=20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Monday, April 02, 2007 12:36 PM > To: Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] Thoughts on Password-based EAP Methods >=20 > I'm not sure that adding yet another version to TTLS=20 > specifically for supporting passwords will make things better=20 > for customers. Multiple > versions certainly has caused quite a confusion in PEAP. =20 >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, March 27, 2007 8:07 AM > > To: emu@ietf.org > > Subject: [Emu] Thoughts on Password-based EAP Methods > >=20 > > After listening to the IETF 68 presentation on a password-based EAP=20 > > method, I would like to voice some concerns. > >=20 > > Today we already have an "over abundance" of such methods. =20 > > These include=20 > > PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my=20 > > discussions > > with customers, I invariably hear complaints about this=20 > explosion, and=20 > > about various interoperability and compatibility problems that it=20 > > causes. Simply put, customers do not want "yet another=20 > password-based=20 > > EAP method"; they want a single method that is widely=20 > implemented and=20 > > interoperable. > >=20 > > I am concerned that by defining yet another password-based=20 > > authentication mechanism, EMU WG will be making this problem worse,=20 > > not > > better. Creating=20 > > yet another mechanism which differs little from the=20 > existing ones also=20 > > seems to have very little chance of being implemented. > >=20 > > There is a better alternative that EMU WG should consider.=20 > > This is to choose an existing method for inclusion on the IETF=20 > > Standards Track, rather than creating a new one. In order=20 > to maintain=20 > > backward compatibility, this would require that the owners give up=20 > > change control to the IETF. > >=20 > > I would suggest that the best candidate for this would be=20 > EAP-TTLSv0,=20 > > since it is very widely implemented, and has an existing=20 > certification=20 > > program in > > WFA. Also, EAP-TTLSv0 had previously been on the Standards=20 > > Track in the > > PPPEXT WG, before work on EAP methods was removed from the=20 > PPPEXT WG=20 > > charter and the EAP WG was formed. > >=20 > > In terms of steps to be taken, this would require the following=20 > > actions: > >=20 > > a. Review and publication of the existing EAP-TTLSv0=20 > specification as=20 > > an RFC. The goal here would be to document EAP-TTLSv0 as it exists=20 > > today. > >=20 > > b. Agreement by the authors to give up change control to the IETF. > >=20 > > c. EMU WG efforts to publish an EAP-TTLSv0 "bis" document,=20 > specifying=20 > > additional capabilities (such as Channel Bindings). > >=20 > >=20 > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 02 17:59:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUYq-0004ox-1r; Mon, 02 Apr 2007 17:59:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUYp-0004oq-4W for emu@ietf.org; Mon, 02 Apr 2007 17:59:35 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYUYn-00031k-PW for emu@ietf.org; Mon, 02 Apr 2007 17:59:35 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 02 Apr 2007 14:59:34 -0700 X-IronPort-AV: i="4.14,362,1170662400"; d="scan'208"; a="701273426:sNHT42026336" 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 Date: Mon, 2 Apr 2007 17:59:31 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Thoughts on Password-based EAP Methods Thread-Index: Acd1WRVKRTRRuO0cRu+Gidz8w0XnkgAFRdTg From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Emu] Re: Thoughts on Password-based EAP Methods X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Sorry it took me a few days to respond to this thread. I agree with Bernard that there's no benefit in creating Yet Another Password-Based EAP Method (YAPBEM). There's no point in reinventing the wheel for a fourth time and it's not the IETF way. We're not researchers. We're practical engineers who respect running code and rough consensus. So, yes, we should have a bias toward existing, well-tested and well-understood protocols. In a security group, it's especially important to avoid the temptation to reinvent the wheel. We should focus our efforts on one secure tunneled EAP method and make that one secure. We should consider existing methods and only invent something new if we need to. I have spoken to Paul Funk, the primary author of the EAP-TTLSv0 spec. He is glad to proceed as Bernard suggested: 1. Publish an updated EAP-TTLSv0 spec that documents current practice (as Informational or Experimental) 2. Give up change control to the IETF so that the EMU WG can make any necessary changes or additions to EAP-TTLS I'm also glad to assist with this effort, since Paul is pretty busy these days. Thanks, Steve -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Tuesday, March 27, 2007 8:07 AM To: emu@ietf.org Subject: [Emu] Thoughts on Password-based EAP Methods After listening to the IETF 68 presentation on a password-based EAP method, I would like to voice some concerns. Today we already have an "over abundance" of such methods. These include PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my discussions with customers, I invariably hear complaints about this explosion, and about various interoperability and compatibility problems that it causes. Simply put, customers do not want "yet another password-based EAP method"; they want a single method that is widely implemented and interoperable. I am concerned that by defining yet another password-based authentication mechanism, EMU WG will be making this problem worse, not better. Creating yet another mechanism which differs little from the existing ones also seems to have very little chance of being implemented. There is a better alternative that EMU WG should consider. This is to choose an existing method for inclusion on the IETF Standards Track, rather than creating a new one. In order to maintain backward compatibility, this would require that the owners give up change control to the IETF. I would suggest that the best candidate for this would be EAP-TTLSv0, since it is very widely implemented, and has an existing certification program in WFA. Also, EAP-TTLSv0 had previously been on the Standards Track in the PPPEXT WG, before work on EAP methods was removed from the PPPEXT WG charter and the EAP WG was formed. In terms of steps to be taken, this would require the following actions: a. Review and publication of the existing EAP-TTLSv0 specification as an RFC. The goal here would be to document EAP-TTLSv0 as it exists today. b. Agreement by the authors to give up change control to the IETF. c. EMU WG efforts to publish an EAP-TTLSv0 "bis" document, specifying additional capabilities (such as Channel Bindings). _______________________________________________ Emu mailing list Emu at ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 02 18:11:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUjx-0005TF-Eh; Mon, 02 Apr 2007 18:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUjv-0005T3-G5 for emu@ietf.org; Mon, 02 Apr 2007 18:11:03 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYUju-0007oR-3L for emu@ietf.org; Mon, 02 Apr 2007 18:11:03 -0400 Received: (qmail invoked by alias); 02 Apr 2007 22:11:00 -0000 Received: from p54986524.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.101.36] by mail.gmx.net (mp028) with SMTP; 03 Apr 2007 00:11:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+gdgwg43SgRqA4q04Nerbtz3NVV5QlJoFrjO4Snz 8/ElDDHymv4ktn Message-ID: <46117F74.5070808@gmx.net> Date: Tue, 03 Apr 2007 00:11:00 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: emu@ietf.org Subject: Re: [Emu] Re: Thoughts on Password-based EAP Methods References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I am not surprised to hear that EAP method authors agree that no further EAP methods should be developed. Part of the problem with EAP methods is that people should have started to standardize them within the IETF several years ago. Unfortunately, there was no interest by some of the EAP method authors nor from the EAP WG chairs to allow that. But if some (unknown) customers say that they do not want more EAP methods then Sam will have to change his mind. At the last IETF meeting he ruled out the usage of TTLS, for example. I hope that the some people can change their mind with regard to the applicability statement of EAP usage in TLS so quickly as well.... ~snip~ _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 02 18:42:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVEH-0002D9-Ai; Mon, 02 Apr 2007 18:42:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVEF-0002D4-Sw for emu@ietf.org; Mon, 02 Apr 2007 18:42:23 -0400 Received: from bay0-omc2-s41.bay0.hotmail.com ([65.54.246.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYVEE-00014y-Jp for emu@ietf.org; Mon, 02 Apr 2007 18:42:23 -0400 Received: from hotmail.com ([207.46.8.83]) by bay0-omc2-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 2 Apr 2007 15:42:22 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 Apr 2007 15:42:22 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 02 Apr 2007 22:42:21 GMT X-Originating-IP: [131.107.0.74] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <46117F74.5070808@gmx.net> From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: Re: [Emu] Re: Thoughts on Password-based EAP Methods Date: Mon, 02 Apr 2007 15:42:21 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 Apr 2007 22:42:22.0010 (UTC) FILETIME=[2D5021A0:01C77578] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >Part of the problem with EAP methods is that people should have started to >standardize them within the IETF several years ago. Unfortunately, there >was no interest by some of the EAP method authors nor from the EAP WG >chairs to allow that. In fact, the IETF was on track to standardize EAP methods back as recently as 2001, within the PPPEXT WG. It was as part of that program that EAP-TLS was first published as an Experimental RFC, and EAP-TTLSv0 was put on the standards track. The decision to remove standards track EAP methods from the PPPEXT WG charter was made by the IESG, not by the authors of EAP methods, or the EAP WG chairs. As I recall, there was considerable opposition to that decision at the time. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 02 18:45:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVHd-0004MR-A2; Mon, 02 Apr 2007 18:45:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVHb-0004ML-Tq for emu@ietf.org; Mon, 02 Apr 2007 18:45:51 -0400 Received: from bay0-omc1-s3.bay0.hotmail.com ([65.54.246.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYVHZ-0003Ak-Kf for emu@ietf.org; Mon, 02 Apr 2007 18:45:51 -0400 Received: from hotmail.com ([207.46.8.96]) by bay0-omc1-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 2 Apr 2007 15:45:49 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 Apr 2007 15:45:48 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 02 Apr 2007 22:45:44 GMT X-Originating-IP: [131.107.0.74] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004ADDE24@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: RE: [Emu] Thoughts on Password-based EAP Methods Date: Mon, 02 Apr 2007 15:45:44 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 Apr 2007 22:45:48.0755 (UTC) FILETIME=[A88AEA30:01C77578] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >I'm not sure that adding yet another version to TTLS specifically for >supporting passwords will make things better for customers. Multiple >versions certainly has caused quite a confusion in PEAP. I would agree that "versioning" is not a good idea. However, as I understand it, EAP-TTLSv0 is the only deployed version of TTLS; v1 has never been implemented. So currently there is no versioning issue with TTLS, and if possible, it would be best if the IETF would not create such a problem. It is not clear to me that EAP-TTLS needs "versioning" in order to enable addition of new features in a backwards compatible way, since it already supports a TLV-based extension mechanism. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 02 20:11:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYWcj-0005MV-7G; Mon, 02 Apr 2007 20:11:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYWci-0005MQ-EA for emu@ietf.org; Mon, 02 Apr 2007 20:11:44 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYWcd-0006st-W6 for emu@ietf.org; Mon, 02 Apr 2007 20:11:44 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 2 Apr 2007 17:11:39 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.685.25; Mon, 2 Apr 2007 17:11:38 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Mon, 2 Apr 2007 17:11:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] Thoughts on Password-based EAP Methods Date: Mon, 2 Apr 2007 17:08:24 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8001D76280@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Thoughts on Password-based EAP Methods Thread-Index: Acd1eLZmt5m13t2uTOaZLCku1JFCAQAC3xLo References: From: Ryan Hurst To: Bernard Aboba , X-OriginalArrivalTime: 03 Apr 2007 00:11:38.0532 (UTC) FILETIME=[A60C8640:01C77584] X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1747700839==" Errors-To: emu-bounces@ietf.org --===============1747700839== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77584.89E8BEA7" ------_=_NextPart_001_01C77584.89E8BEA7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I totally agree, I would hate to see us define yet another tunneling eap = method if we could add a couple extensions to a existing one that has = received reasonable adoption already. =20 If it turns out we had to define a totally new non-backwards compatible = protocol I would agree we would probably be better off starting all over = but from my read of the current (expired) TTLSv0 document I dont think = thats where we would be going. =20 Ryan ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Mon 4/2/2007 3:45 PM To: emu@ietf.org Subject: RE: [Emu] Thoughts on Password-based EAP Methods >I'm not sure that adding yet another version to TTLS specifically for >supporting passwords will make things better for customers. Multiple >versions certainly has caused quite a confusion in PEAP. I would agree that "versioning" is not a good idea. However, as I understand it, EAP-TTLSv0 is the only deployed version of TTLS; v1 has = never been implemented. So currently there is no versioning issue with TTLS, = and if possible, it would be best if the IETF would not create such a = problem. It is not clear to me that EAP-TTLS needs "versioning" in order to = enable addition of new features in a backwards compatible way, since it already supports a TLV-based extension mechanism. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ------_=_NextPart_001_01C77584.89E8BEA7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Emu] Thoughts on Password-based EAP = Methods=0A= =0A= =0A= =0A=
=0A=
I totally = agree, I would hate to see us define yet another tunneling eap method if = we could add a couple extensions to a existing one that has received = reasonable adoption already.
=0A=
 
=0A=
If it turns out we had to = define a totally new non-backwards compatible protocol I would agree we = would probably be better off starting all over but from my read of the = current (expired) TTLSv0 document I dont think thats where we would be = going.
=0A=
 
=0A=
Ryan
=0A=

=0A=
=0A= From: Bernard Aboba = [mailto:bernard_aboba@hotmail.com]
Sent: Mon 4/2/2007 3:45 = PM
To: emu@ietf.org
Subject: RE: [Emu] Thoughts on = Password-based EAP Methods

=0A=
=0A=

>I'm not sure that adding yet another version to = TTLS specifically for
>supporting passwords will make things = better for customers.  Multiple
>versions certainly has = caused quite a confusion in PEAP.

I would agree that "versioning" = is not a good idea.  However, as I
understand it, EAP-TTLSv0 is = the only deployed version of TTLS; v1 has never
been = implemented.   So currently there is no versioning issue with = TTLS, and
if possible, it would be best if the IETF would not create = such a problem.

It is not clear to me that EAP-TTLS needs = "versioning" in order to enable
addition of new features in a = backwards compatible way, since it already
supports a TLV-based = extension = mechanism.



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

------_=_NextPart_001_01C77584.89E8BEA7-- --===============1747700839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1747700839==-- From emu-bounces@ietf.org Mon Apr 02 22:08:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYRT-00089L-QV; Mon, 02 Apr 2007 22:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYRS-00087h-6l for emu@ietf.org; Mon, 02 Apr 2007 22:08:14 -0400 Received: from mail1.sea5.speakeasy.net ([69.17.117.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYYRQ-0001wb-RK for emu@ietf.org; Mon, 02 Apr 2007 22:08:14 -0400 Received: (qmail 18863 invoked from network); 3 Apr 2007 02:08:01 -0000 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net (HELO jm) ([69.17.49.110]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 3 Apr 2007 02:08:01 -0000 Received: by jm (sSMTP sendmail emulation); Mon, 2 Apr 2007 19:07:15 -0700 Date: Mon, 2 Apr 2007 19:07:15 -0700 From: Jouni Malinen To: Bernard Aboba Subject: Re: [Emu] Thoughts on Password-based EAP Methods Message-ID: <20070403020714.GT16197@jm.kir.nu> References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004ADDE24@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Mon, Apr 02, 2007 at 03:45:44PM -0700, Bernard Aboba wrote: > I would agree that "versioning" is not a good idea. However, as I > understand it, EAP-TTLSv0 is the only deployed version of TTLS; v1 has > never been implemented. So currently there is no versioning issue with > TTLS, and if possible, it would be best if the IETF would not create such a > problem. I'm aware of at least one, though maybe partial, implementation of TTLSv1. Anyway, I don't think it has been deployed anywhere. > It is not clear to me that EAP-TTLS needs "versioning" in order to enable > addition of new features in a backwards compatible way, since it already > supports a TLV-based extension mechanism. If this can be done in backwards compatible way, staying with the v0 sounds reasonable assuming features from TTLSv1 are not desired and I don't think would necessarily like to mandate TLS/IA support for the method to be standardized. In general, the PEAP version negotiation itself works fine, but one of the problems is that number of different implementations _within_ the same version number work differently.. The main issue for me from the implementation view point has been lack of clear description of the protocol and existance of differently behaving and already deployed implementations.. EAP-TTLSv0 is in better situation from the viewpoint of most implementation behaving more or less in the same way. However, this can get interesting if new extensions are added and if some of the implementations are not exactly prepared for this. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 02 22:41:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYxO-0002TD-0z; Mon, 02 Apr 2007 22:41:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYxM-0002Sf-Ez for emu@ietf.org; Mon, 02 Apr 2007 22:41:12 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYYxL-0008Av-4D for emu@ietf.org; Mon, 02 Apr 2007 22:41:12 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2007 22:41:11 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l332fACi007487; Mon, 2 Apr 2007 22:41:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l332fAGd025797; Tue, 3 Apr 2007 02:41:10 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 22:41:10 -0400 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: [Emu] Thoughts on Password-based EAP Methods Date: Mon, 2 Apr 2007 22:41:09 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B7041F9B8A@xmb-rtp-212.amer.cisco.com> In-Reply-To: <20070403020714.GT16197@jm.kir.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Thoughts on Password-based EAP Methods Thread-Index: Acd1lPj18X4o9taoS62sPgYEQODlOgAAuSXg References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004ADDE24@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <20070403020714.GT16197@jm.kir.nu> From: "Hao Zhou \(hzhou\)" To: "Jouni Malinen" , "Bernard Aboba" X-OriginalArrivalTime: 03 Apr 2007 02:41:10.0275 (UTC) FILETIME=[899FDD30:01C77599] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3101; t=1175568070; x=1176432070; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20\(hzhou\)=22=20 |Subject:=20RE=3A=20[Emu]=20Thoughts=20on=20Password-based=20EAP=20Method s |Sender:=20 |To:=20=22Jouni=20Malinen=22=20, =20=22Bernard=20Aboba=22=20; bh=REc2NCBI+RFG/IZIJdSEljIMoiXpo0mcDrtqK1MM19A=; b=LPuBrveITH1JMQ7lK8PZ9aCvwJrvkfvHMWU2WILpNjI98f9CkVsE3Aiqy1qvIHPW1CkeMGsw nc+Kosi0oMBqz/rffJ7ocwodW5xNn5oeX0Ka/cdQCdZdir3W8+btfgpz; Authentication-Results: rtp-dkim-2; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Please see inline.=20 > -----Original Message----- > From: Jouni Malinen [mailto:j@w1.fi]=20 > Sent: Monday, April 02, 2007 10:07 PM > To: Bernard Aboba > Cc: emu@ietf.org > Subject: Re: [Emu] Thoughts on Password-based EAP Methods >=20 > On Mon, Apr 02, 2007 at 03:45:44PM -0700, Bernard Aboba wrote: >=20 > > I would agree that "versioning" is not a good idea. However, as I=20 > > understand it, EAP-TTLSv0 is the only deployed version of=20 > TTLS; v1 has > > never been implemented. So currently there is no=20 > versioning issue with=20 > > TTLS, and if possible, it would be best if the IETF would=20 > not create=20 > > such a problem. >=20 > I'm aware of at least one, though maybe partial,=20 > implementation of TTLSv1. Anyway, I don't think it has been=20 > deployed anywhere. >=20 > > It is not clear to me that EAP-TTLS needs "versioning" in order to=20 > > enable addition of new features in a backwards compatible=20 > way, since=20 > > it already supports a TLV-based extension mechanism. >=20 > If this can be done in backwards compatible way, staying with=20 > the v0 sounds reasonable assuming features from TTLSv1 are=20 > not desired and I don't think would necessarily like to=20 > mandate TLS/IA support for the method to be standardized. > [HZ] My point is that we cannot do it in a backward compatible way. First of all, not sure we need the Diameter AVP complexity inside the tunnel. Second of all, TTLSv0 doesn't have crypto-binding and agility, which mostly require changes that are not backward compatible.=20 =20 > In general, the PEAP version negotiation itself works fine,=20 > but one of the problems is that number of different=20 > implementations _within_ the same version number work=20 > differently.. The main issue for me from the implementation=20 > view point has been lack of clear description of the protocol=20 > and existance of differently behaving and already deployed=20 > implementations.. [HZ] That's not true. There are only two PEAP versions in deployment, PEAPv0 and PEAPv1. They are different between them. But among PEAPv0 or PEAPv1 implementations, they interoperate. >=20 > EAP-TTLSv0 is in better situation from the viewpoint of most=20 > implementation behaving more or less in the same way.=20 > However, this can get interesting if new extensions are added=20 > and if some of the implementations are not exactly prepared for this. >=20 [HZ] That's the problem. We cannot add or take away functionalities and maintain interoperability without incrementing the version. If we do that, then how is that different than creating a new EAP method. The design team is looking at approach similar to TTLS/PEAP/EAP-FAST, with a much simpler inner data representation. Whatever the argument made for TTLS, we can make it for PEAP and EAP-FAST. > --=20 > Jouni Malinen PGP=20 > id EFC895FA >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 02 23:23:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYZcI-0003ZU-AL; Mon, 02 Apr 2007 23:23:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYZcG-0003WF-Oy for emu@ietf.org; Mon, 02 Apr 2007 23:23:28 -0400 Received: from mail3.sea5.speakeasy.net ([69.17.117.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYZcF-0007Md-CM for emu@ietf.org; Mon, 02 Apr 2007 23:23:28 -0400 Received: (qmail 14367 invoked from network); 3 Apr 2007 03:23:11 -0000 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net (HELO jm) ([69.17.49.110]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 3 Apr 2007 03:23:10 -0000 Received: by jm (sSMTP sendmail emulation); Mon, 2 Apr 2007 20:22:24 -0700 Date: Mon, 2 Apr 2007 20:22:24 -0700 From: Jouni Malinen To: "Hao Zhou (hzhou)" Subject: Re: [Emu] Thoughts on Password-based EAP Methods Message-ID: <20070403032224.GV16197@jm.kir.nu> References: <20070403020714.GT16197@jm.kir.nu> <9958B444368E884DBB215F3FEF36F5B7041F9B8A@xmb-rtp-212.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9958B444368E884DBB215F3FEF36F5B7041F9B8A@xmb-rtp-212.amer.cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Bernard Aboba , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Mon, Apr 02, 2007 at 10:41:09PM -0400, Hao Zhou (hzhou) wrote: > > differently.. The main issue for me from the implementation > > view point has been lack of clear description of the protocol > > and existance of differently behaving and already deployed > > implementations.. > [HZ] That's not true. There are only two PEAP versions in deployment, > PEAPv0 and PEAPv1. They are different between them. But among PEAPv0 or > PEAPv1 implementations, they interoperate. Have you run interop tests with PEAPv0 and PEAPv1 using a large set of different server implementations? I've tested with ten or so servers that supported various combinations of PEAPv0 and PEAPv1. There were at least six different combinations on behaviors that required peer workarounds to handle.. PEAPv1 is more problematic on this front since there is more than one IETF draft describing a protocol that uses version 1 and these drafts differ on number of areas and none of these drafts actually describe the exact behavior that most servers uses.. For example, at least one server uses "client PEAP encryption" as the label for PRF whereas most use "client EAP encryption". That is clearly an interoperability issue (I've only seen this with PEAPv1 and one RADIUS server, but anyway that is the label described in some of the drafts). Another difference is in how the negotiation is terminated. Some implementations require protected success indication by use of a tunneled EAP-Success. Some use just plain EAP-Success outside the tunnel without any protected success indication. Yet another interoperability issue. One strange case was an implementation that uses incorrect version negotiation and in practice ends up always using v0 (which itself interoperates relatively well, so this is not a major problem). In other words, PEAPv1 is not exactly something I would consider a good example of an interoperable or well-defined EAP method. I think that EAP-PEAP has caused more interop issues in my tests than all other methods combined.. Sure, this is partly due to most implementations supporting PEAP in one form or another so there are more test cases, but still, EAP-TLS and EAP-TTLS have been more or less problem free from the view point of seeing different behavior from implementations. > [HZ] That's the problem. We cannot add or take away functionalities and > maintain interoperability without incrementing the version. If we do > that, then how is that different than creating a new EAP method. The > design team is looking at approach similar to TTLS/PEAP/EAP-FAST, with a > much simpler inner data representation. Whatever the argument made for > TTLS, we can make it for PEAP and EAP-FAST. I haven't went through the details of what would be needed for the changes while trying to maintain backwards compatibility within the same version number, so I cannot comment on the first part, but I can agree with the second. Anyway, I certainly support the idea of using something existing as a starting point whether the end result ends up using the same method number and version or not. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 03:25:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYdNw-00028E-CI; Tue, 03 Apr 2007 03:24:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYdNu-000289-Sb for emu@ietf.org; Tue, 03 Apr 2007 03:24:54 -0400 Received: from bay0-omc2-s17.bay0.hotmail.com ([65.54.246.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYdNt-0006Jb-Ih for emu@ietf.org; Tue, 03 Apr 2007 03:24:54 -0400 Received: from hotmail.com ([207.46.8.106]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 3 Apr 2007 00:24:52 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Apr 2007 00:24:52 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 03 Apr 2007 07:24:51 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20070403032224.GV16197@jm.kir.nu> From: "Bernard Aboba" To: j@w1.fi Bcc: Subject: Re: [Emu] Thoughts on Password-based EAP Methods Date: Tue, 03 Apr 2007 00:24:51 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 03 Apr 2007 07:24:52.0923 (UTC) FILETIME=[2BE9D0B0:01C775C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >For example, at least one server uses "client PEAP encryption" as the >label for PRF whereas most use "client EAP encryption". That is clearly >an interoperability issue (I've only seen this with PEAPv1 and one >RADIUS server, but anyway that is the label described in some of the >drafts). Using the same label string as EAP-TLS (e.g. "client EAP encryption") enables an attacker to modify the PEAP Type Code without detection, since the Type field is not included in the MIC. >One strange case was an implementation that uses incorrect version >negotiation and in practice ends up always using v0 (which itself >interoperates relatively well, so this is not a major problem). The PEAP version negotiation assumes that implementations support all the downward compatible versions, so that a server advertising PEAPv1 also can negotiate (and support) PEAPv0. However, this assumes that endpoints will negotiate the highest available version. Unfortunately, there are now multiple versions of PEAPv0, some of which include functionality not supported by PEAPv1, so that this assumption is not really valid. >I think that PEAP has caused more interop issues in my tests than all other >methods combined.. Right. Not surprisingly, PEAP also been the source of a huge number of customer complaints. >Still, EAP-TLS and EAP-TTLS have been more or less problem free from the >view point of seeing different behavior from implementations. At least this was true prior to the deployment of TLSv1.1 implementations. I'm afraid that since then we are seeing a substantial rise in interoperability problems with all TLS-based EAP methods. Hopefully this will subside once broken TLS v1.0 implementations are fixed in the field. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 04:24:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYeJn-0004c0-G5; Tue, 03 Apr 2007 04:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYeJm-0004bq-6Z for emu@ietf.org; Tue, 03 Apr 2007 04:24:42 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYeJg-0007bc-Tw for emu@ietf.org; Tue, 03 Apr 2007 04:24:42 -0400 Received: (qmail invoked by alias); 03 Apr 2007 08:24:35 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp032) with SMTP; 03 Apr 2007 10:24:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+1YJNyPia1aCSZV5Z5+X2KhRbN3epVwH3Q1xp11k LY5ZB6CfH4wjhN Message-ID: <46120F43.9020004@gmx.net> Date: Tue, 03 Apr 2007 10:24:35 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: wpolk@nist.gov, hartmans-ietf@mit.edu Subject: [Emu] Next Steps on Passwd-based EAP Methods X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi all, before we spend more time considering EAP tunneling methods like PEAP and TTLS I would like to hear the opinion of our ADs on this subject. So far, the working assumption was that EAP methods that tunnel EAP are outside the scope of the working group. These statements were also repeated during the IETF#68 EMU WG meeting by our ADs. We seem to change the assumptions on the fly. Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 04:27:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYeMI-0005tt-97; Tue, 03 Apr 2007 04:27:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYeMH-0005ti-G7 for emu@ietf.org; Tue, 03 Apr 2007 04:27:17 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYeMD-0000FP-26 for emu@ietf.org; Tue, 03 Apr 2007 04:27:17 -0400 Received: (qmail invoked by alias); 03 Apr 2007 08:27:12 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp040) with SMTP; 03 Apr 2007 10:27:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/RRXpcP+HRNRP0wSbIjqyWVxdIHpWvQYkytrLUDi HeM6CVvySKQjrj Message-ID: <46120FE0.6050302@gmx.net> Date: Tue, 03 Apr 2007 10:27:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] Thoughts on Password-based EAP Methods References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I see it a bit differently since I was at many EAP meetings where EAP method authors wanted to work on standards track EAP methods. Ciao Hannes Bernard Aboba wrote: >> Part of the problem with EAP methods is that people should have >> started to standardize them within the IETF several years ago. >> Unfortunately, there was no interest by some of the EAP method >> authors nor from the EAP WG chairs to allow that. > > In fact, the IETF was on track to standardize EAP methods back as > recently as 2001, within the PPPEXT WG. It was as part of that > program that EAP-TLS was first published as an Experimental RFC, and > EAP-TTLSv0 was put on the standards track. > > The decision to remove standards track EAP methods from the PPPEXT WG > charter was made by the IESG, not by the authors of EAP methods, or > the EAP WG chairs. As I recall, there was considerable opposition to > that decision at the time. > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 05:54:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfiW-0005sA-29; Tue, 03 Apr 2007 05:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfiV-0005rQ-2d for emu@ietf.org; Tue, 03 Apr 2007 05:54:19 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYfXO-0000tM-TI for emu@ietf.org; Tue, 03 Apr 2007 05:42:52 -0400 Received: (qmail invoked by alias); 03 Apr 2007 09:42:49 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp057) with SMTP; 03 Apr 2007 11:42:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX183TrkUDEU3ahKsNHng7CzNfw6lOSvBmKI2PjGUP3 BVedw/ZxlPQsOG Message-ID: <46122193.6030209@gmx.net> Date: Tue, 03 Apr 2007 11:42:43 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: emu@ietf.org Subject: Re: [Emu] Next Steps on Passwd-based EAP Methods References: <46120F43.9020004@gmx.net> In-Reply-To: <46120F43.9020004@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: wpolk@nist.gov, hartmans-ietf@mit.edu X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I also need to say that at the IETF#68 EMU WG meeting the discussions in the room where pretty positive for moving forward with a simple password-based EAP method using TLS without another EAP encapsulation on top of TLS. I also got the impression after the session that the people in the room where happy with the tentative decisions we made. I had a clear picture in mind how to move forward with the work on this topic. I only recall a single person in the room that raised some concerns. Ciao Hannes PS: To clarify my position: I also have no problem with working on TTLSv1 (as I expressed on the DT mailing list). This would, however, require the TLS working group to work on the TLS Inner Application, which I also think is useful. This approach was, however, ruled out by the ADs. Hannes Tschofenig wrote: > Hi all, > > before we spend more time considering EAP tunneling methods like PEAP > and TTLS I would like to hear the opinion of our ADs on this subject. > So far, the working assumption was that EAP methods that tunnel EAP > are outside the scope of the working group. These statements were also > repeated during the IETF#68 EMU WG meeting by our ADs. > > We seem to change the assumptions on the fly. > > Ciao > Hannes > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 08:52:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYiUl-0003TG-Q6; Tue, 03 Apr 2007 08:52:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYiUh-0003AM-Vv for emu@ietf.org; Tue, 03 Apr 2007 08:52:16 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYiUg-0008Ae-Ne for emu@ietf.org; Tue, 03 Apr 2007 08:52:15 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B4397E0431; Tue, 3 Apr 2007 08:52:14 -0400 (EDT) From: Sam Hartman To: Hannes Tschofenig References: <46120F43.9020004@gmx.net> Date: Tue, 03 Apr 2007 08:52:14 -0400 In-Reply-To: <46120F43.9020004@gmx.net> (Hannes Tschofenig's message of "Tue, 03 Apr 2007 10:24:35 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: wpolk@nist.gov, emu@ietf.org Subject: [Emu] Re: Next Steps on Passwd-based EAP Methods X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >>>>> "Hannes" == Hannes Tschofenig writes: Hannes> Hi all, before we spend more time considering EAP Hannes> tunneling methods like PEAP and TTLS I would like to hear Hannes> the opinion of our ADs on this subject. So far, the Hannes> working assumption was that EAP methods that tunnel EAP Hannes> are outside the scope of the working group. These Hannes> statements were also repeated during the IETF#68 EMU WG Hannes> meeting by our ADs. I at least don't recall objecting to a tunnel method. If you're going to do a tunnel method you do need cryptographic binding when tunneling something that generates a key. Bernard objected rather strongly to a tunneled method. Note that I am not saying you should go in the direction of a tunneled method; a simple password over tls method is a fine approach. I just don't recall me making an AD level objection to tunnels. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 11:15:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkja-0006E3-VO; Tue, 03 Apr 2007 11:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkja-0006Dw-A8 for emu@ietf.org; Tue, 03 Apr 2007 11:15:46 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYkjY-0003nt-VG for emu@ietf.org; Tue, 03 Apr 2007 11:15:46 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2007 08:15:44 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l33FFiXO000463; Tue, 3 Apr 2007 08:15:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l33FFiZT023149; Tue, 3 Apr 2007 15:15:44 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 08:15:44 -0700 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: [Emu] Thoughts on Password-based EAP Methods Date: Tue, 3 Apr 2007 08:15:35 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Thoughts on Password-based EAP Methods Thread-Index: Acd1eLJ4rcfb6ubPRKyrmX8KD8SaPgAiZwTA From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 03 Apr 2007 15:15:44.0183 (UTC) FILETIME=[F2F9FC70:01C77602] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1447; t=1175613344; x=1176477344; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20Thoughts=20on=20Password-based=20EAP=20Method s |Sender:=20; bh=/RbUqpJQkNj51ZGY90YPgfRxhslddpPs7/z/Mtpsxvo=; b=omqx/MH5b9OCPGcqjCDX/M+DlC5UrxUQJGWLEEz7wUkxivurWlkrHHE1fyq8kT2Hah6NJNzE qXczoPD7pLpDwmXdjtvBmZqJx9afEzf1Q8JiNV2mcmvclO3KcPuPcQcV; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Some of the things that need to be fixed are fairly fundamental. For example crypto-binding and avoiding multiple layers of negotiation are fairly fundamental. At this point I'm not sure that modifying TLVs is the best way to achieve this. It needs to be investigated. =20 Joe > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Monday, April 02, 2007 3:46 PM > To: emu@ietf.org > Subject: RE: [Emu] Thoughts on Password-based EAP Methods >=20 > >I'm not sure that adding yet another version to TTLS=20 > specifically for=20 > >supporting passwords will make things better for customers. =20 > Multiple=20 > >versions certainly has caused quite a confusion in PEAP. >=20 > I would agree that "versioning" is not a good idea. However,=20 > as I understand it, EAP-TTLSv0 is the only deployed version=20 > of TTLS; v1 has never=20 > been implemented. So currently there is no versioning issue=20 > with TTLS, and=20 > if possible, it would be best if the IETF would not create=20 > such a problem. >=20 > It is not clear to me that EAP-TTLS needs "versioning" in=20 > order to enable addition of new features in a backwards=20 > compatible way, since it already supports a TLV-based=20 > extension mechanism. >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 11:40:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYl7I-0007RQ-St; Tue, 03 Apr 2007 11:40:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYl7H-0007PB-IG for emu@ietf.org; Tue, 03 Apr 2007 11:40:15 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYl7D-0003vn-Bf for emu@ietf.org; Tue, 03 Apr 2007 11:40:15 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B5135E0433; Tue, 3 Apr 2007 11:40:01 -0400 (EDT) From: Sam Hartman To: "Tschofenig, Hannes" Subject: Re: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods References: <8F6CBC7005099442AECDB784C9E9D7E7019AD5E1@MCHP7R6A.ww002.siemens.net> Date: Tue, 03 Apr 2007 11:40:01 -0400 In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E7019AD5E1@MCHP7R6A.ww002.siemens.net> (Hannes Tschofenig's message of "Tue, 3 Apr 2007 15:52:16 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: emu@ietf.org, wpolk@nist.gov X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >>>>> "Tschofenig," == Tschofenig, Hannes writes: Tschofenig,> Hi Sam, >> >>>>> "Hannes" == Hannes Tschofenig >> writes: >> Hannes> Hi all, before we spend more time considering EAP Hannes> tunneling methods like PEAP and TTLS I would like to hear Hannes> the opinion of our ADs on this subject. So far, the Hannes> working assumption was that EAP methods that tunnel EAP Hannes> are outside the scope of the working group. These Hannes> statements were also repeated during the IETF#68 EMU WG Hannes> meeting by our ADs. >> I at least don't recall objecting to a tunnel method. If >> you're going to do a tunnel method you do need cryptographic >> binding when tunneling something that generates a key. Tschofenig,> I recall that you rejected the TTLS approach where we Tschofenig,> would have to add EAP support into TLS. I am also Tschofenig,> happy to hear that you like providing EAP support in Tschofenig,> TLS. Yes, I reject that approach to tunnelsing. But you could for example use the TLS application record protocol to tunnel EAP. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 11:46:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYlCx-0002L8-8U; Tue, 03 Apr 2007 11:46:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYlCv-0002EB-8Y for emu@ietf.org; Tue, 03 Apr 2007 11:46:05 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYlCl-00066j-QX for emu@ietf.org; Tue, 03 Apr 2007 11:46:05 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 03 Apr 2007 08:45:55 -0700 X-IronPort-AV: i="4.14,366,1170662400"; d="scan'208"; a="701763061:sNHT66411036" 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: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods Date: Tue, 3 Apr 2007 11:45:55 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods Thread-Index: Acd2Bmtl2HTWv1y0TNOSUgXFgNIO8gAAEzWg From: "Stephen Hanna" To: "Sam Hartman" , "Tschofenig, Hannes" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: wpolk@nist.gov, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org FYI, EAP-TTLSv0 does not require any changes to the TLS handshake. Only EAP-TTLSv1 does. Thanks, Steve -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 Sent: Tuesday, April 03, 2007 11:40 AM To: Tschofenig, Hannes Cc: emu@ietf.org; wpolk@nist.gov Subject: Re: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods >>>>> "Tschofenig," =3D=3D Tschofenig, Hannes = writes: Tschofenig,> Hi Sam, >> >>>>> "Hannes" =3D=3D Hannes Tschofenig = >> writes: >>=20 Hannes> Hi all, before we spend more time considering EAP Hannes> tunneling methods like PEAP and TTLS I would like to hear Hannes> the opinion of our ADs on this subject. So far, the Hannes> working assumption was that EAP methods that tunnel EAP Hannes> are outside the scope of the working group. These Hannes> statements were also repeated during the IETF#68 EMU WG Hannes> meeting by our ADs. >> I at least don't recall objecting to a tunnel method. If >> you're going to do a tunnel method you do need cryptographic >> binding when tunneling something that generates a key. Tschofenig,> I recall that you rejected the TTLS approach where we Tschofenig,> would have to add EAP support into TLS. I am also Tschofenig,> happy to hear that you like providing EAP support in Tschofenig,> TLS. Yes, I reject that approach to tunnelsing. But you could for example use the TLS application record protocol to tunnel EAP. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 12:33:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYlwG-0008Mn-Ew; Tue, 03 Apr 2007 12:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjQs-0001HT-3z for emu@ietf.org; Tue, 03 Apr 2007 09:52:22 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYjQp-0005X9-It for emu@ietf.org; Tue, 03 Apr 2007 09:52:22 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l33DqI4q029394; Tue, 3 Apr 2007 15:52:18 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l33DqHql002522; Tue, 3 Apr 2007 15:52:18 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.165]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 15:52:17 +0200 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: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods Date: Tue, 3 Apr 2007 15:52:16 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E7019AD5E1@MCHP7R6A.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Re: Next Steps on Passwd-based EAP Methods Thread-Index: Acd17xYo6Oxjc0I2StOjD+Mp5uzrpgABy/KA From: "Tschofenig, Hannes" To: "Sam Hartman" , "Hannes Tschofenig" X-OriginalArrivalTime: 03 Apr 2007 13:52:17.0777 (UTC) FILETIME=[4AED0E10:01C775F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Tue, 03 Apr 2007 12:32:55 -0400 Cc: wpolk@nist.gov, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Sam,=20 > >>>>> "Hannes" =3D=3D Hannes Tschofenig=20 > writes: >=20 > Hannes> Hi all, before we spend more time considering EAP > Hannes> tunneling methods like PEAP and TTLS I would like to hear > Hannes> the opinion of our ADs on this subject. So far, the > Hannes> working assumption was that EAP methods that tunnel EAP > Hannes> are outside the scope of the working group. These > Hannes> statements were also repeated during the IETF#68 EMU WG > Hannes> meeting by our ADs. >=20 > I at least don't recall objecting to a tunnel method. If you're going > to do a tunnel method you do need cryptographic binding when tunneling > something that generates a key. I recall that you rejected the TTLS approach where we would have to add EAP support into TLS.=20 I am also happy to hear that you like providing EAP support in TLS.=20 >=20 > Bernard objected rather strongly to a tunneled method. I recall that as well. Now, he is in favor of it.=20 >=20 > Note that I am not saying you should go in the direction of a tunneled > method; a simple password over tls method is a fine approach.=20 For me as well.=20 > I just > don't recall me making an AD level objection to tunnels. I personally don't care which approach we pick as long as we stick with the same assumptions until the work is finished. For example, very early we said that this password based EAP method is not SRP-like work. I could imagine that someone suggests to reconsider that From emu-bounces@ietf.org Tue Apr 03 12:33:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYlwG-0008Mn-Ew; Tue, 03 Apr 2007 12:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjQs-0001HT-3z for emu@ietf.org; Tue, 03 Apr 2007 09:52:22 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYjQp-0005X9-It for emu@ietf.org; Tue, 03 Apr 2007 09:52:22 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l33DqI4q029394; Tue, 3 Apr 2007 15:52:18 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l33DqHql002522; Tue, 3 Apr 2007 15:52:18 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.165]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 15:52:17 +0200 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: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods Date: Tue, 3 Apr 2007 15:52:16 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E7019AD5E1@MCHP7R6A.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Re: Next Steps on Passwd-based EAP Methods Thread-Index: Acd17xYo6Oxjc0I2StOjD+Mp5uzrpgABy/KA From: "Tschofenig, Hannes" To: "Sam Hartman" , "Hannes Tschofenig" X-OriginalArrivalTime: 03 Apr 2007 13:52:17.0777 (UTC) FILETIME=[4AED0E10:01C775F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Tue, 03 Apr 2007 12:32:55 -0400 Cc: wpolk@nist.gov, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Sam,=20 > >>>>> "Hannes" =3D=3D Hannes Tschofenig=20 > writes: >=20 > Hannes> Hi all, before we spend more time considering EAP > Hannes> tunneling methods like PEAP and TTLS I would like to hear > Hannes> the opinion of our ADs on this subject. So far, the > Hannes> working assumption was that EAP methods that tunnel EAP > Hannes> are outside the scope of the working group. These > Hannes> statements were also repeated during the IETF#68 EMU WG > Hannes> meeting by our ADs. >=20 > I at least don't recall objecting to a tunnel method. If you're going > to do a tunnel method you do need cryptographic binding when tunneling > something that generates a key. I recall that you rejected the TTLS approach where we would have to add EAP support into TLS.=20 I am also happy to hear that you like providing EAP support in TLS.=20 >=20 > Bernard objected rather strongly to a tunneled method. I recall that as well. Now, he is in favor of it.=20 >=20 > Note that I am not saying you should go in the direction of a tunneled > method; a simple password over tls method is a fine approach.=20 For me as well.=20 > I just > don't recall me making an AD level objection to tunnels. I personally don't care which approach we pick as long as we stick with the same assumptions until the work is finished. For example, very early we said that this password based EAP method is not SRP-like work. I could imagine that someone suggests to reconsider that decision.=20 The rules are simple:=20 Different assumptions for the design =3D> Different protocols as output. = Changing the assumptions periodically =3D> Takes longer to complete the work Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 12:33:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYlwG-0008Ms-I3; Tue, 03 Apr 2007 12:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYlB7-0000Ln-Bo for emu@ietf.org; Tue, 03 Apr 2007 11:44:13 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYlAk-0005XP-TN for emu@ietf.org; Tue, 03 Apr 2007 11:44:13 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l33FhnTS009197; Tue, 3 Apr 2007 17:43:49 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l33FhnNc016326; Tue, 3 Apr 2007 17:43:49 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.165]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 17:43:49 +0200 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: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods Date: Tue, 3 Apr 2007 17:43:48 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E7019AD694@MCHP7R6A.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods Thread-Index: Acd2BmGjdfQ2EbNoRl6LhD3IdGkn9wAADx3w From: "Tschofenig, Hannes" To: "ext Sam Hartman" X-OriginalArrivalTime: 03 Apr 2007 15:43:49.0162 (UTC) FILETIME=[DF4D60A0:01C77606] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Tue, 03 Apr 2007 12:32:55 -0400 Cc: emu@ietf.org, wpolk@nist.gov X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org During the meeting the group said that they want to have a = password-based only approach (no tunneled EAP support). Even CHAP etc. = was left for future work, if ever done. For this purpose PAP over TLS + = room for extensibility is just good enough. Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: ext Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Gesendet: Dienstag, 3. April 2007 17:40 > An: Tschofenig, Hannes > Cc: Hannes Tschofenig; wpolk@nist.gov; emu@ietf.org > Betreff: Re: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods >=20 > >>>>> "Tschofenig," =3D=3D Tschofenig, Hannes=20 > writes: >=20 > Tschofenig,> Hi Sam, > >> >>>>> "Hannes" =3D=3D Hannes Tschofenig = > >> writes: > >>=20 > Hannes> Hi all, before we spend more time considering EAP > Hannes> tunneling methods like PEAP and TTLS I would like to hear > Hannes> the opinion of our ADs on this subject. So far, the > Hannes> working assumption was that EAP methods that tunnel EAP > Hannes> are outside the scope of the working group. These > Hannes> statements were also repeated during the IETF#68 EMU WG > Hannes> meeting by our decision.=20 The rules are simple:=20 Different assumptions for the design =3D> Different protocols as output. = Changing the assumptions periodically =3D> Takes longer to complete the work Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 12:33:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYlwG-0008Ms-I3; Tue, 03 Apr 2007 12:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYlB7-0000Ln-Bo for emu@ietf.org; Tue, 03 Apr 2007 11:44:13 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYlAk-0005XP-TN for emu@ietf.org; Tue, 03 Apr 2007 11:44:13 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l33FhnTS009197; Tue, 3 Apr 2007 17:43:49 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l33FhnNc016326; Tue, 3 Apr 2007 17:43:49 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.165]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 17:43:49 +0200 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: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods Date: Tue, 3 Apr 2007 17:43:48 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E7019AD694@MCHP7R6A.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods Thread-Index: Acd2BmGjdfQ2EbNoRl6LhD3IdGkn9wAADx3w From: "Tschofenig, Hannes" To: "ext Sam Hartman" X-OriginalArrivalTime: 03 Apr 2007 15:43:49.0162 (UTC) FILETIME=[DF4D60A0:01C77606] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Tue, 03 Apr 2007 12:32:55 -0400 Cc: emu@ietf.org, wpolk@nist.gov X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org During the meeting the group said that they want to have a = password-based only approach (no tunneled EAP support). Even CHAP etc. = was left for future work, if ever done. For this purpose PAP over TLS + = room for extensibility is just good enough. Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: ext Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Gesendet: Dienstag, 3. April 2007 17:40 > An: Tschofenig, Hannes > Cc: Hannes Tschofenig; wpolk@nist.gov; emu@ietf.org > Betreff: Re: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods >=20 > >>>>> "Tschofenig," =3D=3D Tschofenig, Hannes=20 > writes: >=20 > Tschofenig,> Hi Sam, > >> >>>>> "Hannes" =3D=3D Hannes Tschofenig = > >> writes: > >>=20 > Hannes> Hi all, before we spend more time considering EAP > Hannes> tunneling methods like PEAP and TTLS I would like to hear > Hannes> the opinion of our ADs on this subject. So far, the > Hannes> working assumption was that EAP methods that tunnel EAP > Hannes> are outside the scope of the working group. These > Hannes> statements were also repeated during the IETF#68 EMU WG > Hannes> meeting by our ADs. > >> I at least don't recall objecting to a tunnel method. If > >> you're going to do a tunnel method you do need cryptographic > >> binding when tunneling something that generates a key. >=20 > Tschofenig,> I recall that you rejected the TTLS approach where we > Tschofenig,> would have to add EAP support into TLS. I am also > Tschofenig,> happy to hear that you like providing EAP support in > Tschofenig,> TLS. >=20 > Yes, I reject that approach to tunnelsing. But you could for example > use the TLS application record protocol to tunnel EAP. >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ADs. > >> I at least don't recall objecting to a tunnel method. If > >> you're going to do a tunnel method you do need cryptographic > >> binding when tunneling something that generates a key. >=20 > Tschofenig,> I recall that you rejected the TTLS approach where we > Tschofenig,> would have to add EAP support into TLS. I am also > Tschofenig,> happy to hear that you like providing EAP support in > Tschofenig,> TLS. >=20 > Yes, I reject that approach to tunnelsing. But you could for example > use the TLS application record protocol to tunnel EAP. >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 12:40:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYm3C-0005H8-HX; Tue, 03 Apr 2007 12:40:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYm2n-0004tK-N7 for emu@ietf.org; Tue, 03 Apr 2007 12:39:41 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYloP-0000bb-5i for emu@ietf.org; Tue, 03 Apr 2007 12:24:52 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 3 Apr 2007 09:24:48 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.25; Tue, 3 Apr 2007 09:24:48 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Apr 2007 09:24:47 -0700 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: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods Date: Tue, 3 Apr 2007 09:24:01 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004ADE26E@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods Thread-Index: Acd2Bmtl2HTWv1y0TNOSUgXFgNIO8gAAEzWgAAFNgUA= References: From: Ryan Hurst To: Stephen Hanna , Sam Hartman , "Tschofenig, Hannes" X-OriginalArrivalTime: 03 Apr 2007 16:24:47.0868 (UTC) FILETIME=[98CE23C0:01C7760C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: wpolk@nist.gov, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Thanks Steve, that was my understanding also. Is it also true that there are no implementations of TTLSv1? Ryan=20 -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Tuesday, April 03, 2007 8:46 AM To: Sam Hartman; Tschofenig, Hannes Cc: wpolk@nist.gov; emu@ietf.org Subject: RE: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods FYI, EAP-TTLSv0 does not require any changes to the TLS handshake. Only EAP-TTLSv1 does. Thanks, Steve -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 Sent: Tuesday, April 03, 2007 11:40 AM To: Tschofenig, Hannes Cc: emu@ietf.org; wpolk@nist.gov Subject: Re: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods >>>>> "Tschofenig," =3D=3D Tschofenig, Hannes = writes: Tschofenig,> Hi Sam, >> >>>>> "Hannes" =3D=3D Hannes Tschofenig = >> writes: >>=20 Hannes> Hi all, before we spend more time considering EAP Hannes> tunneling methods like PEAP and TTLS I would like to hear Hannes> the opinion of our ADs on this subject. So far, the Hannes> working assumption was that EAP methods that tunnel EAP Hannes> are outside the scope of the working group. These Hannes> statements were also repeated during the IETF#68 EMU WG Hannes> meeting by our ADs. >> I at least don't recall objecting to a tunnel method. If >> you're going to do a tunnel method you do need cryptographic >> binding when tunneling something that generates a key. Tschofenig,> I recall that you rejected the TTLS approach where we Tschofenig,> would have to add EAP support into TLS. I am also Tschofenig,> happy to hear that you like providing EAP support in Tschofenig,> TLS. Yes, I reject that approach to tunnelsing. But you could for example use the TLS application record protocol to tunnel EAP. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 12:44:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYm74-0000ia-Tk; Tue, 03 Apr 2007 12:44:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYm74-0000iM-7w for emu@ietf.org; Tue, 03 Apr 2007 12:44:06 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYm71-0005bm-So for emu@ietf.org; Tue, 03 Apr 2007 12:44:06 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 3 Apr 2007 09:44:03 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Tue, 3 Apr 2007 09:44:02 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Apr 2007 09:44:02 -0700 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: [Emu] Thoughts on Password-based EAP Methods Date: Tue, 3 Apr 2007 09:43:22 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004ADE28A@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Thoughts on Password-based EAP Methods Thread-Index: Acd1eLJ4rcfb6ubPRKyrmX8KD8SaPgAiZwTAAAMeS4A= References: From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , Bernard Aboba , X-OriginalArrivalTime: 03 Apr 2007 16:44:02.0154 (UTC) FILETIME=[48D034A0:01C7760F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I can easily see how crypto-binding could be added to the protocol without breaking backwards compatibility, eg how negotiation via TTLSv0's extensibility model could add this in as a optional operation that the client and server agree upon. In general I think having a standards based, interoperable tunneling method would be good for customers and the industry and TTLSv0 appears clean enough, and pretty broadly adopted so using it as the basis of work in this area looks like a good idea to me. Ryan -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Tuesday, April 03, 2007 8:16 AM To: Bernard Aboba; emu@ietf.org Subject: RE: [Emu] Thoughts on Password-based EAP Methods Some of the things that need to be fixed are fairly fundamental. For example crypto-binding and avoiding multiple layers of negotiation are fairly fundamental. At this point I'm not sure that modifying TLVs is the best way to achieve this. It needs to be investigated. =20 Joe > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Monday, April 02, 2007 3:46 PM > To: emu@ietf.org > Subject: RE: [Emu] Thoughts on Password-based EAP Methods >=20 > >I'm not sure that adding yet another version to TTLS=20 > specifically for=20 > >supporting passwords will make things better for customers. =20 > Multiple=20 > >versions certainly has caused quite a confusion in PEAP. >=20 > I would agree that "versioning" is not a good idea. However,=20 > as I understand it, EAP-TTLSv0 is the only deployed version=20 > of TTLS; v1 has never=20 > been implemented. So currently there is no versioning issue=20 > with TTLS, and=20 > if possible, it would be best if the IETF would not create=20 > such a problem. >=20 > It is not clear to me that EAP-TTLS needs "versioning" in=20 > order to enable addition of new features in a backwards=20 > compatible way, since it already supports a TLV-based=20 > extension mechanism. >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 13:25:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmlN-0006IK-55; Tue, 03 Apr 2007 13:25:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmlL-0006IE-Sb for emu@ietf.org; Tue, 03 Apr 2007 13:25:43 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYmlH-0002Sk-F1 for emu@ietf.org; Tue, 03 Apr 2007 13:25:43 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 03 Apr 2007 10:25:39 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l33HPcsp024633; Tue, 3 Apr 2007 10:25:38 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l33HPcMF007828; Tue, 3 Apr 2007 17:25:38 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 10:25:38 -0700 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: [Emu] Re: Thoughts on Password-based EAP Methods Date: Tue, 3 Apr 2007 10:25:37 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262503B747D2@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Re: Thoughts on Password-based EAP Methods Thread-Index: Acd1eDzhdPRll8axTnqTvpkGlESiAwAnGRGA References: <46117F74.5070808@gmx.net> From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" X-OriginalArrivalTime: 03 Apr 2007 17:25:38.0608 (UTC) FILETIME=[18D0DB00:01C77615] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1029; t=1175621138; x=1176485138; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Emu]=20Re=3A=20Thoughts=20on=20Password-based=20EAP= 20Methods |Sender:=20; bh=UoEr3WD01P22riWaNhJraKq7eT6MhkMmw7ggZ4qqa0E=; b=WUsUbJXzR6MMWQjsY5YnTf38MtJl37sS/uNzL/OR0XPBgkmHgPlpfOiYvLqHiSOUYIl/4a/m oyXruWRzKe4q2qmI7IvUEK44A7YaIhRmMGRdxuhk46Ry0LZLKTE3AW4s; Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Bernard Aboba allegedly scribbled on Monday, April 02, 2007 3:42 PM: >> Part of the problem with EAP methods is that people should have >> started to standardize them within the IETF several years ago. >> Unfortunately, there was no interest by some of the EAP method >> authors nor from the EAP WG chairs to allow that. >=20 > In fact, the IETF was on track to standardize EAP methods back as > recently as 2001, within the PPPEXT WG. It was as part of that > program that EAP-TLS was first published as an Experimental RFC, and > EAP-TTLSv0 was put on the standards track. =20 >=20 > The decision to remove standards track EAP methods from the PPPEXT WG > charter was made by the IESG, not by the authors of EAP methods, or > the EAP WG chairs. As I recall, there was considerable opposition to > that decision at the time. =20 I was in favor of it at the time, as I recall; however, I imagined that the project would move to the EAP WG, not drop into a black hole. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 15:21:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYoZN-0007vG-21; Tue, 03 Apr 2007 15:21:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYoZL-0007v2-Ql for emu@ietf.org; Tue, 03 Apr 2007 15:21:27 -0400 Received: from bay0-omc2-s25.bay0.hotmail.com ([65.54.246.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYoZK-0004uR-8c for emu@ietf.org; Tue, 03 Apr 2007 15:21:27 -0400 Received: from hotmail.com ([207.46.8.109]) by bay0-omc2-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 3 Apr 2007 12:21:25 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Apr 2007 12:21:25 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 03 Apr 2007 19:21:20 GMT X-Originating-IP: [131.107.0.74] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E7019AD694@MCHP7R6A.ww002.siemens.net> From: "Bernard Aboba" To: emu@ietf.org Bcc: Date: Tue, 03 Apr 2007 12:21:20 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 03 Apr 2007 19:21:25.0420 (UTC) FILETIME=[45703EC0:01C77625] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Emu] Re: Next Steps on Passwd-based EAP Methods X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >During the meeting the group said that they want to have a password-based >only approach (no >tunneled EAP support). Even CHAP etc. was left for >future work, if ever done. For this purpose >PAP over TLS + room for >extensibility is just good enough. FWIW, EAP-TTLSv0 does support non-EAP authentication as well as tunneling. This includes support for PAP, CHAP, MS-CHAP and MS-CHAPv2. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 15:34:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYolx-0000Ni-GD; Tue, 03 Apr 2007 15:34:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYolw-0000NY-2d for emu@ietf.org; Tue, 03 Apr 2007 15:34:28 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYols-0007Rj-QZ for emu@ietf.org; Tue, 03 Apr 2007 15:34:28 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 03 Apr 2007 12:34:24 -0700 X-IronPort-AV: i="4.14,366,1170662400"; d="scan'208"; a="701871211:sNHT34108748" 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: [Emu] Thoughts on Password-based EAP Methods Date: Tue, 3 Apr 2007 15:34:24 -0400 Message-ID: In-Reply-To: <20070403020714.GT16197@jm.kir.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Thoughts on Password-based EAP Methods Thread-Index: Acd1lQDn23QCdBCWQEe1QmZXcxlbfwAj9dgw From: "Stephen Hanna" To: "Jouni Malinen" , "Bernard Aboba" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Jouni Malinen wrote: > I'm aware of at least one, though maybe partial, implementation of > TTLSv1. Anyway, I don't think it has been deployed anywhere. I talked to Paul Funk about this. He hasn't implemented EAP-TTLSv1, is not planning to do so, and is not aware of any implementations or deployments of that protocol. Also, Pascal asked about a patent application. I asked Paul about that and he said it isn't about EAP-TTLS. Thanks, Steve _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 15:56:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYp7A-0001MS-7Z; Tue, 03 Apr 2007 15:56:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYp79-0001ML-Aw for emu@ietf.org; Tue, 03 Apr 2007 15:56:23 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYp74-0004ze-RG for emu@ietf.org; Tue, 03 Apr 2007 15:56:23 -0400 Received: (qmail invoked by alias); 03 Apr 2007 19:56:17 -0000 Received: from p54984833.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.72.51] by mail.gmx.net (mp027) with SMTP; 03 Apr 2007 21:56:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/bdHYgdM3bCEGSaRWicvIqryG2yq80M/llEjfHlj 2x9QYUJLZc03En Message-ID: <4612B160.1050309@gmx.net> Date: Tue, 03 Apr 2007 21:56:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [Emu] Password-Based EAP Method: Proposal to Move Forward X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi all, I went through TTLSv0, through the EAP Passwd-based DT and my notes from the EMU IETF#68 meeting. Here is a short summary: * Within the Design Team we have investigated different EAP methods including the ability to carry EAP payloads, CHAP, MS-CHAP and MS-CHAP-V2 in addition to PAP. Within the design team we were not sure about the approach we should take. Hence, we solicited feedback from the EMU working group. See http://www1.ietf.org/mail-archive/web/emu/current/msg00394.html As part of the design team work a strawman proposal was compiled. Please find it at: http://www.tschofenig.com/svn/draft-zhou-emu-pp-eap/draft-zhou-emu-pp-eap-00.txt * At the IETF#68 EMU WG meeting (see http://www3.ietf.org/proceedings/07mar/slides/emu-3.ppt) a number of questions were asked and the following feedback was provided (based on my notes): - Protected result indication: Indicated that it is required. - Channel Binding: Sam indicated that this is required due to the Housley criteria. - Password Pin/ changes: Provided as an extension. - CHAP, MS-CHAP, MS-CHAP-V2 Support: Provided as an extension. - EAP Support: Provided as an extension - Crypto-Binding: Indication that Crypto-Binding should be added to the base specification even though it is not required for PAP. Removing CHAP, MS-CHAP, MS-CHAPv2 from draft-zhou-emu-pp-eap-00.txt makes it obviously quite similar to http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt (when CHAP, MS-CHAP, MS-CHAPv2, EAP is removed and Crypto-Binding added). This is not a big surprise given that there are only finite ways to encode packets carried on top of EAP-TLS. Taking an existing document and removing some parts, rewriting other parts and adding some section OR creating a new document by adding content from other documents is not a big difference. Here is my conclusion and a suggestion to move forward: * The EAP-TLS part would be based on http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-08.txt * Add a crypto-binding similar to the one defined in http://www.tschofenig.com/svn/draft-zhou-emu-pp-eap/draft-zhou-emu-pp-eap-00.txt * Use the MSK/EMSK generation from http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-08.txt http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt does not generate an EMSK -- this needs to be added since it is mandatory. Unfortunately, the details with regard to the MSK generation in http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-08.txt are different to http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt . * Packet format: We could make use of the packet format defined in Section 9 of http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt (that is based on Diameter). Section 8 of http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt when we base our work on the recent EAP-TLS work. We would duplicate the EAP-TLS work if we were to include Section 8 and create inconsistency. * Add protected results indication as requested * Add channel binding as requested The question is just which approach. --- stop here for the base document // something for discussion --- * Define an extension for EAP usage in a separate document (including the multiple authentication concept), if someone wants it. This at least reflects what most people wanted at the meeting. In some sense this is a pure document handling aspect. For multiple authentication EAP runs it would be necessary to apply multiple crypto-bindings. For the crypto-binding to work it would be necessary for EAP-TLS to export keying material. EAP-TTLSv0 does not address this aspect. CONCLUSION: Does this address Bernard's concern " In my discussions with customers, I invariably hear complaints about this explosion, and about various interoperability and compatibility problems that it causes. Simply put, customers do not want "yet another password-based EAP method"; they want a single method that is widely implemented and interoperable. " ? I don't know. It depends where the interoperability and compatibility problems come from. Is an EAP method that is based on a previous one with enhancements reflecting the state-of-the-art a new protocol or not? Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 20:17:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYtBo-0006xv-9R; Tue, 03 Apr 2007 20:17:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYtBn-0006xq-8V for emu@ietf.org; Tue, 03 Apr 2007 20:17:27 -0400 Received: from bay0-omc2-s5.bay0.hotmail.com ([65.54.246.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYtBk-0007ot-UY for emu@ietf.org; Tue, 03 Apr 2007 20:17:27 -0400 Received: from hotmail.com ([207.46.8.83]) by bay0-omc2-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 3 Apr 2007 17:17:24 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Apr 2007 17:17:24 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 04 Apr 2007 00:17:21 GMT X-Originating-IP: [131.107.0.74] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: RE: [Emu] Thoughts on Password-based EAP Methods Date: Tue, 03 Apr 2007 17:17:21 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 Apr 2007 00:17:24.0086 (UTC) FILETIME=[9E6DA160:01C7764E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >Also, Pascal asked about a patent application. I asked Paul about >that and he said it isn't about EAP-TTLS. Searching the IETF IPR page, I found the following disclosure, which relates to TLS-IA, and therefore is only relevant to EAP-TTLSv1: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=594 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 03 20:38:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYtVq-0007Rc-6b; Tue, 03 Apr 2007 20:38:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYtUN-0006uZ-BH for emu@ietf.org; Tue, 03 Apr 2007 20:36:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYtUM-0002sq-2F for emu@ietf.org; Tue, 03 Apr 2007 20:36:39 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2007 17:36:37 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l340ab4N031558 for ; Tue, 3 Apr 2007 17:36:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l340aMFE021969 for ; Wed, 4 Apr 2007 00:36:37 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 17:36:26 -0700 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 Date: Tue, 3 Apr 2007 17:36:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Password based method Thread-Index: Acd2UUGXT0FFD3WFQqasNdrEqbNg2w== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 04 Apr 2007 00:36:26.0699 (UTC) FILETIME=[477A89B0:01C77651] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=241; t=1175646997; x=1176510997; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20Password=20based=20method |Sender:=20; bh=x93UKAzZPlelf8RLuEVzyM2OPnwC9jYJEI2XF6qewDA=; b=KReLAXg2j2VeupC7pLWrVPDGxkv0rltXsdSRsn1r8lZq4lcn3yKBSorZ83Hs3U24GdS0EKba T8gBYchdgGs5gzrCybEwJoaXEaAA/3fhMXNbL2VF4f9wZMGm9TkarOY6; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-Mailman-Approved-At: Tue, 03 Apr 2007 20:38:08 -0400 Subject: [Emu] Password based method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I would recommend that the design team put together a draft that can be evaluated against other options if they are generated. The draft should strive to meet the requirements and be simple. I think we already have a good start. Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 06 03:07:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZiXa-0004tE-Eo; Fri, 06 Apr 2007 03:07:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZiXZ-0004t9-L8 for emu@ietf.org; Fri, 06 Apr 2007 03:07:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZiXY-0005wM-7u for emu@ietf.org; Fri, 06 Apr 2007 03:07:21 -0400 Received: (qmail invoked by alias); 06 Apr 2007 07:07:15 -0000 Received: from ip-90-186-62-69.web.vodafone.de (EHLO [90.186.62.69]) [90.186.62.69] by mail.gmx.net (mp048) with SMTP; 06 Apr 2007 09:07:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+SepVgHrSSzgpl+QbXmWSPNQkyzIN1QRTjI7aAlb B11/f8SelFawcF Message-ID: <4615F19F.7040004@gmx.net> Date: Fri, 06 Apr 2007 09:07:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Emu] EAP-GPSK: Feedback Solicited X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi all, we have submitted a new EAP-GPSK draft version: http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-05.txt ChangeLog: - references fixes identified by idnits - spell check found a couple misspelled words - replaced Hash with MAC - fixed key length KDF output for HMAC ciphersuite - removed MID references, replaced with Method-ID Please take a look at it to ensure that we made the changes requested at the IETF#68 EMU meeting. Provide your comments by April, 23rd to allow our chair to continue with the publication process. Ciao Hannes & Charles _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 06 13:29:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZsFN-0002z3-Ck; Fri, 06 Apr 2007 13:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZsFL-0002ye-Sb for emu@ietf.org; Fri, 06 Apr 2007 13:29:11 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZsFH-0006uo-Dl; Fri, 06 Apr 2007 13:29:11 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 6 Apr 2007 10:29:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.25; Fri, 6 Apr 2007 10:29:06 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Apr 2007 10:29:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Apr 2007 10:28:45 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004B82F6A@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Talk on Windows EAP implementation... Thread-Index: Acd4cQeg/yf6zV81SPqizGMsWra3oQ== From: Ryan Hurst To: , X-OriginalArrivalTime: 06 Apr 2007 17:29:06.0561 (UTC) FILETIME=[14013710:01C77871] X-Spam-Score: 1.4 (+) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: Subject: [Emu] Talk on Windows EAP implementation... X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1800031155==" Errors-To: emu-bounces@ietf.org --===============1800031155== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77871.080F6525" ------_=_NextPart_001_01C77871.080F6525 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I thought folks on these two lists might be interested in this, Microsoft will be having a web chat next week discussing its EAP platform if you want to know more about our implementation and how you can integrate with it this is probably a interesting talk. =20 See: http://blogs.technet.com/nap/archive/2007/04/05/eaphost-and-eap-methods- in-windows-vista-and-longhorn.aspx =20 Ryan =20 =20 ------_=_NextPart_001_01C77871.080F6525 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I = thought folks on these two lists might be interested in this, Microsoft will be having a = web chat next week discussing its EAP platform if you want to know more = about our implementation and how you can integrate with it this is probably a = interesting talk.

 

See: = http://blogs.technet.com/nap/a= rchive/2007/04/05/eaphost-and-eap-methods-in-windows-vista-and-longhorn.a= spx

 

Ryan

 

 

------_=_NextPart_001_01C77871.080F6525-- --===============1800031155== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1800031155==-- From emu-bounces@ietf.org Fri Apr 06 13:43:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZsTF-000540-DJ; Fri, 06 Apr 2007 13:43:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZsTD-00053r-TG; Fri, 06 Apr 2007 13:43:31 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZsTC-0001RR-5M; Fri, 06 Apr 2007 13:43:31 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 90108E0433; Fri, 6 Apr 2007 13:43:29 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org Date: Fri, 06 Apr 2007 13:43:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: bernarda@microsoft.com, emu@ietf.org, nicolas.williams@sun.com Subject: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi. For the last couple of years, we've been believing that EAP and GSS used the term channel bindings inconsistently. For those of us dealing with both, it's been a bit annoying. I've been thinking about EAP a lot lately. and have come to the conclusion that actually the terms are used consistently. I'd like to see if people agree with the following change to Nico's channel binding draft: old: Also unfortunately there is a conflict with the Extensible Authentication Protocol (EAP) [RFC3748] which uses "channel binding" to refer to a facility that is subtly different from the one described here. (It does not seem feasible to adopt new terminology to avoid these problems now. The GSS-API, NFSv4 and other communities have been using the terms "channel binding" and "channel bindings" in these ways for a long time, sometimes with variations such as "channel binding facility" and so on.) new: The Extensible Authentication Protocol (EAP) [RFC3748] includes two facilities related to channel binding. The first, called channel binding, is used to bind the lower-layer channel created between the peer and the authenticator to the authentication performed using EAP. Specific detials of this facility have not been specified, but it is likely that this channel would use endpoint channel bindings carried in the EAP method exchange. The endpoint channel bindings would be defined for the specific lower layer. EAP also has a facility called cryptographic binding, which is another instance of channel binding. Cryptographic binding refers to binding the channel created by a tunneling EAP method to an inner authentication performed within that method. Cryptographic binding will likely use unique channel bindings. Do these changes make sense to people? Am I telling any lies or conflating two architectures in a bad way? _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 06 14:26:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZt8Z-0007xN-6j; Fri, 06 Apr 2007 14:26:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZt8V-0007xH-DP for emu@ietf.org; Fri, 06 Apr 2007 14:26:11 -0400 Received: from mail7.sea5.speakeasy.net ([69.17.117.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZt8T-0004Y8-4j for emu@ietf.org; Fri, 06 Apr 2007 14:26:11 -0400 Received: (qmail 25258 invoked from network); 6 Apr 2007 18:26:05 -0000 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net (HELO jm) ([69.17.49.110]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Apr 2007 18:26:05 -0000 Received: by jm (sSMTP sendmail emulation); Fri, 6 Apr 2007 11:25:14 -0700 Date: Fri, 6 Apr 2007 11:25:14 -0700 From: Jouni Malinen To: Hannes Tschofenig Subject: Re: [Emu] EAP-GPSK: Feedback Solicited Message-ID: <20070406182514.GD16197@jm.kir.nu> References: <4615F19F.7040004@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4615F19F.7040004@gmx.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Fri, Apr 06, 2007 at 09:07:11AM +0200, Hannes Tschofenig wrote: > http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-05.txt > ChangeLog: > - replaced Hash with MAC If I understood the change correctly, GKDF-X(Y, Z) is now using AES-128-CMAC if ciphersuite #1 is used. This would require 16-octet key (Y), but the values passed into GKDF in 6.1.3 are of 1 octet (0x00) and 32 octets (MK). How is this supposed to work? -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 06 14:41:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtN3-00088S-UZ; Fri, 06 Apr 2007 14:41:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtN3-00088F-2u; Fri, 06 Apr 2007 14:41:13 -0400 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZtN1-0007QV-Pp; Fri, 06 Apr 2007 14:41:13 -0400 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l36If9sp013297; Fri, 6 Apr 2007 14:41:09 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id l36If9RQ013295; Fri, 6 Apr 2007 14:41:09 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Fri, 6 Apr 2007 14:41:09 -0400 (EDT) Message-ID: <43960.63.239.69.1.1175884869.squirrel@webmail.cs.umd.edu> In-Reply-To: References: Date: Fri, 6 Apr 2007 14:41:09 -0400 (EDT) Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings From: "Charles Clancy" To: "Sam Hartman" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: bernarda@microsoft.com, ietf@ietf.org, nicolas.williams@sun.com, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Sam, In skimming through Nico's draft, it looks like EAP's crypto bindings look something like GSS channel bindings. EAP's channel bindings, on the other hand, don't really look like GSS channel bindings. In order for EAP's channel binding to look like GSS channel binding, EAP channel binding would have to cryptographically bind an L2 security association to EAP keys -- but that's not what it's doing. It's binding L2 identities to EAP keys. In fact, there's no reason it has to be an L2 identity. It can be any identity that's meaningful to the parties involved, and can serve as the basis for making authorization decisions. Perhaps you could abstract the definition of channel bindings even further such that all three are subsets of some common terminology... but that sounds painful. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy On Fri, April 6, 2007 1:43 pm, Sam Hartman wrote: > > > > Hi. > > For the last couple of years, we've been believing that EAP and GSS > used the term channel bindings inconsistently. For those of us > dealing with both, it's been a bit annoying. > > I've been thinking about EAP a lot lately. and have come to the > conclusion that actually the terms are used consistently. > > I'd like to see if people agree with the following change to Nico's > channel binding draft: > > old: > > Also unfortunately there is a conflict with the Extensible > Authentication Protocol (EAP) [RFC3748] which uses "channel binding" > to refer to a facility that is subtly different from the one > described here. (It does not seem feasible to adopt new terminology > to avoid these problems now. The GSS-API, NFSv4 and other > communities have been using the terms "channel binding" and "channel > bindings" in these ways for a long time, sometimes with variations > such as "channel binding facility" and so on.) > > new: > > The Extensible Authentication Protocol (EAP) [RFC3748] includes two > facilities related to channel binding. The first, called channel > binding, is used to bind the lower-layer channel created between the > peer and the authenticator to the authentication performed using EAP. > Specific detials of this facility have not been specified, but it is > likely that this channel would use endpoint channel bindings carried > in the EAP method exchange. The endpoint channel bindings would be > defined for the specific lower layer. EAP also has a facility called > cryptographic binding, which is another instance of channel binding. > Cryptographic binding refers to binding the channel created by a > tunneling EAP method to an inner authentication performed within that > method. Cryptographic binding will likely use unique channel > bindings. > > Do these changes make sense to people? Am I telling any lies or > conflating two architectures in a bad way? > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 06 14:46:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtSF-0003q3-Dg; Fri, 06 Apr 2007 14:46:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtSE-0003pw-Ab for emu@ietf.org; Fri, 06 Apr 2007 14:46:34 -0400 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZtSD-0008PK-2p for emu@ietf.org; Fri, 06 Apr 2007 14:46:34 -0400 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l36IkVlZ013593; Fri, 6 Apr 2007 14:46:31 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id l36IkV9o013591; Fri, 6 Apr 2007 14:46:31 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Fri, 6 Apr 2007 14:46:31 -0400 (EDT) Message-ID: <60302.63.239.69.1.1175885191.squirrel@webmail.cs.umd.edu> In-Reply-To: <20070406182514.GD16197@jm.kir.nu> References: <4615F19F.7040004@gmx.net> <20070406182514.GD16197@jm.kir.nu> Date: Fri, 6 Apr 2007 14:46:31 -0400 (EDT) Subject: Re: [Emu] EAP-GPSK: Feedback Solicited From: "Charles Clancy" To: "Jouni Malinen" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Hannes Tschofenig , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Jouni, Good catch -- 0x00 should be 16 octets long and MK should be generated from GKDF-16 instead. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy On Fri, April 6, 2007 2:25 pm, Jouni Malinen wrote: > On Fri, Apr 06, 2007 at 09:07:11AM +0200, Hannes Tschofenig wrote: > >> http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-05.txt >> ChangeLog: >> - replaced Hash with MAC > > If I understood the change correctly, GKDF-X(Y, Z) is now using > AES-128-CMAC if ciphersuite #1 is used. This would require 16-octet key > (Y), but the values passed into GKDF in 6.1.3 are of 1 octet (0x00) and > 32 octets (MK). How is this supposed to work? > > -- > Jouni Malinen PGP id EFC895FA > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 06 15:13:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtrv-0005A8-Lg; Fri, 06 Apr 2007 15:13:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtru-00059e-0K; Fri, 06 Apr 2007 15:13:06 -0400 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZtrs-0004t8-OC; Fri, 06 Apr 2007 15:13:05 -0400 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l36JD4FL016727; Fri, 6 Apr 2007 15:13:04 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id l36JD4v9016725; Fri, 6 Apr 2007 15:13:04 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Fri, 6 Apr 2007 15:13:04 -0400 (EDT) Message-ID: <33203.63.239.69.1.1175886784.squirrel@webmail.cs.umd.edu> In-Reply-To: <20070406184854.GL28748@Sun.COM> References: <43960.63.239.69.1.1175884869.squirrel@webmail.cs.umd.edu> <20070406184854.GL28748@Sun.COM> Date: Fri, 6 Apr 2007 15:13:04 -0400 (EDT) Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings From: "Charles Clancy" To: "Nicolas Williams" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: bernarda@microsoft.com, Sam Hartman , ietf@ietf.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >> to be an L2 identity. It can be any identity that's meaningful to the >> parties involved, and can serve as the basis for making authorization >> decisions. > > As long as it's cryptographically bound to the L2 channel and that > channel provides suitable protection for the EAP method doing the EAP > channel binding, THEN Sam's observation is correct: "EAP channel > binding" uses what I termed "end-point channel binding" and "EAP > cryptographic binding" uses what I termed "unique channel binding." I don't think I'm convinced that EAP channel bindings are doing this binding to the L2 channel. The identity used in an EAP channel binding must be bound to the AAA security association between the authenticator and the peer in order for everything to work, so it would be more likely a NAS-ID than a MAC address. That's not to say there isn't an L2 binding happening -- but I think it's being performed by the L2 secure association phase that uses the EAP key to derive L2 keys. Then during that handshake, a MAC address may be involved, binding in an L2 identity. I guess I see EAP channel bindings as an EAP<->AAA binding, and the L2 secure association protocol as the EAP<->L2 binding. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 06 15:50:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZuRi-0001ri-SV; Fri, 06 Apr 2007 15:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZuRf-0001c7-Cm; Fri, 06 Apr 2007 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZuRe-0005Bf-Om; Fri, 06 Apr 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B544C329A0; Fri, 6 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HZuRe-0005mr-Iq; Fri, 06 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 06 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-05.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : EAP Generalized Pre-Shared Key (EAP-GPSK) Author(s) : C. Clancy, H. Tschofenig Filename : draft-ietf-emu-eap-gpsk-05.txt Pages : 34 Date : 2007-4-6 This Internet Draft defines an Extensible Authentication Protocol method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-emu-eap-gpsk-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-emu-eap-gpsk-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-6140034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-emu-eap-gpsk-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-emu-eap-gpsk-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-6140034.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Fri Apr 06 16:11:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZumb-0000mF-Bk; Fri, 06 Apr 2007 16:11:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZuma-0000i7-8B; Fri, 06 Apr 2007 16:11:40 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZumX-0004Jy-Dk; Fri, 06 Apr 2007 16:11:40 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0D169E0431; Fri, 6 Apr 2007 16:11:36 -0400 (EDT) From: Sam Hartman To: "Charles Clancy" Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings References: <43960.63.239.69.1.1175884869.squirrel@webmail.cs.umd.edu> <20070406184854.GL28748@Sun.COM> <33203.63.239.69.1.1175886784.squirrel@webmail.cs.umd.edu> Date: Fri, 06 Apr 2007 16:11:36 -0400 In-Reply-To: <33203.63.239.69.1.1175886784.squirrel@webmail.cs.umd.edu> (Charles Clancy's message of "Fri, 6 Apr 2007 15:13:04 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.6 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: bernarda@microsoft.com, ietf@ietf.org, Nicolas Williams , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >>>>> "Charles" == Charles Clancy writes: >>> to be an L2 identity. It can be any identity that's >>> meaningful to the parties involved, and can serve as the basis >>> for making authorization decisions. >> As long as it's cryptographically bound to the L2 channel and >> that channel provides suitable protection for the EAP method >> doing the EAP channel binding, THEN Sam's observation is >> correct: "EAP channel binding" uses what I termed "end-point >> channel binding" and "EAP cryptographic binding" uses what I >> termed "unique channel binding." Charles> I don't think I'm convinced that EAP channel bindings are Charles> doing this binding to the L2 channel. The identity used Charles> in an EAP channel binding must be bound to the AAA Charles> security association between the authenticator and the Charles> peer in order for everything to work, so it would be more I'm not sure I'd describe the association between the peer and authenticator as an AAA association. I agree with the rest. Charles> Charles> likely a NAS-ID than a MAC address. Are you sure that the binding happens between the mac address and NAS ID? I don't understand how the peer ever confirms the NAS ID at layer two unless it also happens to be a MAC address. I do agree with you though that EAP channel bindings include the peer's lower layer identity and the identity of the authenticator that the peer will later be able to verify. Charles> That's not to say there isn't an L2 binding happening -- Charles> but I think it's being performed by the L2 secure Charles> association phase that uses the EAP key to derive L2 Charles> keys. Then during that handshake, a MAC address may be Charles> involved, binding in an L2 identity. ANd if things are secure some L2 identity of the authenticator. Charles> I guess I see EAP channel bindings as an EAP<->AAA Charles> binding, and the L2 secure association protocol as the Charles> EAP<->L2 binding. The L2 secure association protocol cannot be an eap->anything binding: it does not typically use EAP level identifiers. Charles> -- t. charles clancy, ph.d. <> tcc@umd.edu <> Charles> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 06 16:13:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZuom-0003Ym-S3; Fri, 06 Apr 2007 16:13:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZuok-0003Oe-OO; Fri, 06 Apr 2007 16:13:54 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZuoj-0005sI-Hw; Fri, 06 Apr 2007 16:13:54 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7E190E0431; Fri, 6 Apr 2007 16:13:46 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <20070406190619.GM28748@Sun.COM> Date: Fri, 06 Apr 2007 16:13:46 -0400 In-Reply-To: <20070406190619.GM28748@Sun.COM> (Nicolas Williams's message of "Fri, 6 Apr 2007 14:06:20 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: bernarda@microsoft.com, ietf@ietf.org, emu@ietf.org Subject: [Emu] Re: Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Also, I think my draft's definition of "end-point channel Nicolas> bidning" needs to be tightened just a bit: not only must Nicolas> the end-point IDs be cryptographically bound into the Nicolas> channel, it must also be the case that the IDs Nicolas> meaningfully identify the channel end-points -- that is, Nicolas> that one nodes cannot assert the same ID as another Nicolas> without sharing credentials with it. I think my text Nicolas> implies this but does not make it sufficiently explicit. Be careful. A DN given a trust anchor seems like a find end-point identifier. However two nodes can share the same DN without sharing the same credential. Under 3280 rules either the CA issued a certificate it should not have issued or the two nodes are the same subject. That's strong enough for the channel binding to be useful even though the nodes may not share a credential. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 06 16:37:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZvBo-0002Hj-03; Fri, 06 Apr 2007 16:37:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZvBn-0002Hb-3w; Fri, 06 Apr 2007 16:37:43 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZvBi-0003nA-Od; Fri, 06 Apr 2007 16:37:43 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 6 Apr 2007 13:37:38 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Fri, 6 Apr 2007 13:37:36 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Apr 2007 13:37:36 -0700 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: [Emu] Re: Last call comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings Date: Fri, 6 Apr 2007 13:37:17 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004B8315F@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Re: Last call comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings Thread-Index: Acd4iB/UICm7gbmOSTGZEevMNa0DKgAAvIUw References: <20070406190619.GM28748@Sun.COM> From: Ryan Hurst To: Sam Hartman , Nicolas Williams X-OriginalArrivalTime: 06 Apr 2007 20:37:36.0421 (UTC) FILETIME=[6934E550:01C7788B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: emu@ietf.org, Bernard Aboba , ietf@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Yup, specifically 3280 says that a issuer, as represented by its DN will guarantee unique serial numbers within its scope and issue within its scope non-ambiguous subject DNs (e.g. no dupes). -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 Sent: Friday, April 06, 2007 1:14 PM To: Nicolas Williams Cc: Bernard Aboba; ietf@ietf.org; emu@ietf.org Subject: [Emu] Re: Last call comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings >>>>> "Nicolas" =3D=3D Nicolas Williams = writes: Nicolas> Also, I think my draft's definition of "end-point channel Nicolas> bidning" needs to be tightened just a bit: not only must Nicolas> the end-point IDs be cryptographically bound into the Nicolas> channel, it must also be the case that the IDs Nicolas> meaningfully identify the channel end-points -- that is, Nicolas> that one nodes cannot assert the same ID as another Nicolas> without sharing credentials with it. I think my text Nicolas> implies this but does not make it sufficiently explicit. Be careful. A DN given a trust anchor seems like a find end-point identifier. However two nodes can share the same DN without sharing the same credential. Under 3280 rules either the CA issued a certificate it should not have issued or the two nodes are the same subject. That's strong enough for the channel binding to be useful even though the nodes may not share a credential. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Apr 07 03:15:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha58Z-0001dC-5w; Sat, 07 Apr 2007 03:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha58Y-0001d6-39 for emu@ietf.org; Sat, 07 Apr 2007 03:15:02 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha58W-0002wx-H7; Sat, 07 Apr 2007 03:15:02 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 07 Apr 2007 00:15:00 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l377Exea011175; Sat, 7 Apr 2007 00:14:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l377Exwn019772; Sat, 7 Apr 2007 07:14:59 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 00:14:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] Talk on Windows EAP implementation... Date: Sat, 7 Apr 2007 00:14:56 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262503BE14B3@xmb-sjc-215.amer.cisco.com> In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004B82F6A@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Talk on Windows EAP implementation... Thread-Index: Acd4cQeg/yf6zV81SPqizGMsWra3oQAcz89g References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004B82F6A@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: "Glen Zorn \(gwz\)" To: "Ryan Hurst" X-OriginalArrivalTime: 07 Apr 2007 07:14:59.0292 (UTC) FILETIME=[73BBE9C0:01C778E4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6993; t=1175930099; x=1176794099; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Emu]=20Talk=20on=20Windows=20EAP=20implementation... |Sender:=20; bh=v7B74XMBLNbD/x73FtgTbzWNK7D+KO1wI+3V9icw5mk=; b=cHfxNfWkvQ1A31HRgXq27cFftgtmP4sOwql9NzBFjiIQllHPE0cQgEX3JA0dCIO7wPyhYSPz bWgkOFA+wSssIyWBiDwZDh4AHB4sTQC+UaD1e5NwvmIHDfo0QRtieZ7z; Authentication-Results: sj-dkim-5; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 1.4 (+) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: eap@ietf.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2115475060==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============2115475060== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C778E4.736FDD95" This is a multi-part message in MIME format. ------_=_NextPart_001_01C778E4.736FDD95 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I thought folks on these two lists might be interested in this, Microsoft will be having a web chat next week discussing its EAP platform if you want to know more about our implementation and how you can integrate with it this is probably a interesting talk. =20 See: http://blogs.technet.com/nap/archive/2007/04/05/eaphost-and-eap-methods- in-windows-vista-and-longhorn.aspx =20 That page says that the chat begins @ 3:00 PM Pacific Standard Time. I assume that that's a typo? =20 Ryan =20 =20 ------_=_NextPart_001_01C778E4.736FDD95 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I thought=20 folks on these two lists might be interested in this, Microsoft will be = having a=20 web chat next week discussing its EAP platform if you want to know more = about=20 our implementation and how you can integrate with it this is probably a=20 interesting talk.

 

See: = http://blogs.technet.com/nap/a= rchive/2007/04/05/eaphost-and-eap-methods-in-windows-vista-and-longhorn.a= spx

 

That page says = that the chat=20 begins @ 3:00 PM Pacific Standard Time.  I assume that = that's a=20 typo?

 

Ryan

 

 

------_=_NextPart_001_01C778E4.736FDD95-- --===============2115475060== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============2115475060==-- From emu-bounces@ietf.org Sat Apr 07 16:45:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaHmE-0007jc-9v; Sat, 07 Apr 2007 16:44:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaHmC-0007fR-DO; Sat, 07 Apr 2007 16:44:48 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaHmB-0003DV-5F; Sat, 07 Apr 2007 16:44:48 -0400 Received: from [127.0.0.1] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (sccrmhc15) with ESMTP id <20070407204446015008km5re>; Sat, 7 Apr 2007 20:44:46 +0000 Message-ID: <461802C6.1080902@cs.umd.edu> Date: Sat, 07 Apr 2007 16:44:54 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings References: <43960.63.239.69.1.1175884869.squirrel@webmail.cs.umd.edu> <20070406184854.GL28748@Sun.COM> <33203.63.239.69.1.1175886784.squirrel@webmail.cs.umd.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: bernarda@microsoft.com, ietf@ietf.org, Nicolas Williams , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Sam Hartman wrote: >>>>>> "Charles" == Charles Clancy writes: > > > Charles> I don't think I'm convinced that EAP channel bindings are > Charles> doing this binding to the L2 channel. The identity used > Charles> in an EAP channel binding must be bound to the AAA > Charles> security association between the authenticator and the > Charles> peer in order for everything to work, so it would be more > > I'm not sure I'd describe the association between the peer and authenticator as an AAA association. > I agree with the rest. Ah, I mistyped. I meant AAA security association between the authenticator and EAP server. > Charles> likely a NAS-ID than a MAC address. > > Are you sure that the binding happens between the mac address and NAS > ID? I don't understand how the peer ever confirms the NAS ID at layer > two unless it also happens to be a MAC address. This is one of the fundamental issues with EAP channel bindings. The NAS ID is bound to the AAA security association between the authenticator and the EAP server. The MAC address is visible to the client. Thus the peer and EAP server each know a different identity for the authenticator. Whatever identity is used must be channel-bound to the AAA security association, otherwise the authenticator could lie to the EAP server about its identity. I see two solutions: 1. The NAS ID is broadcast to the peer before EAP authentication (e.g. in an 802.11 beacon) 2. The EAP server maintains a static mapping between NAS IDs and MAC addresses, manually binding MAC addresses to AAA security associations > I do agree with you though that EAP channel bindings include the > peer's lower layer identity and the identity of the authenticator that > the peer will later be able to verify. Right -- but there needs to be some way for the EAP server to know the authenticator's lower-layer information in such a way that the authenticator can't lie about its lower-layer information to the EAP server. > Charles> I guess I see EAP channel bindings as an EAP<->AAA > Charles> binding, and the L2 secure association protocol as the > Charles> EAP<->L2 binding. > > The L2 secure association protocol cannot be an eap->anything binding: > it does not typically use EAP level identifiers. It uses EAP keys though. If from a higher layer we know EAP keys could have only been delivered to a particular EAP/AAA identity, and those keys are exported to the lower layer, then I'd think you have a binding from the EAP identity to the EAP keys to the lower-layer keys to the lower-layer identity. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Apr 07 17:52:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaIpI-0004Jb-UM; Sat, 07 Apr 2007 17:52:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaIpG-0004Ic-I2 for emu@ietf.org; Sat, 07 Apr 2007 17:52:02 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaInI-00016H-LG for emu@ietf.org; Sat, 07 Apr 2007 17:50:03 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l37Lnuvb029739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 7 Apr 2007 14:49:57 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l37LnuLV012949; Sat, 7 Apr 2007 14:49:56 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 14:49:56 -0700 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: [Emu] Re: Thoughts on Password-based EAP Methods Date: Sat, 7 Apr 2007 14:49:55 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Re: Thoughts on Password-based EAP Methods Thread-Index: Acd1WRVKRTRRuO0cRu+Gidz8w0XnkgAFRdTgAPu2hiA= References: From: "Narayanan, Vidya" To: "Stephen Hanna" , X-OriginalArrivalTime: 07 Apr 2007 21:49:56.0371 (UTC) FILETIME=[AE6E7630:01C7795E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I share the concerns expressed about defining yet another password based EAP method. As people have pointed out here, EAP-TTLSv0 also allows the use of the TLS record layer to carry a password-based authentication method without an inner tunneling of EAP.=20 Several months ago, I tried contacting Paul Funk, Bernard and Jari to see if there would be an interest in publishing EAP-TTLSv0. Since we never heard from Paul, that communication fizzled out. We (in Qualcomm) have an implementation of PEAPv0, PEAPv1 and TTLSv0 and would like to see the IETF publish a standard for at least one of these methods, preferably TTLSv0. The choice of an EAP method to use with some legacy authentication mechanisms in 3gpp2 has been pending for a while, due to the lack of IETF activity with respect to these protocols. Publishing a new password-based method is not going to solve this problem, since there is considerable resistance to implementing another method.=20 I'm glad to hear from Steve here that there is support for publishing TTLSv0. I would like to see that happen regardless of whether it is done as an EMU work item or not.=20 Vidya > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Monday, April 02, 2007 3:00 PM > To: emu@ietf.org > Subject: [Emu] Re: Thoughts on Password-based EAP Methods >=20 > Sorry it took me a few days to respond to this thread. >=20 > I agree with Bernard that there's no benefit in creating Yet=20 > Another Password-Based EAP Method (YAPBEM). There's no point=20 > in reinventing the wheel for a fourth time and it's not the=20 > IETF way. We're not researchers. We're practical engineers=20 > who respect running code and rough consensus. > So, yes, we should have a bias toward existing, well-tested=20 > and well-understood protocols. >=20 > In a security group, it's especially important to avoid the=20 > temptation to reinvent the wheel. We should focus our efforts=20 > on one secure tunneled EAP method and make that one secure.=20 > We should consider existing methods and only invent something=20 > new if we need to. >=20 > I have spoken to Paul Funk, the primary author of the=20 > EAP-TTLSv0 spec. He is glad to proceed as Bernard suggested: >=20 > 1. Publish an updated EAP-TTLSv0 spec that documents > current practice (as Informational or Experimental) >=20 > 2. Give up change control to the IETF so that the EMU WG > can make any necessary changes or additions to EAP-TTLS >=20 > I'm also glad to assist with this effort, since Paul is=20 > pretty busy these days. >=20 > Thanks, >=20 > Steve >=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Tuesday, March 27, 2007 8:07 AM > To: emu@ietf.org > Subject: [Emu] Thoughts on Password-based EAP Methods >=20 > After listening to the IETF 68 presentation on a=20 > password-based EAP method, I would like to voice some concerns. >=20 > Today we already have an "over abundance" of such methods.=20 > These include PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and=20 > EAP-FAST. In my discussions with customers, I invariably hear=20 > complaints about this explosion, and about various=20 > interoperability and compatibility problems that it causes.=20 > Simply put, customers do not want "yet another password-based=20 > EAP method"; they want a single method that is widely=20 > implemented and interoperable. >=20 > I am concerned that by defining yet another password-based=20 > authentication mechanism, EMU WG will be making this problem=20 > worse, not better. Creating yet another mechanism which=20 > differs little from the existing ones also seems to have very=20 > little chance of being implemented. >=20 > There is a better alternative that EMU WG should consider.=20 > This is to choose an existing method for inclusion on the=20 > IETF Standards Track, rather than creating a new one. In=20 > order to maintain backward compatibility, this would require=20 > that the owners give up change control to the IETF. >=20 > I would suggest that the best candidate for this would be=20 > EAP-TTLSv0, since it is very widely implemented, and has an=20 > existing certification program in WFA. Also, EAP-TTLSv0 had=20 > previously been on the Standards Track in the PPPEXT WG,=20 > before work on EAP methods was removed from the PPPEXT WG=20 > charter and the EAP WG was formed. >=20 > In terms of steps to be taken, this would require the=20 > following actions: >=20 >=20 > a. Review and publication of the existing EAP-TTLSv0=20 > specification as an RFC. The goal here would be to document=20 > EAP-TTLSv0 as it exists today. >=20 > b. Agreement by the authors to give up change control to the IETF. >=20 >=20 > c. EMU WG efforts to publish an EAP-TTLSv0 "bis" document,=20 > specifying additional capabilities (such as Channel Bindings). >=20 > _______________________________________________ > Emu mailing list > Emu at ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Apr 07 18:18:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaJET-0001Zn-Ed; Sat, 07 Apr 2007 18:18:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaJES-0001Zi-5f for emu@ietf.org; Sat, 07 Apr 2007 18:18:04 -0400 Received: from bay0-omc1-s10.bay0.hotmail.com ([65.54.246.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaJEQ-0002bi-TK for emu@ietf.org; Sat, 07 Apr 2007 18:18:04 -0400 Received: from hotmail.com ([207.46.8.104]) by bay0-omc1-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 7 Apr 2007 15:18:02 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 7 Apr 2007 15:18:02 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Sat, 07 Apr 2007 22:17:57 GMT X-Originating-IP: [208.54.15.129] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: vidyan@qualcomm.com, shanna@juniper.net, emu@ietf.org Bcc: Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods Date: Sat, 07 Apr 2007 15:17:57 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 07 Apr 2007 22:18:02.0087 (UTC) FILETIME=[9B324F70:01C77962] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >I'm glad to hear from Steve here that there is support for publishing >TTLSv0. I would like to see that happen regardless of whether it is done >as an EMU work item or not. My understanding is that a new version of the TTLSv0 document will be forthcoming which will fill in some of the details that were previously missing, such as the EMSK generation formula, and the definitions of the Session-Id, Peer-Id and Server-Id. A new version of the PEAPv0 specification will also be forthcoming. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Apr 07 20:09:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaKyB-0002rF-V6; Sat, 07 Apr 2007 20:09:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaKyA-0002qx-KB for emu@ietf.org; Sat, 07 Apr 2007 20:09:22 -0400 Received: from mail1.sea5.speakeasy.net ([69.17.117.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaKy9-00064m-01 for emu@ietf.org; Sat, 07 Apr 2007 20:09:22 -0400 Received: (qmail 12250 invoked from network); 8 Apr 2007 00:09:13 -0000 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net (HELO jm) ([69.17.49.110]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 8 Apr 2007 00:09:13 -0000 Received: by jm (sSMTP sendmail emulation); Sat, 7 Apr 2007 17:08:18 -0700 Date: Sat, 7 Apr 2007 17:08:18 -0700 From: Jouni Malinen To: Charles Clancy Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings Message-ID: <20070408000818.GN16197@jm.kir.nu> References: <43960.63.239.69.1.1175884869.squirrel@webmail.cs.umd.edu> <20070406184854.GL28748@Sun.COM> <33203.63.239.69.1.1175886784.squirrel@webmail.cs.umd.edu> <461802C6.1080902@cs.umd.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461802C6.1080902@cs.umd.edu> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: bernarda@microsoft.com, Sam Hartman , ietf@ietf.org, Nicolas Williams , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Sat, Apr 07, 2007 at 04:44:54PM -0400, Charles Clancy wrote: > This is one of the fundamental issues with EAP channel bindings. The > NAS ID is bound to the AAA security association between the > authenticator and the EAP server. The MAC address is visible to the > client. Thus the peer and EAP server each know a different identity for > the authenticator. Whatever identity is used must be channel-bound to > the AAA security association, otherwise the authenticator could lie to > the EAP server about its identity. > > I see two solutions: > > 1. The NAS ID is broadcast to the peer before EAP authentication (e.g. > in an 802.11 beacon) This is something that IEEE 802.11r/D5.0 is doing. R0KH-ID is set to the identity of the NAS Client (e.g., NAS-Identifier if RADIUS is used as the backend protocol) and this identifier is sent to the peer during association (before EAP authentication). In addition, both the R0KH-ID (NAS-Identifier) and R1KH-ID (authenticator MAC address) are mixed in into the key derivation after the EAP authentication. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Apr 07 20:22:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaLBA-0003ZR-2a; Sat, 07 Apr 2007 20:22:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaLB8-0003ZA-Ii; Sat, 07 Apr 2007 20:22:46 -0400 Received: from bay0-omc2-s13.bay0.hotmail.com ([65.54.246.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaLB7-0000Q1-5a; Sat, 07 Apr 2007 20:22:46 -0400 Received: from hotmail.com ([207.46.8.82]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 7 Apr 2007 17:22:44 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 7 Apr 2007 17:22:44 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Sun, 08 Apr 2007 00:22:43 GMT X-Originating-IP: [208.54.15.129] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20070408000818.GN16197@jm.kir.nu> From: "Bernard Aboba" To: j@w1.fi, clancy@cs.umd.edu Bcc: Date: Sat, 07 Apr 2007 17:22:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 Apr 2007 00:22:44.0438 (UTC) FILETIME=[07067760:01C77974] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: hartmans-ietf@mit.edu, bernarda@microsoft.com, ietf@ietf.org, Nicolas.Williams@sun.com, emu@ietf.org Subject: [Emu] Re: Last call comments:draft-williams-on-channel-binding-01.txt: EAP chann X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >This is something that IEEE 802.11r/D5.0 is doing. R0KH-ID is set to the >identity of the NAS Client (e.g., NAS-Identifier if RADIUS is used as >the backend protocol) and this identifier is sent to the peer during >association (before EAP authentication). In addition, both the R0KH-ID >(NAS-Identifier) and R1KH-ID (authenticator MAC address) are mixed in >into the key derivation after the EAP authentication. I would also add that IEEE 802.11r binds the R1KH-ID and the AP BSSID/MAC address during the post-EAP handshake. IEEE 802.11r also advertises the set of authenticators within which fast handoff is possible via the Mobility Domain IE. Currently there is no equivalent AAA attribute to carry that, but once there is (it has been discussed in RADEXT WG), it will also be possible to verify this parameter within EAP Channel Bindings. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 09 10:32:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hauul-0002rP-FB; Mon, 09 Apr 2007 10:32:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtmE-0007bH-VG; Fri, 06 Apr 2007 15:07:14 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZtmD-0003vu-GA; Fri, 06 Apr 2007 15:07:14 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l36J7CER009407; Fri, 6 Apr 2007 19:07:13 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l36J7Ccj012145; Fri, 6 Apr 2007 13:07:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l36J6K8r008122; Fri, 6 Apr 2007 14:06:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l36J6KCc008121; Fri, 6 Apr 2007 14:06:20 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 6 Apr 2007 14:06:20 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20070406190619.GM28748@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Mon, 09 Apr 2007 10:32:13 -0400 Cc: bernarda@microsoft.com, ietf@ietf.org, emu@ietf.org Subject: [Emu] Re: Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Sam, Your observation is brilliant. Yes, I agree, "EAP channel binding" and "EAP cryptographic binding" map to what my draft calls "end-point channel binding" and "unique channel binding," respectively. I had not noticed this before. Also, I think my draft's definition of "end-point channel bidning" needs to be tightened just a bit: not only must the end-point IDs be cryptographically bound into the channel, it must also be the case that the IDs meaningfully identify the channel end-points -- that is, that one nodes cannot assert the same ID as another without sharing credentials with it. I think my text implies this but does not make it sufficiently explicit. Nico -- _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 09 10:32:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hauul-0002qN-8b; Mon, 09 Apr 2007 10:32:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtVU-0006V1-7H; Fri, 06 Apr 2007 14:49:56 -0400 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZtVR-0000qk-QX; Fri, 06 Apr 2007 14:49:56 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l36Inr7B027949; Fri, 6 Apr 2007 18:49:53 GMT Received: from binky.ceFrom emu-bounces@ietf.org Mon Apr 09 10:32:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hauul-0002rP-FB; Mon, 09 Apr 2007 10:32:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtmE-0007bH-VG; Fri, 06 Apr 2007 15:07:14 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZtmD-0003vu-GA; Fri, 06 Apr 2007 15:07:14 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l36J7CER009407; Fri, 6 Apr 2007 19:07:13 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l36J7Ccj012145; Fri, 6 Apr 2007 13:07:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l36J6K8r008122; Fri, 6 Apr 2007 14:06:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l36J6KCc008121; Fri, 6 Apr 2007 14:06:20 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 6 Apr 2007 14:06:20 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20070406190619.GM28748@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Mon, 09 Apr 2007 10:32:13 -0400 Cc: bernarda@microsoft.com, ietf@ietf.org, emu@ietf.org Subject: [Emu] Re: Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Sam, Your observation is brilliant. Yes, I agree, "EAP channel binding" and "EAP cryptographic binding" map to what my draft calls "end-point channel binding" and "unique channel binding," respectively. I had not noticed this before. Also, I think my draft's definition of "end-point channel bidning" needs to be tightened just a bit: not only must the end-point IDs be cryptographically bound into the channel, it must also be the case that the IDs meaningfully identify the channel end-points -- that is, that one nodes cannot assert the same ID as another without sharing credentials with it. I think my text implies this but does not make it sufficiently explicit. Nico -- _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 09 10:32:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hauul-0002qN-8b; Mon, 09 Apr 2007 10:32:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtVU-0006V1-7H; Fri, 06 Apr 2007 14:49:56 -0400 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZtVR-0000qk-QX; Fri, 06 Apr 2007 14:49:56 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l36Inr7B027949; Fri, 6 Apr 2007 18:49:53 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l36Inq2m005351; Fri, 6 Apr 2007 12:49:52 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l36ImxqB008077; Fri, 6 Apr 2007 13:48:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l36Ims9F008076; Fri, 6 Apr 2007 13:48:54 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 6 Apr 2007 13:48:54 -0500 From: Nicolas Williams To: Charles Clancy Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings Message-ID: <20070406184854.GL28748@Sun.COM> References: <43960.63.239.69.1.1175884869.squirrel@webmail.cs.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43960.63.239.69.1.1175884869.squirrel@webmail.cs.umd.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Mon, 09 Apr 2007 10:32:13 -0400 Cc: bernarda@microsoft.com, Sam Hartman , ietf@ietf.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Fri, Apr 06, 2007 at 02:41:09PM -0400, Charles Clancy wrote: > Sam, > > In skimming through Nico's draft, it looks like EAP's crypto bindings look > something like GSS channel bindings. Note: my I-D does not describe GSS channel binding -- it describes channel binding. The reference to GSS channel binding is there as an informative, historical note. > EAP's channel bindings, on the other hand, don't really look like GSS > channel bindings. In order for EAP's channel binding to look like GSS > channel binding, EAP channel binding would have to cryptographically bind > an L2 security association to EAP keys -- but that's not what it's doing. > It's binding L2 identities to EAP keys. In fact, there's no reason it has ^^^^^^^^^^^^^ When the identities of the two end-points of a channel are: a) cryptographically bound into that channel b) such that other channels between different pairs of end-points could not have the same end-point identities, THEN we can call that pair of channel end-points identities "end-point channel bindings" -- as my I-D explains. > to be an L2 identity. It can be any identity that's meaningful to the > parties involved, and can serve as the basis for making authorization > decisions. As long as it's cryptographically bound to the L2 channel and that channel provides suitable protection for the EAP method doing the EAP channel binding, THEN Sam's observation is correct: "EAP channel binding" uses what I termed "end-point channel binding" and "EAP cryptographic binding" uses what I termed "unique channel binding." > Perhaps you could abstract the definition of channel bindings even further > such that all three are subsets of some common terminology... but that > sounds painful. No, I think we did just that, but I had not noticed that, in fact, the two kinds of EAP binding map to the two kinds of channel binding described in my draft. Thanks Sam! Nico -- _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ntral.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l36Inq2m005351; Fri, 6 Apr 2007 12:49:52 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l36ImxqB008077; Fri, 6 Apr 2007 13:48:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l36Ims9F008076; Fri, 6 Apr 2007 13:48:54 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 6 Apr 2007 13:48:54 -0500 From: Nicolas Williams To: Charles Clancy Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings Message-ID: <20070406184854.GL28748@Sun.COM> References: <43960.63.239.69.1.1175884869.squirrel@webmail.cs.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43960.63.239.69.1.1175884869.squirrel@webmail.cs.umd.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Mon, 09 Apr 2007 10:32:13 -0400 Cc: bernarda@microsoft.com, Sam Hartman , ietf@ietf.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Fri, Apr 06, 2007 at 02:41:09PM -0400, Charles Clancy wrote: > Sam, > > In skimming through Nico's draft, it looks like EAP's crypto bindings look > something like GSS channel bindings. Note: my I-D does not describe GSS channel binding -- it describes channel binding. The reference to GSS channel binding is there as an informative, historical note. > EAP's channel bindings, on the other hand, don't really look like GSS > channel bindings. In order for EAP's channel binding to look like GSS > channel binding, EAP channel binding would have to cryptographically bind > an L2 security association to EAP keys -- but that's not what it's doing. > It's binding L2 identities to EAP keys. In fact, there's no reason it has ^^^^^^^^^^^^^ When the identities of the two end-points of a channel are: a) cryptographically bound into that channel b) such that other channels between different pairs of end-points could not have the same end-point identities, THEN we can call that pair of channel end-points identities "end-point channel bindings" -- as my I-D explains. > to be an L2 identity. It can be any identity that's meaningful to the > parties involved, and can serve as the basis for making authorization > decisions. As long as it's cryptographically bound to the L2 channel and that channel provides suitable protection for the EAP method doing the EAP channel binding, THEN Sam's observation is correct: "EAP channel binding" uses what I termed "end-point channel binding" and "EAP cryptographic binding" uses what I termed "unique channel binding." > Perhaps you could abstract the definition of channel bindings even further > such that all three are subsets of some common terminology... but that > sounds painful. No, I think we did just that, but I had not noticed that, in fact, the two kinds of EAP binding map to the two kinds of channel binding described in my draft. Thanks Sam! Nico -- _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 09 14:09:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HayJ5-0006VW-Pk; Mon, 09 Apr 2007 14:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HayJ5-0006VR-1Y for emu@ietf.org; Mon, 09 Apr 2007 14:09:35 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HayJ2-0007uB-0c for emu@ietf.org; Mon, 09 Apr 2007 14:09:35 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Apr 2007 11:09:31 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l39I9Vue022156 for ; Mon, 9 Apr 2007 11:09:31 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l39I9Ia1015685 for ; Mon, 9 Apr 2007 18:09:31 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 11:09:26 -0700 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 Date: Mon, 9 Apr 2007 11:09:18 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Meeting Minutes from IETF-68 Thread-Index: Acd60jChgIiLQ5VyTyaB5/gawpVmtw== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 09 Apr 2007 18:09:26.0384 (UTC) FILETIME=[35922700:01C77AD2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16111; t=1176142171; x=1177006171; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20Draft=20Meeting=20Minutes=20from=20IETF-68 |Sender:=20; bh=8d4O18Y4wcKpoXe2LObYofsVLB56G4jt05Rf3ybDGgc=; b=wpvlEbot6BcwtVRr6l2pgo8C7NU2pL4Ie6ea050I6OWokZtvv+FMHaqzSyASxGug6KsevfTd dXC03HgJf7WlmXYqw1FFZQf6w2j5MtklR6Nxxdj59Pf71xaC3H3HoeeU; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Subject: [Emu] Draft Meeting Minutes from IETF-68 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Below are draft meeting minutes from IETF-68. Please let me know if you have any additions or corrections. =20 ------------------------------------------------------------------------ ---------------------- EAP Method Update (EMU) Minutes=20 IETF-68=20 Prague, Czech Republic March 19, 2007=20 -------------------------------- Chair: Joseph Salowey Note Taker: Nancy Cam-Winget -------------------------------- -------------------------------- Agenda -------------------------------- 1. rfc2716-bis 2. EAP-GPSK 3. Password-based method 4. Additional Item - EAP extensions -------------------------------- RFC 2716bis - Bernard Aboba -------------------------------- - Discussion of changes in version 08 - Open Issues mostly around certificate usage + Discussion on multiple names in certificate Joe Salowey: what if there is more than one subjectAltName? Tim Polk: states that we need to define the same context and rules. Stefan Santesson: having more names in a cert is not a problem so long as matching the name requirement is okay in general. Tim: retorts that it can get tricky as it depends on where the name "sought" is in the appropriate place. Sam Hartman: trying to authorize access; all names provided in a cert should be valid, so if any of those names match an authorizable name, then access should be granted. =20 Tim: questions whether there would be an issue if there's a distinguished name versus an RFC2716 name... Sam and Tim: agree that as long as there is a searchable name, it should be "good enough". Bernard Aboba: comments AAA server should try to see for the name to match in any and all the fields. Hannes Tschofenig: comments it may just be an implementation issue by the EAP server. Doesn't believe the checks need to be constrained and precise as it would require full description of what is to be matched; in this case it shouldn't matter. + Discussion on where to put MAC address in certificate raised by Ryan Hurst on list Bernard: comments that it arose from cert applicability of whether the MAC address is in the subjectAltName and whether they should be colon delimited or not. Stefan: comments on 3 alternatives: (1) distinguished name; (2) permanent serial number and (3) creating a new "other" field. Concern of use of (2) and (3); suggests the use of an OID as part of the TLS exchange. + Some consensus that the previous comment should not be part of this spec. Tim: agrees its out of scope for this group. All names should be equally valid for the subject; they are for specific contexts. + back to multiple names in certificate=20 Joe: comments that subjectName may have multiple components. Sam: mentions that all parts in the subjectName needs to be valid. Tim: notes that especially for distinguished name, one should not extract a portion it should be used as a whole. Sam: mentions RFC 2818 describes exactly what Tim said not to do.=20 Bernard: summarizes it may not take long to resolve. Paul Hoffman: comments on how prior descriptions still may not give us interoperability. Servers tend to be lazy as they will scan for first match and then fail (too easily). Bernard: concurs and notes that we'd need to add more text. Gregory Liebowitz: mentions that there should be a clear indication of what name should be sought. Hannes: mentions that IPSec has experience on this, 802.16 also has this application. We should find out where the MAC address validation occurs, if it is terminated by the EAP server, AAA server or otherwise. Vidya Narayanan: comments TLS cipher suites not supported by the draft, questions which ones are. Several respond that there are quite a few that are documented as SHOULD and SHALLs to enumerate the supported ones. Bernard: mentions behavior of 2716 requires that request for cert is still be made. Sam: mentions that this is last call issues and to be cognizant of this state so that we do not open up more new issues. Bernard: states that we should look at text and see if there's anything wrong. If there's nothing broken, then we can open it to a wider group to get more eyes that have deeper certificate expertise to help review. -------------------------------- EAP-GPSK - Hannes Tschofenig -------------------------------- Current status and mention of reviewers. - discussion of cipher suites and KDFs - 2 current cipher suites: AES-CBC-128, NULL - suggested change #1 CBC to CTR in ciphersuite #1 - suggested change #2 KDF use MAC-based vs. hash based KDF. The commenter mentions that the change is not aligned with http://tools.ietf.org/html/draft-dang-nistkdf-01 + KDF discussion Tim (with NIST "hat"): tries to clarify without having looked at this document. NIST has a standard for keys derived from key establishment (DH, MQV)...they way NIST works, it looks at a standard to use one of the approved methods. There's nothing against using MAC's in KDFs by NIST, previous guidance may have been misled on the belief that key establishment was based on DH. =20 Charles Clancy: comments there were other suggestions but HASH vs. MAC requires a new cryptographic function in the draft. Sam: argues that there's no theoretical basis for why hashes are good for KDFs. Tim: apologizes that NIST's SP856 can be confusing, he hopes to do a presentation in Chicago to help clarify. Suspects the suggested reordering may be warranted but change from MAC to HASH is not a requirement. Lakshminath Dondeti: comments that he'd like to see the draft before commenting. Sam: mentions that if a MAC constructions meets the desired properties, that should be fine...unless you want to do something different and its aptly justified it could also be accepted. Lakshminath: comments to the contradicting opinions on hash vs. mac constructions. From the current feedback, perception is that hash may be stronger. Hannes: comments that the draft will revert back to the MAC construction. Tim: mentions there is sensitivity to ordering and unambiguous ordering. But this group is not in the space of SP856 so that document should not have an impact on this body of work. + CTR vs. CBC + Hannes: brings back suggestion to change CBC to CTR mode. Lakshminath: as one who suggested change, notes that it is not such a big deal; but mentions that CBC mode requires implementation of both encrypt and decrypt. Hannes and Joe: mention that performance is not an issue. Hannes: also mentions that code size is also not an issue as the code bloat is not that large. Document explicitly notes that other ciphersuites may be used. Joe: notes there's no strong compelling reason to change=20 Sam: notes the group has to have consensus to change which is not apparent -------------------------------- Password based method=20 design team update=20 Madjid Nakhjiri -------------------------------- + Discussion of requirements + Open issues on requirements to discuss: - Should we require password/pin change - Other password based protocols (CHAP, MSCHAP, etc) - Cryptographic binding of password exchange keys to keys of the protection layer - extension mechanism (data exchanges inside tunnel) - transport of channel binding data - protected result indication - OCSP for cert-based "server authentication" + Leaning direction: towards Use of TLS - presentation of how TLS is used - data format alternatives discussed: XDR (RFC1832), AVP, ASN.1....leaning towards AVPs + Discussion of Remaining Open issues: + new EAP method type: do we use one method type for passwords only? Sam: cautions multi-layer negotiation as being a potential issue =20 + Do we need messaging framework or just TLVs? Sam: comments on crypto binding as being a requirement that authentication at one layer be tied to authentication at another layer. Like using the TLS finished message. This is as an alternative to mixing key derivation but notes that crypto binding is a requirement. Hao Zhou: mentions that using the TLS finished message signing may require extensions to this. Sam: mentions that we could sign the TLS finished message Hao: mentions that we may not get a key from the password method Sam: agrees that if we use the key from TLS that is another way to get the crypto binding. Hannes: mentions the crypto binding discussion came from the tunneling; the best work showed that crypto binding is a requirement. If a password is done on top of the EAP exchange, it wasn't clear that we needed the crypto binding....still not sure on how to handle that case. Hao: responds to Sam that the TLS tunnel is used to generate the EMSK and MSK since its not guaranteed that a key is generated from the password exchange. Joe: mentions other issues with other password based protocols, where some methods require the passing of username and passwords during the exchange. Hao: mentions to adopt a consistent crypto binding as there are different password exchanges + Joe: asks whether we want to adopt other schemes than just plaintext password, asks the general group if there is use to adopt something other than plaintext password. Hao: mentions that some client implementations only obtain the hash of the password. Bernard: you can always ask the user Joe: Hao are you referring to the case where single sign on or some other mechanism restricts access to password Hao: yes Joe: mentions there's not much excitement in adopting more than plaintext but discussion to be continued on the thread. Lakshminath: asks how this work would be different than PAP? Joe: mentions it will not be any more different than TTLS, PEAP or EAP-FAST but wants to make sure we do not support everything under the sun. Keep the model simple. Lakshminath: asks on EAP-TLS and discussions on how to use EAP with TLS. Hannes: mentions that it is not new, it is new in the sense that one author dropped from the original draft.=09 Sam: mentions that EAP has limited applicability. Hannes: comments EAP applicability in TLS has also been rationale in IKEv2=20 Sam: mentions there are different mechanisms for doing authentication; doesn't want groups adopting frameworks based on methods supported. Unless all frameworks are made to work together, he will make strict ruling on applicability. But it is outside of scope to this group. Bernard: comments that customers are tired of this and wants to standardize on a single one and not to create more tunneled EAP methods. - Joe: returns to open issues and discussion of password/pin change: Sam: believes it is very hard to achieve Paul: email did this (POP) and no-one used it Hao: believes we need to address it, if we don't, a new method will be created to address it Paul: iterates that we need it though is not convinced that we need to spend a lot of time to get it "right" Jeff Hutzelman: mentions a requirement for extension as a pro and suggest that at a minimum, defer the password change mechanism until we get to the extensibility. As the extensibility should allow us to do password change in the future. Hao: speaks as an implementer to getting many customer requirements to support OTP and password change. Hannes: asks if there is such a mechanism documented.=09 Sam: mentions there isn't one and this environment may be different than an email environment. Today, with EAP, it may not be feasible to get anywhere until the password is changed.=20 Paul: agree =20 Joe: closes that there is agreement that we need to support password change...we may need to go further Paul: mentions that this (password change) may be a good test of extensibility Joe summarizes:=20 + crypto binding may be taken care of thru the use of the EAP TLS tunnel for key generation. More discussion to continue on the email thread. + extension mechanism is a requirement as it will be used as a means to address other requirements such as password change. + transport of channel binding data: may be another use for an extension + requiring protection of the result indication Sam: You need to explain how you are going to meet draft housley AAA requirements - Discussion of the results being reliable Jefferey: asks if the EAP fails, how do we authenticate the result indication? Joe agrees it is a hard problem, but could authenticate the other failures like bad password or other conditions within the tunnel. More people think its good and no one was against implementing this. Sam: asks to look at the Housley requirement if we choose not to do this. =09 - OCSP for cert-based "server authentication" Sam: comments that this may be not enough as it doesn't give you status of intermediate, nor anything else that could be done to remedy this without touching TLS. Charlie: mentions that SCVP could help. Sam: doesn't quite agree as TLS would have to be modified to do SCVP within TLS....though it could be done within the tunnel (as a blob). But the catch is that SCVP may not be widely implemented to force this be implemented by this group. Joe: asks whether OCSP should be mandatory? Jeff: comments that question is not well formed. Joe: clarifies that this would require OCSP extensions to be mandatory to implement. Jeff: mentions that requirement imposes a deployment requirement on the protocol Joe's: concern is more on implementation that if its not supported, then there is no means to enable vs. disable this feature. Stefan: notes that it is different to say support (enforce) OCSP versus require to implement Joe: means require to implement OCSP Tim and Sam: agree that there has to be a strategy for certificate checking including revocation; given the proposals there must be one mandatory to implement Joe: wants to continue discussion Yoshihiro Obha: mentions that his presentation discusses channel binding Joe: mentions target is to have draft out by next meeting (this concludes working group Discussion of Working group items) Sam: asks if there are any Hokey chairs and caucus with them to determine that Yoshi's presentation is out of scope for this group. Yoshiro: retorts that his presentation is on an EAP method Glen Zorn (HOKEY Co-Chair): Does not have an objection to the presentation -------------------------------- EAP-EXT - Yoshihiro Obha -------------------------------- * Proposal to use EMSK usage=20 * Channel binding issues: two approaches and lack of support * EAP notes: no version, lack of backward compatibility * Design discussion on how to extend EAP to allow for: - sequencing in a single EAP conversation - sequencing multiple EAP conversations - allow for channel binding * Proposes EAP-EXT: a tunneled method with protected capabilities exchange to enable sequencing inside the tunnel and allow for backwards compatibility. - proposal includes TLV for accomplishing Key (EMSK) derivation, channel binding and crypto binding but using its own construction. - proposal was also presented in HOKEY meeting Hao: questions how this is different than TTLS, PEAPv2, EAP-FAST Yoshi: mentions capability negotiation and being able to do "other" things. Glen: likes the capability negotiation and would like to see it expanded, though there's not much applicability in HOKEY it is work looking at other uses Alan: going on capability discussion there's a lot of discussion in RADEXT Joe: mentions there's no space to take this up as a work item. Jeff: What do you recommend the author? Sam: clarifies that this working group has a fixed charter and this is not one of them; revising core EAP is not in this group's charter. Jeff: concludes that there's no current home Sam: suggests a BOF Joe: says need to articulate the problem we're trying to solve in the BOF Sam: mentions it could be an individual submission but is leery of this given that it is more intrusive to the EAP protocol _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 09 14:26:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HayZi-0008Lo-4r; Mon, 09 Apr 2007 14:26:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HayZg-0008HN-HF for emu@ietf.org; Mon, 09 Apr 2007 14:26:44 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HayZb-0002pA-W5; Mon, 09 Apr 2007 14:26:44 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 9 Apr 2007 11:26:39 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.25; Mon, 9 Apr 2007 11:26:38 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Apr 2007 11:26:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] Talk on Windows EAP implementation... Date: Mon, 9 Apr 2007 11:25:42 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004C03883@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262503BE14B3@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Talk on Windows EAP implementation... Thread-Index: Acd4cQeg/yf6zV81SPqizGMsWra3oQAcz89gAHwKwmA= References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004B82F6A@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <4C0FAAC489C8B74F96BEAD85EAEB262503BE14B3@xmb-sjc-215.amer.cisco.com> From: Ryan Hurst To: "Glen Zorn (gwz)" X-OriginalArrivalTime: 09 Apr 2007 18:26:37.0881 (UTC) FILETIME=[9C641A90:01C77AD4] X-Spam-Score: 1.2 (+) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: eap@ietf.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1211268751==" Errors-To: emu-bounces@ietf.org --===============1211268751== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77AD4.7BD67D34" ------_=_NextPart_001_01C77AD4.7BD67D34 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes that time is correct, 3:00 PM PST. =20 From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 Sent: Saturday, April 07, 2007 12:15 AM To: Ryan Hurst Cc: emu@ietf.org; eap@ietf.org Subject: RE: [Emu] Talk on Windows EAP implementation... =20 I thought folks on these two lists might be interested in this, Microsoft will be having a web chat next week discussing its EAP platform if you want to know more about our implementation and how you can integrate with it this is probably a interesting talk. =20 See: http://blogs.technet.com/nap/archive/2007/04/05/eaphost-and-eap-methods- in-windows-vista-and-longhorn.aspx =20 That page says that the chat begins @ 3:00 PM Pacific Standard Time. I assume that that's a typo? =20 Ryan =20 =20 ------_=_NextPart_001_01C77AD4.7BD67D34 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes that time is = correct, 3:00 PM PST.

 

From:= Glen Zorn = (gwz) [mailto:gwz@cisco.com]
Sent: Saturday, April 07, 2007 12:15 AM
To: Ryan Hurst
Cc: emu@ietf.org; eap@ietf.org
Subject: RE: [Emu] Talk on Windows EAP = implementation...

 

I thought folks on these = two lists might be interested in this, Microsoft will be having a web chat = next week discussing its EAP platform if you want to know more about our implementation and how you can integrate with it this is probably a = interesting talk.

 

See: = http://blogs.technet.com/nap/a= rchive/2007/04/05/eaphost-and-eap-methods-in-windows-vista-and-longhorn.a= spx

 

That page says that the chat begins @ 3:00 PM Pacific = = Standard Time. I assume that that's a typo?

 

Ryan

 

 

------_=_NextPart_001_01C77AD4.7BD67D34-- --===============1211268751== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1211268751==-- From emu-bounces@ietf.org Mon Apr 09 18:38:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2VV-0000MW-Jp; Mon, 09 Apr 2007 18:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2VU-0000GW-1D; Mon, 09 Apr 2007 18:38:40 -0400 Received: from dhcp-18-188-3-76.dyn.mit.edu ([18.188.3.76] helo=live.Belkin) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb2VR-0006lY-FG; Mon, 09 Apr 2007 18:38:40 -0400 Received: by live.Belkin (Postfix, from userid 8042) id B264548E4; Mon, 9 Apr 2007 18:38:36 -0400 (EDT) From: hartmans-ietf@mit.edu To: Charles Clancy Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings References: <43960.63.239.69.1.1175884869.squirrel@webmail.cs.umd.edu> <20070406184854.GL28748@Sun.COM> <33203.63.239.69.1.1175886784.squirrel@webmail.cs.umd.edu> <461802C6.1080902@cs.umd.edu> Date: Mon, 09 Apr 2007 18:38:36 -0400 In-Reply-To: <461802C6.1080902@cs.umd.edu> (Charles Clancy's message of "Sat, 07 Apr 2007 16:44:54 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: bernarda@microsoft.com, ietf@ietf.org, Nicolas Williams , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >>>>> "Charles" == Charles Clancy writes: Charles> Sam Hartman wrote: >>>>>>> "Charles" == Charles Clancy writes: >> Charles> I don't think I'm convinced that EAP channel bindings are Charles> doing this binding to the L2 channel. The identity used Charles> in an EAP channel binding must be bound to the AAA Charles> security association between the authenticator and the Charles> peer in order for everything to work, so it would be more >> I'm not sure I'd describe the association between the peer and >> authenticator as an AAA association. I agree with the rest. Charles> Ah, I mistyped. I meant AAA security association between Charles> the authenticator and EAP server. I'd define the EAP channel binding problem as follows. There are two sets of identities that the peer and authenticator use: one at the EAP layer and one at a lower layer. There is an additional identity that the authenticator may use to authenticate to the AAA server. The channel binding problem is to make sure that the EAP server authorizes the authenticator's use of the lower layer identity to the peer and the peer's use of a given lower layer identity. In performing this authorization the EAP server must authorize that the authenticator is actually allowed to claim the lower layer identity it wants to claim. In doing that it will have to make an authorization decision about whether the identity the authenticator uses to authenticate to the AAA server is authorized to claim the given lower layer identity. However that identity--between the NAS and the AAA server doesn't inherently appear anywhere else. It sounds like 802.11R does plan to expose that identity, but that's a design decision for that lower layer. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Apr 12 02:03:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbsP9-00033C-4n; Thu, 12 Apr 2007 02:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbsP6-00032q-7O; Thu, 12 Apr 2007 02:03:32 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbsP5-0008SW-Pa; Thu, 12 Apr 2007 02:03:32 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3C63UR8025334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Apr 2007 23:03:30 -0700 Received: from [10.50.76.193] (qconnect-10-50-76-193.qualcomm.com [10.50.76.193]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3C63Ta8013715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2007 23:03:29 -0700 Message-ID: <461DCBB1.1010401@qualcomm.com> Date: Wed, 11 Apr 2007 23:03:29 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: bernarda@microsoft.com, ietf@ietf.org, nicolas.williams@sun.com, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Sam, Here is my take on this topic: After having reviewed "draft-williams-on-channel-binding-01," I feel that putting EAP in scope of that document would require a rather involved revision of the document. As Charles noted it might require further abstraction of the concept of channel binding as defined in draft-williams. Now, I must say, I do see the similarities between the two notions of channel binding. But the EAP/AAA model is unique and it is not easy to map it to the other, let's say simpler, security models. The notion of compound binding or crypto binding also has some similarities to the notion of channel binding in draft-williams-on-channel-binding-01, but there are also some differences. Overall though, since expanding draft-williams-on-channel-binding-01's scope to EAP means that the requirements, recommendations and suggestions of Section 2.1 may be applied to EAP channel binding, it would be a rather painful exercise to sort it all out. For now, I am comfortable with the guidance in Section 7.15 of 3748. thanks, Lakshminath Sam Hartman wrote: > > > Hi. > > For the last couple of years, we've been believing that EAP and GSS > used the term channel bindings inconsistently. For those of us > dealing with both, it's been a bit annoying. > > I've been thinking about EAP a lot lately. and have come to the > conclusion that actually the terms are used consistently. > > I'd like to see if people agree with the following change to Nico's channel binding draft: > > old: > > Also unfortunately there is a conflict with the Extensible > Authentication Protocol (EAP) [RFC3748] which uses "channel binding" > to refer to a facility that is subtly different from the one > described here. (It does not seem feasible to adopt new terminology > to avoid these problems now. The GSS-API, NFSv4 and other > communities have been using the terms "channel binding" and "channel > bindings" in these ways for a long time, sometimes with variations > such as "channel binding facility" and so on.) > > new: > > The Extensible Authentication Protocol (EAP) [RFC3748] includes two > facilities related to channel binding. The first, called channel > binding, is used to bind the lower-layer channel created between the > peer and the authenticator to the authentication performed using EAP. > Specific detials of this facility have not been specified, but it is > likely that this channel would use endpoint channel bindings carried > in the EAP method exchange. The endpoint channel bindings would be > defined for the specific lower layer. EAP also has a facility called > cryptographic binding, which is another instance of channel binding. > Cryptographic binding refers to binding the channel created by a > tunneling EAP method to an inner authentication performed within that > method. Cryptographic binding will likely use unique channel > bindings. > > Do these changes make sense to people? Am I telling any lies or > conflating two architectures in a bad way? > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Apr 12 11:42:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc1R4-00060K-5g; Thu, 12 Apr 2007 11:42:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbz0M-0000YA-Ra; Thu, 12 Apr 2007 09:06:26 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbz0K-0000id-Kl; Thu, 12 Apr 2007 09:06:26 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 12 Apr 2007 06:06:24 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.25; Thu, 12 Apr 2007 06:06:23 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Apr 2007 06:06:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings Date: Thu, 12 Apr 2007 06:04:36 -0700 Message-ID: <0C7B902B470A264FA64D66CBF76FB8210358C522@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings thread-index: Acd8yFmtnNgpJRgWRHyGqVUd+s7Y6wAOsXF1 References: <461DCBB1.1010401@qualcomm.com> From: Bernard Aboba To: Lakshminath Dondeti , Sam Hartman X-OriginalArrivalTime: 12 Apr 2007 13:06:23.0428 (UTC) FILETIME=[5EEC8040:01C77D03] X-Spam-Score: 0.5 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 X-Mailman-Approved-At: Thu, 12 Apr 2007 11:42:09 -0400 Cc: ietf@ietf.org, nicolas.williams@sun.com, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0798370662==" Errors-To: emu-bounces@ietf.org --===============0798370662== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77D03.50C2F768" ------_=_NextPart_001_01C77D03.50C2F768 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Lakshminath on this. =20 ________________________________ From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: Wed 4/11/2007 11:03 PM To: Sam Hartman Cc: ietf@ietf.org; Bernard Aboba; emu@ietf.org; nicolas.williams@sun.com Subject: Re: [Emu] Last call comments: = draft-williams-on-channel-binding-01.txt: EAP channel bindings Hi Sam, Here is my take on this topic: After having reviewed "draft-williams-on-channel-binding-01," I feel that putting EAP in scope of that document would require a rather involved revision of the document. As Charles noted it might require further abstraction of the concept of channel binding as defined in draft-williams. Now, I must say, I do see the similarities between the two notions of channel binding. But the EAP/AAA model is unique and it is not easy to map it to the other, let's say simpler, security models. The notion of compound binding or crypto binding also has some similarities to the notion of channel binding in draft-williams-on-channel-binding-01, but there are also some differences. Overall though, since expanding draft-williams-on-channel-binding-01's scope to EAP means that the requirements, recommendations and suggestions of Section 2.1 may be applied to EAP channel binding, it would be a rather painful exercise to sort it all out. For now, I am comfortable with the guidance in Section 7.15 of 3748. thanks, Lakshminath Sam Hartman wrote: > > > Hi. > > For the last couple of years, we've been believing that EAP and GSS > used the term channel bindings inconsistently. For those of us > dealing with both, it's been a bit annoying. > > I've been thinking about EAP a lot lately. and have come to the > conclusion that actually the terms are used consistently. > > I'd like to see if people agree with the following change to Nico's = channel binding draft: > > old: > > Also unfortunately there is a conflict with the Extensible > Authentication Protocol (EAP) [RFC3748] which uses "channel = binding" > to refer to a facility that is subtly different from the one > described here. (It does not seem feasible to adopt new = terminology > to avoid these problems now. The GSS-API, NFSv4 and other > communities have been using the terms "channel binding" and = "channel > bindings" in these ways for a long time, sometimes with variations > such as "channel binding facility" and so on.) > > new: > > The Extensible Authentication Protocol (EAP) [RFC3748] includes two > facilities related to channel binding. The first, called channel > binding, is used to bind the lower-layer channel created between the > peer and the authenticator to the authentication performed using EAP. > Specific detials of this facility have not been specified, but it is > likely that this channel would use endpoint channel bindings carried > in the EAP method exchange. The endpoint channel bindings would be > defined for the specific lower layer. EAP also has a facility called > cryptographic binding, which is another instance of channel binding. > Cryptographic binding refers to binding the channel created by a > tunneling EAP method to an inner authentication performed within that > method. Cryptographic binding will likely use unique channel > bindings. > > Do these changes make sense to people? Am I telling any lies or > conflating two architectures in a bad way? > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > ------_=_NextPart_001_01C77D03.50C2F768 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Emu] Last call comments: = draft-williams-on-channel-binding-01.txt: EAP channel bindings=0A= =0A= =0A= =0A=
=0A=
I agree with = Lakshminath on this. 
=0A=

=0A=
=0A= From: Lakshminath Dondeti = [mailto:ldondeti@qualcomm.com]
Sent: Wed 4/11/2007 11:03 = PM
To: Sam Hartman
Cc: ietf@ietf.org; Bernard Aboba; = emu@ietf.org; nicolas.williams@sun.com
Subject: Re: [Emu] Last = call comments: draft-williams-on-channel-binding-01.txt: EAP channel = bindings

=0A=
=0A=

Hi Sam,

Here is my take on this = topic:

After having reviewed = "draft-williams-on-channel-binding-01," I feel
that putting EAP in = scope of that document would require a rather
involved revision of = the document.  As Charles noted it might require
further = abstraction of the concept of channel binding as defined = in
draft-williams.

Now, I must say, I do see the similarities = between the two notions of
channel binding.  But the EAP/AAA = model is unique and it is not easy to
map it to the other, let's say = simpler, security models.  The notion of
compound binding or = crypto binding also has some similarities to the
notion of channel = binding in draft-williams-on-channel-binding-01, but
there are also = some differences.

Overall though, since expanding = draft-williams-on-channel-binding-01's
scope to EAP means that the = requirements, recommendations and
suggestions of Section 2.1 may be = applied to EAP channel binding, it
would be a rather painful exercise = to sort it all out.  For now, I am
comfortable with the guidance = in Section 7.15 of 3748.

thanks,
Lakshminath

Sam = Hartman wrote:
>
>
> Hi.
>
> For the last = couple of years, we've been believing that EAP and GSS
> used the = term channel bindings inconsistently.  For those of us
> = dealing with both, it's been a bit annoying.
>
> I've been = thinking about EAP a lot lately. and have come to the
> conclusion = that actually the terms are used consistently.
>
> I'd like = to see if people agree with the following change to Nico's channel = binding draft:
>
> old:
>
>    = Also unfortunately there is a conflict with the = Extensible
>    Authentication Protocol (EAP) = [RFC3748] which uses "channel binding"
>    to = refer to a facility that is subtly different from the = one
>    described here.  (It does not seem = feasible to adopt new terminology
>    to avoid = these problems now.  The GSS-API, NFSv4 and = other
>    communities have been using the terms = "channel binding" and "channel
>    bindings" in = these ways for a long time, sometimes with = variations
>    such as "channel binding facility" = and so on.)
>
> new:
>
> The Extensible = Authentication Protocol (EAP) [RFC3748] includes two
> facilities = related to channel binding.  The first, called channel
> = binding, is used to bind the lower-layer channel created between = the
> peer and the authenticator to the authentication performed = using EAP.
> Specific detials of this facility have not been = specified, but it is
> likely that this channel would use endpoint = channel bindings carried
> in the EAP method exchange.  The = endpoint channel bindings would be
> defined for the specific = lower layer.  EAP also has a facility called
> cryptographic = binding, which is another instance of channel binding.
> = Cryptographic binding refers to binding the channel created by a
> = tunneling EAP method to an inner authentication performed within = that
> method.  Cryptographic binding will likely use unique = channel
> bindings.
>
> Do these changes make sense to = people?  Am I telling any lies or
> conflating two = architectures in a bad way?
>
>
> = _______________________________________________
> Emu mailing = list
> Emu@ietf.org
> https://www1.ietf.org= /mailman/listinfo/emu
>

------_=_NextPart_001_01C77D03.50C2F768-- --===============0798370662== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============0798370662==-- From emu-bounces@ietf.org Thu Apr 12 11:42:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc1R4-00060F-2D; Thu, 12 Apr 2007 11:42:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbV7P-0005iI-3T; Wed, 11 Apr 2007 01:11:43 -0400 Received: from colo.trepanning.net ([69.55.226.174] helo=mail1.trepanning.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbV7N-0007eJ-M2; Wed, 11 Apr 2007 01:11:43 -0400 Received: from www.trepanning.net (localhost [127.0.0.1]) by mail1.trepanning.net (Postfix) with ESMTP id 97D751FA678B; Tue, 10 Apr 2007 22:11:32 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 10 Apr 2007 22:11:32 -0700 (PDT) Message-ID: <55137.69.12.173.8.1176268292.squirrel@www.trepanning.net> In-Reply-To: References: <43960.63.239.69.1.1175884869.squirrel@webmail.cs.umd.edu> <20070406184854.GL28748@Sun.COM> <33203.63.239.69.1.1175886784.squirrel@webmail.cs.umd.edu> <461802C6.1080902@cs.umd.edu> Date: Tue, 10 Apr 2007 22:11:32 -0700 (PDT) Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings From: "Dan Harkins" To: hartmans-ietf@mit.edu User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Thu, 12 Apr 2007 11:42:09 -0400 Cc: bernarda@microsoft.com, ietf@ietf.org, Nicolas Williams , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Mon, April 9, 2007 3:38 pm, hartmans-ietf@mit.edu wrote: [snip] > I'd define the EAP channel binding problem as follows. There are two > sets of identities that the peer and authenticator use: one at the EAP > layer and one at a lower layer. There is an additional identity that > the authenticator may use to authenticate to the AAA server. The > channel binding problem is to make sure that the EAP server authorizes > the authenticator's use of the lower layer identity to the peer and > the peer's use of a given lower layer identity. I don't agree. The channel binding problem is to make sure the EAP server and the peer agree to whom the key is being disclosed. They have to agree on a common identity that is relevant at the EAP layer. You're right that the authenticator can have 3 identities-- a lower layer identity like a MAC address, a NAS ID, and some identity that was used to create a security association with the AS. The AS doesn't know and doesn't care what the lower layer identity of the authenticator is. Likewise the peer doesn't know and doesn't care what identity the authenticator used to establish a security association with the AS (most likely an IP address). But they are both speaking EAP and there is an identity of the authenticator that they can both agree on and that is relevant at that layer-- the NAS ID. EAP channel binding is a protected exchange, between the peer and AS, of this identity (the NAS ID not a lower layer identity) and the identity passed in the protected exchange is verified with the identity establishe= d in some out-of-band fashion (for instance, at provisioning time of the NAS). If they are equal then all systems are go, if they are not then houston we have a problem. Dan. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Apr 12 12:22:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc24T-0007Ib-QK; Thu, 12 Apr 2007 12:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc24S-0007Hd-5G for emu@ietf.org; Thu, 12 Apr 2007 12:22:52 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc24R-0000Ap-Pu for emu@ietf.org; Thu, 12 Apr 2007 12:22:52 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2007 09:22:52 -0700 X-IronPort-AV: i="4.14,403,1170662400"; d="scan'208"; a="369570916:sNHT47642164" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3CGMpH6029634 for ; Thu, 12 Apr 2007 09:22:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3CGMiML007451 for ; Thu, 12 Apr 2007 16:22:51 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 09:22:44 -0700 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: FW: [Emu] Last call comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings Date: Thu, 12 Apr 2007 09:22:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Last call comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings Thread-Index: Acd9FORJV1W7OtUuRFGd/sAU4yx5fAABQ7kQ From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 12 Apr 2007 16:22:44.0767 (UTC) FILETIME=[CD262AF0:01C77D1E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2410; t=1176394971; x=1177258971; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20FW=3A=20[Emu]=20Last=20call=20comments=3Adraft-williams-on-ch annel-binding-01.txt=3A=20EAP=20channel=20bindings |Sender:=20; bh=1jOYYMonhmKmxXig8cfBb++dWGb9OvWb9+tmn8Bm2iM=; b=ZQuRGKdE8G808iqo9PEl9uKtQ37KNdFr+iz6RRbLqbSJZsCljBJXg7IlOtDn9BGTaDBgrKqS Ui/jhpXyAZAn/cRgLGdWH/+x9Y5JTw+c7H7y1FcYX7cI4JQJ3Rf1RdDM; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Message accidentally discarded by the moderator. =20 > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Thursday, April 12, 2007 8:10 AM > To: Lakshminath Dondeti > Cc: bernarda@microsoft.com; Sam Hartman; ietf@ietf.org; emu@ietf.org > Subject: Re: [Emu] Last call=20 > comments:draft-williams-on-channel-binding-01.txt: EAP=20 > channel bindings >=20 > On Wed, Apr 11, 2007 at 11:03:29PM -0700, Lakshminath Dondeti wrote: > > After having reviewed=20 > "draft-williams-on-channel-binding-01," I feel=20 > > that putting EAP in scope of that document would require a rather=20 > > involved revision of the document. As Charles noted it=20 > might require=20 > > further abstraction of the concept of channel binding as defined in=20 > > draft-williams. > >=20 > > Now, I must say, I do see the similarities between the two=20 > notions of=20 > > channel binding. But the EAP/AAA model is unique and it is=20 > not easy=20 > > to map it to the other, let's say simpler, security models. The=20 > > notion of compound binding or crypto binding also has some=20 > > similarities to the notion of channel binding in=20 > > draft-williams-on-channel-binding-01, but there are also=20 > some differences. > >=20 > > Overall though, since expanding=20 > draft-williams-on-channel-binding-01's > > scope to EAP means that the requirements, recommendations and=20 > > suggestions of Section 2.1 may be applied to EAP channel=20 > binding, it=20 > > would be a rather painful exercise to sort it all out. For=20 > now, I am=20 > > comfortable with the guidance in Section 7.15 of 3748. >=20 > My impression was that Sam's suggested text was introductory=20 > and informative, and not at all intended to cause this doc to=20 > normatively constrain EAP. >=20 > I think that having a single abstraction that can describe=20 > what went by multiple names in different areas can be very=20 > useful because it facilitates cross-area communication. And=20 > missing an opportunity to point out how two things are more=20 > similar than they look would help perpetuate a perception=20 > that those two things are more different than they actually are. >=20 > Nico > --=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Apr 12 18:34:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7sZ-0004gJ-0o; Thu, 12 Apr 2007 18:34:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7sY-0004gE-00 for emu@ietf.org; Thu, 12 Apr 2007 18:34:58 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc7sW-0004kg-LA for emu@ietf.org; Thu, 12 Apr 2007 18:34:57 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGE00FQKPE8SQ@usaga01-in.huawei.com> for emu@ietf.org; Thu, 12 Apr 2007 15:34:56 -0700 (PDT) Received: from N737011 (pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGE00AR6PE3C2@usaga01-in.huawei.com> for emu@ietf.org; Thu, 12 Apr 2007 15:34:56 -0700 (PDT) Date: Thu, 12 Apr 2007 15:34:56 -0700 From: Madjid Nakhjiri Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods In-reply-to: To: 'Stephen Hanna' , emu@ietf.org Message-id: <002d01c77d52$cc7ec9c0$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd1WRVKRTRRuO0cRu+Gidz8w0XnkgAFRdTgAfjmS9A= X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Steve, Sorry for jumping late. Internally within the design team and not having followed this thread, I suggested that we could follow the TTLS path in a way that it meets our requirements. The fact that Paul has agreed to give up control of the draft to IETF is really good news, however, I am a bit confused as how the process you suggested will happen, so let me understand this: We publish the current TTLSv0 as an RFC, and we also publish TTLSvX based on the changes EMU does as a separate RFC in a way that it does not deprecate the first one? (sort of like IKEv1 and IKEv2 scenario?) As good as that sounds to me, the not so rhetorical question would be: wouldn't the two versions still get two different method types? BTW, I am hearing that Paul has promised to add EMSK generation to TTLSv0, so may be TTLSv0 is not quite there yet:)? R, Madjid -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Monday, April 02, 2007 3:00 PM To: emu@ietf.org Subject: [Emu] Re: Thoughts on Password-based EAP Methods Sorry it took me a few days to respond to this thread. I agree with Bernard that there's no benefit in creating Yet Another Password-Based EAP Method (YAPBEM). There's no point in reinventing the wheel for a fourth time and it's not the IETF way. We're not researchers. We're practical engineers who respect running code and rough consensus. So, yes, we should have a bias toward existing, well-tested and well-understood protocols. In a security group, it's especially important to avoid the temptation to reinvent the wheel. We should focus our efforts on one secure tunneled EAP method and make that one secure. We should consider existing methods and only invent something new if we need to. I have spoken to Paul Funk, the primary author of the EAP-TTLSv0 spec. He is glad to proceed as Bernard suggested: 1. Publish an updated EAP-TTLSv0 spec that documents current practice (as Informational or Experimental) 2. Give up change control to the IETF so that the EMU WG can make any necessary changes or additions to EAP-TTLS I'm also glad to assist with this effort, since Paul is pretty busy these days. Thanks, Steve -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Tuesday, March 27, 2007 8:07 AM To: emu@ietf.org Subject: [Emu] Thoughts on Password-based EAP Methods After listening to the IETF 68 presentation on a password-based EAP method, I would like to voice some concerns. Today we already have an "over abundance" of such methods. These include PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my discussions with customers, I invariably hear complaints about this explosion, and about various interoperability and compatibility problems that it causes. Simply put, customers do not want "yet another password-based EAP method"; they want a single method that is widely implemented and interoperable. I am concerned that by defining yet another password-based authentication mechanism, EMU WG will be making this problem worse, not better. Creating yet another mechanism which differs little from the existing ones also seems to have very little chance of being implemented. There is a better alternative that EMU WG should consider. This is to choose an existing method for inclusion on the IETF Standards Track, rather than creating a new one. In order to maintain backward compatibility, this would require that the owners give up change control to the IETF. I would suggest that the best candidate for this would be EAP-TTLSv0, since it is very widely implemented, and has an existing certification program in WFA. Also, EAP-TTLSv0 had previously been on the Standards Track in the PPPEXT WG, before work on EAP methods was removed from the PPPEXT WG charter and the EAP WG was formed. In terms of steps to be taken, this would require the following actions: a. Review and publication of the existing EAP-TTLSv0 specification as an RFC. The goal here would be to document EAP-TTLSv0 as it exists today. b. Agreement by the authors to give up change control to the IETF. c. EMU WG efforts to publish an EAP-TTLSv0 "bis" document, specifying additional capabilities (such as Channel Bindings). _______________________________________________ Emu mailing list Emu at ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Apr 12 18:37:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7uu-0005yH-03; Thu, 12 Apr 2007 18:37:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7ut-0005yC-BF for emu@ietf.org; Thu, 12 Apr 2007 18:37:23 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc7ur-0005MU-UC; Thu, 12 Apr 2007 18:37:23 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGE00F7RPI9SQ@usaga01-in.huawei.com>; Thu, 12 Apr 2007 15:37:21 -0700 (PDT) Received: from N737011 (pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGE00EB5PI3DR@usaga01-in.huawei.com>; Thu, 12 Apr 2007 15:37:21 -0700 (PDT) Date: Thu, 12 Apr 2007 15:37:20 -0700 From: Madjid Nakhjiri Subject: RE: [Emu] Talk on Windows EAP implementation... In-reply-to: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004B82F6A@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> To: 'Ryan Hurst' , emu@ietf.org, eap@ietf.org Message-id: <002e01c77d53$23468450$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acd4cQeg/yf6zV81SPqizGMsWra3oQE4fT1Q X-Spam-Score: 1.4 (+) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1282188491==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============1282188491== Content-type: multipart/alternative; boundary="Boundary_(ID_ArArMU7yELbzmG3qeC7jpw)" This is a multi-part message in MIME format. --Boundary_(ID_ArArMU7yELbzmG3qeC7jpw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Ryan, I see that I just missed this. Is there a recording available? Madjid _____ From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] Sent: Friday, April 06, 2007 10:29 AM To: emu@ietf.org; eap@ietf.org Subject: [Emu] Talk on Windows EAP implementation... I thought folks on these two lists might be interested in this, Microsoft will be having a web chat next week discussing its EAP platform if you want to know more about our implementation and how you can integrate with it this is probably a interesting talk. See: http://blogs.technet.com/nap/archive/2007/04/05/eaphost-and-eap-methods-in-w indows-vista-and-longhorn.aspx Ryan --Boundary_(ID_ArArMU7yELbzmG3qeC7jpw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Ryan,

 

I see that I just missed this. Is = there a recording available?

 

Madjid

 

From: Ryan = Hurst [mailto:Ryan.Hurst@microsoft.com]
Sent: Friday, April 06, = 2007 10:29 AM
To: emu@ietf.org; = eap@ietf.org
Subject: [Emu] Talk on = Windows EAP implementation...

 

I thought folks on these two lists = might be interested in this, Microsoft will be having a web chat next week = discussing its EAP platform if you want to know more about our implementation and = how you can integrate with it this is probably a interesting = talk.

 

See: http://blogs.technet.com/nap/a= rchive/2007/04/05/eaphost-and-eap-methods-in-windows-vista-and-longhorn.a= spx

 

Ryan

 

 

--Boundary_(ID_ArArMU7yELbzmG3qeC7jpw)-- --===============1282188491== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1282188491==-- From emu-bounces@ietf.org Thu Apr 12 22:29:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBXW-0003Nh-PN; Thu, 12 Apr 2007 22:29:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBXV-0003NW-EY; Thu, 12 Apr 2007 22:29:29 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcBXU-0007gi-4c; Thu, 12 Apr 2007 22:29:29 -0400 Received: from [127.0.0.1] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc11) with ESMTP id <20070413022926m11005ftpme>; Fri, 13 Apr 2007 02:29:27 +0000 Message-ID: <461EEB0D.1050109@cs.umd.edu> Date: Thu, 12 Apr 2007 22:29:33 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: hartmans-ietf@mit.edu Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings References: <43960.63.239.69.1.1175884869.squirrel@webmail.cs.umd.edu> <20070406184854.GL28748@Sun.COM> <33203.63.239.69.1.1175886784.squirrel@webmail.cs.umd.edu> <461802C6.1080902@cs.umd.edu> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: bernarda@microsoft.com, ietf@ietf.org, Nicolas Williams , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Mon, April 9, 2007 6:38 pm, hartmans-ietf@mit.edu wrote: >>>>>> "Charles" == Charles Clancy writes: > > Charles> Sam Hartman wrote: > >>>>>>> "Charles" == Charles Clancy writes: > >> > Charles> I don't think I'm convinced that EAP channel bindings are > Charles> doing this binding to the L2 channel. The identity used > Charles> in an EAP channel binding must be bound to the AAA > Charles> security association between the authenticator and the > Charles> peer in order for everything to work, so it would be more > >> I'm not sure I'd describe the association between the peer and > >> authenticator as an AAA association. I agree with the rest. > > Charles> Ah, I mistyped. I meant AAA security association between > Charles> the authenticator and EAP server. > > I'd define the EAP channel binding problem as follows. There are two > sets of identities that the peer and authenticator use: one at the EAP > layer and one at a lower layer. There is an additional identity that > the authenticator may use to authenticate to the AAA server. The > channel binding problem is to make sure that the EAP server authorizes > the authenticator's use of the lower layer identity to the peer and > the peer's use of a given lower layer identity. > > In performing this authorization the EAP server must authorize that > the authenticator is actually allowed to claim the lower layer > identity it wants to claim. I think this is implicit -- you gave the MSK to an authenticator, therefore that authenticator's lower layer (regardless of its identity) is authorized to use that key. Of course, this assumes an authenticator has a single lower layers. I'm not sure the case of multiple lower layers been addressed. EAP could simply forbid it (i.e. one lower layer per authenticator), or say that giving a key to an authenticator authorizes it for all lower layers. > In doing that it will have to make an > authorization decision about whether the identity the authenticator > uses to authenticate to the AAA server is authorized to claim the > given lower layer identity. Currently there's no AAA mechanism for an authenticator to "claim" a lower-layer identity to an EAP server. Lower layer identities would have to be statically provided to the EAP server if the EAP server is going to use them for channel bindings. > However that identity--between the NAS > and the AAA server doesn't inherently appear anywhere else. It sounds > like 802.11R does plan to expose that identity, but that's a design > decision for that lower layer. I guess the point of all my commentary is that the SAP needs to be involved in your discussion of EAP channel bindings. Most cryptographically binds an L2 identities to an EAP key, and some new ones (11r) even bind AAA identities to an EAP key. If EAP channel bindings could include AAA identities, then the peer would actually have enough information to start doing identity comparisons and catch lying NASes. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 13 01:30:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEMj-0006Ui-O7; Fri, 13 Apr 2007 01:30:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEMh-0006UU-Or; Fri, 13 Apr 2007 01:30:31 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcEMh-0001eP-Ce; Fri, 13 Apr 2007 01:30:31 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3D5UUUi017171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Apr 2007 22:30:30 -0700 Received: from [10.50.76.59] (qconnect-10-50-76-59.qualcomm.com [10.50.76.59]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3D5USD7031999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Apr 2007 22:30:28 -0700 Message-ID: <461F1573.2080604@qualcomm.com> Date: Thu, 12 Apr 2007 22:30:27 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings References: <461DCBB1.1010401@qualcomm.com> <20070412151020.GZ28748@Sun.COM> In-Reply-To: <20070412151020.GZ28748@Sun.COM> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: bernarda@microsoft.com, Sam Hartman , ietf@ietf.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Nico, Please see inline: Nicolas Williams wrote: > On Wed, Apr 11, 2007 at 11:03:29PM -0700, Lakshminath Dondeti wrote: >> After having reviewed "draft-williams-on-channel-binding-01," I feel >> that putting EAP in scope of that document would require a rather >> involved revision of the document. As Charles noted it might require >> further abstraction of the concept of channel binding as defined in >> draft-williams. >> >> Now, I must say, I do see the similarities between the two notions of >> channel binding. But the EAP/AAA model is unique and it is not easy to >> map it to the other, let's say simpler, security models. The notion of >> compound binding or crypto binding also has some similarities to the >> notion of channel binding in draft-williams-on-channel-binding-01, but >> there are also some differences. >> >> Overall though, since expanding draft-williams-on-channel-binding-01's >> scope to EAP means that the requirements, recommendations and >> suggestions of Section 2.1 may be applied to EAP channel binding, it >> would be a rather painful exercise to sort it all out. For now, I am >> comfortable with the guidance in Section 7.15 of 3748. > > My impression was that Sam's suggested text was introductory and > informative, and not at all intended to cause this doc to normatively > constrain EAP. The draft is standards track and there is a lot of 2119 language in there. > > I think that having a single abstraction that can describe what went by > multiple names in different areas can be very useful because it > facilitates cross-area communication. And missing an opportunity to > point out how two things are more similar than they look would help > perpetuate a perception that those two things are more different than > they actually are. I can see your point of view. The other thing to worry about is that the more we try to cover under a single abstraction, the more watered down it might become to satisfy all viewpoints of applicability to all of the domains. In fact, I find the requirements and recommendations in the draft troublesome. As I thought about it, perhaps here is something that might make sense: Define channel binding so that we can cover all uses of that term. Define properties and specify how one can achieve those properties. Not sure this next one needs to be done in the current draft, define which properties apply to which protocol. Alternatively, different protocol drafts may specify which of the properties are required or recommended in each case. Does that make sense? I know I am suggesting this, but until something like that is written, I am not sure we can get there (haven't put enough thought into whether a common consensus abstraction is possible here or not). As I noted in my review of your draft, EAP model is different from some of the other security models in the IETF. best regards, Lakshminath > > Nico _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 13 12:07:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOJT-0006Lg-1y; Fri, 13 Apr 2007 12:07:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOJS-0006Lb-4t for emu@ietf.org; Fri, 13 Apr 2007 12:07:50 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOJQ-000885-R5 for emu@ietf.org; Fri, 13 Apr 2007 12:07:50 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 13 Apr 2007 09:07:48 -0700 X-IronPort-AV: i="4.14,408,1170662400"; d="scan'208"; a="411212606:sNHT44273872" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3DG7mld026978 for ; Fri, 13 Apr 2007 09:07:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3DG7mwn002947 for ; Fri, 13 Apr 2007 16:07:48 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 09:07:47 -0700 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 Date: Fri, 13 Apr 2007 09:07:46 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D803DE3636@xmb-sjc-222.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thoughts on Password-based EAP Methods Thread-Index: Acd9jOAEVUItwvlvRZOsZ1tJNF6X4gAV6LFA From: "Nancy Winget \(ncamwing\)" To: X-OriginalArrivalTime: 13 Apr 2007 16:07:48.0090 (UTC) FILETIME=[E119DDA0:01C77DE5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=654; t=1176480468; x=1177344468; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ncamwing@cisco.com; z=From:=20=22Nancy=20Winget=20\(ncamwing\)=22=20 |Subject:=20Re=3A=20Thoughts=20on=20Password-based=20EAP=20Methods |Sender:=20; bh=1MHz2LmOF7v8496i1JwJxJOznRCzcrkV+XFqGa+LuV8=; b=FtOHaFRKIBPAFPurs7eGFLBXx1pelNcCGqSCCAI6T0X6BU0qJSLf0Coq+7Sv0gk0wYwJtH7c JM1J8TSjZ8ynveqLFE38Ur5l+18WajVxWndnYlQLj97pE+VZklStOfna; Authentication-Results: sj-dkim-5; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Emu] Re: Thoughts on Password-based EAP Methods X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi, Though I agree with Bernard's sentiment that there are already many EAP password-based methods, I do not understand why considering TTLS is the right path to pursue. =20 >From reading the thread, there is a sentiment that none of these methods meet "all requirements" sought by the group charter and as such, any method in existence would have to be modified sufficiently to classify it as a "new EAP method". That said, if we are going to use any existing EAP method as a *basis* for the new one, there are better methods than TTLS that better meet the current set of requirements, EAP-FAST is one such example. Nancy. =20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 13 16:46:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcSf5-00035C-Qp; Fri, 13 Apr 2007 16:46:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcSf5-00034g-GX for emu@ietf.org; Fri, 13 Apr 2007 16:46:27 -0400 Received: from revol2.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HcSf3-0002lT-NB for emu@ietf.org; Fri, 13 Apr 2007 16:46:27 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 622B7B8358 for ; Fri, 13 Apr 2007 22:46:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from infres.enst.fr (infres.enst.fr [137.194.160.3]) by smtp2.enst.fr (Postfix) with ESMTP id 2F617B834E for ; Fri, 13 Apr 2007 22:46:20 +0200 (CEST) Received: from VAIO.enst.fr (pptp3-35.enst.fr [137.194.3.35]) by infres.enst.fr (Postfix) with ESMTP id 385F413CBB for ; Fri, 13 Apr 2007 22:46:19 +0200 (MEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Apr 2007 22:46:08 +0200 To: emu@ietf.org From: Pascal Urien Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070413204619.385F413CBB@infres.enst.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Emu] Re: Thoughts on Password-based EAP Methods X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Everybody, The emu working agreed on the fact that a secure channel is needed Item1. - a) Is there a consensus for TTLS (what version ?) - b) Is this possible to push TTLS as an RFC (from an IT point of view) Item2 -c) Do we need a new password based method ? I agree with Bernard point of view. Many methods already exist. My personal feeling is a=yes, b=yes, c=no I am ready to organize a meeting in Paris in June, if the working group intends to debate about these points Best Regards Pascal _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 13 17:08:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcT0I-0003kc-Dd; Fri, 13 Apr 2007 17:08:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcT0H-0003iM-2j for emu@ietf.org; Fri, 13 Apr 2007 17:08:21 -0400 Received: from wx-out-0506.google.com ([66.249.82.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcT0F-0007cH-Pt for emu@ietf.org; Fri, 13 Apr 2007 17:08:21 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1054129wxd for ; Fri, 13 Apr 2007 14:08:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=cX1td5uMXfRm/clF+2HUrQdSQWtp9k6+Hs5eP1GJ1ty8dYV6Ty2DK543mKh0inAnbMR//Mz0dd5ffd0uFXktL+x26eIEi5ko5eKTMEB9emybwTuOPwoMsK3q2aV1haONu3zxo7C3ukmLWnkwUFdK5xDIreDsLG1elWXmwOfYslU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tZPijf/T3arHJRo0LwyPFugxMi6cdXeWFZNMOhFnT3uUV+3pG+Xs7qprP93TVzFYR69KpQHGrQATdgsE+aKGXA5otFkXs1FZeTBmfqsDYmSakhx3ZRtvTRA3n3Hzf5osYlvRTmDSKapOSPXNa6mHpOqBzVGJSfgqeq/HV174bPA= Received: by 10.78.205.7 with SMTP id c7mr729176hug.1176498498280; Fri, 13 Apr 2007 14:08:18 -0700 (PDT) Received: by 10.78.67.13 with HTTP; Fri, 13 Apr 2007 14:08:18 -0700 (PDT) Message-ID: Date: Fri, 13 Apr 2007 23:08:18 +0200 From: Badra To: "Pascal Urien" Subject: Re: [Emu] Re: Thoughts on Password-based EAP Methods In-Reply-To: <20070413204619.385F413CBB@infres.enst.fr> MIME-Version: 1.0 References: <20070413204619.385F413CBB@infres.enst.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1443157002==" Errors-To: emu-bounces@ietf.org --===============1443157002== Content-Type: multipart/alternative; boundary="----=_Part_11218_32219628.1176498498201" ------=_Part_11218_32219628.1176498498201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Since Nancy comments are reasonable and that EAP-FAST is designed in a nice fashion, I think it is good to add it as option d) Best regards, Badra On 4/13/07, Pascal Urien wrote: > > Hi Everybody, > > The emu working agreed on the fact that a secure channel is needed > > Item1. > > - a) Is there a consensus for TTLS (what version ?) > - b) Is this possible to push TTLS as an RFC (from an IT point of > view) > > Item2 > -c) Do we need a new password based method ? > I agree with Bernard point of view. Many methods already exist. > > My personal feeling is > a=yes, b=yes, c=no > > I am ready to organize a meeting in Paris in June, if the working > group intends to debate about these points > > Best Regards > > Pascal > > > > > > > > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu ------=_Part_11218_32219628.1176498498201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Since Nancy comments are reasonable and that EAP-FAST is designed in a nice fashion, I think it is good to add it as option d)
 
Best regards,
Badra
 
On 4/13/07, Pascal Urien <Pascal.Urien@enst.fr> wrote:
Hi Everybody,

The emu working agreed on the fact that a secure channel is needed

Item1.

   - a)  Is there a consensus for TTLS (what version ?)
   - b) Is this possible to push   TTLS as an RFC (from an IT point of view)

Item2
-c) Do we need a new password based method ?
      I agree with Bernard point of view. Many methods already exist.

My personal feeling  is
a=yes, b=yes, c=no

I am ready to organize a meeting  in Paris in June, if the working
group intends to debate about these points

Best Regards

Pascal










_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
------=_Part_11218_32219628.1176498498201-- --===============1443157002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1443157002==-- From emu-bounces@ietf.org Fri Apr 13 17:12:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcT4a-0004D9-Fh; Fri, 13 Apr 2007 17:12:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcT4Z-0004D2-Q0 for emu@ietf.org; Fri, 13 Apr 2007 17:12:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcT4W-0000UQ-RO for emu@ietf.org; Fri, 13 Apr 2007 17:12:47 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2007 17:12:45 -0400 X-IronPort-AV: i="4.14,409,1170651600"; d="scan'208"; a="57626910:sNHT50109956" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3DLCisl020983; Fri, 13 Apr 2007 17:12:44 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3DLBelU002527; Fri, 13 Apr 2007 21:12:44 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 17:12:30 -0400 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: [Emu] Re: Thoughts on Password-based EAP Methods Date: Fri, 13 Apr 2007 17:12:31 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B704327356@xmb-rtp-212.amer.cisco.com> In-Reply-To: <20070413204619.385F413CBB@infres.enst.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Re: Thoughts on Password-based EAP Methods Thread-Index: Acd+DNLf9sdXAVpWSqG6cZOqrbf81QAAMsxg References: <20070413204619.385F413CBB@infres.enst.fr> From: "Hao Zhou \(hzhou\)" To: "Pascal Urien" , X-OriginalArrivalTime: 13 Apr 2007 21:12:30.0315 (UTC) FILETIME=[722803B0:01C77E10] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2596; t=1176498764; x=1177362764; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20\(hzhou\)=22=20 |Subject:=20RE=3A=20[Emu]=20Re=3A=20Thoughts=20on=20Password-based=20EAP= 20Methods |Sender:=20 |To:=20=22Pascal=20Urien=22=20,=20; bh=SfhAKY2r35YzjPN1rwy9rl6QT112OOwXhYDhiRhZkVM=; b=IbzrYioIBg/Q6iN14l1xt3RRxifPFx77lWaF5L3iaLIVdkQodXJXjv8P/5kM6OmYu/fUzZlI y1p6ZH5lFoNaDwEu1E9vy5VBASi4JCWLp/a9baGqJcLZuus7dKh3JK1k; Authentication-Results: rtp-dkim-2; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org While I agree that we probably don't need another password based method, I firmly believe that we need a standard base method provides more extensibility beyond password based authentication, for instance, channel binding, exchange protected data, crypto-agility, etc. Past experience tells me that if we don't define a standard one to address this, someone will come up with proprietary solution and we will end up with multiple methods again. TTLS, PEAP, EAP-FAST are early attempts. We will keep making the same mistakes. That's why I think addressing password authentication should not be the only goal, but addressing the standard extension points might be the more important goal here. Addressing password authentication should be trivial, as we already have working protocol. Just like TLS is being used as a framework, I like to have a standard EAP tunnel method that is extensible, extensible on the tunnel establishment as well as inside the tunnel. Since the extension points are standardized and extensions need to go thru IETF process and publishing, this will ensure better interoperability. That's why I think we need to take a look at both the password based method and enhanced TLS based method requirements together, and maybe with some requirements outside the current WG charter, and come up with a standard tunneling method that's extensible. As far as the basis for such method, I don't think we have consensus towards TTLS. We need to judge them base on the requirements and each candidate's merits. > -----Original Message----- > From: Pascal Urien [mailto:Pascal.Urien@enst.fr]=20 > Sent: Friday, April 13, 2007 4:46 PM > To: emu@ietf.org > Subject: [Emu] Re: Thoughts on Password-based EAP Methods >=20 > Hi Everybody, >=20 > The emu working agreed on the fact that a secure channel is needed >=20 > Item1. >=20 > - a) Is there a consensus for TTLS (what version ?) > - b) Is this possible to push TTLS as an RFC (from an=20 > IT point of view) >=20 > Item2 > -c) Do we need a new password based method ? > I agree with Bernard point of view. Many methods already exist. >=20 > My personal feeling is > a=3Dyes, b=3Dyes, c=3Dno >=20 > I am ready to organize a meeting in Paris in June, if the=20 > working group intends to debate about these points >=20 > Best Regards >=20 > Pascal >=20 >=20 >=20 >=20 >=20 >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 13 18:10:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTyJ-0006T6-Cm; Fri, 13 Apr 2007 18:10:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTyI-0006Sz-KU for emu@ietf.org; Fri, 13 Apr 2007 18:10:22 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcTyI-000812-8l for emu@ietf.org; Fri, 13 Apr 2007 18:10:22 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 13 Apr 2007 15:10:21 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.685.25; Fri, 13 Apr 2007 15:10:21 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Apr 2007 15:10:19 -0700 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: [Emu] Re: Thoughts on Password-based EAP Methods Date: Fri, 13 Apr 2007 15:09:51 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004CB1A0D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9958B444368E884DBB215F3FEF36F5B704327356@xmb-rtp-212.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Re: Thoughts on Password-based EAP Methods Thread-Index: Acd+DNLf9sdXAVpWSqG6cZOqrbf81QAAMsxgAAKZG6A= References: <20070413204619.385F413CBB@infres.enst.fr> <9958B444368E884DBB215F3FEF36F5B704327356@xmb-rtp-212.amer.cisco.com> From: Ryan Hurst To: "Hao Zhou (hzhou)" , Pascal Urien , X-OriginalArrivalTime: 13 Apr 2007 22:10:19.0310 (UTC) FILETIME=[85D6A4E0:01C77E18] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I agree that if there is not a standards based approach to choose proprietary solutions will be implemented, I also agree that addressing the password based authentication is not the only problem here. I also think there is need for a standards based tunneled EAP method also. I for one support the standardization of a TTLS that addresses channel binding, crypto binding, etc. Ryan -----Original Message----- From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com]=20 Sent: Friday, April 13, 2007 2:13 PM To: Pascal Urien; emu@ietf.org Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods While I agree that we probably don't need another password based method, I firmly believe that we need a standard base method provides more extensibility beyond password based authentication, for instance, channel binding, exchange protected data, crypto-agility, etc. Past experience tells me that if we don't define a standard one to address this, someone will come up with proprietary solution and we will end up with multiple methods again. TTLS, PEAP, EAP-FAST are early attempts. We will keep making the same mistakes. That's why I think addressing password authentication should not be the only goal, but addressing the standard extension points might be the more important goal here. Addressing password authentication should be trivial, as we already have working protocol. Just like TLS is being used as a framework, I like to have a standard EAP tunnel method that is extensible, extensible on the tunnel establishment as well as inside the tunnel. Since the extension points are standardized and extensions need to go thru IETF process and publishing, this will ensure better interoperability. That's why I think we need to take a look at both the password based method and enhanced TLS based method requirements together, and maybe with some requirements outside the current WG charter, and come up with a standard tunneling method that's extensible. As far as the basis for such method, I don't think we have consensus towards TTLS. We need to judge them base on the requirements and each candidate's merits. > -----Original Message----- > From: Pascal Urien [mailto:Pascal.Urien@enst.fr]=20 > Sent: Friday, April 13, 2007 4:46 PM > To: emu@ietf.org > Subject: [Emu] Re: Thoughts on Password-based EAP Methods >=20 > Hi Everybody, >=20 > The emu working agreed on the fact that a secure channel is needed >=20 > Item1. >=20 > - a) Is there a consensus for TTLS (what version ?) > - b) Is this possible to push TTLS as an RFC (from an=20 > IT point of view) >=20 > Item2 > -c) Do we need a new password based method ? > I agree with Bernard point of view. Many methods already exist. >=20 > My personal feeling is > a=3Dyes, b=3Dyes, c=3Dno >=20 > I am ready to organize a meeting in Paris in June, if the=20 > working group intends to debate about these points >=20 > Best Regards >=20 > Pascal >=20 >=20 >=20 >=20 >=20 >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 13 19:05:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcUpH-0006JB-LB; Fri, 13 Apr 2007 19:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcUpH-0006Hv-33; Fri, 13 Apr 2007 19:05:07 -0400 Received: from stratton-six-fourteen.mit.edu ([18.187.7.103] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcUpE-0003D1-Qf; Fri, 13 Apr 2007 19:05:07 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CD5884998; Fri, 13 Apr 2007 19:05:03 -0400 (EDT) From: Sam Hartman To: Lakshminath Dondeti Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings References: <461DCBB1.1010401@qualcomm.com> <20070412151020.GZ28748@Sun.COM> <461F1573.2080604@qualcomm.com> Date: Fri, 13 Apr 2007 19:05:03 -0400 In-Reply-To: <461F1573.2080604@qualcomm.com> (Lakshminath Dondeti's message of "Thu, 12 Apr 2007 22:30:27 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: bernarda@microsoft.com, ietf@ietf.org, Nicolas Williams , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >>>>> "Lakshminath" == Lakshminath Dondeti writes: >> I think that having a single abstraction that can describe >> what went by multiple names in different areas can be very >> useful because it facilitates cross-area communication. And >> missing an opportunity to point out how two things are more >> similar than they look would help perpetuate a perception that >> those two things are more different than they actually are. Lakshminath> I can see your point of view. The other thing to Lakshminath> worry about is that the more we try to cover under a Lakshminath> single abstraction, the more watered down it might Lakshminath> become to satisfy all viewpoints of applicability to Lakshminath> all of the domains. In fact, I find the requirements Lakshminath> and recommendations in the draft troublesome. Lakshminath> As I thought about it, perhaps here is something that Lakshminath> might make sense: Lakshminath> Define channel binding so that we can cover all uses Lakshminath> of that term. Define properties and specify how one Lakshminath> can achieve those properties. Not sure this next one Lakshminath> needs to be done in the current draft, define which Lakshminath> properties apply to which protocol. Alternatively, Lakshminath> different protocol drafts may specify which of the Lakshminath> properties are required or recommended in each case. Lakshminath> Does that make sense? That makes sense; I think that is exactly what we're doing. I continue to believe, having read all the messages here that my original text is very close to correct in describing the EAP channel bindings problems. I'd love to talk to someone off-line to discuss this, because there is some obvious confusion somewhere. The more I read what you, Bernard and Charles say, the more I'm convinced that I agree with your description of EAP and that my text is correct. The more I talk, the more you're convinced that my text is wrong. We're talking past each other somehow. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 13 19:52:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcVYw-0000gE-HC; Fri, 13 Apr 2007 19:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcVYt-0000fz-E3; Fri, 13 Apr 2007 19:52:15 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcVYs-0003Z6-4O; Fri, 13 Apr 2007 19:52:15 -0400 Received: from [127.0.0.1] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc14) with ESMTP id <20070413235212m1400imquoe>; Fri, 13 Apr 2007 23:52:13 +0000 Message-ID: <462017B1.7070705@cs.umd.edu> Date: Fri, 13 Apr 2007 19:52:17 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings References: <461DCBB1.1010401@qualcomm.com> <20070412151020.GZ28748@Sun.COM> <461F1573.2080604@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: bernarda@microsoft.com, ietf@ietf.org, Nicolas Williams , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Sam Hartman wrote: > The more I > read what you, Bernard and Charles say, the more I'm convinced that I > agree with your description of EAP and that my text is correct. The > more I talk, the more you're convinced that my text is wrong. > We're talking past each other somehow. I think your text was correct, but incomplete. I think the SAP needs to be included, as it does channel bindings under Nico's broader definition. The SAP does an EAP lower-layer to EAP layer binding -- it just doesn't provide the authorization you're looking for, hence why we need EAP channel bindings to prevent the lying NAS problem. Sam's suggested text: The first, called channel binding, is used to bind the lower-layer channel created between the peer and the authenticator to the authentication performed using EAP. Specific detials of this facility have not been specified, but it is likely that this channel would use endpoint channel bindings carried in the EAP method exchange. My suggestion for Sam's suggested text: The first, called channel binding, is used to bind the lower-layer channel created between the peer and the authenticator to the authentication performed using EAP. The Secure Association Protocol (SAP) defined by the EAP lower layer often binds lower-layer identities and sometimes even AAA identities into the key derivation, serving to bind EAP keys to the EAP lower layer. However, as this binding is done by the lower layer, and not EAP, there is no explicit authorization by the EAP server for the lower layer to use the EAP keys. Consequently, EAP channel bindings are defined in RFC 3748 to perform the binding at the EAP layer. Specific details of this facility have not been specified, but it is likely that this channel would use endpoint channel bindings carried in the EAP method exchange. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Apr 14 15:30:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcnxG-00017p-Ks; Sat, 14 Apr 2007 15:30:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcnxF-00016v-1c for emu@ietf.org; Sat, 14 Apr 2007 15:30:37 -0400 Received: from bay0-omc1-s17.bay0.hotmail.com ([65.54.246.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcnxD-0006P6-Nh for emu@ietf.org; Sat, 14 Apr 2007 15:30:37 -0400 Received: from hotmail.com ([207.46.8.117]) by bay0-omc1-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 14 Apr 2007 12:30:35 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 14 Apr 2007 12:30:35 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Sat, 14 Apr 2007 19:30:32 GMT X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <9958B444368E884DBB215F3FEF36F5B704327356@xmb-rtp-212.amer.cisco.com> From: "Bernard Aboba" To: Pascal.Urien@enst.fr, emu@ietf.org Bcc: Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods Date: Sat, 14 Apr 2007 12:30:32 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 14 Apr 2007 19:30:35.0014 (UTC) FILETIME=[5F90E260:01C77ECB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >I am ready to organize a meeting in Paris in June, if the working group >intends to debate about >these points Paris in June (or any time, really) sounds wonderful. However, if the idea is to focus people on work, without the distractions created by art, music, good food and inspiring architecture, then other places (such as a Motel 6 in Newark, New Jersey) may work better :) _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Apr 14 15:34:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hco1R-00039v-MD; Sat, 14 Apr 2007 15:34:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hco1Q-00039n-GZ for emu@ietf.org; Sat, 14 Apr 2007 15:34:56 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hco1P-0007NY-6S for emu@ietf.org; Sat, 14 Apr 2007 15:34:56 -0400 Received: by ug-out-1314.google.com with SMTP id 72so623607ugd for ; Sat, 14 Apr 2007 12:34:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JXSq/wVi5qMkYeFlEnxv5/Ixo/V0Cf0OFU5ZyP87lggTaTY+sYW2yMjGQyKFLOP04SdrZ+8Jcn8MyY/p/Fh6LruxtvtAEVJeGIwjzptRTS2F842rcbC7DF0Au8ug6+eRs3A3cCq7XxEoLRVHk3qedqyg9TQjr04x4XjP9wSimhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=k7GtcsaqJTSIOugY6z8db6MqSQZPQ0o7EYbOP0GPEzJ+i5PGjEpALajo5a4vxv15sCE9Kc0oOQjkal9bsINki9w2XykyGsXUY/Czn8L0rdL714spBlsc3AQb3GuEPMBBb/WqG0is1Bwa6LzyPdxQSMXPY3WqAXiFSfkEwogKN5E= Received: by 10.67.97.7 with SMTP id z7mr2981319ugl.1176579294446; Sat, 14 Apr 2007 12:34:54 -0700 (PDT) Received: by 10.67.23.14 with HTTP; Sat, 14 Apr 2007 12:34:54 -0700 (PDT) Message-ID: Date: Sat, 14 Apr 2007 12:34:54 -0700 From: "Clint Chaplin" To: "Bernard Aboba" Subject: Re: [Emu] Re: Thoughts on Password-based EAP Methods In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9958B444368E884DBB215F3FEF36F5B704327356@xmb-rtp-212.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Right, and make sure there is >no< internet access. It's amazing how much work can get done when none of the participants have their head buried in a laptop answering email. Of course, there are some people who you don't want to be engaged in the discussion... On 4/14/07, Bernard Aboba wrote: > >I am ready to organize a meeting in Paris in June, if the working group > >intends to debate about >these points > > Paris in June (or any time, really) sounds wonderful. However, if the idea > is to focus people on work, without the distractions created by art, music, > good food and inspiring architecture, then other places (such as a Motel 6 > in Newark, New Jersey) may work better :) > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Apr 14 15:53:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcoJk-0002in-UX; Sat, 14 Apr 2007 15:53:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcoJk-0002ii-9f for emu@ietf.org; Sat, 14 Apr 2007 15:53:52 -0400 Received: from bay0-omc3-s16.bay0.hotmail.com ([65.54.246.216]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcoJh-0005R6-UY for emu@ietf.org; Sat, 14 Apr 2007 15:53:52 -0400 Received: from hotmail.com ([207.46.8.113]) by bay0-omc3-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 14 Apr 2007 12:53:49 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 14 Apr 2007 12:53:49 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Sat, 14 Apr 2007 19:53:47 GMT X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20070413204619.385F413CBB@infres.enst.fr> From: "Bernard Aboba" To: Pascal.Urien@enst.fr, emu@ietf.org Bcc: Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods Date: Sat, 14 Apr 2007 12:53:47 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 14 Apr 2007 19:53:49.0103 (UTC) FILETIME=[9E81FBF0:01C77ECE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >The emu working agreed on the fact that a secure channel is needed > > Item1. > > - a) Is there a consensus for TTLS (what version ?) > - b) Is this possible to push TTLS as an RFC (from an IT point of >view) > > Item2 > -c) Do we need a new password based method ? > I agree with Bernard point of view. Many methods already exist. > >My personal feeling is >a=yes, b=yes, c=no I agree with this. With respect to a) there is realy only one deployed version of EAP-TTLS, namely EAP-TTLSv0. EAP-TTLSv1 has not been implemented. So that is probably the place to start. With respect to b), a fothcoming version of the EAP-TTLSv0 specification will be submitted for publication as an RFC. This will address questions from implementers and address the need for a stable reference from WiMAX Forum, OMA, TNC and other organizations that are incorporating EAP-TTLSv0 into their standards. With respect to c), one needs to take several factors into account, such as the certification/testing situation, availability of reference implementations and IPR declarations. EAP-TTLSv0 is currently being tested for interoperability by WFA so that a certification program is already in place. As far as I could tell, there is only one IPR declaration relating to EAP-TTLS, and that relates to EAP-TTLSv1, rather than EAP-TTLSv0: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=594 Compare this with the IPR Declarations relating to EAP FAST: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fast.txt http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fast-provisioning-03.txt http://www.ietf.org/ietf/IPR/cisco-ipr-draft-salowey-tls-ticket.txt https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=595 http://www1.ietf.org/ietf/IPR/microsoft-ipr-draft-cam-winget-eap-fast.txt _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 16 11:52:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTVG-0006lz-GR; Mon, 16 Apr 2007 11:52:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTVF-0006lt-8G for emu@ietf.org; Mon, 16 Apr 2007 11:52:29 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTVE-00017W-1T for emu@ietf.org; Mon, 16 Apr 2007 11:52:29 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2007 08:52:28 -0700 X-IronPort-AV: i="4.14,415,1170662400"; d="scan'208"; a="369979458:sNHT41613132" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3GFqRSr027980 for ; Mon, 16 Apr 2007 08:52:27 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l3GFqNEo016879 for ; Mon, 16 Apr 2007 15:52:27 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 08:52:24 -0700 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 Date: Mon, 16 Apr 2007 08:52:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2716bis Section 5.2. Peer and Server Identities Thread-Index: AceAPzbzoVbC5QguTmaNZd9+oXoHwg== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 16 Apr 2007 15:52:24.0772 (UTC) FILETIME=[39FFF840:01C7803F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=262; t=1176738747; x=1177602747; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RFC=202716bis=20Section=205.2.=20=20Peer=20and=20Server=20Ide ntities |Sender:=20; bh=LOgZ1/0SB3E5+c3C2YcFiRLIoLzt0Aj6tSf6ra+84Nw=; b=xJii5TSPFfUNxubKFuOkvImOLIop/2wY3YyAeGGaNBDNhjtG1Org7QG3HWNaG9mePKs5O1Ml 89BE5tilrG6EnbczLDwCApkBpUdSpjb+jGOmYBsaAqp57rlj0xcxnc90; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Emu] RFC 2716bis Section 5.2. Peer and Server Identities X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org At the meeting in Prague we had some discussion on the contents of section 5.2 of RFC2716bis. Section 5.2 of draft-simon-emu-rfc2716bis-08.txt looks to be acceptable according to the discussion. Do people approve of or object to the text in section 5.2? _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 16 14:25:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVtN-00050U-VE; Mon, 16 Apr 2007 14:25:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVtL-0004zc-UJ for emu@ietf.org; Mon, 16 Apr 2007 14:25:31 -0400 Received: from bay0-omc1-s26.bay0.hotmail.com ([65.54.246.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdVtJ-0002mz-H8 for emu@ietf.org; Mon, 16 Apr 2007 14:25:31 -0400 Received: from hotmail.com ([207.46.8.88]) by bay0-omc1-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 16 Apr 2007 11:25:29 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 16 Apr 2007 11:25:29 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 16 Apr 2007 18:25:27 GMT X-Originating-IP: [131.107.0.74] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Subject: RE: [Emu] RFC 2716bis Section 5.2. Peer and Server Identities Date: Mon, 16 Apr 2007 11:25:27 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 16 Apr 2007 18:25:29.0014 (UTC) FILETIME=[9C3C1560:01C78054] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org To refresh people's memories, here is what is in Section 5.2: 5.2. Peer and Server Identities The EAP-TLS peer name (Peer-Id) represents the identity to be used for access control and accounting purposes. The Server-Id represents the identity of the EAP server. In EAP-TLS, the Peer-Id and Server-Id are determined from the subject or subjectAltName fields in the peer and server certificates. For details, see [RFC3280] Section 4.1.2.6. Where the subjectAltName field is present in the peer or server certificate, the Peer-Id or Server-Id MUST be set to the contents of the subjectAltName as described in Section 5.3. If subject naming information is present only in the subjectAltName extension of a peer or server certificate, then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical. Although the use of the subject name field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. Where it is non-empty, the subject name field MUST contain an X.500 distinguished name (DN). Where the peer identity represents a host, a subjectAltName of type dnsName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1. If a dnsName or rfc822Name are not available other field types (for example a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used. A server identity will typically represent a host, not a user or a resource. As a result, a subjectAltName of type dnsName SHOULD be present in the server certificate. If a dnsName is not available other field types (for example a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used. If subject naming information is present only in the subject name field and the peer identity represents a user, then the subject name field SHOULD contain an emailAddress RDN. If the peer identity represents a host or device the subject name field SHOULD contain a CN RDN or serialNumber RDN. If subject naming information is present only in the subject name field of a server certificate, then the subject name field MUST contain a CN RDN or serialNumber RDN. >From: "Joseph Salowey (jsalowey)" >To: >Subject: [Emu] RFC 2716bis Section 5.2. Peer and Server Identities >Date: Mon, 16 Apr 2007 08:52:19 -0700 > >At the meeting in Prague we had some discussion on the contents of >section 5.2 of RFC2716bis. Section 5.2 of >draft-simon-emu-rfc2716bis-08.txt looks to be acceptable according to >the discussion. Do people approve of or object to the text in section >5.2? > > > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 16 17:23:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYf7-0006Zj-1B; Mon, 16 Apr 2007 17:23:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYf5-0006W7-9n; Mon, 16 Apr 2007 17:22:59 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdYf3-0006N4-SQ; Mon, 16 Apr 2007 17:22:59 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3GLMvbB018179; Mon, 16 Apr 2007 21:22:57 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3GLMuUV016399; Mon, 16 Apr 2007 15:22:57 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3GLLxSa007433; Mon, 16 Apr 2007 16:21:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3GLLwO4007432; Mon, 16 Apr 2007 16:21:58 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 16 Apr 2007 16:21:58 -0500 From: Nicolas Williams To: Charles Clancy Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings Message-ID: <20070416212157.GE12328@Sun.COM> References: <461DCBB1.1010401@qualcomm.com> <20070412151020.GZ28748@Sun.COM> <461F1573.2080604@qualcomm.com> <462017B1.7070705@cs.umd.edu> <20070416061032.GS4375@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070416061032.GS4375@Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: bernarda@microsoft.com, Sam Hartman , ietf@ietf.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Mon, Apr 16, 2007 at 01:10:32AM -0500, Nicolas Williams wrote: > - New text about EAP channel binding Actually, some of that text is incorrect -- I misunderstood the lying NAS issue: it's not about MITM attacks but about making sure that the client knows the correct name for the NAS so that it can make authorization decisions based on it (e.g., applying a specific firewall policy). I'll fix the text and re-send. Nico -- _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 17 12:07:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqDG-0004Yl-Ab; Tue, 17 Apr 2007 12:07:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqDF-0004Ye-BX for emu@ietf.org; Tue, 17 Apr 2007 12:07:25 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdqDC-0003JN-Vg for emu@ietf.org; Tue, 17 Apr 2007 12:07:25 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2007 12:07:05 -0400 X-IronPort-AV: i="4.14,419,1170651600"; d="scan'208"; a="57866849:sNHT47236383636" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3HG72X5023542; Tue, 17 Apr 2007 12:07:02 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3HG6Qlk021078; Tue, 17 Apr 2007 16:07:02 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 12:06:36 -0400 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: [Emu] Re: Thoughts on Password-based EAP Methods Date: Tue, 17 Apr 2007 12:06:27 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B7043A1FAC@xmb-rtp-212.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Re: Thoughts on Password-based EAP Methods Thread-Index: Acd+zqSqcVI9/LVVQGGmdIWzpdowUQCOkYNQ References: <20070413204619.385F413CBB@infres.enst.fr> From: "Hao Zhou \(hzhou\)" To: "Bernard Aboba" , , X-OriginalArrivalTime: 17 Apr 2007 16:06:36.0593 (UTC) FILETIME=[60234A10:01C7810A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3341; t=1176826023; x=1177690023; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20\(hzhou\)=22=20 |Subject:=20RE=3A=20[Emu]=20Re=3A=20Thoughts=20on=20Password-based=20EAP= 20Methods |Sender:=20 |To:=20=22Bernard=20Aboba=22=20, =20,=0A=20=20=20=20=20=20=20=20; bh=/wp+scehL/J/y9P4Iq6XSk47BTqPQujMdspH4RjW8rg=; b=NobX4U0lr2DvC2dJpSRnURja7CEv7DaBu1qToV22sLijZHZjheb9+W0cbLgMephmFICEEaSX uZnKS5pRZW/cpAYnLm4ftGG3vkSydbIcG8XoJgANCvTXYWS+pn1eSlS3; Authentication-Results: rtp-dkim-1; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Bernard: With regard to the IPR issue on TTLS and EAP-FAST, I believe they share the common declaration related to a Nokia Patent. As far as I can tell, it is somewhat related to crypto-binding. Although it is only put on TTLSv1 (as TTLSv0 doesn't address crypto-binding), I believe that if we need to address crypto-binding in the standard RFC, we will face the same IPR. As for rest of the IPR declarations on EAP-FAST, they are all related to the use of TLS ticket and provisioning of additional credentials. They may not end up in or be optional features in the standard RFC method. If we bring these features in to the standard RFC method, we will be likely facing the same IPRs, regardless which draft method to base on. Last, IPR doesn't necessary prevent protocol becomes standard. There is plenty example of protocols with Cisco IPR in the standard track.=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Saturday, April 14, 2007 3:54 PM > To: Pascal.Urien@enst.fr; emu@ietf.org > Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods >=20 > >The emu working agreed on the fact that a secure channel is needed > > > > Item1. > > > > - a) Is there a consensus for TTLS (what version ?) > > - b) Is this possible to push TTLS as an RFC (from an=20 > IT point of > >view) > > > > Item2 > > -c) Do we need a new password based method ? > > I agree with Bernard point of view. Many methods=20 > already exist. > > > >My personal feeling is > >a=3Dyes, b=3Dyes, c=3Dno >=20 > I agree with this. >=20 > With respect to a) there is realy only one deployed version=20 > of EAP-TTLS, namely EAP-TTLSv0. EAP-TTLSv1 has not been=20 > implemented. So that is probably the place to start. >=20 > With respect to b), a fothcoming version of the EAP-TTLSv0=20 > specification will be submitted for publication as an RFC. =20 > This will address questions from implementers and address the=20 > need for a stable reference from WiMAX Forum, OMA, TNC and=20 > other organizations that are incorporating EAP-TTLSv0 into=20 > their standards. >=20 > With respect to c), one needs to take several factors into=20 > account, such as the certification/testing situation,=20 > availability of reference implementations and IPR=20 > declarations. EAP-TTLSv0 is currently being tested for=20 > interoperability by WFA so that a certification program is=20 > already in place. As far as I could tell, there is only one=20 > IPR declaration relating to EAP-TTLS, and that relates to=20 > EAP-TTLSv1, rather than EAP-TTLSv0: > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D594 >=20 > Compare this with the IPR Declarations relating to EAP FAST: > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fast.txt > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fa > st-provisioning-03.txt > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-salowey-tls-ticket.txt > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D595 > http://www1.ietf.org/ietf/IPR/microsoft-ipr-draft-cam-winget-e > ap-fast.txt >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 18 16:22:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeGfr-0004BV-RX; Wed, 18 Apr 2007 16:22:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeGfp-0003vZ-9o for emu@ietf.org; Wed, 18 Apr 2007 16:22:41 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeGfg-0001p0-UF for emu@ietf.org; Wed, 18 Apr 2007 16:22:40 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 18 Apr 2007 13:22:32 -0700 X-IronPort-AV: i="4.14,423,1170662400"; d="scan'208"; a="769539798:sNHT44210830" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3IKMWFr009796 for ; Wed, 18 Apr 2007 13:22:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3IKMUMZ005794 for ; Wed, 18 Apr 2007 20:22:32 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 13:22:31 -0700 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 Date: Wed, 18 Apr 2007 13:22:30 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments on EAP-GPSK Thread-Index: AceB90n1zoo7v+8yTcePy0bIJgf2Xg== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 18 Apr 2007 20:22:31.0266 (UTC) FILETIME=[4AA63420:01C781F7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=740; t=1176927752; x=1177791752; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20Some=20comments=20on=20EAP-GPSK |Sender:=20; bh=gJVqrIwUSjq+O1jYhDaf8o0eZHzCtHKnDdUtEQfakvc=; b=BvThzp+hkJQtX2xI0zj98UzvqTfc7CVDjeeOI2kjY2FIwQeZ54fSFoTfLkv6j2vYUAMEcuJ/ Ci/j0PLMtoKiqsllB9vNvwJaUrvQYGH03Js1lb9X1XhIIz9nukSM0Amd; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Emu] Some comments on EAP-GPSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I think the document is in good shape, but I have a few minor comments: 1. The document defines vendor OID. What is this intended to be, is the SMI OID? I think the document needs to specify what the registry is. =20 2. There is no IANA registry created for OP-CODES 3. Are both the PSK not found and authentication error codes necessary. It appears that the "PSK not found" error is equivalent to "bad username". Perhaps this is not as much of an issue with a PSK as with a password, but it may allow an attacker to probe for valid "accounts".=20 4. It seems that there should be a reference to AES.=20 5. It seems that the server-ID is a user-visible field and should be encoded in UTF-8.=20 Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 18 17:34:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHn8-0005GC-Ul; Wed, 18 Apr 2007 17:34:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHn7-0005G7-Ny for emu@ietf.org; Wed, 18 Apr 2007 17:34:17 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHn5-0002jA-S0 for emu@ietf.org; Wed, 18 Apr 2007 17:34:17 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGP003PCQL3ZD@usaga01-in.huawei.com> for emu@ietf.org; Wed, 18 Apr 2007 14:34:15 -0700 (PDT) Received: from N737011 (pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGP00KB6QKWXU@usaga01-in.huawei.com> for emu@ietf.org; Wed, 18 Apr 2007 14:34:15 -0700 (PDT) Date: Wed, 18 Apr 2007 14:34:13 -0700 From: Madjid Nakhjiri Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods In-reply-to: To: 'Bernard Aboba' , Pascal.Urien@enst.fr, emu@ietf.org Message-id: <000301c78201$5121b450$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd+y2fmvLP0evkKRiKv1Yw6jeW7hgDNbozg X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I guess this explains all the motivation behind March Minnesota IETFs:) -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Saturday, April 14, 2007 12:31 PM To: Pascal.Urien@enst.fr; emu@ietf.org Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods >I am ready to organize a meeting in Paris in June, if the working group >intends to debate about >these points Paris in June (or any time, really) sounds wonderful. However, if the idea is to focus people on work, without the distractions created by art, music, good food and inspiring architecture, then other places (such as a Motel 6 in Newark, New Jersey) may work better :) _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 18 17:43:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHwT-0007YC-Q1; Wed, 18 Apr 2007 17:43:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHwS-0007WL-JK for emu@ietf.org; Wed, 18 Apr 2007 17:43:56 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHwR-0000c2-9j for emu@ietf.org; Wed, 18 Apr 2007 17:43:56 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGP003GFR16ZD@usaga01-in.huawei.com> for emu@ietf.org; Wed, 18 Apr 2007 14:43:55 -0700 (PDT) Received: from N737011 (pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGP00KM9R12XU@usaga01-in.huawei.com> for emu@ietf.org; Wed, 18 Apr 2007 14:43:54 -0700 (PDT) Date: Wed, 18 Apr 2007 14:43:56 -0700 From: Madjid Nakhjiri Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods In-reply-to: To: 'Bernard Aboba' , Pascal.Urien@enst.fr, emu@ietf.org Message-id: <000401c78202$aac12a80$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd+zqM23UzfVTtIS/iC3pGTrnU1QwDMyh8Q X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Bernard, By "that is probably the place to start", I am assuming you mean insert all EMU changes into an EAP-TTLSv1. What happens with the existing EAP-TTLSv1? Are the authors okay with us taking over and calling something different than theirs EAP-TTLSv1? If yes, then I am for it. Not sure how we can get away with crypto-binding IPR if it is a blanker IPR, I have not read the patent myself. R, Madjid -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Saturday, April 14, 2007 12:54 PM To: Pascal.Urien@enst.fr; emu@ietf.org Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods >The emu working agreed on the fact that a secure channel is needed > > Item1. > > - a) Is there a consensus for TTLS (what version ?) > - b) Is this possible to push TTLS as an RFC (from an IT point of >view) > > Item2 > -c) Do we need a new password based method ? > I agree with Bernard point of view. Many methods already exist. > >My personal feeling is >a=yes, b=yes, c=no I agree with this. With respect to a) there is realy only one deployed version of EAP-TTLS, namely EAP-TTLSv0. EAP-TTLSv1 has not been implemented. So that is probably the place to start. With respect to b), a fothcoming version of the EAP-TTLSv0 specification will be submitted for publication as an RFC. This will address questions from implementers and address the need for a stable reference from WiMAX Forum, OMA, TNC and other organizations that are incorporating EAP-TTLSv0 into their standards. With respect to c), one needs to take several factors into account, such as the certification/testing situation, availability of reference implementations and IPR declarations. EAP-TTLSv0 is currently being tested for interoperability by WFA so that a certification program is already in place. As far as I could tell, there is only one IPR declaration relating to EAP-TTLS, and that relates to EAP-TTLSv1, rather than EAP-TTLSv0: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=594 Compare this with the IPR Declarations relating to EAP FAST: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fast.txt http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fast-provisionin g-03.txt http://www.ietf.org/ietf/IPR/cisco-ipr-draft-salowey-tls-ticket.txt https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=595 http://www1.ietf.org/ietf/IPR/microsoft-ipr-draft-cam-winget-eap-fast.txt _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 25 05:21:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdhF-0003FY-Vl; Wed, 25 Apr 2007 05:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdhD-0003Aw-Cj for emu@ietf.org; Wed, 25 Apr 2007 05:21:55 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgdhC-0005ZW-GF for emu@ietf.org; Wed, 25 Apr 2007 05:21:55 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3P9Lopq032073 for ; Wed, 25 Apr 2007 12:21:52 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 12:21:52 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 12:21:52 +0300 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: [Emu] RFC 2716bis Section 5.2. Peer and Server Identities Date: Wed, 25 Apr 2007 12:21:54 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Emu] RFC 2716bis Section 5.2. Peer and Server Identities Thread-Index: AceHGypguJjt7vngQneN3v7gZMQAOA== From: To: X-OriginalArrivalTime: 25 Apr 2007 09:21:52.0517 (UTC) FILETIME=[29015B50:01C7871B] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I'm fine with this text. Best regards, Pasi -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Monday, April 16, 2007 11:25 AM To: Joseph Salowey (jsalowey); emu@ietf.org Subject: RE: [Emu] RFC 2716bis Section 5.2. Peer and Server Identities To refresh people's memories, here is what is in Section 5.2: 5.2. Peer and Server Identities The EAP-TLS peer name (Peer-Id) represents the identity to be used for access control and accounting purposes. The Server-Id represents the identity of the EAP server. In EAP-TLS, the Peer-Id and Server-Id are determined from the subject or subjectAltName fields in the peer and server certificates. For details, see [RFC3280] Section 4.1.2.6. Where the subjectAltName field is present in the peer or server certificate, the Peer-Id or Server-Id MUST be set to the contents of the subjectAltName as described in Section 5.3. If subject naming information is present only in the subjectAltName extension of a peer or server certificate, then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical. Although the use of the subject name field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. Where it is non-empty, the subject name field MUST contain an X.500 distinguished name (DN). Where the peer identity represents a host, a subjectAltName of type dnsName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1. If a dnsName or rfc822Name are not available other field types (for example a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used. A server identity will typically represent a host, not a user or a resource. As a result, a subjectAltName of type dnsName SHOULD be present in the server certificate. If a dnsName is not available other field types (for example a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used. If subject naming information is present only in the subject name field and the peer identity represents a user, then the subject name field SHOULD contain an emailAddress RDN. If the peer identity represents a host or device the subject name field SHOULD contain a CN RDN or serialNumber RDN. If subject naming information is present only in the subject name field of a server certificate, then the subject name field MUST contain a CN RDN or serialNumber RDN. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu