From jsalowey@cisco.com Wed May 11 09:10:43 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB42AE0800 for ; Wed, 11 May 2011 09:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYTyyzcolRkV for ; Wed, 11 May 2011 09:10:43 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 4B226E07C2 for ; Wed, 11 May 2011 09:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1308; q=dns/txt; s=iport; t=1305130243; x=1306339843; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rjwv0XZ0n8UItdbjIJIDqVlCYL5hFvV4vmMilp8h6Qo=; b=CQTnZQnO4rGZM5/a0C12vfub/IhCFNpiKogZ4nZyqnO8vG8ngrZwj4Ql fTyzlDygrvpgusIOZeNPvNDuPtcQ6k+OMi3T1V9cmmXQv+W4/af3HShUg HTU5tM7k/zsfGnrpCC4XfX7+b2bLNLblPPIdr2384TQNHCwpI/1/n4FTF w=; X-IronPort-AV: E=Sophos;i="4.64,353,1301875200"; d="scan'208";a="354917171" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 11 May 2011 16:10:43 +0000 Received: from [10.33.249.93] ([10.33.249.93]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4BGAg9m013765; Wed, 11 May 2011 16:10:42 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <0E03D014-2A60-4908-B72D-532E113B818D@cisco.com> Date: Wed, 11 May 2011 09:10:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1EDB6C2E-B39A-49A6-A91A-4BDDCA99BD94@cisco.com> References: <0E03D014-2A60-4908-B72D-532E113B818D@cisco.com> To: Joe Salowey X-Mailer: Apple Mail (2.1084) Cc: emu@ietf.org Subject: Re: [Emu] Channel Binding Consensus Call X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 16:10:43 -0000 The consensus for the first topic affirms the current direction of the = document. =20 The consensus for the second question is a bit rougher, but indicates a = preference for option 1. =20 The document needs to be revised to reflect any changes as a result of = this call.=20 On Apr 18, 2011, at 11:11 AM, Joe Salowey wrote: > This is a consensus call to validate the direction the = draft-ietf-emu-chbind-07 and confirm the consensus around the encoding = of the channel binding TLV. Please respond to the following questions = by May 2, 2011. =20 >=20 > 1. Do you agree with the direction taken in draft-ietf-emu-chbind-07. = More specifically the usage of a channel binding specific TLV, the = support of multiple name spaces, and that the server indicates to the = client what attributes were validated. =20 >=20 > 2. Two encoding method where described in IETF-80 in the following = presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf. Do you = prefer encoding option 1, where attributes are encoded individually or = option 2 where attributes in the same namespace are grouped together. =20= >=20 > Cheers, >=20 > Joe > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From aland@deployingradius.com Fri May 13 08:29:06 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57813E0787 for ; Fri, 13 May 2011 08:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1rjb4E3BH8G for ; Fri, 13 May 2011 08:29:05 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE3DE077C for ; Fri, 13 May 2011 08:29:05 -0700 (PDT) Message-ID: <4DCD4E3F.70601@deployingradius.com> Date: Fri, 13 May 2011 17:29:03 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "emu@ietf.org" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 15:29:06 -0000 Since we have reached WG consensus on the method, can the authors of draft-zhou-emu-eap-fastv2-00.txt please re-submit the document as: draft-ietf-emu-eap-tunnel-method-00.txt The reason for the name change is that there have been questions raised about whether this document should be left as EAP-FASTv2, or whether it should request allocation of a new EAP type. Since the document name (individual draft) currently reflects the EAP type name, abstracting that would be useful. That way the document name will not change no matter what the WG decides to do. Anyone with opinions either way is requested to discuss the pros and cons of the issue. Alan DeKok. From internet-drafts@ietf.org Fri May 13 10:58:33 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D27E083A; Fri, 13 May 2011 10:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqPOQFiA+Rmg; Fri, 13 May 2011 10:58:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AADE0831; Fri, 13 May 2011 10:58:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110513175832.7617.48403.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2011 10:58:32 -0700 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-eap-tunnel-method-00.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 17:58:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of th= e IETF. Title : Flexible Authentication via Secure Tunneling Extensible = Authentication Protocol (EAP-FAST) Version 2 Author(s) : Hao Zhou Nancy Cam-Winget Joseph Salowey Stephen Hanna Filename : draft-ietf-emu-eap-tunnel-method-00.txt Pages : 74 Date : 2011-05-13 This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol version 2. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-tunnel-method-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-emu-eap-tunnel-method-00.txt From gwz@net-zen.net Fri May 13 18:31:51 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5874FE07C5 for ; Fri, 13 May 2011 18:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nRDHiUpM0hU for ; Fri, 13 May 2011 18:31:50 -0700 (PDT) Received: from p3plsmtpa01-05.prod.phx3.secureserver.net (p3plsmtpa01-05.prod.phx3.secureserver.net [72.167.82.85]) by ietfa.amsl.com (Postfix) with SMTP id C89ADE0663 for ; Fri, 13 May 2011 18:31:50 -0700 (PDT) Received: (qmail 10456 invoked from network); 14 May 2011 01:31:50 -0000 Received: from unknown (124.120.71.84) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 14 May 2011 01:31:49 -0000 Message-ID: <4DCDDB82.9070605@net-zen.net> Date: Sat, 14 May 2011 08:31:46 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alan DeKok References: <4DCD4E3F.70601@deployingradius.com> In-Reply-To: <4DCD4E3F.70601@deployingradius.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------090107040305030607070100" Cc: "emu@ietf.org" Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 01:31:51 -0000 This is a multi-part message in MIME format. --------------090107040305030607070100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/13/2011 10:29 PM, Alan DeKok wrote: > Since we have reached WG consensus on the method, can the authors of > > draft-zhou-emu-eap-fastv2-00.txt > > please re-submit the document as: > > draft-ietf-emu-eap-tunnel-method-00.txt > > The reason for the name change is that there have been questions > raised about whether this document should be left as EAP-FASTv2, or > whether it should request allocation of a new EAP type. > > Since the document name (individual draft) currently reflects the EAP > type name, abstracting that would be useful. That way the document name > will not change no matter what the WG decides to do. > > Anyone with opinions either way is requested to discuss the pros and > cons of the issue. There seem to be two issues here: renaming the draft & allocating a new EAP type. For which one are opinions being solicited? ... --------------090107040305030607070100 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------090107040305030607070100-- From aland@deployingradius.com Fri May 13 23:40:43 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CDFE06DE for ; Fri, 13 May 2011 23:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msJxYKh4veCj for ; Fri, 13 May 2011 23:40:42 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 1920DE06AC for ; Fri, 13 May 2011 23:40:41 -0700 (PDT) Message-ID: <4DCE23E6.1050003@deployingradius.com> Date: Sat, 14 May 2011 08:40:38 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Glen Zorn References: <4DCD4E3F.70601@deployingradius.com> <4DCDDB82.9070605@net-zen.net> In-Reply-To: <4DCDDB82.9070605@net-zen.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "emu@ietf.org" Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 06:40:43 -0000 Glen Zorn wrote: > There seem to be two issues here: renaming the draft & allocating a new > EAP type. For which one are opinions being solicited? Allocating a new EAP type. The draft name "eap-tunnel-method" describes the protocol accurately. Alan DeKok. From dharkins@lounge.org Sat May 14 10:33:03 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8B1E06AF for ; Sat, 14 May 2011 10:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztw4tHiZrvRP for ; Sat, 14 May 2011 10:33:02 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 99B08E0659 for ; Sat, 14 May 2011 10:33:01 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 85C4910224050; Sat, 14 May 2011 10:33:01 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 14 May 2011 10:33:01 -0700 (PDT) Message-ID: In-Reply-To: <4DCD4E3F.70601@deployingradius.com> References: <4DCD4E3F.70601@deployingradius.com> Date: Sat, 14 May 2011 10:33:01 -0700 (PDT) From: "Dan Harkins" To: "Alan DeKok" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "emu@ietf.org" Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 17:33:03 -0000 My opinion is we request allocation of a new EAP method value. And I suggest that the new EAP method have a name/description of "Extensible Tunneled Authentication (ETA)". Dan. On Fri, May 13, 2011 8:29 am, Alan DeKok wrote: > Since we have reached WG consensus on the method, can the authors of > > draft-zhou-emu-eap-fastv2-00.txt > > please re-submit the document as: > > draft-ietf-emu-eap-tunnel-method-00.txt > > The reason for the name change is that there have been questions > raised about whether this document should be left as EAP-FASTv2, or > whether it should request allocation of a new EAP type. > > Since the document name (individual draft) currently reflects the EAP > type name, abstracting that would be useful. That way the document name > will not change no matter what the WG decides to do. > > Anyone with opinions either way is requested to discuss the pros and > cons of the issue. > > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From hartmans@mit.edu Sat May 14 12:36:43 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C12E0701 for ; Sat, 14 May 2011 12:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzAQkIvarWFk for ; Sat, 14 May 2011 12:36:42 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3BBE0700 for ; Sat, 14 May 2011 12:36:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (port-213-148-154-218.static.qsc.de [213.148.154.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 624392034A; Sat, 14 May 2011 15:32:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3FDB140F6; Sat, 14 May 2011 15:36:36 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <4DCD4E3F.70601@deployingradius.com> <4DCDDB82.9070605@net-zen.net> <4DCE23E6.1050003@deployingradius.com> Date: Sat, 14 May 2011 15:36:36 -0400 In-Reply-To: <4DCE23E6.1050003@deployingradius.com> (Alan DeKok's message of "Sat, 14 May 2011 08:40:38 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "emu@ietf.org" Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 19:36:43 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Glen Zorn wrote: >> There seem to be two issues here: renaming the draft & allocating >> a new EAP type. For which one are opinions being solicited? Alan> Allocating a new EAP type. My opinion is that we have two options: 1) Allocate a new method type now. 2) Revisit this issue at the end. I don't think we'll be in a position to decide for sure we can keep the method type until we reach WGLC. However we can always short-circuit the issue early. From aland@deployingradius.com Sat May 14 13:58:59 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3F8E06E7 for ; Sat, 14 May 2011 13:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-E-O39ez2NC for ; Sat, 14 May 2011 13:58:58 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 99B1FE06B9 for ; Sat, 14 May 2011 13:58:58 -0700 (PDT) Message-ID: <4DCEED0F.6050801@deployingradius.com> Date: Sat, 14 May 2011 22:58:55 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Dan Harkins References: <4DCD4E3F.70601@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "emu@ietf.org" Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 20:58:59 -0000 Dan Harkins wrote: > My opinion is we request allocation of a new EAP method value. > And I suggest that the new EAP method have a name/description of > "Extensible Tunneled Authentication (ETA)". I'd like to know more about the pros and cons. What is the value in keeping the existing EAP-FAST code? What is the value in changing to a new code? Alan DeKok. From dharkins@lounge.org Sat May 14 15:41:32 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E06E06DA for ; Sat, 14 May 2011 15:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSBMv-9jI1yY for ; Sat, 14 May 2011 15:41:32 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 07402E06D7 for ; Sat, 14 May 2011 15:41:32 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9020B1022400A; Sat, 14 May 2011 15:41:31 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 14 May 2011 15:41:31 -0700 (PDT) Message-ID: <7ce5b23c7a45c04064213b00db636a3f.squirrel@www.trepanning.net> In-Reply-To: <4DCEED0F.6050801@deployingradius.com> References: <4DCD4E3F.70601@deployingradius.com> <4DCEED0F.6050801@deployingradius.com> Date: Sat, 14 May 2011 15:41:31 -0700 (PDT) From: "Dan Harkins" To: "Alan DeKok" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "emu@ietf.org" Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 22:41:32 -0000 On Sat, May 14, 2011 1:58 pm, Alan DeKok wrote: > Dan Harkins wrote: >> My opinion is we request allocation of a new EAP method value. >> And I suggest that the new EAP method have a name/description of >> "Extensible Tunneled Authentication (ETA)". > > I'd like to know more about the pros and cons. > > What is the value in keeping the existing EAP-FAST code? > > What is the value in changing to a new code? > > Alan DeKok. > Having a new EAP method value would be more ecumenical. Dan. From gwz@net-zen.net Sat May 14 18:18:35 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CBAE06C4 for ; Sat, 14 May 2011 18:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgkvV51t1rUE for ; Sat, 14 May 2011 18:18:35 -0700 (PDT) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by ietfa.amsl.com (Postfix) with SMTP id 0F7CAE066E for ; Sat, 14 May 2011 18:18:34 -0700 (PDT) Received: (qmail 10225 invoked from network); 15 May 2011 01:18:33 -0000 Received: from unknown (124.122.83.151) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 15 May 2011 01:18:33 -0000 Message-ID: <4DCF29E2.1070208@net-zen.net> Date: Sun, 15 May 2011 08:18:26 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Sam Hartman References: <4DCD4E3F.70601@deployingradius.com> <4DCDDB82.9070605@net-zen.net> <4DCE23E6.1050003@deployingradius.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------000608030903060409050300" Cc: "emu@ietf.org" Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 01:18:35 -0000 This is a multi-part message in MIME format. --------------000608030903060409050300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/15/2011 2:36 AM, Sam Hartman wrote: >>>>>> "Alan" == Alan DeKok writes: > > Alan> Glen Zorn wrote: > >> There seem to be two issues here: renaming the draft & allocating > >> a new EAP type. For which one are opinions being solicited? > > Alan> Allocating a new EAP type. > > My opinion is that we have two options: > > 1) Allocate a new method type now. > > 2) Revisit this issue at the end. > > I don't think we'll be in a position to decide for sure we can keep the > method type until we reach WGLC. I don't follow your logic here. Allocating a new EAP type is, practically speaking, nothing. > > However we can always short-circuit the issue early. The only question I can see is whether or not emu really is an extension of the Cisco marketing department. One would like to think that the answer is obvious but maybe not... ... --------------000608030903060409050300 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------000608030903060409050300-- From hartmans@mit.edu Mon May 16 05:39:18 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EF5E06A1 for ; Mon, 16 May 2011 05:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.406 X-Spam-Level: X-Spam-Status: No, score=-100.406 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-oUDRczD62p for ; Mon, 16 May 2011 05:39:17 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id AC74CE0669 for ; Mon, 16 May 2011 05:39:17 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [80.187.200.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4064820008 for ; Mon, 16 May 2011 08:35:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 565154065; Mon, 16 May 2011 08:39:14 -0400 (EDT) From: Sam Hartman To: emu@ietf.org Date: Mon, 16 May 2011 08:39:14 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 12:39:18 -0000 I'd like to confirm my understanding. The current text proposes the use of eap type code 43. I'd like to confirm that code is in use both by implementations of eap-fast v1 and v2. Does the current text mandate support for eap-fast v1 as well as v2? Is it expected that most implementations will support v1 and v2? Is it desired that people be able to create a v2 only implementation? I think based on answers to these questions I at least will be able to better determine my opinion on the type code issue. From aland@deployingradius.com Mon May 16 06:02:47 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4F0E06A1 for ; Mon, 16 May 2011 06:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsu9DWGHuV9t for ; Mon, 16 May 2011 06:02:46 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 7B619E06A0 for ; Mon, 16 May 2011 06:02:46 -0700 (PDT) Message-ID: <4DD12073.7020500@deployingradius.com> Date: Mon, 16 May 2011 15:02:43 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 13:02:47 -0000 Sam Hartman wrote: > I'd like to confirm that code is in use both by implementations of > eap-fast v1 and v2. As a backup question: Are there *any* implementations of v2? The draft does not make it clear if this is the case. Can the authors step in and give their opinion? > Does the current text mandate support for eap-fast v1 as well as v2? Yes and no. Section 3.1 says: The version negotiation procedure guarantees that the EAP-FAST peer and server will agree to the latest version supported by both parties. If version negotiation fails, then use of EAP-FAST will not be possible, and another mutually acceptable EAP method will need to be negotiated if authentication is to proceed. This makes it *possible* for an implementation to support v2 only. This will require starting version negotiation for EAP-FASTv2, and then switching to a different EAP method. Implementations traditionally have found it difficult to start one EAP method, and then to switch to another one. This means that v2-only implementations may be difficult to deploy in practice. > Is it expected that most implementations will support v1 and v2? > > Is it desired that people be able to create a v2 only implementation? I will partially avoid those two questions, and say that it should be possible to deploy only the EMU tunneled method. Alan DeKok. From hzhou@cisco.com Mon May 16 07:33:14 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F3CE06D9 for ; Mon, 16 May 2011 07:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHGERCxN9Cwr for ; Mon, 16 May 2011 07:33:14 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id EC118E0699 for ; Mon, 16 May 2011 07:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=2943; q=dns/txt; s=iport; t=1305556394; x=1306765994; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=WSOMXhIFoaNWjCanjz4sdeWcgBe5GAD5+jJhG8w6rcI=; b=jYWlXLhXfNfiK4i6redUvBjHVYGRcQ75isgaJoDvSHo21CQCP9M0l1ww jGbr4vjigYBiGwON8uJjX3W4fDm6PcMIvE+bQDKLE/DoCn/zhFLVTQ67K nixYSSmCIg+/hfi5gf95p3ckqtEcdq+SS9JdjB4uaM2Ck22HhjG4mpGuG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM400U2tJXHA/2dsb2JhbACmFneIcKAZnXKGGQSQEYQ4ighR X-IronPort-AV: E=Sophos;i="4.64,374,1301875200"; d="scan'208";a="233163451" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-1.cisco.com with ESMTP; 16 May 2011 14:32:11 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p4GEWBAN008322; Mon, 16 May 2011 14:32:11 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 May 2011 09:32:11 -0500 Received: from 10.21.107.248 ([10.21.107.248]) by XMB-RCD-202.cisco.com ([72.163.62.209]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Mon, 16 May 2011 14:32:10 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 16 May 2011 10:32:09 -0400 From: Hao Zhou To: Alan DeKok , Sam Hartman Message-ID: Thread-Topic: [Emu] Some questions about eap type code and the tunnel method Thread-Index: AcwT1gl8qkMxN8M3Jky6aYGwb4L6Ow== In-Reply-To: <4DD12073.7020500@deployingradius.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 May 2011 14:32:11.0134 (UTC) FILETIME=[0AC259E0:01CC13D6] Cc: emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 14:33:14 -0000 Alan: Please see responses inline below. On 5/16/11 9:02 AM, "Alan DeKok" wrote: > Sam Hartman wrote: >> I'd like to confirm that code is in use both by implementations of >> eap-fast v1 and v2. > [HZ] Yes. Type Code 43 is being used by EAP-FAST v1 and widely deployed. > As a backup question: Are there *any* implementations of v2? > [HZ] Not right now. Once this draft is finalized, it will be. > The draft does not make it clear if this is the case. Can the authors > step in and give their opinion? > >> Does the current text mandate support for eap-fast v1 as well as v2? > [HZ] The draft doesn't mandate support for v1 and v2, it's up to each implementation. How, ever, due to the small changes from V2 to v1, I suspect most of them could support both easily. Doesn't running code mean something in IETF? > Yes and no. Section 3.1 says: > > The version negotiation procedure guarantees that the EAP-FAST peer > and server will agree to the latest version supported by both > parties. If version negotiation fails, then use of EAP-FAST will not > be possible, and another mutually acceptable EAP method will need to > be negotiated if authentication is to proceed. > > This makes it *possible* for an implementation to support v2 only. > This will require starting version negotiation for EAP-FASTv2, and then > switching to a different EAP method. > > Implementations traditionally have found it difficult to start one EAP > method, and then to switch to another one. This means that v2-only > implementations may be difficult to deploy in practice. > [HZ] Agree. Considering all devices out there supporting EAP-FASTv1 and it may take a while for them to support the new method, most server implementations would probably support both. >> Is it expected that most implementations will support v1 and v2? >> [HZ] See above. >> Is it desired that people be able to create a v2 only implementation? > > I will partially avoid those two questions, and say that it should be > possible to deploy only the EMU tunneled method. [HZ] Realistically, until the new tunnel method is published and adopted by all servers and supplicants, implementation would have to support older tunnel methods, including EAP-FASTv1. By retaining the EAP-FAST type, customers wouldn't have to be educated with another new EAP type and validate its security, and they would have a smoother migration path, from v1 to v2. Implementers could reuse the same code. I thought one of the reasons EAP-FASTv2 is adopted is because of its existing code and deployment, with small changes to meet EMU requirements. Changing the method name and type would totally negativate that. > > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From aland@deployingradius.com Mon May 16 07:45:42 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FE4E06C6 for ; Mon, 16 May 2011 07:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOYF4EBQRiLR for ; Mon, 16 May 2011 07:45:41 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5B8E067E for ; Mon, 16 May 2011 07:45:41 -0700 (PDT) Message-ID: <4DD13892.404@deployingradius.com> Date: Mon, 16 May 2011 16:45:38 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Hao Zhou References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 14:45:42 -0000 Hao Zhou wrote: >> As a backup question: Are there *any* implementations of v2? >> > [HZ] Not right now. Once this draft is finalized, it will be. OK. That means there are no costs to choosing a new EAP type code. > [HZ] The draft doesn't mandate support for v1 and v2, it's up to each > implementation. How, ever, due to the small changes from V2 to v1, I suspect > most of them could support both easily. Doesn't running code mean something > in IETF? Speaking as an individual contributor and implementor, I think the v2 draft is a lot clearer than the v1 specification. It looks to be simpler, too. > [HZ] Agree. Considering all devices out there supporting EAP-FASTv1 and it > may take a while for them to support the new method, most server > implementations would probably support both. Again, speaking as an individual, some server software doesn't support EAP-FAST. There have been few complaints so far about that. > [HZ] Realistically, until the new tunnel method is published and adopted by > all servers and supplicants, implementation would have to support older > tunnel methods, including EAP-FASTv1. See above. > By retaining the EAP-FAST type, > customers wouldn't have to be educated with another new EAP type and > validate its security, and they would have a smoother migration path, from > v1 to v2. Implementers could reuse the same code. I agree that cost of deployment is a factor to consider. > I thought one of the > reasons EAP-FASTv2 is adopted is because of its existing code and > deployment, with small changes to meet EMU requirements. Changing the method > name and type would totally negativate that. I'm not sure how changing the type code adds deployment costs. The new version has to be deployed no matter what. Alan DeKok. From dharkins@lounge.org Mon May 16 10:44:21 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A79BE0719 for ; Mon, 16 May 2011 10:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp-qp2IPlSj1 for ; Mon, 16 May 2011 10:44:20 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 48C5CE06D3 for ; Mon, 16 May 2011 10:44:20 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C85321022400A; Mon, 16 May 2011 10:44:19 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 16 May 2011 10:44:19 -0700 (PDT) Message-ID: <836089fafc4c9715600ee8535d055ab6.squirrel@www.trepanning.net> In-Reply-To: References: Date: Mon, 16 May 2011 10:44:19 -0700 (PDT) From: "Dan Harkins" To: "Hao Zhou" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 17:44:21 -0000 Hi Hao, On Mon, May 16, 2011 7:32 am, Hao Zhou wrote: > I thought one of the reasons EAP-FASTv2 is adopted is because of its > existing code and deployment, with small changes to meet EMU > requirements. Changing the method name and type would totally > negativate that. After the "vote" I asked several people who did not have a dog in the fight why they did not "vote" for TEAM and the overwhelming response I got was the way TEAM did passwords. It had nothing to do with deployment. regards, Dan. From dstanley1389@gmail.com Mon May 16 11:29:47 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52263E0790 for ; Mon, 16 May 2011 11:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KynJlTWeSZUd for ; Mon, 16 May 2011 11:29:46 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D60FE0651 for ; Mon, 16 May 2011 11:29:45 -0700 (PDT) Received: by wwa36 with SMTP id 36so3721471wwa.13 for ; Mon, 16 May 2011 11:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fScjFxksKg38p5fKJgQAbEA/8s7FN8DTXpIL1DPGLno=; b=H0vk+GgctiIv5bFp+44wMQEwjqKnB5/R7wjXl/BBGheYLSbDVy5j4KvAg4OIaieYZp DmSkXhJuVi7Vg1xrJCwY9M+BEBRSviF9DEbsKaE4k55S74kRBVL+7j1T/fC3Qn03gw/D BGzh6KfSfYk4WaF8v1gwKceIamTUYlN9CHLUs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FQHOvernx98G3JCfyi/xbfF980nOZMDpA1B+K0uMzXN3r7aSOxUZEr+fT66obDKQ6c 4xWGenXvO4z8EzOFRROAfQ1q26syTxkfLvGu9zIjy643/fkQijNJvP82Rn/6y98bw9tN tA1pra5Xxoa7gf/DB4erfIOXgjssT92DOnKAU= MIME-Version: 1.0 Received: by 10.227.159.205 with SMTP id k13mr1395374wbx.30.1305570585222; Mon, 16 May 2011 11:29:45 -0700 (PDT) Received: by 10.227.135.72 with HTTP; Mon, 16 May 2011 11:29:45 -0700 (PDT) In-Reply-To: <4DCF29E2.1070208@net-zen.net> References: <4DCD4E3F.70601@deployingradius.com> <4DCDDB82.9070605@net-zen.net> <4DCE23E6.1050003@deployingradius.com> <4DCF29E2.1070208@net-zen.net> Date: Mon, 16 May 2011 11:29:45 -0700 Message-ID: From: Dorothy Stanley To: Glen Zorn Content-Type: multipart/alternative; boundary=00248c0ee8a0f61fe304a368d6bd Cc: Sam Hartman , "emu@ietf.org" Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 18:29:47 -0000 --00248c0ee8a0f61fe304a368d6bd Content-Type: text/plain; charset=ISO-8859-1 I support allocating a new method type for the new standard method, sooner, rather than later. The new method is defined by an IETF group, based on submissions/modifications from multiple parties, and should carry/use an IETF rather than specific vendor identifier. Dorothy On Sat, May 14, 2011 at 6:18 PM, Glen Zorn wrote: > On 5/15/2011 2:36 AM, Sam Hartman wrote: > >>>>>> "Alan" == Alan DeKok writes: > > > > Alan> Glen Zorn wrote: > > >> There seem to be two issues here: renaming the draft & allocating > > >> a new EAP type. For which one are opinions being solicited? > > > > Alan> Allocating a new EAP type. > > > > My opinion is that we have two options: > > > > 1) Allocate a new method type now. > > > > 2) Revisit this issue at the end. > > > > I don't think we'll be in a position to decide for sure we can keep the > > method type until we reach WGLC. > > I don't follow your logic here. Allocating a new EAP type is, > practically speaking, nothing. > > > > > However we can always short-circuit the issue early. > > The only question I can see is whether or not emu really is an extension > of the Cisco marketing department. One would like to think that the > answer is obvious but maybe not... > > ... > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > > --00248c0ee8a0f61fe304a368d6bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support allocating a new method type for the new standard method, sooner,= rather than later.

The new method is defined by an IETF group, base= d on submissions/modifications
from multiple parties, and should carry/u= se an IETF rather than specific vendor identifier.

Dorothy

On Sat, May 14, 2011 at 6:18 = PM, Glen Zorn <gwz@= net-zen.net> wrote:
On 5/15/2011 2:36 AM, Sam Hartman wrote:
>>>>>> "Alan" =3D=3D Alan DeKok <aland@deployingradius.com> writes:=
>
> =A0 =A0 Alan> Glen Zorn wrote:
> =A0 =A0 >> There seem to be two issues here: renaming the draft = & allocating
> =A0 =A0 >> a new EAP type. =A0For which one are opinions being s= olicited?
>
> =A0 =A0 Alan> =A0 Allocating a new EAP type.
>
> My opinion is that we have two options:
>
> 1) Allocate a new method type now.
>
> 2) Revisit this issue at the end.
>
> I don't think we'll be in a position to decide for sure we can= keep the
> method type until we reach WGLC.

I don't follow your logic here. =A0Allocating a new EAP type is,<= br> practically speaking, nothing.

>
> However we can always short-circuit the issue early.

The only question I can see is whether or not emu really is an extens= ion
of the Cisco marketing department. =A0One would like to think that the
answer is obvious but maybe not...

...

_______________________________________________
Emu mailing list
Emu@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/emu


--00248c0ee8a0f61fe304a368d6bd-- From jsalowey@cisco.com Mon May 16 11:37:11 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DB0E0793 for ; Mon, 16 May 2011 11:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksYNcGHn6CYU for ; Mon, 16 May 2011 11:37:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id AD6F1E0681 for ; Mon, 16 May 2011 11:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1896; q=dns/txt; s=iport; t=1305571029; x=1306780629; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=X/STfdB5pwMzan2fyrEJZmoJzFol9sQP+MkdrY+8rtA=; b=QoV1iw39csEtbOVgRze3B3qOtiJYIKF4PXfjebdp7XFCBKlLfrrSjz1W ZKY/9iJQcRtaSXOXOoEMBVyrEyG4eUsRGNSroT75W51Q0lCUbMJHZ0GLb W0NN0CBFhjjzWt9Ld7nbQvkofhe/Mb9/iwJt+T4pbGDD/VXfqJDTnew27 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC9u0U2rRDoG/2dsb2JhbACmF3eIcJ8lnhmGGQSGUIlBhC+KZg X-IronPort-AV: E=Sophos;i="4.65,220,1304294400"; d="scan'208";a="698229241" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 16 May 2011 18:37:09 +0000 Received: from [10.33.249.93] ([10.33.249.93]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4GIb8RY020305; Mon, 16 May 2011 18:37:08 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Mon, 16 May 2011 11:37:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DCD4E3F.70601@deployingradius.com> <4DCDDB82.9070605@net-zen.net> <4DCE23E6.1050003@deployingradius.com> <4DCF29E2.1070208@net-zen.net> To: Dorothy Stanley X-Mailer: Apple Mail (2.1084) Cc: Sam Hartman , "emu@ietf.org" Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 18:37:11 -0000 On May 16, 2011, at 11:29 AM, Dorothy Stanley wrote: > I support allocating a new method type for the new standard method, = sooner, rather than later. >=20 > The new method is defined by an IETF group, based on = submissions/modifications > from multiple parties, and should carry/use an IETF rather than = specific vendor identifier. >=20 [Joe] Just to be clear, EAP-FAST type ID has been allocated from the = IETF type space and is not an expanded vendor specific EAP type as = defined in RFC 3748. =20 > Dorothy >=20 > On Sat, May 14, 2011 at 6:18 PM, Glen Zorn wrote: > On 5/15/2011 2:36 AM, Sam Hartman wrote: > >>>>>> "Alan" =3D=3D Alan DeKok writes: > > > > Alan> Glen Zorn wrote: > > >> There seem to be two issues here: renaming the draft & = allocating > > >> a new EAP type. For which one are opinions being solicited? > > > > Alan> Allocating a new EAP type. > > > > My opinion is that we have two options: > > > > 1) Allocate a new method type now. > > > > 2) Revisit this issue at the end. > > > > I don't think we'll be in a position to decide for sure we can keep = the > > method type until we reach WGLC. >=20 > I don't follow your logic here. Allocating a new EAP type is, > practically speaking, nothing. >=20 > > > > However we can always short-circuit the issue early. >=20 > The only question I can see is whether or not emu really is an = extension > of the Cisco marketing department. One would like to think that the > answer is obvious but maybe not... >=20 > ... >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From dstanley1389@gmail.com Mon May 16 12:04:53 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B900E07BA for ; Mon, 16 May 2011 12:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE7XqmmRwps1 for ; Mon, 16 May 2011 12:04:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6325AE07CB for ; Mon, 16 May 2011 12:04:15 -0700 (PDT) Received: by wyb29 with SMTP id 29so4321686wyb.31 for ; Mon, 16 May 2011 12:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zu4LZ6pklQ7ajqcXvFRu+i8qbYVAiAOuCi2Z1UEd0MI=; b=Dck63mnODZRSFY+WX25NcQbWryFqDq/u3GlmEAD6qhSARilbFgaNUSlttYXmPkGEiF oSu6trpBtVupvMmeJDqs01pBAQlFiNpnhKnfD8vqny//3huG/6QiOYcItWM48Z7M2lQG 5hauxngF7gdkpdkSyAnplg2i27Np171asSljw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pbmiX8DY+4ipXmPLfueCR/kjGQwUhsGa3RLiijWgBClRDwaM6M/D20VbUD0ZTQKWQa KFJOQ6RPC+TBP3HHxncdda0z66cX80bMaDNulvHj23B8L/PteeLpXq+aIO2Hp5CiZ20a VOtUM/fiWreUTF6/AmUdub1Xckbci6BChh29U= MIME-Version: 1.0 Received: by 10.227.58.82 with SMTP id f18mr4645211wbh.45.1305572654340; Mon, 16 May 2011 12:04:14 -0700 (PDT) Received: by 10.227.135.72 with HTTP; Mon, 16 May 2011 12:04:14 -0700 (PDT) In-Reply-To: References: <4DCD4E3F.70601@deployingradius.com> <4DCDDB82.9070605@net-zen.net> <4DCE23E6.1050003@deployingradius.com> <4DCF29E2.1070208@net-zen.net> Date: Mon, 16 May 2011 12:04:14 -0700 Message-ID: From: Dorothy Stanley To: Joe Salowey Content-Type: multipart/alternative; boundary=20cf30025dde4a59f404a36952e2 Cc: Sam Hartman , "emu@ietf.org" Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 19:04:53 -0000 --20cf30025dde4a59f404a36952e2 Content-Type: text/plain; charset=ISO-8859-1 Joe, Understood. The "EAP-FAST" protocol and name and type value (from the IETF space) are tied in the market to specific vendor. A new name and a corresponding new IETF type help associate the new standard method with the IETF. Dorothy On Mon, May 16, 2011 at 11:37 AM, Joe Salowey wrote: > > On May 16, 2011, at 11:29 AM, Dorothy Stanley wrote: > > > I support allocating a new method type for the new standard method, > sooner, rather than later. > > > > The new method is defined by an IETF group, based on > submissions/modifications > > from multiple parties, and should carry/use an IETF rather than specific > vendor identifier. > > > > [Joe] Just to be clear, EAP-FAST type ID has been allocated from the IETF > type space and is not an expanded vendor specific EAP type as defined in RFC > 3748. > > > Dorothy > > > > On Sat, May 14, 2011 at 6:18 PM, Glen Zorn wrote: > > On 5/15/2011 2:36 AM, Sam Hartman wrote: > > >>>>>> "Alan" == Alan DeKok writes: > > > > > > Alan> Glen Zorn wrote: > > > >> There seem to be two issues here: renaming the draft & > allocating > > > >> a new EAP type. For which one are opinions being solicited? > > > > > > Alan> Allocating a new EAP type. > > > > > > My opinion is that we have two options: > > > > > > 1) Allocate a new method type now. > > > > > > 2) Revisit this issue at the end. > > > > > > I don't think we'll be in a position to decide for sure we can keep the > > > method type until we reach WGLC. > > > > I don't follow your logic here. Allocating a new EAP type is, > > practically speaking, nothing. > > > > > > > > However we can always short-circuit the issue early. > > > > The only question I can see is whether or not emu really is an extension > > of the Cisco marketing department. One would like to think that the > > answer is obvious but maybe not... > > > > ... > > > > _______________________________________________ > > 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 > > --20cf30025dde4a59f404a36952e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joe,

Understood. The "EAP-FAST" protocol and name and type= value (from the IETF space) are tied in the market to specific vendor. A n= ew name and a corresponding new IETF type help associate the new standard m= ethod with the IETF.

Dorothy

On Mon, May 16, 2011 at 11:37= AM, Joe Salowey <jsalowey@cisco.com> wrote:

On May 16, 2011, at 11:29 AM, Dorothy Stanley wrote:

> I support allocating a new method type for the new standard method, so= oner, rather than later.
>
> The new method is defined by an IETF group, based on submissions/modif= ications
> from multiple parties, and should carry/use an IETF rather than specif= ic vendor identifier.
>

[Joe] Just to be clear, EAP-FAST type ID has been allocated from the = IETF type space and is not an expanded vendor specific EAP type as defined = in RFC 3748.

> Dorothy
>
> On Sat, May 14, 2011 at 6:18 PM, Glen Zorn <gwz@net-zen.net> wrote:
> On 5/15/2011 2:36 AM, Sam Hartman wrote:
> >>>>>> "Alan" =3D=3D Alan DeKok <aland@deployingradius.com> wr= ites:
> >
> > =A0 =A0 Alan> Glen Zorn wrote:
> > =A0 =A0 >> There seem to be two issues here: renaming the d= raft & allocating
> > =A0 =A0 >> a new EAP type. =A0For which one are opinions be= ing solicited?
> >
> > =A0 =A0 Alan> =A0 Allocating a new EAP type.
> >
> > My opinion is that we have two options:
> >
> > 1) Allocate a new method type now.
> >
> > 2) Revisit this issue at the end.
> >
> > I don't think we'll be in a position to decide for sure w= e can keep the
> > method type until we reach WGLC.
>
> I don't follow your logic here. =A0Allocating a new EAP type is, > practically speaking, nothing.
>
> >
> > However we can always short-circuit the issue early.
>
> The only question I can see is whether or not emu really is an extensi= on
> of the Cisco marketing department. =A0One would like to think that the=
> answer is obvious but maybe not...
>
> ...
>
> _______________________________________________
> 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


--20cf30025dde4a59f404a36952e2-- From hartmans@mit.edu Mon May 16 15:35:50 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34149E07B6 for ; Mon, 16 May 2011 15:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JotAWsEbvo+v for ; Mon, 16 May 2011 15:35:48 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id CEB78E0651 for ; Mon, 16 May 2011 15:35:48 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [85.13.70.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 044C8203C0; Mon, 16 May 2011 18:31:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 741AC4065; Mon, 16 May 2011 18:35:43 -0400 (EDT) From: Sam Hartman To: Dorothy Stanley References: <4DCD4E3F.70601@deployingradius.com> <4DCDDB82.9070605@net-zen.net> <4DCE23E6.1050003@deployingradius.com> <4DCF29E2.1070208@net-zen.net> Date: Mon, 16 May 2011 18:35:43 -0400 In-Reply-To: (Dorothy Stanley's message of "Mon, 16 May 2011 12:04:14 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , "emu@ietf.org" Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 22:35:50 -0000 Based on the answers to my questions, I strongly support allocation of a new EAP type code . I think using the existing type code will significantly disadvantage implementations that want to implement the IETF spec but not eap-fast v1. I believe that is highly undesirable. From ncamwing@cisco.com Mon May 16 16:48:30 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5302E06B5 for ; Mon, 16 May 2011 16:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMhcB-2NA2ZE for ; Mon, 16 May 2011 16:48:29 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 53C88E0659 for ; Mon, 16 May 2011 16:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ncamwing@cisco.com; l=6562; q=dns/txt; s=iport; t=1305589709; x=1306799309; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=vc70EMTmFUEmw/b7d7Q8nSnGn1JJJpzRfmA9JQOr92I=; b=L4cwYza9iZs3giZ4+dQNAwtVcfs6f2mVHoGTB4NhejZk3z6QlXI3YqVI D/2Wh7b9J1Ic2hnIKDFiZRz6Fn/ZQLs8KqWoEXTqsJxSyTcRslRVmXbaY gk+zJTO4RCyMySlSbCK37HeIF47LbroY36L2p46ZlIr1yDtP5xJ5CPGT1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANC20U2rRDoG/2dsb2JhbACCZaJHa3eIcJ80njaGGQSGUIlBhDiKXQ X-IronPort-AV: E=Sophos;i="4.65,222,1304294400"; d="scan'208,217";a="698401446" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 16 May 2011 23:48:28 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4GNmSQj014260; Mon, 16 May 2011 23:48:28 GMT Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 May 2011 16:48:19 -0700 Received: from 10.21.76.13 ([10.21.76.13]) by xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) with Microsoft Exchange Server HTTP-DAV ; Mon, 16 May 2011 23:48:19 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 16 May 2011 16:48:00 -0700 From: Nancy Cam-Winget To: Alan DeKok , Hao Zhou Message-ID: Thread-Topic: [Emu] Some questions about eap type code and the tunnel method Thread-Index: AcwT1/LSVkVcUPeNT6O4w5tiKq2WpAAS71o1 In-Reply-To: <4DD13892.404@deployingradius.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3388409280_26101870" X-OriginalArrivalTime: 16 May 2011 23:48:19.0882 (UTC) FILETIME=[BC1538A0:01CC1423] Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 23:48:31 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3388409280_26101870 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit It seems too early to decide whether there is a need to change the EAP type at this point. I think there is merit to considering reducing customer education as to why yet another new EAP type is being defined....as Hao mentioned, there is also merit to facilitating code reuse and reducing deployment complexity. Changing the type code has implications to the configuration and management interfaces especially on the client side. Nancy. On 5/16/11 7:45 AM, "Alan DeKok" wrote: > Hao Zhou wrote: >>> >> As a backup question: Are there *any* implementations of v2? >>> >> >> > [HZ] Not right now. Once this draft is finalized, it will be. > > OK. That means there are no costs to choosing a new EAP type code. > >> > [HZ] The draft doesn't mandate support for v1 and v2, it's up to each >> > implementation. How, ever, due to the small changes from V2 to v1, I >> suspect >> > most of them could support both easily. Doesn't running code mean something >> > in IETF? > > Speaking as an individual contributor and implementor, I think the v2 > draft is a lot clearer than the v1 specification. It looks to be > simpler, too. > >> > [HZ] Agree. Considering all devices out there supporting EAP-FASTv1 and it >> > may take a while for them to support the new method, most server >> > implementations would probably support both. > > Again, speaking as an individual, some server software doesn't support > EAP-FAST. There have been few complaints so far about that. > >> > [HZ] Realistically, until the new tunnel method is published and adopted by >> > all servers and supplicants, implementation would have to support older >> > tunnel methods, including EAP-FASTv1. > > See above. > >> > By retaining the EAP-FAST type, >> > customers wouldn't have to be educated with another new EAP type and >> > validate its security, and they would have a smoother migration path, from >> > v1 to v2. Implementers could reuse the same code. > > I agree that cost of deployment is a factor to consider. > >> > I thought one of the >> > reasons EAP-FASTv2 is adopted is because of its existing code and >> > deployment, with small changes to meet EMU requirements. Changing the >> method >> > name and type would totally negativate that. > > I'm not sure how changing the type code adds deployment costs. The > new version has to be deployed no matter what. > > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > --B_3388409280_26101870 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Emu] Some questions about eap type code and the tunnel method</= TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>It seems too early to decide whether there is a need to change the EAP typ= e<BR>  at this point.  <BR> <BR> I think there is merit to considering reducing customer education as to why= <BR>  yet another new EAP type is being defined....as Hao mentioned, there = is <BR>  also merit to facilitating code reuse and reducing deployment complex= ity.<BR> Changing the type code has implications to the configuration and management= <BR>  interfaces especially on the client side.<BR> <BR>   Nancy. <BR> <BR> <BR> On 5/16/11 7:45 AM, "Alan DeKok" <<a href=3D"aland@deployingradi= us.com">aland@deployingradius.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>Hao Zhou wrote:<BR> >>   As a backup question: Are there *any* implementations = of v2?<BR> >><BR> > [HZ] Not right now. Once this draft is finalized, it will be.<BR> <BR>   OK.  That means there are no costs to choosing a new EAP t= ype code.<BR> <BR> > [HZ] The draft doesn't mandate support for v1 and v2, it's up to each<= BR> > implementation. How, ever, due to the small changes from V2 to v1, I s= uspect<BR> > most of them could support both easily. Doesn't running code mean some= thing<BR> > in IETF?<BR> <BR>   Speaking as an individual contributor and implementor, I think = the v2<BR> draft is a lot clearer than the v1 specification.  It looks to be<BR> simpler, too.<BR> <BR> > [HZ] Agree. Considering all devices out there supporting EAP-FASTv1 an= d it<BR> > may take a while for them to support the new method, most server<BR> > implementations would probably support both.<BR> <BR>   Again, speaking as an individual, some server software doesn't = support<BR> EAP-FAST.  There have been few complaints so far about that.<BR> <BR> > [HZ] Realistically, until the new tunnel method is published and adopt= ed by<BR> > all servers and supplicants, implementation would have to support olde= r<BR> > tunnel methods, including EAP-FASTv1.<BR> <BR>   See above.<BR> <BR> > By retaining the EAP-FAST type,<BR> > customers wouldn't have to be educated with another new EAP type and<B= R> > validate its security, and they would have a smoother migration path, = from<BR> > v1 to v2. Implementers could reuse the same code.<BR> <BR>   I agree that cost of deployment is a factor to consider.<BR> <BR> > I thought one of the<BR> > reasons EAP-FASTv2 is adopted is because of its existing code and<BR> > deployment, with small changes to meet EMU requirements. Changing the = method<BR> > name and type would totally negativate that.<BR> <BR>   I'm not sure how changing the type code adds deployment costs. =  The<BR> new version has to be deployed no matter what.<BR> <BR>   Alan DeKok.<BR> _______________________________________________<BR> Emu mailing list<BR> <a href=3D"Emu@ietf.org">Emu@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/emu">https://www.ietf.org/ma= ilman/listinfo/emu</a><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3388409280_26101870-- From gwz@net-zen.net Mon May 16 17:03:33 2011 Return-Path: <gwz@net-zen.net> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E253E06ED for <emu@ietfa.amsl.com>; Mon, 16 May 2011 17:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzFIpTP81yWY for <emu@ietfa.amsl.com>; Mon, 16 May 2011 17:03:32 -0700 (PDT) Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by ietfa.amsl.com (Postfix) with SMTP id 34039E0659 for <emu@ietf.org>; Mon, 16 May 2011 17:03:32 -0700 (PDT) Received: (qmail 17810 invoked from network); 17 May 2011 00:03:31 -0000 Received: from unknown (124.122.138.47) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 17 May 2011 00:03:30 -0000 Message-ID: <4DD1BB4D.7000304@net-zen.net> Date: Tue, 17 May 2011 07:03:25 +0700 From: Glen Zorn <gwz@net-zen.net> Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alan DeKok <aland@deployingradius.com> References: <tslpqnilszx.fsf@mit.edu> <4DD12073.7020500@deployingradius.com> In-Reply-To: <4DD12073.7020500@deployingradius.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------040001050308080803050701" Cc: Sam Hartman <hartmans-ietf@mit.edu>, emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 May 2011 00:03:33 -0000 This is a multi-part message in MIME format. --------------040001050308080803050701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/16/2011 8:02 PM, Alan DeKok wrote: > Sam Hartman wrote: >> I'd like to confirm that code is in use both by implementations of >> eap-fast v1 and v2. > > As a backup question: Are there *any* implementations of v2? > > The draft does not make it clear if this is the case. Can the authors > step in and give their opinion? I believe that it was stated in Prague that there were no implementations (let alone deployments) at that time, but that Cisco would commit to putting development on their road map. > >> Does the current text mandate support for eap-fast v1 as well as v2? > > Yes and no. Section 3.1 says: > > The version negotiation procedure guarantees that the EAP-FAST peer > and server will agree to the latest version supported by both > parties. If version negotiation fails, then use of EAP-FAST will not > be possible, and another mutually acceptable EAP method will need to > be negotiated if authentication is to proceed. > > This makes it *possible* for an implementation to support v2 only. > This will require starting version negotiation for EAP-FASTv2, and then > switching to a different EAP method. > > Implementations traditionally have found it difficult to start one EAP > method, and then to switch to another one. This means that v2-only > implementations may be difficult to deploy in practice. > >> Is it expected that most implementations will support v1 and v2? >> >> Is it desired that people be able to create a v2 only implementation? > > I will partially avoid those two questions, and say that it should be > possible to deploy only the EMU tunneled method. This seems to me to be a strong argument for a new type code. ... --------------040001050308080803050701 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------040001050308080803050701-- From gwz@net-zen.net Mon May 16 17:12:52 2011 Return-Path: <gwz@net-zen.net> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBABCE06ED for <emu@ietfa.amsl.com>; Mon, 16 May 2011 17:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta4KpLZeNi6f for <emu@ietfa.amsl.com>; Mon, 16 May 2011 17:12:52 -0700 (PDT) Received: from smtpauth12.prod.mesa1.secureserver.net (smtpauth12.prod.mesa1.secureserver.net [64.202.165.35]) by ietfa.amsl.com (Postfix) with SMTP id 67BF4E0686 for <emu@ietf.org>; Mon, 16 May 2011 17:12:52 -0700 (PDT) Received: (qmail 10724 invoked from network); 17 May 2011 00:12:51 -0000 Received: from unknown (124.122.138.47) by smtpauth12.prod.mesa1.secureserver.net (64.202.165.35) with ESMTP; 17 May 2011 00:12:50 -0000 Message-ID: <4DD1BD7E.40803@net-zen.net> Date: Tue, 17 May 2011 07:12:46 +0700 From: Glen Zorn <gwz@net-zen.net> Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Sam Hartman <hartmans-ietf@mit.edu> References: <tslpqnilszx.fsf@mit.edu> In-Reply-To: <tslpqnilszx.fsf@mit.edu> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------090107020007060706060007" Cc: emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 May 2011 00:12:53 -0000 This is a multi-part message in MIME format. --------------090107020007060706060007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/16/2011 7:39 PM, Sam Hartman wrote: > > > I'd like to confirm my understanding. > > The current text proposes the use of eap type code 43. > > I'd like to confirm that code is in use both by implementations of > eap-fast v1 and v2. I'm pretty sure that there are no implementations (except maybe in a lab somewhere) of EAP-FAST v2. > > Does the current text mandate support for eap-fast v1 as well as v2? > > Is it expected that most implementations will support v1 and v2? This question seems to assume an answer. There are 2 ways to look at the question: either the standard tunneled method is EAP-FAST v2 or it is v1 of itself (as yet unnamed -- I suggest "TEAM" ;-). > > Is it desired that people be able to create a v2 only implementation? See above, but my guess is that most vendors would prefer to be able to support the standard tunneled method without also supporting a proprietary tunneled method... > > I think based on answers to these questions I at least will be able to > better determine my opinion on the type code issue. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > > --------------090107020007060706060007 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------090107020007060706060007-- From gwz@net-zen.net Mon May 16 18:04:15 2011 Return-Path: <gwz@net-zen.net> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D634FE06ED for <emu@ietfa.amsl.com>; Mon, 16 May 2011 18:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8gs4tJLfxIh for <emu@ietfa.amsl.com>; Mon, 16 May 2011 18:04:15 -0700 (PDT) Received: from p3plsmtpa01-05.prod.phx3.secureserver.net (p3plsmtpa01-05.prod.phx3.secureserver.net [72.167.82.85]) by ietfa.amsl.com (Postfix) with SMTP id 380EAE06E5 for <emu@ietf.org>; Mon, 16 May 2011 18:04:15 -0700 (PDT) Received: (qmail 12011 invoked from network); 17 May 2011 01:04:14 -0000 Received: from unknown (124.120.81.30) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 17 May 2011 01:04:13 -0000 Message-ID: <4DD1C987.4030105@net-zen.net> Date: Tue, 17 May 2011 08:04:07 +0700 From: Glen Zorn <gwz@net-zen.net> Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Hao Zhou <hzhou@cisco.com> References: <C9F6ADA9.217A3%hzhou@cisco.com> In-Reply-To: <C9F6ADA9.217A3%hzhou@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------000402090703080600060900" Cc: Sam Hartman <hartmans-ietf@mit.edu>, emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 May 2011 01:04:16 -0000 This is a multi-part message in MIME format. --------------000402090703080600060900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/16/2011 9:32 PM, Hao Zhou wrote: ... >> Sam Hartman wrote: >>> I'd like to confirm that code is in use both by implementations of >>> eap-fast v1 and v2. >> > [HZ] Yes. Type Code 43 is being used by EAP-FAST v1 and widely deployed. > >> As a backup question: Are there *any* implementations of v2? >> > [HZ] Not right now. Once this draft is finalized, it will be. > >> The draft does not make it clear if this is the case. Can the authors >> step in and give their opinion? >> >>> Does the current text mandate support for eap-fast v1 as well as v2? >> > [HZ] The draft doesn't mandate support for v1 and v2, it's up to each > implementation. How, ever, due to the small changes from V2 to v1, I suspect > most of them could support both easily. Doesn't running code mean something > in IETF? Let me get this straight: are you claiming that changing the EAP type will break the "running code" but making the same "small changes" and keeping the same EAP type won't? > >> Yes and no. Section 3.1 says: >> >> The version negotiation procedure guarantees that the EAP-FAST peer >> and server will agree to the latest version supported by both >> parties. If version negotiation fails, then use of EAP-FAST will not >> be possible, and another mutually acceptable EAP method will need to >> be negotiated if authentication is to proceed. >> >> This makes it *possible* for an implementation to support v2 only. >> This will require starting version negotiation for EAP-FASTv2, and then >> switching to a different EAP method. >> >> Implementations traditionally have found it difficult to start one EAP >> method, and then to switch to another one. This means that v2-only >> implementations may be difficult to deploy in practice. >> > [HZ] Agree. Considering all devices out there supporting EAP-FASTv1 and it > may take a while for them to support the new method, most server > implementations would probably support both. New devices are created every day. I don't think that it's too much of a stretch to think that device vendors would prefer to support only one tunneled method; after all, isn't that one of the purposes of this exercise? >>> Is it expected that most implementations will support v1 and v2? >>> > [HZ] See above. > >>> Is it desired that people be able to create a v2 only implementation? >> >> I will partially avoid those two questions, and say that it should be >> possible to deploy only the EMU tunneled method. > [HZ] Realistically, until the new tunnel method is published and adopted by > all servers and supplicants, implementation would have to support older > tunnel methods, including EAP-FASTv1. By retaining the EAP-FAST type, > customers wouldn't have to be educated with another new EAP type and > validate its security, and they would have a smoother migration path, from > v1 to v2. Is the claim here that customers are so stupid that they would deploy a new version of EAP-FAST without validating its security? > Implementers could reuse the same code. This is a non-issue. The same code can be reused regardless of the EAP type. > I thought one of the > reasons EAP-FASTv2 is adopted is because of its existing code and > deployment, with small changes to meet EMU requirements. Again, I'm confused: you wrote above that there are no implementations in existence. If we adopted EAP-FASTv2 "because of its existing code and deployment" then we must certainly be deluded since there is no code and there are no deployments. > Changing the method > name and type would totally negativate that. I suspect that all it would really negate is the marketing opportunity. OTOH, the Cisco marketing machine is truly awesome while the IETF's, not so much ;-). Would vendors (other than the employers of the authors) be more likely to implement EAP-FASTv2 that the IETF Tunneled EAP Method? Would customers be more likely to deploy it? I don't know, but I think that it's worth considering. AFAICT the difference between the two options in terms of development and operational costs is very close to zero, though. ... --------------000402090703080600060900 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------000402090703080600060900-- From stefan.winter@restena.lu Mon May 16 23:41:48 2011 Return-Path: <stefan.winter@restena.lu> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3B9E069E for <emu@ietfa.amsl.com>; Mon, 16 May 2011 23:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac6KtEdGP8Zg for <emu@ietfa.amsl.com>; Mon, 16 May 2011 23:41:46 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id B14DFE07AE for <emu@ietf.org>; Mon, 16 May 2011 23:41:45 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 51692A98C2 for <emu@ietf.org>; Tue, 17 May 2011 08:41:42 +0200 (CEST) Received: from [158.64.15.248] (248-15.vpn.restena.lu [158.64.15.248]) by legolas.restena.lu (Postfix) with ESMTPSA id 36528AF4D9 for <emu@ietf.org>; Tue, 17 May 2011 08:41:42 +0200 (CEST) Message-ID: <4DD218A9.3070108@restena.lu> Date: Tue, 17 May 2011 08:41:45 +0200 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: emu@ietf.org References: <tslpqnilszx.fsf@mit.edu> <4DD12073.7020500@deployingradius.com> In-Reply-To: <4DD12073.7020500@deployingradius.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 May 2011 06:41:49 -0000 Hi, > Implementations traditionally have found it difficult to start one EAP > method, and then to switch to another one. This means that v2-only > implementations may be difficult to deploy in practice. That would speak for assigning a new EAP type code for v2, wouldn't it? EAP method (re)negotiation is well-tested, and known to work across many supplicants. That way, a v2-only implementation wouldn't need to rely on in-EAP-method version negotiation and whacky switching. Greetings, Stefan Winter >> Is it expected that most implementations will support v1 and v2? >> >> Is it desired that people be able to create a v2 only implementation? > I will partially avoid those two questions, and say that it should be > possible to deploy only the EMU tunneled method. > > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From aland@deployingradius.com Tue May 17 00:33:12 2011 Return-Path: <aland@deployingradius.com> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764B2E06C0 for <emu@ietfa.amsl.com>; Tue, 17 May 2011 00:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3ynA8J8tFgN for <emu@ietfa.amsl.com>; Tue, 17 May 2011 00:33:12 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DB093E069C for <emu@ietf.org>; Tue, 17 May 2011 00:33:11 -0700 (PDT) Message-ID: <4DD224B4.6030605@deployingradius.com> Date: Tue, 17 May 2011 09:33:08 +0200 From: Alan DeKok <aland@deployingradius.com> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nancy Cam-Winget <ncamwing@cisco.com> References: <C9F705C0.8516%ncamwing@cisco.com> In-Reply-To: <C9F705C0.8516%ncamwing@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman <hartmans-ietf@mit.edu>, emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 May 2011 07:33:12 -0000 Nancy Cam-Winget wrote: > It seems too early to decide whether there is a need to change the EAP type > at this point. We're asking for input, not a decision right now. > Changing the type code has implications to the configuration and management > interfaces especially on the client side. Yes, that is certainly true. Alan DeKok. From jkmalinen@gmail.com Tue May 17 01:35:00 2011 Return-Path: <jkmalinen@gmail.com> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87DBE069C for <emu@ietfa.amsl.com>; Tue, 17 May 2011 01:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNhwb5rRWQ0k for <emu@ietfa.amsl.com>; Tue, 17 May 2011 01:35:00 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA50FE0671 for <emu@ietf.org>; Tue, 17 May 2011 01:34:59 -0700 (PDT) Received: by vxg33 with SMTP id 33so201081vxg.31 for <emu@ietf.org>; Tue, 17 May 2011 01:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hWGbb+1MhMJgkM5TMeklaQvk/ufH7iFkWXx8Fgk2E/0=; b=L4S8WgEnexKBXlWkR/IVazYtQ6zsb3HCAQBxLr1Q+ceoSJEb1M5vV5dZK958VRpoDb Q3m0tOmP2Zg664jPweVPhzFTL/5FyYw0cMxSkm6V0rB/7OdwhwKf5GVvkLlxlN4mzRsN iT5Hb4atgtcfCr0LXeGmhoPN4Vz2bs9XuyFLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=h6DH9RsS5ni7wL4EyxW2UXgTiqMccLD3Gic52BfV4yAmek71fX0b8/QwaWBeTN1hVG Tj1IOnMof0IHhT6SwMavU5GlQMT2YF55BdV2JNNwswY8fy7pLurHezJieKx708EC1/r6 oz67Yv7DVZm635S4aatQ5OwvwAAuKU6cIftq4= MIME-Version: 1.0 Received: by 10.52.177.106 with SMTP id cp10mr473247vdc.199.1305621299350; Tue, 17 May 2011 01:34:59 -0700 (PDT) Received: by 10.220.192.9 with HTTP; Tue, 17 May 2011 01:34:59 -0700 (PDT) In-Reply-To: <4DCD4E3F.70601@deployingradius.com> References: <4DCD4E3F.70601@deployingradius.com> Date: Tue, 17 May 2011 11:34:59 +0300 Message-ID: <BANLkTinPj9t9Ntf3HuMZ6WOXWqjXN7Q=mg@mail.gmail.com> From: Jouni Malinen <jkmalinen@gmail.com> To: Alan DeKok <aland@deployingradius.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "emu@ietf.org" <emu@ietf.org> Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 May 2011 08:35:00 -0000 On Fri, May 13, 2011 at 6:29 PM, Alan DeKok <aland@deployingradius.com> wro= te: > =C2=A0The reason for the name change is that there have been questions > raised about whether this document should be left as EAP-FASTv2, or > whether it should request allocation of a new EAP type. > > =C2=A0Since the document name (individual draft) currently reflects the E= AP > type name, abstracting that would be useful. =C2=A0That way the document = name > will not change no matter what the WG decides to do. > > =C2=A0Anyone with opinions either way is requested to discuss the pros an= d > cons of the issue. I would prefer to allocate a new EAP type for this method and do that as soon as possible to make it easier to run early interoperability testing without having to use vendors specific type or experimental type (of which there are only one) and to agree between various implementations what to use.. Allocating a new EAP type enables cleaner design options for implementations that only support the standard method and do not have support for the proprietary EAP-FAST method. In addition, it allows proprietary EAP-FAST extensions to be kept separate in case both methods are implemented. EAP-FAST requires various hacks in the EAP implementation, including modifying a phase 2 method (EAP-GTC) based on the phase 1 method. I do not really want to extend those hacks any further and just want to keep them conditional on the already allocated EAP-FAST type instead of having to figure out which EAP-FAST method version is being run in a method that is not really supposed to be in any way dependent on the tunnel method. As far as EAP method/version negotiation is concerned, I find it more likely that the EAP-NAK mechanism for selecting the EAP method has received much more testing than EAP-FAST version negotiation and as such, is more likely to interoperate with legacy implementations. - Jouni From simon@josefsson.org Tue May 17 08:20:54 2011 Return-Path: <simon@josefsson.org> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC04E0665 for <emu@ietfa.amsl.com>; Tue, 17 May 2011 08:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83FeKROVDVsH for <emu@ietfa.amsl.com>; Tue, 17 May 2011 08:20:53 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id 2A671E0658 for <emu@ietf.org>; Tue, 17 May 2011 08:20:52 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p4HFKcIp022226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 May 2011 17:20:40 +0200 From: Simon Josefsson <simon@josefsson.org> To: Jouni Malinen <jkmalinen@gmail.com> References: <4DCD4E3F.70601@deployingradius.com> <BANLkTinPj9t9Ntf3HuMZ6WOXWqjXN7Q=mg@mail.gmail.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110517:emu@ietf.org::z3I/SNLcDuDRq9I8:1UZE X-Hashcash: 1:22:110517:jkmalinen@gmail.com::pCRcwnrXkSPyNknL:4cBg X-Hashcash: 1:22:110517:aland@deployingradius.com::kOr4rlyl/sf+Tvae:71rG Date: Tue, 17 May 2011 17:20:38 +0200 In-Reply-To: <BANLkTinPj9t9Ntf3HuMZ6WOXWqjXN7Q=mg@mail.gmail.com> (Jouni Malinen's message of "Tue, 17 May 2011 11:34:59 +0300") Message-ID: <87k4dptku1.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "emu@ietf.org" <emu@ietf.org> Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 May 2011 15:20:54 -0000 Jouni Malinen <jkmalinen@gmail.com> writes: > On Fri, May 13, 2011 at 6:29 PM, Alan DeKok <aland@deployingradius.com> wrote: >>  The reason for the name change is that there have been questions >> raised about whether this document should be left as EAP-FASTv2, or >> whether it should request allocation of a new EAP type. >> >>  Since the document name (individual draft) currently reflects the EAP >> type name, abstracting that would be useful.  That way the document name >> will not change no matter what the WG decides to do. >> >>  Anyone with opinions either way is requested to discuss the pros and >> cons of the issue. > > I would prefer to allocate a new EAP type for this method and do that > as soon as possible to make it easier to run early interoperability > testing without having to use vendors specific type or experimental > type (of which there are only one) and to agree between various > implementations what to use.. +1 for a new EAP type for FASTv2. /Simon From gwz@net-zen.net Tue May 17 19:43:44 2011 Return-Path: <gwz@net-zen.net> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B11E06F2 for <emu@ietfa.amsl.com>; Tue, 17 May 2011 19:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkWfzZRe01OV for <emu@ietfa.amsl.com>; Tue, 17 May 2011 19:43:43 -0700 (PDT) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by ietfa.amsl.com (Postfix) with SMTP id A7AA0E06F0 for <emu@ietf.org>; Tue, 17 May 2011 19:43:43 -0700 (PDT) Received: (qmail 26848 invoked from network); 18 May 2011 02:43:43 -0000 Received: from unknown (124.120.203.20) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 18 May 2011 02:43:42 -0000 Message-ID: <4DD33259.6030703@net-zen.net> Date: Wed, 18 May 2011 09:43:37 +0700 From: Glen Zorn <gwz@net-zen.net> Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alan DeKok <aland@deployingradius.com> References: <C9F705C0.8516%ncamwing@cisco.com> <4DD224B4.6030605@deployingradius.com> In-Reply-To: <4DD224B4.6030605@deployingradius.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------000609040604060208030309" Cc: Sam Hartman <hartmans-ietf@mit.edu>, emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 May 2011 02:43:44 -0000 This is a multi-part message in MIME format. --------------000609040604060208030309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/17/2011 2:33 PM, Alan DeKok wrote: > Nancy Cam-Winget wrote: >> It seems too early to decide whether there is a need to change the EAP type >> at this point. > > We're asking for input, not a decision right now. Why not? > >> Changing the type code has implications to the configuration and management >> interfaces especially on the client side. Sorry, but I have no idea what that means. What you seem to be saying is that the mere addition of a new EAP method requires changes in the actual defined interfaces between the management and configuration components of the system (not merely in the data that traverses those interfaces). That is absurd, of course, so you must _mean_ is that there will be more and/or different stuff to configure and manage but that is so close to being a tautology that it hardly seems mentioning (and certainly not in such an ominous tone). Or maybe not. What are you talking about? ... --------------000609040604060208030309 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------000609040604060208030309-- From aland@deployingradius.com Tue May 17 22:39:23 2011 Return-Path: <aland@deployingradius.com> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3729AE068C for <emu@ietfa.amsl.com>; Tue, 17 May 2011 22:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3g0UzidkqbO for <emu@ietfa.amsl.com>; Tue, 17 May 2011 22:39:22 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id A0322E0681 for <emu@ietf.org>; Tue, 17 May 2011 22:39:22 -0700 (PDT) Message-ID: <4DD35B88.3060403@deployingradius.com> Date: Wed, 18 May 2011 07:39:20 +0200 From: Alan DeKok <aland@deployingradius.com> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Glen Zorn <gwz@net-zen.net> References: <C9F705C0.8516%ncamwing@cisco.com> <4DD224B4.6030605@deployingradius.com> <4DD33259.6030703@net-zen.net> In-Reply-To: <4DD33259.6030703@net-zen.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 May 2011 05:39:23 -0000 Glen Zorn wrote: > On 5/17/2011 2:33 PM, Alan DeKok wrote: >> We're asking for input, not a decision right now. > > Why not? I'd like to see what the WG consensus is prior to making a decision. In addition, I'd like to be sure we understand the consequences of a change, before we make a decision. If the type code does change, then the method name will likely need to change, too. What's the new name? etc... Alan DeKok. From aland@deployingradius.com Tue May 17 23:06:30 2011 Return-Path: <aland@deployingradius.com> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA215E06B2 for <emu@ietfa.amsl.com>; Tue, 17 May 2011 23:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggY0TpMNrCci for <emu@ietfa.amsl.com>; Tue, 17 May 2011 23:06:30 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 648AEE068C for <emu@ietf.org>; Tue, 17 May 2011 23:06:29 -0700 (PDT) Message-ID: <4DD361E4.1050508@deployingradius.com> Date: Wed, 18 May 2011 08:06:28 +0200 From: Alan DeKok <aland@deployingradius.com> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Glen Zorn <gwz@net-zen.net> References: <C9F705C0.8516%ncamwing@cisco.com> <4DD224B4.6030605@deployingradius.com> <4DD33259.6030703@net-zen.net> <4DD35B88.3060403@deployingradius.com> <4DD360FD.4000906@net-zen.net> In-Reply-To: <4DD360FD.4000906@net-zen.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 May 2011 06:06:31 -0000 Glen Zorn wrote: > I guess the IETF process has really changed lately! I had always > thought that WG consensus _was_ the decision & the task of the chairs > was merely to determine what WG consensus was. Silly me! Make that "establish WG consensus prior to announcing a decision" Alan DeKok. From gwz@net-zen.net Tue May 17 23:09:23 2011 Return-Path: <gwz@net-zen.net> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2452BE06C4 for <emu@ietfa.amsl.com>; Tue, 17 May 2011 23:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2odcYol8F6s for <emu@ietfa.amsl.com>; Tue, 17 May 2011 23:09:22 -0700 (PDT) Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) by ietfa.amsl.com (Postfix) with SMTP id 9B652E06B2 for <emu@ietf.org>; Tue, 17 May 2011 23:09:22 -0700 (PDT) Received: (qmail 7666 invoked from network); 18 May 2011 06:02:42 -0000 Received: from unknown (124.120.203.20) by p3plsmtpa07-06.prod.phx3.secureserver.net (173.201.192.235) with ESMTP; 18 May 2011 06:02:42 -0000 Message-ID: <4DD360FD.4000906@net-zen.net> Date: Wed, 18 May 2011 13:02:37 +0700 From: Glen Zorn <gwz@net-zen.net> Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alan DeKok <aland@deployingradius.com> References: <C9F705C0.8516%ncamwing@cisco.com> <4DD224B4.6030605@deployingradius.com> <4DD33259.6030703@net-zen.net> <4DD35B88.3060403@deployingradius.com> In-Reply-To: <4DD35B88.3060403@deployingradius.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------020201030604060006050507" Cc: emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 May 2011 06:09:23 -0000 This is a multi-part message in MIME format. --------------020201030604060006050507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/18/2011 12:39 PM, Alan DeKok wrote: > Glen Zorn wrote: >> On 5/17/2011 2:33 PM, Alan DeKok wrote: >>> We're asking for input, not a decision right now. >> >> Why not? > > I'd like to see what the WG consensus is prior to making a decision. I guess the IETF process has really changed lately! I had always thought that WG consensus _was_ the decision & the task of the chairs was merely to determine what WG consensus was. Silly me! > > In addition, I'd like to be sure we understand the consequences of a > change, before we make a decision. > > If the type code does change, then the method name will likely need to > change, too. What's the new name? etc... Highly technical stuff -- I'd put a couple of more years in the charter timeline to deal with these tough questions. In the meantime, I have two suggestions for the new name (assuming that the Deciders establish that a new type is a good idea), just to get the ball rolling: Tunneled Extensible Authentication Method (TEAM, an oldie but goody) and Internet (or IETF) Tunneled EAP Method (ITEM). ... --------------020201030604060006050507 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------020201030604060006050507-- From Manuel_Nedbal@mcafee.com Tue May 17 08:19:59 2011 Return-Path: <Manuel_Nedbal@mcafee.com> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DAAE069C for <emu@ietfa.amsl.com>; Tue, 17 May 2011 08:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5tj7Z1xYXpp for <emu@ietfa.amsl.com>; Tue, 17 May 2011 08:19:58 -0700 (PDT) Received: from sncsmrelay2.nai.com (sncsmrelay2.nai.com [67.97.80.206]) by ietfa.amsl.com (Postfix) with ESMTP id 64FB7E0658 for <emu@ietf.org>; Tue, 17 May 2011 08:19:58 -0700 (PDT) Received: from (unknown [10.68.5.51]) by sncsmrelay2.nai.com with smtp id 7a4c_9b0c_ae6b1c02_8097_11e0_9a57_00219b92b092; Tue, 17 May 2011 15:09:37 +0000 Received: from SNCEXAPENG.corp.nai.org ([10.68.5.45]) by SNCEXHT1.corp.nai.org ([::1]) with mapi; Tue, 17 May 2011 08:09:15 -0700 From: <Manuel_Nedbal@McAfee.com> To: <emu@ietf.org>, <radiusext@ops.ietf.org> Date: Tue, 17 May 2011 08:09:14 -0700 Thread-Topic: EAP Issues (http://aboba.drizzlehosting.com/EAP/eapissues0.html) Thread-Index: AcwUhrMdS4cjsQtXTFei4DuRy27tPAAHYrRA Message-ID: <20352B104660934B912EA8B07F40716C023893E5A0@SNCEXAPENG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 18 May 2011 08:29:14 -0700 Subject: [Emu] FW: EAP Issues (http://aboba.drizzlehosting.com/EAP/eapissues0.html) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 May 2011 15:22:01 -0000 Rm9yd2FyZGluZyBhY2NvcmRpbmcgdG8gQmVybmhhcmRzIHJlY29tbWVuZGF0aW9uLg0KDQpCZXN0 IHJlZ2FyZHMsDQpNYW51ZWwgTmVkYmFsLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogQmVybmFyZCBBYm9iYSBbbWFpbHRvOmFib2JhQGludGVybmF1dC5jb21dIA0KU2VudDog VHVlc2RheSwgTWF5IDE3LCAyMDExIDQ6MzcgQU0NClRvOiBOZWRiYWwsIE1hbnVlbA0KU3ViamVj dDogUmU6IEVBUCBJc3N1ZXMgKGh0dHA6Ly9hYm9iYS5kcml6emxlaG9zdGluZy5jb20vRUFQL2Vh cGlzc3VlczAuaHRtbCkNCg0KSSdtIG5vdCBpbnZvbHZlZCBpbiB3b3JrIG9uIEVBUCBhbnkgbG9u Z2VyLCBzbyBteSBhZHZpY2Ugd291bGQgYmUgdG8gcG9zdCANCnlvdXIgcXVlc3Rpb24gdG8gdGhl IEVNVSAoZW11QGlldGYub3JnKSBvciBSQURFWFQgV0cgbWFpbGluZyBsaXN0cyANCihyYWRpdXNl eHRAb3BzLmlldGYub3JnKS4NCg0KT24gRnJpLCAyOSBBcHIgMjAxMSwgTWFudWVsX05lZGJhbEBN Y0FmZWUuY29tIHdyb3RlOg0KDQo+IA0KPiBEZWFyIEJlcm5hcmQsDQo+IA0KPiDCoA0KPiANCj4g SeKAmXZlIGJlZW4gZW5jb3VudGVyaW5nIHlvdXIgbmFtZS9lbWFpbCBkdXJpbmcgcmVhZGluZyB0 aHJvdWdoIHRoZSBkb2N1bWVudCBpbiB0aGUgc3ViamVjdC4gU3BlY2lmaWNhbGx5LCB5b3UgaGF2 ZSBzdWJtaXR0ZWQNCj4g4oCcU3VwcG9ydCBmb3IgVmVuZG9yLVNwZWNpZmljIFR5cGVz4oCdIGR1 cmluZyBFQVAgYXV0aGVudGljYXRpb24uIFNvIEkgaGFkIGhvcGVkIHlvdSBjb3VsZCBhZHZpc2Ug b24gdGhlIHBvc3NpYmlsaXR5IG9mIGFkZGluZyBhDQo+IGN1c3RvbSB2YWx1ZSBkdXJpbmcgRUFQ IGF1dGhlbnRpY2F0aW9uIHRoYXQgd291bGQgYmUgdGhlbiBmb3J3YXJkZWQgZnJvbSBhIE5ldHdv cmsgQWNjZXNzIFNlcnZlciB2aWEgUkFESVVTIGF0dHJpYnV0ZXMuIElzDQo+IHRoZXJlIGEgd2F5 IHRoYXQgd291bGQgYWxsb3cgYSBwcm9ncmFtIG9uIGEgaG9zdCB0byBwaWdneSBiYWNrIG9uIHRo ZSBFQVAgdHJhZmZpYyB2aWEgYSB2ZW5kb3Igc3BlY2lmaWMgYXR0cmlidXRlIHRvIHN1cHBseQ0K PiBlLmcuIG9uZSBieXRlIG9mIGluZm9ybWF0aW9uIHRvIGFuIHVwc3RyZWFtIHJhZGl1cyBzZXJ2 ZXI/DQo+IA0KPiDCoA0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiANCj4gTWFudWVsLg0KPiANCj4g DQo+DQo= From ebakyt@yahoo.com Mon May 23 02:40:48 2011 Return-Path: <ebakyt@yahoo.com> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE95E076D for <emu@ietfa.amsl.com>; Mon, 23 May 2011 02:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lE-cuKopabd for <emu@ietfa.amsl.com>; Mon, 23 May 2011 02:40:47 -0700 (PDT) Received: from nm24.bullet.mail.sp2.yahoo.com (nm24.bullet.mail.sp2.yahoo.com [98.139.91.94]) by ietfa.amsl.com (Postfix) with SMTP id B3AD2E06F7 for <emu@ietf.org>; Mon, 23 May 2011 02:40:47 -0700 (PDT) Received: from [98.139.91.67] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 23 May 2011 09:40:44 -0000 Received: from [98.139.91.17] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 23 May 2011 09:40:44 -0000 Received: from [127.0.0.1] by omp1017.mail.sp2.yahoo.com with NNFMP; 23 May 2011 09:40:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 805031.92748.bm@omp1017.mail.sp2.yahoo.com Received: (qmail 71779 invoked by uid 60001); 23 May 2011 09:40:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306143644; bh=jxuoIRD9UUu6ONo5VDESGmevFU1hTdSj+GQvp+ALoYI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=ruTcwXyWoup2iiRF9GKgxMY2DY6GacEZOQkPJyUDHLWo24aEEBnvavLj69R5hUTmH2p9mqJbNSjQHXe02G23u40IJwVEuxXrXoFTqYh1LQ7/3O1PF1AUJuw+1kR1bAHHb1ucZLwr7IXL5LjMFpOJtc4BO5yJgD+iOf0x+Xxd67U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=NorVeZ5mcTr2vc+od0Int0QHjiujWSJL3eheEe+G0MEKlr18gsLjbkqvEeP2ahUUOPaRELSA/R5UwknuiONzaF0nhWYV/5S5rl7+fatf6CTplgPguPn5iz5Vp6FTfG8xBGJ//lvF06BPlY0wP2zLJyxCURV9RaTY3w1dK1PvRyI=; Message-ID: <143120.60909.qm@web110808.mail.gq1.yahoo.com> X-YMail-OSG: bhOFBYoVM1mqTaudF0r3cbQZxg.FEadfbFfoFpZD2.m3ueM 9ecBVPZQ7KskfPh49jQ4.GQnb9cIv8P98O4Va2eIEvD5bPRtPWXaywxOreEj gvODxzabN.tRf_5J7yHGajgOaAzIIaZm9DuHP6_0ruE0Me0QXJ7ZA9UDO.EC 6L_IcYAtX6IPlhWeDdkUNkhtb1dWqW9OK0NfvLtC3fePjTTQsbYUDSs3XVd7 teP9boNANL3gkRga1Lb5v5tqTK1SB7CrM3vIIhabxTKCyysXgJlWs4SjFybT 6ADOmEwumuEbxepcG2SkYS9ujWnoicJrA_xaCsK6Hc64C23bYN0ziwxVwbpB SoUytpZ1LzjZWEzgRUPNrU2tFYBYIi8eGSKcUXRvK0Ke7eParlA1vKpgIPE. PrXuPbYQ2Ev1ghg-- Received: from [95.183.152.30] by web110808.mail.gq1.yahoo.com via HTTP; Mon, 23 May 2011 02:40:44 PDT X-Mailer: YahooMailRC/567 YahooMailWebService/0.8.111.303096 Date: Mon, 23 May 2011 02:40:44 -0700 (PDT) From: bakyt eshmurzaev <ebakyt@yahoo.com> To: emu@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-105574314-1306143644=:60909" Subject: [Emu] Mutual Authentication with .. X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 May 2011 09:40:48 -0000 --0-105574314-1306143644=:60909 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0AMutual Authentication with EAP-MD5 =0A=0ADear all, =0A=0AI hope it is ri= ght place to ask this question. =0AIn these days, I am learning a protocol = verification tool and trying to verify =0AEAP methods. =0A=0AI want to see = if the tool can find known attacks that can be launched to these =0Aprotoco= ls. =0A=0AAnd started with basic one - EAP-MD5. =0A=0AThe [rfc1994 CHAP 19= 96] states CHAP protocol is only one-way authentication. =0ABut by negotiat= ing CHAP in both directions the same secret set may easily be =0Aused for m= utual authentication.=0A=0AIn [rfc3748 EAP 2004] it is said that the sequen= ce of Requests and Responses =0Acontinues as long as needed.=0AThe Request = packet is sent by the authenticator to the peer. =0A=0AMy questions are: = =0A1) Is it possible to mutually authenticate Peer and Server using EAP-MD5= ?=0A2) If it is possible then how will messages exchange ? =0A3) is it pos= sible that peer also can send request (Or may the Peer can send a =0Achalle= nge in the Respond packet) ? =0A=0A4) Can it be like following : =0A=0AP <-= - S : Request_Id=0AP --> S : Respond_Id.User_Id=0A=0AP <-- S : Ser= ver_Challenge, Server_Id=0AP --> S : Hash(User_Id.Secret.Server_Challeng= e), User_Challenge=0AP <-- S : Hash(Server_Id.Secret.User_Challenge), E= AP_Success =0A % or EAP_Failure =0A=0A=0Awhere=0AP = : Peer=0AS : Server=0ASecret : Password (symme= tric key) =0AHash : One-way hash function =0A=0A=0AI'm very not sur= e, =0APlease correct me =0A=0AYour help would be greatly appreciated=0A=0AT= hank you very much =0A=0A=0AP.S. I think I explained what my problem is. M= y English is not good. --0-105574314-1306143644=:60909 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he= ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon= t-size:12pt;color:#000000;"><div><br>Mutual Authentication with EAP-MD5 <br= ><br>Dear all, <br><br>I hope it is right place to ask this question. <br>I= n these days, I am learning a protocol verification tool and trying to veri= fy EAP methods. <br>I want to see if the tool can find known attacks that c= an be launched to these protocols. <br>And started with basic one - EAP-MD5= .  <br><br>The [rfc1994 CHAP 1996] states CHAP protocol is only one-wa= y authentication. <br>But by negotiating CHAP in both directions the same s= ecret set may easily be used for mutual authentication.<br><br>In [rfc3748 = EAP 2004] it is said that the sequence of Requests and Responses continues = as long as needed.<br>The Request packet is sent by the authenticator to th= e peer. <br><br>My questions are: <br>1) Is it possible to mutually authenticate Peer and Server using EAP-MD5 ?<br>2) If it is possible then = how will messages exchange ? <br>3) is it possible that peer also can send = request (Or may the Peer can send a challenge in the Respond packet) ? <br>= 4) Can it be like following : <br><br>P <-- S :    Reques= t_Id<br>P --> S :    Respond_Id.User_Id<br><br>P <-- S= :    Server_Challenge, Server_Id<br>P --> S :  = ;  Hash(User_Id.Secret.Server_Challenge), User_Challenge<br>P <-- S= :     Hash(Server_Id.Secret.User_Challenge), EAP_Success &n= bsp;               &= nbsp;       % or EAP_Failure <br><br>where<br>P&nb= sp;           : Peer<br>S &nbs= p;          : Server<br>Secret  &nb= sp;      : Password (symmetric key) <br>Hash         : One-way hash function <br><br><br>= I'm very not sure, <br>Please correct me <br><br>Your help would be greatly= appreciated<br><br>Thank you very much <br><br><br>P.S.  I think I ex= plained what my problem is. My English is not good. <br><br><br></div>=0A</= div></body></html> --0-105574314-1306143644=:60909-- From stefan.winter@restena.lu Mon May 23 02:50:23 2011 Return-Path: <stefan.winter@restena.lu> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40FFE0779 for <emu@ietfa.amsl.com>; Mon, 23 May 2011 02:50:23 -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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0Mmhf4XnFem for <emu@ietfa.amsl.com>; Mon, 23 May 2011 02:50:23 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 71193E0776 for <emu@ietf.org>; Mon, 23 May 2011 02:50:20 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id AB9BA10584; Mon, 23 May 2011 11:50:18 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 577DB10582; Mon, 23 May 2011 11:50:18 +0200 (CEST) Message-ID: <4DDA2DD5.6060005@restena.lu> Date: Mon, 23 May 2011 11:50:13 +0200 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: emu@ietf.org, ebakyt@yahoo.com References: <143120.60909.qm@web110808.mail.gq1.yahoo.com> In-Reply-To: <143120.60909.qm@web110808.mail.gq1.yahoo.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig274DC78F91065D567B552821" X-Virus-Scanned: ClamAV Subject: Re: [Emu] Mutual Authentication with .. X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 May 2011 09:50:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig274DC78F91065D567B552821 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, you may want to look at MSCHAPv2, RFC2759. From its introduction: * MS-CHAP-V2 provides mutual authentication between peers by piggybacking a peer challenge on the Response packet and an authenticator response on the Success packet. which seems to be roughly what you described below. Greetings, Stefan Winter Am 23.05.2011 11:40, schrieb bakyt eshmurzaev: > > Mutual Authentication with EAP-MD5 > > Dear all, > > I hope it is right place to ask this question. > In these days, I am learning a protocol verification tool and trying > to verify EAP methods. > I want to see if the tool can find known attacks that can be launched > to these protocols. > And started with basic one - EAP-MD5.=20 > > The [rfc1994 CHAP 1996] states CHAP protocol is only one-way > authentication. > But by negotiating CHAP in both directions the same secret set may > easily be used for mutual authentication. > > In [rfc3748 EAP 2004] it is said that the sequence of Requests and > Responses continues as long as needed. > The Request packet is sent by the authenticator to the peer. > > My questions are: > 1) Is it possible to mutually authenticate Peer and Server using EAP-MD= 5 ? > 2) If it is possible then how will messages exchange ? > 3) is it possible that peer also can send request (Or may the Peer can > send a challenge in the Respond packet) ? > 4) Can it be like following : > > P <-- S : Request_Id > P --> S : Respond_Id.User_Id > > P <-- S : Server_Challenge, Server_Id > P --> S : Hash(User_Id.Secret.Server_Challenge), User_Challenge > P <-- S : Hash(Server_Id.Secret.User_Challenge), EAP_Success =20 > % or EAP_Failure > > where > P : Peer > S : Server > Secret : Password (symmetric key) > Hash : One-way hash function > > > I'm very not sure, > Please correct me > > Your help would be greatly appreciated > > Thank you very much > > > P.S. I think I explained what my problem is. My English is not good. > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig274DC78F91065D567B552821 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3aLdkACgkQ+jm90f8eFWbjEgCeLY99Y/edmSvZwJzpOSzO+RDg VpIAn0u9ZkX81rHr1GcD0RVLmilfxeaU =Nuak -----END PGP SIGNATURE----- --------------enig274DC78F91065D567B552821-- From stefan.winter@restena.lu Mon May 23 05:45:29 2011 Return-Path: <stefan.winter@restena.lu> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AA9E0791 for <emu@ietfa.amsl.com>; Mon, 23 May 2011 05:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=1.348, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQnXmxCFLyLQ for <emu@ietfa.amsl.com>; Mon, 23 May 2011 05:45:28 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8016FE06AF for <emu@ietf.org>; Mon, 23 May 2011 05:45:28 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 03147106CB for <emu@ietf.org>; Mon, 23 May 2011 14:45:25 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id EAA1A10582 for <emu@ietf.org>; Mon, 23 May 2011 14:45:24 +0200 (CEST) Message-ID: <4DDA56E4.7060100@restena.lu> Date: Mon, 23 May 2011 14:45:24 +0200 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: emu@ietf.org References: <C9F705C0.8516%ncamwing@cisco.com> <4DD224B4.6030605@deployingradius.com> <4DD33259.6030703@net-zen.net> <4DD35B88.3060403@deployingradius.com> <4DD360FD.4000906@net-zen.net> In-Reply-To: <4DD360FD.4000906@net-zen.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5997A1FEEF4198D6A0CD59F3" X-Virus-Scanned: ClamAV Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 May 2011 12:45:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5997A1FEEF4198D6A0CD59F3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > two suggestions for the new name (assuming that the Deciders establish > that a new type is a good idea), just to get the ball rolling: Tunneled= > Extensible Authentication Method (TEAM, an oldie but goody) and Interne= t > (or IETF) Tunneled EAP Method (ITEM). Crazy thought: how about EAP-TUNNEL? Yes, I know, not an acronym, just a plain old English word which makes sense on its own - which probably breaks several "but it needs to be a four-letter acronym, preferably a nicely sounding one, with a strange expansion which is obviously reverse-engineered from the acronym to sound cool" policies. Stefan > ... > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig5997A1FEEF4198D6A0CD59F3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3aVuQACgkQ+jm90f8eFWaTxQCfdOEVg/y6d0Wkz+QMNprjgQMn m74An14K296BLO50Y+a1Hegg8OGd8HZw =6qon -----END PGP SIGNATURE----- --------------enig5997A1FEEF4198D6A0CD59F3-- From jsalowey@cisco.com Mon May 23 10:53:08 2011 Return-Path: <jsalowey@cisco.com> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97542E0670 for <emu@ietfa.amsl.com>; Mon, 23 May 2011 10:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hpiGWqQJUWW for <emu@ietfa.amsl.com>; Mon, 23 May 2011 10:53:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id D2979E0658 for <emu@ietf.org>; Mon, 23 May 2011 10:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1526; q=dns/txt; s=iport; t=1306173187; x=1307382787; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/KDOq30frJlWNaNwXRkakX2laKgCEq9x5r+NTqyHhF8=; b=hxnK9Zha9GLZ5Dk6UrnkA3X3AFjJ4isdB14+A/JzUkJlQ2ASnzAmnTHI Ws7CoFIcY8tOsGi2NNwjkZ1UzeMuMmHZzEY/EnpE6qDAzjHQ1eftJ8VVr mvnOV3/wVU/Op65W9oWnBzu1BBIgQP2WuSFCmvidne4pffkg5PvKUYAoy M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABue2k2rRDoJ/2dsb2JhbACmJ3eIcJ5OnUGGGQSGUIlBhC+KZg X-IronPort-AV: E=Sophos;i="4.65,257,1304294400"; d="scan'208";a="362595634" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 23 May 2011 17:53:07 +0000 Received: from [10.35.71.67] ([10.35.71.67]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4NHr7i7020884; Mon, 23 May 2011 17:53:07 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey <jsalowey@cisco.com> In-Reply-To: <4DCD4E3F.70601@deployingradius.com> Date: Mon, 23 May 2011 10:53:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <FF651006-95C1-4572-A282-D83CA660A6FC@cisco.com> References: <4DCD4E3F.70601@deployingradius.com> To: Alan DeKok <aland@deployingradius.com> X-Mailer: Apple Mail (2.1084) Cc: "emu@ietf.org" <emu@ietf.org> Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 May 2011 17:53:08 -0000 One benefit I see in keeping the same EAP method type code is it allows = secure version negotiation from v1 to v2 with version rollback = protection. However, moving to a new EAP type code would seem to make = EAP method negotiation somewhat better since all implementation may not = implement v1. I'm OK with assigning a new EAP method type code, but = I'd like to try to maintain some backward compatibility with the v1 = versioning in the case that v1 implementations find it advantageous to = negotiate the v2 feature set under the v1 type code.=20 Cheers, Joe On May 13, 2011, at 8:29 AM, Alan DeKok wrote: >=20 > Since we have reached WG consensus on the method, can the authors of >=20 > draft-zhou-emu-eap-fastv2-00.txt >=20 > please re-submit the document as: >=20 > draft-ietf-emu-eap-tunnel-method-00.txt >=20 > The reason for the name change is that there have been questions > raised about whether this document should be left as EAP-FASTv2, or > whether it should request allocation of a new EAP type. >=20 > Since the document name (individual draft) currently reflects the EAP > type name, abstracting that would be useful. That way the document = name > will not change no matter what the WG decides to do. >=20 > Anyone with opinions either way is requested to discuss the pros and > cons of the issue. >=20 > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From gwz@net-zen.net Mon May 23 17:50:12 2011 Return-Path: <gwz@net-zen.net> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A84AE07FF for <emu@ietfa.amsl.com>; Mon, 23 May 2011 17:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTj9q-DF3YHt for <emu@ietfa.amsl.com>; Mon, 23 May 2011 17:50:11 -0700 (PDT) Received: from smtpauth01.prod.mesa1.secureserver.net (smtpauth01.prod.mesa1.secureserver.net [64.202.165.181]) by ietfa.amsl.com (Postfix) with SMTP id 98A80E07FA for <emu@ietf.org>; Mon, 23 May 2011 17:50:11 -0700 (PDT) Received: (qmail 7908 invoked from network); 24 May 2011 00:50:10 -0000 Received: from unknown (124.120.74.224) by smtpauth01.prod.mesa1.secureserver.net (64.202.165.181) with ESMTP; 24 May 2011 00:50:10 -0000 Message-ID: <4DDB00BD.2050504@net-zen.net> Date: Tue, 24 May 2011 07:50:05 +0700 From: Glen Zorn <gwz@net-zen.net> Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Joe Salowey <jsalowey@cisco.com> References: <4DCD4E3F.70601@deployingradius.com> <FF651006-95C1-4572-A282-D83CA660A6FC@cisco.com> In-Reply-To: <FF651006-95C1-4572-A282-D83CA660A6FC@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------080008070903030504080402" Cc: "emu@ietf.org" <emu@ietf.org> Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 24 May 2011 00:50:12 -0000 This is a multi-part message in MIME format. --------------080008070903030504080402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/24/2011 12:53 AM, Joe Salowey wrote: > One benefit I see in keeping the same EAP method type code is it allows secure version negotiation from v1 to v2 with version rollback protection. > > However, moving to a new EAP type code would seem to make EAP method negotiation somewhat better since all implementation may not implement v1. > > I'm OK with assigning a new EAP method type code, but I'd like to try to maintain some backward compatibility with the v1 versioning in the case that v1 > > implementations find it advantageous to negotiate the v2 feature set under the v1 type code. None of this seems to me to be relevant to the IETF, the emu WG or the discussion at hand. Just to be clear, EAP-FAST is not a product of any IETF WG and does not specify a standard of any kind. Furthermore, regardless of the IANA type registration status, EAP-FAST is, in fact, a proprietary protocol; it's publication in RFC 4851 reflects the RFC Series as a vanity press, not the IETF as a SDO. The method that this WG is developing will be a standard, however, and must not be tethered in any way to a proprietary protocol; i.e., backward compatibility with EAP-FAST. Whatever the name of the tunneled method ends up to be, the version number must be one (1). If a vendor wants to track the IETF protocol development for whatever reason so that, for example, v2 of its protocol is equivalent to v1 of the standard then that is their choice, but enabling (let alone encouraging) that behavior is not any of our concern. ... --------------080008070903030504080402 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------080008070903030504080402-- From gwz@net-zen.net Tue May 24 20:46:11 2011 Return-Path: <gwz@net-zen.net> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ABCE0785 for <emu@ietfa.amsl.com>; Tue, 24 May 2011 20:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuzEy1LJ22RV for <emu@ietfa.amsl.com>; Tue, 24 May 2011 20:46:10 -0700 (PDT) Received: from smtpauth01.prod.mesa1.secureserver.net (smtpauth01.prod.mesa1.secureserver.net [64.202.165.181]) by ietfa.amsl.com (Postfix) with SMTP id 72826E075E for <emu@ietf.org>; Tue, 24 May 2011 20:46:10 -0700 (PDT) Received: (qmail 22908 invoked from network); 25 May 2011 03:46:09 -0000 Received: from unknown (124.120.106.166) by smtpauth01.prod.mesa1.secureserver.net (64.202.165.181) with ESMTP; 25 May 2011 03:46:08 -0000 Message-ID: <4DDC7B7B.6030204@net-zen.net> Date: Wed, 25 May 2011 10:46:03 +0700 From: Glen Zorn <gwz@net-zen.net> Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stefan Winter <stefan.winter@restena.lu> References: <C9F705C0.8516%ncamwing@cisco.com> <4DD224B4.6030605@deployingradius.com> <4DD33259.6030703@net-zen.net> <4DD35B88.3060403@deployingradius.com> <4DD360FD.4000906@net-zen.net> <4DDA56E4.7060100@restena.lu> In-Reply-To: <4DDA56E4.7060100@restena.lu> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------000802010408020302030901" Cc: emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 May 2011 03:46:11 -0000 This is a multi-part message in MIME format. --------------000802010408020302030901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/23/2011 7:45 PM, Stefan Winter wrote: > Hi, > >> two suggestions for the new name (assuming that the Deciders establish >> that a new type is a good idea), just to get the ball rolling: Tunneled >> Extensible Authentication Method (TEAM, an oldie but goody) and Internet >> (or IETF) Tunneled EAP Method (ITEM). > > Crazy thought: how about EAP-TUNNEL? > > Yes, I know, not an acronym, just a plain old English word which makes > sense on its own - which probably breaks several "but it needs to be a > four-letter acronym, preferably a nicely sounding one, with a strange > expansion which is obviously reverse-engineered from the acronym to > sound cool" policies. Actually, I was pleasantly surprised that "Internet Tunneled EAP Method" turned out to be ITEM but in any case...I'm sure that there is no policy except maybe having a little fun ;-). Maybe that should be against policy? I do think that EAP-TUNNEL is both grammatically incorrect (since "tunnel" is a common noun it shouldn't be capitalized, let alone ALL CAPS :-). Also, I wonder if it isn't a bit too generic: there are a whole bunch of PEAP clones (sorry, tunneled methods) already: TTLS, FAST, etc., all of which could be reasonably referred to as "EAP TUNNEL". ... --------------000802010408020302030901 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------000802010408020302030901-- From ietf-denmike@snkmail.com Thu May 19 06:13:05 2011 Return-Path: <ietf-denmike@snkmail.com> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D91BE075B for <emu@ietfa.amsl.com>; Thu, 19 May 2011 06:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOpnDqehKUBn for <emu@ietfa.amsl.com>; Thu, 19 May 2011 06:13:04 -0700 (PDT) Received: from sneak2.sneakemail.com (sneak2.sneakemail.com [38.113.6.65]) by ietfa.amsl.com (Postfix) with SMTP id B6DE9E06EA for <emu@ietf.org>; Thu, 19 May 2011 06:13:04 -0700 (PDT) Received: (qmail 19283 invoked from network); 19 May 2011 13:13:02 -0000 Received: from unknown (HELO localhost.localdomain) (192.168.0.1) by sneak2.sneakemail.com with SMTP; 19 May 2011 13:13:02 -0000 Received: from 192.168.0.2 by mail.sneakemail.com with SMTP; 19 May 2011 13:13:02 -0000 Received: (sneakemail censored 18168-1305810782-800868 #2); 19 May 2011 13:13:02 -0000 Received: (sneakemail censored 18168-1305810782-800868 #1); 19 May 2011 13:13:02 -0000 Date: Thu, 19 May 2011 13:13:02 +0000 To: emu@ietf.org Message-ID: <18168-1305810782-800868@sneakemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 From: "Michael Thomsen" <ietf-denmike@snkmail.com> X-Mailer: Perl5 Mail::Internet v X-Mailman-Approved-At: Tue, 24 May 2011 21:28:33 -0700 Subject: [Emu] draft-urien-eap-smartcard-20.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 19 May 2011 13:14:54 -0000 Hi, anybody knows if this document is still being updated? Some of the EAP-AKA test vectors doesn't seem to add up with the EAP-AKA RFC4187. Kind regards, Michael Thomsen From stefan.winter@restena.lu Wed May 25 00:23:44 2011 Return-Path: <stefan.winter@restena.lu> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19C0E06B2 for <emu@ietfa.amsl.com>; Wed, 25 May 2011 00:23:44 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D41n1zCV07mf for <emu@ietfa.amsl.com>; Wed, 25 May 2011 00:23:44 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 73FA4E069A for <emu@ietf.org>; Wed, 25 May 2011 00:23:43 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 6DAA5106CB; Wed, 25 May 2011 09:23:39 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 46BD910694; Wed, 25 May 2011 09:23:39 +0200 (CEST) Message-ID: <4DDCAE77.1050509@restena.lu> Date: Wed, 25 May 2011 09:23:35 +0200 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Glen Zorn <gwz@net-zen.net> References: <C9F705C0.8516%ncamwing@cisco.com> <4DD224B4.6030605@deployingradius.com> <4DD33259.6030703@net-zen.net> <4DD35B88.3060403@deployingradius.com> <4DD360FD.4000906@net-zen.net> <4DDA56E4.7060100@restena.lu> <4DDC7B7B.6030204@net-zen.net> In-Reply-To: <4DDC7B7B.6030204@net-zen.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig86CAD46698E839CC20B8C6B6" X-Virus-Scanned: ClamAV Cc: emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 May 2011 07:23:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig86CAD46698E839CC20B8C6B6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Actually, I was pleasantly surprised that "Internet Tunneled EAP Method= " > turned out to be ITEM but in any case...I'm sure that there is no polic= y > except maybe having a little fun ;-). Maybe that should be against > policy? I do think that EAP-TUNNEL is both grammatically incorrect > (since "tunnel" is a common noun it shouldn't be capitalized, let alone= > ALL CAPS :-). I didn't want to violate more common thinking about naming by using non-capitals! EAP-Tunnel would be just as fine for me. > Also, I wonder if it isn't a bit too generic: there are a > whole bunch of PEAP clones (sorry, tunneled methods) already: TTLS, > FAST, etc., all of which could be reasonably referred to as "EAP TUNNEL= ". That's right. We should prefix it as "*/the/*" EAP Tunnel to make people aware that it's the one-and-only type to be used. Yes, I'm actually dreaming that the deployed world out there would settle to use just one in a distant future... Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig86CAD46698E839CC20B8C6B6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3crnsACgkQ+jm90f8eFWbkmgCfWdYYffPbe6An7JPaSm1LwLUL A40An2C9kodGF3Lnb0lOFyDnAflhBfsR =W8o2 -----END PGP SIGNATURE----- --------------enig86CAD46698E839CC20B8C6B6-- From dharkins@lounge.org Wed May 25 08:16:47 2011 Return-Path: <dharkins@lounge.org> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3E5130035 for <emu@ietfa.amsl.com>; Wed, 25 May 2011 08:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qFZzbo41wW2 for <emu@ietfa.amsl.com>; Wed, 25 May 2011 08:16:46 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2BFE0750 for <emu@ietf.org>; Wed, 25 May 2011 08:16:46 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4FEE1A888108; Wed, 25 May 2011 08:16:44 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 25 May 2011 08:16:44 -0700 (PDT) Message-ID: <08a5cd6b488c1054953b2cfff9eccd64.squirrel@www.trepanning.net> In-Reply-To: <4DDCAE77.1050509@restena.lu> References: <C9F705C0.8516%ncamwing@cisco.com> <4DD224B4.6030605@deployingradius.com> <4DD33259.6030703@net-zen.net> <4DD35B88.3060403@deployingradius.com> <4DD360FD.4000906@net-zen.net> <4DDA56E4.7060100@restena.lu> <4DDC7B7B.6030204@net-zen.net> <4DDCAE77.1050509@restena.lu> Date: Wed, 25 May 2011 08:16:44 -0700 (PDT) From: "Dan Harkins" <dharkins@lounge.org> To: "Stefan Winter" <stefan.winter@restena.lu> User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: emu@ietf.org Subject: Re: [Emu] Some questions about eap type code and the tunnel method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 May 2011 15:16:47 -0000 On Wed, May 25, 2011 12:23 am, Stefan Winter wrote: > Hi, > >> Actually, I was pleasantly surprised that "Internet Tunneled EAP Method" >> turned out to be ITEM but in any case...I'm sure that there is no policy >> except maybe having a little fun ;-). Maybe that should be against >> policy? I do think that EAP-TUNNEL is both grammatically incorrect >> (since "tunnel" is a common noun it shouldn't be capitalized, let alone >> ALL CAPS :-). > > I didn't want to violate more common thinking about naming by using > non-capitals! EAP-Tunnel would be just as fine for me. > >> Also, I wonder if it isn't a bit too generic: there are a >> whole bunch of PEAP clones (sorry, tunneled methods) already: TTLS, >> FAST, etc., all of which could be reasonably referred to as "EAP >> TUNNEL". > > That's right. We should prefix it as "*/the/*" EAP Tunnel to make people > aware that it's the one-and-only type to be used. Yes, I'm actually > dreaming that the deployed world out there would settle to use just one > in a distant future... Let me offer my suggestion again: Extensible Tunneled Authentication or EAP-ETA. "What's the ETA?" Well the way this group progresses it's probably about...wait, sorry, ETA is the shiny new fantabulous EAP method from EMU! regards, Dan. From jsalowey@cisco.com Mon May 30 21:06:55 2011 Return-Path: <jsalowey@cisco.com> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E9FE0697 for <emu@ietfa.amsl.com>; Mon, 30 May 2011 21:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH4xqpttitus for <emu@ietfa.amsl.com>; Mon, 30 May 2011 21:06:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id A7D04E073B for <emu@ietf.org>; Mon, 30 May 2011 21:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1931; q=dns/txt; s=iport; t=1306814810; x=1308024410; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hW6qh7ou40FW+9EdGF1dsFyo3ILQFWnzrY37rBCUMUA=; b=HOrUsu31HxPRWMayRfBcdX7wON1HTERPBSBxzns7dOnAE/O7GPRjeOUH Pfb4uoXBgf3Wki8bK3PjmJK2DliHJoG5YAn9JeU9+B4bUU7YGeCOakG0s 9hdygRQrlQ0wPHLJLQFWa3DvxAVYcCgM0WpJJYIsm3BInonuMXo9OulSF k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANto5E2rRDoJ/2dsb2JhbABTpit3iHGdP51Mhh4EhmSJa4Q+inw X-IronPort-AV: E=Sophos;i="4.65,295,1304294400"; d="scan'208";a="456741421" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 31 May 2011 04:06:50 +0000 Received: from [10.33.248.52] ([10.33.248.52]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4V46ne1028602; Tue, 31 May 2011 04:06:49 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey <jsalowey@cisco.com> In-Reply-To: <4DDB00BD.2050504@net-zen.net> Date: Mon, 30 May 2011 21:08:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <AD1CA0FC-B1A3-46AD-8C0A-D931FD55D6AC@cisco.com> References: <4DCD4E3F.70601@deployingradius.com> <FF651006-95C1-4572-A282-D83CA660A6FC@cisco.com> <4DDB00BD.2050504@net-zen.net> To: Glen Zorn <gwz@net-zen.net> X-Mailer: Apple Mail (2.1084) Cc: "emu@ietf.org" <emu@ietf.org> Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 31 May 2011 04:06:55 -0000 On May 23, 2011, at 5:50 PM, Glen Zorn wrote: > On 5/24/2011 12:53 AM, Joe Salowey wrote: >=20 >> One benefit I see in keeping the same EAP method type code is it = allows secure version negotiation from v1 to v2 with version rollback = protection. =20 >>=20 >> However, moving to a new EAP type code would seem to make EAP method = negotiation somewhat better since all implementation may not implement = v1. =20 >>=20 >> I'm OK with assigning a new EAP method type code, but I'd like to = try to maintain some backward compatibility with the v1 versioning in = the case that v1=20 >>=20 >> implementations find it advantageous to negotiate the v2 feature set = under the v1 type code.=20 >=20 > None of this seems to me to be relevant to the IETF, the emu WG or the > discussion at hand. =20 [Joe] I would hope that negotiation of methods is relevant to the EMU = WG. =20 > Just to be clear, EAP-FAST is not a product of any > IETF WG and does not specify a standard of any kind. Furthermore, > regardless of the IANA type registration status, EAP-FAST is, in fact, = a > proprietary protocol; it's publication in RFC 4851 reflects the RFC > Series as a vanity press, not the IETF as a SDO. The method that this > WG is developing will be a standard, however, and must not be tethered > in any way to a proprietary protocol; i.e., backward compatibility = with > EAP-FAST. Whatever the name of the tunneled method ends up to be, the > version number must be one (1). =20 [Joe] A new method name would be good. How the protocol evolves is up = to the working group. =20 > If a vendor wants to track the IETF > protocol development for whatever reason so that, for example, v2 of = its > protocol is equivalent to v1 of the standard then that is their = choice, > but enabling (let alone encouraging) that behavior is not any of our > concern. >=20 > ... > <gwz.vcf> From pascal.urien@gmail.com Wed May 25 05:43:53 2011 Return-Path: <pascal.urien@gmail.com> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E539E072E for <emu@ietfa.amsl.com>; Wed, 25 May 2011 05:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm0U-hG6Sks3 for <emu@ietfa.amsl.com>; Wed, 25 May 2011 05:43:53 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE53FE0723 for <emu@ietf.org>; Wed, 25 May 2011 05:43:52 -0700 (PDT) Received: by qwc23 with SMTP id 23so6150301qwc.31 for <emu@ietf.org>; Wed, 25 May 2011 05:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sGwH9KiopZgYEYi4ReZhmt12DIaT5N7wCoxWi1k5AnU=; b=KQozkE9uN42aCtvN6DAXa7RZJICywcnwzcQ9+saFHJgdpgKmy4oaIubfvR+lvKO2vA fPrRd8Sv0jw00/zk1VHvCMDTmdzK/dPYov2/anKOEL0aKm/VafFAvwLregu0WkyR0UVj oMWUi6OodDpDcEeVE4LgAT6yCjJ59J7drTSuI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hqop9IFL2QoKbvwQnWV+Ino1DYsZWRrT11b78MMWc5gvPNfVzkmLJnGezXyUjSICAq dkPmoNSEeVtZbDAKp7J0Exw6xRT+Igidi6KvkFwrWIJeRYOCe22xhqA96rxndfOXw4MQ Hf7kfMsrq1fSdQ0Sz4Mcun47rz+vkrWqSOvQI= MIME-Version: 1.0 Received: by 10.229.1.166 with SMTP id 38mr3626210qcf.195.1306327432374; Wed, 25 May 2011 05:43:52 -0700 (PDT) Received: by 10.229.80.133 with HTTP; Wed, 25 May 2011 05:43:52 -0700 (PDT) In-Reply-To: <18168-1305810782-800868@sneakemail.com> References: <18168-1305810782-800868@sneakemail.com> Date: Wed, 25 May 2011 14:43:52 +0200 Message-ID: <BANLkTimfezcR-oC7p+oR+cj3ct1swrjn5w@mail.gmail.com> From: Pascal Urien <pascal.urien@gmail.com> To: Michael Thomsen <ietf-denmike@snkmail.com> Content-Type: multipart/alternative; boundary=0016364d2ae591292a04a4190e1e X-Mailman-Approved-At: Mon, 30 May 2011 21:08:23 -0700 Cc: emu@ietf.org Subject: Re: [Emu] draft-urien-eap-smartcard-20.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 May 2011 12:43:53 -0000 --0016364d2ae591292a04a4190e1e Content-Type: text/plain; charset=ISO-8859-1 Hi The draft is still ipdated, by the vectore dealing with EAP-AKA are in conformance with the former EAP-AKA version Pascal Urien 2011/5/19 Michael Thomsen <ietf-denmike@snkmail.com> > Hi, > > anybody knows if this document is still being updated? > > Some of the EAP-AKA test vectors doesn't seem to add up with the EAP-AKA > RFC4187. > > Kind regards, > Michael Thomsen > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > --0016364d2ae591292a04a4190e1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hi</div> <div>=A0</div> <div>The draft is still ipdated, by the vectore dealing with EAP-AKA are in= conformance with the former EAP-AKA version</div> <div>=A0</div> <div>Pascal Urien<br><br></div> <div class=3D"gmail_quote">2011/5/19 Michael Thomsen <span dir=3D"ltr"><= <a href=3D"mailto:ietf-denmike@snkmail.com">ietf-denmike@snkmail.com</a>>= ;</span><br> <blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex= ; PADDING-LEFT: 1ex" class=3D"gmail_quote">Hi,<br><br>anybody knows if this= document is still being updated?<br><br>Some of the EAP-AKA test vectors d= oesn't seem to add up with the EAP-AKA RFC4187.<br> <br>Kind regards,<br><font color=3D"#888888">=A0Michael Thomsen<br>________= _______________________________________<br>Emu mailing list<br><a href=3D"m= ailto:Emu@ietf.org">Emu@ietf.org</a><br><a href=3D"https://www.ietf.org/mai= lman/listinfo/emu" target=3D"_blank">https://www.ietf.org/mailman/listinfo/= emu</a><br> </font></blockquote></div><br> --0016364d2ae591292a04a4190e1e-- From gwz@net-zen.net Mon May 30 23:25:18 2011 Return-Path: <gwz@net-zen.net> X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9741CE0734 for <emu@ietfa.amsl.com>; Mon, 30 May 2011 23:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLTJotkO73IB for <emu@ietfa.amsl.com>; Mon, 30 May 2011 23:25:18 -0700 (PDT) Received: from smtpauth18.prod.mesa1.secureserver.net (smtpauth18.prod.mesa1.secureserver.net [64.202.165.31]) by ietfa.amsl.com (Postfix) with SMTP id CD7C5E06D4 for <emu@ietf.org>; Mon, 30 May 2011 23:25:17 -0700 (PDT) Received: (qmail 3637 invoked from network); 31 May 2011 06:25:16 -0000 Received: from unknown (124.120.176.220) by smtpauth18.prod.mesa1.secureserver.net (64.202.165.31) with ESMTP; 31 May 2011 06:25:16 -0000 Message-ID: <4DE489C6.40900@net-zen.net> Date: Tue, 31 May 2011 13:25:10 +0700 From: Glen Zorn <gwz@net-zen.net> Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Joe Salowey <jsalowey@cisco.com> References: <4DCD4E3F.70601@deployingradius.com> <FF651006-95C1-4572-A282-D83CA660A6FC@cisco.com> <4DDB00BD.2050504@net-zen.net> <AD1CA0FC-B1A3-46AD-8C0A-D931FD55D6AC@cisco.com> In-Reply-To: <AD1CA0FC-B1A3-46AD-8C0A-D931FD55D6AC@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------040906080908030306090503" Cc: "emu@ietf.org" <emu@ietf.org> Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/emu> List-Post: <mailto:emu@ietf.org> List-Help: <mailto:emu-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 31 May 2011 06:25:18 -0000 This is a multi-part message in MIME format. --------------040906080908030306090503 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/31/2011 11:08 AM, Joe Salowey wrote: > > On May 23, 2011, at 5:50 PM, Glen Zorn wrote: > >> On 5/24/2011 12:53 AM, Joe Salowey wrote: >> >>> One benefit I see in keeping the same EAP method type code is it allows secure version negotiation from v1 to v2 with version rollback protection. >>> >>> However, moving to a new EAP type code would seem to make EAP method negotiation somewhat better since all implementation may not implement v1. >>> >>> I'm OK with assigning a new EAP method type code, but I'd like to try to maintain some backward compatibility with the v1 versioning in the case that v1 >>> >>> implementations find it advantageous to negotiate the v2 feature set under the v1 type code. >> >> None of this seems to me to be relevant to the IETF, the emu WG or the >> discussion at hand. > > [Joe] I would hope that negotiation of methods is relevant to the EMU WG. Hmm. I thought we were talking about EAP-FAST version negotiation. > >> Just to be clear, EAP-FAST is not a product of any >> IETF WG and does not specify a standard of any kind. Furthermore, >> regardless of the IANA type registration status, EAP-FAST is, in fact, a >> proprietary protocol; it's publication in RFC 4851 reflects the RFC >> Series as a vanity press, not the IETF as a SDO. The method that this >> WG is developing will be a standard, however, and must not be tethered >> in any way to a proprietary protocol; i.e., backward compatibility with >> EAP-FAST. Whatever the name of the tunneled method ends up to be, the >> version number must be one (1). > > [Joe] A new method name would be good. A new EAP type would be better. If a new EAP type is assigned, how does it make sense to start the version numbering for that type @ 2? > How the protocol evolves is up to the working group. Absolutely, but unless the rules have changed rather drastically recently, I'm pretty sure that I'm a WG member... > >> If a vendor wants to track the IETF >> protocol development for whatever reason so that, for example, v2 of its >> protocol is equivalent to v1 of the standard then that is their choice, >> but enabling (let alone encouraging) that behavior is not any of our >> concern. >> >> ... >> <gwz.vcf> > > > --------------040906080908030306090503 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------040906080908030306090503--