From emu-bounces@ietf.org Tue Aug 14 04:42: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 1IKryp-0002hW-9G; Tue, 14 Aug 2007 04:42:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKryo-0002hQ-9d for emu@ietf.org; Tue, 14 Aug 2007 04:42:22 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKrym-0000jH-Ri for emu@ietf.org; Tue, 14 Aug 2007 04:42:22 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7E8gJHI016560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Aug 2007 01:42:19 -0700 Received: from [10.50.69.139] (qconnect-10-50-69-139.qualcomm.com [10.50.69.139]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7E8gIHL026500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 14 Aug 2007 01:42:18 -0700 (PDT) Message-ID: <46C16AE9.6080208@qualcomm.com> Date: Tue, 14 Aug 2007 01:42:17 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Emu] Crypto-binding in TTLS-v0 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 probably has been asked before, but I will ask it in a different context: as we try to standardize EAP-TTLS in EMU (is this a charter item, Joe?) is there a plan to support cryto-binding in TTLS-v0? My opinion: well, yeah! :) regards, Lakshminath _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 14 07:03: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 1IKuBN-000357-Kf; Tue, 14 Aug 2007 07:03:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKuBN-000352-30 for emu@ietf.org; Tue, 14 Aug 2007 07:03:29 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKuBM-00066I-HT for emu@ietf.org; Tue, 14 Aug 2007 07:03:28 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id l7EB3OuF020361; Tue, 14 Aug 2007 13:03:24 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l7EB3OKf017062; Tue, 14 Aug 2007 13:03:24 +0200 Received: from MCHP7IDA.ww002.siemens.net ([139.25.131.144]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 13:03:24 +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: [Emu] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 13:03:23 +0200 Message-ID: <0D22E3C1A7D7A843B12BF8C6F0A40758024045E0@MCHP7IDA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfeT8Y0UGe2oNj9QRu8QvymHLxLgQAEWTNwAABh35A= References: <46C16AE9.6080208@qualcomm.com> From: "Tschofenig, Hannes" To: "Lakshminath Dondeti" , X-OriginalArrivalTime: 14 Aug 2007 11:03:24.0585 (UTC) FILETIME=[BC036990:01C7DE62] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Crypto-binding: Yes (my opinion) Sam also suggested to add channel bindings and to address = internalization support in a proper way.=20 Regarding your other question: No. EAP-TTLS is not a charter item since = the work on password-based protocols currently does not include tunneled = EAP protocols. This was discussed during the meeting.=20 It was also mentioned that the fans of EAP-TTLS would like to publish = their EAP-TTLSv0 as is -- without any modifications.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Gesendet: Dienstag, 14. August 2007 10:42 > An: emu@ietf.org > Betreff: [Emu] Crypto-binding in TTLS-v0 >=20 > This probably has been asked before, but I will ask it in a different=20 > context: as we try to standardize EAP-TTLS in EMU (is this a charter=20 > item, Joe?) is there a plan to support cryto-binding in TTLS-v0? >=20 > My opinion: well, yeah! :) >=20 > regards, > Lakshminath >=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 Aug 14 09:53:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwpu-0003zi-E2; Tue, 14 Aug 2007 09:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwps-0003z1-Nd for emu@ietf.org; Tue, 14 Aug 2007 09:53:28 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKwpr-00024U-GX for emu@ietf.org; Tue, 14 Aug 2007 09:53:28 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 14 Aug 2007 06:53:26 -0700 X-IronPort-AV: i="4.19,259,1183359600"; d="scan'208"; a="57224294:sNHT50383200" 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: RE: [Emu] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 09:53:09 -0400 Message-ID: In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A40758024045E0@MCHP7IDA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfeT8Y0UGe2oNj9QRu8QvymHLxLgQAEWTNwAABh35AABVLdYA== References: <46C16AE9.6080208@qualcomm.com> <0D22E3C1A7D7A843B12BF8C6F0A40758024045E0@MCHP7IDA.ww002.siemens.net> From: "Stephen Hanna" To: "Tschofenig, Hannes" , "Lakshminath Dondeti" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Perhaps a little clarification or correction is in order here. draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has been implemented by vendors and adopted by other SDOs. We plan to submit this for RFC status as part of the ongoing effort to document popular EAP methods as RFCs. As I described in my presentation at EMU in Chicago, we are working on an Internet-Draft that describes a few AVPs for use with EAP-TTLSv0 that allow it to address all the requirements the EMU WG has laid out for a strong password-based method. I expect to have this Internet-Draft ready in the next week or two. As to your question about whether EAP-TTLSv0 is a chartered work item for the EMU WG, that may depend in part on how the WG decides to address the work item to deliver a strong password-based method. At the EMU WG in Chicago, there were two proposals: my proposal to use EAP-TTLSv0 with these new AVPs and another proposal to define a new EAP method especially for this purpose. The results of a hum were inconclusive and it was agreed to take this discussion to the email list. If the WG decides to use EAP-TTLSv0 to address the work item related to delivering a strong password-based method, then I think that EAP-TTLSv0 and the new AVPs would not be work items for the EMU WG but the work item would instead be the creation of a profile showing how to use EAP-TTLSv0 and the new AVPs to provide a strong password-based method. Joe, is that consistent with your current thinking? Thanks, Steve -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@nsn.com]=20 Sent: Tuesday, August 14, 2007 7:03 AM To: Lakshminath Dondeti; emu@ietf.org Subject: AW: [Emu] Crypto-binding in TTLS-v0 Crypto-binding: Yes (my opinion) Sam also suggested to add channel bindings and to address = internalization support in a proper way.=20 Regarding your other question: No. EAP-TTLS is not a charter item since = the work on password-based protocols currently does not include tunneled = EAP protocols. This was discussed during the meeting.=20 It was also mentioned that the fans of EAP-TTLS would like to publish = their EAP-TTLSv0 as is -- without any modifications.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Gesendet: Dienstag, 14. August 2007 10:42 > An: emu@ietf.org > Betreff: [Emu] Crypto-binding in TTLS-v0 >=20 > This probably has been asked before, but I will ask it in a different=20 > context: as we try to standardize EAP-TTLS in EMU (is this a charter=20 > item, Joe?) is there a plan to support cryto-binding in TTLS-v0? >=20 > My opinion: well, yeah! :) >=20 > regards, > Lakshminath >=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 Aug 14 10:38: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 1IKxXY-000301-O5; Tue, 14 Aug 2007 10:38:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKxXY-0002zw-6y for emu@ietf.org; Tue, 14 Aug 2007 10:38:36 -0400 Received: from bay0-omc3-s37.bay0.hotmail.com ([65.54.246.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKxXX-0006Fp-Pu for emu@ietf.org; Tue, 14 Aug 2007 10:38:36 -0400 Received: from hotmail.com ([207.46.8.92]) by bay0-omc3-s37.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 14 Aug 2007 07:38:35 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 14 Aug 2007 07:38:35 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 14 Aug 2007 14:38:31 GMT X-Originating-IP: [71.197.208.131] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A40758024045E0@MCHP7IDA.ww002.siemens.net> From: "Bernard Aboba" To: hannes.tschofenig@nsn.com, ldondeti@qualcomm.com, emu@ietf.org Bcc: Subject: RE: AW: [Emu] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 07:38:31 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 14 Aug 2007 14:38:35.0046 (UTC) FILETIME=[CB3F6C60:01C7DE80] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 >Sam also suggested to add channel bindings and to address internalization >support in a proper way. Do you mean internationalization? If so, I'm not quite sure what this means. RFC 4282 supports internationalization of the NAI. Are we talking about internationalization of error messages? For TLS-based EAP methods this will often depend on TLS internationalization support. With respect to Channel Bindings, it should be understood that no proposals for this have ever been implemented, as far as I am aware. So a first step would be for a method to choose one of the approaches to Channel Bindings and support it (probably as an experimental extension), and then to evaluate the experiment so we can understand how well (or badly) the chosen approach works. At that point we might be ready to support Channel Bindings in other methods. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 14 11:18: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 1IKyA9-0006tq-1U; Tue, 14 Aug 2007 11:18:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKyA7-0006tk-EP for emu@ietf.org; Tue, 14 Aug 2007 11:18:27 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKyA6-0007JN-Ms for emu@ietf.org; Tue, 14 Aug 2007 11:18:27 -0400 Received: (qmail invoked by alias); 14 Aug 2007 15:18:25 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp003) with SMTP; 14 Aug 2007 17:18:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/1jVY6VB/1BVD8+CSRkBbC+3ToqeYXqRu/QbX1VW MKbL16AxDtqjfK Message-ID: <46C1C7BF.3080708@gmx.net> Date: Tue, 14 Aug 2007 17:18:23 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bernard Aboba Subject: Re: AW: [Emu] Crypto-binding in TTLS-v0 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: 4adaf050708fb13be3316a9eee889caa 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 Hi Bernard, Bernard Aboba wrote: >> Sam also suggested to add channel bindings and to address >> internalization support in a proper way. > > Do you mean internationalization? Typo. Yes. That's what I meant. > > If so, I'm not quite sure what this means. RFC 4282 supports > internationalization of the NAI. Are we talking about > internationalization of error messages? For TLS-based EAP methods > this will often depend on TLS internationalization support. Sam mentioned it in context of password based EAP methods. > > With respect to Channel Bindings, it should be understood that no > proposals for this have ever been implemented, as far as I am aware. > So a first step would be for a method to choose one of the approaches > to Channel Bindings and support it (probably as an experimental > extension), and then to evaluate the experiment so we can understand > how well (or badly) the chosen approach works. At that point we might > be ready to support Channel Bindings in other methods. > > Doesn't RFC 4962 mandate that channel binding has to be provided by an EAP method. At least it gets mentioned every time in discussions about new EAP methods. The market does not seem to be excited about a number of aspects. One the other hand we write documents and mandate things that do not seem to have any chance for deployment. 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 Aug 14 12:47:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzYI-00087x-GO; Tue, 14 Aug 2007 12:47:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzYH-00086F-AK for emu@ietf.org; Tue, 14 Aug 2007 12:47:29 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKzYG-0003Sw-Rg for emu@ietf.org; Tue, 14 Aug 2007 12:47:29 -0400 Received: from [142.131.76.184] (unknown [142.131.76.184]) by deployingradius.com (Postfix) with ESMTP id 69847A7161; Tue, 14 Aug 2007 09:47:24 -0700 (PDT) Message-ID: <46C1DC96.7020607@deployingradius.com> Date: Tue, 14 Aug 2007 12:47:18 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46C16AE9.6080208@qualcomm.com> <0D22E3C1A7D7A843B12BF8C6F0A40758024045E0@MCHP7IDA.ww002.siemens.net> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Stephen Hanna wrote: > draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has > been implemented by vendors and adopted by other SDOs. We plan > to submit this for RFC status as part of the ongoing effort > to document popular EAP methods as RFCs. I think this document should be published. It's widely used, and deserves documentation in the IETF process. > As to your question about whether EAP-TTLSv0 is a chartered > work item for the EMU WG, that may depend in part on how the > WG decides to address the work item to deliver a strong > password-based method. At the EMU WG in Chicago, there were > two proposals: my proposal to use EAP-TTLSv0 with these > new AVPs and another proposal to define a new EAP method > especially for this purpose. The results of a hum were > inconclusive and it was agreed to take this discussion > to the email list. I am in favor of EAP-TTLSv0 + new AVP's. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 14 12:58:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKziS-0006BN-4Y; Tue, 14 Aug 2007 12:58:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKziQ-0006B9-PV for emu@ietf.org; Tue, 14 Aug 2007 12:57:58 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKziP-0000Rj-FA for emu@ietf.org; Tue, 14 Aug 2007 12:57:58 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 14 Aug 2007 09:57:56 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.70.16) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.1.177.1; Tue, 14 Aug 2007 09:57:56 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com (157.54.62.24) by TK5-EXMLT-W601.wingroup.windeploy.ntdev.microsoft.com (157.54.70.16) with Microsoft SMTP Server id 8.1.122.1; Tue, 14 Aug 2007 09:57: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] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 09:57:29 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80061C0F2B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <46C1DC96.7020607@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfektFpOqH8oMANSTSC+dU82hk0MwAAT7aA References: <46C16AE9.6080208@qualcomm.com> <0D22E3C1A7D7A843B12BF8C6F0A40758024045E0@MCHP7IDA.ww002.siemens.net> <46C1DC96.7020607@deployingradius.com> From: Ryan Hurst To: Alan DeKok , Stephen Hanna X-Spam-Score: -8.0 (--------) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 agree, I also want to see PEAPv0 published for the same reasons (I am working on a draft of this, no ETA I can share at this time). -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Tuesday, August 14, 2007 9:47 AM To: Stephen Hanna Cc: emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Stephen Hanna wrote: > draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has > been implemented by vendors and adopted by other SDOs. We plan > to submit this for RFC status as part of the ongoing effort > to document popular EAP methods as RFCs. I think this document should be published. It's widely used, and deserves documentation in the IETF process. > As to your question about whether EAP-TTLSv0 is a chartered > work item for the EMU WG, that may depend in part on how the > WG decides to address the work item to deliver a strong > password-based method. At the EMU WG in Chicago, there were > two proposals: my proposal to use EAP-TTLSv0 with these > new AVPs and another proposal to define a new EAP method > especially for this purpose. The results of a hum were > inconclusive and it was agreed to take this discussion > to the email list. I am in favor of EAP-TTLSv0 + new AVP's. Alan DeKok. _______________________________________________ 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 Aug 14 13:00: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 1IKzkv-0001Bp-Ug; Tue, 14 Aug 2007 13:00:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzkv-0001Bj-AO for emu@ietf.org; Tue, 14 Aug 2007 13:00:33 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKzkt-0000W7-Ct for emu@ietf.org; Tue, 14 Aug 2007 13:00:33 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7EH0U6j009727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Aug 2007 10:00:30 -0700 Received: from [129.46.78.94] (ldondeti.na.qualcomm.com [129.46.78.94]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7EH0TFn011169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Aug 2007 10:00:29 -0700 Message-ID: <46C1DFAB.3000203@qualcomm.com> Date: Tue, 14 Aug 2007 10:00:27 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46C16AE9.6080208@qualcomm.com> <0D22E3C1A7D7A843B12BF8C6F0A40758024045E0@MCHP7IDA.ww002.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ithilien.qualcomm.com id l7EH0U6j009727 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 One of the things I would like to see is the addition of crypto-binding=20 (optionally and therefore does not affect others' existing=20 implementations). I am hoping that can be added as part of the=20 draft-funk-eap-ttls-v0-01.txt publication process. The other thing I would like to see is addition of IANA considerations=20 on using TTLS to carry other legacy weak authentication methods. This=20 would avoid making all of those line up for EAP-MyMethod IANA registratio= ns. Steve, if you would like, I can volunteer cycles to write text. Thoughts? thanks, Lakshminath On 8/14/2007 6:53 AM, Stephen Hanna wrote: > Perhaps a little clarification or correction is in order here. >=20 > draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has > been implemented by vendors and adopted by other SDOs. We plan > to submit this for RFC status as part of the ongoing effort > to document popular EAP methods as RFCs. >=20 > As I described in my presentation at EMU in Chicago, we are > working on an Internet-Draft that describes a few AVPs for > use with EAP-TTLSv0 that allow it to address all the requirements > the EMU WG has laid out for a strong password-based method. > I expect to have this Internet-Draft ready in the next week > or two. >=20 > As to your question about whether EAP-TTLSv0 is a chartered > work item for the EMU WG, that may depend in part on how the > WG decides to address the work item to deliver a strong > password-based method. At the EMU WG in Chicago, there were > two proposals: my proposal to use EAP-TTLSv0 with these > new AVPs and another proposal to define a new EAP method > especially for this purpose. The results of a hum were > inconclusive and it was agreed to take this discussion > to the email list. >=20 > If the WG decides to use EAP-TTLSv0 to address the work item > related to delivering a strong password-based method, then > I think that EAP-TTLSv0 and the new AVPs would not be work > items for the EMU WG but the work item would instead be the > creation of a profile showing how to use EAP-TTLSv0 and the > new AVPs to provide a strong password-based method. >=20 > Joe, is that consistent with your current thinking? >=20 > Thanks, >=20 > Steve >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@nsn.com]=20 > Sent: Tuesday, August 14, 2007 7:03 AM > To: Lakshminath Dondeti; emu@ietf.org > Subject: AW: [Emu] Crypto-binding in TTLS-v0 >=20 > Crypto-binding: Yes (my opinion) >=20 > Sam also suggested to add channel bindings and to address internalizati= on support in a proper way.=20 >=20 > Regarding your other question: No. EAP-TTLS is not a charter item since= the work on password-based protocols currently does not include tunneled= EAP protocols. This was discussed during the meeting.=20 >=20 > It was also mentioned that the fans of EAP-TTLS would like to publish t= heir EAP-TTLSv0 as is -- without any modifications.=20 >=20 > Ciao > Hannes >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 >> Gesendet: Dienstag, 14. August 2007 10:42 >> An: emu@ietf.org >> Betreff: [Emu] Crypto-binding in TTLS-v0 >> >> This probably has been asked before, but I will ask it in a different=20 >> context: as we try to standardize EAP-TTLS in EMU (is this a charter=20 >> item, Joe?) is there a plan to support cryto-binding in TTLS-v0? >> >> My opinion: well, yeah! :) >> >> regards, >> Lakshminath >> >> _______________________________________________ >> 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 Tue Aug 14 13:19: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 1IL03a-0003pZ-LM; Tue, 14 Aug 2007 13:19:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL03Y-0003iu-IS for emu@ietf.org; Tue, 14 Aug 2007 13:19:48 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL03X-0004QH-Uo for emu@ietf.org; Tue, 14 Aug 2007 13:19:48 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 14 Aug 2007 10:19:47 -0700 X-IronPort-AV: i="4.19,260,1183359600"; d="scan'208,217"; a="13401791:sNHT53425650" 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 l7EHJlRc025296; Tue, 14 Aug 2007 10:19:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7EHJjiX019815; Tue, 14 Aug 2007 17:19:46 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 10:19:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 10:15:12 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9DB@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfektHlqYJtCHKQTmWGDfbawFh6qAAA9ps9 References: <46C16AE9.6080208@qualcomm.com> <0D22E3C1A7D7A843B12BF8C6F0A40758024045E0@MCHP7IDA.ww002.siemens.net> <46C1DC96.7020607@deployingradius.com> From: "Glen Zorn \(gwz\)" To: "Alan DeKok" , "Stephen Hanna" X-OriginalArrivalTime: 14 Aug 2007 17:19:15.0327 (UTC) FILETIME=[3D4D90F0:01C7DE97] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3835; t=1187111987; x=1187975987; c=relaxed/simple; s=sjdkim2002; 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]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20; bh=GcNSdNUXf46j03HqkH2q/G3APCiDMvGrbwlmiAYUZCg=; b=Oz0ZnsuTMZgp/KrxF4mSkJ9v6ECGgHq1ASe5bvYgBO344E4l791058+8DEi8wa8zwfEJEpDf P514LWpAu1DyJwTUdgQwMe0IhxJ/VDr5lQFbnRZLha9XeUOifLWOqdHE; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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="===============0399332146==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============0399332146== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DE97.3D2684C3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DE97.3D2684C3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stephen Hanna wrote: > draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has > been implemented by vendors and adopted by other SDOs. We plan > to submit this for RFC status as part of the ongoing effort > to document popular EAP methods as RFCs. I think this document should be published. It's widely used, and deserves documentation in the IETF process. =20 gwz> I agree, no matter what the outcome of our discussions here may be. > As to your question about whether EAP-TTLSv0 is a chartered > work item for the EMU WG, that may depend in part on how the > WG decides to address the work item to deliver a strong > password-based method. At the EMU WG in Chicago, there were > two proposals: my proposal to use EAP-TTLSv0 with these > new AVPs and another proposal to define a new EAP method > especially for this purpose.=20 =20 gwz > I thought that the new method had already been defined by a design = team? =20 > The results of a hum were > inconclusive and it was agreed to take this discussion > to the email list. I am in favor of EAP-TTLSv0 + new AVP's. =20 gwz> Ditto.=20 =20 ------_=_NextPart_001_01C7DE97.3D2684C3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Emu] Crypto-binding in TTLS-v0=0A= =0A= =0A=
=0A=
Stephen Hanna wrote:
> =0A= draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has
> = been =0A= implemented by vendors and adopted by other SDOs. We plan
> to = submit this =0A= for RFC status as part of the ongoing effort
> to document popular = EAP =0A= methods as RFCs.

  I think this document should be = published.  =0A= It's widely used, and
deserves documentation in the IETF =0A= process.
=0A=
 
=0A=
gwz> = I agree, no =0A= matter what the outcome of our discussions here may = be.

> As to =0A= your question about whether EAP-TTLSv0 is a chartered
> work item = for the =0A= EMU WG, that may depend in part on how the
> WG decides to address = the =0A= work item to deliver a strong
> password-based method. At the EMU = WG in =0A= Chicago, there were
> two proposals: my proposal to use EAP-TTLSv0 = with =0A= these
> new AVPs and another proposal to define a new EAP = method
> =0A= especially for this purpose.
=0A=
 
=0A=
gwz > I = thought that the =0A= new method had already been defined by a design team?
=0A=
 
=0A=
> The results of a hum were
> = inconclusive =0A= and it was agreed to take this discussion
> to the email =0A= list.

  I am in favor of EAP-TTLSv0 + new AVP's.
=0A=
 
=0A=
gwz> = Ditto.=0A=
 
=0A= =0A= =0A= ------_=_NextPart_001_01C7DE97.3D2684C3-- --===============0399332146== 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 --===============0399332146==-- From emu-bounces@ietf.org Tue Aug 14 14:06: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 1IL0mm-0005hV-Ki; Tue, 14 Aug 2007 14:06:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0mk-0005hK-Mc for emu@ietf.org; Tue, 14 Aug 2007 14:06:30 -0400 Received: from bay0-omc1-s36.bay0.hotmail.com ([65.54.246.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL0mi-00025H-37 for emu@ietf.org; Tue, 14 Aug 2007 14:06:30 -0400 Received: from hotmail.com ([207.46.8.114]) by bay0-omc1-s36.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 14 Aug 2007 11:06:27 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 14 Aug 2007 11:06:26 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 14 Aug 2007 18:06:25 GMT X-Originating-IP: [131.107.0.71] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <46C1C7BF.3080708@gmx.net> From: "Bernard Aboba" To: Hannes.Tschofenig@gmx.net Bcc: Subject: Re: AW: [Emu] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 11:06:25 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 14 Aug 2007 18:06:26.0927 (UTC) FILETIME=[D5116FF0:01C7DE9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 >Doesn't RFC 4962 mandate that channel binding has to be provided by an EAP >method. At least it gets mentioned every time in discussions about new EAP >methods. As far as I can tell, there is no channel binding requirement in RFC 4962. RFC 4017 lists Channel Binding as optional. During EAP WG review, the argument against recommending (or requiring) Channel Bindings was that there were several models for Channel Bindings, but none had been standardized; implementation experience was also limited (or non-existent). So the argument was that we could not mandate or recommend support for something that unproven. >The market does not seem to be excited about a number of aspects. One the >other hand we write documents and mandate things that do not seem to have >any chance for deployment. It's one thing to mandate something that is doable, but which people may not choose to deploy. It's another thing to mandate something which we don't know how to do. A good first step might be to specify channel binding support as an optional feature in at least one method, and get an implementation to test. Then at least we'd have some experience for further discussion. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 14 14:08:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0od-0006Em-KV; Tue, 14 Aug 2007 14:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0oc-00068w-5E for emu@ietf.org; Tue, 14 Aug 2007 14:08:26 -0400 Received: from bay0-omc2-s31.bay0.hotmail.com ([65.54.246.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL0oa-000282-Ui for emu@ietf.org; Tue, 14 Aug 2007 14:08:26 -0400 Received: from hotmail.com ([207.46.8.93]) by bay0-omc2-s31.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 14 Aug 2007 11:08:24 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 14 Aug 2007 11:08:24 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 14 Aug 2007 18:08:20 GMT X-Originating-IP: [131.107.0.71] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9DB@xmb-sjc-215.amer.cisco.com> From: "Bernard Aboba" To: emu@ietf.org, aland@deployingradius.com, shanna@juniper.net Bcc: Subject: RE: [Emu] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 11:08:20 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 14 Aug 2007 18:08:24.0087 (UTC) FILETIME=[1AE6A270:01C7DE9E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 in favor of EAP-TTLSv0 + new AVP's. > >gwz> Ditto. [BA] + 1 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 14 14:13: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 1IL0tH-0001OH-Qr; Tue, 14 Aug 2007 14:13:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0tG-0001OB-LN for emu@ietf.org; Tue, 14 Aug 2007 14:13:14 -0400 Received: from mail.elbrysnetworks.com ([64.140.243.164] helo=gumby.elbrysnetworks.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IL0tF-0005iC-Uc for emu@ietf.org; Tue, 14 Aug 2007 14:13:14 -0400 Received: (qmail 9014 invoked from network); 14 Aug 2007 14:13:33 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 14 Aug 2007 14:13:33 -0400 From: "David B. Nelson" To: References: <46C16AE9.6080208@qualcomm.com> <0D22E3C1A7D7A843B12BF8C6F0A40758024045E0@MCHP7IDA.ww002.siemens.net><46C1DC96.7020607@deployingradius.com> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9DB@xmb-sjc-215.amer.cisco.com> Subject: RE: [Emu] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 14:13:31 -0400 Organization: Elbrys Networks, Inc. Message-ID: <009a01c7de9e$d264d110$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfektHlqYJtCHKQTmWGDfbawFh6qAAA9ps9AAHyxtA= In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9DB@xmb-sjc-215.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 Glen Zorn writes... > I thought that the new method had already been defined > by a design team? As a process observation, the work product and decisions of a design team are subject to acceptance by WG consensus. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 14 14:15: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 1IL0vt-0003aF-BJ; Tue, 14 Aug 2007 14:15:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0vs-0003aA-NO for emu@ietf.org; Tue, 14 Aug 2007 14:15:56 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL0vs-0005lO-BK for emu@ietf.org; Tue, 14 Aug 2007 14:15:56 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 14 Aug 2007 11:15:55 -0700 X-IronPort-AV: i="4.19,260,1183359600"; d="scan'208"; a="13417253:sNHT70253748" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7EIFrKE026771; Tue, 14 Aug 2007 11:15:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7EIFnVr017507; Tue, 14 Aug 2007 18:15:53 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); Tue, 14 Aug 2007 11:15:50 -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] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 11:15:54 -0700 Message-ID: In-Reply-To: <46C16AE9.6080208@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfeTwrqNqdPjxnVQmGohRFyzmo0mQAOxz0g From: "Joseph Salowey \(jsalowey\)" To: "Lakshminath Dondeti" , X-OriginalArrivalTime: 14 Aug 2007 18:15:50.0805 (UTC) FILETIME=[252A6450:01C7DE9F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1158; t=1187115353; x=1187979353; c=relaxed/simple; s=sjdkim3002; 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]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20; bh=zAEqLbNBGXwnR7RNpA37fgiC5sBkBYxuO8x+ePTTkP0=; b=Wsqy7WpXRLvsDXlc0XOA6FH7lk79rq3CZAxSbXHe/N2UiTkGvJTwEa3wVRC1ytou572DYQdG rlYCucz5fs/sHcwKbAC/kHUmfbrb4OwWIkMdyyJGZgOLbYaKTg1K3Qtj; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 charter item is for a password based method that supports legacy password databases. I do not believe Crypto-binding is strictly required to satisfy this charter item. =20 TTLS is being considered as part of the solution to this charter item, not necessarily a as method for tunneling generic authentication mechanisms so it is not clear if crypto-binding is required. However, for a protocol that tunnels arbitrary authentication mechanisms it is highly desirable to provide crypto-binding. =20 > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Tuesday, August 14, 2007 1:42 AM > To: emu@ietf.org > Subject: [Emu] Crypto-binding in TTLS-v0 >=20 > This probably has been asked before, but I will ask it in a different > context: as we try to standardize EAP-TTLS in EMU (is this a=20 > charter item, Joe?) is there a plan to support cryto-binding=20 > in TTLS-v0? >=20 > My opinion: well, yeah! :) >=20 > regards, > Lakshminath >=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 Aug 14 14:18: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 1IL0yC-0006hT-9I; Tue, 14 Aug 2007 14:18:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0yA-0006YF-W4 for emu@ietf.org; Tue, 14 Aug 2007 14:18:19 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL0yA-0005pi-AY for emu@ietf.org; Tue, 14 Aug 2007 14:18:18 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 14 Aug 2007 11:18:18 -0700 X-IronPort-AV: i="4.19,260,1183359600"; d="scan'208"; a="392183349:sNHT59283434" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7EIIHU8018046; Tue, 14 Aug 2007 11:18:17 -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 l7EIICW3019882; Tue, 14 Aug 2007 18:18:17 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, 14 Aug 2007 11:18:15 -0700 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: RE: [Emu] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 11:18:18 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfeT8Y0UGe2oNj9QRu8QvymHLxLgQAEWTNwAABh35AABVLdYAAHrKSQ From: "Joseph Salowey \(jsalowey\)" To: "Stephen Hanna" , "Tschofenig, Hannes" , "Lakshminath Dondeti" , X-OriginalArrivalTime: 14 Aug 2007 18:18:15.0500 (UTC) FILETIME=[7B6918C0:01C7DE9F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4174; t=1187115497; x=1187979497; c=relaxed/simple; s=sjdkim1004; 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]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20; bh=MER+DeQCymteNmQ57k2bPnEW3G4KCFxb8NsynGbbaw8=; b=MJfYjqz1RKhDiy0bZm+VV1uhQ194OCnu6Rs8Bi79UpSoDLmhSmSlF7Uph/sBiI6xJUFVWPFP nLEbe9R2jnl6RaieCsDhj2MyRIzIl2xBjoUp38RJs0fMOtKc6sLUiVuK2HDDU+SGyYilOdK1tU uwHjDprkaVOdH2a5pd04ErchI=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 Inline below:=20 > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Tuesday, August 14, 2007 6:53 AM > To: Tschofenig, Hannes; Lakshminath Dondeti; emu@ietf.org > Subject: RE: [Emu] Crypto-binding in TTLS-v0 >=20 > Perhaps a little clarification or correction is in order here. >=20 > draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has=20 > been implemented by vendors and adopted by other SDOs. We=20 > plan to submit this for RFC status as part of the ongoing=20 > effort to document popular EAP methods as RFCs. >=20 > As I described in my presentation at EMU in Chicago, we are=20 > working on an Internet-Draft that describes a few AVPs for=20 > use with EAP-TTLSv0 that allow it to address all the=20 > requirements the EMU WG has laid out for a strong=20 > password-based method. > I expect to have this Internet-Draft ready in the next week or two. >=20 [Joe] good. > As to your question about whether EAP-TTLSv0 is a chartered=20 > work item for the EMU WG, that may depend in part on how the=20 > WG decides to address the work item to deliver a strong=20 > password-based method. At the EMU WG in Chicago, there were=20 > two proposals: my proposal to use EAP-TTLSv0 with these new=20 > AVPs and another proposal to define a new EAP method=20 > especially for this purpose. The results of a hum were=20 > inconclusive and it was agreed to take this discussion to the=20 > email list. >=20 [Joe] Yes, there were at least two hums that need to be validated on the = list. I'll get those notes out today.=20 > If the WG decides to use EAP-TTLSv0 to address the work item=20 > related to delivering a strong password-based method, then I=20 > think that EAP-TTLSv0 and the new AVPs would not be work=20 > items for the EMU WG but the work item would instead be the=20 > creation of a profile showing how to use EAP-TTLSv0 and the=20 > new AVPs to provide a strong password-based method. >=20 [Joe] Maybe, but it is possible that a profile will not meet the charter = item. Also, it seems that the AVPs that form a protocol that solves = the problems of password authentication, password change, = internationalization, etc. could be considered to be within the scope of = the working group charter. =20 > Joe, is that consistent with your current thinking? >=20 > Thanks, >=20 > Steve >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@nsn.com] > Sent: Tuesday, August 14, 2007 7:03 AM > To: Lakshminath Dondeti; emu@ietf.org > Subject: AW: [Emu] Crypto-binding in TTLS-v0 >=20 > Crypto-binding: Yes (my opinion) >=20 > Sam also suggested to add channel bindings and to address=20 > internalization support in a proper way.=20 >=20 > Regarding your other question: No. EAP-TTLS is not a charter=20 > item since the work on password-based protocols currently=20 > does not include tunneled EAP protocols. This was discussed=20 > during the meeting.=20 >=20 > It was also mentioned that the fans of EAP-TTLS would like to=20 > publish their EAP-TTLSv0 as is -- without any modifications.=20 >=20 > Ciao > Hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > Gesendet: Dienstag, 14. August 2007 10:42 > > An: emu@ietf.org > > Betreff: [Emu] Crypto-binding in TTLS-v0 > >=20 > > This probably has been asked before, but I will ask it in a=20 > different > > context: as we try to standardize EAP-TTLS in EMU (is this =20 > a charter=20 > > item, Joe?) is there a plan to support cryto-binding in TTLS-v0? > >=20 > > My opinion: well, yeah! :) > >=20 > > regards, > > Lakshminath > >=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 Tue Aug 14 14:52: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 1IL1VU-00046C-3J; Tue, 14 Aug 2007 14:52:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1VS-000464-KL for emu@ietf.org; Tue, 14 Aug 2007 14:52:42 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL1VR-0002wt-D6 for emu@ietf.org; Tue, 14 Aug 2007 14:52:42 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 14 Aug 2007 11:52:40 -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] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 14:52:23 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfeT8Y0UGe2oNj9QRu8QvymHLxLgQAEWTNwAABh35AABVLdYAAHrKSQAAJO37A= References: From: "Stephen Hanna" To: "Joseph Salowey (jsalowey)" , "Tschofenig, Hannes" , "Lakshminath Dondeti" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 > If the WG decides to use EAP-TTLSv0 to address the work item=20 > related to delivering a strong password-based method, then I=20 > think that EAP-TTLSv0 and the new AVPs would not be work=20 > items for the EMU WG but the work item would instead be the=20 > creation of a profile showing how to use EAP-TTLSv0 and the=20 > new AVPs to provide a strong password-based method. >=20 [Joe] Maybe, but it is possible that a profile will not meet the charter item. Also, it seems that the AVPs that form a protocol that solves the problems of password authentication, password change, internationalization, etc. could be considered to be within the scope of the working group charter. =20 [Steve] If the WG decides it wants to adopt the draft on the new AVPs for EAP-TTLSv0 as a WG item in order to fulfill the WG charter, that's fine with me. Thanks, Steve _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 14 14:53: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 1IL1WG-0004xt-BX; Tue, 14 Aug 2007 14:53:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1WF-0004w3-7e for emu@ietf.org; Tue, 14 Aug 2007 14:53:31 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL1WE-0002xc-1p for emu@ietf.org; Tue, 14 Aug 2007 14:53:31 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 14 Aug 2007 11:53:29 -0700 X-IronPort-AV: i="4.19,261,1183359600"; d="scan'208"; a="57499748:sNHT63573488" 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] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 14:53:12 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfeniUspCIe8nYERTC+HjmYsLcgWQABiBtw References: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9DB@xmb-sjc-215.amer.cisco.com> From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db 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 in favor of EAP-TTLSv0 + new AVP's. > >gwz> Ditto. [SH] + 1 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 14 19:03: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 1IL5QJ-0007YR-QA; Tue, 14 Aug 2007 19:03:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL5QJ-0007YI-7Y for emu@ietf.org; Tue, 14 Aug 2007 19:03:39 -0400 Received: from smtp.trpz.com ([66.7.225.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL5QH-0000NU-Tn for emu@ietf.org; Tue, 14 Aug 2007 19:03:39 -0400 Received: from exch2.trpz.com (exch2.trpz.com [172.21.129.211]) by smtp.trpz.com (Postfix) with ESMTP id B378C460CC8; Tue, 14 Aug 2007 16:04:58 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 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] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 16:03:36 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfektHlqYJtCHKQTmWGDfbawFh6qAAA9ps9AAHmtyA= From: "Matthew Gast" To: "Glen Zorn \(gwz\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 Glen Zorn (gwz) wrote: > I am in favor of EAP-TTLSv0 + new AVP's. >=20 > gwz> Ditto.=20 [MG] +1 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 14 19:29:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL5pJ-0001yT-SI; Tue, 14 Aug 2007 19:29:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL5pJ-0001yO-89 for emu@ietf.org; Tue, 14 Aug 2007 19:29:29 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL5pI-0005SH-Pr for emu@ietf.org; Tue, 14 Aug 2007 19:29:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 14 Aug 2007 16:29:28 -0700 X-IronPort-AV: i="4.19,261,1183359600"; d="scan'208"; a="513547074:sNHT72742736" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7ENTSnW002890; Tue, 14 Aug 2007 16:29:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7ENTJiZ015527; Tue, 14 Aug 2007 23:29:28 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); Tue, 14 Aug 2007 16:29: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 Subject: RE: [Emu] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 16:29:25 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D804AC341E@xmb-sjc-222.amer.cisco.com> In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80061C0F2B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfektFpOqH8oMANSTSC+dU82hk0MwAAT7aAAA08NNA= From: "Nancy Winget \(ncamwing\)" To: "Ryan Hurst" , "Alan DeKok" , "Stephen Hanna" X-OriginalArrivalTime: 14 Aug 2007 23:29:26.0227 (UTC) FILETIME=[F407F230:01C7DECA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2573; t=1187134168; x=1187998168; c=relaxed/simple; s=sjdkim1004; 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=20[Emu]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20; bh=T83bQ3LwgWuUaxF7OyTA+hEtIPJHQPoZQ1z2nqta4co=; b=ZuMo1j7gz0gIkohXVW/zCiHXc8b+0ChPJHJf045QeUyVkh2rq1WS89l2AtvI9IuWPUnrCUjb KkZz9u3kOXPmIjjf7Hgg8bbTockdNOjItkWJwTOMKvuft0k4KlpDc6Cs8iUImm82qsVB2U4A6/ WGBTZeQNphYhZ94te3uXe1mL0=; Authentication-Results: sj-dkim-1; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Publishing TTLS and PEAPv0 (and PEAPv1) is a worthy cause given that there are deployments out there. However, I think that is a different item/issue than having it be taken as an EMU work item. For instance, it can be published as an informational RFC much the same way EAP-FAST is now RFC 4851. It is not clear why TTLS should become an EMU work item or standardized as the means to deliver a strong password based method. There are other tunnel methods such as PEAP and EAP-FAST that can also meet the requirements. If we are discussing what would need to be changed/updated to TTLS to meet the requirements, perhaps we should also be evaluating PEAP and EAP-FAST as alternatives as they also meet the requirements and perhaps more so than TTLS. Nancy. -----Original Message----- From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Tuesday, August 14, 2007 9:57 AM To: Alan DeKok; Stephen Hanna Cc: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 I agree, I also want to see PEAPv0 published for the same reasons (I am working on a draft of this, no ETA I can share at this time). -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Tuesday, August 14, 2007 9:47 AM To: Stephen Hanna Cc: emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Stephen Hanna wrote: > draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has been=20 > implemented by vendors and adopted by other SDOs. We plan to submit=20 > this for RFC status as part of the ongoing effort to document popular=20 > EAP methods as RFCs. I think this document should be published. It's widely used, and deserves documentation in the IETF process. > As to your question about whether EAP-TTLSv0 is a chartered work item=20 > for the EMU WG, that may depend in part on how the WG decides to=20 > address the work item to deliver a strong password-based method. At=20 > the EMU WG in Chicago, there were two proposals: my proposal to use=20 > EAP-TTLSv0 with these new AVPs and another proposal to define a new=20 > EAP method especially for this purpose. The results of a hum were=20 > inconclusive and it was agreed to take this discussion to the email=20 > list. I am in favor of EAP-TTLSv0 + new AVP's. Alan DeKok. _______________________________________________ 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 Aug 14 19: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 1IL64M-0003pE-Lv; Tue, 14 Aug 2007 19:45:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL64L-0003p4-43 for emu@ietf.org; Tue, 14 Aug 2007 19:45:01 -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 1IL64J-0001pS-CC for emu@ietf.org; Tue, 14 Aug 2007 19:45:01 -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.700.0; Tue, 14 Aug 2007 16:44:58 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.70.16) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.1.177.1; Tue, 14 Aug 2007 16:44:58 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com (157.54.62.26) by TK5-EXMLT-W601.wingroup.windeploy.ntdev.microsoft.com (157.54.70.16) with Microsoft SMTP Server id 8.1.122.1; Tue, 14 Aug 2007 16:44:57 -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] Crypto-binding in TTLS-v0 Date: Tue, 14 Aug 2007 16:44:38 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80061C13F5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <08A9A3213527A6428774900A80DBD8D804AC341E@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfektFpOqH8oMANSTSC+dU82hk0MwAAT7aAAA08NNAAAOKgMA== References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80061C0F2B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <08A9A3213527A6428774900A80DBD8D804AC341E@xmb-sjc-222.amer.cisco.com> From: Ryan Hurst To: "Nancy Winget (ncamwing)" , Alan DeKok , Stephen Hanna X-Spam-Score: -8.0 (--------) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 agree that PEAPv0 is a orthogonal issue Nancy, did not mean to suggest it was although in hindsight I can see how it might have read that way. On the topic of TTLS as a EMU working group item, I am not opposed to this as from the customer engagements I have had it appears to have a very strong existing deployment across a number of customer segments and from a protocol standpoint is pretty clean (It just needs a couple of additions like CryptoBindings). Ryan -----Original Message----- From: Nancy Winget (ncamwing) [mailto:ncamwing@cisco.com]=20 Sent: Tuesday, August 14, 2007 4:29 PM To: Ryan Hurst; Alan DeKok; Stephen Hanna Cc: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 Publishing TTLS and PEAPv0 (and PEAPv1) is a worthy cause given that there are deployments out there. However, I think that is a different item/issue than having it be taken as an EMU work item. For instance, it can be published as an informational RFC much the same way EAP-FAST is now RFC 4851. It is not clear why TTLS should become an EMU work item or standardized as the means to deliver a strong password based method. There are other tunnel methods such as PEAP and EAP-FAST that can also meet the requirements. If we are discussing what would need to be changed/updated to TTLS to meet the requirements, perhaps we should also be evaluating PEAP and EAP-FAST as alternatives as they also meet the requirements and perhaps more so than TTLS. Nancy. -----Original Message----- From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Tuesday, August 14, 2007 9:57 AM To: Alan DeKok; Stephen Hanna Cc: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 I agree, I also want to see PEAPv0 published for the same reasons (I am working on a draft of this, no ETA I can share at this time). -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Tuesday, August 14, 2007 9:47 AM To: Stephen Hanna Cc: emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Stephen Hanna wrote: > draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has been=20 > implemented by vendors and adopted by other SDOs. We plan to submit=20 > this for RFC status as part of the ongoing effort to document popular=20 > EAP methods as RFCs. I think this document should be published. It's widely used, and deserves documentation in the IETF process. > As to your question about whether EAP-TTLSv0 is a chartered work item=20 > for the EMU WG, that may depend in part on how the WG decides to=20 > address the work item to deliver a strong password-based method. At=20 > the EMU WG in Chicago, there were two proposals: my proposal to use=20 > EAP-TTLSv0 with these new AVPs and another proposal to define a new=20 > EAP method especially for this purpose. The results of a hum were=20 > inconclusive and it was agreed to take this discussion to the email=20 > list. I am in favor of EAP-TTLSv0 + new AVP's. Alan DeKok. _______________________________________________ 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 14 22:45:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL8sW-0000wK-AR; Tue, 14 Aug 2007 22:45:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL8sV-0000su-HO for emu@ietf.org; Tue, 14 Aug 2007 22:44:59 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL8sU-0006pk-7H for emu@ietf.org; Tue, 14 Aug 2007 22:44:59 -0400 Received: from [142.131.76.184] (unknown [142.131.76.184]) by deployingradius.com (Postfix) with ESMTP id 0E39FA7161; Tue, 14 Aug 2007 19:44:51 -0700 (PDT) Message-ID: <46C268A2.8090503@deployingradius.com> Date: Tue, 14 Aug 2007 22:44:50 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Nancy Winget (ncamwing)" Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <08A9A3213527A6428774900A80DBD8D804AC341E@xmb-sjc-222.amer.cisco.com> In-Reply-To: <08A9A3213527A6428774900A80DBD8D804AC341E@xmb-sjc-222.amer.cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Ryan Hurst , 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 Nancy Winget (ncamwing) wrote: > Publishing TTLS and PEAPv0 (and PEAPv1) is a worthy cause given that > there are deployments out there. However, I think that is a different > item/issue than having it be taken as an EMU work item. For instance, > it can be published as an informational RFC much the same way EAP-FAST > is now RFC 4851. I would prefer at least that. > It is not clear why TTLS should become an EMU work item or standardized > as the means to deliver a strong password based method. There are other > tunnel methods such as PEAP and EAP-FAST that can also meet the > requirements. TTLS has a much more flexible structure for in-tunnel transport than PEAP does. TTLS is also widely deployed than EAP-FAST. > If we are discussing what would need to be > changed/updated to TTLS to meet the requirements, perhaps we should also > be evaluating PEAP and EAP-FAST as alternatives as they also meet the > requirements and perhaps more so than TTLS. I believe that the evaluation is ongoing on this list. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 00:46: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 1ILXFp-0002f0-On; Thu, 16 Aug 2007 00:46:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILXFo-0002Wf-Nh for emu@ietf.org; Thu, 16 Aug 2007 00:46:40 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILXFo-00008W-0V for emu@ietf.org; Thu, 16 Aug 2007 00:46:40 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 15 Aug 2007 21:46:39 -0700 X-IronPort-AV: i="4.19,269,1183359600"; d="scan'208"; a="392529145:sNHT100689576" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7G4kdkw006348; Wed, 15 Aug 2007 21:46:39 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l7G4kLaD029219; Thu, 16 Aug 2007 04:46:39 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 21:46:27 -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] Crypto-binding in TTLS-v0 Date: Wed, 15 Aug 2007 21:46:26 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D804AC37C9@xmb-sjc-222.amer.cisco.com> In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80061C13F5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfektFpOqH8oMANSTSC+dU82hk0MwAAT7aAAA08NNAAAOKgMAA81zvw From: "Nancy Winget \(ncamwing\)" To: "Ryan Hurst" , "Alan DeKok" , "Stephen Hanna" X-OriginalArrivalTime: 16 Aug 2007 04:46:27.0793 (UTC) FILETIME=[682E5410:01C7DFC0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4347; t=1187239599; x=1188103599; c=relaxed/simple; s=sjdkim4002; 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=20[Emu]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20; bh=AXGWod1MGn45IsfdCwEnEulA67+8JU4dXGBTWku2TX4=; b=Nsi0vUGMhTXIR/II4L/i+cdbaaxmCKJAMlM2e1J2OFMm5e3w6dihN+XJIu4ziHaomhQIlOZg cr3BBoIjQPg5mpCbfGK/+pwUG0W66MmYqXnz/IPCUg/tnQ9B97SuLntm; Authentication-Results: sj-dkim-4; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Hi Ryan, Well, I thought presenting tunneled methods were in general out of scope for the password based authentication. But it is a viable means to meeting the requirements.....which I believe, is what the design team presented with PP-EAP. My point is that if we contemplate TTLS as a working group item, we should also be analyzing PEAP and EAP-FAST. Though PEAP may not have as much traction, I believe though EAP-FAST was instantiated after TTLS, is also widely deployed and addresses some of the deployment challenges (like crypto binding and the ability to establish tunnels without the need of asymmetric crypto) that were presented by PEAP and TTLS. Nancy. -----Original Message----- From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Tuesday, August 14, 2007 4:45 PM To: Nancy Winget (ncamwing); Alan DeKok; Stephen Hanna Cc: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 I agree that PEAPv0 is a orthogonal issue Nancy, did not mean to suggest it was although in hindsight I can see how it might have read that way. On the topic of TTLS as a EMU working group item, I am not opposed to this as from the customer engagements I have had it appears to have a very strong existing deployment across a number of customer segments and from a protocol standpoint is pretty clean (It just needs a couple of additions like CryptoBindings). Ryan -----Original Message----- From: Nancy Winget (ncamwing) [mailto:ncamwing@cisco.com] Sent: Tuesday, August 14, 2007 4:29 PM To: Ryan Hurst; Alan DeKok; Stephen Hanna Cc: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 Publishing TTLS and PEAPv0 (and PEAPv1) is a worthy cause given that there are deployments out there. However, I think that is a different item/issue than having it be taken as an EMU work item. For instance, it can be published as an informational RFC much the same way EAP-FAST is now RFC 4851. It is not clear why TTLS should become an EMU work item or standardized as the means to deliver a strong password based method. There are other tunnel methods such as PEAP and EAP-FAST that can also meet the requirements. If we are discussing what would need to be changed/updated to TTLS to meet the requirements, perhaps we should also be evaluating PEAP and EAP-FAST as alternatives as they also meet the requirements and perhaps more so than TTLS. Nancy. -----Original Message----- From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Tuesday, August 14, 2007 9:57 AM To: Alan DeKok; Stephen Hanna Cc: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 I agree, I also want to see PEAPv0 published for the same reasons (I am working on a draft of this, no ETA I can share at this time). -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Tuesday, August 14, 2007 9:47 AM To: Stephen Hanna Cc: emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Stephen Hanna wrote: > draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has been=20 > implemented by vendors and adopted by other SDOs. We plan to submit=20 > this for RFC status as part of the ongoing effort to document popular=20 > EAP methods as RFCs. I think this document should be published. It's widely used, and deserves documentation in the IETF process. > As to your question about whether EAP-TTLSv0 is a chartered work item=20 > for the EMU WG, that may depend in part on how the WG decides to=20 > address the work item to deliver a strong password-based method. At=20 > the EMU WG in Chicago, there were two proposals: my proposal to use=20 > EAP-TTLSv0 with these new AVPs and another proposal to define a new=20 > EAP method especially for this purpose. The results of a hum were=20 > inconclusive and it was agreed to take this discussion to the email=20 > list. I am in favor of EAP-TTLSv0 + new AVP's. Alan DeKok. _______________________________________________ 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 00:46: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 1ILXFp-0002dn-JT; Thu, 16 Aug 2007 00:46:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILXFo-0002VW-Ix for emu@ietf.org; Thu, 16 Aug 2007 00:46:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILXFn-00008V-Rc for emu@ietf.org; Thu, 16 Aug 2007 00:46:40 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Aug 2007 21:46:39 -0700 X-IronPort-AV: i="4.19,269,1183359600"; d="scan'208"; a="513992376:sNHT101271210" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7G4kdZ7006344; Wed, 15 Aug 2007 21:46:39 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l7G4kLa9029219; Thu, 16 Aug 2007 04:46:34 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 21:46:27 -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] Crypto-binding in TTLS-v0 Date: Wed, 15 Aug 2007 21:46:26 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D804AC37C8@xmb-sjc-222.amer.cisco.com> In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80061C13F5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfektFpOqH8oMANSTSC+dU82hk0MwAAT7aAAA08NNAAAOKgMAA81zvw From: "Nancy Winget \(ncamwing\)" To: "Ryan Hurst" , "Alan DeKok" , "Stephen Hanna" X-OriginalArrivalTime: 16 Aug 2007 04:46:27.0575 (UTC) FILETIME=[680D1070:01C7DFC0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4347; t=1187239599; x=1188103599; c=relaxed/simple; s=sjdkim4002; 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=20[Emu]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20; bh=AXGWod1MGn45IsfdCwEnEulA67+8JU4dXGBTWku2TX4=; b=Nsi0vUGMhTXIR/II4L/i+cdbaaxmCKJAMlM2e1J2OFMm5e3w6dihN+XJIu4ziHaomhQIlOZg cr3BBoIjQPg5mpCbfGK/+pwUG0W66MmYqXnz/IPCUg/tnQ9B97SuLntm; Authentication-Results: sj-dkim-4; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Hi Ryan, Well, I thought presenting tunneled methods were in general out of scope for the password based authentication. But it is a viable means to meeting the requirements.....which I believe, is what the design team presented with PP-EAP. My point is that if we contemplate TTLS as a working group item, we should also be analyzing PEAP and EAP-FAST. Though PEAP may not have as much traction, I believe though EAP-FAST was instantiated after TTLS, is also widely deployed and addresses some of the deployment challenges (like crypto binding and the ability to establish tunnels without the need of asymmetric crypto) that were presented by PEAP and TTLS. Nancy. -----Original Message----- From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Tuesday, August 14, 2007 4:45 PM To: Nancy Winget (ncamwing); Alan DeKok; Stephen Hanna Cc: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 I agree that PEAPv0 is a orthogonal issue Nancy, did not mean to suggest it was although in hindsight I can see how it might have read that way. On the topic of TTLS as a EMU working group item, I am not opposed to this as from the customer engagements I have had it appears to have a very strong existing deployment across a number of customer segments and from a protocol standpoint is pretty clean (It just needs a couple of additions like CryptoBindings). Ryan -----Original Message----- From: Nancy Winget (ncamwing) [mailto:ncamwing@cisco.com] Sent: Tuesday, August 14, 2007 4:29 PM To: Ryan Hurst; Alan DeKok; Stephen Hanna Cc: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 Publishing TTLS and PEAPv0 (and PEAPv1) is a worthy cause given that there are deployments out there. However, I think that is a different item/issue than having it be taken as an EMU work item. For instance, it can be published as an informational RFC much the same way EAP-FAST is now RFC 4851. It is not clear why TTLS should become an EMU work item or standardized as the means to deliver a strong password based method. There are other tunnel methods such as PEAP and EAP-FAST that can also meet the requirements. If we are discussing what would need to be changed/updated to TTLS to meet the requirements, perhaps we should also be evaluating PEAP and EAP-FAST as alternatives as they also meet the requirements and perhaps more so than TTLS. Nancy. -----Original Message----- From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Tuesday, August 14, 2007 9:57 AM To: Alan DeKok; Stephen Hanna Cc: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 I agree, I also want to see PEAPv0 published for the same reasons (I am working on a draft of this, no ETA I can share at this time). -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Tuesday, August 14, 2007 9:47 AM To: Stephen Hanna Cc: emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Stephen Hanna wrote: > draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has been=20 > implemented by vendors and adopted by other SDOs. We plan to submit=20 > this for RFC status as part of the ongoing effort to document popular=20 > EAP methods as RFCs. I think this document should be published. It's widely used, and deserves documentation in the IETF process. > As to your question about whether EAP-TTLSv0 is a chartered work item=20 > for the EMU WG, that may depend in part on how the WG decides to=20 > address the work item to deliver a strong password-based method. At=20 > the EMU WG in Chicago, there were two proposals: my proposal to use=20 > EAP-TTLSv0 with these new AVPs and another proposal to define a new=20 > EAP method especially for this purpose. The results of a hum were=20 > inconclusive and it was agreed to take this discussion to the email=20 > list. I am in favor of EAP-TTLSv0 + new AVP's. Alan DeKok. _______________________________________________ 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 00:48: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 1ILXHe-0005W8-1i; Thu, 16 Aug 2007 00:48:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILXHd-0005Pu-16 for emu@ietf.org; Thu, 16 Aug 2007 00:48:33 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILXHc-0000Ng-IP for emu@ietf.org; Thu, 16 Aug 2007 00:48:33 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Aug 2007 21:48:32 -0700 X-IronPort-AV: i="4.19,269,1183359600"; d="scan'208"; a="200885555:sNHT55747476" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7G4mVbH030339; Wed, 15 Aug 2007 21:48:31 -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 l7G4mVa1029769; Thu, 16 Aug 2007 04:48:31 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); Wed, 15 Aug 2007 21:48: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 Subject: RE: [Emu] Crypto-binding in TTLS-v0 Date: Wed, 15 Aug 2007 21:48:30 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D804AC37CA@xmb-sjc-222.amer.cisco.com> In-Reply-To: <46C268A2.8090503@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: Acfe5kc8l7HLkiIMQ0ySSr8gySkTSQA2irOw From: "Nancy Winget \(ncamwing\)" To: "Alan DeKok" X-OriginalArrivalTime: 16 Aug 2007 04:48:31.0631 (UTC) FILETIME=[B1FE81F0:01C7DFC0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1530; t=1187239711; x=1188103711; c=relaxed/simple; s=sjdkim2002; 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=20[Emu]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20; bh=b9mPLON+flcP+efLsyHFmWETCI02J9BQyH/aW2V5Tzc=; b=TGAoKsi51u2j6YjM0kdJmHhKYJPqbmXLUSPfomQtYqR04GAtgyCVWIU1hqLsgrqzxH63D4QR 81FxT9QeJElxt6+BPvc9Uq+ON8Tc98S9I/EBG4fbbyYPmBQC9D8zFbDL; Authentication-Results: sj-dkim-2; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Ryan Hurst , 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 Alan, I am glad to see that the evaluation is continuing on the thread.....I think both TTLS and EAP-FAST are being widely deployed and both merit consideration. Nancy.=20 -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Tuesday, August 14, 2007 7:45 PM To: Nancy Winget (ncamwing) Cc: Ryan Hurst; Stephen Hanna; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Nancy Winget (ncamwing) wrote: > Publishing TTLS and PEAPv0 (and PEAPv1) is a worthy cause given that=20 > there are deployments out there. However, I think that is a different > item/issue than having it be taken as an EMU work item. For instance, > it can be published as an informational RFC much the same way EAP-FAST > is now RFC 4851. I would prefer at least that. > It is not clear why TTLS should become an EMU work item or=20 > standardized as the means to deliver a strong password based method. =20 > There are other tunnel methods such as PEAP and EAP-FAST that can also > meet the requirements. TTLS has a much more flexible structure for in-tunnel transport than PEAP does. TTLS is also widely deployed than EAP-FAST. > If we are discussing what would need to be changed/updated to TTLS to > meet the requirements, perhaps we should also be evaluating PEAP and=20 > EAP-FAST as alternatives as they also meet the requirements and=20 > perhaps more so than TTLS. I believe that the evaluation is ongoing on this list. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 00:48: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 1ILXHg-0005eW-Ld; Thu, 16 Aug 2007 00:48:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILXHe-0005Zm-Eq for emu@ietf.org; Thu, 16 Aug 2007 00:48:34 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILXHd-0000Ng-7O for emu@ietf.org; Thu, 16 Aug 2007 00:48:34 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 15 Aug 2007 21:48:32 -0700 X-IronPort-AV: i="4.19,269,1183359600"; d="scan'208"; a="200885557:sNHT56025720" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7G4mWtl027682; Wed, 15 Aug 2007 21:48:32 -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 l7G4mWa1029776; Thu, 16 Aug 2007 04:48:32 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); Wed, 15 Aug 2007 21:48: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 Subject: RE: [Emu] Crypto-binding in TTLS-v0 Date: Wed, 15 Aug 2007 21:48:30 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D804AC37CB@xmb-sjc-222.amer.cisco.com> In-Reply-To: <46C268A2.8090503@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: Acfe5kc8l7HLkiIMQ0ySSr8gySkTSQA2irOw From: "Nancy Winget \(ncamwing\)" To: "Alan DeKok" X-OriginalArrivalTime: 16 Aug 2007 04:48:31.0849 (UTC) FILETIME=[B21FC590:01C7DFC0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1530; t=1187239712; x=1188103712; c=relaxed/simple; s=sjdkim3002; 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=20[Emu]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20; bh=b9mPLON+flcP+efLsyHFmWETCI02J9BQyH/aW2V5Tzc=; b=coADj9sjUtiVsfPgK07GBkZYz9lF4ucMdojFJEufW773sOZh85QRbLsrh6zJrTAhQSpbRwVZ DlH9dgwY4F+GRJQwPqZgCrRXWX8gZKevw4J+YmxsFFold1pKaLcCj38f; Authentication-Results: sj-dkim-3; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Ryan Hurst , 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 Alan, I am glad to see that the evaluation is continuing on the thread.....I think both TTLS and EAP-FAST are being widely deployed and both merit consideration. Nancy.=20 -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Tuesday, August 14, 2007 7:45 PM To: Nancy Winget (ncamwing) Cc: Ryan Hurst; Stephen Hanna; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Nancy Winget (ncamwing) wrote: > Publishing TTLS and PEAPv0 (and PEAPv1) is a worthy cause given that=20 > there are deployments out there. However, I think that is a different > item/issue than having it be taken as an EMU work item. For instance, > it can be published as an informational RFC much the same way EAP-FAST > is now RFC 4851. I would prefer at least that. > It is not clear why TTLS should become an EMU work item or=20 > standardized as the means to deliver a strong password based method. =20 > There are other tunnel methods such as PEAP and EAP-FAST that can also > meet the requirements. TTLS has a much more flexible structure for in-tunnel transport than PEAP does. TTLS is also widely deployed than EAP-FAST. > If we are discussing what would need to be changed/updated to TTLS to > meet the requirements, perhaps we should also be evaluating PEAP and=20 > EAP-FAST as alternatives as they also meet the requirements and=20 > perhaps more so than TTLS. I believe that the evaluation is ongoing on this list. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 08:46: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 1ILejv-0003hD-CR; Thu, 16 Aug 2007 08:46:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILejt-0003h8-S3 for emu@ietf.org; Thu, 16 Aug 2007 08:46:13 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILejt-0006Dx-9X for emu@ietf.org; Thu, 16 Aug 2007 08:46:13 -0400 Received: from [192.168.1.102] (ottawa-hs-206-191-39-219.d-ip.magma.ca [206.191.39.219]) by deployingradius.com (Postfix) with ESMTP id E631AA7161; Thu, 16 Aug 2007 05:46:05 -0700 (PDT) Message-ID: <46C44700.10409@deployingradius.com> Date: Thu, 16 Aug 2007 08:45:52 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Nancy Winget (ncamwing)" Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <08A9A3213527A6428774900A80DBD8D804AC37CB@xmb-sjc-222.amer.cisco.com> In-Reply-To: <08A9A3213527A6428774900A80DBD8D804AC37CB@xmb-sjc-222.amer.cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Ryan Hurst , 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 Nancy Winget (ncamwing) wrote: > Thanks Alan, I am glad to see that the evaluation is continuing on the > thread.....I think both TTLS and EAP-FAST are being widely deployed and > both merit consideration. I think EAP-FAST has been considered, and has little support. I've never seen an EAP-FAST deployment, and most people I talk to haven't seen one, either. Most people I talk to don't plan on supporting EAP-FAST any time soon. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 10:13:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILg6Q-00035K-R1; Thu, 16 Aug 2007 10:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILg6P-00035A-Nn for emu@ietf.org; Thu, 16 Aug 2007 10:13:33 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILg6N-0007lX-Pg for emu@ietf.org; Thu, 16 Aug 2007 10:13:33 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 16 Aug 2007 07:13:31 -0700 X-IronPort-AV: i="4.19,272,1183359600"; d="scan'208"; a="201164517:sNHT64220589" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7GEDVOX028277; Thu, 16 Aug 2007 07:13:31 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7GEDRW3007920; Thu, 16 Aug 2007 14:13:30 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 10:13:24 -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] Crypto-binding in TTLS-v0 Date: Thu, 16 Aug 2007 10:13:29 -0400 Message-ID: <0F64770A6FD22C43AAA498C1E774ECC704218500@xmb-rtp-208.amer.cisco.com> In-Reply-To: <46C44700.10409@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfgA3bdHYj7fp9SSMifCZLiLTt11QAC1l3Q References: <08A9A3213527A6428774900A80DBD8D804AC37CB@xmb-sjc-222.amer.cisco.com> <46C44700.10409@deployingradius.com> From: "Gene Chang \(genchang\)" To: "Alan DeKok" , "Nancy Winget \(ncamwing\)" X-OriginalArrivalTime: 16 Aug 2007 14:13:24.0822 (UTC) FILETIME=[9BE90760:01C7E00F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1512; t=1187273611; x=1188137611; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=genchang@cisco.com; z=From:=20=22Gene=20Chang=20\(genchang\)=22=20 |Subject:=20RE=3A=20[Emu]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20; bh=JwlG047Quy6pnrjBWtoXjS+N+XcN2adu5LFLnm8DhX0=; b=s5rATQVuTF1c759LZne3SlUnnMKbpL/cjzhaS9Cyq4HJdwOLJ67aHojT9GCpL+NOLR1BBtSw CxcrlZY0AUe0WWARD7HfFO4b9qkTYgAGqMIFus8SlE/iKJWX/N9wRBzI; Authentication-Results: sj-dkim-4; header.From=genchang@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Ryan Hurst , 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 Alan, It is not unusual for developers to be unaware of the breath of the EAP-FAST market adoption. It has been growing under the radar for a lot of people since market research firms do not track market share of different EAP methods. Part of the misperception that EAP-FAST has no market presence has been because no one has been drawing attention to the adoption success of EAP-FAST. I am hoping to assemble some public data to shed a light on the secret life of EAP-FAST. Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) WNBU, Technical Leader Office: 603-559-2978 Mobile: 781-799-0233 =20 =20 =20 -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Thursday, August 16, 2007 8:46 AM To: Nancy Winget (ncamwing) Cc: Ryan Hurst; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Nancy Winget (ncamwing) wrote: > Thanks Alan, I am glad to see that the evaluation is continuing on the > thread.....I think both TTLS and EAP-FAST are being widely deployed and > both merit consideration. I think EAP-FAST has been considered, and has little support. I've never seen an EAP-FAST deployment, and most people I talk to haven't seen one, either. Most people I talk to don't plan on supporting EAP-FAST any time soon. Alan DeKok. _______________________________________________ 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 Aug 16 10:26:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgJL-00039r-UD; Thu, 16 Aug 2007 10:26:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgJK-00039l-IW for emu@ietf.org; Thu, 16 Aug 2007 10:26:54 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ILgJJ-00089V-76 for emu@ietf.org; Thu, 16 Aug 2007 10:26:54 -0400 Received: (qmail invoked by alias); 16 Aug 2007 14:26:51 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp021) with SMTP; 16 Aug 2007 16:26:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/fPmYbxqrfngu8QLwNfxGbhoXn4oDi4mJAYt0gsb WsCWUBqaciN4VR Message-ID: <46C45EA9.7060805@gmx.net> Date: Thu, 16 Aug 2007 16:26:49 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46C16AE9.6080208@qualcomm.com> <0D22E3C1A7D7A843B12BF8C6F0A40758024045E0@MCHP7IDA.ww002.siemens.net> <46C1DFAB.3000203@qualcomm.com> In-Reply-To: <46C1DFAB.3000203@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Lakshminath Dondeti wrote: > > Steve, if you would like, I can volunteer cycles to write text. > I offered help to the authors a few month ago already and it was rejected. Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 10:57: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 1ILgmu-0003Jl-NR; Thu, 16 Aug 2007 10:57:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgms-0003Dd-Ti for emu@ietf.org; Thu, 16 Aug 2007 10:57:26 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILgms-0001BV-D4 for emu@ietf.org; Thu, 16 Aug 2007 10:57:26 -0400 Received: from [192.168.1.102] (ottawa-hs-206-191-39-219.d-ip.magma.ca [206.191.39.219]) by deployingradius.com (Postfix) with ESMTP id DEB76A7161; Thu, 16 Aug 2007 07:57:20 -0700 (PDT) Message-ID: <46C465CA.8020800@deployingradius.com> Date: Thu, 16 Aug 2007 10:57:14 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Gene Chang (genchang)" Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <08A9A3213527A6428774900A80DBD8D804AC37CB@xmb-sjc-222.amer.cisco.com> <46C44700.10409@deployingradius.com> <0F64770A6FD22C43AAA498C1E774ECC704218500@xmb-rtp-208.amer.cisco.com> In-Reply-To: <0F64770A6FD22C43AAA498C1E774ECC704218500@xmb-rtp-208.amer.cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Ryan Hurst , 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 Gene Chang (genchang) wrote: > It is not unusual for developers to be unaware of the breath of the > EAP-FAST market adoption. It has been growing under the radar for a lot > of people since market research firms do not track market share of > different EAP methods. I do rather a bit more than just development. I work with people deploying systems from 100 to 10M+ users. I don't see EAP-FAST being adopted. I *do* hear rumors about EAP-FAST from enterprises who have bought single source solutions. > Part of the misperception that EAP-FAST has no market presence has been > because no one has been drawing attention to the adoption success of > EAP-FAST. I am hoping to assemble some public data to shed a light on > the secret life of EAP-FAST. People haven't drawn attention to the adoption success of PEAP or TTLS, either. Instead, people just deployed it in large numbers. I started hearing about PEAP and TTLS almost as soon as they were proposed. There was quick and immediate demand for both protocols from a wide range of systems (small, medium, large). I've seen nothing similar happen with EAP-FAST (so far). Part of the misperception that EAP-FAST has a large market presence has been that the people who are deploying it don't talk to the people *not* deploying it, and vice versa. Within the EAP-FAST camp, it looks like there's wide-spread adoption. Outside of it, it just doesn't come up in any conversation. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 11:00: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 1ILgq1-0005qU-7h; Thu, 16 Aug 2007 11:00:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgpz-0005qP-ES for emu@ietf.org; Thu, 16 Aug 2007 11:00:39 -0400 Received: from smtpout1443.sc1.he.tucows.com ([64.97.157.143] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILgpy-0000aV-2l for emu@ietf.org; Thu, 16 Aug 2007 11:00:39 -0400 Received: from fh1064.dia.cp.net (64.97.139.2) by n007.sc1.he.tucows.com (7.2.069.1) id 465670BB00EA9E84 for emu@ietf.org; Thu, 16 Aug 2007 15:00:37 +0000 Received: from 216.162.240.250 (authenticated as user david@mitton.com) by 64.97.168.74 with HTTP; Thu, 16 Aug 2007 15:00:36 UTC Message-ID: <8959994.1187276437046.JavaMail.?@fh1064.dia.cp.net> Date: Thu, 16 Aug 2007 15:00:37 +0000 (UTC) From: "david@mitton.com" To: Subject: RE: [Emu] Crypto-binding in TTLS-v0 MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "david@mitton.com" List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I with Alan on this. I still haven't seen one yet either. But I'd love to see a version of EAP-FAST that I _could_ work with. Meaning; - it runs with something more accessible than the Cisco ACS server, preferably an open source or reference copy. Maybe even an Windows/IAS plugin. - there is a Windows EAPhost supplicant availible, preferably with interfaces for tunnelled methods and/or interfaces for the ID we wrote for SecurID PAC provisioning. draft-cam-winget-eap-fast-potp-provisioning-00.txt (hmm... time to renew that) If you have any of this, let me know. Dave Mitton, RSA - Security Division of EMC. ----Original Message---- From: genchang@cisco.com Date: Aug 16, 2007 10:13 To: "Alan DeKok", "Nancy Winget (ncamwing)" Cc: "Ryan Hurst", Subj: RE: [Emu] Crypto-binding in TTLS-v0 Alan, It is not unusual for developers to be unaware of the breath of the EAP-FAST market adoption. It has been growing under the radar for a lot of people since market research firms do not track market share of different EAP methods. Part of the misperception that EAP-FAST has no market presence has been because no one has been drawing attention to the adoption success of EAP-FAST. I am hoping to assemble some public data to shed a light on the secret life of EAP-FAST. Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) WNBU, Technical Leader Office: 603-559-2978 Mobile: 781-799-0233 -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Thursday, August 16, 2007 8:46 AM To: Nancy Winget (ncamwing) Cc: Ryan Hurst; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Nancy Winget (ncamwing) wrote: > Thanks Alan, I am glad to see that the evaluation is continuing on the > thread.....I think both TTLS and EAP-FAST are being widely deployed and > both merit consideration. I think EAP-FAST has been considered, and has little support. I've never seen an EAP-FAST deployment, and most people I talk to haven't seen one, either. Most people I talk to don't plan on supporting EAP-FAST any time soon. Alan DeKok. _______________________________________________ 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 Thu Aug 16 11:35:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhO7-0006Vr-Tg; Thu, 16 Aug 2007 11:35:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhO7-0006Vm-FR for emu@ietf.org; Thu, 16 Aug 2007 11:35:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILhO6-00022p-8V for emu@ietf.org; Thu, 16 Aug 2007 11:35:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Aug 2007 11:35:52 -0400 X-IronPort-AV: i="4.19,272,1183348800"; d="scan'208"; a="129048439:sNHT95797830" 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 l7GFZpQC019050; Thu, 16 Aug 2007 11:35:51 -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 l7GFZHnB016875; Thu, 16 Aug 2007 15:35:51 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 11:35:38 -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] Crypto-binding in TTLS-v0 Date: Thu, 16 Aug 2007 11:35:43 -0400 Message-ID: <0F64770A6FD22C43AAA498C1E774ECC704218533@xmb-rtp-208.amer.cisco.com> In-Reply-To: <8959994.1187276437046.JavaMail.?@fh1064.dia.cp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfgFj2Rf3ckydjaT2eAiVB0eQmo0wABEoSQ References: <8959994.1187276437046.JavaMail.?@fh1064.dia.cp.net> From: "Gene Chang \(genchang\)" To: , X-OriginalArrivalTime: 16 Aug 2007 15:35:38.0894 (UTC) FILETIME=[18D8AAE0:01C7E01B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3362; t=1187278551; x=1188142551; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=genchang@cisco.com; z=From:=20=22Gene=20Chang=20\(genchang\)=22=20 |Subject:=20RE=3A=20[Emu]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20 |To:=20,=20; bh=TKV5seiCEk2dvZykK9iC87LQsqkq2QVBY0b3ye0nyOg=; b=M2D//S68+Q7fwDCrhky5FkCBdSt4D21sh9nW8TVGnmUSL1d4PB6+F7wgtSj7bscTZptVHG8v oEa/QvwZs4OXN1U2UdEBcP39OUbCEYOqaeqdTr5lb1D1+YT11wZ+mzTA; Authentication-Results: rtp-dkim-2; header.From=genchang@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 Dave, There is an EAP-FAST implementation on FreeRADIUS from Jouni Malinan. I don't know how much testing has already gone into the module. I don't know of a client side implementation with APIs for you to integrate the SecurID PAC provisioning. Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) WNBU, Technical Leader Office: 603-559-2978 Mobile: 781-799-0233 =20 =20 =20 -----Original Message----- From: david@mitton.com [mailto:david@mitton.com]=20 Sent: Thursday, August 16, 2007 11:01 AM To: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 I with Alan on this. I still haven't seen one yet either. But I'd love to see a version of EAP-FAST that I _could_ work with. Meaning;=20 - it runs with something more accessible than the Cisco ACS server, preferably an open source or reference copy. Maybe even an=20 Windows/IAS plugin. - there is a Windows EAPhost supplicant availible, preferably with=20 interfaces for tunnelled methods and/or interfaces for the ID we wrote=20 for SecurID PAC provisioning. draft-cam-winget-eap-fast-potp-provisioning-00.txt (hmm... time to renew that) If you have any of this, let me know. Dave Mitton, RSA - Security Division of EMC. ----Original Message---- From: genchang@cisco.com Date: Aug 16, 2007 10:13=20 To: "Alan DeKok", "Nancy Winget (ncamwing)" Cc: "Ryan Hurst", Subj: RE: [Emu] Crypto-binding in TTLS-v0 Alan, It is not unusual for developers to be unaware of the breath of the EAP-FAST market adoption. It has been growing under the radar for a=20 lot of people since market research firms do not track market share of different EAP methods. Part of the misperception that EAP-FAST has no market presence has=20 been because no one has been drawing attention to the adoption success of EAP-FAST. I am hoping to assemble some public data to shed a light on the secret life of EAP-FAST. Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) WNBU, Technical Leader Office: 603-559-2978 Mobile: 781-799-0233 =20 =20 =20 -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Thursday, August 16, 2007 8:46 AM To: Nancy Winget (ncamwing) Cc: Ryan Hurst; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Nancy Winget (ncamwing) wrote: > Thanks Alan, I am glad to see that the evaluation is continuing on=20 the > thread.....I think both TTLS and EAP-FAST are being widely deployed and > both merit consideration. I think EAP-FAST has been considered, and has little support. I've never seen an EAP-FAST deployment, and most people I talk to haven't seen one, either. Most people I talk to don't plan on supporting EAP-FAST any time soon. Alan DeKok. _______________________________________________ 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 11:39: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 1ILhRw-0000yX-6C; Thu, 16 Aug 2007 11:39:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhRv-0000yS-0c for emu@ietf.org; Thu, 16 Aug 2007 11:39:51 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILhRu-0002wX-Js for emu@ietf.org; Thu, 16 Aug 2007 11:39:50 -0400 Received: from [192.168.1.102] (ottawa-hs-206-191-39-219.d-ip.magma.ca [206.191.39.219]) by deployingradius.com (Postfix) with ESMTP id 9DA82A7161; Thu, 16 Aug 2007 08:39:47 -0700 (PDT) Message-ID: <46C46FB3.8030005@deployingradius.com> Date: Thu, 16 Aug 2007 11:39:31 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Gene Chang (genchang)" Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <8959994.1187276437046.JavaMail.?@fh1064.dia.cp.net> <0F64770A6FD22C43AAA498C1E774ECC704218533@xmb-rtp-208.amer.cisco.com> In-Reply-To: <0F64770A6FD22C43AAA498C1E774ECC704218533@xmb-rtp-208.amer.cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Gene Chang (genchang) wrote: > There is an EAP-FAST implementation on FreeRADIUS from Jouni Malinan. If there was, I would have known about it. Jouni has added EAP-FAST to hostapd and to wpa_supplicant. While hostapd is a RADIUS server, it's pretty minimal. i.e. not database support, no policy language, etc. If there is an EAP-FAST patch for FreeRADIUS, I'd like to see it. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 12:00: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 1ILhmF-0008HR-EY; Thu, 16 Aug 2007 12:00:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhlf-0006jZ-Tu for emu@ietf.org; Thu, 16 Aug 2007 12:00:17 -0400 Received: from bay0-omc2-s35.bay0.hotmail.com ([65.54.246.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILhle-0002WK-MR for emu@ietf.org; Thu, 16 Aug 2007 12:00:15 -0400 Received: from hotmail.com ([207.46.8.114]) by bay0-omc2-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 16 Aug 2007 09:00:13 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 Aug 2007 09:00:13 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Thu, 16 Aug 2007 16:00:11 GMT X-Originating-IP: [71.197.208.131] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <08A9A3213527A6428774900A80DBD8D804AC37CB@xmb-sjc-222.amer.cisco.com> From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: RE: [Emu] focus on deployed protocols Date: Thu, 16 Aug 2007 09:00:11 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 16 Aug 2007 16:00:13.0403 (UTC) FILETIME=[87B8E2B0:01C7E01E] 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 >Thanks Alan, I am glad to see that the evaluation is continuing on the >thread.....I think both TTLS and EAP-FAST are being widely deployed and >both merit consideration. I would agree that the EMU WG should focus on evaluation of existing, deployed EAP methods for the password work item. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 12:07: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 1ILhsb-00069U-Ho; Thu, 16 Aug 2007 12:07:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhsa-00069P-M3 for emu@ietf.org; Thu, 16 Aug 2007 12:07:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILhsa-0003aP-5y for emu@ietf.org; Thu, 16 Aug 2007 12:07:24 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 16 Aug 2007 09:07:16 -0700 X-IronPort-AV: i="4.19,272,1183359600"; d="scan'208"; a="13724375:sNHT13380746376" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7GG7GZQ023327; Thu, 16 Aug 2007 09:07:16 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7GG6nih021134; Thu, 16 Aug 2007 16:07:16 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 12:06:48 -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] Crypto-binding in TTLS-v0 Date: Thu, 16 Aug 2007 12:06:53 -0400 Message-ID: <0F64770A6FD22C43AAA498C1E774ECC704218556@xmb-rtp-208.amer.cisco.com> In-Reply-To: <46C465CA.8020800@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfgFcOcTCD8NQo3QfO0SDjQCrjnPwACJFjw References: <08A9A3213527A6428774900A80DBD8D804AC37CB@xmb-sjc-222.amer.cisco.com> <46C44700.10409@deployingradius.com> <0F64770A6FD22C43AAA498C1E774ECC704218500@xmb-rtp-208.amer.cisco.com> <46C465CA.8020800@deployingradius.com> From: "Gene Chang \(genchang\)" To: "Alan DeKok" X-OriginalArrivalTime: 16 Aug 2007 16:06:48.0855 (UTC) FILETIME=[736E1270:01C7E01F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2614; t=1187280436; x=1188144436; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=genchang@cisco.com; z=From:=20=22Gene=20Chang=20\(genchang\)=22=20 |Subject:=20RE=3A=20[Emu]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20; bh=MdFGi0MT5rPGuI22a9s9wOOLpqyaOGXordh+G+I3Slw=; b=XH6uW+Upt+FPay4jKaYjT4F5smqA6nFeNEgtEfxe6wL/pLa0nyEUa+eLYsewM8cv5yLd5bH0 8fbZSfCI0H+andj/m4KKwSVNVq+p9ByS0BxFfvaQb7qio/D+Qr6jHNoK3QpRyNVCTvzf9R6C1z sUJLXDbJhl4/MTcuEqwHV2R6s=; Authentication-Results: sj-dkim-1; header.From=genchang@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Ryan Hurst , 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 Alan, I think we can all agree that without the help of the market analysts measuring deployment, comparing our personal perceptions of deployment is a bit like the five blind men and the elephant. I had the pleasure of helping to bring TTLS into the market. The industry conditions in 2003 was very different from 2005-2006. 2003 was a greenfield market so adoption of a strong EAP method was instant (especially with the then prevailing embarrassment of WEP as a protection scheme). By the time EAP-FAST arrived, EAP-FAST had to earn adoption on to its own merits. The adoption characteristic was naturally different from TTLS or PEAP.=20 Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) WNBU, Technical Leader Office: 603-559-2978 Mobile: 781-799-0233 =20 =20 =20 -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Thursday, August 16, 2007 10:57 AM To: Gene Chang (genchang) Cc: Nancy Winget (ncamwing); Ryan Hurst; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Gene Chang (genchang) wrote: > It is not unusual for developers to be unaware of the breath of the > EAP-FAST market adoption. It has been growing under the radar for a lot > of people since market research firms do not track market share of > different EAP methods. I do rather a bit more than just development. I work with people deploying systems from 100 to 10M+ users. I don't see EAP-FAST being adopted. I *do* hear rumors about EAP-FAST from enterprises who have bought single source solutions. > Part of the misperception that EAP-FAST has no market presence has been > because no one has been drawing attention to the adoption success of > EAP-FAST. I am hoping to assemble some public data to shed a light on > the secret life of EAP-FAST. People haven't drawn attention to the adoption success of PEAP or TTLS, either. Instead, people just deployed it in large numbers. I started hearing about PEAP and TTLS almost as soon as they were proposed. There was quick and immediate demand for both protocols from a wide range of systems (small, medium, large). I've seen nothing similar happen with EAP-FAST (so far). Part of the misperception that EAP-FAST has a large market presence has been that the people who are deploying it don't talk to the people *not* deploying it, and vice versa. Within the EAP-FAST camp, it looks like there's wide-spread adoption. Outside of it, it just doesn't come up in any conversation. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 12:17: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 1ILi2i-0004xQ-Bf; Thu, 16 Aug 2007 12:17:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILi2h-0004xL-5R for emu@ietf.org; Thu, 16 Aug 2007 12:17:51 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILi2g-0003pD-OD for emu@ietf.org; Thu, 16 Aug 2007 12:17:51 -0400 Received: from [192.168.1.102] (ottawa-hs-206-191-39-219.d-ip.magma.ca [206.191.39.219]) by deployingradius.com (Postfix) with ESMTP id 6DA87A7161; Thu, 16 Aug 2007 09:17:46 -0700 (PDT) Message-ID: <46C478A4.5070607@deployingradius.com> Date: Thu, 16 Aug 2007 12:17:40 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Gene Chang (genchang)" Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <08A9A3213527A6428774900A80DBD8D804AC37CB@xmb-sjc-222.amer.cisco.com> <46C44700.10409@deployingradius.com> <0F64770A6FD22C43AAA498C1E774ECC704218500@xmb-rtp-208.amer.cisco.com> <46C465CA.8020800@deployingradius.com> <0F64770A6FD22C43AAA498C1E774ECC704218556@xmb-rtp-208.amer.cisco.com> In-Reply-To: <0F64770A6FD22C43AAA498C1E774ECC704218556@xmb-rtp-208.amer.cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Ryan Hurst , 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 Gene Chang (genchang) wrote: > I think we can all agree that without the help of the market analysts > measuring deployment, comparing our personal perceptions of deployment > is a bit like the five blind men and the elephant. I disagree. Sufficient volumes of data make personal perception statistically significant. That's just what market analysts do. > The adoption characteristic was naturally different from TTLS or PEAP. The only relevant characteristic is volume of deployments. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 18:26: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 1ILnnI-0005sQ-5u; Thu, 16 Aug 2007 18:26:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILnnH-0005sL-Oy for emu@ietf.org; Thu, 16 Aug 2007 18:26:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILnnG-0005yB-GU for emu@ietf.org; Thu, 16 Aug 2007 18:26:19 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Aug 2007 18:26:18 -0400 X-IronPort-AV: i="4.19,273,1183348800"; d="scan'208"; a="68208783:sNHT54116986" 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 l7GMQI3J025564; Thu, 16 Aug 2007 18:26:18 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7GMQFmf007718; Thu, 16 Aug 2007 22:26:18 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 18:26:15 -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] Crypto-binding in TTLS-v0 Date: Thu, 16 Aug 2007 18:26:15 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B7050959DD@xmb-rtp-212.amer.cisco.com> In-Reply-To: <0F64770A6FD22C43AAA498C1E774ECC704218533@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcfgFj2Rf3ckydjaT2eAiVB0eQmo0wABEoSQAA5VvTA= References: <8959994.1187276437046.JavaMail.?@fh1064.dia.cp.net> <0F64770A6FD22C43AAA498C1E774ECC704218533@xmb-rtp-208.amer.cisco.com> From: "Hao Zhou \(hzhou\)" To: "Gene Chang \(genchang\)" , , X-OriginalArrivalTime: 16 Aug 2007 22:26:15.0881 (UTC) FILETIME=[75A28B90:01C7E054] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4418; t=1187303178; x=1188167178; 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]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20 |To:=20=22Gene=20Chang=20\(genchang\)=22=20, =20,=0A=20=20=20=20=20=20=20=20; bh=BlWqKmT2JPv0CukmFfbWXozk3qS5IjXRY2ldrVsmsTo=; b=lm1zWU9Hr8zKIgMAj5rh3pKZ2mHNiHUfIpQJRGbc8yVunl12aomrTMxYFe5C2HgKpQPTLG64 nR3gdEF9c+mlAHzNgsq+pXt0i5qCQNdMhdMOE2PmogTHI5e4I2VsPC91; Authentication-Results: rtp-dkim-2; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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 There is an EAP-FAST module for EAPHost plug-in, which currently uses three hard coded inner methods, EAP-GTC, EAP-MSCHAPv2 and EAP-TLS. But it can be extended to work with EAPHost supplicant interface to load any inner method registered with EAPHost. Will you have a POTP plug-in soon? The problem is to find a server that supports provisioning with POTP. I can work with you to make it happen. > -----Original Message----- > From: Gene Chang (genchang)=20 > Sent: Thursday, August 16, 2007 11:36 AM > To: david@mitton.com; emu@ietf.org > Subject: RE: [Emu] Crypto-binding in TTLS-v0 >=20 > Dave, > There is an EAP-FAST implementation on FreeRADIUS from Jouni=20 > Malinan. I don't know how much testing has already gone into=20 > the module. >=20 > I don't know of a client side implementation with APIs for=20 > you to integrate the SecurID PAC provisioning. >=20 > Gene >=20 > -------------------------------------------------------------- > ---------- > ---- > Eugene Chang (genchang) > WNBU, Technical Leader > Office: 603-559-2978 > Mobile: 781-799-0233 > =20 > =20 > =20 >=20 > -----Original Message----- > From: david@mitton.com [mailto:david@mitton.com] > Sent: Thursday, August 16, 2007 11:01 AM > To: emu@ietf.org > Subject: RE: [Emu] Crypto-binding in TTLS-v0 >=20 > I with Alan on this. > I still haven't seen one yet either. >=20 > But I'd love to see a version of EAP-FAST that I _could_ work with. >=20 > Meaning; > - it runs with something more accessible than the Cisco ACS=20 > server, preferably an open source or reference copy. Maybe=20 > even an Windows/IAS plugin. >=20 > - there is a Windows EAPhost supplicant availible, preferably=20 > with interfaces for tunnelled methods and/or interfaces for=20 > the ID we wrote for SecurID PAC provisioning. > draft-cam-winget-eap-fast-potp-provisioning-00.txt > (hmm... time to renew that) >=20 > If you have any of this, let me know. >=20 > Dave Mitton, > RSA - Security Division of EMC. >=20 > ----Original Message---- > From: genchang@cisco.com > Date: Aug 16, 2007 10:13 > To: "Alan DeKok", "Nancy Winget (ncamwing)" > > Cc: "Ryan Hurst", > Subj: RE: [Emu] Crypto-binding in TTLS-v0 >=20 > Alan, > It is not unusual for developers to be unaware of the breath=20 > of the EAP-FAST market adoption. It has been growing under=20 > the radar for a lot of people since market research firms do=20 > not track market share of different EAP methods. >=20 > Part of the misperception that EAP-FAST has no market=20 > presence has been because no one has been drawing attention=20 > to the adoption success of EAP-FAST. I am hoping to assemble=20 > some public data to shed a light on the secret life of EAP-FAST. >=20 > Gene >=20 > -------------------------------------------------------------- > ---------- > ---- > Eugene Chang (genchang) > WNBU, Technical Leader > Office: 603-559-2978 > Mobile: 781-799-0233 > =20 > =20 > =20 >=20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Thursday, August 16, 2007 8:46 AM > To: Nancy Winget (ncamwing) > Cc: Ryan Hurst; emu@ietf.org > Subject: Re: [Emu] Crypto-binding in TTLS-v0 >=20 > Nancy Winget (ncamwing) wrote: > > Thanks Alan, I am glad to see that the evaluation is continuing on > the > > thread.....I think both TTLS and EAP-FAST are being widely deployed > and > > both merit consideration. >=20 > I think EAP-FAST has been considered, and has little=20 > support. I've never seen an EAP-FAST deployment, and most=20 > people I talk to haven't seen one, either. Most people I=20 > talk to don't plan on supporting EAP-FAST any time soon. >=20 > Alan DeKok. >=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 >=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 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 16 22:57: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 1ILs1L-0004gI-DW; Thu, 16 Aug 2007 22:57:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILs1K-0004gD-SV for emu@ietf.org; Thu, 16 Aug 2007 22:57:06 -0400 Received: from mail1.sea5.speakeasy.net ([69.17.117.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILs1J-0005IH-Jd for emu@ietf.org; Thu, 16 Aug 2007 22:57:06 -0400 Received: (qmail 28973 invoked from network); 17 Aug 2007 02:57:04 -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 ; 17 Aug 2007 02:57:04 -0000 Received: by jm (sSMTP sendmail emulation); Thu, 16 Aug 2007 19:56:00 -0700 Date: Thu, 16 Aug 2007 19:56:00 -0700 From: Jouni Malinen To: Alan DeKok Subject: Re: [Emu] Crypto-binding in TTLS-v0 Message-ID: <20070817025600.GA1415@jm.kir.nu> References: <8959994.1187276437046.JavaMail.?@fh1064.dia.cp.net> <0F64770A6FD22C43AAA498C1E774ECC704218533@xmb-rtp-208.amer.cisco.com> <46C46FB3.8030005@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46C46FB3.8030005@deployingradius.com> 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 Thu, Aug 16, 2007 at 11:39:31AM -0400, Alan DeKok wrote: > Gene Chang (genchang) wrote: > > There is an EAP-FAST implementation on FreeRADIUS from Jouni Malinan. > > If there was, I would have known about it. Yes, and I would assume I would also be aware of this should such a thing have happened ;-). > Jouni has added EAP-FAST to hostapd and to wpa_supplicant. While > hostapd is a RADIUS server, it's pretty minimal. i.e. not database > support, no policy language, etc. I added EAP-FAST support to hostapd mainly to make it (much) easier for me to test client side code in wpa_supplicant. Anyway, that means that there is an open source implementation available for both the server and peer side of EAP-FAST should someone be interested in testing them and was just waiting for broader set of available implementations or access to source code. I would obviously be interested in any feedback on the implementations, too. I try to run as complete interop tests with other implementations as feasible, but don't really have unlimited resources for doing this, so any additional testing would be welcome. Sure, hostapd as a RADIUS server is not meant for large and complex deployments, but I think it works well as a testbed component for testing various EAP methods, including EAP-FAST. In addition, based on past history, it looks like I have quite open view in adding support for new EAP methods regardless of their completeness, popularity, or even suitability for anything ;-). I see this as one of the best ways to evaluate protocol designs and specifications and more or less mandatory part of standard development. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 21 01:26:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INMGB-00088f-64; Tue, 21 Aug 2007 01:26:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INMG9-00086w-Rj for emu@ietf.org; Tue, 21 Aug 2007 01:26:33 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INMG7-0008JP-OX for emu@ietf.org; Tue, 21 Aug 2007 01:26:33 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 20 Aug 2007 22:26:32 -0700 X-IronPort-AV: i="4.19,287,1183359600"; d="scan'208"; a="393375190:sNHT92242118" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7L5QViO020649 for ; Mon, 20 Aug 2007 22:26:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l7L5QQgD008120 for ; Tue, 21 Aug 2007 05:26:31 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, 20 Aug 2007 22:26:27 -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, 20 Aug 2007 22:26:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes from IETF-69 Thread-Index: Acfjs9K7AIFWsUVSS2u6eS5A3VkscA== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 21 Aug 2007 05:26:27.0930 (UTC) FILETIME=[D2D6EBA0:01C7E3B3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18673; t=1187673991; x=1188537991; 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:=20Minutes=20from=20IETF-69 |Sender:=20; bh=MJ9zSzRjCRb6f95Q7pUrJV0fpsZVq+47wWNUvM6Xpu0=; b=JsGjDsp3IxWw4C71e2Tg9PogbVibMgMZ7u+SFyVvcTksp1nnAaXw0HH0Hk4Fcd+mcE/DhWg0 YrvCQ6prKOFdwJS+FM1jHSBWeiUL0vcp5xMjpG1tox0yKZjYTHbhSiF9; 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: 2fe944273194be3112d13b31c91e6941 Subject: [Emu] Minutes from IETF-69 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 minutes to the EMU session at IETF-69. I will also upload them to the proceedings page. Let me know if you have any corrections. Thanks to Mauricio and Nancy for taking good notes. Joe Notes from EMU meeting at IETF 69 Tuesday, July 24, 2007 Chicago Agenda ----------------------- + Administrivia (5 min) Note takers, blue sheets, agenda bashing + Document Status (20 min) EAP-TLS (5 min) EAP-GPSK (15 min) + IEEE Liaison Request (20 min) + Password based method (75 min) Requirements (10 min) PP-EAP - draft-zhou-emu-pp-eap-01.txt (20 min) EAP-TTLS - draft-funk-eap-ttls-v0-01.txt (20 min) Discussion (25 min) Document Status --------------------- + EAP-TLS=20 Ready to go to the IESG + EAP-GPSK Some open comments still need to be addressed that will be addressed in security considerations. + IEEE Liaison Request Matthew Gast presented overview of work in 802.11u related to requirements for an EAP method for emergency services. Joe Salowey: surprised by request. There is already a WG in IETF working on emergency related technology. thought that group would be tapped instead of EMU. Matthew Gast: Highlighted the EMU was tapped instead of ECRIT because they deal with high-order call handling. EMU seen as better WG to answer question at hand. =20 - Matthew Gast Presents Bernard Aboba: asserted that EAP methods have poorer DoS resistance than PSK. Joe: agrees Matthew: admits he was loose with usage of DoS Presentation Continues Paul Hoffman: in what way EAP is used by 802.11 Matthew: it's for link-layer operations Presentation continues:=20 - Basic requirements for emergency services:=20 1) No pre-existing trust relationships - anonymous cryptography is acceptable to them - Is it secure? 2) Small number of round-trips=20 - concern that TLS messages are too long, they'd like to reduce latency - want fast speed of access since they realize the call will be of short duration Hannes Tschofenig: suggests that a new EAP type be allocated that then leverages a watered-down version of EAP-TLS that satisfies the reduced security requirements for 802.11u. =20 Bernard: questions the requirement for regulatory requirements driving need for link encryption. Points out that the encryption without authentication is not satisfying any useful security requirements. =20 Matthew: responds that operators/carriers sometimes reject having an open SSID. =20 Bernard: most will have at least one open SSID. Matthew: in 11u, an SSID is set up that is dedicated only to emergency services. Objections in 802.11 to design a network only for emergency services....there is some fear that they conversation will have to be protected somehow, at least from hijacking, spoofing or splicing. From a network implementation view, the username in the public credential can be defined as being part of the emergencies architecture to know to treat it in a special way without having to reconstruct the infrastructure. Bernard: questions who the regulatory compliance requirements apply to: Is it enterprise or carrier. Joe: points out that there are still questions about requirements, but doesn't feel that EMU WG is not the right forum to discuss or change the initial requirements. there may still be some requirements based on the presentation. It's not clear that requirements are valid or that EMU can address this. Most of the work items and the way EAP works is focused on authenticating the peer. There may be possible solutions, as Hannes brought up a special method for it. Steve Hana: EAP-TTLS supports server-side auth only if needed. Joe: take discussion to list to see if there is anyone on list that has additional insight on what could solve 802.11u requirement Hao Zhou: asks about timelines Matthew: says this exercise is not critical path for their work. They ultimately just want to point to the IETF recommendation at the end.=20 Dorothy: it would be extremely desirable to have a final recommendation by July '08. Hao: feels that there is no need for a new EAP method. Existing EAP protocols can be leveraged as long as a pre-defined policy is adhered to that satisfies 802.11u requirements. Joe: don't know of any standard track methods that could address this. If there is work to be done, we'll need a liaison to keep the work going. Hao: based on some current methods, it doesn't seem like a new protocol is needed but rather a policy to help validate the server cert or client credential. If we can make the current EAP method that can be configured in such a way, no new method is needed. Joe: to do something expedient, there may be more work that is required since the current methods do not meet all of the requirements presented by TGu. + Password Based Method Joe: excused himself that he was not able to dedicate as much time as desired into this work item. Other high-priorities (EAP-TLS and EAP-GPSK) took his time. Joe goes through password based requirements Paul: Question whether password need to be truly randomized or can it be human "memorizable". Joe: says that password can be anything perceived as a "password". Gareth: asks whether OTP have been considered, asks if this would preclude POTP Chair: this mechanism is looking at supporting a password, could be but not limited to OTP Gareth: only mentioned other password - Hao Zhou presents PP-EAP Kaushik Narayan: asks how this work is different from EAP-PEAPv2 or EAP-TTLS? Is this a new method? =20 Hao: says that they leveraged common design details from existing EAP methods and that a new EAP type will be likely allocated. This work may conceptually boil down to just extensions of existing methods, but because versioning brings its own set of disadvantages the cleaner approach is to treat it as a separate EAP method. =20 Kaushik: responds that he felt the desire of IETF was to reduce the number of EAP methods, not increase them. =20 Hao: a lot of these constructs were taken from other methods. But because other constructs are added and to solve interoperability issues, a new EAP method type is to be assigned. Kaushik: this is potentially a new version of an existing method. Joe: a concern of the extensibility, is that the WG charter item is to do a password based method. With the extensibility, will get us well beyond the WG item and make it more complex than it needs to be and cause interoperability issues. Make sure that the decisions we make do not confine us or cause more confusion. Kaushik: thought we need less not more methods Hao: but we need one that will be adopted by all and interoperate Glen Zorn: Asks where key material only comes from TLS exchange. =20 Hao: yes. =20 Glen: asks how crypto binding can be done if there is only a password. Glens asks whether the method has an inner method defined. =20 Hao: no. Crypto binding left in method to allow future extensions that may require crypto binding. Today it's not required. If group feels that there should be no crypto binding, then it can be removed. Charles Clancy: the reason for the attack in MSCHAPv2 is because it could be done outside. Here there is no inner method, so it can not be run outside the tunnel. So, there's no need to bind the exchange to the keys derived. For this specific step....the binding is done for future. Doesn't believe we should support tunneled method inside this (like EAP-MSCHAPv2) the Glen: not really true. PEAP was that it could be used the same form of the password for other methods, this is true for stuff like VPN. We can not outlaw them for multi-use password Sam: needs to be documented in the security considerations David Nelson: points out that we should be careful on number of bells and whistles added. Points out that current proposal is a mega-method with ability to define any number of smaller sub-methods.=20 Hannes: counters that there may be usefulness for allowing for future extensibility, in particular in light of desire to reduce number of future EAP methods.=20 Dave: but then that should be another method. Dan Harkins: sarcastically points out that no one ever uses self-signed certificates on their authentication serves. Usage of self-signed certificates essentially nullifies any value of TLS. Passwords would be effectively transferred in the clear. Hao: but there are some backend databases where clear text password is not accessible. Hannes: EMU has already adopted methods like EAP-GPSK that could be used for such a purpose.=20 Bernard: comments that the PEAP MiTM attack had nothing to do with the method. Hannes: so this should force us to put a requirement to guard against such an attack? Charles: http authentication over TLS. We're not worried about binding the password into the TLS key. Sam: but we should be Joe: seems like crypto-binding should not be required if we're trying to "keep it simple"". Kaushik: asks whether this new method could be run as a inner method to another method. =20 Hao: says no, but there isn't any way to disallow it. =20 Joe: the idea is to avoid that situation. Which is why we need to limit what is inside this tunnel (method).=20 Glen: Original question: since problem is reuse of credentials and we can not force people to use the same password on different applications, how are we going to address this? Hao: we can not fix it because it is not on our scope. We can put the limits into the security considerations. Glen: points out since the re-use of credentials is the base weakness at root to many security vulnerabilities, is there anything this method that will prevent credential re-use. =20 Hao: says no. Glen: isn't the layer EAP and PP-EAP mixed up? Hao: this is looking at it from a packet encapsulation layer Kaushik: are these EAP TLVs? Hao: these are just plain TLVs. Application layer TLS data. Joe: packet format looks like EAP-TLS Hao: yes. Sam Hartman: : we haven't had enough fun yet. Problem #1: what language should the password be in? Invite to side session on Thursday to talk about internationalization. The discussion will be on what lead to the stringprep discussion. Stringprep requires exact matching vs. fuzzy matching; not clear that passwords in all environment meet that requirement. It may be reasonable to try different normalization of a password. We had an attempt in SASL (for internationalization); but need to carefully consider when stringprep is used (profile and design of profile needs to be strongly reviewed). Hao: asks whether usage of just UTF-8 would suffice. =20 Sam: Answer is an emphatic no from Sam. Hannes: asks for suggestions on what to do. =20 Sam: says attend the Thursday SAAG meeting and read the draft that deals with issues on internationalization. Glen: L2TP talks about internationalization so you may take a look at that too. Charles: Asks whether we need to wait until TLS exchange completes in order to start exchanging challenges. =20 Hao: says that it's possible to optimize and start exchanging information beforehand. =20 - Steve Hanna presents EAP-TTLS Joe: asks why allow a DIAMETER AVP in EAP method? =20 Steve: clarified that format is leveraged but not the code types. =20 Bernard: this is not reusing Diameter, it is using the AVP format. Joe: only format or type codes? Steve: only the codes from RADIUS. Joe: it is confusing to reuse the typespace from RADIUS Allan: it is implicit, it seems like this is overly RADIUS. One should not put RADIUS stuff inside the authentication message originated by the client. Joe: agrees Bernard: but could use it for channel binding Sam: will need them for Housley key management Steve: Base assertion is that EAP-TTLS can cover all requirements, so why start over? Hannes: Hannes asserts whether after all the changes being introduced (channel binding and internationalization) can EAP-TTLS still be called as EAP-TTLS. =20 Steve: what you'd be doing is providing additional AVPs, the client can send an AVP that it would prefer to use the new AVPs and the server would have to ignore them if it doesn't know it. Hannes: challenges whether EAP-TTLS can make the claim that it's free of IPR restrictions.=20 Steve: the extensions that we would define in TTLS vs. starting from a new protocol. But do we want to start with something that has been widely implemented and extend AVPs or do we want to start from scratch that can only be used for passwords. Seems likely that the marketplace has been enthusiastic about TTLS, but if we create a new way for password; it seems unlikely to him that 'they' would abandon already existing code . Crypto binding are no longer considered a requirement. Hao: challenges statement that the other, PP-EAP, protocol is not widely implemented. Not true it is based on EAP-TLS which is widely deployed. There are also other protocol=20 Steve: it would interoperate, it just wouldn't take advantage of the new features. If you want to add crypto agility to TTLS Hao: to meet this requirement, need to add crypto binding. This will need to be added. Steve: if there is an AVP it doesn't know, you ignore it. =20 Hao: there are a lot of options that the negotiation of what's required versus not may be too confusing and complex. Vidya Narayanan: Adding TLV to address Hao's point, if there's extensions or changing the version number seems simple. So, would be a proponent to adopting something that is already deployed. What is missing from TTLS that we would have to add? Joe: there were requirements that TTLS is not meeting which is why the extensions to TTLS were proposed=20 Kaushik: there are 2 options. What is being proposed is an "uber" method, but essentially do all the password based mechanism...that is the key difference between TTLS and PP-EAP. So, are we looking at an "uber" method approach? Because if we are doing that then we should look at EAP-FAST or other tunneled methods. Alan: TTLS uses the Diameter AVP, what are the IANA considerations for the number space because it is reusing some of the name space? Steve: Paul would be a better person to answer this. Bernard: the scourge comes from vendor specific. When talking to customers: they do not say "we need more EAP methods". If it possible to start from something that is widely implemented, then it would cause a lot less pail. The nice thing about TTLS, it supports the notion of non-mandatory AVPs so it makes it easy to add the channel and crypto binding. So there is a nice transition story since there is open source code available. For something like channel binding we will need code. Charles: advantages of PP-EAP over TTLS. The fact that PP-EAP cuts out the unneeded things is the advantage; from an interoperability standpoint. Hannes: comment on what's new and what's not: If you have a new protocol and put stuff to it, like changing or adding AVP's, is that new? It is a philosophical issue. To interoperability issue: it is a tighter specification versus "flexibility" in negotiation. There is rarely a chance to change or "fix" some of the concepts like key derivation, then it is not the same method. Joe: a notice on both approaches. We're looking for a password based method, but then we get the kitchen sink which worries me. There's a significant amount of things just to meet the password based method, like change of password, character sets that throwing other things is expanding the charter and in general introduces a lot of complexity. Gabriel Montenegro: seems painfully obvious that we need to start with something that runs is known, has been known not to be extended and very importantly has been adopted by different organizations. These are critical for actual deployment, TTLS is already being certified by WiFi and soon Wimax, that should not be discounted to easily. Alan and Steve: were going to say the same thing. - Joe puts out question whether group has opinion whether we should focus on just a simple password-based method or a more-complex, yet extensible, method.=20 David: : this sounds like re-do the charter. Seems like the work that was chartered was just a password method. Now it sounds like we are trying to rescope the charter. Joe: there are potential implications in adopting something broader, like complexities and potentially more work. Glen: depends if you're pragmatic or theologian. TTLS is password based but happens to be more...so it can be considered outside the charter Sam: you can give me a TTLS and thou shall use it only for certain things. Glen: asserts that the editors of EAP-TTLS haven't been very active in WG. Nervous about accepting work.=20 Sam: says we can steal it, as long as they are fine with it. =20 Steve: suggests that=20 Glen: if we do what Sam suggests, since it is being considered by other groups, they are not going to accept the idea of just plaintext passwords. So if our RFC says only plaintext then the other groups may not adopt. Steve: if we take TTLS as the start, then the TTLSv0 could be documented as the start. That could be the stable point to start from. Could also move forward in adding the AVPs to make sure that all requirements are being met....and then there could be another document to state how it is limited to address Hao: concerned that if only a subset of TTLS functionality is carved out whether it would introduce unacceptable interoperability problems.=20 Alan: to a certain extent, EMU requirements could be to define a new type to carry the restrictions of TTLS.=20 Bernard: procedural complexity of informational, standards and working drafts. But from a purely technical point, it could be done without having to bump a version number. Joe asks the WG to hum on two questions: - Should we focus efforts on a password method, which could be based on EAP-TTLS, EAP-PP, and can only be extended with channel bindings but nothing else? - Should we focus efforts on a method that performs password authentication and is extensible to do other forms of authentication? - Louder hum recorded to limit ourselves to just password method. - WG requests and Joe grants a hum on two additional questions Second question - Who would like to base this on EAP-TTLS? - Who would like to base this on a new method? Consensus of hum is difficult to discern. Joe: let's take it to the list.=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 21 14:09: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 1INYAX-0006Er-Gh; Tue, 21 Aug 2007 14:09:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYAW-0006Em-Ai for emu@ietf.org; Tue, 21 Aug 2007 14:09:32 -0400 Received: from stratton-six-thirty.mit.edu ([18.187.7.119] helo=carter-zimmerman.suchdamage.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INYAW-0007QV-1L for emu@ietf.org; Tue, 21 Aug 2007 14:09:32 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8883648C3; Tue, 21 Aug 2007 14:09:31 -0400 (EDT) From: Sam Hartman To: "Joseph Salowey \(jsalowey\)" Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: Date: Tue, 21 Aug 2007 14:09:31 -0400 In-Reply-To: (Joseph Salowey's message of "Tue, 14 Aug 2007 11:18:18 -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.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 As a matter of process, if EMU is going to satisfy its charter item regarding passwords, it will need to refer to a standards-track EAP type of some kind. The existing process for getting EAP methods published as RFCs does not result in standards track RFCs. So, if EMU is going to base its work on something existing, it is probably important for EMU to take on the entire method. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Aug 22 00:38: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 1INhzS-0000oA-6f; Wed, 22 Aug 2007 00:38:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INhzR-0000nU-8y for emu@ietf.org; Wed, 22 Aug 2007 00:38:45 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INhzP-0000VC-Ls for emu@ietf.org; Wed, 22 Aug 2007 00:38:45 -0400 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 1D461A704E; Tue, 21 Aug 2007 21:38:35 -0700 (PDT) Message-ID: <46CBBDC3.50300@deployingradius.com> Date: Wed, 22 Aug 2007 06:38:27 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Sam Hartman wrote: > So, if EMU is going to base its work on something existing, it is > probably important for EMU to take on the entire method. If consensus is to use EAP-TTLS, then I would suggest publishing the base EAP-TTLS document pretty much as-is as a standards-track document. The additional EMU requirements can be addressed in a separate document. This process lets us get something done quickly. I would prefer to void spending years talking about a new EAP method, followed by years of trying to get it widely deployed. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Aug 22 00:45:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INi5y-0005g8-EC; Wed, 22 Aug 2007 00:45:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INi5x-0005g3-EB for emu@ietf.org; Wed, 22 Aug 2007 00:45:29 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INi5w-0000f7-0e for emu@ietf.org; Wed, 22 Aug 2007 00:45:29 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7M4jNMX021611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Aug 2007 21:45:23 -0700 Received: from [10.50.69.155] (qconnect-10-50-69-155.qualcomm.com [10.50.69.155]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7M4jMc6002584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Aug 2007 21:45:22 -0700 (PDT) Message-ID: <46CBBF61.8070207@qualcomm.com> Date: Tue, 21 Aug 2007 21:45:21 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alan DeKok Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46CBBDC3.50300@deployingradius.com> In-Reply-To: <46CBBDC3.50300@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Sam Hartman , 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 would like to see the crypto-binding stuff (not compound binding -- as others have noted, we don't have consensus on that topic) and extensibility (how to add new attributes) specified. That should not take more than 1-2 months to write-up, review and finalize :). That should also be least disruptive to existing implementations. I would also like to see TTLS-v0 published very soon. regards, Lakshminath On 8/21/2007 9:38 PM, Alan DeKok wrote: > Sam Hartman wrote: >> So, if EMU is going to base its work on something existing, it is >> probably important for EMU to take on the entire method. > > If consensus is to use EAP-TTLS, then I would suggest publishing the > base EAP-TTLS document pretty much as-is as a standards-track document. > The additional EMU requirements can be addressed in a separate document. > > This process lets us get something done quickly. I would prefer to > void spending years talking about a new EAP method, followed by years of > trying to get it widely deployed. > > Alan DeKok. > > _______________________________________________ > 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 Aug 22 02:18: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 1INjXc-00053h-T6; Wed, 22 Aug 2007 02:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INjXY-00053E-OH for emu@ietf.org; Wed, 22 Aug 2007 02:18:04 -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 1INjXX-0002dE-EF for emu@ietf.org; Wed, 22 Aug 2007 02:18:04 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 21 Aug 2007 23:18:02 -0700 X-IronPort-AV: i="4.19,292,1183359600"; d="scan'208"; a="14449121:sNHT23468310" 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 l7M6I2U8009705; Tue, 21 Aug 2007 23:18:02 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7M6I27J011362; Wed, 22 Aug 2007 06:18:02 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 02:18:02 -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] Crypto-binding in TTLS-v0 Date: Wed, 22 Aug 2007 02:17:59 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> In-Reply-To: <46CBBF61.8070207@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: Acfkd0uBgY8ilB6vTRGLp2GifFe46QAC6knw References: <46CBBDC3.50300@deployingradius.com> <46CBBF61.8070207@qualcomm.com> From: "Hao Zhou \(hzhou\)" To: "Lakshminath Dondeti" , "Alan DeKok" X-OriginalArrivalTime: 22 Aug 2007 06:18:02.0018 (UTC) FILETIME=[31790820:01C7E484] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2485; t=1187763483; x=1188627483; c=relaxed/simple; s=sjdkim2002; 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]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20; bh=rYD58xSpDvpGac4tUhaV4AihBFWyvq9Y+qyo5h72JZI=; b=KNUvEOy2zrQCn2AzLf2+zZTwlxyoCZ37i90d22xTZP7PbIkgXPNV2BzhPTO7S8JDvc4StB9x Yo8OL+e2LP+Rsi0DrmfnfaT+YNGQbZC8CSG5b5DieAYi3Qiztj1LSo40; Authentication-Results: sj-dkim-2; header.From=hzhou@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Sam Hartman , 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: Do you mean channel binding, not "compound binding"? I thought crypto-binding is "compound-binding". I think publishing a "widely" deployed EAP method is orthogonal to publishing a new method meeting EMU charter. I agree publishing the existing method as deployed is something needs to be done quickly. I am still doubtful that adding the extra stuff required to meet the charter (crypto-binding, crypto-agility, synchronized result indication, internationalization), to the existing method can be done without breaking backward compatibility. If indeed breaks it, then the argument of TTLS is widely deployed doesn't stand anymore. The new method or new version of the old method still needs to be implemented and deployed. > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Wednesday, August 22, 2007 12:45 AM > To: Alan DeKok > Cc: Sam Hartman; emu@ietf.org > Subject: Re: [Emu] Crypto-binding in TTLS-v0 >=20 > I would like to see the crypto-binding stuff (not compound=20 > binding -- as others have noted, we don't have consensus on=20 > that topic) and extensibility (how to add new attributes) specified. >=20 > That should not take more than 1-2 months to write-up, review=20 > and finalize :). That should also be least disruptive to=20 > existing implementations. I would also like to see TTLS-v0=20 > published very soon. >=20 > regards, > Lakshminath >=20 > On 8/21/2007 9:38 PM, Alan DeKok wrote: > > Sam Hartman wrote: > >> So, if EMU is going to base its work on something existing, it is=20 > >> probably important for EMU to take on the entire method. > >=20 > > If consensus is to use EAP-TTLS, then I would suggest=20 > publishing the=20 > > base EAP-TTLS document pretty much as-is as a=20 > standards-track document. > > The additional EMU requirements can be addressed in a=20 > separate document. > >=20 > > This process lets us get something done quickly. I would=20 > prefer to=20 > > void spending years talking about a new EAP method,=20 > followed by years=20 > > of trying to get it widely deployed. > >=20 > > Alan DeKok. > >=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 From emu-bounces@ietf.org Wed Aug 22 02:24: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 1INjdu-0001xI-Nh; Wed, 22 Aug 2007 02:24:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INjdt-0001uo-Rp for emu@ietf.org; Wed, 22 Aug 2007 02:24:37 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INjds-0000BY-QI for emu@ietf.org; Wed, 22 Aug 2007 02:24:37 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7M6OWiT028546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Aug 2007 23:24:32 -0700 Received: from [10.50.69.155] (qconnect-10-50-69-155.qualcomm.com [10.50.69.155]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7M6OV2O007310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Aug 2007 23:24:31 -0700 (PDT) Message-ID: <46CBD69E.4080305@qualcomm.com> Date: Tue, 21 Aug 2007 23:24:30 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hao Zhou (hzhou)" Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46CBBDC3.50300@deployingradius.com> <46CBBF61.8070207@qualcomm.com> <9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> In-Reply-To: <9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Sam Hartman , 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 Yeah, sorry. I meant channel binding. I am not necessarily tying TTLS-v0 with the password-based EMU method deliverable. If the extensibility is there, that decision could be separated from the much needed publication of TTLS-v0. regards, Lakshminath On 8/21/2007 11:17 PM, Hao Zhou (hzhou) wrote: > Lakshminath: > > Do you mean channel binding, not "compound binding"? I thought > crypto-binding is "compound-binding". > > I think publishing a "widely" deployed EAP method is orthogonal to > publishing a new method meeting EMU charter. I agree publishing the > existing method as deployed is something needs to be done quickly. I am > still doubtful that adding the extra stuff required to meet the charter > (crypto-binding, crypto-agility, synchronized result indication, > internationalization), to the existing method can be done without > breaking backward compatibility. If indeed breaks it, then the argument > of TTLS is widely deployed doesn't stand anymore. The new method or new > version of the old method still needs to be implemented and deployed. > >> -----Original Message----- >> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >> Sent: Wednesday, August 22, 2007 12:45 AM >> To: Alan DeKok >> Cc: Sam Hartman; emu@ietf.org >> Subject: Re: [Emu] Crypto-binding in TTLS-v0 >> >> I would like to see the crypto-binding stuff (not compound >> binding -- as others have noted, we don't have consensus on >> that topic) and extensibility (how to add new attributes) specified. >> >> That should not take more than 1-2 months to write-up, review >> and finalize :). That should also be least disruptive to >> existing implementations. I would also like to see TTLS-v0 >> published very soon. >> >> regards, >> Lakshminath >> >> On 8/21/2007 9:38 PM, Alan DeKok wrote: >>> Sam Hartman wrote: >>>> So, if EMU is going to base its work on something existing, it is >>>> probably important for EMU to take on the entire method. >>> If consensus is to use EAP-TTLS, then I would suggest >> publishing the >>> base EAP-TTLS document pretty much as-is as a >> standards-track document. >>> The additional EMU requirements can be addressed in a >> separate document. >>> This process lets us get something done quickly. I would >> prefer to >>> void spending years talking about a new EAP method, >> followed by years >>> of trying to get it widely deployed. >>> >>> Alan DeKok. >>> >>> _______________________________________________ >>> 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 Wed Aug 22 05:56: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 1INmx1-000726-6U; Wed, 22 Aug 2007 05:56:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INmwz-00071y-Mn for emu@ietf.org; Wed, 22 Aug 2007 05:56:33 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INmwz-0004f4-3H for emu@ietf.org; Wed, 22 Aug 2007 05:56:33 -0400 Received: from [10.0.1.38] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id BE46CA704E; Wed, 22 Aug 2007 02:56:22 -0700 (PDT) Message-ID: <46CC083E.7000908@deployingradius.com> Date: Wed, 22 Aug 2007 11:56:14 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Hao Zhou (hzhou)" Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46CBBDC3.50300@deployingradius.com> <46CBBF61.8070207@qualcomm.com> <9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> In-Reply-To: <9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Sam Hartman , 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 Hao Zhou (hzhou) wrote: > I think publishing a "widely" deployed EAP method is orthogonal to > publishing a new method meeting EMU charter. I agree publishing the > existing method as deployed is something needs to be done quickly. I am > still doubtful that adding the extra stuff required to meet the charter > (crypto-binding, crypto-agility, synchronized result indication, > internationalization), I'm not sure why internationalization is an issue. This came up in RADEXT a while ago. The consensus at the time was that RFC 4282 discusses internationalization of the NAI, and that passwords don't need to be internationalized. Internationalization matters for *display* to end users. Internationalization is about *languages*. Passwords aren't displayed, and they aren't words in any language. They're opaque tokens that users have memorized, and can repeat on demand to demonstrate secret knowledge. > to the existing method can be done without > breaking backward compatibility. If indeed breaks it, then the argument > of TTLS is widely deployed doesn't stand anymore. The new method or new > version of the old method still needs to be implemented and deployed. One of the suggestions at IETF 69 was that TTLS was at least safely backwards compatible with any new feature. i.e. The new features would require changes to the content of the TLS tunnel, and not much else. Those changes could be done via AVP's with the "M" bit set. Existing clients would know enough to fail when they saw an "M" bit set on an AVP that they didn't understand. Do you expect that crypto-binding/agility features would require changes that are not compatible with existing TTLS deployments? If so, can you provide examples? Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Aug 22 07:14:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INoAh-0008BO-T2; Wed, 22 Aug 2007 07:14:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INoAU-00087C-39 for emu@ietf.org; Wed, 22 Aug 2007 07:14:34 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INoAT-0006VR-Jq for emu@ietf.org; Wed, 22 Aug 2007 07:14:33 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 29B8848C3; Wed, 22 Aug 2007 07:14:32 -0400 (EDT) From: Sam Hartman To: Alan DeKok Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46CBBDC3.50300@deployingradius.com> <46CBBF61.8070207@qualcomm.com> <9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> <46CC083E.7000908@deployingradius.com> Date: Wed, 22 Aug 2007 07:14:32 -0400 In-Reply-To: <46CC083E.7000908@deployingradius.com> (Alan DeKok's message of "Wed, 22 Aug 2007 11:56:14 +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: bb8f917bb6b8da28fc948aeffb74aa17 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 >>>>> "Alan" == Alan DeKok writes: Alan> Hao Zhou (hzhou) wrote: >> I think publishing a "widely" deployed EAP method is orthogonal >> to publishing a new method meeting EMU charter. I agree >> publishing the existing method as deployed is something needs >> to be done quickly. I am still doubtful that adding the extra >> stuff required to meet the charter (crypto-binding, >> crypto-agility, synchronized result indication, >> internationalization), Alan> I'm not sure why internationalization is an issue. This Alan> came up in RADEXT a while ago. The consensus at the time Alan> was that RFC 4282 discusses internationalization of the NAI, Alan> and that passwords don't need to be internationalized. Alan> Internationalization matters for *display* to end users. Alan> Internationalization is about *languages*. Passwords aren't Alan> displayed, and they aren't words in any language. They're Alan> opaque tokens that users have memorized, and can repeat on Alan> demand to demonstrate secret knowledge. The consensus of the SASL and Kerberos communities has been different. In particular, these communities believe that it is strongly desirable that the same password when entered on two different systems actually work. To get that, you need to deal with issues like normalization. Otherwise, if you use a system with input methods that produce combined characters you will get different results than if you use input methods that produce decomposed characters. At some level, this is an implementation issue for the server. However to support the server, you definitely need to label the character set, discuss any normalization that the client should do (often none) and set interoperability goals. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Aug 22 07:48: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 1INohU-0004kG-25; Wed, 22 Aug 2007 07:48:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INohS-0004k9-Nc for emu@ietf.org; Wed, 22 Aug 2007 07:48:38 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INohS-0007BE-EU for emu@ietf.org; Wed, 22 Aug 2007 07:48:38 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3384448C3; Wed, 22 Aug 2007 07:48:37 -0400 (EDT) From: Sam Hartman To: Lakshminath Dondeti References: <46CBBDC3.50300@deployingradius.com> <46CBBF61.8070207@qualcomm.com> Date: Wed, 22 Aug 2007 07:48:37 -0400 In-Reply-To: <46CBBF61.8070207@qualcomm.com> (Lakshminath Dondeti's message of "Tue, 21 Aug 2007 21:45:21 -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.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: emu@ietf.org Subject: [Emu] Chennal binding 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: Lakshminath> I would like to see the crypto-binding stuff (not Lakshminath> compound binding -- as others have noted, we don't Lakshminath> have consensus on that topic) and extensibility (how Lakshminath> to add new attributes) specified. I'd really appreciate it if someone would think hard about the interactions of draft-housley-aaa-key-mgmt and channel binding. I'd like to understand whether we can meet all the requirements of that BCP without channel binding and if not, what we need to do about it. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Aug 22 10:29: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 1INrCj-0006nT-AL; Wed, 22 Aug 2007 10:29:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrCh-0006nN-2C for emu@ietf.org; Wed, 22 Aug 2007 10:29:03 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INrCg-0004oT-HC for emu@ietf.org; Wed, 22 Aug 2007 10:29:03 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Aug 2007 10:29:02 -0400 X-IronPort-AV: i="4.19,294,1183348800"; d="scan'208"; a="129581642:sNHT52038062" 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 l7MET2DJ004020; Wed, 22 Aug 2007 10:29: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 l7MESfnb004468; Wed, 22 Aug 2007 14:29:00 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 10:28:47 -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] Crypto-binding in TTLS-v0 Date: Wed, 22 Aug 2007 10:28:51 -0400 Message-ID: <0F64770A6FD22C43AAA498C1E774ECC7042A4041@xmb-rtp-208.amer.cisco.com> In-Reply-To: <46CC083E.7000908@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: Acfkor5nF4jL4kpASBywSxe6Gb9PcQAJRoGA References: <46CBBDC3.50300@deployingradius.com><46CBBF61.8070207@qualcomm.com><9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> <46CC083E.7000908@deployingradius.com> From: "Gene Chang \(genchang\)" To: "Alan DeKok" , "Hao Zhou \(hzhou\)" X-OriginalArrivalTime: 22 Aug 2007 14:28:47.0744 (UTC) FILETIME=[C07E4000:01C7E4C8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2834; t=1187792942; x=1188656942; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=genchang@cisco.com; z=From:=20=22Gene=20Chang=20\(genchang\)=22=20 |Subject:=20RE=3A=20[Emu]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20 |To:=20=22Alan=20DeKok=22=20, =0A=20=20=20=20=2 0=20=20=20=22Hao=20Zhou=20\(hzhou\)=22=20; bh=EM4iLDR5EYaKw19EfJA7bnkcQXCslGFkaFtLNvBrlvw=; b=T+Ksh+KOkHVRynzGQNxxrh3V/QJzW1lqKZ3q1FsnJI0j4jb2nqbEhaMYtnKbo3RFZhoiV9/P t1YZZEIt4DxjVGKITX4rPCgukcS1e+RVrFbuFzNjPOYPmLq86McwRQHE; Authentication-Results: rtp-dkim-2; header.From=genchang@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Sam Hartman , 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 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Wednesday, August 22, 2007 5:56 AM > To: Hao Zhou (hzhou) > Cc: Sam Hartman; emu@ietf.org > Subject: Re: [Emu] Crypto-binding in TTLS-v0 >=20 > Hao Zhou (hzhou) wrote: > > I think publishing a "widely" deployed EAP method is orthogonal to > > publishing a new method meeting EMU charter. I agree publishing the > > existing method as deployed is something needs to be done quickly. I am > > still doubtful that adding the extra stuff required to meet the charter > > (crypto-binding, crypto-agility, synchronized result indication, > > internationalization), >=20 > I'm not sure why internationalization is an issue. This came up in > RADEXT a while ago. The consensus at the time was that RFC 4282 > discusses internationalization of the NAI, and that passwords don't need > to be internationalized. >=20 > Internationalization matters for *display* to end users. > Internationalization is about *languages*. Passwords aren't displayed, > and they aren't words in any language. They're opaque tokens that users > have memorized, and can repeat on demand to demonstrate secret knowledge. - Passwords aren't just a random number. - Users often need mnemonic aids to accurately reproduce their passwords. This is why often passwords are related to words or phrases. - It is also important that these passwords are normalized between the user system and the backend systems as the strings generated by the user's system may be handled differently from the backend. - There may be more variety for users that use multiple systems or speak multiple languages or for backend systems that support a community that use more than one language. Gene Chang >=20 > > to the existing method can be done without > > breaking backward compatibility. If indeed breaks it, then the argument > > of TTLS is widely deployed doesn't stand anymore. The new method or new > > version of the old method still needs to be implemented and deployed. >=20 > One of the suggestions at IETF 69 was that TTLS was at least safely > backwards compatible with any new feature. i.e. The new features would > require changes to the content of the TLS tunnel, and not much else. > Those changes could be done via AVP's with the "M" bit set. Existing > clients would know enough to fail when they saw an "M" bit set on an AVP > that they didn't understand. >=20 > Do you expect that crypto-binding/agility features would require > changes that are not compatible with existing TTLS deployments? If so, > can you provide examples? >=20 > Alan DeKok. >=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 Wed Aug 22 12:38: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 1INtEF-0004UY-HW; Wed, 22 Aug 2007 12:38:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INtEE-0004US-3b for emu@ietf.org; Wed, 22 Aug 2007 12:38:46 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INtED-0005cl-Kd for emu@ietf.org; Wed, 22 Aug 2007 12:38:46 -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 l7MGcf0I007636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Aug 2007 09:38:42 -0700 Received: from [129.46.78.94] (ldondeti.na.qualcomm.com [129.46.78.94]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7MGcf7h019128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Aug 2007 09:38:41 -0700 Message-ID: <46CC6691.2010409@qualcomm.com> Date: Wed, 22 Aug 2007 09:38:41 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sam Hartman References: <46CBBDC3.50300@deployingradius.com> <46CBBF61.8070207@qualcomm.com> 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: emu@ietf.org Subject: [Emu] Channel binding (Re: Chennal binding) 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, We discussed channel binding before the publication of 4962 (I was reminded recently that draft-housley-aaa-key-mgmt is now a published document :) ) and concluded (I think) that the language in 4962 should just mirror the language of 3748. I think that is what 4962 in fact does: "As described in RFC 3748 in Section 7.15, channel binding is required to enable the peer to verify that the authenticator claim of identity is both consistent and correct." As to what needs to be done for channel binding, I would echo what Bernard said recently "With respect to Channel Bindings, it should be understood that no proposals for this have ever been implemented, as far as I am aware. So a first step would be for a method to choose one of the approaches to Channel Bindings and support it (probably as an experimental extension), and then to evaluate the experiment so we can understand how well (or badly) the chosen approach works. At that point we might be ready to support Channel Bindings in other methods. " best regards, Lakshminath On 8/22/2007 4:48 AM, Sam Hartman wrote: >>>>>> "Lakshminath" == Lakshminath Dondeti writes: > > Lakshminath> I would like to see the crypto-binding stuff (not > Lakshminath> compound binding -- as others have noted, we don't > Lakshminath> have consensus on that topic) and extensibility (how > Lakshminath> to add new attributes) specified. > > > I'd really appreciate it if someone would think hard about the > interactions of draft-housley-aaa-key-mgmt and channel binding. I'd > like to understand whether we can meet all the requirements of that > BCP without channel binding and if not, what we need to do about it. > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 23 04:57:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8VO-0004mv-4D; Thu, 23 Aug 2007 04:57:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8VL-0004mp-Bh for emu@ietf.org; Thu, 23 Aug 2007 04:57:27 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO8VJ-0000Ye-Lb for emu@ietf.org; Thu, 23 Aug 2007 04:57:27 -0400 Received: from [10.0.1.38] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id E6EA9A704E; Thu, 23 Aug 2007 01:57:16 -0700 (PDT) Message-ID: <46CD4BE5.3040004@deployingradius.com> Date: Thu, 23 Aug 2007 10:57:09 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46CBBDC3.50300@deployingradius.com> <46CBBF61.8070207@qualcomm.com> <9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> <46CC083E.7000908@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Sam Hartman wrote: > The consensus of the SASL and Kerberos communities has been different. > In particular, these communities believe that it is strongly desirable > that the same password when entered on two different systems actually > work. Well, yes. But is it a real problem, or a theoretical issue? RADIUS has had over a decade of experience in authenticating pretty much everyone who accesses the Internet. Internationalization issues with usernames or passwords just haven't been encountered. I'm wary of trying to create a solution where the existing deployments show no problems. I know of multiple RADIUS / EAP implementations outside of North America, with 15 million or more users. The largest Kerberos implementation I've heard of was about a million users. I think that RADIUS has pretty well searched the space of potential internationalization issues. > To get that, you need to deal with issues like normalization. > Otherwise, if you use a system with input methods that produce > combined characters you will get different results than if you use > input methods that produce decomposed characters. For EAP methods, the majority of users are using a small number of input systems for almost all authentications. e.g. a laptop. They enter the password once, and it's cached for the next time. Even if they have to enter the password again, they will likely do so on a similar system. So whatever format is used the first time is the same format they user for subsequent authentications. This doesn't solve the problem, but it makes the problem much less likely to appear. > At some level, this is an implementation issue for the server. > However to support the server, you definitely need to label the > character set, discuss any normalization that the client should do > (often none) and set interoperability goals. The whole composed / decomposed thing is a nightmare for passwords. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 23 05:31: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 1IO92O-0001Yf-Se; Thu, 23 Aug 2007 05:31:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO92O-0001YZ-0J for emu@ietf.org; Thu, 23 Aug 2007 05:31:36 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO92N-0001Av-BY for emu@ietf.org; Thu, 23 Aug 2007 05:31:35 -0400 Received: from [10.0.1.38] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 80C32A704E; Thu, 23 Aug 2007 02:31:22 -0700 (PDT) Message-ID: <46CD53E3.3060905@deployingradius.com> Date: Thu, 23 Aug 2007 11:31:15 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Gene Chang (genchang)" Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46CBBDC3.50300@deployingradius.com><46CBBF61.8070207@qualcomm.com><9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> <46CC083E.7000908@deployingradius.com> <0F64770A6FD22C43AAA498C1E774ECC7042A4041@xmb-rtp-208.amer.cisco.com> In-Reply-To: <0F64770A6FD22C43AAA498C1E774ECC7042A4041@xmb-rtp-208.amer.cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Sam Hartman , 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 Gene Chang (genchang) wrote: > - Passwords aren't just a random number. > - Users often need mnemonic aids to accurately reproduce their > passwords. This is why often passwords are related to words or phrases. The key is "related". But they're not words, and we should not treat them as such. The only important requirement is *consistency*. All systems that are used to enter passwords must convert the users intention to the same sequence of bytes. Once that's done, the rest of the network can treat the password as an opaque token. Doing it this way simplifies the i18n issues enormously for the authentication systems. > - It is also important that these passwords are normalized between the > user system and the backend systems as the strings generated by the > user's system may be handled differently from the backend. Are you really saying that the backend has to *interpret* the password that the user has entered? i.e. Turn o" into =C3=B6? What happens when the back-end has stored the password in hashed format? Does *it* normalize the password sent to it by the client before doing the hash? Does it try hashing & comparing both the normalized and non-normalized passwords? If the authentication server can normalize the password, why isn't that done on the client, which presumably has *more* information about the users language preferences? Doing that would also permit better scaling, as more per-user work is done at the edge, where it belongs. > - There may be more variety for users that use multiple systems or spea= k > multiple languages or for backend systems that support a community that > use more than one language. I understand what you're trying to get at, but has this been a real problem in currently deployed networks? I see these issues as requirements on end user devices, UI, and data entry schemes. I don't see that these issues should affect the underlying authentication protocol. The client device should do any normalization or mangling, and send an opaque sequence of bytes to the authentication server. The authentication server shouldn't interpret those bytes, it should just compare them to previously stored credentials= . Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 23 10:33: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 1IODkt-000267-Bd; Thu, 23 Aug 2007 10:33:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IODks-000262-0s for emu@ietf.org; Thu, 23 Aug 2007 10:33:50 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IODkr-0008Bk-C9 for emu@ietf.org; Thu, 23 Aug 2007 10:33:49 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 23 Aug 2007 07:33:49 -0700 X-IronPort-AV: i="4.19,300,1183359600"; d="scan'208"; a="516440042:sNHT53605630" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7NEXmhe021500; Thu, 23 Aug 2007 07:33:48 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l7NEXYiW004910; Thu, 23 Aug 2007 14:33:48 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 10:32:49 -0400 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: RE: [Emu] Crypto-binding in TTLS-v0 Date: Thu, 23 Aug 2007 10:32:53 -0400 Message-ID: <0F64770A6FD22C43AAA498C1E774ECC7043188C2@xmb-rtp-208.amer.cisco.com> In-Reply-To: <46CD53E3.3060905@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Crypto-binding in TTLS-v0 Thread-Index: AcflaGidB1qrjw4RT6KBrjbMJ6hROQAKORaw References: <46CBBDC3.50300@deployingradius.com><46CBBF61.8070207@qualcomm.com><9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> <46CC083E.7000908@deployingradius.com> <0F64770A6FD22C43AAA498C1E774ECC7042A4041@xmb-rtp-208.amer.cisco.com> <46CD53E3.3060905@deployingradius.com> From: "Gene Chang \(genchang\)" To: "Alan DeKok" X-OriginalArrivalTime: 23 Aug 2007 14:32:49.0165 (UTC) FILETIME=[7ACDEBD0:01C7E592] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3596; t=1187879628; x=1188743628; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=genchang@cisco.com; z=From:=20=22Gene=20Chang=20\(genchang\)=22=20 |Subject:=20RE=3A=20[Emu]=20Crypto-binding=20in=20TTLS-v0 |Sender:=20; bh=SN8+lgz1dVrBpdqKWEn2dMJ/vUm8cMP5keND9lDw+98=; b=NdEPwWhdJwVGM7qRZ33PiABHTpryQzpBFMCBIpHf6yJzptPDJwvgmzmxOJa9EFiiCHBgyyMa nVwPGWzDbo3i2hWoSwOf8BXGMmW+MWxzW6fu6BcMwkZiS1rdnpJQs8kV; Authentication-Results: sj-dkim-2; header.From=genchang@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Sam Hartman , 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 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Thursday, August 23, 2007 5:31 AM > To: Gene Chang (genchang) > Cc: Hao Zhou (hzhou); Sam Hartman; emu@ietf.org > Subject: Re: [Emu] Crypto-binding in TTLS-v0 >=20 > Gene Chang (genchang) wrote: > > - Passwords aren't just a random number. > > - Users often need mnemonic aids to accurately reproduce their > > passwords. This is why often passwords are related to words or = phrases. >=20 > The key is "related". But they're not words, and we should not = treat > them as such. [EC: ] Yes... >=20 > The only important requirement is *consistency*. All systems that = are > used to enter passwords must convert the users intention to the same > sequence of bytes. Once that's done, the rest of the network can = treat > the password as an opaque token. Doing it this way simplifies the = i18n > issues enormously for the authentication systems. >=20 > > - It is also important that these passwords are normalized between = the > > user system and the backend systems as the strings generated by the > > user's system may be handled differently from the backend. >=20 > Are you really saying that the backend has to *interpret* the = password > that the user has entered? i.e. Turn o" into =F6? >=20 > What happens when the back-end has stored the password in hashed > format? Does *it* normalize the password sent to it by the client > before doing the hash? Does it try hashing & comparing both the > normalized and non-normalized passwords? >=20 > If the authentication server can normalize the password, why isn't > that done on the client, which presumably has *more* information about > the users language preferences? Doing that would also permit better > scaling, as more per-user work is done at the edge, where it belongs. >=20 [EC: ] [EC: ] No... I implied that we cannot assume the backend UI and = the client system UI will convert human input into normalized passwords = the same way unless we explicitly specify the conversion. Otherwise we = are in agreement about the typical machinery. > > - There may be more variety for users that use multiple systems or = speak > > multiple languages or for backend systems that support a community = that > > use more than one language. >=20 > I understand what you're trying to get at, but has this been a real > problem in currently deployed networks? >=20 [EC: ] Whether it is a problem or not depends on your perspective and on = our attitude of being user friendly. I have seen this issue in the past. = Back then, the AAA system could not handle multiple inputs from multiple = character sets. The solution then was to require all users of a system = to "speak" the same language. In large international deployment, this = usually means that all users us our "English" character set. The time is = past for us to expect single language systems. > I see these issues as requirements on end user devices, UI, and data > entry schemes. I don't see that these issues should affect the > underlying authentication protocol. The client device should do any > normalization or mangling, and send an opaque sequence of bytes to the > authentication server. The authentication server shouldn't interpret > those bytes, it should just compare them to previously stored = credentials. >=20 [EC: ] It depends on where we want to put the normalization and where we = want to handle differences between different operating systems. > Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Aug 24 06:14:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOWBF-0001yS-8N; Fri, 24 Aug 2007 06:14:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOWBD-0001uy-Su for emu@ietf.org; Fri, 24 Aug 2007 06:14:15 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOWBD-0006ZE-3Y for emu@ietf.org; Fri, 24 Aug 2007 06:14:15 -0400 Received: from [10.0.1.38] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id D443AA704E; Fri, 24 Aug 2007 03:14:03 -0700 (PDT) Message-ID: <46CEAF62.20102@deployingradius.com> Date: Fri, 24 Aug 2007 12:13:54 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Gene Chang (genchang)" Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46CBBDC3.50300@deployingradius.com><46CBBF61.8070207@qualcomm.com><9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> <46CC083E.7000908@deployingradius.com> <0F64770A6FD22C43AAA498C1E774ECC7042A4041@xmb-rtp-208.amer.cisco.com> <46CD53E3.3060905@deployingradius.com> <0F64770A6FD22C43AAA498C1E774ECC7043188C2@xmb-rtp-208.amer.cisco.com> In-Reply-To: <0F64770A6FD22C43AAA498C1E774ECC7043188C2@xmb-rtp-208.amer.cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Sam Hartman , 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 Gene Chang (genchang) wrote: > [EC: ] [EC: ] No... I implied that we cannot assume the backend UI and > the client system UI will convert human input into normalized > passwords the same way unless we explicitly specify the conversion. Yes. > [EC: ] Whether it is a problem or not depends on your perspective > and on our attitude of being user friendly. I have seen this issue > in the past. Back then, the AAA system could not handle multiple > inputs from multiple character sets. The solution then was to > require all users of a system to "speak" the same language. > In large international deployment, this usually means that all users > us our "English" character set. The time is past for us to expect > single language systems. I agree. The tests I've done on multiple AAA systems indicate that the majority now support UTF-8. This solves many 18n issues, other than composed / decomposed characters. > [EC: ] It depends on where we want to put the normalization and where > we want to handle differences between different operating systems. My opinion is that normalization belongs at the edge, which generally also has information about the language and locale. Once normalization is performed, the password can be sent over the wire *without* language or locale information to the server. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 27 10:59:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPg49-0002v1-Hk; Mon, 27 Aug 2007 10:59:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPg48-0002uE-HB for emu@ietf.org; Mon, 27 Aug 2007 10:59:44 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPg48-0006rg-6D for emu@ietf.org; Mon, 27 Aug 2007 10:59:44 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 63F974A3F; Mon, 27 Aug 2007 10:59:42 -0400 (EDT) From: Sam Hartman To: Alan DeKok Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46CBBDC3.50300@deployingradius.com> <46CBBF61.8070207@qualcomm.com> <9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> <46CC083E.7000908@deployingradius.com> <0F64770A6FD22C43AAA498C1E774ECC7042A4041@xmb-rtp-208.amer.cisco.com> <46CD53E3.3060905@deployingradius.com> <0F64770A6FD22C43AAA498C1E774ECC7043188C2@xmb-rtp-208.amer.cisco.com> <46CEAF62.20102@deployingradius.com> Date: Mon, 27 Aug 2007 10:59:42 -0400 In-Reply-To: <46CEAF62.20102@deployingradius.com> (Alan DeKok's message of "Fri, 24 Aug 2007 12:13:54 +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: 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 >>>>> "Alan" == Alan DeKok writes: Alan> My opinion is that normalization belongs at the edge, Alan> which generally also has information about the language and Alan> locale. Once normalization is performed, the password can Alan> be sent over the wire *without* language or locale Alan> information to the server. This isn't a bad idea. Think though about how it interacts with password databases used for multiple purposes. You sometimes get into situations where you need to do normalization both at the client and server. That too can be OK. You just need to think it all through when writing your specs. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 27 11:03: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 1IPg7a-0006eb-1C; Mon, 27 Aug 2007 11:03:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPg7Y-0006cI-IT for emu@ietf.org; Mon, 27 Aug 2007 11:03:16 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPg7X-0003J7-BX for emu@ietf.org; Mon, 27 Aug 2007 11:03:16 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B31564A3F; Mon, 27 Aug 2007 11:03:13 -0400 (EDT) From: Sam Hartman To: Alan DeKok Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46CBBDC3.50300@deployingradius.com> <46CBBF61.8070207@qualcomm.com> <9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> <46CC083E.7000908@deployingradius.com> <46CD4BE5.3040004@deployingradius.com> Date: Mon, 27 Aug 2007 11:03:13 -0400 In-Reply-To: <46CD4BE5.3040004@deployingradius.com> (Alan DeKok's message of "Thu, 23 Aug 2007 10:57:09 +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: cf4fa59384e76e63313391b70cd0dd25 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 >>>>> "Alan" == Alan DeKok writes: >> At some level, this is an implementation issue for the server. >> However to support the server, you definitely need to label the >> character set, discuss any normalization that the client should >> do (often none) and set interoperability goals. Alan> The whole composed / decomposed thing is a nightmare for Alan> passwords. And one the emu working group needs to deal with. Sam hartman Security Area Director _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 28 04:53: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 1IPwpX-0007gj-Ol; Tue, 28 Aug 2007 04:53:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPwpV-0007gZ-TC for emu@ietf.org; Tue, 28 Aug 2007 04:53:45 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPwpU-0004e4-AX for emu@ietf.org; Tue, 28 Aug 2007 04:53:45 -0400 Received: from [10.0.1.38] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 7345CA704E; Tue, 28 Aug 2007 01:53:35 -0700 (PDT) Message-ID: <46D3E280.6020506@deployingradius.com> Date: Tue, 28 Aug 2007 10:53:20 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46CBBDC3.50300@deployingradius.com> <46CBBF61.8070207@qualcomm.com> <9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> <46CC083E.7000908@deployingradius.com> <46CD4BE5.3040004@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Sam Hartman wrote: > Alan> The whole composed / decomposed thing is a nightmare for > Alan> passwords. > > And one the emu working group needs to deal with. RFC 3629 says that overlong sequences are invalid: Implementations of the decoding algorithm above MUST protect against decoding invalid sequences. For instance, a naive implementation may decode the overlong UTF-8 sequence C0 80 ... I would therefore follow the lead of the UTF-8 experts, and suggest that decomposed characters are "overlong", and thus invalid for the purposes of EMU. Therefore, UTF-8 sequences must consist solely of composed characters. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 28 04:55: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 1IPwrJ-0008Ax-Px; Tue, 28 Aug 2007 04:55:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPwrJ-0008Aq-1r for emu@ietf.org; Tue, 28 Aug 2007 04:55:37 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPwrH-0004fX-Ez for emu@ietf.org; Tue, 28 Aug 2007 04:55:37 -0400 Received: from [10.0.1.38] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id A1441A704E; Tue, 28 Aug 2007 01:55:26 -0700 (PDT) Message-ID: <46D3E2EF.8080606@deployingradius.com> Date: Tue, 28 Aug 2007 10:55:11 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46CBBDC3.50300@deployingradius.com> <46CBBF61.8070207@qualcomm.com> <9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> <46CC083E.7000908@deployingradius.com> <0F64770A6FD22C43AAA498C1E774ECC7042A4041@xmb-rtp-208.amer.cisco.com> <46CD53E3.3060905@deployingradius.com> <0F64770A6FD22C43AAA498C1E774ECC7043188C2@xmb-rtp-208.amer.cisco.com> <46CEAF62.20102@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Sam Hartman wrote: > This isn't a bad idea. Think though about how it interacts with > password databases used for multiple purposes. You sometimes get into > situations where you need to do normalization both at the client and > server. That too can be OK. You just need to think it all through > when writing your specs. When people enter passwords, the pop-up window often says "CASE SENSITIVE", and "Make sure you don't have CAPS-LOCK pressed". Servers don't currently normalize passwords to do case-insensitive comparisons. I don't see why they would need to normalize passwords for composed/decomposed characters. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 28 10:59: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 1IQ2XI-0004g5-S7; Tue, 28 Aug 2007 10:59:20 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IQ2XH-0004fx-Qd for emu-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 10:59:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ2XH-0004fp-GU for emu@ietf.org; Tue, 28 Aug 2007 10:59:19 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ2XH-0002su-3d for emu@ietf.org; Tue, 28 Aug 2007 10:59:19 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1CF974A40; Tue, 28 Aug 2007 10:59:17 -0400 (EDT) From: Sam Hartman To: Alan DeKok Subject: Re: [Emu] Crypto-binding in TTLS-v0 References: <46CBBDC3.50300@deployingradius.com> <46CBBF61.8070207@qualcomm.com> <9958B444368E884DBB215F3FEF36F5B705131953@xmb-rtp-212.amer.cisco.com> <46CC083E.7000908@deployingradius.com> <46CD4BE5.3040004@deployingradius.com> <46D3E280.6020506@deployingradius.com> Date: Tue, 28 Aug 2007 10:59:17 -0400 In-Reply-To: <46D3E280.6020506@deployingradius.com> (Alan DeKok's message of "Tue, 28 Aug 2007 10:53:20 +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: 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 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: The whole composed / decomposed thing is Alan> a nightmare for passwords. >> And one the emu working group needs to deal with. Alan> RFC 3629 says that overlong sequences are invalid: Alan> Implementations of the decoding algorithm above MUST Alan> protect against decoding invalid sequences. For instance, a Alan> naive implementation may decode the overlong UTF-8 sequence Alan> C0 80 ... Alan> I would therefore follow the lead of the UTF-8 experts, Alan> and suggest that decomposed characters are "overlong", and Alan> thus invalid for the purposes of EMU. Therefore, UTF-8 Alan> sequences must consist solely of composed characters. This will be my last message on the subject. There are approaches to consider in this space, but it's not that simple. If only it were that simple. One of the simplest problems with this approach is that not all the combined characters that you need actually exist. Another potential issue is that I think normalizing towards decomposed may be easier than normalizing towards combined. --Sam _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu