From emu-bounces@ietf.org Tue Apr 1 15:27:24 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7F783A6E46; Tue, 1 Apr 2008 15:27:24 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7573A6E4D for ; Tue, 1 Apr 2008 15:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggMm4CQy5Kzt for ; Tue, 1 Apr 2008 15:27:23 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 06E363A6890 for ; Tue, 1 Apr 2008 15:25:54 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B32FBA888810 for ; Tue, 1 Apr 2008 15:25:52 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Apr 2008 15:25:52 -0700 (PDT) Message-ID: <4cbf045715e41c38b4f2f1e04a19d763.squirrel@www.trepanning.net> Date: Tue, 1 Apr 2008 15:25:52 -0700 (PDT) From: "Dan Harkins" To: emu@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Subject: [Emu] comment on draft-ietf-emu-eap-gpsk X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Hello, Section 11.6 of draft-ietf-emu-eap-gpsk says: EAP-GPSK relies on a long-term shared secret (PSK) that MUST be based on at least 16 octets of entropy to guarantee security against dictionary attacks. This is not a generally accepted view of resistance to dictionary attack. For instance, the excellent paper by Bellare, Pointcheval, and Rogaway, Authenticated Key Exchange Secure Against Dictionary Attacks says: One sees whether or not one has security against dictionary attacks by looking to see if maximal adversarial advantage grows primarily with the ratio of interaction to the size of the password space. Open Key Exchange-- How to Defeat Dictionary Attacks Without Encrypting Public Keys, by Stefan Lucks, says that the probability of success of the attacker is based on the size of the dictionary and the number of number of times the attacker has been rejected (after active attack), and "does not significantly exceed 1/(S-R)" where S is the size of the dictionary and R is the number or rejections. Even RFC3748 says that for an EAP method to be resistant to dictionary attacks that: ...the method does not allow an offline attack that has a work factor based on the number of passwords in an attacker's dictionary. The idea here is that merely making the size of the pool from which the secret is drawn (i.e. "the dictionary") large does not make a protocol resistant to dictionary attack. What makes it resistant to dictionary attacks is whether an attacker gets one guess at the password per active attack-- interaction-- and not an unlimited number after a single attack-- computation. This draft implies that since the secret has "16 octets of entropy"-- 2^128 bits, which is quite a requirement!-- that it is resistant to a dictionary attack. This is not correct. I really think this draft should be corrected to not imply it has resistance to dictionary attack. I suggest something along the lines of: The success of a dictionary attack against EAP-GPSK depends on the strength of the long-term shared secret (PSK) it uses. The PSK used by EAP-GPSK MUST be drawn from a pool of secrets that is at least 2^128 bits large and whose distribution is uniformly random. Note that this does not imply resistance to dictionary attack, only that the probability of success in such an attack is acceptably remote. regards, Dan. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 1 21:38:37 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBDBC3A6DC1; Tue, 1 Apr 2008 21:38:37 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D722A3A6DAC for ; Tue, 1 Apr 2008 21:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GurIwkUUMI4 for ; Tue, 1 Apr 2008 21:38:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E21383A6CF0 for ; Tue, 1 Apr 2008 21:38:35 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2008 21:38:35 -0700 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 m324cZX0022606; Tue, 1 Apr 2008 21:38:35 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m324cZps023203; Wed, 2 Apr 2008 04:38:35 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 21:38:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 21:39:25 -0700 Message-ID: In-Reply-To: <4cbf045715e41c38b4f2f1e04a19d763.squirrel@www.trepanning.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] comment on draft-ietf-emu-eap-gpsk Thread-Index: AciUR5IDqUX4rjvFRSKAOGlSfX0yDQAM7nNA From: "Joseph Salowey (jsalowey)" To: "Dan Harkins" , X-OriginalArrivalTime: 02 Apr 2008 04:38:35.0737 (UTC) FILETIME=[69D2CC90:01C8947B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3286; t=1207111115; x=1207975115; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20comment=20on=20draft-ietf-emu-e ap-gpsk |Sender:=20; bh=B3dpDNQToxDNAg2FuTTZGa3d9gYIqfsUWgZQ62PwOZY=; b=RliMCSNZ1jrjtoJlNcFFTvonOrSRGKkJ+nLMYzOtDPQUbb4WcbrhCDIgJQ 1nV0m8ixw9OydOgUSlI3Nmf5Y8UUswFQEcHFg+nEqIUfIgGXJaSR1jQzz3eN 9QSTXVaMIg; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Emu] comment on draft-ietf-emu-eap-gpsk X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Thanks Dan, I agree with your assessment. I think we should include text similar to what you propose in the document. Joe > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > Behalf Of Dan Harkins > Sent: Tuesday, April 01, 2008 3:26 PM > To: emu@ietf.org > Subject: [Emu] comment on draft-ietf-emu-eap-gpsk > > > Hello, > > Section 11.6 of draft-ietf-emu-eap-gpsk says: > > EAP-GPSK relies on a long-term shared secret (PSK) that MUST be > based on at least 16 octets of entropy to guarantee security > against dictionary attacks. > > This is not a generally accepted view of resistance to > dictionary attack. For instance, the excellent paper by > Bellare, Pointcheval, and Rogaway, Authenticated Key Exchange > Secure Against Dictionary Attacks says: > > One sees whether or not one has security against dictionary > attacks by looking to see if maximal adversarial advantage grows > primarily with the ratio of interaction to the size of the > password space. > > Open Key Exchange-- How to Defeat Dictionary Attacks > Without Encrypting Public Keys, by Stefan Lucks, says that > the probability of success of the attacker is based on the > size of the dictionary and the number of number of times the > attacker has been rejected (after active attack), and "does > not significantly exceed 1/(S-R)" where S is the size of the > dictionary and R is the number or rejections. > > Even RFC3748 says that for an EAP method to be resistant to > dictionary attacks that: > > ...the method does not allow an offline attack that has a work > factor based on the number of passwords in an > attacker's dictionary. > > The idea here is that merely making the size of the pool > from which the secret is drawn (i.e. "the dictionary") large > does not make a protocol resistant to dictionary attack. What > makes it resistant to dictionary attacks is whether an > attacker gets one guess at the password per active > attack-- interaction-- and not an unlimited number after a > single attack-- computation. > > This draft implies that since the secret has "16 octets of > entropy"-- > 2^128 bits, which is quite a requirement!-- that it is > resistant to a dictionary attack. This is not correct. > > I really think this draft should be corrected to not imply > it has resistance to dictionary attack. I suggest something > along the lines of: > > The success of a dictionary attack against EAP-GPSK depends on > the strength of the long-term shared secret (PSK) it uses. The > PSK used by EAP-GPSK MUST be drawn from a pool of secrets that > is at least 2^128 bits large and whose distribution is uniformly > random. Note that this does not imply resistance to dictionary > attack, only that the probability of success in such an attack > is acceptably remote. > > regards, > > Dan. > > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 2 02:08:56 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5005128C457; Wed, 2 Apr 2008 02:08:56 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5026228C451 for ; Wed, 2 Apr 2008 02:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNJ+Rdq1I7Xn for ; Wed, 2 Apr 2008 02:08:54 -0700 (PDT) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by core3.amsl.com (Postfix) with SMTP id 56CEE28C463 for ; Wed, 2 Apr 2008 02:08:54 -0700 (PDT) Received: from aruba-mx1.arubanetworks.com ([10.1.1.17]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 02:08:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 02:08:53 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] comment on draft-ietf-emu-eap-gpsk Thread-Index: AciUR5IDqUX4rjvFRSKAOGlSfX0yDQAM7nNAAAjzQpA= References: <4cbf045715e41c38b4f2f1e04a19d763.squirrel@www.trepanning.net> From: "Glen Zorn" To: "Dan Harkins" X-OriginalArrivalTime: 02 Apr 2008 09:08:55.0044 (UTC) FILETIME=[2D48A440:01C894A1] Cc: emu@ietf.org Subject: Re: [Emu] comment on draft-ietf-emu-eap-gpsk X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Joseph Salowey (jsalowey) <> scribbled on : > Thanks Dan, I agree with your assessment. I think we should > include text similar to what you propose in the document. > > Joe > >> -----Original Message----- >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf >> Of Dan Harkins Sent: Tuesday, April 01, 2008 3:26 PM >> To: emu@ietf.org >> Subject: [Emu] comment on draft-ietf-emu-eap-gpsk >> >> >> Hello, >> >> Section 11.6 of draft-ietf-emu-eap-gpsk says: >> >> EAP-GPSK relies on a long-term shared secret (PSK) that MUST be >> based on at least 16 octets of entropy to guarantee security >> against dictionary attacks. >> >> This is not a generally accepted view of resistance to dictionary >> attack. For instance, the excellent paper by Bellare, Pointcheval, >> and Rogaway, Authenticated Key Exchange Secure Against Dictionary >> Attacks says: >> >> One sees whether or not one has security against dictionary >> attacks by looking to see if maximal adversarial advantage >> grows primarily with the ratio of interaction to the size of >> the password space. In other word, if the choice of dictionary elements significantly increases the likelihood of success over that of randomly chosen strings from the search space. >> >> Open Key Exchange-- How to Defeat Dictionary Attacks Without >> Encrypting Public Keys, by Stefan Lucks, says that the probability of >> success of the attacker is based on the size of the dictionary and >> the number of number of times the attacker has been rejected (after >> active attack), and "does not significantly exceed 1/(S-R)" where S >> is the size of the dictionary and R is the number or rejections. This says essentially the same thing, since 1/(S-R) is just the probability of success of a brute force attack. >> >> Even RFC3748 says that for an EAP method to be resistant to >> dictionary attacks that: >> >> ...the method does not allow an offline attack that has a work >> factor based on the number of passwords in an attacker's >> dictionary. >> >> The idea here is that merely making the size of the pool from which >> the secret is drawn (i.e. "the dictionary") large does not make a >> protocol resistant to dictionary attack. What makes it resistant to >> dictionary attacks is whether an attacker gets one guess at the >> password per active attack-- interaction-- and not an unlimited >> number after a single attack-- computation. No. What makes a protocol resistant to dictionary attack is that the use of a dictionary (i.e., a subset of the search space chosen to increase the probability of success) doesn't work any better than a brute force attack without a dictionary. That's why they are called "dictionary attacks" & not "one guess attacks" or some such thing. >> >> This draft implies that since the secret has "16 octets of >> entropy"-- 2^128 bits, which is quite a requirement!-- that it is >> resistant to a dictionary attack. This is not correct. >> >> I really think this draft should be corrected to not imply it has >> resistance to dictionary attack. I suggest something along the lines >> of: >> >> The success of a dictionary attack against EAP-GPSK depends on >> the strength of the long-term shared secret (PSK) it uses. The >> PSK used by EAP-GPSK MUST be drawn from a pool of secrets that >> is at least 2^128 bits large and whose distribution is >> uniformly random. Note that this does not imply resistance to >> dictionary attack, only that the probability of success in >> such an attack is acceptably remote. >> >> regards, >> >> Dan. >> >> >> >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >> > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 2 09:32:17 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B57A3A6F3A; Wed, 2 Apr 2008 09:32:17 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575873A680D for ; Wed, 2 Apr 2008 09:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRf5HNIM5ej9 for ; Wed, 2 Apr 2008 09:32:14 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6F2213A6949 for ; Wed, 2 Apr 2008 09:30:04 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2008 09:30:05 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m32GU51O005071; Wed, 2 Apr 2008 09:30:05 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m32GU4vT028923; Wed, 2 Apr 2008 16:30:05 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); Wed, 2 Apr 2008 09:30:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 09:30:52 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] comment on draft-ietf-emu-eap-gpsk Thread-Index: AciUR5IDqUX4rjvFRSKAOGlSfX0yDQAM7nNAAAjzQpAAD9MLIA== From: "Joseph Salowey (jsalowey)" To: "Glen Zorn" , "Dan Harkins" X-OriginalArrivalTime: 02 Apr 2008 16:30:03.0260 (UTC) FILETIME=[CD91E3C0:01C894DE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4962; t=1207153805; x=1208017805; 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]=20comment=20on=20draft-ietf-emu-e ap-gpsk |Sender:=20; bh=Is7ABhry46wBzXSI39giUfBjqM0RMhRrkXIxOlpcO44=; b=Gufn22GXE4flnxgcngE2I3ZdTS59q3bMtzKj1khNlx1u1pY8bUUfWw1gCS yBk7LNV1dE/vsEYQG8sRPlqPTWdiPJs9303h8ldTDRGRsCCCbo46loHT+naT QYO1Skfi4P; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: emu@ietf.org Subject: Re: [Emu] comment on draft-ietf-emu-eap-gpsk X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org OK, but do you agree that EAP-GPSK should not be claiming resistance to dictionary attack if its security depends upon the selection of secret from a pool that is large enough? Joe > -----Original Message----- > From: Glen Zorn [mailto:gzorn@arubanetworks.com] > Sent: Wednesday, April 02, 2008 2:09 AM > To: Dan Harkins > Cc: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] comment on draft-ietf-emu-eap-gpsk > > Joseph Salowey (jsalowey) <> scribbled on : > > > Thanks Dan, I agree with your assessment. I think we > should include > > text similar to what you propose in the document. > > > > Joe > > > >> -----Original Message----- > >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] > On Behalf Of > >> Dan Harkins Sent: Tuesday, April 01, 2008 3:26 PM > >> To: emu@ietf.org > >> Subject: [Emu] comment on draft-ietf-emu-eap-gpsk > >> > >> > >> Hello, > >> > >> Section 11.6 of draft-ietf-emu-eap-gpsk says: > >> > >> EAP-GPSK relies on a long-term shared secret (PSK) > that MUST be > >> based on at least 16 octets of entropy to guarantee security > >> against dictionary attacks. > >> > >> This is not a generally accepted view of resistance to dictionary > >> attack. For instance, the excellent paper by Bellare, Pointcheval, > >> and Rogaway, Authenticated Key Exchange Secure Against Dictionary > >> Attacks says: > >> > >> One sees whether or not one has security against dictionary > >> attacks by looking to see if maximal adversarial advantage > >> grows primarily with the ratio of interaction to the size of > >> the password space. > > In other word, if the choice of dictionary elements > significantly increases the likelihood of success over that > of randomly chosen strings from the search space. > > >> > >> Open Key Exchange-- How to Defeat Dictionary Attacks Without > >> Encrypting Public Keys, by Stefan Lucks, says that the > probability of > >> success of the attacker is based on the size of the dictionary and > >> the number of number of times the attacker has been > rejected (after > >> active attack), and "does not significantly exceed > 1/(S-R)" where S > >> is the size of the dictionary and R is the number or rejections. > > This says essentially the same thing, since 1/(S-R) is just > the probability of success of a brute force attack. > > >> > >> Even RFC3748 says that for an EAP method to be resistant to > >> dictionary attacks that: > >> > >> ...the method does not allow an offline attack that > has a work > >> factor based on the number of passwords in an attacker's > >> dictionary. > >> > >> The idea here is that merely making the size of the pool > from which > >> the secret is drawn (i.e. "the dictionary") large does not make a > >> protocol resistant to dictionary attack. What makes it > resistant to > >> dictionary attacks is whether an attacker gets one guess at the > >> password per active attack-- interaction-- and not an unlimited > >> number after a single attack-- computation. > > No. What makes a protocol resistant to dictionary attack is > that the use of a dictionary (i.e., a subset of the search > space chosen to increase the probability of success) doesn't > work any better than a brute force attack without a > dictionary. That's why they are called "dictionary attacks" > & not "one guess attacks" or some such thing. > > >> > >> This draft implies that since the secret has "16 octets of > >> entropy"-- 2^128 bits, which is quite a requirement!-- that it is > >> resistant to a dictionary attack. This is not correct. > >> > >> I really think this draft should be corrected to not > imply it has > >> resistance to dictionary attack. I suggest something along > the lines > >> of: > >> > >> The success of a dictionary attack against EAP-GPSK > depends on > >> the strength of the long-term shared secret (PSK) it > uses. The > >> PSK used by EAP-GPSK MUST be drawn from a pool of > secrets that > >> is at least 2^128 bits large and whose distribution is > >> uniformly random. Note that this does not imply resistance to > >> dictionary attack, only that the probability of success in > >> such an attack is acceptably remote. > >> > >> regards, > >> > >> Dan. > >> > >> > >> > >> > >> _______________________________________________ > >> Emu mailing list > >> Emu@ietf.org > >> https://www.ietf.org/mailman/listinfo/emu > >> > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Apr 3 18:32:00 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED34C28C72A; Thu, 3 Apr 2008 18:32:00 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DEE528C6EE for ; Thu, 3 Apr 2008 18:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q40MlLTif9jf for ; Thu, 3 Apr 2008 18:31:59 -0700 (PDT) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by core3.amsl.com (Postfix) with SMTP id 5F36528C6A0 for ; Thu, 3 Apr 2008 18:31:59 -0700 (PDT) Received: from aruba-mx1.arubanetworks.com ([10.1.1.17]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 18:32:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 18:31:57 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] comment on draft-ietf-emu-eap-gpsk Thread-Index: AciUR5IDqUX4rjvFRSKAOGlSfX0yDQAM7nNAAAjzQpAAD9MLIABFSLLQ References: From: "Glen Zorn" To: "Joseph Salowey \(jsalowey\)" , "Dan Harkins" X-OriginalArrivalTime: 04 Apr 2008 01:32:04.0275 (UTC) FILETIME=[B004B830:01C895F3] Cc: emu@ietf.org Subject: Re: [Emu] comment on draft-ietf-emu-eap-gpsk X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Joseph Salowey (jsalowey) scribbled on Wednesday, April 02, 2008 9:31 AM: > OK, but do you agree that EAP-GPSK should not be claiming > resistance to dictionary attack if its security depends upon > the selection of secret from a pool that is large enough? Yes. > > Joe > >> -----Original Message----- >> From: Glen Zorn [mailto:gzorn@arubanetworks.com] >> Sent: Wednesday, April 02, 2008 2:09 AM >> To: Dan Harkins >> Cc: Joseph Salowey (jsalowey); emu@ietf.org >> Subject: RE: [Emu] comment on draft-ietf-emu-eap-gpsk >> >> Joseph Salowey (jsalowey) <> scribbled on : >> >>> Thanks Dan, I agree with your assessment. I think we should >>> include text similar to what you propose in the document. >>> >>> Joe >>> >>>> -----Original Message----- >>>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf >>>> Of Dan Harkins Sent: Tuesday, April 01, 2008 3:26 PM >>>> To: emu@ietf.org >>>> Subject: [Emu] comment on draft-ietf-emu-eap-gpsk >>>> >>>> >>>> Hello, >>>> >>>> Section 11.6 of draft-ietf-emu-eap-gpsk says: >>>> >>>> EAP-GPSK relies on a long-term shared secret (PSK) that MUST >>>> be based on at least 16 octets of entropy to guarantee >>>> security against dictionary attacks. >>>> >>>> This is not a generally accepted view of resistance to dictionary >>>> attack. For instance, the excellent paper by Bellare, Pointcheval, >>>> and Rogaway, Authenticated Key Exchange Secure Against Dictionary >>>> Attacks says: >>>> >>>> One sees whether or not one has security against dictionary >>>> attacks by looking to see if maximal adversarial advantage >>>> grows primarily with the ratio of interaction to the size of >>>> the password space. >> >> In other word, if the choice of dictionary elements significantly >> increases the likelihood of success over that of randomly chosen >> strings from the search space. >> >>>> >>>> Open Key Exchange-- How to Defeat Dictionary Attacks Without >>>> Encrypting Public Keys, by Stefan Lucks, says that the probability >>>> of success of the attacker is based on the size of the dictionary >>>> and the number of number of times the attacker has been rejected >>>> (after active attack), and "does not significantly exceed 1/(S-R)" >>>> where S is the size of the dictionary and R is the number or >>>> rejections. >> >> This says essentially the same thing, since 1/(S-R) is just the >> probability of success of a brute force attack. >> >>>> >>>> Even RFC3748 says that for an EAP method to be resistant to >>>> dictionary attacks that: >>>> >>>> ...the method does not allow an offline attack that has a >>>> work factor based on the number of passwords in an >>>> attacker's dictionary. >>>> >>>> The idea here is that merely making the size of the pool from >>>> which the secret is drawn (i.e. "the dictionary") large does not >>>> make a protocol resistant to dictionary attack. What makes it >>>> resistant to dictionary attacks is whether an attacker gets one >>>> guess at the password per active attack-- interaction-- and not an >>>> unlimited number after a single attack-- computation. >> >> No. What makes a protocol resistant to dictionary attack is that the >> use of a dictionary (i.e., a subset of the search space chosen to >> increase the probability of success) doesn't work any better than a >> brute force attack without a dictionary. That's why they are called >> "dictionary attacks" & not "one guess attacks" or some such thing. >> >>>> >>>> This draft implies that since the secret has "16 octets of >>>> entropy"-- 2^128 bits, which is quite a requirement!-- that it is >>>> resistant to a dictionary attack. This is not correct. >>>> >>>> I really think this draft should be corrected to not imply it has >>>> resistance to dictionary attack. I suggest something along the >>>> lines of: >>>> >>>> The success of a dictionary attack against EAP-GPSK depends >>>> on the strength of the long-term shared secret (PSK) it >>>> uses. The PSK used by EAP-GPSK MUST be drawn from a pool of >>>> secrets that is at least 2^128 bits large and whose >>>> distribution is uniformly random. Note that this does not >>>> imply resistance to dictionary attack, only that the >>>> probability of success in >>>> such an attack is acceptably remote. >>>> >>>> regards, >>>> >>>> Dan. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Emu mailing list >>>> Emu@ietf.org >>>> https://www.ietf.org/mailman/listinfo/emu >>>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 9 12:38:25 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106913A6B26; Wed, 9 Apr 2008 12:38:25 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375833A6B26 for ; Wed, 9 Apr 2008 12:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjbIGfI3UJCJ for ; Wed, 9 Apr 2008 12:38:23 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 7A9873A687B for ; Wed, 9 Apr 2008 12:38:22 -0700 (PDT) Received: from u-172-c174.cs.uni-tuebingen.de ([134.2.172.174]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1Jjg81-0003dM-PS for emu@ietf.org; Wed, 09 Apr 2008 21:38:41 +0200 Message-ID: <47FD1B3F.2050401@uni-tuebingen.de> Date: Wed, 09 Apr 2008 21:38:39 +0200 From: Ali Fessi User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: emu@ietf.org Subject: [Emu] Question on EAP-IKEv2 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Hi, I wonder why the IKEv2 exchange in EAP-IKEv2 is initiated by the server. (See, RFC 5106, Page 7, Figure 1, message 3) Is the reason to save two messages, for example, compared to EAP-TLS? Best, Ali _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Apr 10 19:25:40 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D019928C50E; Thu, 10 Apr 2008 19:25:40 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D423A69B0 for ; Thu, 10 Apr 2008 19:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.357 X-Spam-Level: X-Spam-Status: No, score=-6.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXtpQ+g2b6sC for ; Thu, 10 Apr 2008 19:25:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5FE8F3A6CE0 for ; Thu, 10 Apr 2008 19:25:35 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Apr 2008 19:25:57 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m3B2Pvrv030490 for ; Thu, 10 Apr 2008 19:25:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3B2PvRL025491 for ; Fri, 11 Apr 2008 02:25:57 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); Thu, 10 Apr 2008 19:25:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Apr 2008 19:26:46 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EMU charter revision Thread-Index: Acibe317kweUp4HKTkWQQaLqPB97nQ== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 11 Apr 2008 02:25:57.0440 (UTC) FILETIME=[6006CC00:01C89B7B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3310; t=1207880757; x=1208744757; 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:=20EMU=20charter=20revision |Sender:=20; bh=HzxycK28gRcr6vu5tYaVZAPx/pVNX68sgd/SmczrPsc=; b=EA6iyhiC+/fbqlUYGurgauUXGtFBeX7BVpKKHnZxqp96NK9sEqjTVuXIG2 xMW5V7fNv3M3HWHSXXag1uvLczKJPxweWIsDjgNUPR6YIUmO4xI3MVsO2EMt L2nZ+rNgdn; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Below is a revision to the EMU charter that is intended to reflect the discussions in the Philadelphia meeting. Please respond to the list if you approve of the charter or if you have any comments on the charter. I would like to have responses by 4/24. Thanks, Joe Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods, but some are documented in informational RFCs. In the past the lack of documented, open specifications has been a deployment and interoperability problem. There are currently only two EAP methods in the standards track that implement features such as key derivation that are required for many modern applications. Authentication types and credentials continue to evolve as do requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement. - A mechanism based on strong shared secrets. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. - A mechanism to support extensible communication within a TLS protected tunnel. This mechanism must support channel bindings in order to meet RFC 4962 requirements. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will extend EAP-TLS and/or the above tunnel method. - A mechanism that makes use of existing password databases such as AAA databases. This item will be based on the above tunnel method. Goals and Milestones: Done Form design team to work on strong shared secret mechanism Done Submit 2716bis I-D Done Submit first draft of shared secret mechanism I-D Done Form password based mechanism design team Done Submit 2716bis draft to IESG for Proposed Standard Apr 2008 Submit Strong Shared Secret Mechanism to IESG May 2008 Submit Tunnel and Password Method requirements first Draft Sep 2008 Submit EAP Channel Bindings First Draft Sep 2008 Submit Tunnel Method first draft Oct 2008 Submit TLS based method channel binding first draft Oct 2008 Submit Password Method first draft Jan 2009 Send EAP Channel Bindings to IESG Mar 2009 Send Tunnel Method to IESG Apr 2009 Send TLS based method channel binding to IESG Apr 2009 Send Password based method to IESG _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 11 10:38:09 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914003A6825; Fri, 11 Apr 2008 10:38:09 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8DE63A67D4 for ; Fri, 11 Apr 2008 10:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhPFxA5D5TSD for ; Fri, 11 Apr 2008 10:38:07 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 41B7F3A695C for ; Fri, 11 Apr 2008 10:38:04 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0AF75A8882BA; Fri, 11 Apr 2008 10:38:28 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 11 Apr 2008 10:38:28 -0700 (PDT) Message-ID: <966f2c824f7a17d84f138a2ee956328e.squirrel@www.trepanning.net> In-Reply-To: References: Date: Fri, 11 Apr 2008 10:38:28 -0700 (PDT) From: "Dan Harkins" To: "Joseph Salowey (jsalowey)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Hi Joe, Thank you for giving me the opportunity to object, once again, to the last sentence in the last item in the charter. If you were to run the following sed filter on the charter I would approve: s/This item will be based on the above tunnel method.// What is the process here? This looks the same as the charter revision you made a consensus call on back in January. I was the only one to opine before your cutoff last time and my comment was the same as above. Now we're doing this again. Dan. On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) wrote: > Below is a revision to the EMU charter that is intended to reflect the > discussions in the Philadelphia meeting. Please respond to the list if > you approve of the charter or if you have any comments on the charter. > I would like to have responses by 4/24. > > Thanks, > > Joe > > Description of Working Group: > The Extensible Authentication Protocol (EAP) [RFC 3748] is a network > access authentication framework used in the PPP, 802.11, 802.16, VPN, > PANA, and in some functions in 3G networks. EAP itself is a simple > protocol and actual authentication happens in EAP methods. > > Over 40 different EAP methods exist. Most of these methods are > proprietary methods, but some are documented in informational RFCs. In > the past the lack of documented, open specifications has been a > deployment and interoperability problem. There are currently only two > EAP methods in the standards track that implement features such as key > derivation that are required for many modern applications. > Authentication types and credentials continue to evolve as do > requirements for EAP methods. > > This group is chartered to work on the following types of mechanisms to > meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements: > > - An update to RFC 2716 to bring EAP-TLS into standards track, clarify > specification, interoperability, and implementation issues gathered over > the years, and update the document to meet the requirements of RFC 3748, > RFC 4017, and EAP keying framework documents. Backwards compatibility > with RFC 2716 is a requirement. > > - A mechanism based on strong shared secrets. This mechanism should > strive to be simple and compact for implementation in resource > constrained environments. > > - A document that defines EAP channel bindings and provides guidance for > establishing EAP channel bindings within EAP methods. > > - A mechanism to support extensible communication within a TLS protected > tunnel. This mechanism must support channel bindings in order to meet > RFC 4962 requirements. This mechanism will support meeting the > requirements of an enhanced TLS mechanism, a password based > authentication mechanism, and additional inner authentication > mechanisms. > > - Enable a TLS-based EAP method to support channel bindings. This item > will not generate a new method, rather it will extend EAP-TLS and/or the > above tunnel method. > > - A mechanism that makes use of existing password databases such as AAA > databases. This item will be based on the above tunnel method. > > Goals and Milestones: > Done Form design team to work on strong shared secret > mechanism > Done Submit 2716bis I-D > Done Submit first draft of shared secret mechanism I-D > Done Form password based mechanism design team > Done Submit 2716bis draft to IESG for Proposed Standard > Apr 2008 Submit Strong Shared Secret Mechanism to IESG > May 2008 Submit Tunnel and Password Method requirements first > Draft > Sep 2008 Submit EAP Channel Bindings First Draft > Sep 2008 Submit Tunnel Method first draft > Oct 2008 Submit TLS based method channel binding first draft > Oct 2008 Submit Password Method first draft > Jan 2009 Send EAP Channel Bindings to IESG > Mar 2009 Send Tunnel Method to IESG > Apr 2009 Send TLS based method channel binding to IESG > Apr 2009 Send Password based method to IESG > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 11 14:48:18 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F43D3A6AAA; Fri, 11 Apr 2008 14:48:18 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7123A6984 for ; Fri, 11 Apr 2008 14:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFltdsEIte+2 for ; Fri, 11 Apr 2008 14:48:12 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D214C3A6854 for ; Fri, 11 Apr 2008 14:48:12 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 11 Apr 2008 14:48:37 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3BLmbmn031776; Fri, 11 Apr 2008 14:48:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3BLmbkQ015660; Fri, 11 Apr 2008 21:48:37 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Apr 2008 14:48:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Apr 2008 14:49:26 -0700 Message-ID: In-Reply-To: <966f2c824f7a17d84f138a2ee956328e.squirrel@www.trepanning.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision Thread-Index: Acib+uycgyJnsgmdTcGkr+PfpTfvdgAA/brQ References: <966f2c824f7a17d84f138a2ee956328e.squirrel@www.trepanning.net> From: "Joseph Salowey (jsalowey)" To: "Dan Harkins" X-OriginalArrivalTime: 11 Apr 2008 21:48:36.0823 (UTC) FILETIME=[CBDBE670:01C89C1D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5642; t=1207950517; x=1208814517; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20EMU=20charter=20revision |Sender:=20; bh=pgFw3rLUi8C5COR4Rfa3emqu5F10ukDC6VICaBVE0wM=; b=FbZlmFt+73leyn5GQQU2bRYmVF7mvX0+iHDustRUBoZnK0+i3aWlWPmomB i36DvZ7hMY92D5HzNT2p2Bg4VORAf65IYEvZYt9hIU7GA2yzsT1BuQjMd2/L bRhuVy+B1a; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Friday, April 11, 2008 10:38 AM > To: Joseph Salowey (jsalowey) > Cc: emu@ietf.org > Subject: Re: [Emu] EMU charter revision > > > Hi Joe, > > Thank you for giving me the opportunity to object, once > again, to the last sentence in the last item in the charter. > If you were to run the following sed filter on the charter I > would approve: > > s/This item will be based on the above tunnel method.// > [Joe] I do not think that removing this line would achieve the goal you wish. With this line removed EAP-PWD is still out of scope of the charter as it does not meet the requirements of supporting legacy password databases. The message from the ADs in the last meeting was pretty clear in that EAP-PWD style mechanisms is not something for the group to take on right now. This does not mean that we cannot take on an EAP-PWD style mechanism once we have made progress on the current charter items. > What is the process here? This looks the same as the > charter revision you made a consensus call on back in > January. I was the only one to opine before your cutoff last > time and my comment was the same as above. Now we're doing this again. > [Joe] There have been several revisions posted to the list and feedback from several working group members that have been worked into the new proposal along with input from the discussion in the last meeting. If enough people respond positively, such that we have rough consensus, then we can move forward. > Dan. > > On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) wrote: > > Below is a revision to the EMU charter that is intended to > reflect the > > discussions in the Philadelphia meeting. Please respond to > the list > > if you approve of the charter or if you have any comments > on the charter. > > I would like to have responses by 4/24. > > > > Thanks, > >f > > Joe > > > > Description of Working Group: > > The Extensible Authentication Protocol (EAP) [RFC 3748] is > a network > > access authentication framework used in the PPP, 802.11, > 802.16, VPN, > > PANA, and in some functions in 3G networks. EAP itself is a simple > > protocol and actual authentication happens in EAP methods. > > > > Over 40 different EAP methods exist. Most of these methods are > > proprietary methods, but some are documented in > informational RFCs. In > > the past the lack of documented, open specifications has been a > > deployment and interoperability problem. There are > currently only two > > EAP methods in the standards track that implement features > such as key > > derivation that are required for many modern applications. > > Authentication types and credentials continue to evolve as do > > requirements for EAP methods. > > > > This group is chartered to work on the following types of > mechanisms > > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements: > > > > - An update to RFC 2716 to bring EAP-TLS into standards > track, clarify > > specification, interoperability, and implementation issues gathered > > over the years, and update the document to meet the requirements of > > RFC 3748, RFC 4017, and EAP keying framework documents. Backwards > > compatibility with RFC 2716 is a requirement. > > > > - A mechanism based on strong shared secrets. This mechanism should > > strive to be simple and compact for implementation in resource > > constrained environments. > > > > - A document that defines EAP channel bindings and provides > guidance > > for establishing EAP channel bindings within EAP methods. > > > > - A mechanism to support extensible communication within a TLS > > protected tunnel. This mechanism must support channel bindings in > > order to meet RFC 4962 requirements. This mechanism will support > > meeting the requirements of an enhanced TLS mechanism, a password > > based authentication mechanism, and additional inner authentication > > mechanisms. > > > > - Enable a TLS-based EAP method to support channel > bindings. This item > > will not generate a new method, rather it will extend > EAP-TLS and/or > > the above tunnel method. > > > > - A mechanism that makes use of existing password databases such as > > AAA databases. This item will be based on the above tunnel method. > > > > Goals and Milestones: > > Done Form design team to work on strong shared secret > > mechanism > > Done Submit 2716bis I-D > > Done Submit first draft of shared secret > mechanism I-D > > Done Form password based mechanism design team > > Done Submit 2716bis draft to IESG for > Proposed Standard > > Apr 2008 Submit Strong Shared Secret Mechanism to IESG > > May 2008 Submit Tunnel and Password Method requirements first > > Draft > > Sep 2008 Submit EAP Channel Bindings First Draft > > Sep 2008 Submit Tunnel Method first draft > > Oct 2008 Submit TLS based method channel binding first draft > > Oct 2008 Submit Password Method first draft > > Jan 2009 Send EAP Channel Bindings to IESG > > Mar 2009 Send Tunnel Method to IESG > > Apr 2009 Send TLS based method channel binding to IESG > > Apr 2009 Send Password based method to IESG > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 16 14:54:44 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0AD73A6C9D; Wed, 16 Apr 2008 14:54:44 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B5C3A6B37 for ; Wed, 16 Apr 2008 14:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7po2HAaX0I8s for ; Wed, 16 Apr 2008 14:54:43 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id A58BA3A6C9D for ; Wed, 16 Apr 2008 14:54:43 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2690575wfa.31 for ; Wed, 16 Apr 2008 14:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=shFojc8bnVHAqUXWM13ruqouj727/1qxPf+3tw8TRPY=; b=f89BWq0dcFCoDhhbxUe4Db7QT5UUohvSvoYmLQNF/8Tz7VjkI3Frg/hDPZEF9toDtko5OQWwpVgiKjsdubt+bd0wub2yfu0l0fWPZ9Pc+Q+AkGf40lz6hI0UJAZVJRrGVgf2ST8Y+AN8LguaRKsziGj6LX1xmwsLznqbOeXowUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=bJlUZnPVKdiB6S9yHjkwiArslVMbV9Wjv5AMDHyjvzepVWmt5m+cWd1ZlkASqBamGwTAtCex997NhQ9TWkYp8wd5wGqRRVJQ1SA38iS5cTqCsKYPKnC54hpQX8ONpRfleEWpZk0aohd3Rn5WbnNgkNYabWgBk9n/qxVsPkR8m0E= Received: by 10.142.68.14 with SMTP id q14mr155214wfa.290.1208382919969; Wed, 16 Apr 2008 14:55:19 -0700 (PDT) Received: by 10.142.232.11 with HTTP; Wed, 16 Apr 2008 14:55:19 -0700 (PDT) Message-ID: <98f5f260804161455v2ce83569l6e97fc9752d24c98@mail.gmail.com> Date: Wed, 16 Apr 2008 17:55:19 -0400 From: "=?ISO-8859-1?Q?Katrin_H=F6per?=" To: emu@ietf.org, hokey@ietf.org, saag@mit.edu MIME-Version: 1.0 Subject: [Emu] Invitation to subscribe to IETF proxy mailing list X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1169493286==" Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org --===============1169493286== Content-Type: multipart/alternative; boundary="----=_Part_24521_32487092.1208382919967" ------=_Part_24521_32487092.1208382919967 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Security problems related to network proxies persistently come up in several IETF WGs and may affect the security of existing IETF network solutions while slowing down the progress of some current Internet Drafts. For this reason, Tim Polk and I organized an informal meeting in Philadelphia at IETF 71 to discuss these so-called "proxy problems" and their implications. As a result of our meeting, a proxy email list was created to further investigate the proxy problems. This email serves as an invitation to anybody interested to join our discussions on the list. Please subscribe at: https://www.ietf.org/mailman/listinfo/proxies Best regards, Katrin Hoeper ______________________________________________ Katrin Hoeper Computer Security Division National Institute of Standards and Technology (NIST) 100 Bureau Dr. Mail stop: 8930 Gaithersburg, MD 20878 (301) 975 - 4024 ------=_Part_24521_32487092.1208382919967 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi,

 

Security problems related to network proxies persistently come up in several IETF WGs and may affect the security of existing IETF network solutions while slowing down the progress of some current Internet Drafts.

 

For this reason, Tim Polk and I organized an informal meeting in Philadelphia at IETF 71 to discuss these so-called "proxy problems" and their implications. As a result of our meeting, a proxy email list was created to further investigate the proxy problems.

 

This email serves as an invitation to anybody interested to join our discussions on the list. Please subscribe at: https://www.ietf.org/mailman/listinfo/proxies

 

Best regards,

Katrin Hoeper

 ______________________________________________

Katrin Hoeper
Computer Security Division
National Institute of Standards and Technology (NIST)
100 Bureau Dr. Mail stop: 8930
Gaithersburg, MD 20878
(301) 975 - 4024

------=_Part_24521_32487092.1208382919967-- --===============1169493286== 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://www.ietf.org/mailman/listinfo/emu --===============1169493286==-- From emu-bounces@ietf.org Thu Apr 24 18:10:30 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0F63A6853; Thu, 24 Apr 2008 18:10:30 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962FF3A6AC4 for ; Thu, 24 Apr 2008 17:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aas5mKKcnU2 for ; Thu, 24 Apr 2008 17:49:30 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 9574B3A63EC for ; Thu, 24 Apr 2008 17:49:30 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BAFA7A888596; Thu, 24 Apr 2008 17:49:35 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 24 Apr 2008 17:49:35 -0700 (PDT) Message-ID: <5b1cd31b697b83e674c02b801a04eb42.squirrel@www.trepanning.net> In-Reply-To: References: Date: Thu, 24 Apr 2008 17:49:35 -0700 (PDT) From: "Dan Harkins" To: "Glen Zorn" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Thu, 24 Apr 2008 18:10:26 -0700 Cc: Dan@trepanning.net, Harkins@trepanning.net, " , emu@ietf.org"@trepanning.net, "Joseph Salowey " , "@trepanning.net"@core3.amsl.com Subject: Re: [Emu] comment on draft-ietf-emu-eap-gpsk X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org I'm glad we three agree that EAP-GPSK should not be claiming resistance to dictionary attack so what can we do about it? Dan. On Thu, April 3, 2008 6:31 pm, Glen Zorn wrote: > Joseph Salowey (jsalowey) scribbled on > Wednesday, April 02, 2008 9:31 AM: > >> OK, but do you agree that EAP-GPSK should not be claiming >> resistance to dictionary attack if its security depends upon >> the selection of secret from a pool that is large enough? > > Yes. > >> >> Joe >> >>> -----Original Message----- >>> From: Glen Zorn [mailto:gzorn@arubanetworks.com] >>> Sent: Wednesday, April 02, 2008 2:09 AM >>> To: Dan Harkins >>> Cc: Joseph Salowey (jsalowey); emu@ietf.org >>> Subject: RE: [Emu] comment on draft-ietf-emu-eap-gpsk >>> >>> Joseph Salowey (jsalowey) <> scribbled on : >>> >>>> Thanks Dan, I agree with your assessment. I think we should >>>> include text similar to what you propose in the document. >>>> >>>> Joe >>>> >>>>> -----Original Message----- >>>>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf >>>>> Of Dan Harkins Sent: Tuesday, April 01, 2008 3:26 PM >>>>> To: emu@ietf.org >>>>> Subject: [Emu] comment on draft-ietf-emu-eap-gpsk >>>>> >>>>> >>>>> Hello, >>>>> >>>>> Section 11.6 of draft-ietf-emu-eap-gpsk says: >>>>> >>>>> EAP-GPSK relies on a long-term shared secret (PSK) that MUST >>>>> be based on at least 16 octets of entropy to guarantee >>>>> security against dictionary attacks. >>>>> >>>>> This is not a generally accepted view of resistance to dictionary >>>>> attack. For instance, the excellent paper by Bellare, Pointcheval, >>>>> and Rogaway, Authenticated Key Exchange Secure Against Dictionary >>>>> Attacks says: >>>>> >>>>> One sees whether or not one has security against dictionary >>>>> attacks by looking to see if maximal adversarial advantage >>>>> grows primarily with the ratio of interaction to the size of >>>>> the password space. >>> >>> In other word, if the choice of dictionary elements significantly >>> increases the likelihood of success over that of randomly chosen >>> strings from the search space. >>> >>>>> >>>>> Open Key Exchange-- How to Defeat Dictionary Attacks Without >>>>> Encrypting Public Keys, by Stefan Lucks, says that the probability >>>>> of success of the attacker is based on the size of the dictionary >>>>> and the number of number of times the attacker has been rejected >>>>> (after active attack), and "does not significantly exceed 1/(S-R)" >>>>> where S is the size of the dictionary and R is the number or >>>>> rejections. >>> >>> This says essentially the same thing, since 1/(S-R) is just the >>> probability of success of a brute force attack. >>> >>>>> >>>>> Even RFC3748 says that for an EAP method to be resistant to >>>>> dictionary attacks that: >>>>> >>>>> ...the method does not allow an offline attack that has a >>>>> work factor based on the number of passwords in an >>>>> attacker's dictionary. >>>>> >>>>> The idea here is that merely making the size of the pool from >>>>> which the secret is drawn (i.e. "the dictionary") large does not >>>>> make a protocol resistant to dictionary attack. What makes it >>>>> resistant to dictionary attacks is whether an attacker gets one >>>>> guess at the password per active attack-- interaction-- and not an >>>>> unlimited number after a single attack-- computation. >>> >>> No. What makes a protocol resistant to dictionary attack is that the >>> use of a dictionary (i.e., a subset of the search space chosen to >>> increase the probability of success) doesn't work any better than a >>> brute force attack without a dictionary. That's why they are called >>> "dictionary attacks" & not "one guess attacks" or some such thing. >>> >>>>> >>>>> This draft implies that since the secret has "16 octets of >>>>> entropy"-- 2^128 bits, which is quite a requirement!-- that it is >>>>> resistant to a dictionary attack. This is not correct. >>>>> >>>>> I really think this draft should be corrected to not imply it has >>>>> resistance to dictionary attack. I suggest something along the >>>>> lines of: >>>>> >>>>> The success of a dictionary attack against EAP-GPSK depends >>>>> on the strength of the long-term shared secret (PSK) it >>>>> uses. The PSK used by EAP-GPSK MUST be drawn from a pool of >>>>> secrets that is at least 2^128 bits large and whose >>>>> distribution is uniformly random. Note that this does not >>>>> imply resistance to dictionary attack, only that the >>>>> probability of success in >>>>> such an attack is acceptably remote. >>>>> >>>>> regards, >>>>> >>>>> Dan. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Emu mailing list >>>>> Emu@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/emu >>>>> >>>> _______________________________________________ >>>> Emu mailing list >>>> Emu@ietf.org >>>> https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 25 08:00:58 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777F228C297; Fri, 25 Apr 2008 08:00:58 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B0B3A692A; Fri, 25 Apr 2008 07:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umht5YaY2O4y; Fri, 25 Apr 2008 07:19:59 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 4F3A83A68E2; Fri, 25 Apr 2008 07:19:59 -0700 (PDT) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m3PEJWjs020384; Fri, 25 Apr 2008 10:19:32 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <0229AD28-4007-4DAA-A098-7201A7F81C41@nist.gov> From: Tim Polk Date: Fri, 25 Apr 2008 10:19:40 -0400 To: emu@ietf.org, msec@ietf.org X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Mailman-Approved-At: Fri, 25 Apr 2008 08:00:57 -0700 Cc: "secdir@MIT.EDU" , Ran Canetti , saag@mit.edu, Brian Weis Subject: [Emu] new co-chairs for emu and msec X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Folks, Pasi and I are very pleased to announce that two of our co-chair vacancies have been filled. Alan Dekok has agreed to co-chair the EAP Method Update (emu) working group with Joe Salowey, who has been flying solo for some time now. Brian Weis will be co- chairing the Multicast Security (msec) working group; he is taking over for Ran Canetti. Lakshminath Dondeti has agreed to continue with msec for a bit longer, which we greatly appreciate. This will certainly smooth the transition, and it gives Pasi and I a bit more time to finalize things with a second co-chair for msec. We are really delighted that Alan and Brian have accepted these leadership positions, and are looking forward to working closely with them in the future. We also would like to thank everyone that threw their name into the hat. Pasi and I had the luxury of choosing between multiple highly qualified candidates. It is great to see how many people have the ability and desire to contribute in IETF leadership positions. Finally, we would like to thank everyone in the community that submitted nominations. Please stay tuned for future co-chair announcements for tls and msec. Thanks, Tim Polk and Pasi Eronen _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 25 09:14:36 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42E5D28C377; Fri, 25 Apr 2008 09:14:36 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B517928C35B; Fri, 25 Apr 2008 09:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAPHgZz7-hkE; Fri, 25 Apr 2008 09:14:29 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 37C1A28C37A; Fri, 25 Apr 2008 09:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1209140074; x=1240676074; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<48120367.8090307@qualcomm.com>|Date:=20Fr i,=2025=20Apr=202008=2009:14:31=20-0700|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.12=20(Windows/20080213)|MIME-Version:=201 .0|To:=20Alan=20DeKok=20,=20Br ian=20Weis=20|CC:=20Tim=20Polk=20,=20emu@ietf.org,=20msec@ietf.org,=0D=0A=20=20 =20=20=20=20=20=20"secdir@MIT.EDU"=20,=20 saag@mit.edu,=0D=0A=20=20=20=20=20=20=20=20Pasi=20Eronen =20,=0D=0A=20=20=20=20=20=20=20=20 Ran=20Canetti=20|Subject:=20Re: =20new=20co-chairs=20for=20emu=20and=20msec|References: =20<0229AD28-4007-4DAA-A098-7201A7F81C41@nist.gov> |In-Reply-To:=20<0229AD28-4007-4DAA-A098-7201A7F81C41@nis t.gov>|Content-Type:=20text/plain=3B=20charset=3DISO-8859 -15=3B=20format=3Dflowed|Content-Transfer-Encoding:=207bi t|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5282"=3B=20 a=3D"2699423"; bh=foj0P28z/Z4uuNmaP7fEqfTVVBbdlmjRyL6+V1cwrT8=; b=xHbVHeSaPhPQ5KEMXGOz+movENekoXoKttme4ruN9rCmOZkgyPOjW4Ev IIn18MzpKGDkycvVziqIBKl1I/T5IDko3BQzRD3OhPTJDC8E+LyarJF7u ZnE4CJzR6BqF4rWliS8J6O3MbaIy6RbdrxvGkxacYmeUY2lYnuN2FVjh+ Y=; X-IronPort-AV: E=McAfee;i="5100,188,5282"; a="2699423" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2008 09:14:33 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3PGEX8J011300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Apr 2008 09:14:33 -0700 Received: from [10.50.64.103] (qconnect-10-50-64-103.qualcomm.com [10.50.64.103]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3PGEV3A025356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Apr 2008 09:14:32 -0700 Message-ID: <48120367.8090307@qualcomm.com> Date: Fri, 25 Apr 2008 09:14:31 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Alan DeKok , Brian Weis References: <0229AD28-4007-4DAA-A098-7201A7F81C41@nist.gov> In-Reply-To: <0229AD28-4007-4DAA-A098-7201A7F81C41@nist.gov> Cc: msec@ietf.org, emu@ietf.org, Tim Polk , "secdir@MIT.EDU" , Ran Canetti , saag@mit.edu Subject: Re: [Emu] new co-chairs for emu and msec X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Congratulations to Alan and Brian. Thanks for taking on these responsibilities. best wishes, Lakshminath On 4/25/2008 7:19 AM, Tim Polk wrote: > Folks, > > Pasi and I are very pleased to announce that two of our co-chair > vacancies have been filled. > > Alan Dekok has agreed to co-chair the EAP Method Update (emu) working > group with Joe Salowey, > who has been flying solo for some time now. Brian Weis will be > co-chairing the Multicast Security > (msec) working group; he is taking over for Ran Canetti. Lakshminath > Dondeti has agreed to continue > with msec for a bit longer, which we greatly appreciate. This will > certainly smooth the transition, and > it gives Pasi and I a bit more time to finalize things with a second > co-chair for msec. > > We are really delighted that Alan and Brian have accepted these > leadership positions, and are looking > forward to working closely with them in the future. We also would like > to thank everyone that threw their > name into the hat. Pasi and I had the luxury of choosing between > multiple highly qualified candidates. > It is great to see how many people have the ability and desire to > contribute in IETF leadership positions. > Finally, we would like to thank everyone in the community that submitted > nominations. > > Please stay tuned for future co-chair announcements for tls and msec. > > Thanks, > > Tim Polk and Pasi Eronen > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Apr 25 17:42:46 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039143A6C74; Fri, 25 Apr 2008 17:42:46 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E4E3A68E5 for ; Fri, 25 Apr 2008 17:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.661, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRqqGL4dI3Hw for ; Fri, 25 Apr 2008 17:42:44 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 2C7EF3A6D2F for ; Fri, 25 Apr 2008 17:42:44 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D37A810224074; Fri, 25 Apr 2008 17:42:48 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 25 Apr 2008 17:42:48 -0700 (PDT) Message-ID: <089d20b64295debabe49c740e696c052.squirrel@www.trepanning.net> In-Reply-To: References: <966f2c824f7a17d84f138a2ee956328e.squirrel@www.trepanning.net> Date: Fri, 25 Apr 2008 17:42:48 -0700 (PDT) From: "Dan Harkins" To: "Joseph Salowey (jsalowey)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Hi Joe, Once again, a call for comments and I'm the only one to comment. Whether removing that line achieves "my goals" or not I still think it should be removed. And that really seems to be the only comment on the charter you get when you ask. regards, Dan. On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) wrote: > > >> -----Original Message----- >> From: Dan Harkins [mailto:dharkins@lounge.org] >> Sent: Friday, April 11, 2008 10:38 AM >> To: Joseph Salowey (jsalowey) >> Cc: emu@ietf.org >> Subject: Re: [Emu] EMU charter revision >> >> >> Hi Joe, >> >> Thank you for giving me the opportunity to object, once >> again, to the last sentence in the last item in the charter. >> If you were to run the following sed filter on the charter I >> would approve: >> >> s/This item will be based on the above tunnel method.// >> > > [Joe] I do not think that removing this line would achieve the goal you > wish. With this line removed EAP-PWD is still out of scope of the > charter as it does not meet the requirements of supporting legacy > password databases. The message from the ADs in the last meeting was > pretty clear in that EAP-PWD style mechanisms is not something for the > group to take on right now. This does not mean that we cannot take on > an EAP-PWD style mechanism once we have made progress on the current > charter items. > >> What is the process here? This looks the same as the >> charter revision you made a consensus call on back in >> January. I was the only one to opine before your cutoff last >> time and my comment was the same as above. Now we're doing this again. >> > [Joe] There have been several revisions posted to the list and feedback > from several working group members that have been worked into the new > proposal along with input from the discussion in the last meeting. If > enough people respond positively, such that we have rough consensus, > then we can move forward. > > >> Dan. >> >> On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) wrote: >> > Below is a revision to the EMU charter that is intended to >> reflect the >> > discussions in the Philadelphia meeting. Please respond to >> the list >> > if you approve of the charter or if you have any comments >> on the charter. >> > I would like to have responses by 4/24. >> > >> > Thanks, >> >f >> > Joe >> > >> > Description of Working Group: >> > The Extensible Authentication Protocol (EAP) [RFC 3748] is >> a network >> > access authentication framework used in the PPP, 802.11, >> 802.16, VPN, >> > PANA, and in some functions in 3G networks. EAP itself is a simple >> > protocol and actual authentication happens in EAP methods. >> > >> > Over 40 different EAP methods exist. Most of these methods are >> > proprietary methods, but some are documented in >> informational RFCs. In >> > the past the lack of documented, open specifications has been a >> > deployment and interoperability problem. There are >> currently only two >> > EAP methods in the standards track that implement features >> such as key >> > derivation that are required for many modern applications. >> > Authentication types and credentials continue to evolve as do >> > requirements for EAP methods. >> > >> > This group is chartered to work on the following types of >> mechanisms >> > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements: >> > >> > - An update to RFC 2716 to bring EAP-TLS into standards >> track, clarify >> > specification, interoperability, and implementation issues gathered >> > over the years, and update the document to meet the requirements of >> > RFC 3748, RFC 4017, and EAP keying framework documents. Backwards >> > compatibility with RFC 2716 is a requirement. >> > >> > - A mechanism based on strong shared secrets. This mechanism should >> > strive to be simple and compact for implementation in resource >> > constrained environments. >> > >> > - A document that defines EAP channel bindings and provides >> guidance >> > for establishing EAP channel bindings within EAP methods. >> > >> > - A mechanism to support extensible communication within a TLS >> > protected tunnel. This mechanism must support channel bindings in >> > order to meet RFC 4962 requirements. This mechanism will support >> > meeting the requirements of an enhanced TLS mechanism, a password >> > based authentication mechanism, and additional inner authentication >> > mechanisms. >> > >> > - Enable a TLS-based EAP method to support channel >> bindings. This item >> > will not generate a new method, rather it will extend >> EAP-TLS and/or >> > the above tunnel method. >> > >> > - A mechanism that makes use of existing password databases such as >> > AAA databases. This item will be based on the above tunnel method. >> > >> > Goals and Milestones: >> > Done Form design team to work on strong shared secret >> > mechanism >> > Done Submit 2716bis I-D >> > Done Submit first draft of shared secret >> mechanism I-D >> > Done Form password based mechanism design team >> > Done Submit 2716bis draft to IESG for >> Proposed Standard >> > Apr 2008 Submit Strong Shared Secret Mechanism to IESG >> > May 2008 Submit Tunnel and Password Method requirements first >> > Draft >> > Sep 2008 Submit EAP Channel Bindings First Draft >> > Sep 2008 Submit Tunnel Method first draft >> > Oct 2008 Submit TLS based method channel binding first draft >> > Oct 2008 Submit Password Method first draft >> > Jan 2009 Send EAP Channel Bindings to IESG >> > Mar 2009 Send Tunnel Method to IESG >> > Apr 2009 Send TLS based method channel binding to IESG >> > Apr 2009 Send Password based method to IESG >> > _______________________________________________ >> > Emu mailing list >> > Emu@ietf.org >> > https://www.ietf.org/mailman/listinfo/emu >> > >> >> >> > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Apr 27 18:10:36 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5793A6A59; Sun, 27 Apr 2008 18:10:36 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0973A6818 for ; Sun, 27 Apr 2008 18:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+9ly4+0x2eu for ; Sun, 27 Apr 2008 18:10:34 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id D22673A68E6 for ; Sun, 27 Apr 2008 18:10:33 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Sun, 27 Apr 2008 18:10:36 PDT Received: from proton.jnpr.net ([10.10.2.37]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 Apr 2008 18:10:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 27 Apr 2008 21:10:01 -0400 Message-ID: In-Reply-To: <089d20b64295debabe49c740e696c052.squirrel@www.trepanning.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision Thread-Index: AcinNnqUaaLdUmYhSni7zg4+VMFL5AAhFYQg References: <966f2c824f7a17d84f138a2ee956328e.squirrel@www.trepanning.net> <089d20b64295debabe49c740e696c052.squirrel@www.trepanning.net> From: "Stephen Hanna" To: "Dan Harkins" , "Joseph Salowey (jsalowey)" X-OriginalArrivalTime: 28 Apr 2008 01:10:03.0633 (UTC) FILETIME=[96C4BE10:01C8A8CC] Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org I apologize for my tardy response. I have been on vacation. I agree with and support the proposed charter below. As for Dan's suggestion that we not require the password based method to be based on the tunnel method, the WG already went through a long discussion and consensus check last fall on this matter. There was clear consensus that we should NOT work on a new password based method designed to function without the tunnel method. One person's opinion to the contrary does not negate that consensus. I think that the reason we are not seeing much email on this charter is that the issues and language have been hashed through many times. Thanks, Steve -----Original Message----- From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Dan Harkins Sent: Friday, April 25, 2008 5:43 PM To: Joseph Salowey (jsalowey) Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision Hi Joe, Once again, a call for comments and I'm the only one to comment. Whether removing that line achieves "my goals" or not I still think it should be removed. And that really seems to be the only comment on the charter you get when you ask. regards, Dan. On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) wrote: > > >> -----Original Message----- >> From: Dan Harkins [mailto:dharkins@lounge.org] >> Sent: Friday, April 11, 2008 10:38 AM >> To: Joseph Salowey (jsalowey) >> Cc: emu@ietf.org >> Subject: Re: [Emu] EMU charter revision >> >> >> Hi Joe, >> >> Thank you for giving me the opportunity to object, once >> again, to the last sentence in the last item in the charter. >> If you were to run the following sed filter on the charter I >> would approve: >> >> s/This item will be based on the above tunnel method.// >> > > [Joe] I do not think that removing this line would achieve the goal you > wish. With this line removed EAP-PWD is still out of scope of the > charter as it does not meet the requirements of supporting legacy > password databases. The message from the ADs in the last meeting was > pretty clear in that EAP-PWD style mechanisms is not something for the > group to take on right now. This does not mean that we cannot take on > an EAP-PWD style mechanism once we have made progress on the current > charter items. > >> What is the process here? This looks the same as the >> charter revision you made a consensus call on back in >> January. I was the only one to opine before your cutoff last >> time and my comment was the same as above. Now we're doing this again. >> > [Joe] There have been several revisions posted to the list and feedback > from several working group members that have been worked into the new > proposal along with input from the discussion in the last meeting. If > enough people respond positively, such that we have rough consensus, > then we can move forward. > > >> Dan. >> >> On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) wrote: >> > Below is a revision to the EMU charter that is intended to >> reflect the >> > discussions in the Philadelphia meeting. Please respond to >> the list >> > if you approve of the charter or if you have any comments >> on the charter. >> > I would like to have responses by 4/24. >> > >> > Thanks, >> >f >> > Joe >> > >> > Description of Working Group: >> > The Extensible Authentication Protocol (EAP) [RFC 3748] is >> a network >> > access authentication framework used in the PPP, 802.11, >> 802.16, VPN, >> > PANA, and in some functions in 3G networks. EAP itself is a simple >> > protocol and actual authentication happens in EAP methods. >> > >> > Over 40 different EAP methods exist. Most of these methods are >> > proprietary methods, but some are documented in >> informational RFCs. In >> > the past the lack of documented, open specifications has been a >> > deployment and interoperability problem. There are >> currently only two >> > EAP methods in the standards track that implement features >> such as key >> > derivation that are required for many modern applications. >> > Authentication types and credentials continue to evolve as do >> > requirements for EAP methods. >> > >> > This group is chartered to work on the following types of >> mechanisms >> > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements: >> > >> > - An update to RFC 2716 to bring EAP-TLS into standards >> track, clarify >> > specification, interoperability, and implementation issues gathered >> > over the years, and update the document to meet the requirements of >> > RFC 3748, RFC 4017, and EAP keying framework documents. Backwards >> > compatibility with RFC 2716 is a requirement. >> > >> > - A mechanism based on strong shared secrets. This mechanism should >> > strive to be simple and compact for implementation in resource >> > constrained environments. >> > >> > - A document that defines EAP channel bindings and provides >> guidance >> > for establishing EAP channel bindings within EAP methods. >> > >> > - A mechanism to support extensible communication within a TLS >> > protected tunnel. This mechanism must support channel bindings in >> > order to meet RFC 4962 requirements. This mechanism will support >> > meeting the requirements of an enhanced TLS mechanism, a password >> > based authentication mechanism, and additional inner authentication >> > mechanisms. >> > >> > - Enable a TLS-based EAP method to support channel >> bindings. This item >> > will not generate a new method, rather it will extend >> EAP-TLS and/or >> > the above tunnel method. >> > >> > - A mechanism that makes use of existing password databases such as >> > AAA databases. This item will be based on the above tunnel method. >> > >> > Goals and Milestones: >> > Done Form design team to work on strong shared secret >> > mechanism >> > Done Submit 2716bis I-D >> > Done Submit first draft of shared secret >> mechanism I-D >> > Done Form password based mechanism design team >> > Done Submit 2716bis draft to IESG for >> Proposed Standard >> > Apr 2008 Submit Strong Shared Secret Mechanism to IESG >> > May 2008 Submit Tunnel and Password Method requirements first >> > Draft >> > Sep 2008 Submit EAP Channel Bindings First Draft >> > Sep 2008 Submit Tunnel Method first draft >> > Oct 2008 Submit TLS based method channel binding first draft >> > Oct 2008 Submit Password Method first draft >> > Jan 2009 Send EAP Channel Bindings to IESG >> > Mar 2009 Send Tunnel Method to IESG >> > Apr 2009 Send TLS based method channel binding to IESG >> > Apr 2009 Send Password based method to IESG >> > _______________________________________________ >> > Emu mailing list >> > Emu@ietf.org >> > https://www.ietf.org/mailman/listinfo/emu >> > >> >> >> > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Apr 27 23:11:50 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF41728C1ED; Sun, 27 Apr 2008 23:11:50 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71343A6929 for ; Sun, 27 Apr 2008 23:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGazZpoxZVeE for ; Sun, 27 Apr 2008 23:11:49 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 8A1BB3A6BEC for ; Sun, 27 Apr 2008 23:11:49 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6ADAC10224074; Sun, 27 Apr 2008 23:11:53 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 27 Apr 2008 23:11:53 -0700 (PDT) Message-ID: <1150ac8bbb9ea8ae59b35181d7adf578.squirrel@www.trepanning.net> In-Reply-To: References: <966f2c824f7a17d84f138a2ee956328e.squirrel@www.trepanning.net> <089d20b64295debabe49c740e696c052.squirrel@www.trepanning.net> Date: Sun, 27 Apr 2008 23:11:53 -0700 (PDT) From: "Dan Harkins" To: "Stephen Hanna" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org That's true. One person's opinion does not negate consensus, even if that one person is the only one who is able to opine in the alloted time given for opinions (twice now). But so what? If someone asks then I'll give an honest opinion, especially since no one else seems to be able to. But maybe you're right. Any additional work taken on by this group would distract from the fantastic progress we've made in the past 9 months on the tunneled method. It would be a shame to lose all that. Yes, let's just focus on the snail race.... Dan. On Sun, April 27, 2008 6:10 pm, Stephen Hanna wrote: > I apologize for my tardy response. I have been on vacation. > > I agree with and support the proposed charter below. As for > Dan's suggestion that we not require the password based > method to be based on the tunnel method, the WG already > went through a long discussion and consensus check last > fall on this matter. There was clear consensus that we > should NOT work on a new password based method designed > to function without the tunnel method. One person's > opinion to the contrary does not negate that consensus. > I think that the reason we are not seeing much email on > this charter is that the issues and language have been > hashed through many times. > > Thanks, > > Steve > > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Dan Harkins > Sent: Friday, April 25, 2008 5:43 PM > To: Joseph Salowey (jsalowey) > Cc: emu@ietf.org > Subject: Re: [Emu] EMU charter revision > > > Hi Joe, > > Once again, a call for comments and I'm the only one to comment. > > Whether removing that line achieves "my goals" or not I still think > it should be removed. And that really seems to be the only comment > on the charter you get when you ask. > > regards, > > Dan. > > On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) wrote: >> >> >>> -----Original Message----- >>> From: Dan Harkins [mailto:dharkins@lounge.org] >>> Sent: Friday, April 11, 2008 10:38 AM >>> To: Joseph Salowey (jsalowey) >>> Cc: emu@ietf.org >>> Subject: Re: [Emu] EMU charter revision >>> >>> >>> Hi Joe, >>> >>> Thank you for giving me the opportunity to object, once >>> again, to the last sentence in the last item in the charter. >>> If you were to run the following sed filter on the charter I >>> would approve: >>> >>> s/This item will be based on the above tunnel method.// >>> >> >> [Joe] I do not think that removing this line would achieve the goal > you >> wish. With this line removed EAP-PWD is still out of scope of the >> charter as it does not meet the requirements of supporting legacy >> password databases. The message from the ADs in the last meeting was >> pretty clear in that EAP-PWD style mechanisms is not something for the >> group to take on right now. This does not mean that we cannot take on >> an EAP-PWD style mechanism once we have made progress on the current >> charter items. >> >>> What is the process here? This looks the same as the >>> charter revision you made a consensus call on back in >>> January. I was the only one to opine before your cutoff last >>> time and my comment was the same as above. Now we're doing this > again. >>> >> [Joe] There have been several revisions posted to the list and > feedback >> from several working group members that have been worked into the new >> proposal along with input from the discussion in the last meeting. If >> enough people respond positively, such that we have rough consensus, >> then we can move forward. >> >> >>> Dan. >>> >>> On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) wrote: >>> > Below is a revision to the EMU charter that is intended to >>> reflect the >>> > discussions in the Philadelphia meeting. Please respond to >>> the list >>> > if you approve of the charter or if you have any comments >>> on the charter. >>> > I would like to have responses by 4/24. >>> > >>> > Thanks, >>> >f >>> > Joe >>> > >>> > Description of Working Group: >>> > The Extensible Authentication Protocol (EAP) [RFC 3748] is >>> a network >>> > access authentication framework used in the PPP, 802.11, >>> 802.16, VPN, >>> > PANA, and in some functions in 3G networks. EAP itself is a simple >>> > protocol and actual authentication happens in EAP methods. >>> > >>> > Over 40 different EAP methods exist. Most of these methods are >>> > proprietary methods, but some are documented in >>> informational RFCs. In >>> > the past the lack of documented, open specifications has been a >>> > deployment and interoperability problem. There are >>> currently only two >>> > EAP methods in the standards track that implement features >>> such as key >>> > derivation that are required for many modern applications. >>> > Authentication types and credentials continue to evolve as do >>> > requirements for EAP methods. >>> > >>> > This group is chartered to work on the following types of >>> mechanisms >>> > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements: >>> > >>> > - An update to RFC 2716 to bring EAP-TLS into standards >>> track, clarify >>> > specification, interoperability, and implementation issues gathered >>> > over the years, and update the document to meet the requirements of >>> > RFC 3748, RFC 4017, and EAP keying framework documents. Backwards >>> > compatibility with RFC 2716 is a requirement. >>> > >>> > - A mechanism based on strong shared secrets. This mechanism should >>> > strive to be simple and compact for implementation in resource >>> > constrained environments. >>> > >>> > - A document that defines EAP channel bindings and provides >>> guidance >>> > for establishing EAP channel bindings within EAP methods. >>> > >>> > - A mechanism to support extensible communication within a TLS >>> > protected tunnel. This mechanism must support channel bindings in >>> > order to meet RFC 4962 requirements. This mechanism will support >>> > meeting the requirements of an enhanced TLS mechanism, a password >>> > based authentication mechanism, and additional inner authentication >>> > mechanisms. >>> > >>> > - Enable a TLS-based EAP method to support channel >>> bindings. This item >>> > will not generate a new method, rather it will extend >>> EAP-TLS and/or >>> > the above tunnel method. >>> > >>> > - A mechanism that makes use of existing password databases such as >>> > AAA databases. This item will be based on the above tunnel method. >>> > >>> > Goals and Milestones: >>> > Done Form design team to work on strong shared secret >>> > mechanism >>> > Done Submit 2716bis I-D >>> > Done Submit first draft of shared secret >>> mechanism I-D >>> > Done Form password based mechanism design team >>> > Done Submit 2716bis draft to IESG for >>> Proposed Standard >>> > Apr 2008 Submit Strong Shared Secret Mechanism to IESG >>> > May 2008 Submit Tunnel and Password Method requirements first >>> > Draft >>> > Sep 2008 Submit EAP Channel Bindings First Draft >>> > Sep 2008 Submit Tunnel Method first draft >>> > Oct 2008 Submit TLS based method channel binding first draft >>> > Oct 2008 Submit Password Method first draft >>> > Jan 2009 Send EAP Channel Bindings to IESG >>> > Mar 2009 Send Tunnel Method to IESG >>> > Apr 2009 Send TLS based method channel binding to IESG >>> > Apr 2009 Send Password based method to IESG >>> > _______________________________________________ >>> > Emu mailing list >>> > Emu@ietf.org >>> > https://www.ietf.org/mailman/listinfo/emu >>> > >>> >>> >>> >> > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 28 03:35:25 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8A928C254; Mon, 28 Apr 2008 03:35:25 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E880228C254 for ; Mon, 28 Apr 2008 03:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5VvdKzeRY7F for ; Mon, 28 Apr 2008 03:35:22 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 336D028C20B for ; Mon, 28 Apr 2008 03:35:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,716,1199682000"; d="scan'208";a="6530318" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Apr 2008 06:35:25 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3SAZPuk003184; Mon, 28 Apr 2008 06:35:25 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3SAZPe4009378; Mon, 28 Apr 2008 10:35:25 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); Mon, 28 Apr 2008 06:35:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 06:35:19 -0400 Message-ID: <0F64770A6FD22C43AAA498C1E774ECC705A0DE55@xmb-rtp-208.amer.cisco.com> In-Reply-To: <1150ac8bbb9ea8ae59b35181d7adf578.squirrel@www.trepanning.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision Thread-Index: Acio9s/R1InWQqDsSQum+9CaahO5OQAIvHww References: <966f2c824f7a17d84f138a2ee956328e.squirrel@www.trepanning.net><089d20b64295debabe49c740e696c052.squirrel@www.trepanning.net> <1150ac8bbb9ea8ae59b35181d7adf578.squirrel@www.trepanning.net> From: "Gene Chang (genchang)" To: "Dan Harkins" , "Stephen Hanna" X-OriginalArrivalTime: 28 Apr 2008 10:35:24.0960 (UTC) FILETIME=[91747A00:01C8A91B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9655; t=1209378925; x=1210242925; 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]=20EMU=20charter=20revision |Sender:=20 |To:=20=22Dan=20Harkins=22=20,=20=22St ephen=20Hanna=22=20; bh=5Tu0iyrqRj9pISii3JFd0z/BcexT4voCUMFrkWvGkIw=; b=qPSAqfh7Ad8WvAf29vpeCPe4PQ5vAkxvnMtGTj8Cjqb+Ubrw6zxa3OLgcl KdLwCLbJCdxEr8ozEvYQqZqi35KPllJ4c3tdKFC8qQKKCAvE02PrkgcM1own 8fCPkqPYiJ; Authentication-Results: rtp-dkim-2; header.From=genchang@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Dan, I am not sure I am able to clearly understand the end result you seek. It seems there is a clear consensus for a tunneled method. Are you pushing for the addition of a tunneled method? Ok... I am easily baited. What would you like to see to achieve more than a snail race? I am assuming we both believe the term "snail race" is a pejorative. Thus I ask you, how do we do better? I clearly hear your comment that there have been a paucity of comments, if nothing else, simply to affirm we are on track. I agree with the proposed charter. I am open to a discussion to add a non-tunneled method if there is sufficient demand. A non-tunneled method does not seem to promise enough features for the use cases that interest me. Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Dan > Harkins > Sent: Monday, April 28, 2008 2:12 AM > To: Stephen Hanna > Cc: emu@ietf.org > Subject: Re: [Emu] EMU charter revision > > > That's true. One person's opinion does not negate consensus, > even if that one person is the only one who is able to opine > in the alloted time given for opinions (twice now). But so what? > If someone asks then I'll give an honest opinion, especially > since no one else seems to be able to. > > But maybe you're right. Any additional work taken on by this > group would distract from the fantastic progress we've made in the > past 9 months on the tunneled method. It would be a shame to lose > all that. Yes, let's just focus on the snail race.... > > Dan. > > On Sun, April 27, 2008 6:10 pm, Stephen Hanna wrote: > > I apologize for my tardy response. I have been on vacation. > > > > I agree with and support the proposed charter below. As for > > Dan's suggestion that we not require the password based > > method to be based on the tunnel method, the WG already > > went through a long discussion and consensus check last > > fall on this matter. There was clear consensus that we > > should NOT work on a new password based method designed > > to function without the tunnel method. One person's > > opinion to the contrary does not negate that consensus. > > I think that the reason we are not seeing much email on > > this charter is that the issues and language have been > > hashed through many times. > > > > Thanks, > > > > Steve > > > > -----Original Message----- > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > > Dan Harkins > > Sent: Friday, April 25, 2008 5:43 PM > > To: Joseph Salowey (jsalowey) > > Cc: emu@ietf.org > > Subject: Re: [Emu] EMU charter revision > > > > > > Hi Joe, > > > > Once again, a call for comments and I'm the only one to comment. > > > > Whether removing that line achieves "my goals" or not I still think > > it should be removed. And that really seems to be the only comment > > on the charter you get when you ask. > > > > regards, > > > > Dan. > > > > On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) wrote: > >> > >> > >>> -----Original Message----- > >>> From: Dan Harkins [mailto:dharkins@lounge.org] > >>> Sent: Friday, April 11, 2008 10:38 AM > >>> To: Joseph Salowey (jsalowey) > >>> Cc: emu@ietf.org > >>> Subject: Re: [Emu] EMU charter revision > >>> > >>> > >>> Hi Joe, > >>> > >>> Thank you for giving me the opportunity to object, once > >>> again, to the last sentence in the last item in the charter. > >>> If you were to run the following sed filter on the charter I > >>> would approve: > >>> > >>> s/This item will be based on the above tunnel method.// > >>> > >> > >> [Joe] I do not think that removing this line would achieve the goal > > you > >> wish. With this line removed EAP-PWD is still out of scope of the > >> charter as it does not meet the requirements of supporting legacy > >> password databases. The message from the ADs in the last meeting was > >> pretty clear in that EAP-PWD style mechanisms is not something for the > >> group to take on right now. This does not mean that we cannot take on > >> an EAP-PWD style mechanism once we have made progress on the current > >> charter items. > >> > >>> What is the process here? This looks the same as the > >>> charter revision you made a consensus call on back in > >>> January. I was the only one to opine before your cutoff last > >>> time and my comment was the same as above. Now we're doing this > > again. > >>> > >> [Joe] There have been several revisions posted to the list and > > feedback > >> from several working group members that have been worked into the new > >> proposal along with input from the discussion in the last meeting. If > >> enough people respond positively, such that we have rough consensus, > >> then we can move forward. > >> > >> > >>> Dan. > >>> > >>> On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) wrote: > >>> > Below is a revision to the EMU charter that is intended to > >>> reflect the > >>> > discussions in the Philadelphia meeting. Please respond to > >>> the list > >>> > if you approve of the charter or if you have any comments > >>> on the charter. > >>> > I would like to have responses by 4/24. > >>> > > >>> > Thanks, > >>> >f > >>> > Joe > >>> > > >>> > Description of Working Group: > >>> > The Extensible Authentication Protocol (EAP) [RFC 3748] is > >>> a network > >>> > access authentication framework used in the PPP, 802.11, > >>> 802.16, VPN, > >>> > PANA, and in some functions in 3G networks. EAP itself is a simple > >>> > protocol and actual authentication happens in EAP methods. > >>> > > >>> > Over 40 different EAP methods exist. Most of these methods are > >>> > proprietary methods, but some are documented in > >>> informational RFCs. In > >>> > the past the lack of documented, open specifications has been a > >>> > deployment and interoperability problem. There are > >>> currently only two > >>> > EAP methods in the standards track that implement features > >>> such as key > >>> > derivation that are required for many modern applications. > >>> > Authentication types and credentials continue to evolve as do > >>> > requirements for EAP methods. > >>> > > >>> > This group is chartered to work on the following types of > >>> mechanisms > >>> > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements: > >>> > > >>> > - An update to RFC 2716 to bring EAP-TLS into standards > >>> track, clarify > >>> > specification, interoperability, and implementation issues gathered > >>> > over the years, and update the document to meet the requirements of > >>> > RFC 3748, RFC 4017, and EAP keying framework documents. Backwards > >>> > compatibility with RFC 2716 is a requirement. > >>> > > >>> > - A mechanism based on strong shared secrets. This mechanism should > >>> > strive to be simple and compact for implementation in resource > >>> > constrained environments. > >>> > > >>> > - A document that defines EAP channel bindings and provides > >>> guidance > >>> > for establishing EAP channel bindings within EAP methods. > >>> > > >>> > - A mechanism to support extensible communication within a TLS > >>> > protected tunnel. This mechanism must support channel bindings in > >>> > order to meet RFC 4962 requirements. This mechanism will support > >>> > meeting the requirements of an enhanced TLS mechanism, a password > >>> > based authentication mechanism, and additional inner authentication > >>> > mechanisms. > >>> > > >>> > - Enable a TLS-based EAP method to support channel > >>> bindings. This item > >>> > will not generate a new method, rather it will extend > >>> EAP-TLS and/or > >>> > the above tunnel method. > >>> > > >>> > - A mechanism that makes use of existing password databases such as > >>> > AAA databases. This item will be based on the above tunnel method. > >>> > > >>> > Goals and Milestones: > >>> > Done Form design team to work on strong shared secret > >>> > mechanism > >>> > Done Submit 2716bis I-D > >>> > Done Submit first draft of shared secret > >>> mechanism I-D > >>> > Done Form password based mechanism design team > >>> > Done Submit 2716bis draft to IESG for > >>> Proposed Standard > >>> > Apr 2008 Submit Strong Shared Secret Mechanism to IESG > >>> > May 2008 Submit Tunnel and Password Method requirements first > >>> > Draft > >>> > Sep 2008 Submit EAP Channel Bindings First Draft > >>> > Sep 2008 Submit Tunnel Method first draft > >>> > Oct 2008 Submit TLS based method channel binding first draft > >>> > Oct 2008 Submit Password Method first draft > >>> > Jan 2009 Send EAP Channel Bindings to IESG > >>> > Mar 2009 Send Tunnel Method to IESG > >>> > Apr 2009 Send TLS based method channel binding to IESG > >>> > Apr 2009 Send Password based method to IESG > >>> > _______________________________________________ > >>> > Emu mailing list > >>> > Emu@ietf.org > >>> > https://www.ietf.org/mailman/listinfo/emu > >>> > > >>> > >>> > >>> > >> > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 28 05:13:16 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976553A6E73; Mon, 28 Apr 2008 05:13:16 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C723A6E73 for ; Mon, 28 Apr 2008 05:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoAIuLZnH3ps for ; Mon, 28 Apr 2008 05:13:14 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dyn32-54.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 272DC3A6882 for ; Mon, 28 Apr 2008 05:13:14 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9D25529400F; Mon, 28 Apr 2008 15:13:16 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E536F294003 for ; Mon, 28 Apr 2008 15:13:15 +0300 (IDT) Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m3SCDEfU020709 for ; Mon, 28 Apr 2008 15:13:15 +0300 (IDT) Message-Id: From: Yoav Nir To: emu@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 28 Apr 2008 15:12:43 +0300 X-Mailer: Apple Mail (2.919.2) Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1532926025==" Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org --===============1532926025== Content-Type: multipart/alternative; boundary=Apple-Mail-5--850670193 --Apple-Mail-5--850670193 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Gene Chang said: > Dan, > I am not sure I am able to clearly understand the end result you seek. > It seems there is a clear consensus for a tunneled method. Are you > pushing for the addition of a tunneled method? > > Ok... I am easily baited. What would you like to see to achieve more > than a snail race? I am assuming we both believe the term "snail race" > is a pejorative. Thus I ask you, how do we do better? > > I clearly hear your comment that there have been a paucity of > comments, > if nothing else, simply to affirm we are on track. I agree with the > proposed charter. I am open to a discussion to add a non-tunneled > method > if there is sufficient demand. A non-tunneled method does not seem to > promise enough features for the use cases that interest me. > > Gene Hi Gene, You did not specify what the uses that interest you are, and I don't know about the use cases that interest Dan either, but I can speak for the use cases that interest me. EAP has been used in several cases as a magic way to use legacy credentials in protocols. I'll cite three examples: 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple, Cisco and others, where an EAP method is used to authenticate the user. 2. IKEv2 (RFC 4306) where EAP is used to magically authenticate the initiator using non-cert and non-PSK credentials. 3. TEE (draft-nir-tls-eap-03) where EAP is used to authenticate the user. In all three cases EAP is used by a protocol inside an encrypted tunnel, where the server, which is either trusted by the authenticator or co-located with it is already authenticated by a certificate or PSK. IMO EAP was used in all cases an some magical way of making passwords into a secure authentication mechanism. The problem is that there really is no publicly available EAP method for passwords. Tunneled methods don't really make sense here. There's no benefit in putting a TLS tunnel inside an IKEv2 exchange just to pass the password. Something like EAP-SRP would be great if it (a) existed and (b) didn't have all that IPR baggage. The method that Dan is proposing would also be beneficial here, if we could get a WG behind it so we can get some solid security review. Instead, what implementors are doing is EAP-MD5 or EAP-GTC, which don't quite meet the requirements for any of the above protocols. Yoav --Apple-Mail-5--850670193 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Gene Chang said:

is a pejorative. Thus I ask you, how do we do = better?

I clearly hear your comment that there have been a = paucity of comments,
if nothing else, simply to affirm we are on = track. I agree with the
proposed charter. I am open to a discussion = to add a non-tunneled method
if there is sufficient demand. A = non-tunneled method does not seem to
promise enough features for the = use cases that interest = me.

Gene

Hi = Gene,

You did not = specify what the uses that interest you are, and I don't know about the = use cases that interest Dan either, but I can speak for the use cases = that interest me.

EAP has been used = in several cases as a magic way to use legacy credentials in protocols. = I'll cite three examples:

1. L2TP/IPsec (RFC = 3193) as implemented by Microsoft, Apple, Cisco and others, where an EAP = method is used to authenticate the user.
2. IKEv2 (RFC = 4306) where EAP is used to magically authenticate the initiator using = non-cert and non-PSK credentials.
3. TEE = (draft-nir-tls-eap-03) where EAP is used to authenticate the = user.

In all three cases = EAP is used by a protocol inside an encrypted tunnel, where the server, = which is either trusted by the authenticator or co-located with it is = already authenticated by a certificate or PSK.  IMO EAP was used in = all cases an some magical way of making passwords into a secure = authentication mechanism.  The problem is that there really is no = publicly available EAP method for passwords.

Tunneled methods = don't really make sense here.  There's no benefit in putting a TLS = tunnel inside an IKEv2 exchange just to pass the password. Something = like EAP-SRP would be great if it (a) existed and (b) didn't have all = that IPR baggage. The method that Dan is proposing would also be = beneficial here, if we could get a WG behind it so we can get some solid = security review.  Instead, what implementors are doing is EAP-MD5 = or EAP-GTC, which don't quite meet the requirements for any of the above = protocols.

Yoav



= --Apple-Mail-5--850670193-- --===============1532926025== 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://www.ietf.org/mailman/listinfo/emu --===============1532926025==-- From emu-bounces@ietf.org Mon Apr 28 05:23:44 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B8228C288; Mon, 28 Apr 2008 05:23:44 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AFD28C1E7 for ; Mon, 28 Apr 2008 05:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtbprENPmpRx for ; Mon, 28 Apr 2008 05:23:42 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6053128C127 for ; Mon, 28 Apr 2008 05:23:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,716,1199682000"; d="scan'208,217";a="6546520" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2008 08:23:45 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3SCNj14007076; Mon, 28 Apr 2008 08:23:45 -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.13.8/8.13.8) with ESMTP id m3SCNjZI011604; Mon, 28 Apr 2008 12:23:45 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); Mon, 28 Apr 2008 08:23:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 08:23:42 -0400 Message-ID: <0F64770A6FD22C43AAA498C1E774ECC705A0DE80@xmb-rtp-208.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision Thread-Index: AcipKUPsTWG/xv5WTKWNjhQvcF7HjAAAFumw References: From: "Gene Chang (genchang)" To: "Yoav Nir" , X-OriginalArrivalTime: 28 Apr 2008 12:23:45.0185 (UTC) FILETIME=[B3E41910:01C8A92A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18169; t=1209385425; x=1210249425; 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]=20EMU=20charter=20revision |Sender:=20 |To:=20=22Yoav=20Nir=22=20,=20; bh=NSE0KBQ3h7G6dM4XjjLX0JLrI5NqCy0Nu4vLC1nWZaU=; b=0vqibF/FZ6aklPwLQ0Og+ITrVxR1FTWi7wM/RQDnN1Rez7K7q0uQ6zlwIp ZrP2RfDHLZPzfVIIVrv2o+HlaV618t0j17O/HJPY4L/QNls2sg48jl28A6Ho Fl5VB9txl2; Authentication-Results: rtp-dkim-2; header.From=genchang@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1843328952==" Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============1843328952== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A92A.B3A2B322" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A92A.B3A2B322 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yoav, I ask for some latitude in my choice of words to describe some of the use cases that interest me. It feels to me (possibly its must me being naive) that we are tip-toeing around the dual use of some EAP methods to support some interesting use cases. These use cases are out of scope for EMU. =20 Explicitly I am interested in both authentication which is in scope for EMU and NAC which is out of scope. The tunneled EAP methods, esp. EAP-FAST and EAP-TTLS, are used for both purposes. We can easily create methods that would only meet the needs of authentication and useless for NAC. I am not interested in spending efforts to such an outcome. =20 Gene =20 ------------------------------------------------------------------------ ---- Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 =20 =20 =20 ________________________________ From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Monday, April 28, 2008 8:13 AM To: emu@ietf.org Subject: Re: [Emu] EMU charter revision =20 Gene Chang said: =20 Dan, I am not sure I am able to clearly understand the end result you seek. It seems there is a clear consensus for a tunneled method. Are you pushing for the addition of a tunneled method?=20 =09 Ok... I am easily baited. What would you like to see to achieve more than a snail race? I am assuming we both believe the term "snail race" is a pejorative. Thus I ask you, how do we do better? =09 I clearly hear your comment that there have been a paucity of comments, if nothing else, simply to affirm we are on track. I agree with the proposed charter. I am open to a discussion to add a non-tunneled method if there is sufficient demand. A non-tunneled method does not seem to promise enough features for the use cases that interest me. =09 Gene =20 Hi Gene, =20 You did not specify what the uses that interest you are, and I don't know about the use cases that interest Dan either, but I can speak for the use cases that interest me. =20 EAP has been used in several cases as a magic way to use legacy credentials in protocols. I'll cite three examples: =20 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple, Cisco and others, where an EAP method is used to authenticate the user. 2. IKEv2 (RFC 4306) where EAP is used to magically authenticate the initiator using non-cert and non-PSK credentials. 3. TEE (draft-nir-tls-eap-03) where EAP is used to authenticate the user. =20 In all three cases EAP is used by a protocol inside an encrypted tunnel, where the server, which is either trusted by the authenticator or co-located with it is already authenticated by a certificate or PSK. IMO EAP was used in all cases an some magical way of making passwords into a secure authentication mechanism. The problem is that there really is no publicly available EAP method for passwords. =20 Tunneled methods don't really make sense here. There's no benefit in putting a TLS tunnel inside an IKEv2 exchange just to pass the password. Something like EAP-SRP would be great if it (a) existed and (b) didn't have all that IPR baggage. The method that Dan is proposing would also be beneficial here, if we could get a WG behind it so we can get some solid security review. Instead, what implementors are doing is EAP-MD5 or EAP-GTC, which don't quite meet the requirements for any of the above protocols. =20 Yoav =20 =20 =20 ------_=_NextPart_001_01C8A92A.B3A2B322 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yoav,

I ask for some latitude in my = choice of words to describe some of the use cases that interest me. It feels to me = (possibly its must me being naive) that we are tip-toeing around the dual use of = some EAP methods to support some interesting use cases. These use cases are out = of scope for EMU.

 

Explicitly I am interested in both authentication which is in scope for EMU and NAC which is out of scope. = The tunneled EAP methods, esp. EAP-FAST and EAP-TTLS, are used for both purposes. We = can easily create methods that would only meet the needs of authentication = and useless for NAC. I am not interested in spending efforts to such an = outcome.

 

Gene

 

------------------------------------= ----------------------------------------
Eugene Chang (genchang)
Cisco Systems

Office:   = 603-559-2978
Mobile:  781-799-0233

Skype:  = gene02421

 

=

 

=

 

From: = emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On = Behalf Of Yoav Nir
Sent: Monday, April 28, = 2008 8:13 AM
To: emu@ietf.org
Subject: Re: [Emu] EMU = charter revision

 

Gene Chang = said:

 

Dan,
I am not sure I am able to clearly = understand the end result you seek.
It seems there is a clear consensus for a = tunneled method. Are you
pushing for the addition of a tunneled = method? 

Ok... I am easily baited. What would you = like to see to achieve more
than a snail race? I am assuming we both = believe the term "snail race"
is a pejorative. Thus I ask you, how do = we do better?

I clearly hear your comment that there = have been a paucity of comments,
if nothing else, simply to affirm we are = on track. I agree with the
proposed charter. I am open to a = discussion to add a non-tunneled method
if there is sufficient demand. A = non-tunneled method does not seem to
promise enough features for the use cases = that interest me.

Gene

 

Hi = Gene,

 

You did not specify what the uses = that interest you are, and I don't know about the use cases that interest Dan either, but I can speak for the use cases that interest = me.

 

EAP has been used in several cases = as a magic way to use legacy credentials in protocols. I'll cite three = examples:

 

1. L2TP/IPsec (RFC 3193) as = implemented by Microsoft, Apple, Cisco and others, where an EAP method is used to authenticate the user.

2. IKEv2 (RFC 4306) where EAP is = used to magically authenticate the initiator using non-cert and non-PSK = credentials.

3. TEE (draft-nir-tls-eap-03) = where EAP is used to authenticate the user.

 

In all three cases EAP is used by = a protocol inside an encrypted tunnel, where the server, which is either = trusted by the authenticator or co-located with it is already authenticated by a certificate or PSK.  IMO EAP was used in all cases an some magical = way of making passwords into a secure authentication mechanism.  The = problem is that there really is no publicly available EAP method for = passwords.

 

Tunneled methods don't really make = sense here.  There's no benefit in putting a TLS tunnel inside an IKEv2 = exchange just to pass the password. Something like EAP-SRP would be great if it = (a) existed and (b) didn't have all that IPR baggage. The method that Dan is proposing would also be beneficial here, if we could get a WG behind it = so we can get some solid security review.  Instead, what implementors are = doing is EAP-MD5 or EAP-GTC, which don't quite meet the requirements for any = of the above protocols.

 

Yoav

 

 

 

------_=_NextPart_001_01C8A92A.B3A2B322-- --===============1843328952== 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://www.ietf.org/mailman/listinfo/emu --===============1843328952==-- From emu-bounces@ietf.org Mon Apr 28 08:09:59 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97023A6EA6; Mon, 28 Apr 2008 08:09:59 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1E13A6EA0 for ; Mon, 28 Apr 2008 08:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.714 X-Spam-Level: X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYx6zpgyJnpM for ; Mon, 28 Apr 2008 08:09:53 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7F2BC3A6E98 for ; Mon, 28 Apr 2008 08:09:53 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 Apr 2008 08:09:57 -0700 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 m3SF9v6W004384; Mon, 28 Apr 2008 08:09:57 -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.13.8/8.13.8) with ESMTP id m3SF9tg2009615; Mon, 28 Apr 2008 15:09:57 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); Mon, 28 Apr 2008 11:09:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 11:10:17 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B706D44AE9@xmb-rtp-212.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision Thread-Index: AcipKUQNwMjWqdxdRZOS45j+dAvK8AAF0Mfg References: From: "Hao Zhou (hzhou)" To: "Yoav Nir" , X-OriginalArrivalTime: 28 Apr 2008 15:09:56.0832 (UTC) FILETIME=[EB74AE00:01C8A941] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10648; t=1209395397; x=1210259397; c=relaxed/simple; s=sjdkim3002; 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]=20EMU=20charter=20revision |Sender:=20; bh=xi+dJTx3AAn1zBimefaaSrAsVvazawrHGVeXu0NgVjg=; b=dDyLySoeGAFqtVBH7dq6Udx/Pg8/A4oUxDqnlLWoz66jbre5krUPWun36W xICgmLUDb10X9SIOg685Y3lRtoIq52Bo7mmKI2UYEfmwAM0BrxH7UHD8Xm+f t6QxgbWs1V; Authentication-Results: sj-dkim-3; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0538925101==" Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============0538925101== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A941.EB41749F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A941.EB41749F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yoav: =20 I thought we had clear consensus in IETF 71 WG meeting and instructed by the AD that while Dan's proposal is an interesting one, but it doesn't work with the legacy password databases and thus out-of the scope of the charter. Until we have the proof of security analysis and clear of IPR issues, the WG is going to work on the tunnel method. I think this is the use case, legacy password database, the working group is currently working on and Gene is talking about =20 Can you also explain why in the three use case you cited, EAP-GTC or MD5 doesn't meet the requirements, as they are all running inside an authenticated and encrypted tunnel? ________________________________ From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Monday, April 28, 2008 8:13 AM To: emu@ietf.org Subject: Re: [Emu] EMU charter revision =09 =09 Gene Chang said:=20 =09 =09 =09 Dan, I am not sure I am able to clearly understand the end result you seek. It seems there is a clear consensus for a tunneled method. Are you pushing for the addition of a tunneled method?=20 =09 Ok... I am easily baited. What would you like to see to achieve more than a snail race? I am assuming we both believe the term "snail race" is a pejorative. Thus I ask you, how do we do better? =09 I clearly hear your comment that there have been a paucity of comments, if nothing else, simply to affirm we are on track. I agree with the proposed charter. I am open to a discussion to add a non-tunneled method if there is sufficient demand. A non-tunneled method does not seem to promise enough features for the use cases that interest me. =09 Gene =09 =09 Hi Gene, =09 =09 You did not specify what the uses that interest you are, and I don't know about the use cases that interest Dan either, but I can speak for the use cases that interest me. =09 =09 EAP has been used in several cases as a magic way to use legacy credentials in protocols. I'll cite three examples: =09 =09 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple, Cisco and others, where an EAP method is used to authenticate the user. 2. IKEv2 (RFC 4306) where EAP is used to magically authenticate the initiator using non-cert and non-PSK credentials. 3. TEE (draft-nir-tls-eap-03) where EAP is used to authenticate the user. =09 =09 In all three cases EAP is used by a protocol inside an encrypted tunnel, where the server, which is either trusted by the authenticator or co-located with it is already authenticated by a certificate or PSK. IMO EAP was used in all cases an some magical way of making passwords into a secure authentication mechanism. The problem is that there really is no publicly available EAP method for passwords. =09 =09 Tunneled methods don't really make sense here. There's no benefit in putting a TLS tunnel inside an IKEv2 exchange just to pass the password. Something like EAP-SRP would be great if it (a) existed and (b) didn't have all that IPR baggage. The method that Dan is proposing would also be beneficial here, if we could get a WG behind it so we can get some solid security review. Instead, what implementors are doing is EAP-MD5 or EAP-GTC, which don't quite meet the requirements for any of the above protocols. =09 =09 Yoav =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C8A941.EB41749F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yoav:
 
I thought we had clear consensus in IETF 71 = WG meeting=20 and instructed by the AD that while Dan's proposal is an interesting = one, but it=20 doesn't work with the legacy password databases and thus out-of the = scope of the=20 charter. Until we have the proof of security analysis and = clear=20 of IPR issues, the WG is going to work on the tunnel method. I = think this=20 is the use case, legacy password database, the working group is = currently=20 working on and Gene is talking about
 
Can you also explain why in the three use = case you=20 cited, EAP-GTC or MD5 doesn't meet the requirements, as they are all = running=20 inside an authenticated and encrypted tunnel?

From: emu-bounces@ietf.org=20 [mailto:emu-bounces@ietf.org] On Behalf Of Yoav = Nir
Sent:=20 Monday, April 28, 2008 8:13 AM
To: = emu@ietf.org
Subject:=20 Re: [Emu] EMU charter revision

Gene Chang said:

Dan,
I am not sure I am = able to=20 clearly understand the end result you seek.
It seems there is a = clear=20 consensus for a tunneled method. Are you
pushing for the addition = of a=20 tunneled method? 

Ok... I am easily baited. What would = you like=20 to see to achieve more
than a snail race? I am assuming we both = believe=20 the term "snail race"
is a pejorative. Thus I ask you, how do we = do=20 better?

I clearly hear your comment that there have been a = paucity of=20 comments,
if nothing else, simply to affirm we are on track. I = agree with=20 the
proposed charter. I am open to a discussion to add a = non-tunneled=20 method
if there is sufficient demand. A non-tunneled method does = not seem=20 to
promise enough features for the use cases that interest=20 me.

Gene

Hi = Gene,

You did = not specify=20 what the uses that interest you are, and I don't know about the use = cases that=20 interest Dan either, but I can speak for the use cases that interest=20 me.

EAP has = been used in=20 several cases as a magic way to use legacy credentials in protocols. = I'll cite=20 three examples:

1. = L2TP/IPsec (RFC=20 3193) as implemented by Microsoft, Apple, Cisco and others, where an = EAP=20 method is used to authenticate the user.
2. IKEv2 = (RFC 4306)=20 where EAP is used to magically authenticate the initiator using = non-cert and=20 non-PSK credentials.
3. TEE=20 (draft-nir-tls-eap-03) where EAP is used to authenticate the=20 user.

In all = three cases=20 EAP is used by a protocol inside an encrypted tunnel, where the = server, which=20 is either trusted by the authenticator or co-located with it is = already=20 authenticated by a certificate or PSK.  IMO EAP was used in all = cases an=20 some magical way of making passwords into a secure authentication = mechanism.=20  The problem is that there really is no publicly available EAP = method for=20 passwords.

Tunneled = methods=20 don't really make sense here.  There's no benefit in putting a = TLS tunnel=20 inside an IKEv2 exchange just to pass the password. Something like = EAP-SRP=20 would be great if it (a) existed and (b) didn't have all that IPR = baggage. The=20 method that Dan is proposing would also be beneficial here, if we = could get a=20 WG behind it so we can get some solid security review.  Instead, = what=20 implementors are doing is EAP-MD5 or EAP-GTC, which don't quite meet = the=20 requirements for any of the above protocols.

Yoav



------_=_NextPart_001_01C8A941.EB41749F-- --===============0538925101== 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://www.ietf.org/mailman/listinfo/emu --===============0538925101==-- From emu-bounces@ietf.org Mon Apr 28 09:04:45 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06DA73A6EA6; Mon, 28 Apr 2008 09:04:45 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681283A6EB0 for ; Mon, 28 Apr 2008 09:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQboLxlG9fRW for ; Mon, 28 Apr 2008 09:04:42 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 12A553A6EA6 for ; Mon, 28 Apr 2008 09:04:42 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BCC8D10224072; Mon, 28 Apr 2008 09:04:45 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 28 Apr 2008 09:04:45 -0700 (PDT) Message-ID: <47545e966f21dad7572e13ba63ea5acf.squirrel@www.trepanning.net> In-Reply-To: <0F64770A6FD22C43AAA498C1E774ECC705A0DE55@xmb-rtp-208.amer.cisco.com> References: <966f2c824f7a17d84f138a2ee956328e.squirrel@www.trepanning.net><089d20b64295debabe49c740e696c052.squirrel@www.trepanning.net> <1150ac8bbb9ea8ae59b35181d7adf578.squirrel@www.trepanning.net> <0F64770A6FD22C43AAA498C1E774ECC705A0DE55@xmb-rtp-208.amer.cisco.com> Date: Mon, 28 Apr 2008 09:04:45 -0700 (PDT) From: "Dan Harkins" To: "Gene Chang (genchang)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Hi Gene, I'm not pushing a tunneled method. We have enough of those and their differences are not so great. Yes, I was using "snail race" as a pejorative. As I said at the last IETF we should have a cage-match-cum-beauty-contest between TTLS and FAST, turn the last RFC text of the winner into a -00 EMU draft, add the channel bindings stuff that was discussed back in Vancouver and then publish. Apparently this working group can work on nothing except a tunneled method. And that work is being done at a snail's pace. I'm glad to hear that you're open to a discussion of adding a non- tunneled method "if there is sufficient demand", but you see we have this long-standing consensus and the mere mention of anything that remotely sounds like a non-tunneled method gets stifled with "consensus!" So apparently we're not allowed to have that discussion. At least until we finish work on a tunneled method. Dan. On Mon, April 28, 2008 3:35 am, Gene Chang (genchang) wrote: > Dan, > I am not sure I am able to clearly understand the end result you seek. > It seems there is a clear consensus for a tunneled method. Are you > pushing for the addition of a tunneled method? > > Ok... I am easily baited. What would you like to see to achieve more > than a snail race? I am assuming we both believe the term "snail race" > is a pejorative. Thus I ask you, how do we do better? > > I clearly hear your comment that there have been a paucity of comments, > if nothing else, simply to affirm we are on track. I agree with the > proposed charter. I am open to a discussion to add a non-tunneled method > if there is sufficient demand. A non-tunneled method does not seem to > promise enough features for the use cases that interest me. > > Gene > > ------------------------------------------------------------------------ > ---- > Eugene Chang (genchang) > Cisco Systems > Office: 603-559-2978 > Mobile: 781-799-0233 > Skype: gene02421 > > > > >> -----Original Message----- >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Dan >> Harkins >> Sent: Monday, April 28, 2008 2:12 AM >> To: Stephen Hanna >> Cc: emu@ietf.org >> Subject: Re: [Emu] EMU charter revision >> >> >> That's true. One person's opinion does not negate consensus, >> even if that one person is the only one who is able to opine >> in the alloted time given for opinions (twice now). But so what? >> If someone asks then I'll give an honest opinion, especially >> since no one else seems to be able to. >> >> But maybe you're right. Any additional work taken on by this >> group would distract from the fantastic progress we've made in the >> past 9 months on the tunneled method. It would be a shame to lose >> all that. Yes, let's just focus on the snail race.... >> >> Dan. >> >> On Sun, April 27, 2008 6:10 pm, Stephen Hanna wrote: >> > I apologize for my tardy response. I have been on vacation. >> > >> > I agree with and support the proposed charter below. As for >> > Dan's suggestion that we not require the password based >> > method to be based on the tunnel method, the WG already >> > went through a long discussion and consensus check last >> > fall on this matter. There was clear consensus that we >> > should NOT work on a new password based method designed >> > to function without the tunnel method. One person's >> > opinion to the contrary does not negate that consensus. >> > I think that the reason we are not seeing much email on >> > this charter is that the issues and language have been >> > hashed through many times. >> > >> > Thanks, >> > >> > Steve >> > >> > -----Original Message----- >> > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf > Of >> > Dan Harkins >> > Sent: Friday, April 25, 2008 5:43 PM >> > To: Joseph Salowey (jsalowey) >> > Cc: emu@ietf.org >> > Subject: Re: [Emu] EMU charter revision >> > >> > >> > Hi Joe, >> > >> > Once again, a call for comments and I'm the only one to comment. >> > >> > Whether removing that line achieves "my goals" or not I still > think >> > it should be removed. And that really seems to be the only comment >> > on the charter you get when you ask. >> > >> > regards, >> > >> > Dan. >> > >> > On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) wrote: >> >> >> >> >> >>> -----Original Message----- >> >>> From: Dan Harkins [mailto:dharkins@lounge.org] >> >>> Sent: Friday, April 11, 2008 10:38 AM >> >>> To: Joseph Salowey (jsalowey) >> >>> Cc: emu@ietf.org >> >>> Subject: Re: [Emu] EMU charter revision >> >>> >> >>> >> >>> Hi Joe, >> >>> >> >>> Thank you for giving me the opportunity to object, once >> >>> again, to the last sentence in the last item in the charter. >> >>> If you were to run the following sed filter on the charter I >> >>> would approve: >> >>> >> >>> s/This item will be based on the above tunnel method.// >> >>> >> >> >> >> [Joe] I do not think that removing this line would achieve the goal >> > you >> >> wish. With this line removed EAP-PWD is still out of scope of the >> >> charter as it does not meet the requirements of supporting legacy >> >> password databases. The message from the ADs in the last meeting > was >> >> pretty clear in that EAP-PWD style mechanisms is not something for > the >> >> group to take on right now. This does not mean that we cannot take > on >> >> an EAP-PWD style mechanism once we have made progress on the > current >> >> charter items. >> >> >> >>> What is the process here? This looks the same as the >> >>> charter revision you made a consensus call on back in >> >>> January. I was the only one to opine before your cutoff last >> >>> time and my comment was the same as above. Now we're doing this >> > again. >> >>> >> >> [Joe] There have been several revisions posted to the list and >> > feedback >> >> from several working group members that have been worked into the > new >> >> proposal along with input from the discussion in the last meeting. > If >> >> enough people respond positively, such that we have rough > consensus, >> >> then we can move forward. >> >> >> >> >> >>> Dan. >> >>> >> >>> On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) wrote: >> >>> > Below is a revision to the EMU charter that is intended to >> >>> reflect the >> >>> > discussions in the Philadelphia meeting. Please respond to >> >>> the list >> >>> > if you approve of the charter or if you have any comments >> >>> on the charter. >> >>> > I would like to have responses by 4/24. >> >>> > >> >>> > Thanks, >> >>> >f >> >>> > Joe >> >>> > >> >>> > Description of Working Group: >> >>> > The Extensible Authentication Protocol (EAP) [RFC 3748] is >> >>> a network >> >>> > access authentication framework used in the PPP, 802.11, >> >>> 802.16, VPN, >> >>> > PANA, and in some functions in 3G networks. EAP itself is a > simple >> >>> > protocol and actual authentication happens in EAP methods. >> >>> > >> >>> > Over 40 different EAP methods exist. Most of these methods are >> >>> > proprietary methods, but some are documented in >> >>> informational RFCs. In >> >>> > the past the lack of documented, open specifications has been a >> >>> > deployment and interoperability problem. There are >> >>> currently only two >> >>> > EAP methods in the standards track that implement features >> >>> such as key >> >>> > derivation that are required for many modern applications. >> >>> > Authentication types and credentials continue to evolve as do >> >>> > requirements for EAP methods. >> >>> > >> >>> > This group is chartered to work on the following types of >> >>> mechanisms >> >>> > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying > requirements: >> >>> > >> >>> > - An update to RFC 2716 to bring EAP-TLS into standards >> >>> track, clarify >> >>> > specification, interoperability, and implementation issues > gathered >> >>> > over the years, and update the document to meet the requirements > of >> >>> > RFC 3748, RFC 4017, and EAP keying framework documents. > Backwards >> >>> > compatibility with RFC 2716 is a requirement. >> >>> > >> >>> > - A mechanism based on strong shared secrets. This mechanism > should >> >>> > strive to be simple and compact for implementation in resource >> >>> > constrained environments. >> >>> > >> >>> > - A document that defines EAP channel bindings and provides >> >>> guidance >> >>> > for establishing EAP channel bindings within EAP methods. >> >>> > >> >>> > - A mechanism to support extensible communication within a TLS >> >>> > protected tunnel. This mechanism must support channel bindings > in >> >>> > order to meet RFC 4962 requirements. This mechanism will support >> >>> > meeting the requirements of an enhanced TLS mechanism, a > password >> >>> > based authentication mechanism, and additional inner > authentication >> >>> > mechanisms. >> >>> > >> >>> > - Enable a TLS-based EAP method to support channel >> >>> bindings. This item >> >>> > will not generate a new method, rather it will extend >> >>> EAP-TLS and/or >> >>> > the above tunnel method. >> >>> > >> >>> > - A mechanism that makes use of existing password databases such > as >> >>> > AAA databases. This item will be based on the above tunnel > method. >> >>> > >> >>> > Goals and Milestones: >> >>> > Done Form design team to work on strong shared secret >> >>> > mechanism >> >>> > Done Submit 2716bis I-D >> >>> > Done Submit first draft of shared secret >> >>> mechanism I-D >> >>> > Done Form password based mechanism design team >> >>> > Done Submit 2716bis draft to IESG for >> >>> Proposed Standard >> >>> > Apr 2008 Submit Strong Shared Secret Mechanism to IESG >> >>> > May 2008 Submit Tunnel and Password Method requirements > first >> >>> > Draft >> >>> > Sep 2008 Submit EAP Channel Bindings First Draft >> >>> > Sep 2008 Submit Tunnel Method first draft >> >>> > Oct 2008 Submit TLS based method channel binding first > draft >> >>> > Oct 2008 Submit Password Method first draft >> >>> > Jan 2009 Send EAP Channel Bindings to IESG >> >>> > Mar 2009 Send Tunnel Method to IESG >> >>> > Apr 2009 Send TLS based method channel binding to IESG >> >>> > Apr 2009 Send Password based method to IESG >> >>> > _______________________________________________ >> >>> > Emu mailing list >> >>> > Emu@ietf.org >> >>> > https://www.ietf.org/mailman/listinfo/emu >> >>> > >> >>> >> >>> >> >>> >> >> >> > >> > >> > _______________________________________________ >> > Emu mailing list >> > Emu@ietf.org >> > https://www.ietf.org/mailman/listinfo/emu >> > >> >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 28 09:45:08 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9864628C24E; Mon, 28 Apr 2008 09:45:08 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF29C3A6AB1 for ; Mon, 28 Apr 2008 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3j68TmDj6QP for ; Mon, 28 Apr 2008 09:45:04 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id CE6D23A6959 for ; Mon, 28 Apr 2008 09:45:04 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 846F010224072; Mon, 28 Apr 2008 09:45:08 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 28 Apr 2008 09:45:08 -0700 (PDT) Message-ID: In-Reply-To: <9958B444368E884DBB215F3FEF36F5B706D44AE9@xmb-rtp-212.amer.cisco.com> References: <9958B444368E884DBB215F3FEF36F5B706D44AE9@xmb-rtp-212.amer.cisco.com> Date: Mon, 28 Apr 2008 09:45:08 -0700 (PDT) From: "Dan Harkins" To: "Hao Zhou (hzhou)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: Yoav Nir , emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Hold on a second there Hao. A security proof was never a requirement. I'm not aware of any other IETF protocols that required security proofs or even have security proofs. There is no formal proof required of the tunneled methods and I think it would be very difficult to do one. One of the problems with the tunneled solution is the "consistency principle" described in Hugo Krawczyk's SIGMA paper. The tunneled methods violate that security requirement. And the fact that these things can be repeatedly tunneled ad nauseum amplifies that violation. A use case? Surely you have noticed the friction between usability and security. Security needs bootstrapping of some sort and typically that is problematic for many people especially when they need to bootstrap a large number of distinct security associations. So they cut corners. How are these corners cut? "Do not verify server certificate". That's why that little check box exists. Because people don't want to enroll everybody/everything into a CA. So they use a self-signed certificate and check the "Do not verify server certificate" check box. And then they send a password over this "encrypted tunnel". So the use case is robust security that cannot be provisioned insecurely. It's scalable and doesn't require the cutting of corners by administrators who are too busy (or frankly lazy) to do it the Correct Way. I have used the "it's their network and if they aren't so concerned about security then who am I to force a workload on them" comments in the past but it really is disingenuous. There are frightfully many deployments of password-authentication-through- encrypted-TLS-tunnel that use self-signed certificates and then something analogous to PAP. And they are done that way because there isn't a viable standard alternative. That is the use case for EAP-pwd. Oh, and it can satisfy the "consistency principle" too. :-) Dan. On Mon, April 28, 2008 8:10 am, Hao Zhou (hzhou) wrote: > Yoav: > > I thought we had clear consensus in IETF 71 WG meeting and instructed by > the AD that while Dan's proposal is an interesting one, but it doesn't > work with the legacy password databases and thus out-of the scope of the > charter. Until we have the proof of security analysis and clear of IPR > issues, the WG is going to work on the tunnel method. I think this is > the use case, legacy password database, the working group is currently > working on and Gene is talking about > > Can you also explain why in the three use case you cited, EAP-GTC or MD5 > doesn't meet the requirements, as they are all running inside an > authenticated and encrypted tunnel? > > > ________________________________ > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > Behalf Of Yoav Nir > Sent: Monday, April 28, 2008 8:13 AM > To: emu@ietf.org > Subject: Re: [Emu] EMU charter revision > > > Gene Chang said: > > > > > Dan, > I am not sure I am able to clearly understand the end > result you seek. > It seems there is a clear consensus for a tunneled > method. Are you > pushing for the addition of a tunneled method? > > Ok... I am easily baited. What would you like to see to > achieve more > than a snail race? I am assuming we both believe the > term "snail race" > is a pejorative. Thus I ask you, how do we do better? > > I clearly hear your comment that there have been a > paucity of comments, > if nothing else, simply to affirm we are on track. I > agree with the > proposed charter. I am open to a discussion to add a > non-tunneled method > if there is sufficient demand. A non-tunneled method > does not seem to > promise enough features for the use cases that interest > me. > > Gene > > > > Hi Gene, > > > You did not specify what the uses that interest you are, and I > don't know about the use cases that interest Dan either, but I can speak > for the use cases that interest me. > > > EAP has been used in several cases as a magic way to use legacy > credentials in protocols. I'll cite three examples: > > > 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple, > Cisco and others, where an EAP method is used to authenticate the user. > 2. IKEv2 (RFC 4306) where EAP is used to magically authenticate > the initiator using non-cert and non-PSK credentials. > 3. TEE (draft-nir-tls-eap-03) where EAP is used to authenticate > the user. > > > In all three cases EAP is used by a protocol inside an encrypted > tunnel, where the server, which is either trusted by the authenticator > or co-located with it is already authenticated by a certificate or PSK. > IMO EAP was used in all cases an some magical way of making passwords > into a secure authentication mechanism. The problem is that there > really is no publicly available EAP method for passwords. > > > Tunneled methods don't really make sense here. There's no > benefit in putting a TLS tunnel inside an IKEv2 exchange just to pass > the password. Something like EAP-SRP would be great if it (a) existed > and (b) didn't have all that IPR baggage. The method that Dan is > proposing would also be beneficial here, if we could get a WG behind it > so we can get some solid security review. Instead, what implementors > are doing is EAP-MD5 or EAP-GTC, which don't quite meet the requirements > for any of the above protocols. > > > Yoav > > > > > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 28 10:33:28 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D7A28C2F7; Mon, 28 Apr 2008 10:33:28 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E71128C2DF for ; Mon, 28 Apr 2008 10:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtHWTKLD4p+h for ; Mon, 28 Apr 2008 10:33:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 43D9328C30F for ; Mon, 28 Apr 2008 10:31:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,717,1199692800"; d="scan'208";a="24209750" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 28 Apr 2008 10:31:56 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3SHVuak003420; Mon, 28 Apr 2008 10:31:56 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m3SHVsr0021816; Mon, 28 Apr 2008 17:31:55 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); Mon, 28 Apr 2008 13:31:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 13:32:14 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B706D44C42@xmb-rtp-212.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision Thread-Index: AcipT0lp4ROJjO28QC+cHcWc38ec3AABPsPg References: <9958B444368E884DBB215F3FEF36F5B706D44AE9@xmb-rtp-212.amer.cisco.com> From: "Hao Zhou (hzhou)" To: "Dan Harkins" X-OriginalArrivalTime: 28 Apr 2008 17:31:54.0772 (UTC) FILETIME=[C08B2D40:01C8A955] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7425; t=1209403916; x=1210267916; c=relaxed/simple; s=sjdkim1004; 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]=20EMU=20charter=20revision |Sender:=20; bh=pGT2ehYApaY6hEq8MTbVI7WdzQNTc3vWTK9KXx7wx1E=; b=BRK3P8csaXuEj66rmEXfkcd9AH3upT6IRMFr2b2Jzg/b3fcgR0N7Q/VXjP i13EmVJKV1fuN61h5Joqitx5ZW/nIi6EP8YnR9MCjVLjJcolPt+CK/DiqU0T T8h9/9dOZiMmelXsVHmiucGmhr7wtzHrIQ7plcpF2vfye0VPYfGTg=; Authentication-Results: sj-dkim-1; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Yoav Nir , emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Dan: Now you have changed to argue that tunnel method is not the right solution for the use case EMU is targeted on, instead of arguing your proposed password should be included as addition to the tunnel method. I thought working on and standardizing the tunnel method is the WG consensus for few IETF meetings now, are you going to challenge that now? Maybe this also contributes to the "snail race" of tunnel method. As for the password method you proposed, I was at the last IETF meeting and you can also verify from he meeting minutes. The consensus is to have more security reviews and the IPR analysis. Also, since the use case it targeted maybe more broader than the EMU WG, it was suggested to bring up in SAAG as well, as multiple WGs can benefit from it. But the direction from the AD is to finish existing work first. Why are we keeping bring this up? > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Monday, April 28, 2008 12:45 PM > To: Hao Zhou (hzhou) > Cc: Yoav Nir; emu@ietf.org > Subject: Re: [Emu] EMU charter revision > > > Hold on a second there Hao. A security proof was never a > requirement. > I'm not aware of any other IETF protocols that required > security proofs or even have security proofs. There is no > formal proof required of the tunneled methods and I think it > would be very difficult to do one. > > One of the problems with the tunneled solution is the > "consistency principle" described in Hugo Krawczyk's SIGMA > paper. The tunneled methods violate that security > requirement. And the fact that these things can be repeatedly > tunneled ad nauseum amplifies that violation. > > A use case? Surely you have noticed the friction between > usability and security. Security needs bootstrapping of some > sort and typically that is problematic for many people > especially when they need to bootstrap a large number of > distinct security associations. So they cut corners. > > How are these corners cut? "Do not verify server > certificate". That's why that little check box exists. > Because people don't want to enroll everybody/everything into > a CA. So they use a self-signed certificate and check the "Do > not verify server certificate" check box. And then they send > a password over this "encrypted tunnel". > > So the use case is robust security that cannot be > provisioned insecurely. > It's scalable and doesn't require the cutting of corners by > administrators who are too busy (or frankly lazy) to do it > the Correct Way. I have used the "it's their network and if > they aren't so concerned about security then who am I to > force a workload on them" comments in the past but it really > is disingenuous. > > There are frightfully many deployments of > password-authentication-through- encrypted-TLS-tunnel that > use self-signed certificates and then something analogous to > PAP. And they are done that way because there isn't a viable > standard alternative. That is the use case for EAP-pwd. Oh, > and it can satisfy the "consistency principle" too. :-) > > Dan. > > On Mon, April 28, 2008 8:10 am, Hao Zhou (hzhou) wrote: > > Yoav: > > > > I thought we had clear consensus in IETF 71 WG meeting and > instructed > > by the AD that while Dan's proposal is an interesting one, but it > > doesn't work with the legacy password databases and thus out-of the > > scope of the charter. Until we have the proof of security > analysis and > > clear of IPR issues, the WG is going to work on the tunnel > method. I > > think this is the use case, legacy password database, the working > > group is currently working on and Gene is talking about > > > > Can you also explain why in the three use case you cited, > EAP-GTC or > > MD5 doesn't meet the requirements, as they are all running > inside an > > authenticated and encrypted tunnel? > > > > > > ________________________________ > > > > From: emu-bounces@ietf.org > [mailto:emu-bounces@ietf.org] On Behalf Of > > Yoav Nir > > Sent: Monday, April 28, 2008 8:13 AM > > To: emu@ietf.org > > Subject: Re: [Emu] EMU charter revision > > > > > > Gene Chang said: > > > > > > > > > > Dan, > > I am not sure I am able to clearly understand > the end result you > > seek. > > It seems there is a clear consensus for a > tunneled method. Are you > > pushing for the addition of a tunneled method? > > > > Ok... I am easily baited. What would you like > to see to achieve more > > than a snail race? I am assuming we both > believe the term "snail > > race" > > is a pejorative. Thus I ask you, how do we do better? > > > > I clearly hear your comment that there have > been a paucity of > > comments, > > if nothing else, simply to affirm we are on > track. I agree with the > > proposed charter. I am open to a discussion to > add a non-tunneled > > method > > if there is sufficient demand. A non-tunneled > method does not seem > > to > > promise enough features for the use cases that > interest me. > > > > Gene > > > > > > > > Hi Gene, > > > > > > You did not specify what the uses that interest you > are, and I don't > > know about the use cases that interest Dan either, but I > can speak for > > the use cases that interest me. > > > > > > EAP has been used in several cases as a magic way to use legacy > > credentials in protocols. I'll cite three examples: > > > > > > 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, > Apple, Cisco > > and others, where an EAP method is used to authenticate the user. > > 2. IKEv2 (RFC 4306) where EAP is used to magically > authenticate the > > initiator using non-cert and non-PSK credentials. > > 3. TEE (draft-nir-tls-eap-03) where EAP is used to > authenticate the > > user. > > > > > > In all three cases EAP is used by a protocol inside an > encrypted > > tunnel, where the server, which is either trusted by the > authenticator > > or co-located with it is already authenticated by a > certificate or PSK. > > IMO EAP was used in all cases an some magical way of making > passwords > > into a secure authentication mechanism. The problem is that there > > really is no publicly available EAP method for passwords. > > > > > > Tunneled methods don't really make sense here. There's > no benefit in > > putting a TLS tunnel inside an IKEv2 exchange just to pass the > > password. Something like EAP-SRP would be great if it (a) > existed and > > (b) didn't have all that IPR baggage. The method that Dan > is proposing > > would also be beneficial here, if we could get a WG behind it so we > > can get some solid security review. Instead, what implementors are > > doing is EAP-MD5 or EAP-GTC, which don't quite meet the > requirements > > for any of the above protocols. > > > > > > Yoav > > > > > > > > > > > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 28 11:27:04 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64FAC3A6C1D; Mon, 28 Apr 2008 11:27:04 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1FF28C15B for ; Mon, 28 Apr 2008 11:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5PQOELOU0gy for ; Mon, 28 Apr 2008 11:26:59 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 27D903A6859 for ; Mon, 28 Apr 2008 11:26:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,717,1199692800"; d="scan'208";a="24232873" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 28 Apr 2008 11:26:49 -0700 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 m3SIQnlI015700; Mon, 28 Apr 2008 11:26:49 -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.13.8/8.13.8) with ESMTP id m3SIQje0016526; Mon, 28 Apr 2008 18:26:49 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); Mon, 28 Apr 2008 14:26:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 14:26:47 -0400 Message-ID: <0F64770A6FD22C43AAA498C1E774ECC705A0E1C5@xmb-rtp-208.amer.cisco.com> In-Reply-To: <47545e966f21dad7572e13ba63ea5acf.squirrel@www.trepanning.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision Thread-Index: AcipSZzKQJ69HSflTgCgstGlTLfobAAEOaOQ References: <966f2c824f7a17d84f138a2ee956328e.squirrel@www.trepanning.net><089d20b64295debabe49c740e696c052.squirrel@www.trepanning.net> <1150ac8bbb9ea8ae59b35181d7adf578.squirrel@www.trepanning.net> <0F64770A6FD22C43AAA498C1E774ECC705A0DE55@xmb-rtp-208.amer.cisco.com> <47545e966f21dad7572e13ba63ea5acf.squirrel@www.trepanning.net> From: "Gene Chang (genchang)" To: "Dan Harkins" X-OriginalArrivalTime: 28 Apr 2008 18:26:48.0910 (UTC) FILETIME=[6C00BEE0:01C8A95D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13508; t=1209407209; x=1210271209; 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]=20EMU=20charter=20revision |Sender:=20; bh=jGpPX8bsMO2jTKwxkTaA2jiQIchSRrcQpeb8L71m5Q8=; b=ea/9Tox6fhHt88KUlq/zv6Z3VIfNE+lyWB3ZIhyU+zEQtfOX57tOS2igFZ MHCO4NSHEt/l2f/olJxDbmyBkajJaQsrHhWYvVg/yeVHL8ycfFXDLc2t02Aj kc5ya9owoc; Authentication-Results: sj-dkim-2; header.From=genchang@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Dan, I think we can all appreciate the entertainment value of bringing a reality show to the IETF. Imagine replacing the IETF social with an arena full of hyped up Internet engineers enjoying a night fellowship with beer and trash talk. Unfortunately, all we are doing is dressing up a down select with two 4-5 year old protocols that do not completely meet the requirements document that is being assembled. We aren't doing the industry a favor freezing the protocol choice to technology ca. 2004. If you are in such a rush, why not simply declare victory and have a tie. That enshrines the status quo. Picking one over the other won't change the status quo and thus won't change the deployment preference already established. Better for the industry would be a foot race where the candidate protocol that meets the requirements document and gains 10 million devices protected would win the standards title. This would advance the technology to cover the missing requirements and significantly grow adoption. Let's focus our efforts on moving the technology forward instead searching for an entertaining down select. I really don't see your sense of urgency. I don't see an adoption window that we are going to miss with the current effort. Yet, I can be really excited pushing to meet the needs of a critical adoption window. I would like to see things progress faster but not at the expense of a weak technical outcome. Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Monday, April 28, 2008 12:05 PM > To: Gene Chang (genchang) > Cc: Dan Harkins; Stephen Hanna; emu@ietf.org > Subject: RE: [Emu] EMU charter revision > > > Hi Gene, > > I'm not pushing a tunneled method. We have enough of those and their > differences are not so great. > > Yes, I was using "snail race" as a pejorative. As I said at the last > IETF we should have a cage-match-cum-beauty-contest between TTLS and > FAST, turn the last RFC text of the winner into a -00 EMU draft, add the > channel bindings stuff that was discussed back in Vancouver and then > publish. Apparently this working group can work on nothing except > a tunneled method. And that work is being done at a snail's pace. > > I'm glad to hear that you're open to a discussion of adding a non- > tunneled method "if there is sufficient demand", but you see we have this > long-standing consensus and the mere mention of anything that remotely > sounds like a non-tunneled method gets stifled with "consensus!" So > apparently we're not allowed to have that discussion. At least until we > finish work on a tunneled method. > > Dan. > > On Mon, April 28, 2008 3:35 am, Gene Chang (genchang) wrote: > > Dan, > > I am not sure I am able to clearly understand the end result you seek. > > It seems there is a clear consensus for a tunneled method. Are you > > pushing for the addition of a tunneled method? > > > > Ok... I am easily baited. What would you like to see to achieve more > > than a snail race? I am assuming we both believe the term "snail race" > > is a pejorative. Thus I ask you, how do we do better? > > > > I clearly hear your comment that there have been a paucity of comments, > > if nothing else, simply to affirm we are on track. I agree with the > > proposed charter. I am open to a discussion to add a non-tunneled method > > if there is sufficient demand. A non-tunneled method does not seem to > > promise enough features for the use cases that interest me. > > > > Gene > > > > ------------------------------------------------------------------------ > > ---- > > Eugene Chang (genchang) > > Cisco Systems > > Office: 603-559-2978 > > Mobile: 781-799-0233 > > Skype: gene02421 > > > > > > > > > >> -----Original Message----- > >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > > Dan > >> Harkins > >> Sent: Monday, April 28, 2008 2:12 AM > >> To: Stephen Hanna > >> Cc: emu@ietf.org > >> Subject: Re: [Emu] EMU charter revision > >> > >> > >> That's true. One person's opinion does not negate consensus, > >> even if that one person is the only one who is able to opine > >> in the alloted time given for opinions (twice now). But so what? > >> If someone asks then I'll give an honest opinion, especially > >> since no one else seems to be able to. > >> > >> But maybe you're right. Any additional work taken on by this > >> group would distract from the fantastic progress we've made in the > >> past 9 months on the tunneled method. It would be a shame to lose > >> all that. Yes, let's just focus on the snail race.... > >> > >> Dan. > >> > >> On Sun, April 27, 2008 6:10 pm, Stephen Hanna wrote: > >> > I apologize for my tardy response. I have been on vacation. > >> > > >> > I agree with and support the proposed charter below. As for > >> > Dan's suggestion that we not require the password based > >> > method to be based on the tunnel method, the WG already > >> > went through a long discussion and consensus check last > >> > fall on this matter. There was clear consensus that we > >> > should NOT work on a new password based method designed > >> > to function without the tunnel method. One person's > >> > opinion to the contrary does not negate that consensus. > >> > I think that the reason we are not seeing much email on > >> > this charter is that the issues and language have been > >> > hashed through many times. > >> > > >> > Thanks, > >> > > >> > Steve > >> > > >> > -----Original Message----- > >> > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf > > Of > >> > Dan Harkins > >> > Sent: Friday, April 25, 2008 5:43 PM > >> > To: Joseph Salowey (jsalowey) > >> > Cc: emu@ietf.org > >> > Subject: Re: [Emu] EMU charter revision > >> > > >> > > >> > Hi Joe, > >> > > >> > Once again, a call for comments and I'm the only one to comment. > >> > > >> > Whether removing that line achieves "my goals" or not I still > > think > >> > it should be removed. And that really seems to be the only comment > >> > on the charter you get when you ask. > >> > > >> > regards, > >> > > >> > Dan. > >> > > >> > On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) wrote: > >> >> > >> >> > >> >>> -----Original Message----- > >> >>> From: Dan Harkins [mailto:dharkins@lounge.org] > >> >>> Sent: Friday, April 11, 2008 10:38 AM > >> >>> To: Joseph Salowey (jsalowey) > >> >>> Cc: emu@ietf.org > >> >>> Subject: Re: [Emu] EMU charter revision > >> >>> > >> >>> > >> >>> Hi Joe, > >> >>> > >> >>> Thank you for giving me the opportunity to object, once > >> >>> again, to the last sentence in the last item in the charter. > >> >>> If you were to run the following sed filter on the charter I > >> >>> would approve: > >> >>> > >> >>> s/This item will be based on the above tunnel method.// > >> >>> > >> >> > >> >> [Joe] I do not think that removing this line would achieve the goal > >> > you > >> >> wish. With this line removed EAP-PWD is still out of scope of the > >> >> charter as it does not meet the requirements of supporting legacy > >> >> password databases. The message from the ADs in the last meeting > > was > >> >> pretty clear in that EAP-PWD style mechanisms is not something for > > the > >> >> group to take on right now. This does not mean that we cannot take > > on > >> >> an EAP-PWD style mechanism once we have made progress on the > > current > >> >> charter items. > >> >> > >> >>> What is the process here? This looks the same as the > >> >>> charter revision you made a consensus call on back in > >> >>> January. I was the only one to opine before your cutoff last > >> >>> time and my comment was the same as above. Now we're doing this > >> > again. > >> >>> > >> >> [Joe] There have been several revisions posted to the list and > >> > feedback > >> >> from several working group members that have been worked into the > > new > >> >> proposal along with input from the discussion in the last meeting. > > If > >> >> enough people respond positively, such that we have rough > > consensus, > >> >> then we can move forward. > >> >> > >> >> > >> >>> Dan. > >> >>> > >> >>> On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) wrote: > >> >>> > Below is a revision to the EMU charter that is intended to > >> >>> reflect the > >> >>> > discussions in the Philadelphia meeting. Please respond to > >> >>> the list > >> >>> > if you approve of the charter or if you have any comments > >> >>> on the charter. > >> >>> > I would like to have responses by 4/24. > >> >>> > > >> >>> > Thanks, > >> >>> >f > >> >>> > Joe > >> >>> > > >> >>> > Description of Working Group: > >> >>> > The Extensible Authentication Protocol (EAP) [RFC 3748] is > >> >>> a network > >> >>> > access authentication framework used in the PPP, 802.11, > >> >>> 802.16, VPN, > >> >>> > PANA, and in some functions in 3G networks. EAP itself is a > > simple > >> >>> > protocol and actual authentication happens in EAP methods. > >> >>> > > >> >>> > Over 40 different EAP methods exist. Most of these methods are > >> >>> > proprietary methods, but some are documented in > >> >>> informational RFCs. In > >> >>> > the past the lack of documented, open specifications has been a > >> >>> > deployment and interoperability problem. There are > >> >>> currently only two > >> >>> > EAP methods in the standards track that implement features > >> >>> such as key > >> >>> > derivation that are required for many modern applications. > >> >>> > Authentication types and credentials continue to evolve as do > >> >>> > requirements for EAP methods. > >> >>> > > >> >>> > This group is chartered to work on the following types of > >> >>> mechanisms > >> >>> > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying > > requirements: > >> >>> > > >> >>> > - An update to RFC 2716 to bring EAP-TLS into standards > >> >>> track, clarify > >> >>> > specification, interoperability, and implementation issues > > gathered > >> >>> > over the years, and update the document to meet the requirements > > of > >> >>> > RFC 3748, RFC 4017, and EAP keying framework documents. > > Backwards > >> >>> > compatibility with RFC 2716 is a requirement. > >> >>> > > >> >>> > - A mechanism based on strong shared secrets. This mechanism > > should > >> >>> > strive to be simple and compact for implementation in resource > >> >>> > constrained environments. > >> >>> > > >> >>> > - A document that defines EAP channel bindings and provides > >> >>> guidance > >> >>> > for establishing EAP channel bindings within EAP methods. > >> >>> > > >> >>> > - A mechanism to support extensible communication within a TLS > >> >>> > protected tunnel. This mechanism must support channel bindings > > in > >> >>> > order to meet RFC 4962 requirements. This mechanism will support > >> >>> > meeting the requirements of an enhanced TLS mechanism, a > > password > >> >>> > based authentication mechanism, and additional inner > > authentication > >> >>> > mechanisms. > >> >>> > > >> >>> > - Enable a TLS-based EAP method to support channel > >> >>> bindings. This item > >> >>> > will not generate a new method, rather it will extend > >> >>> EAP-TLS and/or > >> >>> > the above tunnel method. > >> >>> > > >> >>> > - A mechanism that makes use of existing password databases such > > as > >> >>> > AAA databases. This item will be based on the above tunnel > > method. > >> >>> > > >> >>> > Goals and Milestones: > >> >>> > Done Form design team to work on strong shared secret > >> >>> > mechanism > >> >>> > Done Submit 2716bis I-D > >> >>> > Done Submit first draft of shared secret > >> >>> mechanism I-D > >> >>> > Done Form password based mechanism design team > >> >>> > Done Submit 2716bis draft to IESG for > >> >>> Proposed Standard > >> >>> > Apr 2008 Submit Strong Shared Secret Mechanism to IESG > >> >>> > May 2008 Submit Tunnel and Password Method requirements > > first > >> >>> > Draft > >> >>> > Sep 2008 Submit EAP Channel Bindings First Draft > >> >>> > Sep 2008 Submit Tunnel Method first draft > >> >>> > Oct 2008 Submit TLS based method channel binding first > > draft > >> >>> > Oct 2008 Submit Password Method first draft > >> >>> > Jan 2009 Send EAP Channel Bindings to IESG > >> >>> > Mar 2009 Send Tunnel Method to IESG > >> >>> > Apr 2009 Send TLS based method channel binding to IESG > >> >>> > Apr 2009 Send Password based method to IESG > >> >>> > _______________________________________________ > >> >>> > Emu mailing list > >> >>> > Emu@ietf.org > >> >>> > https://www.ietf.org/mailman/listinfo/emu > >> >>> > > >> >>> > >> >>> > >> >>> > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Emu mailing list > >> > Emu@ietf.org > >> > https://www.ietf.org/mailman/listinfo/emu > >> > > >> > >> > >> _______________________________________________ > >> Emu mailing list > >> Emu@ietf.org > >> https://www.ietf.org/mailman/listinfo/emu > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 28 11:35:36 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A8E28C290; Mon, 28 Apr 2008 11:35:36 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4873628C290 for ; Mon, 28 Apr 2008 11:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnLlCeJj9HYh for ; Mon, 28 Apr 2008 11:35:34 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id ED19328C251 for ; Mon, 28 Apr 2008 11:35:33 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6F55810224072; Mon, 28 Apr 2008 11:35:37 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 28 Apr 2008 11:35:37 -0700 (PDT) Message-ID: <3060f5984089b9927367f4d8bec80071.squirrel@www.trepanning.net> In-Reply-To: <9958B444368E884DBB215F3FEF36F5B706D44C42@xmb-rtp-212.amer.cisco.com> References: <9958B444368E884DBB215F3FEF36F5B706D44AE9@xmb-rtp-212.amer.cisco.com> <9958B444368E884DBB215F3FEF36F5B706D44C42@xmb-rtp-212.amer.cisco.com> Date: Mon, 28 Apr 2008 11:35:37 -0700 (PDT) From: "Dan Harkins" To: "Hao Zhou (hzhou)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: Yoav Nir , emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Hao, On Mon, April 28, 2008 10:32 am, Hao Zhou (hzhou) wrote: > Dan: > > Now you have changed to argue that tunnel method is not the right > solution for the use case EMU is targeted on, instead of arguing your > proposed password should be included as addition to the tunnel method. I > thought working on and standardizing the tunnel method is the WG > consensus for few IETF meetings now, are you going to challenge that > now? Maybe this also contributes to the "snail race" of tunnel method. It is the consensus. I'm not challenging consensus, just answering a question. "Do you approve of this charter?" Well, no I don't. I was told by the ADs that EAP-pwd is outside the current charter. Fine. We can't work on it but that doesn't mean I approve of the charter; I don't, for that very reason. If I'm asked again I'll give the same answer again. Don't blame me for the pace of the work in this WG. I don't have a stake in the outcome of the only thing we're allowed to work on. And I don't believe a quarterly email saying "I don't approve" (of the charter) is enough to put those who do have a stake in the outcome off their work schedules. > As for the password method you proposed, I was at the last IETF meeting > and you can also verify from he meeting minutes. The consensus is to > have more security reviews and the IPR analysis. Also, since the use > case it targeted maybe more broader than the EMU WG, it was suggested to > bring up in SAAG as well, as multiple WGs can benefit from it. But the > direction from the AD is to finish existing work first. Yes, I remember. But you said, "Until we have a proof...we will work on the tunneled method." IPR issues, yes that will probably hold things up. But a proof, no. No proof is required prior to adoption as a work item. If it was then where's the security proof for either tunneled method? The real thing holding up adoption of EAP-pwd as a work item is finishing work on the tunneled method. Which wouldn't be such a bad thing if we were further along towards that goal after Philly than we were after Vancouver and from the looks of it we won't be any further after Dublin than we were after Vancouver. :-( > Why are we keeping bring this up? You asked why are tunneled GTC and tunneled MD5 not OK; you asked what is the use case for EAP-pwd. I answered both: consistency principle and a need for robustness, respectively. Dan. >> -----Original Message----- >> From: Dan Harkins [mailto:dharkins@lounge.org] >> Sent: Monday, April 28, 2008 12:45 PM >> To: Hao Zhou (hzhou) >> Cc: Yoav Nir; emu@ietf.org >> Subject: Re: [Emu] EMU charter revision >> >> >> Hold on a second there Hao. A security proof was never a >> requirement. >> I'm not aware of any other IETF protocols that required >> security proofs or even have security proofs. There is no >> formal proof required of the tunneled methods and I think it >> would be very difficult to do one. >> >> One of the problems with the tunneled solution is the >> "consistency principle" described in Hugo Krawczyk's SIGMA >> paper. The tunneled methods violate that security >> requirement. And the fact that these things can be repeatedly >> tunneled ad nauseum amplifies that violation. >> >> A use case? Surely you have noticed the friction between >> usability and security. Security needs bootstrapping of some >> sort and typically that is problematic for many people >> especially when they need to bootstrap a large number of >> distinct security associations. So they cut corners. >> >> How are these corners cut? "Do not verify server >> certificate". That's why that little check box exists. >> Because people don't want to enroll everybody/everything into >> a CA. So they use a self-signed certificate and check the "Do >> not verify server certificate" check box. And then they send >> a password over this "encrypted tunnel". >> >> So the use case is robust security that cannot be >> provisioned insecurely. >> It's scalable and doesn't require the cutting of corners by >> administrators who are too busy (or frankly lazy) to do it >> the Correct Way. I have used the "it's their network and if >> they aren't so concerned about security then who am I to >> force a workload on them" comments in the past but it really >> is disingenuous. >> >> There are frightfully many deployments of >> password-authentication-through- encrypted-TLS-tunnel that >> use self-signed certificates and then something analogous to >> PAP. And they are done that way because there isn't a viable >> standard alternative. That is the use case for EAP-pwd. Oh, >> and it can satisfy the "consistency principle" too. :-) >> >> Dan. >> >> On Mon, April 28, 2008 8:10 am, Hao Zhou (hzhou) wrote: >> > Yoav: >> > >> > I thought we had clear consensus in IETF 71 WG meeting and >> instructed >> > by the AD that while Dan's proposal is an interesting one, but it >> > doesn't work with the legacy password databases and thus out-of the >> > scope of the charter. Until we have the proof of security >> analysis and >> > clear of IPR issues, the WG is going to work on the tunnel >> method. I >> > think this is the use case, legacy password database, the working >> > group is currently working on and Gene is talking about >> > >> > Can you also explain why in the three use case you cited, >> EAP-GTC or >> > MD5 doesn't meet the requirements, as they are all running >> inside an >> > authenticated and encrypted tunnel? >> > >> > >> > ________________________________ >> > >> > From: emu-bounces@ietf.org >> [mailto:emu-bounces@ietf.org] On Behalf Of >> > Yoav Nir >> > Sent: Monday, April 28, 2008 8:13 AM >> > To: emu@ietf.org >> > Subject: Re: [Emu] EMU charter revision >> > >> > >> > Gene Chang said: >> > >> > >> > >> > >> > Dan, >> > I am not sure I am able to clearly understand >> the end result you >> > seek. >> > It seems there is a clear consensus for a >> tunneled method. Are you >> > pushing for the addition of a tunneled method? >> > >> > Ok... I am easily baited. What would you like >> to see to achieve more >> > than a snail race? I am assuming we both >> believe the term "snail >> > race" >> > is a pejorative. Thus I ask you, how do we do better? >> > >> > I clearly hear your comment that there have >> been a paucity of >> > comments, >> > if nothing else, simply to affirm we are on >> track. I agree with the >> > proposed charter. I am open to a discussion to >> add a non-tunneled >> > method >> > if there is sufficient demand. A non-tunneled >> method does not seem >> > to >> > promise enough features for the use cases that >> interest me. >> > >> > Gene >> > >> > >> > >> > Hi Gene, >> > >> > >> > You did not specify what the uses that interest you >> are, and I don't >> > know about the use cases that interest Dan either, but I >> can speak for >> > the use cases that interest me. >> > >> > >> > EAP has been used in several cases as a magic way to use legacy >> > credentials in protocols. I'll cite three examples: >> > >> > >> > 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, >> Apple, Cisco >> > and others, where an EAP method is used to authenticate the user. >> > 2. IKEv2 (RFC 4306) where EAP is used to magically >> authenticate the >> > initiator using non-cert and non-PSK credentials. >> > 3. TEE (draft-nir-tls-eap-03) where EAP is used to >> authenticate the >> > user. >> > >> > >> > In all three cases EAP is used by a protocol inside an >> encrypted >> > tunnel, where the server, which is either trusted by the >> authenticator >> > or co-located with it is already authenticated by a >> certificate or PSK. >> > IMO EAP was used in all cases an some magical way of making >> passwords >> > into a secure authentication mechanism. The problem is that there >> > really is no publicly available EAP method for passwords. >> > >> > >> > Tunneled methods don't really make sense here. There's >> no benefit in >> > putting a TLS tunnel inside an IKEv2 exchange just to pass the >> > password. Something like EAP-SRP would be great if it (a) >> existed and >> > (b) didn't have all that IPR baggage. The method that Dan >> is proposing >> > would also be beneficial here, if we could get a WG behind it so we >> > can get some solid security review. Instead, what implementors are >> > doing is EAP-MD5 or EAP-GTC, which don't quite meet the >> requirements >> > for any of the above protocols. >> > >> > >> > Yoav >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Emu mailing list >> > Emu@ietf.org >> > https://www.ietf.org/mailman/listinfo/emu >> > >> >> >> > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 28 11:40:49 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C2B28C2EB; Mon, 28 Apr 2008 11:40:49 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109F428C2E5 for ; Mon, 28 Apr 2008 11:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.47 X-Spam-Level: X-Spam-Status: No, score=-5.47 tagged_above=-999 required=5 tests=[AWL=1.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGC-zdY48uoE for ; Mon, 28 Apr 2008 11:40:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2BC9628C2EB for ; Mon, 28 Apr 2008 11:40:40 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2008 11:40:43 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3SIeh1F022092; Mon, 28 Apr 2008 11:40:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3SIeZ4B026398; Mon, 28 Apr 2008 18:40:43 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); Mon, 28 Apr 2008 11:40:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 11:41:33 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision Thread-Index: AcipKUOQ2s7bO/u/R1ywqNbrbL6p8QAInKiw References: From: "Joseph Salowey (jsalowey)" To: "Yoav Nir" , X-OriginalArrivalTime: 28 Apr 2008 18:40:43.0504 (UTC) FILETIME=[5D75AF00:01C8A95F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3499; t=1209408043; x=1210272043; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20EMU=20charter=20revision |Sender:=20; bh=2kukrhuXZVqEX1uBbpgWiUOOmdjqJiVmW06qrr9XH0U=; b=tzvr5HjunGWy7aBmkzCMakab+uMS3i7GAYJy3xLCH+3UIQo/T93HlJP8Mc d5mQIpf+5kqVsDiMQ+YWrb7qy9eyg87TXw2TLnQlQzSewbsBhVJ+51o1Wf0E nl6xBl0Lu9; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Hi Yoav, You bring up an interesting point in discussing the need for EAP password based authentication within other protected protocols. If this is targeted at working with legacy databases then I think it can be accommodated under the current charter. An EAP protected tunnel is required for some deployments, however perhaps the tunneled password protocol can be designed to be used in other cases (IKEv2, TLS, etc.) if the group wants to take this direction. What do you see lacking in something like EAP-GTC? Cheers, Joe > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > Behalf Of Yoav Nir > Sent: Monday, April 28, 2008 5:13 AM > To: emu@ietf.org > Subject: Re: [Emu] EMU charter revision > > Gene Chang said: > > > > Dan, > I am not sure I am able to clearly understand the end > result you seek. > It seems there is a clear consensus for a tunneled > method. Are you > pushing for the addition of a tunneled method? > > Ok... I am easily baited. What would you like to see to > achieve more > than a snail race? I am assuming we both believe the > term "snail race" > is a pejorative. Thus I ask you, how do we do better? > > I clearly hear your comment that there have been a > paucity of comments, > if nothing else, simply to affirm we are on track. I > agree with the > proposed charter. I am open to a discussion to add a > non-tunneled method > if there is sufficient demand. A non-tunneled method > does not seem to > promise enough features for the use cases that interest me. > > Gene > > > > Hi Gene, > > > You did not specify what the uses that interest you are, and > I don't know about the use cases that interest Dan either, > but I can speak for the use cases that interest me. > > > EAP has been used in several cases as a magic way to use > legacy credentials in protocols. I'll cite three examples: > > > 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple, > Cisco and others, where an EAP method is used to authenticate > the user. > 2. IKEv2 (RFC 4306) where EAP is used to magically > authenticate the initiator using non-cert and non-PSK credentials. > 3. TEE (draft-nir-tls-eap-03) where EAP is used to > authenticate the user. > > > In all three cases EAP is used by a protocol inside an > encrypted tunnel, where the server, which is either trusted > by the authenticator or co-located with it is already > authenticated by a certificate or PSK. IMO EAP was used in > all cases an some magical way of making passwords into a > secure authentication mechanism. The problem is that there > really is no publicly available EAP method for passwords. > > > Tunneled methods don't really make sense here. There's no > benefit in putting a TLS tunnel inside an IKEv2 exchange just > to pass the password. Something like EAP-SRP would be great > if it (a) existed and (b) didn't have all that IPR baggage. > The method that Dan is proposing would also be beneficial > here, if we could get a WG behind it so we can get some solid > security review. Instead, what implementors are doing is > EAP-MD5 or EAP-GTC, which don't quite meet the requirements > for any of the above protocols. > > > Yoav > > > > > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 28 12:22:14 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D013A6A35; Mon, 28 Apr 2008 12:22:14 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2A33A69E6 for ; Mon, 28 Apr 2008 12:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEWQmcdqWhET for ; Mon, 28 Apr 2008 12:22:05 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 5C13B28C291 for ; Mon, 28 Apr 2008 12:22:01 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0BA9810224072; Mon, 28 Apr 2008 12:22:05 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 28 Apr 2008 12:22:05 -0700 (PDT) Message-ID: In-Reply-To: <0F64770A6FD22C43AAA498C1E774ECC705A0E1C5@xmb-rtp-208.amer.cisco.com> References: <966f2c824f7a17d84f138a2ee956328e.squirrel@www.trepanning.net><089d20b64295debabe49c740e696c052.squirrel@www.trepanning.net> <1150ac8bbb9ea8ae59b35181d7adf578.squirrel@www.trepanning.net> <0F64770A6FD22C43AAA498C1E774ECC705A0DE55@xmb-rtp-208.amer.cisco.com> <47545e966f21dad7572e13ba63ea5acf.squirrel@www.trepanning.net> <0F64770A6FD22C43AAA498C1E774ECC705A0E1C5@xmb-rtp-208.amer.cisco.com> Date: Mon, 28 Apr 2008 12:22:05 -0700 (PDT) From: "Dan Harkins" To: "Gene Chang (genchang)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Gene, I don't think anyone would find an EMU reality show entertaining. The only comic relief would be one crazy guy who, once every 4 months, pokes his head in the window and says "I do not approve" to people sitting around watching paint dry. You are restating Stephen's comment from Philly that I'm more interested in the cage match than in the coronation of the winner. That is not true but it is also irrelevant. I actually don't care who wins or how much blood is let, I just want it to be over. It would really be an abuse of process to hold up all other work while each side crunches numbers and pays analysts to run surveys so that someone can claim to have reached an arbitrary 10M mark. And it would not be a service to anybody. So what we have is argument over the wording of "requirements" so that they will subtly favor one side over the other. Then we create a "requirements" document that captures all the carefully constructed verbage. And while that's getting advanced we then argue over which candidate best matches the customized wording of the "requirements". And then we finally get down to the work of actually changing one of the specifications to add channel binding. And this must all be done serially. Sigh. Both FAST and TTLS are equally amenable to modification and their differences are not so great or we'd have had a clear "winner" already. No matter which one gets selected we will not end up with a weak solution. You don't see my sense of urgency because what you view as interesting work is not being held up. Dan. On Mon, April 28, 2008 11:26 am, Gene Chang (genchang) wrote: > Dan, > > I think we can all appreciate the entertainment value of bringing a > reality show to the IETF. Imagine replacing the IETF social with an > arena full of hyped up Internet engineers enjoying a night fellowship > with beer and trash talk. > > Unfortunately, all we are doing is dressing up a down select with two > 4-5 year old protocols that do not completely meet the requirements > document that is being assembled. We aren't doing the industry a favor > freezing the protocol choice to technology ca. 2004. > > If you are in such a rush, why not simply declare victory and have a > tie. That enshrines the status quo. Picking one over the other won't > change the status quo and thus won't change the deployment preference > already established. > > Better for the industry would be a foot race where the candidate > protocol that meets the requirements document and gains 10 million > devices protected would win the standards title. This would advance the > technology to cover the missing requirements and significantly grow > adoption. > > Let's focus our efforts on moving the technology forward instead > searching for an entertaining down select. > > I really don't see your sense of urgency. I don't see an adoption window > that we are going to miss with the current effort. Yet, I can be really > excited pushing to meet the needs of a critical adoption window. > > I would like to see things progress faster but not at the expense of a > weak technical outcome. > > Gene > > ------------------------------------------------------------------------ > ---- > Eugene Chang (genchang) > Cisco Systems > Office: 603-559-2978 > Mobile: 781-799-0233 > Skype: gene02421 > > > >> -----Original Message----- >> From: Dan Harkins [mailto:dharkins@lounge.org] >> Sent: Monday, April 28, 2008 12:05 PM >> To: Gene Chang (genchang) >> Cc: Dan Harkins; Stephen Hanna; emu@ietf.org >> Subject: RE: [Emu] EMU charter revision >> >> >> Hi Gene, >> >> I'm not pushing a tunneled method. We have enough of those and their >> differences are not so great. >> >> Yes, I was using "snail race" as a pejorative. As I said at the last >> IETF we should have a cage-match-cum-beauty-contest between TTLS and >> FAST, turn the last RFC text of the winner into a -00 EMU draft, add > the >> channel bindings stuff that was discussed back in Vancouver and then >> publish. Apparently this working group can work on nothing except >> a tunneled method. And that work is being done at a snail's pace. >> >> I'm glad to hear that you're open to a discussion of adding a non- >> tunneled method "if there is sufficient demand", but you see we have > this >> long-standing consensus and the mere mention of anything that remotely >> sounds like a non-tunneled method gets stifled with "consensus!" So >> apparently we're not allowed to have that discussion. At least until > we >> finish work on a tunneled method. >> >> Dan. >> >> On Mon, April 28, 2008 3:35 am, Gene Chang (genchang) wrote: >> > Dan, >> > I am not sure I am able to clearly understand the end result you > seek. >> > It seems there is a clear consensus for a tunneled method. Are you >> > pushing for the addition of a tunneled method? >> > >> > Ok... I am easily baited. What would you like to see to achieve more >> > than a snail race? I am assuming we both believe the term "snail > race" >> > is a pejorative. Thus I ask you, how do we do better? >> > >> > I clearly hear your comment that there have been a paucity of > comments, >> > if nothing else, simply to affirm we are on track. I agree with the >> > proposed charter. I am open to a discussion to add a non-tunneled > method >> > if there is sufficient demand. A non-tunneled method does not seem > to >> > promise enough features for the use cases that interest me. >> > >> > Gene >> > >> > > ------------------------------------------------------------------------ >> > ---- >> > Eugene Chang (genchang) >> > Cisco Systems >> > Office: 603-559-2978 >> > Mobile: 781-799-0233 >> > Skype: gene02421 >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf > Of >> > Dan >> >> Harkins >> >> Sent: Monday, April 28, 2008 2:12 AM >> >> To: Stephen Hanna >> >> Cc: emu@ietf.org >> >> Subject: Re: [Emu] EMU charter revision >> >> >> >> >> >> That's true. One person's opinion does not negate consensus, >> >> even if that one person is the only one who is able to opine >> >> in the alloted time given for opinions (twice now). But so what? >> >> If someone asks then I'll give an honest opinion, especially >> >> since no one else seems to be able to. >> >> >> >> But maybe you're right. Any additional work taken on by this >> >> group would distract from the fantastic progress we've made in the >> >> past 9 months on the tunneled method. It would be a shame to lose >> >> all that. Yes, let's just focus on the snail race.... >> >> >> >> Dan. >> >> >> >> On Sun, April 27, 2008 6:10 pm, Stephen Hanna wrote: >> >> > I apologize for my tardy response. I have been on vacation. >> >> > >> >> > I agree with and support the proposed charter below. As for >> >> > Dan's suggestion that we not require the password based >> >> > method to be based on the tunnel method, the WG already >> >> > went through a long discussion and consensus check last >> >> > fall on this matter. There was clear consensus that we >> >> > should NOT work on a new password based method designed >> >> > to function without the tunnel method. One person's >> >> > opinion to the contrary does not negate that consensus. >> >> > I think that the reason we are not seeing much email on >> >> > this charter is that the issues and language have been >> >> > hashed through many times. >> >> > >> >> > Thanks, >> >> > >> >> > Steve >> >> > >> >> > -----Original Message----- >> >> > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > Behalf >> > Of >> >> > Dan Harkins >> >> > Sent: Friday, April 25, 2008 5:43 PM >> >> > To: Joseph Salowey (jsalowey) >> >> > Cc: emu@ietf.org >> >> > Subject: Re: [Emu] EMU charter revision >> >> > >> >> > >> >> > Hi Joe, >> >> > >> >> > Once again, a call for comments and I'm the only one to > comment. >> >> > >> >> > Whether removing that line achieves "my goals" or not I still >> > think >> >> > it should be removed. And that really seems to be the only > comment >> >> > on the charter you get when you ask. >> >> > >> >> > regards, >> >> > >> >> > Dan. >> >> > >> >> > On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) wrote: >> >> >> >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: Dan Harkins [mailto:dharkins@lounge.org] >> >> >>> Sent: Friday, April 11, 2008 10:38 AM >> >> >>> To: Joseph Salowey (jsalowey) >> >> >>> Cc: emu@ietf.org >> >> >>> Subject: Re: [Emu] EMU charter revision >> >> >>> >> >> >>> >> >> >>> Hi Joe, >> >> >>> >> >> >>> Thank you for giving me the opportunity to object, once >> >> >>> again, to the last sentence in the last item in the charter. >> >> >>> If you were to run the following sed filter on the charter I >> >> >>> would approve: >> >> >>> >> >> >>> s/This item will be based on the above tunnel method.// >> >> >>> >> >> >> >> >> >> [Joe] I do not think that removing this line would achieve the > goal >> >> > you >> >> >> wish. With this line removed EAP-PWD is still out of scope of > the >> >> >> charter as it does not meet the requirements of supporting > legacy >> >> >> password databases. The message from the ADs in the last > meeting >> > was >> >> >> pretty clear in that EAP-PWD style mechanisms is not something > for >> > the >> >> >> group to take on right now. This does not mean that we cannot > take >> > on >> >> >> an EAP-PWD style mechanism once we have made progress on the >> > current >> >> >> charter items. >> >> >> >> >> >>> What is the process here? This looks the same as the >> >> >>> charter revision you made a consensus call on back in >> >> >>> January. I was the only one to opine before your cutoff last >> >> >>> time and my comment was the same as above. Now we're doing this >> >> > again. >> >> >>> >> >> >> [Joe] There have been several revisions posted to the list and >> >> > feedback >> >> >> from several working group members that have been worked into > the >> > new >> >> >> proposal along with input from the discussion in the last > meeting. >> > If >> >> >> enough people respond positively, such that we have rough >> > consensus, >> >> >> then we can move forward. >> >> >> >> >> >> >> >> >>> Dan. >> >> >>> >> >> >>> On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) > wrote: >> >> >>> > Below is a revision to the EMU charter that is intended to >> >> >>> reflect the >> >> >>> > discussions in the Philadelphia meeting. Please respond to >> >> >>> the list >> >> >>> > if you approve of the charter or if you have any comments >> >> >>> on the charter. >> >> >>> > I would like to have responses by 4/24. >> >> >>> > >> >> >>> > Thanks, >> >> >>> >f >> >> >>> > Joe >> >> >>> > >> >> >>> > Description of Working Group: >> >> >>> > The Extensible Authentication Protocol (EAP) [RFC 3748] is >> >> >>> a network >> >> >>> > access authentication framework used in the PPP, 802.11, >> >> >>> 802.16, VPN, >> >> >>> > PANA, and in some functions in 3G networks. EAP itself is a >> > simple >> >> >>> > protocol and actual authentication happens in EAP methods. >> >> >>> > >> >> >>> > Over 40 different EAP methods exist. Most of these methods > are >> >> >>> > proprietary methods, but some are documented in >> >> >>> informational RFCs. In >> >> >>> > the past the lack of documented, open specifications has been > a >> >> >>> > deployment and interoperability problem. There are >> >> >>> currently only two >> >> >>> > EAP methods in the standards track that implement features >> >> >>> such as key >> >> >>> > derivation that are required for many modern applications. >> >> >>> > Authentication types and credentials continue to evolve as do >> >> >>> > requirements for EAP methods. >> >> >>> > >> >> >>> > This group is chartered to work on the following types of >> >> >>> mechanisms >> >> >>> > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying >> > requirements: >> >> >>> > >> >> >>> > - An update to RFC 2716 to bring EAP-TLS into standards >> >> >>> track, clarify >> >> >>> > specification, interoperability, and implementation issues >> > gathered >> >> >>> > over the years, and update the document to meet the > requirements >> > of >> >> >>> > RFC 3748, RFC 4017, and EAP keying framework documents. >> > Backwards >> >> >>> > compatibility with RFC 2716 is a requirement. >> >> >>> > >> >> >>> > - A mechanism based on strong shared secrets. This mechanism >> > should >> >> >>> > strive to be simple and compact for implementation in > resource >> >> >>> > constrained environments. >> >> >>> > >> >> >>> > - A document that defines EAP channel bindings and provides >> >> >>> guidance >> >> >>> > for establishing EAP channel bindings within EAP methods. >> >> >>> > >> >> >>> > - A mechanism to support extensible communication within a > TLS >> >> >>> > protected tunnel. This mechanism must support channel > bindings >> > in >> >> >>> > order to meet RFC 4962 requirements. This mechanism will > support >> >> >>> > meeting the requirements of an enhanced TLS mechanism, a >> > password >> >> >>> > based authentication mechanism, and additional inner >> > authentication >> >> >>> > mechanisms. >> >> >>> > >> >> >>> > - Enable a TLS-based EAP method to support channel >> >> >>> bindings. This item >> >> >>> > will not generate a new method, rather it will extend >> >> >>> EAP-TLS and/or >> >> >>> > the above tunnel method. >> >> >>> > >> >> >>> > - A mechanism that makes use of existing password databases > such >> > as >> >> >>> > AAA databases. This item will be based on the above tunnel >> > method. >> >> >>> > >> >> >>> > Goals and Milestones: >> >> >>> > Done Form design team to work on strong shared secret >> >> >>> > mechanism >> >> >>> > Done Submit 2716bis I-D >> >> >>> > Done Submit first draft of shared secret >> >> >>> mechanism I-D >> >> >>> > Done Form password based mechanism design team >> >> >>> > Done Submit 2716bis draft to IESG for >> >> >>> Proposed Standard >> >> >>> > Apr 2008 Submit Strong Shared Secret Mechanism to IESG >> >> >>> > May 2008 Submit Tunnel and Password Method requirements >> > first >> >> >>> > Draft >> >> >>> > Sep 2008 Submit EAP Channel Bindings First Draft >> >> >>> > Sep 2008 Submit Tunnel Method first draft >> >> >>> > Oct 2008 Submit TLS based method channel binding first >> > draft >> >> >>> > Oct 2008 Submit Password Method first draft >> >> >>> > Jan 2009 Send EAP Channel Bindings to IESG >> >> >>> > Mar 2009 Send Tunnel Method to IESG >> >> >>> > Apr 2009 Send TLS based method channel binding to IESG >> >> >>> > Apr 2009 Send Password based method to IESG >> >> >>> > _______________________________________________ >> >> >>> > Emu mailing list >> >> >>> > Emu@ietf.org >> >> >>> > https://www.ietf.org/mailman/listinfo/emu >> >> >>> > >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> > >> >> > >> >> > _______________________________________________ >> >> > Emu mailing list >> >> > Emu@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/emu >> >> > >> >> >> >> >> >> _______________________________________________ >> >> Emu mailing list >> >> Emu@ietf.org >> >> https://www.ietf.org/mailman/listinfo/emu >> > >> > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 28 12:45:00 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442173A6EAE; Mon, 28 Apr 2008 12:45:00 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A79F628C2DC for ; Mon, 28 Apr 2008 12:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5fUSR5u2lgV for ; Mon, 28 Apr 2008 12:44:56 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9A05028C2EE for ; Mon, 28 Apr 2008 12:44:22 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2008 12:44:26 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3SJiQBS014347; Mon, 28 Apr 2008 12:44:26 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m3SJiENP012063; Mon, 28 Apr 2008 19:44:26 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); Mon, 28 Apr 2008 15:44:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 15:44:20 -0400 Message-ID: <0F64770A6FD22C43AAA498C1E774ECC705A0E27B@xmb-rtp-208.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision Thread-Index: AcipZTcWtejtCYufTaOHdI8NwjmR8AAAvc3Q References: <966f2c824f7a17d84f138a2ee956328e.squirrel@www.trepanning.net><089d20b64295debabe49c740e696c052.squirrel@www.trepanning.net> <1150ac8bbb9ea8ae59b35181d7adf578.squirrel@www.trepanning.net> <0F64770A6FD22C43AAA498C1E774ECC705A0DE55@xmb-rtp-208.amer.cisco.com> <47545e966f21dad7572e13ba63ea5acf.squirrel@www.trepanning.net> <0F64770A6FD22C43AAA498C1E774ECC705A0E1C5@xmb-rtp-208.amer.cisco.com> From: "Gene Chang (genchang)" To: "Dan Harkins" X-OriginalArrivalTime: 28 Apr 2008 19:44:19.0780 (UTC) FILETIME=[40233040:01C8A968] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17061; t=1209411866; x=1210275866; 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]=20EMU=20charter=20revision |Sender:=20; bh=KRuk6asTu+T9UMRXjAixApa1Pt8nXE71pasDqkHVCh0=; b=heCI0zZslPAoQRZtmjFawhOyvhJ0wnmC1IqWId/r2eZi5eXrvgQZJbtbkY 4s9h71n3tAxrsdRCzV+oDhy3zMInBKTLTdvoNXXY8STviP0xaQD/0e/rWL2L JwCLfwq6zst54iXCsWVMF1dO282Ab1OqUlOaRSA1bGFItdUoawbuM=; Authentication-Results: sj-dkim-1; header.From=genchang@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Dan, Great, we are not back to lets get those requirements done. It's the gate to the next steps. Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Monday, April 28, 2008 3:22 PM > To: Gene Chang (genchang) > Cc: Dan Harkins; Stephen Hanna; emu@ietf.org > Subject: RE: [Emu] EMU charter revision > > > Gene, > > I don't think anyone would find an EMU reality show entertaining. The > only comic relief would be one crazy guy who, once every 4 months, pokes > his head in the window and says "I do not approve" to people sitting > around watching paint dry. > > You are restating Stephen's comment from Philly that I'm more > interested in the cage match than in the coronation of the winner. > That is not true but it is also irrelevant. I actually don't care > who wins or how much blood is let, I just want it to be over. > > It would really be an abuse of process to hold up all other work while > each side crunches numbers and pays analysts to run surveys so that > someone can claim to have reached an arbitrary 10M mark. And it would not > be a service to anybody. > > So what we have is argument over the wording of "requirements" so > that they will subtly favor one side over the other. Then we create a > "requirements" document that captures all the carefully constructed > verbage. And while that's getting advanced we then argue over which > candidate best matches the customized wording of the "requirements". And > then we finally get down to the work of actually changing one of the > specifications to add channel binding. And this must all be done > serially. Sigh. > > Both FAST and TTLS are equally amenable to modification and their > differences are not so great or we'd have had a clear "winner" already. > No matter which one gets selected we will not end up with a weak solution. > > You don't see my sense of urgency because what you view as interesting > work is not being held up. > > Dan. > > On Mon, April 28, 2008 11:26 am, Gene Chang (genchang) wrote: > > Dan, > > > > I think we can all appreciate the entertainment value of bringing a > > reality show to the IETF. Imagine replacing the IETF social with an > > arena full of hyped up Internet engineers enjoying a night fellowship > > with beer and trash talk. > > > > Unfortunately, all we are doing is dressing up a down select with two > > 4-5 year old protocols that do not completely meet the requirements > > document that is being assembled. We aren't doing the industry a favor > > freezing the protocol choice to technology ca. 2004. > > > > If you are in such a rush, why not simply declare victory and have a > > tie. That enshrines the status quo. Picking one over the other won't > > change the status quo and thus won't change the deployment preference > > already established. > > > > Better for the industry would be a foot race where the candidate > > protocol that meets the requirements document and gains 10 million > > devices protected would win the standards title. This would advance the > > technology to cover the missing requirements and significantly grow > > adoption. > > > > Let's focus our efforts on moving the technology forward instead > > searching for an entertaining down select. > > > > I really don't see your sense of urgency. I don't see an adoption window > > that we are going to miss with the current effort. Yet, I can be really > > excited pushing to meet the needs of a critical adoption window. > > > > I would like to see things progress faster but not at the expense of a > > weak technical outcome. > > > > Gene > > > > ------------------------------------------------------------------------ > > ---- > > Eugene Chang (genchang) > > Cisco Systems > > Office: 603-559-2978 > > Mobile: 781-799-0233 > > Skype: gene02421 > > > > > > > >> -----Original Message----- > >> From: Dan Harkins [mailto:dharkins@lounge.org] > >> Sent: Monday, April 28, 2008 12:05 PM > >> To: Gene Chang (genchang) > >> Cc: Dan Harkins; Stephen Hanna; emu@ietf.org > >> Subject: RE: [Emu] EMU charter revision > >> > >> > >> Hi Gene, > >> > >> I'm not pushing a tunneled method. We have enough of those and their > >> differences are not so great. > >> > >> Yes, I was using "snail race" as a pejorative. As I said at the last > >> IETF we should have a cage-match-cum-beauty-contest between TTLS and > >> FAST, turn the last RFC text of the winner into a -00 EMU draft, add > > the > >> channel bindings stuff that was discussed back in Vancouver and then > >> publish. Apparently this working group can work on nothing except > >> a tunneled method. And that work is being done at a snail's pace. > >> > >> I'm glad to hear that you're open to a discussion of adding a non- > >> tunneled method "if there is sufficient demand", but you see we have > > this > >> long-standing consensus and the mere mention of anything that remotely > >> sounds like a non-tunneled method gets stifled with "consensus!" So > >> apparently we're not allowed to have that discussion. At least until > > we > >> finish work on a tunneled method. > >> > >> Dan. > >> > >> On Mon, April 28, 2008 3:35 am, Gene Chang (genchang) wrote: > >> > Dan, > >> > I am not sure I am able to clearly understand the end result you > > seek. > >> > It seems there is a clear consensus for a tunneled method. Are you > >> > pushing for the addition of a tunneled method? > >> > > >> > Ok... I am easily baited. What would you like to see to achieve more > >> > than a snail race? I am assuming we both believe the term "snail > > race" > >> > is a pejorative. Thus I ask you, how do we do better? > >> > > >> > I clearly hear your comment that there have been a paucity of > > comments, > >> > if nothing else, simply to affirm we are on track. I agree with the > >> > proposed charter. I am open to a discussion to add a non-tunneled > > method > >> > if there is sufficient demand. A non-tunneled method does not seem > > to > >> > promise enough features for the use cases that interest me. > >> > > >> > Gene > >> > > >> > > > ------------------------------------------------------------------------ > >> > ---- > >> > Eugene Chang (genchang) > >> > Cisco Systems > >> > Office: 603-559-2978 > >> > Mobile: 781-799-0233 > >> > Skype: gene02421 > >> > > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf > > Of > >> > Dan > >> >> Harkins > >> >> Sent: Monday, April 28, 2008 2:12 AM > >> >> To: Stephen Hanna > >> >> Cc: emu@ietf.org > >> >> Subject: Re: [Emu] EMU charter revision > >> >> > >> >> > >> >> That's true. One person's opinion does not negate consensus, > >> >> even if that one person is the only one who is able to opine > >> >> in the alloted time given for opinions (twice now). But so what? > >> >> If someone asks then I'll give an honest opinion, especially > >> >> since no one else seems to be able to. > >> >> > >> >> But maybe you're right. Any additional work taken on by this > >> >> group would distract from the fantastic progress we've made in the > >> >> past 9 months on the tunneled method. It would be a shame to lose > >> >> all that. Yes, let's just focus on the snail race.... > >> >> > >> >> Dan. > >> >> > >> >> On Sun, April 27, 2008 6:10 pm, Stephen Hanna wrote: > >> >> > I apologize for my tardy response. I have been on vacation. > >> >> > > >> >> > I agree with and support the proposed charter below. As for > >> >> > Dan's suggestion that we not require the password based > >> >> > method to be based on the tunnel method, the WG already > >> >> > went through a long discussion and consensus check last > >> >> > fall on this matter. There was clear consensus that we > >> >> > should NOT work on a new password based method designed > >> >> > to function without the tunnel method. One person's > >> >> > opinion to the contrary does not negate that consensus. > >> >> > I think that the reason we are not seeing much email on > >> >> > this charter is that the issues and language have been > >> >> > hashed through many times. > >> >> > > >> >> > Thanks, > >> >> > > >> >> > Steve > >> >> > > >> >> > -----Original Message----- > >> >> > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > > Behalf > >> > Of > >> >> > Dan Harkins > >> >> > Sent: Friday, April 25, 2008 5:43 PM > >> >> > To: Joseph Salowey (jsalowey) > >> >> > Cc: emu@ietf.org > >> >> > Subject: Re: [Emu] EMU charter revision > >> >> > > >> >> > > >> >> > Hi Joe, > >> >> > > >> >> > Once again, a call for comments and I'm the only one to > > comment. > >> >> > > >> >> > Whether removing that line achieves "my goals" or not I still > >> > think > >> >> > it should be removed. And that really seems to be the only > > comment > >> >> > on the charter you get when you ask. > >> >> > > >> >> > regards, > >> >> > > >> >> > Dan. > >> >> > > >> >> > On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) wrote: > >> >> >> > >> >> >> > >> >> >>> -----Original Message----- > >> >> >>> From: Dan Harkins [mailto:dharkins@lounge.org] > >> >> >>> Sent: Friday, April 11, 2008 10:38 AM > >> >> >>> To: Joseph Salowey (jsalowey) > >> >> >>> Cc: emu@ietf.org > >> >> >>> Subject: Re: [Emu] EMU charter revision > >> >> >>> > >> >> >>> > >> >> >>> Hi Joe, > >> >> >>> > >> >> >>> Thank you for giving me the opportunity to object, once > >> >> >>> again, to the last sentence in the last item in the charter. > >> >> >>> If you were to run the following sed filter on the charter I > >> >> >>> would approve: > >> >> >>> > >> >> >>> s/This item will be based on the above tunnel method.// > >> >> >>> > >> >> >> > >> >> >> [Joe] I do not think that removing this line would achieve the > > goal > >> >> > you > >> >> >> wish. With this line removed EAP-PWD is still out of scope of > > the > >> >> >> charter as it does not meet the requirements of supporting > > legacy > >> >> >> password databases. The message from the ADs in the last > > meeting > >> > was > >> >> >> pretty clear in that EAP-PWD style mechanisms is not something > > for > >> > the > >> >> >> group to take on right now. This does not mean that we cannot > > take > >> > on > >> >> >> an EAP-PWD style mechanism once we have made progress on the > >> > current > >> >> >> charter items. > >> >> >> > >> >> >>> What is the process here? This looks the same as the > >> >> >>> charter revision you made a consensus call on back in > >> >> >>> January. I was the only one to opine before your cutoff last > >> >> >>> time and my comment was the same as above. Now we're doing this > >> >> > again. > >> >> >>> > >> >> >> [Joe] There have been several revisions posted to the list and > >> >> > feedback > >> >> >> from several working group members that have been worked into > > the > >> > new > >> >> >> proposal along with input from the discussion in the last > > meeting. > >> > If > >> >> >> enough people respond positively, such that we have rough > >> > consensus, > >> >> >> then we can move forward. > >> >> >> > >> >> >> > >> >> >>> Dan. > >> >> >>> > >> >> >>> On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) > > wrote: > >> >> >>> > Below is a revision to the EMU charter that is intended to > >> >> >>> reflect the > >> >> >>> > discussions in the Philadelphia meeting. Please respond to > >> >> >>> the list > >> >> >>> > if you approve of the charter or if you have any comments > >> >> >>> on the charter. > >> >> >>> > I would like to have responses by 4/24. > >> >> >>> > > >> >> >>> > Thanks, > >> >> >>> >f > >> >> >>> > Joe > >> >> >>> > > >> >> >>> > Description of Working Group: > >> >> >>> > The Extensible Authentication Protocol (EAP) [RFC 3748] is > >> >> >>> a network > >> >> >>> > access authentication framework used in the PPP, 802.11, > >> >> >>> 802.16, VPN, > >> >> >>> > PANA, and in some functions in 3G networks. EAP itself is a > >> > simple > >> >> >>> > protocol and actual authentication happens in EAP methods. > >> >> >>> > > >> >> >>> > Over 40 different EAP methods exist. Most of these methods > > are > >> >> >>> > proprietary methods, but some are documented in > >> >> >>> informational RFCs. In > >> >> >>> > the past the lack of documented, open specifications has been > > a > >> >> >>> > deployment and interoperability problem. There are > >> >> >>> currently only two > >> >> >>> > EAP methods in the standards track that implement features > >> >> >>> such as key > >> >> >>> > derivation that are required for many modern applications. > >> >> >>> > Authentication types and credentials continue to evolve as do > >> >> >>> > requirements for EAP methods. > >> >> >>> > > >> >> >>> > This group is chartered to work on the following types of > >> >> >>> mechanisms > >> >> >>> > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying > >> > requirements: > >> >> >>> > > >> >> >>> > - An update to RFC 2716 to bring EAP-TLS into standards > >> >> >>> track, clarify > >> >> >>> > specification, interoperability, and implementation issues > >> > gathered > >> >> >>> > over the years, and update the document to meet the > > requirements > >> > of > >> >> >>> > RFC 3748, RFC 4017, and EAP keying framework documents. > >> > Backwards > >> >> >>> > compatibility with RFC 2716 is a requirement. > >> >> >>> > > >> >> >>> > - A mechanism based on strong shared secrets. This mechanism > >> > should > >> >> >>> > strive to be simple and compact for implementation in > > resource > >> >> >>> > constrained environments. > >> >> >>> > > >> >> >>> > - A document that defines EAP channel bindings and provides > >> >> >>> guidance > >> >> >>> > for establishing EAP channel bindings within EAP methods. > >> >> >>> > > >> >> >>> > - A mechanism to support extensible communication within a > > TLS > >> >> >>> > protected tunnel. This mechanism must support channel > > bindings > >> > in > >> >> >>> > order to meet RFC 4962 requirements. This mechanism will > > support > >> >> >>> > meeting the requirements of an enhanced TLS mechanism, a > >> > password > >> >> >>> > based authentication mechanism, and additional inner > >> > authentication > >> >> >>> > mechanisms. > >> >> >>> > > >> >> >>> > - Enable a TLS-based EAP method to support channel > >> >> >>> bindings. This item > >> >> >>> > will not generate a new method, rather it will extend > >> >> >>> EAP-TLS and/or > >> >> >>> > the above tunnel method. > >> >> >>> > > >> >> >>> > - A mechanism that makes use of existing password databases > > such > >> > as > >> >> >>> > AAA databases. This item will be based on the above tunnel > >> > method. > >> >> >>> > > >> >> >>> > Goals and Milestones: > >> >> >>> > Done Form design team to work on strong shared secret > >> >> >>> > mechanism > >> >> >>> > Done Submit 2716bis I-D > >> >> >>> > Done Submit first draft of shared secret > >> >> >>> mechanism I-D > >> >> >>> > Done Form password based mechanism design team > >> >> >>> > Done Submit 2716bis draft to IESG for > >> >> >>> Proposed Standard > >> >> >>> > Apr 2008 Submit Strong Shared Secret Mechanism to IESG > >> >> >>> > May 2008 Submit Tunnel and Password Method requirements > >> > first > >> >> >>> > Draft > >> >> >>> > Sep 2008 Submit EAP Channel Bindings First Draft > >> >> >>> > Sep 2008 Submit Tunnel Method first draft > >> >> >>> > Oct 2008 Submit TLS based method channel binding first > >> > draft > >> >> >>> > Oct 2008 Submit Password Method first draft > >> >> >>> > Jan 2009 Send EAP Channel Bindings to IESG > >> >> >>> > Mar 2009 Send Tunnel Method to IESG > >> >> >>> > Apr 2009 Send TLS based method channel binding to IESG > >> >> >>> > Apr 2009 Send Password based method to IESG > >> >> >>> > _______________________________________________ > >> >> >>> > Emu mailing list > >> >> >>> > Emu@ietf.org > >> >> >>> > https://www.ietf.org/mailman/listinfo/emu > >> >> >>> > > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >> > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > Emu mailing list > >> >> > Emu@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/emu > >> >> > > >> >> > >> >> > >> >> _______________________________________________ > >> >> Emu mailing list > >> >> Emu@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/emu > >> > > >> > > > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 28 12:47:19 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6174E3A6B31; Mon, 28 Apr 2008 12:47:19 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F9B3A6B31 for ; Mon, 28 Apr 2008 12:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZ3TRwSSBFIA for ; Mon, 28 Apr 2008 12:47:16 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A8EA43A67B2 for ; Mon, 28 Apr 2008 12:47:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,718,1199682000"; d="scan'208";a="6594671" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2008 15:47:16 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3SJlGwW013933; Mon, 28 Apr 2008 15:47:16 -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.13.8/8.13.8) with ESMTP id m3SJlG0d001288; Mon, 28 Apr 2008 19:47:16 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); Mon, 28 Apr 2008 15:47:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 15:47:15 -0400 Message-ID: <0F64770A6FD22C43AAA498C1E774ECC705A0E27D@xmb-rtp-208.amer.cisco.com> In-Reply-To: <0F64770A6FD22C43AAA498C1E774ECC705A0E27B@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision Thread-Index: AcipZTcWtejtCYufTaOHdI8NwjmR8AAAvc3QAAAXoYA= References: <966f2c824f7a17d84f138a2ee956328e.squirrel@www.trepanning.net><089d20b64295debabe49c740e696c052.squirrel@www.trepanning.net><1150ac8bbb9ea8ae59b35181d7adf578.squirrel@www.trepanning.net><0F64770A6FD22C43AAA498C1E774ECC705A0DE55@xmb-rtp-208.amer.cisco.com><47545e966f21dad7572e13ba63ea5acf.squirrel@www.trepanning.net><0F64770A6FD22C43AAA498C1E774ECC705A0E1C5@xmb-rtp-208.amer.cisco.com> <0F64770A6FD22C43AAA498C1E774ECC705A0E27B@xmb-rtp-208.amer.cisco.com> From: "Gene Chang (genchang)" To: "Gene Chang (genchang)" , "Dan Harkins" X-OriginalArrivalTime: 28 Apr 2008 19:47:16.0329 (UTC) FILETIME=[A95E6D90:01C8A968] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18817; t=1209412036; x=1210276036; 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]=20EMU=20charter=20revision |Sender:=20 |To:=20=22Gene=20Chang=20(genchang)=22=20,=0A=20=20=20=20=20=20=20=20=22Dan=20Harkins=22=20; bh=JZmUC5tQhpzMjl7W0MsWjMAonI5eLFyCTxZs6sjWehM=; b=cAbWsZSaKHM5RiCFc5scKTbwF4evziPdQd5OsScwC3PvN6yogR2aekjHtd sqmNXhaYD0kzruqGK+5NlvqKk9uET0iMNjeySVcg2oDPEqpzoLCPAsGBW2oo EymkBmKOBf; Authentication-Results: rtp-dkim-2; header.From=genchang@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Oops... a key typo in the earlier version... Dan, Great, we are now back to let's get those requirements done. It's the gate to the next steps. Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Gene > Chang (genchang) > Sent: Monday, April 28, 2008 3:44 PM > To: Dan Harkins > Cc: emu@ietf.org > Subject: Re: [Emu] EMU charter revision > > Dan, > Great, we are not back to lets get those requirements done. It's the > gate to the next steps. > > Gene > > ------------------------------------------------------------------------ > ---- > Eugene Chang (genchang) > Cisco Systems > Office: 603-559-2978 > Mobile: 781-799-0233 > Skype: gene02421 > > > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@lounge.org] > > Sent: Monday, April 28, 2008 3:22 PM > > To: Gene Chang (genchang) > > Cc: Dan Harkins; Stephen Hanna; emu@ietf.org > > Subject: RE: [Emu] EMU charter revision > > > > > > Gene, > > > > I don't think anyone would find an EMU reality show entertaining. > The > > only comic relief would be one crazy guy who, once every 4 months, > pokes > > his head in the window and says "I do not approve" to people sitting > > around watching paint dry. > > > > You are restating Stephen's comment from Philly that I'm more > > interested in the cage match than in the coronation of the winner. > > That is not true but it is also irrelevant. I actually don't care > > who wins or how much blood is let, I just want it to be over. > > > > It would really be an abuse of process to hold up all other work > while > > each side crunches numbers and pays analysts to run surveys so that > > someone can claim to have reached an arbitrary 10M mark. And it would > not > > be a service to anybody. > > > > So what we have is argument over the wording of "requirements" so > > that they will subtly favor one side over the other. Then we create a > > "requirements" document that captures all the carefully constructed > > verbage. And while that's getting advanced we then argue over which > > candidate best matches the customized wording of the "requirements". > And > > then we finally get down to the work of actually changing one of the > > specifications to add channel binding. And this must all be done > > serially. Sigh. > > > > Both FAST and TTLS are equally amenable to modification and their > > differences are not so great or we'd have had a clear "winner" > already. > > No matter which one gets selected we will not end up with a weak > solution. > > > > You don't see my sense of urgency because what you view as > interesting > > work is not being held up. > > > > Dan. > > > > On Mon, April 28, 2008 11:26 am, Gene Chang (genchang) wrote: > > > Dan, > > > > > > I think we can all appreciate the entertainment value of bringing a > > > reality show to the IETF. Imagine replacing the IETF social with an > > > arena full of hyped up Internet engineers enjoying a night > fellowship > > > with beer and trash talk. > > > > > > Unfortunately, all we are doing is dressing up a down select with > two > > > 4-5 year old protocols that do not completely meet the requirements > > > document that is being assembled. We aren't doing the industry a > favor > > > freezing the protocol choice to technology ca. 2004. > > > > > > If you are in such a rush, why not simply declare victory and have a > > > tie. That enshrines the status quo. Picking one over the other won't > > > change the status quo and thus won't change the deployment > preference > > > already established. > > > > > > Better for the industry would be a foot race where the candidate > > > protocol that meets the requirements document and gains 10 million > > > devices protected would win the standards title. This would advance > the > > > technology to cover the missing requirements and significantly grow > > > adoption. > > > > > > Let's focus our efforts on moving the technology forward instead > > > searching for an entertaining down select. > > > > > > I really don't see your sense of urgency. I don't see an adoption > window > > > that we are going to miss with the current effort. Yet, I can be > really > > > excited pushing to meet the needs of a critical adoption window. > > > > > > I would like to see things progress faster but not at the expense of > a > > > weak technical outcome. > > > > > > Gene > > > > > > > ------------------------------------------------------------------------ > > > ---- > > > Eugene Chang (genchang) > > > Cisco Systems > > > Office: 603-559-2978 > > > Mobile: 781-799-0233 > > > Skype: gene02421 > > > > > > > > > > > >> -----Original Message----- > > >> From: Dan Harkins [mailto:dharkins@lounge.org] > > >> Sent: Monday, April 28, 2008 12:05 PM > > >> To: Gene Chang (genchang) > > >> Cc: Dan Harkins; Stephen Hanna; emu@ietf.org > > >> Subject: RE: [Emu] EMU charter revision > > >> > > >> > > >> Hi Gene, > > >> > > >> I'm not pushing a tunneled method. We have enough of those and > their > > >> differences are not so great. > > >> > > >> Yes, I was using "snail race" as a pejorative. As I said at the > last > > >> IETF we should have a cage-match-cum-beauty-contest between TTLS > and > > >> FAST, turn the last RFC text of the winner into a -00 EMU draft, > add > > > the > > >> channel bindings stuff that was discussed back in Vancouver and > then > > >> publish. Apparently this working group can work on nothing except > > >> a tunneled method. And that work is being done at a snail's pace. > > >> > > >> I'm glad to hear that you're open to a discussion of adding a > non- > > >> tunneled method "if there is sufficient demand", but you see we > have > > > this > > >> long-standing consensus and the mere mention of anything that > remotely > > >> sounds like a non-tunneled method gets stifled with "consensus!" So > > >> apparently we're not allowed to have that discussion. At least > until > > > we > > >> finish work on a tunneled method. > > >> > > >> Dan. > > >> > > >> On Mon, April 28, 2008 3:35 am, Gene Chang (genchang) wrote: > > >> > Dan, > > >> > I am not sure I am able to clearly understand the end result you > > > seek. > > >> > It seems there is a clear consensus for a tunneled method. Are > you > > >> > pushing for the addition of a tunneled method? > > >> > > > >> > Ok... I am easily baited. What would you like to see to achieve > more > > >> > than a snail race? I am assuming we both believe the term "snail > > > race" > > >> > is a pejorative. Thus I ask you, how do we do better? > > >> > > > >> > I clearly hear your comment that there have been a paucity of > > > comments, > > >> > if nothing else, simply to affirm we are on track. I agree with > the > > >> > proposed charter. I am open to a discussion to add a non-tunneled > > > method > > >> > if there is sufficient demand. A non-tunneled method does not > seem > > > to > > >> > promise enough features for the use cases that interest me. > > >> > > > >> > Gene > > >> > > > >> > > > > > ------------------------------------------------------------------------ > > >> > ---- > > >> > Eugene Chang (genchang) > > >> > Cisco Systems > > >> > Office: 603-559-2978 > > >> > Mobile: 781-799-0233 > > >> > Skype: gene02421 > > >> > > > >> > > > >> > > > >> > > > >> >> -----Original Message----- > > >> >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > Behalf > > > Of > > >> > Dan > > >> >> Harkins > > >> >> Sent: Monday, April 28, 2008 2:12 AM > > >> >> To: Stephen Hanna > > >> >> Cc: emu@ietf.org > > >> >> Subject: Re: [Emu] EMU charter revision > > >> >> > > >> >> > > >> >> That's true. One person's opinion does not negate consensus, > > >> >> even if that one person is the only one who is able to opine > > >> >> in the alloted time given for opinions (twice now). But so what? > > >> >> If someone asks then I'll give an honest opinion, especially > > >> >> since no one else seems to be able to. > > >> >> > > >> >> But maybe you're right. Any additional work taken on by this > > >> >> group would distract from the fantastic progress we've made in > the > > >> >> past 9 months on the tunneled method. It would be a shame to > lose > > >> >> all that. Yes, let's just focus on the snail race.... > > >> >> > > >> >> Dan. > > >> >> > > >> >> On Sun, April 27, 2008 6:10 pm, Stephen Hanna wrote: > > >> >> > I apologize for my tardy response. I have been on vacation. > > >> >> > > > >> >> > I agree with and support the proposed charter below. As for > > >> >> > Dan's suggestion that we not require the password based > > >> >> > method to be based on the tunnel method, the WG already > > >> >> > went through a long discussion and consensus check last > > >> >> > fall on this matter. There was clear consensus that we > > >> >> > should NOT work on a new password based method designed > > >> >> > to function without the tunnel method. One person's > > >> >> > opinion to the contrary does not negate that consensus. > > >> >> > I think that the reason we are not seeing much email on > > >> >> > this charter is that the issues and language have been > > >> >> > hashed through many times. > > >> >> > > > >> >> > Thanks, > > >> >> > > > >> >> > Steve > > >> >> > > > >> >> > -----Original Message----- > > >> >> > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > > > Behalf > > >> > Of > > >> >> > Dan Harkins > > >> >> > Sent: Friday, April 25, 2008 5:43 PM > > >> >> > To: Joseph Salowey (jsalowey) > > >> >> > Cc: emu@ietf.org > > >> >> > Subject: Re: [Emu] EMU charter revision > > >> >> > > > >> >> > > > >> >> > Hi Joe, > > >> >> > > > >> >> > Once again, a call for comments and I'm the only one to > > > comment. > > >> >> > > > >> >> > Whether removing that line achieves "my goals" or not I > still > > >> > think > > >> >> > it should be removed. And that really seems to be the only > > > comment > > >> >> > on the charter you get when you ask. > > >> >> > > > >> >> > regards, > > >> >> > > > >> >> > Dan. > > >> >> > > > >> >> > On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) > wrote: > > >> >> >> > > >> >> >> > > >> >> >>> -----Original Message----- > > >> >> >>> From: Dan Harkins [mailto:dharkins@lounge.org] > > >> >> >>> Sent: Friday, April 11, 2008 10:38 AM > > >> >> >>> To: Joseph Salowey (jsalowey) > > >> >> >>> Cc: emu@ietf.org > > >> >> >>> Subject: Re: [Emu] EMU charter revision > > >> >> >>> > > >> >> >>> > > >> >> >>> Hi Joe, > > >> >> >>> > > >> >> >>> Thank you for giving me the opportunity to object, once > > >> >> >>> again, to the last sentence in the last item in the charter. > > >> >> >>> If you were to run the following sed filter on the charter I > > >> >> >>> would approve: > > >> >> >>> > > >> >> >>> s/This item will be based on the above tunnel method.// > > >> >> >>> > > >> >> >> > > >> >> >> [Joe] I do not think that removing this line would achieve > the > > > goal > > >> >> > you > > >> >> >> wish. With this line removed EAP-PWD is still out of scope > of > > > the > > >> >> >> charter as it does not meet the requirements of supporting > > > legacy > > >> >> >> password databases. The message from the ADs in the last > > > meeting > > >> > was > > >> >> >> pretty clear in that EAP-PWD style mechanisms is not > something > > > for > > >> > the > > >> >> >> group to take on right now. This does not mean that we > cannot > > > take > > >> > on > > >> >> >> an EAP-PWD style mechanism once we have made progress on the > > >> > current > > >> >> >> charter items. > > >> >> >> > > >> >> >>> What is the process here? This looks the same as the > > >> >> >>> charter revision you made a consensus call on back in > > >> >> >>> January. I was the only one to opine before your cutoff last > > >> >> >>> time and my comment was the same as above. Now we're doing > this > > >> >> > again. > > >> >> >>> > > >> >> >> [Joe] There have been several revisions posted to the list > and > > >> >> > feedback > > >> >> >> from several working group members that have been worked into > > > the > > >> > new > > >> >> >> proposal along with input from the discussion in the last > > > meeting. > > >> > If > > >> >> >> enough people respond positively, such that we have rough > > >> > consensus, > > >> >> >> then we can move forward. > > >> >> >> > > >> >> >> > > >> >> >>> Dan. > > >> >> >>> > > >> >> >>> On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) > > > wrote: > > >> >> >>> > Below is a revision to the EMU charter that is intended to > > >> >> >>> reflect the > > >> >> >>> > discussions in the Philadelphia meeting. Please respond > to > > >> >> >>> the list > > >> >> >>> > if you approve of the charter or if you have any comments > > >> >> >>> on the charter. > > >> >> >>> > I would like to have responses by 4/24. > > >> >> >>> > > > >> >> >>> > Thanks, > > >> >> >>> >f > > >> >> >>> > Joe > > >> >> >>> > > > >> >> >>> > Description of Working Group: > > >> >> >>> > The Extensible Authentication Protocol (EAP) [RFC 3748] is > > >> >> >>> a network > > >> >> >>> > access authentication framework used in the PPP, 802.11, > > >> >> >>> 802.16, VPN, > > >> >> >>> > PANA, and in some functions in 3G networks. EAP itself is > a > > >> > simple > > >> >> >>> > protocol and actual authentication happens in EAP methods. > > >> >> >>> > > > >> >> >>> > Over 40 different EAP methods exist. Most of these methods > > > are > > >> >> >>> > proprietary methods, but some are documented in > > >> >> >>> informational RFCs. In > > >> >> >>> > the past the lack of documented, open specifications has > been > > > a > > >> >> >>> > deployment and interoperability problem. There are > > >> >> >>> currently only two > > >> >> >>> > EAP methods in the standards track that implement features > > >> >> >>> such as key > > >> >> >>> > derivation that are required for many modern applications. > > >> >> >>> > Authentication types and credentials continue to evolve as > do > > >> >> >>> > requirements for EAP methods. > > >> >> >>> > > > >> >> >>> > This group is chartered to work on the following types of > > >> >> >>> mechanisms > > >> >> >>> > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying > > >> > requirements: > > >> >> >>> > > > >> >> >>> > - An update to RFC 2716 to bring EAP-TLS into standards > > >> >> >>> track, clarify > > >> >> >>> > specification, interoperability, and implementation issues > > >> > gathered > > >> >> >>> > over the years, and update the document to meet the > > > requirements > > >> > of > > >> >> >>> > RFC 3748, RFC 4017, and EAP keying framework documents. > > >> > Backwards > > >> >> >>> > compatibility with RFC 2716 is a requirement. > > >> >> >>> > > > >> >> >>> > - A mechanism based on strong shared secrets. This > mechanism > > >> > should > > >> >> >>> > strive to be simple and compact for implementation in > > > resource > > >> >> >>> > constrained environments. > > >> >> >>> > > > >> >> >>> > - A document that defines EAP channel bindings and > provides > > >> >> >>> guidance > > >> >> >>> > for establishing EAP channel bindings within EAP methods. > > >> >> >>> > > > >> >> >>> > - A mechanism to support extensible communication within a > > > TLS > > >> >> >>> > protected tunnel. This mechanism must support channel > > > bindings > > >> > in > > >> >> >>> > order to meet RFC 4962 requirements. This mechanism will > > > support > > >> >> >>> > meeting the requirements of an enhanced TLS mechanism, a > > >> > password > > >> >> >>> > based authentication mechanism, and additional inner > > >> > authentication > > >> >> >>> > mechanisms. > > >> >> >>> > > > >> >> >>> > - Enable a TLS-based EAP method to support channel > > >> >> >>> bindings. This item > > >> >> >>> > will not generate a new method, rather it will extend > > >> >> >>> EAP-TLS and/or > > >> >> >>> > the above tunnel method. > > >> >> >>> > > > >> >> >>> > - A mechanism that makes use of existing password > databases > > > such > > >> > as > > >> >> >>> > AAA databases. This item will be based on the above > tunnel > > >> > method. > > >> >> >>> > > > >> >> >>> > Goals and Milestones: > > >> >> >>> > Done Form design team to work on strong > shared secret > > >> >> >>> > mechanism > > >> >> >>> > Done Submit 2716bis I-D > > >> >> >>> > Done Submit first draft of shared secret > > >> >> >>> mechanism I-D > > >> >> >>> > Done Form password based mechanism design > team > > >> >> >>> > Done Submit 2716bis draft to IESG for > > >> >> >>> Proposed Standard > > >> >> >>> > Apr 2008 Submit Strong Shared Secret Mechanism to IESG > > >> >> >>> > May 2008 Submit Tunnel and Password Method requirements > > >> > first > > >> >> >>> > Draft > > >> >> >>> > Sep 2008 Submit EAP Channel Bindings First Draft > > >> >> >>> > Sep 2008 Submit Tunnel Method first draft > > >> >> >>> > Oct 2008 Submit TLS based method channel binding first > > >> > draft > > >> >> >>> > Oct 2008 Submit Password Method first draft > > >> >> >>> > Jan 2009 Send EAP Channel Bindings to IESG > > >> >> >>> > Mar 2009 Send Tunnel Method to IESG > > >> >> >>> > Apr 2009 Send TLS based method channel binding to IESG > > >> >> >>> > Apr 2009 Send Password based method to IESG > > >> >> >>> > _______________________________________________ > > >> >> >>> > Emu mailing list > > >> >> >>> > Emu@ietf.org > > >> >> >>> > https://www.ietf.org/mailman/listinfo/emu > > >> >> >>> > > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >> > > >> >> > > > >> >> > > > >> >> > _______________________________________________ > > >> >> > Emu mailing list > > >> >> > Emu@ietf.org > > >> >> > https://www.ietf.org/mailman/listinfo/emu > > >> >> > > > >> >> > > >> >> > > >> >> _______________________________________________ > > >> >> Emu mailing list > > >> >> Emu@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/emu > > >> > > > >> > > > > > > > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Apr 28 21:03:19 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B093A6C1B; Mon, 28 Apr 2008 21:03:19 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D74B3A6E0E; Fri, 25 Apr 2008 08:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzfMCtEqNMGq; Fri, 25 Apr 2008 08:43:02 -0700 (PDT) Received: from smtp.unijos.edu.ng (unknown [82.206.136.75]) by core3.amsl.com (Postfix) with ESMTP id ECFBE3A6959; Fri, 25 Apr 2008 08:42:59 -0700 (PDT) Received: from localhost (smtp.unijos.edu.ng [127.0.0.1]) by smtp.unijos.edu.ng (Postfix) with ESMTP id 9DE9B6816D; Fri, 25 Apr 2008 16:37:37 +0100 (WAT) X-Virus-Scanned: amavisd-new at unijos.edu.ng Received: from smtp.unijos.edu.ng ([127.0.0.1]) by localhost (smtp.unijos.edu.ng [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg7tDfI5O4lT; Fri, 25 Apr 2008 16:37:28 +0100 (WAT) Received: from imap.unijos.edu.ng (imap.unijos.edu.ng [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.unijos.edu.ng (Postfix) with ESMTP id 3034768161; Fri, 25 Apr 2008 16:37:28 +0100 (WAT) Received: from mail.unijos.edu.ng (localhost [127.0.0.1]) by imap.unijos.edu.ng (Postfix) with ESMTP id 1CA1C28106; Fri, 25 Apr 2008 16:44:47 +0100 (WAT) Received: from 192.168.192.232 (SquirrelMail authenticated user gogwim) by mail.unijos.edu.ng with HTTP; Fri, 25 Apr 2008 16:44:47 +0100 (WAT) Message-ID: <51428.192.168.192.232.1209138287.squirrel@mail.unijos.edu.ng> In-Reply-To: <0229AD28-4007-4DAA-A098-7201A7F81C41@nist.gov> References: <0229AD28-4007-4DAA-A098-7201A7F81C41@nist.gov> Date: Fri, 25 Apr 2008 16:44:47 +0100 (WAT) From: "GOGWIM, JOEL GODWIN" To: "Tim Polk" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Mon, 28 Apr 2008 21:03:14 -0700 Cc: msec@ietf.org, emu@ietf.org, "secdir@MIT.EDU" , Ran Canetti , saag@mit.edu Subject: Re: [Emu] [saag] new co-chairs for emu and msec X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gogwim@unijos.edu.ng List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org You are welcome on the chairs and big congratulations while anticipating your able leadership. Thank you, ^^Gogwim,Joel. On Fri, April 25, 2008 3:19 pm, Tim Polk said: > Folks, > > Pasi and I are very pleased to announce that two of our co-chair > vacancies have been filled. > > Alan Dekok has agreed to co-chair the EAP Method Update (emu) working > group with Joe Salowey, > who has been flying solo for some time now. Brian Weis will be co- > chairing the Multicast Security > (msec) working group; he is taking over for Ran Canetti. > Lakshminath Dondeti has agreed to continue > with msec for a bit longer, which we greatly appreciate. This will > certainly smooth the transition, and > it gives Pasi and I a bit more time to finalize things with a second > co-chair for msec. > > We are really delighted that Alan and Brian have accepted these > leadership positions, and are looking > forward to working closely with them in the future. We also would > like to thank everyone that threw their > name into the hat. Pasi and I had the luxury of choosing between > multiple highly qualified candidates. > It is great to see how many people have the ability and desire to > contribute in IETF leadership positions. > Finally, we would like to thank everyone in the community that > submitted nominations. > > Please stay tuned for future co-chair announcements for tls and msec. > > Thanks, > > Tim Polk and Pasi Eronen > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 29 00:11:08 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF7A3A698F; Tue, 29 Apr 2008 00:11:08 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0730C3A6C6E for ; Tue, 29 Apr 2008 00:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQmQcJujA556 for ; Tue, 29 Apr 2008 00:11:00 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dyn32-54.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 64FD83A698F for ; Tue, 29 Apr 2008 00:11:00 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C0FC2294013; Tue, 29 Apr 2008 10:11:02 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id AFA6E294011; Tue, 29 Apr 2008 10:11:01 +0300 (IDT) Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m3T7B1fU010117; Tue, 29 Apr 2008 10:11:01 +0300 (IDT) Message-Id: <59FF31EF-481F-4BDE-BE2B-763B515898D9@checkpoint.com> From: Yoav Nir To: "Joseph Salowey (jsalowey)" , emu@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 29 Apr 2008 10:11:01 +0300 References: X-Mailer: Apple Mail (2.919.2) Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Hi Joe, I don't see much wrong with EAP-GTC, and I may end up using it for legacy RADIUS support, But there are two arguments against using it. 1. The typical deployment of an IKE gateway is that there's a RADIUS or LDAP server somewhere in the internal network or even on another network in the case of a branch office gateway. EAP is usually forwarded to that server. If the forwarded payload is GTC, it's something malicious (perhaps on the internal network) might sniff it and get the password. 2. There is a threat scenario described in http://eprint.iacr.org/2002/163 . The idea is that a client that does EAP-GTC will do it both in a secure tunnel (such as in IKEv2) and outside of a secure tunnel (such as 802.1x). Someone sniffing the 802.1x will be able to acquire the password. This sounds simplistic to me, but more realistically, if IKEv2 (or even more so - TLS) is authenticated with a password, it may be tempting, as Dan pointed out, to uncheck the "verify server certificate" because "we're authenticating with a certificate". IOW, the user is actually authenticating to the RADIUS server, which tells the gateway that the user is authenticated. Since the gateway can't authenticate the user on its own, it makes sense that the client can't authenticate the gateway on its own. The RADIUS server sends the MSK to the gateway and the gateway sends a PoP to the client, and that is the proof the client has that the gateway is "authentic". But for this to work, you need an EAP method that (1) generates keys, and (2) mutually authenticates the client and server. These are required in the IKEv2 RFC. Tunneling a method like EAP-GTC gives you the keys and the mutual authentication but it requires that the client be able to verify the server certificate, and it requires that the tunneling go all the way to the server, rather than GTC going to the server, while the tunnel terminates at the gateway. It still takes a lot of round trips to get it to work, and a non-tunneled method like EAP-SRP or EAP-pwd would probably be better suited. Yoav On Apr 28, 2008, at 9:41 PM, Joseph Salowey (jsalowey) wrote: > Hi Yoav, > > You bring up an interesting point in discussing the need for EAP > password based authentication within other protected protocols. If > this > is targeted at working with legacy databases then I think it can be > accommodated under the current charter. An EAP protected tunnel is > required for some deployments, however perhaps the tunneled password > protocol can be designed to be used in other cases (IKEv2, TLS, > etc.) if > the group wants to take this direction. What do you see lacking in > something like EAP-GTC? > > Cheers, > > Joe > >> -----Original Message----- >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On >> Behalf Of Yoav Nir >> Sent: Monday, April 28, 2008 5:13 AM >> To: emu@ietf.org >> Subject: Re: [Emu] EMU charter revision >> >> Gene Chang said: >> >> >> >> Dan, >> I am not sure I am able to clearly understand the end >> result you seek. >> It seems there is a clear consensus for a tunneled >> method. Are you >> pushing for the addition of a tunneled method? >> >> Ok... I am easily baited. What would you like to see to >> achieve more >> than a snail race? I am assuming we both believe the >> term "snail race" >> is a pejorative. Thus I ask you, how do we do better? >> >> I clearly hear your comment that there have been a >> paucity of comments, >> if nothing else, simply to affirm we are on track. I >> agree with the >> proposed charter. I am open to a discussion to add a >> non-tunneled method >> if there is sufficient demand. A non-tunneled method >> does not seem to >> promise enough features for the use cases that interest me. >> >> Gene >> >> >> >> Hi Gene, >> >> >> You did not specify what the uses that interest you are, and >> I don't know about the use cases that interest Dan either, >> but I can speak for the use cases that interest me. >> >> >> EAP has been used in several cases as a magic way to use >> legacy credentials in protocols. I'll cite three examples: >> >> >> 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple, >> Cisco and others, where an EAP method is used to authenticate >> the user. >> 2. IKEv2 (RFC 4306) where EAP is used to magically >> authenticate the initiator using non-cert and non-PSK credentials. >> 3. TEE (draft-nir-tls-eap-03) where EAP is used to >> authenticate the user. >> >> >> In all three cases EAP is used by a protocol inside an >> encrypted tunnel, where the server, which is either trusted >> by the authenticator or co-located with it is already >> authenticated by a certificate or PSK. IMO EAP was used in >> all cases an some magical way of making passwords into a >> secure authentication mechanism. The problem is that there >> really is no publicly available EAP method for passwords. >> >> >> Tunneled methods don't really make sense here. There's no >> benefit in putting a TLS tunnel inside an IKEv2 exchange just >> to pass the password. Something like EAP-SRP would be great >> if it (a) existed and (b) didn't have all that IPR baggage. >> The method that Dan is proposing would also be beneficial >> here, if we could get a WG behind it so we can get some solid >> security review. Instead, what implementors are doing is >> EAP-MD5 or EAP-GTC, which don't quite meet the requirements >> for any of the above protocols. >> >> >> Yoav >> >> >> >> >> >> >> > > Scanned by Check Point Total Security Gateway. > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Apr 29 12:50:01 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB403A6D91; Tue, 29 Apr 2008 12:50:01 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A602C3A6C7A for ; Tue, 29 Apr 2008 12:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QZNFzir2PMA for ; Tue, 29 Apr 2008 12:49:59 -0700 (PDT) Received: from blu139-omc3-s21.blu139.hotmail.com (blu139-omc3-s21.blu139.hotmail.com [65.55.175.221]) by core3.amsl.com (Postfix) with ESMTP id A9F3028C272 for ; Tue, 29 Apr 2008 12:49:58 -0700 (PDT) Received: from BLU137-W2 ([65.55.162.189]) by blu139-omc3-s21.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 12:50:01 -0700 Message-ID: X-Originating-IP: [131.107.0.105] From: Bernard Aboba To: Date: Tue, 29 Apr 2008 12:50:01 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 29 Apr 2008 19:50:01.0657 (UTC) FILETIME=[36533A90:01C8AA32] Subject: Re: [Emu] EMU charter revision, X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0688065822==" Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org --===============0688065822== Content-Type: multipart/alternative; boundary="_c8a64dd7-ba88-429a-9e8e-bfe320b3b09d_" --_c8a64dd7-ba88-429a-9e8e-bfe320b3b09d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In re-reading this charter, I still don't think we're quite there: =20 a. Why is there still a charter item for EAP-TLS? This work hasbeen compl= eted, no?=20 =20 b. Attempting to extend EAP-TLS to support tunneling or channel bindings=20 is not appropriate. EAP-TLS already widely deployed, with large investments= =20 in conformance tests. Given the number of existing TLS-based tunneling pro= tocols, such a work item would serve no useful purpose. Let's focus on add= ing channel binding support to tunnel methods.=20 =20 c. To some extent, I agree with Dan and Yoav with respect to the need for p= assword-based methods. Had such methods been availableearlier, it's questi= onable whether TLS tunneling would have takenoff to the extent that it has.= Also, I think that such methods, if specified in the IETF, would be likely to be widely deployed. However, on the other hand I think that this is really an issue for the entire security area, not just for EMU. So I'd suggest that this issue be brought up in SAAG.=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DBelow is a revisio= n to the EMU charter that is intended to reflect thediscussions in the Phil= adelphia meeting. Please respond to the list ifyou approve of the charter = or if you have any comments on the charter.I would like to have responses b= y 4/24. =20 Thanks, Joe =20 = --_c8a64dd7-ba88-429a-9e8e-bfe320b3b09d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In re-reading this charter, I still don't think we're quite there:
 
a.  Why is there still a charter item for EAP-TLS?  This work has=
been completed, no?
 
b. Attempting to extend EAP-TLS to support tunneling or channel bindings is not appropriate. EAP-TLS already widely deployed, with large investments=
in conformance tests.  Given the number of existing TLS-based tunnelin= g protocols,
such a work item would serve no useful purpose.  Let'= s focus on adding
channel binding support to tunnel methods.
 
c. To some extent, I agree with Dan and Yoav with respect to the
need f= or password-based methods.  Had such methods been available
earlier= , it's questionable whether TLS tunneling would have taken
off to the ex= tent that it has.  Also, I think that such methods, if specified
in the IETF, would be likely to be widely deployed.  However, on the o= ther
hand I think that this is really an issue for the entire security area, not=
just for EMU.  So I'd suggest that this issue be brought up in SAAG. <= BR>  
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Below is a rev= ision to the EMU charter that is intended to reflect the
discussions in = the Philadelphia meeting.  Please respond to the list if
you approv= e of the charter or if you have any comments on the charter.
I would lik= e to have responses by 4/24.
 
Thanks,
Joe
 
 
= --_c8a64dd7-ba88-429a-9e8e-bfe320b3b09d_-- --===============0688065822== 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://www.ietf.org/mailman/listinfo/emu --===============0688065822==-- From emu-bounces@ietf.org Wed Apr 30 09:33:42 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FDA3A6C36; Wed, 30 Apr 2008 09:33:42 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338813A6E6F for ; Wed, 30 Apr 2008 09:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKY5PvEp2wPP for ; Wed, 30 Apr 2008 09:33:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9825A3A6E22 for ; Wed, 30 Apr 2008 09:33:39 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2008 09:33:42 -0700 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 m3UGXgdN014336; Wed, 30 Apr 2008 09:33:42 -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.13.8/8.13.8) with ESMTP id m3UGXftS012191; Wed, 30 Apr 2008 16:33:42 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, 30 Apr 2008 12:33:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 12:34:02 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B706DC56E5@xmb-rtp-212.amer.cisco.com> In-Reply-To: <3060f5984089b9927367f4d8bec80071.squirrel@www.trepanning.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision Thread-Index: AcipXqw86f3mS4fZT+qMhbE5YDzmxwBgEQPw References: <9958B444368E884DBB215F3FEF36F5B706D44AE9@xmb-rtp-212.amer.cisco.com> <9958B444368E884DBB215F3FEF36F5B706D44C42@xmb-rtp-212.amer.cisco.com> <3060f5984089b9927367f4d8bec80071.squirrel@www.trepanning.net> From: "Hao Zhou (hzhou)" To: "Dan Harkins" X-OriginalArrivalTime: 30 Apr 2008 16:33:41.0518 (UTC) FILETIME=[F33A6AE0:01C8AADF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10723; t=1209573222; x=1210437222; c=relaxed/simple; s=sjdkim4002; 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]=20EMU=20charter=20revision |Sender:=20; bh=a9lz1zAo2gZoS7YoW9ezZpKK2/HdVpasrItKMg/PnCI=; b=uuUWYLTpRPV6eluY7ErMdA7Sp+hIzB8LopaU4BboShBP/4+bEXHzqyIFH2 YfNHb95zrgrTqfqnuL0+YGeKrC2oTc3qn/JmDBLiwrXEDKAMMmSV4fEo4FKW DqLhVEEhpK; Authentication-Results: sj-dkim-4; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Yoav Nir , emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Dan wrote: > The real thing holding up adoption of EAP-pwd as a work > item is finishing work on the tunneled method. Which wouldn't > be such a bad thing if we were further along towards that > goal after Philly than we were after Vancouver and from the > looks of it we won't be any further after Dublin than we were > after Vancouver. :-( I don't think tunnel method is the real thing holding up the EAP-pw as a work item, so stop attacking the tunnel method or hurry it into some kind of "sword fight." As others pointed out, EAP-pw might be quite useful for multiple WGs and should be bring to SAAG. But security review and IPR analysis need to be done before any WG is willing to take that work, I think. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Monday, April 28, 2008 2:36 PM > To: Hao Zhou (hzhou) > Cc: Dan Harkins; Yoav Nir; emu@ietf.org > Subject: RE: [Emu] EMU charter revision > > > Hao, > > On Mon, April 28, 2008 10:32 am, Hao Zhou (hzhou) wrote: > > Dan: > > > > Now you have changed to argue that tunnel method is not the right > > solution for the use case EMU is targeted on, instead of > arguing your > > proposed password should be included as addition to the > tunnel method. > > I thought working on and standardizing the tunnel method is the WG > > consensus for few IETF meetings now, are you going to > challenge that > > now? Maybe this also contributes to the "snail race" of > tunnel method. > > It is the consensus. I'm not challenging consensus, just > answering a question. "Do you approve of this charter?" Well, > no I don't. I was told by the ADs that EAP-pwd is outside the > current charter. Fine. We can't work on it but that doesn't > mean I approve of the charter; I don't, for that very reason. > If I'm asked again I'll give the same answer again. > > Don't blame me for the pace of the work in this WG. I don't > have a stake in the outcome of the only thing we're allowed > to work on. And I don't believe a quarterly email saying "I > don't approve" (of the charter) is enough to put those who do > have a stake in the outcome off their work schedules. > > > As for the password method you proposed, I was at the last IETF > > meeting and you can also verify from he meeting minutes. > The consensus > > is to have more security reviews and the IPR analysis. > Also, since the > > use case it targeted maybe more broader than the EMU WG, it was > > suggested to bring up in SAAG as well, as multiple WGs can benefit > > from it. But the direction from the AD is to finish > existing work first. > > Yes, I remember. But you said, "Until we have a proof...we > will work on the tunneled method." IPR issues, yes that will > probably hold things up. But a proof, no. No proof is > required prior to adoption as a work item. > If it was then where's the security proof for either tunneled method? > > The real thing holding up adoption of EAP-pwd as a work > item is finishing work on the tunneled method. Which wouldn't > be such a bad thing if we were further along towards that > goal after Philly than we were after Vancouver and from the > looks of it we won't be any further after Dublin than we were > after Vancouver. :-( > > > Why are we keeping bring this up? > > You asked why are tunneled GTC and tunneled MD5 not OK; you > asked what is the use case for EAP-pwd. I answered both: > consistency principle and a need for robustness, respectively. > > Dan. > > >> -----Original Message----- > >> From: Dan Harkins [mailto:dharkins@lounge.org] > >> Sent: Monday, April 28, 2008 12:45 PM > >> To: Hao Zhou (hzhou) > >> Cc: Yoav Nir; emu@ietf.org > >> Subject: Re: [Emu] EMU charter revision > >> > >> > >> Hold on a second there Hao. A security proof was never a > >> requirement. > >> I'm not aware of any other IETF protocols that required security > >> proofs or even have security proofs. There is no formal proof > >> required of the tunneled methods and I think it would be very > >> difficult to do one. > >> > >> One of the problems with the tunneled solution is the > "consistency > >> principle" described in Hugo Krawczyk's SIGMA paper. The tunneled > >> methods violate that security requirement. And the fact that these > >> things can be repeatedly tunneled ad nauseum amplifies that > >> violation. > >> > >> A use case? Surely you have noticed the friction between > usability > >> and security. Security needs bootstrapping of some sort > and typically > >> that is problematic for many people especially when they need to > >> bootstrap a large number of distinct security > associations. So they > >> cut corners. > >> > >> How are these corners cut? "Do not verify server certificate". > >> That's why that little check box exists. > >> Because people don't want to enroll everybody/everything > into a CA. > >> So they use a self-signed certificate and check the "Do not verify > >> server certificate" check box. And then they send a password over > >> this "encrypted tunnel". > >> > >> So the use case is robust security that cannot be provisioned > >> insecurely. > >> It's scalable and doesn't require the cutting of corners by > >> administrators who are too busy (or frankly lazy) to do it the > >> Correct Way. I have used the "it's their network and if > they aren't > >> so concerned about security then who am I to force a workload on > >> them" comments in the past but it really is disingenuous. > >> > >> There are frightfully many deployments of > >> password-authentication-through- encrypted-TLS-tunnel that use > >> self-signed certificates and then something analogous to PAP. And > >> they are done that way because there isn't a viable standard > >> alternative. That is the use case for EAP-pwd. Oh, and it > can satisfy > >> the "consistency principle" too. :-) > >> > >> Dan. > >> > >> On Mon, April 28, 2008 8:10 am, Hao Zhou (hzhou) wrote: > >> > Yoav: > >> > > >> > I thought we had clear consensus in IETF 71 WG meeting and > >> instructed > >> > by the AD that while Dan's proposal is an interesting > one, but it > >> > doesn't work with the legacy password databases and thus > out-of the > >> > scope of the charter. Until we have the proof of security > >> analysis and > >> > clear of IPR issues, the WG is going to work on the tunnel > >> method. I > >> > think this is the use case, legacy password database, > the working > >> > group is currently working on and Gene is talking about > >> > > >> > Can you also explain why in the three use case you cited, > >> EAP-GTC or > >> > MD5 doesn't meet the requirements, as they are all running > >> inside an > >> > authenticated and encrypted tunnel? > >> > > >> > > >> > ________________________________ > >> > > >> > From: emu-bounces@ietf.org > >> [mailto:emu-bounces@ietf.org] On Behalf Of > >> > Yoav Nir > >> > Sent: Monday, April 28, 2008 8:13 AM > >> > To: emu@ietf.org > >> > Subject: Re: [Emu] EMU charter revision > >> > > >> > > >> > Gene Chang said: > >> > > >> > > >> > > >> > > >> > Dan, > >> > I am not sure I am able to clearly understand > >> the end result you > >> > seek. > >> > It seems there is a clear consensus for a > >> tunneled method. Are you > >> > pushing for the addition of a tunneled method? > >> > > >> > Ok... I am easily baited. What would you like > >> to see to achieve more > >> > than a snail race? I am assuming we both > >> believe the term "snail > >> > race" > >> > is a pejorative. Thus I ask you, how do we do better? > >> > > >> > I clearly hear your comment that there have > >> been a paucity of > >> > comments, > >> > if nothing else, simply to affirm we are on > >> track. I agree with the > >> > proposed charter. I am open to a discussion to > >> add a non-tunneled > >> > method > >> > if there is sufficient demand. A non-tunneled > >> method does not seem > >> > to > >> > promise enough features for the use cases that > >> interest me. > >> > > >> > Gene > >> > > >> > > >> > > >> > Hi Gene, > >> > > >> > > >> > You did not specify what the uses that interest you > >> are, and I don't > >> > know about the use cases that interest Dan either, but I > >> can speak for > >> > the use cases that interest me. > >> > > >> > > >> > EAP has been used in several cases as a magic way to use legacy > >> > credentials in protocols. I'll cite three examples: > >> > > >> > > >> > 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, > >> Apple, Cisco > >> > and others, where an EAP method is used to authenticate the user. > >> > 2. IKEv2 (RFC 4306) where EAP is used to magically > >> authenticate the > >> > initiator using non-cert and non-PSK credentials. > >> > 3. TEE (draft-nir-tls-eap-03) where EAP is used to > >> authenticate the > >> > user. > >> > > >> > > >> > In all three cases EAP is used by a protocol inside an > >> encrypted > >> > tunnel, where the server, which is either trusted by the > >> authenticator > >> > or co-located with it is already authenticated by a > >> certificate or PSK. > >> > IMO EAP was used in all cases an some magical way of making > >> passwords > >> > into a secure authentication mechanism. The problem is > that there > >> > really is no publicly available EAP method for passwords. > >> > > >> > > >> > Tunneled methods don't really make sense here. There's > >> no benefit in > >> > putting a TLS tunnel inside an IKEv2 exchange just to pass the > >> > password. Something like EAP-SRP would be great if it (a) > >> existed and > >> > (b) didn't have all that IPR baggage. The method that Dan > >> is proposing > >> > would also be beneficial here, if we could get a WG > behind it so we > >> > can get some solid security review. Instead, what > implementors are > >> > doing is EAP-MD5 or EAP-GTC, which don't quite meet the > >> requirements > >> > for any of the above protocols. > >> > > >> > > >> > Yoav > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Emu mailing list > >> > Emu@ietf.org > >> > https://www.ietf.org/mailman/listinfo/emu > >> > > >> > >> > >> > > > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 30 10:11:48 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516803A6849; Wed, 30 Apr 2008 10:11:48 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0753A6A0A for ; Wed, 30 Apr 2008 10:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLtPbiz2viB0 for ; Wed, 30 Apr 2008 10:11:40 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 26CD53A6A54 for ; Wed, 30 Apr 2008 10:11:40 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4E20110224072; Wed, 30 Apr 2008 10:11:42 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 30 Apr 2008 10:11:42 -0700 (PDT) Message-ID: <243d449380ed61ae8f6bea9582c5a516.squirrel@www.trepanning.net> In-Reply-To: <9958B444368E884DBB215F3FEF36F5B706DC56E5@xmb-rtp-212.amer.cisco.com> References: <9958B444368E884DBB215F3FEF36F5B706D44AE9@xmb-rtp-212.amer.cisco.com> <9958B444368E884DBB215F3FEF36F5B706D44C42@xmb-rtp-212.amer.cisco.com> <3060f5984089b9927367f4d8bec80071.squirrel@www.trepanning.net> <9958B444368E884DBB215F3FEF36F5B706DC56E5@xmb-rtp-212.amer.cisco.com> Date: Wed, 30 Apr 2008 10:11:42 -0700 (PDT) From: "Dan Harkins" To: "Hao Zhou (hzhou)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: Yoav Nir , emu@ietf.org Subject: Re: [Emu] EMU charter revision X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Hi Hao, On Wed, April 30, 2008 9:34 am, Hao Zhou (hzhou) wrote: > Dan wrote: > >> The real thing holding up adoption of EAP-pwd as a work >> item is finishing work on the tunneled method. Which wouldn't >> be such a bad thing if we were further along towards that >> goal after Philly than we were after Vancouver and from the >> looks of it we won't be any further after Dublin than we were >> after Vancouver. :-( > > I don't think tunnel method is the real thing holding up the EAP-pw as a > work item, so stop attacking the tunnel method or hurry it into some > kind of "sword fight." As others pointed out, EAP-pw might be quite > useful for multiple WGs and should be bring to SAAG. But security review > and IPR analysis need to be done before any WG is willing to take that > work, I think. Let me quote the chairman of this group, Joe Salowey: "The message from the ADs in the last meeting was pretty clear in that EAP-PWD style mechanisms is not something for the group to take on right now. This does not mean that we cannot take on an EAP-PWD style mechanism once we have made progress on the current charter items." And what are the current charter items? GPSK which is getting one last edit before going off to IETF LC and... the tunneled method! So until "we have made some progress" on the tunneled method the charter cannot change to make EAP-pwd in scope of the group. Let me mention once more I'm not interested in sword fights. Let's call it a "beauty contest". And it would be really nice if the contestants would finish their hair-dos and make-up and get into their evening gowns and out on the runway so the winner can get crowned. Dan. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 30 10:31:51 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE573A6849; Wed, 30 Apr 2008 10:31:51 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6746E3A689D for ; Wed, 30 Apr 2008 10:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE0G2pd9Lbhc for ; Wed, 30 Apr 2008 10:31:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9A27D3A6917 for ; Wed, 30 Apr 2008 10:31:49 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 30 Apr 2008 10:31:52 -0700 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 m3UHVqQe009518; Wed, 30 Apr 2008 10:31:52 -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.13.8/8.13.8) with ESMTP id m3UHVq6K009123; Wed, 30 Apr 2008 17:31:52 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); Wed, 30 Apr 2008 10:31:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 10:32:41 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision, Thread-Index: AciqMkKiVF3DAopwS3it/91Ti19LXgAq8Y/Q References: From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 30 Apr 2008 17:31:51.0754 (UTC) FILETIME=[13922AA0:01C8AAE8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2652; t=1209576712; x=1210440712; 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]=20EMU=20charter=20revision, |Sender:=20; bh=iYcN9fX+KESw3nDlnMRy+u50rHNKMECAzt5I+my9NnM=; b=BQEtCuxU3RAQUgtQduSup9I+8Tlt7KKYcJsClTXwyVfpc/Hrmru9Ql5wOf /ff4EzFh/2kkUBCuL7g6oUQzCfP2C8DYImSEyPB+tifbJUBVSAPDuwkhG4In irCw/kA31xx+dFP1V5wnhtHyeWPItmRgiCm3PjMfFm6fQ7yCaMZRs=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Emu] EMU charter revision, X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > Behalf Of Bernard Aboba > Sent: Tuesday, April 29, 2008 12:50 PM > To: emu@ietf.org > Subject: Re: [Emu] EMU charter revision, > > In re-reading this charter, I still don't think we're quite there: > > a. Why is there still a charter item for EAP-TLS? This work > has been completed, no? > [Joe] Yes it has. I originally argued to keep it in the charter for historical reasons, but now it seems to make more sense to remove it. > b. Attempting to extend EAP-TLS to support tunneling or > channel bindings is not appropriate. EAP-TLS already widely > deployed, with large investments in conformance tests. Given > the number of existing TLS-based tunneling protocols, such a > work item would serve no useful purpose. Let's focus on > adding channel binding support to tunnel methods. > [Joe] Jari had asked to keep this open to TLS. I think he was suggesting it could be done as a TLS extension and would not require tunneling. I agree that we do not want to extend EAP-TLS to do tunneling. How about: "- Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on supporting EAP channel bindings within the tunnel method. The possiblity of adding channel bindings to EAP-TLS through a TLS extension or other standard TLS mechanism may also be investigated. " > c. To some extent, I agree with Dan and Yoav with respect to > the need for password-based methods. Had such methods been > available earlier, it's questionable whether TLS tunneling > would have taken off to the extent that it has. Also, I > think that such methods, if specified in the IETF, would be > likely to be widely deployed. However, on the other hand I > think that this is really an issue for the entire security > area, not just for EMU. So I'd suggest that this issue be > brought up in SAAG. > [Joe] I agree. > ===================================================================== > Below is a revision to the EMU charter that is intended to > reflect the discussions in the Philadelphia meeting. Please > respond to the list if you approve of the charter or if you > have any comments on the charter. > I would like to have responses by 4/24. > > Thanks, > Joe > > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 30 16:53:53 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E533A677D; Wed, 30 Apr 2008 16:53:53 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1963A677D for ; Wed, 30 Apr 2008 16:53:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[AWL=1.590, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpPThO1rT0sx for ; Wed, 30 Apr 2008 16:53:52 -0700 (PDT) Received: from bay0-omc3-s6.bay0.hotmail.com (bay0-omc3-s6.bay0.hotmail.com [65.54.246.206]) by core3.amsl.com (Postfix) with ESMTP id 34CA73A63EC for ; Wed, 30 Apr 2008 16:53:48 -0700 (PDT) Received: from hotmail.com ([10.4.31.16]) by bay0-omc3-s6.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Apr 2008 16:53:51 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 30 Apr 2008 16:53:50 -0700 Message-ID: Received: from 131.107.0.105 by BLU137-DAV6.phx.gbl with DAV; Wed, 30 Apr 2008 23:53:47 +0000 X-Originating-IP: [131.107.0.105] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: "'Joseph Salowey \(jsalowey\)'" , References: In-Reply-To: Date: Wed, 30 Apr 2008 16:53:47 -0700 Message-ID: <000401c8ab1d$6e6408b0$4b2c1a10$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciqMkKiVF3DAopwS3it/91Ti19LXgAq8Y/QAA+tLKA= Content-Language: en-us X-OriginalArrivalTime: 30 Apr 2008 23:53:50.0507 (UTC) FILETIME=[703657B0:01C8AB1D] Subject: Re: [Emu] EMU charter revision, X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org [Joe] Jari had asked to keep this open to TLS. I think he was suggesting it could be done as a TLS extension and would not require tunneling. I agree that we do not want to extend EAP-TLS to do tunneling. How about: "- Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on supporting EAP channel bindings within the tunnel method. The possiblity of adding channel bindings to EAP-TLS through a TLS extension or other standard TLS mechanism may also be investigated. " [BA] I think we only want one mechanism for support of channel bindings in TLS-based methods. So it's ok to investigate a TLS extension vs. other mechanisms for supporting channel bindings, but I'd suggest we only want to choose one path. So my suggestion would be to modify the text as follows: - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on adding support for EAP channel bindings. Potential mechanisms for addition of support for channel bindings will be investigated, including tunneling of channel binding parameters, or a TLS extension or other standard TLS mechanism." _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 30 17:37:00 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6033A6B1D; Wed, 30 Apr 2008 17:37:00 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E78A3A67A1 for ; Wed, 30 Apr 2008 17:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axUxDJptv6HE for ; Wed, 30 Apr 2008 17:36:57 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 630A83A6C5F for ; Wed, 30 Apr 2008 17:36:36 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2008 17:36:37 -0700 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 m410abjB025519 for ; Wed, 30 Apr 2008 17:36:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m410abLI024522 for ; Thu, 1 May 2008 00:36:37 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 17:36:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 17:36:40 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EMU charter update Thread-Index: AcirI2xCzYKYEzQCTY+6NbxEUh0ttg== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 01 May 2008 00:36:37.0148 (UTC) FILETIME=[6A0CADC0:01C8AB23] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3149; t=1209602197; x=1210466197; 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:=20EMU=20charter=20update |Sender:=20; bh=OgJerpdVA4eRCPQ4N77vECOE+3ZoZTIUGAzNENDEalc=; b=DlHtGT919dWD25Rz2ucHPoGMVHjSXOM/HUDquRWE9vbnkuxL8HxI84fcxn YQ8gipUtdhcdL9tAPGPXaOyE8CEIQuo86hcA5fleX5qlKFMfmZgSa15Yl1pP XUE0zw1c7jZkOAIEJBHZX4XRSi52K5Oo0M81yIrkWSptf9VKUIUbI=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Emu] EMU charter update X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org In order to get things moving we will send the following charter update to Pasi tomorrow. I will also let Pasi and Tim know there is interest in secure password methods and they should consider it as a topic for SAAG. ------------------------ Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods, but some are documented in informational RFCs. In the past the lack of documented, open specifications has been a deployment and interoperability problem. There are currently only two EAP methods in the standards track that implement features such as key derivation that are required for many modern applications. Authentication types and credentials continue to evolve as do requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet requirements relevant to EAP methods in RFC 3748, RFC 4017, RFC 4962 and EAP Keying: - A mechanism based on strong shared secrets. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. - A mechanism to support extensible communication within a TLS protected tunnel. This mechanism must support channel bindings in order to meet RFC 4962 requirements. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on supporting EAP channel bindings within the tunnel method. The possibility of adding channel bindings to EAP-TLS through a TLS extension or other standard TLS mechanism may also be investigated. - A mechanism that makes use of existing password databases such as AAA databases. This item will be based on the above tunnel method. Goals and Milestones: Done Form design team to work on strong shared secret mechanism Done Submit 2716bis I-D Done Submit first draft of shared secret mechanism I-D Done Form password based mechanism design team Done Submit 2716bis draft to IESG for Proposed Standard May 2008 Submit Strong Shared Secret Mechanism to IESG May 2008 Submit Tunnel and Password Method requirements first Draft Sep 2008 Submit EAP Channel Bindings First Draft Sep 2008 Submit Tunnel Method first draft Oct 2008 Submit TLS based method channel binding first draft Oct 2008 Submit Password Method first draft Jan 2009 Send EAP Channel Bindings to IESG Mar 2009 Send Tunnel Method to IESG Apr 2009 Send TLS based method channel binding to IESG Apr 2009 Send Password based method to IESG _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 30 17:56:36 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3BC3A6C33; Wed, 30 Apr 2008 17:56:36 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26743A6A68 for ; Wed, 30 Apr 2008 17:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2zV5fGikc4o for ; Wed, 30 Apr 2008 17:56:34 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EE3243A6B76 for ; Wed, 30 Apr 2008 17:56:25 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Apr 2008 17:56:28 -0700 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 m410uSwG028573; Wed, 30 Apr 2008 17:56:28 -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.13.8/8.13.8) with ESMTP id m410uSNu002513; Thu, 1 May 2008 00:56:28 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); Wed, 30 Apr 2008 17:56:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 17:57:17 -0700 Message-ID: In-Reply-To: <000401c8ab1d$6e6408b0$4b2c1a10$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision, Thread-Index: AciqMkKiVF3DAopwS3it/91Ti19LXgAq8Y/QAA+tLKAAAlFdAA== References: <000401c8ab1d$6e6408b0$4b2c1a10$@com> From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 01 May 2008 00:56:28.0460 (UTC) FILETIME=[302076C0:01C8AB26] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1818; t=1209603388; x=1210467388; 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]=20EMU=20charter=20revision, |Sender:=20; bh=57BM+gBCziz1ffxCqswIh/Vnbk4Top6ookPLM/cQ40s=; b=Hg0y69dRl+aN0y/B5//Vz20wwsZjrP4E9pPzWxpZV5W27L+wgbaT3BmTkU 26q3SZQfEcAVLlL/CGp41GbO1WbTgVLDn+V6se7DzwnNjRIc3eeQPiqvcZpH G2pTnsb4g2; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Emu] EMU charter revision, X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org I was offline when I sent the charter update. I'm not sure there has to be only one mechanism, but I think it would be a desirable outcome. I like your text and will include it. Thanks, Joe > -----Original Message----- > From: Bernard Aboba [mailto:Bernard_Aboba@hotmail.com] > Sent: Wednesday, April 30, 2008 4:54 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] EMU charter revision, > > [Joe] Jari had asked to keep this open to TLS. I think he > was suggesting it could be done as a TLS extension and would > not require tunneling. I agree that we do not want to extend > EAP-TLS to do tunneling. > > How about: > > "- Enable a TLS-based EAP method to support channel bindings. > This item will not generate a new method, rather it will > focus on supporting EAP channel bindings within the tunnel > method. The possiblity of adding channel bindings to EAP-TLS > through a TLS extension or other standard TLS mechanism may > also be investigated. " > > [BA] I think we only want one mechanism for support of > channel bindings in TLS-based methods. So it's ok to > investigate a TLS extension vs. > other mechanisms for supporting channel bindings, but I'd > suggest we only want to choose one path. So my suggestion > would be to modify the text as follows: > > - Enable a TLS-based EAP method to support channel bindings. > This item will not generate a new method, rather it will > focus on adding support for EAP channel bindings. Potential > mechanisms for addition of support for channel bindings will > be investigated, including tunneling of channel > binding parameters, or a TLS extension or other standard TLS > mechanism." > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Apr 30 18:33:26 2008 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772C43A6884; Wed, 30 Apr 2008 18:33:26 -0700 (PDT) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABBC73A6884 for ; Wed, 30 Apr 2008 18:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 577uZJaVOdHc for ; Wed, 30 Apr 2008 18:33:24 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 779EB3A6848 for ; Wed, 30 Apr 2008 18:33:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,419,1204520400"; d="scan'208";a="6862989" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2008 21:33:24 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m411XOOq028906; Wed, 30 Apr 2008 21:33:24 -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.13.8/8.13.8) with ESMTP id m411XOA1020684; Thu, 1 May 2008 01:33:24 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 21:33:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 21:33:45 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B706DC59E0@xmb-rtp-212.amer.cisco.com> In-Reply-To: <000401c8ab1d$6e6408b0$4b2c1a10$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter revision, Thread-Index: AciqMkKiVF3DAopwS3it/91Ti19LXgAq8Y/QAA+tLKAAA6PJ0A== References: <000401c8ab1d$6e6408b0$4b2c1a10$@com> From: "Hao Zhou (hzhou)" To: "Bernard Aboba" , "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 01 May 2008 01:33:24.0427 (UTC) FILETIME=[58F231B0:01C8AB2B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1810; t=1209605604; x=1210469604; 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]=20EMU=20charter=20revision, |Sender:=20 |To:=20=22Bernard=20Aboba=22=20, =0A=20=20=20=20=20=20=20=20=22Joseph=20Salowey=20(jsalowey)= 22=20,=20; bh=nV+fOp8472Pj/Q5pfUumX1q0mZcWfyOds+8EcZa3xyA=; b=arWJ/kOGT0sjarSg2q+Vpq4Vwl7DHHl8wVAaP49z/AR5S0JOTSj/FK8aYk kFDTKUn77wGm6Qe28s9FC7nm5Zugs1y5mfrFWgsQ5ukFr3Oeqq01PrVyqNmM 9YgZyF2r+A; Authentication-Results: rtp-dkim-2; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Emu] EMU charter revision, X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org I like Bernard's text better. > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > Behalf Of Bernard Aboba > Sent: Wednesday, April 30, 2008 7:54 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: Re: [Emu] EMU charter revision, > > [Joe] Jari had asked to keep this open to TLS. I think he > was suggesting it could be done as a TLS extension and would > not require tunneling. I agree that we do not want to extend > EAP-TLS to do tunneling. > > How about: > > "- Enable a TLS-based EAP method to support channel bindings. > This item will not generate a new method, rather it will > focus on supporting EAP channel bindings within the tunnel > method. The possiblity of adding channel bindings to EAP-TLS > through a TLS extension or other standard TLS mechanism may > also be investigated. " > > [BA] I think we only want one mechanism for support of > channel bindings in TLS-based methods. So it's ok to > investigate a TLS extension vs. > other mechanisms for supporting channel bindings, but I'd > suggest we only want to choose one path. So my suggestion > would be to modify the text as follows: > > - Enable a TLS-based EAP method to support channel bindings. > This item will not generate a new method, rather it will > focus on adding support for EAP channel bindings. Potential > mechanisms for addition of support for channel bindings will > be investigated, including tunneling of channel > binding parameters, or a TLS extension or other standard TLS > mechanism." > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu