From aland@deployingradius.com Thu Jan 6 01:54:18 2011 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A423A6D14 for ; Thu, 6 Jan 2011 01:54:18 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T92NWRbefHUi for ; Thu, 6 Jan 2011 01:54:17 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 68DDD3A6BA7 for ; Thu, 6 Jan 2011 01:54:17 -0800 (PST) Received: from [192.168.1.20] (unknown [93.15.72.6]) by liberty.deployingradius.com (Postfix) with ESMTPSA id E33BE12340D0 for ; Thu, 6 Jan 2011 10:56:22 +0100 (CET) Message-ID: <4D2591C7.4010708@deployingradius.com> Date: Thu, 06 Jan 2011 10:56:23 +0100 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] Call for proposals X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 09:54:18 -0000 This is a call for proposals to meet the tunnel method requirements defined in draft-ietf-emu-eaptunnel-req. Proposals must: * be in the form of an internet draft defining the method, including references to appropriate existing documents. * describe how the proposal meets the requirements. * be submitted by March 7, 2011, along with an email to the EMU list identifying the draft as a proposal. Proposers are encouraged to submit their draft before the cutoff date to allow for more discussion before the IETF in Prague. Thanks, EMU Chairs From hartmans@mit.edu Mon Jan 10 11:49:22 2011 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1CA43A6B12 for ; Mon, 10 Jan 2011 11:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.881 X-Spam-Level: X-Spam-Status: No, score=-102.881 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0535oJEJYPvE for ; Mon, 10 Jan 2011 11:49:22 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id E8CF33A6B15 for ; Mon, 10 Jan 2011 11:49:21 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (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 1CFF2200CC for ; Mon, 10 Jan 2011 14:50:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A79FB4228; Mon, 10 Jan 2011 14:51:35 -0500 (EST) From: Sam Hartman To: emu@ietf.org Date: Mon, 10 Jan 2011 14:51:35 -0500 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] Channel Bindings: RADIUS or Diameter namespace X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:49:22 -0000 At the last IETF, Glen proposed that rather than using diameter's namespace for channel binding AVPs we use the RADIUS namespace. There were two aspects to this concern. One is that diameter has a larger length value for attributes. If we're routinely exceeding 253-octets for values that are part of channel binding, then EAP is not a good The second aspect is that there is more overhead because the diameter namespace is larger. So far we've not been able to come across use cases for channel binding for attributes present in Diameter but not RADIUS. So, I'd like to propose that we adopt Glen's suggestion. This may call into question an earlier discussion. At IETF 78, we decided that we didn't need to have a mechanism for non-AAA channel binding attributes, because especially for Diameter it is relatively easy to add a new attribute. The RADIUS namespace is more constrained. I think we have a couple of options: 1) encourage the RADEXT work to extend the RADIUS namespace and work with RADEXT to make sure they will be OK if they have to approve a couple of attributes that we only expect to be used for channel binding. I still expect there will be few of these. 2) Have multiple namespaces for attributes we support. This may remove a lot of the overhead savings for RADIUS over Diameter; in the obvious implementation I'd expect we would waste a byte per AVP. 3) Decide Diameter is fine after all. I don't care much what option we adopt. I'd like to decide soon and propose that option 2 is most conservative. If no other consensus emerges I'd like to move forward with that option, effectively reversing our IETF 78 decision. Thoughts? From aland@deployingradius.com Tue Jan 11 00:40:56 2011 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477A53A6A05 for ; Tue, 11 Jan 2011 00:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JX2N7VsLAPIm for ; Tue, 11 Jan 2011 00:40:55 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 6AD0C3A69FB for ; Tue, 11 Jan 2011 00:40:55 -0800 (PST) Message-ID: <4D2C181E.8000405@deployingradius.com> Date: Tue, 11 Jan 2011 09:43:10 +0100 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] Channel Bindings: RADIUS or Diameter namespace X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 08:40:56 -0000 Sam Hartman wrote: > So, I'd like to propose that we adopt Glen's suggestion. Speaking as an individual, that sounds reasonable. > I think we have a couple of options: > > 1) encourage the RADEXT work to extend the RADIUS namespace and work > with RADEXT to make sure they will be OK if they have to approve a > couple of attributes that we only expect to be used for channel binding. > I still expect there will be few of these. There are multiple proposals in RADIUS to extend the namespace. Under current allocation pressure, the namespace may be exhausted in 2-3 years. That's about how long it takes for a new document to be standardized. > 2) Have multiple namespaces for attributes we support. This may remove > a lot of the overhead savings for RADIUS over Diameter; in the obvious > implementation I'd expect we would waste a byte per AVP. I'm not sure what you mean by that proposal. > 3) Decide Diameter is fine after all. > > I don't care much what option we adopt. I'd like to decide soon and > propose that option 2 is most conservative. If no other consensus > emerges I'd like to move forward with that option, effectively reversing > our IETF 78 decision. We should be aware of the alternatives,and costs/benefits before making or reversing any decision. Alan DeKok. From iesg-secretary@ietf.org Tue Jan 11 09:32:59 2011 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE09B3A6A64; Tue, 11 Jan 2011 09:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkwSURKM3+66; Tue, 11 Jan 2011 09:32:59 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ED3428C28A; Tue, 11 Jan 2011 09:32:58 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111173258.10518.44681.idtracker@localhost> Date: Tue, 11 Jan 2011 09:32:58 -0800 Cc: Internet Architecture Board , emu mailing list , emu chair , RFC Editor Subject: [Emu] Document Action: 'Requirements for a Tunnel Based EAP Method' to Informational RFC (draft-ietf-emu-eaptunnel-req-09.txt) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 17:33:00 -0000 The IESG has approved the following document: - 'Requirements for a Tunnel Based EAP Method' (draft-ietf-emu-eaptunnel-req-09.txt) as an Informational RFC This document is the product of the EAP Method Update Working Group. The IESG contact persons are Sean Turner and Tim Polk. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-emu-eaptunnel-req/ Technical Summary This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. Working Group Summary The document has had substantial review from a number of working group participants. The working group is ready to start working on protocols. Document Quality The document is a requirements document that has had contributions from Working group participants from different vendors. Discussion in the Working group has resulted in improvements to the document. Personnel Alan DeKok (aland@deployingradius.com) is the document shepherd. Sean Turner (turners@ieca.com) is the responsible Area Director. From turners@ieca.com Tue Jan 11 12:54:09 2011 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA673A635F for ; Tue, 11 Jan 2011 12:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpgQA1f32VtD for ; Tue, 11 Jan 2011 12:54:07 -0800 (PST) Received: from nm7-vm0.bullet.mail.sp2.yahoo.com (nm7-vm0.bullet.mail.sp2.yahoo.com [98.139.91.192]) by core3.amsl.com (Postfix) with SMTP id 0BBCA3A67B5 for ; Tue, 11 Jan 2011 12:54:06 -0800 (PST) Received: from [98.139.91.69] by nm7.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jan 2011 20:56:21 -0000 Received: from [98.139.91.9] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jan 2011 20:56:21 -0000 Received: from [127.0.0.1] by omp1009.mail.sp2.yahoo.com with NNFMP; 11 Jan 2011 20:56:21 -0000 X-Yahoo-Newman-Id: 341995.39627.bm@omp1009.mail.sp2.yahoo.com Received: (qmail 31391 invoked from network); 11 Jan 2011 20:56:21 -0000 Received: from thunderfish.local (turners@96.241.0.66 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 11 Jan 2011 12:56:20 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: Pahl5NAVM1nI6SQVxSdJnBwL2XPWz17HDBRnVkoDKwSv96F A3grKZkFON3xBgGRyE91vHmV8SxM7lZ7MSBNxZpdwJZeycsu8GRhHf26KQI6 3LoFosCGCjZqyqi3cfEGYULR5F_ns08yfdMVduL7FpEx4PNQfJbQ9R7e9QdT 2.rK0LCMex9jnXC5Mkhp7r7WCXUZnxO3XqIPVt6BMQPv7zni892jar6otFgP yZ5mB1qxn9fGg6aVNLjhdjEDIg6V.Cxy7BsEU_Tm_4kY.D7con_fiRntf1fK PJMzaz51FN.shFyePnKYOxS8iO_jckkg9hA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D2CB56F.4000109@ieca.com> Date: Tue, 11 Jan 2011 14:54:23 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: emu mailing list References: <20110111173258.10518.44681.idtracker@localhost> In-Reply-To: <20110111173258.10518.44681.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Emu] Document Action: 'Requirements for a Tunnel Based EAP Method' to Informational RFC (draft-ietf-emu-eaptunnel-req-09.txt) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 20:54:09 -0000 Congrats to all involved! Now lets pick one of the methods! spt On 1/11/11 12:32 PM, The IESG wrote: > The IESG has approved the following document: > - 'Requirements for a Tunnel Based EAP Method' > (draft-ietf-emu-eaptunnel-req-09.txt) as an Informational RFC > > This document is the product of the EAP Method Update Working Group. > > The IESG contact persons are Sean Turner and Tim Polk. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-emu-eaptunnel-req/ > > > > Technical Summary > > This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. > > Working Group Summary > > The document has had substantial review from a number of working group participants. The working group is ready to start working on protocols. > > Document Quality > > The document is a requirements document that has had contributions from Working group participants from different vendors. Discussion in the Working group has resulted in improvements to the document. > > Personnel > > Alan DeKok (aland@deployingradius.com) is the document shepherd. > Sean Turner (turners@ieca.com) is the responsible Area Director. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From jsalowey@cisco.com Tue Jan 11 15:30:37 2011 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1703A680A for ; Tue, 11 Jan 2011 15:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.585 X-Spam-Level: X-Spam-Status: No, score=-110.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZTfeys8WtJQ for ; Tue, 11 Jan 2011 15:30:36 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ADAF93A657C for ; Tue, 11 Jan 2011 15:30:36 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD53LE2rR7Hu/2dsb2JhbACkO3OkEJhhhUwEhGeGJYMgiBE Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 11 Jan 2011 23:32:54 +0000 Received: from [10.33.249.181] ([10.33.249.181]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0BNWqwn010546; Tue, 11 Jan 2011 23:32:53 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Tue, 11 Jan 2011 15:33:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <45C1E5B6-6DDB-43E0-97AD-47694242D021@cisco.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1082) Cc: emu@ietf.org Subject: Re: [Emu] Channel Bindings: RADIUS or Diameter namespace X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 23:30:37 -0000 On Jan 10, 2011, at 11:51 AM, Sam Hartman wrote: > At the last IETF, Glen proposed that rather than using diameter's > namespace for channel binding AVPs we use the RADIUS namespace. There > were two aspects to this concern. One is that diameter has a larger > length value for attributes. If we're routinely exceeding 253-octets = for > values that are part of channel binding, then EAP is not a good >=20 [Joe] I think we do want to discourage using large amounts of data as = channel bindings.=20 > The second aspect is that there is more overhead because the diameter > namespace is larger. >=20 > So far we've not been able to come across use cases for channel = binding > for attributes present in Diameter but not RADIUS. >=20 > So, I'd like to propose that we adopt Glen's suggestion. >=20 > This may call into question an earlier discussion. At IETF 78, we = decided > that we didn't need to have a mechanism for non-AAA channel binding > attributes, because especially for Diameter it is relatively easy to = add > a new attribute. > The RADIUS namespace is more constrained. >=20 [Joe] I think we need to have a way to add new attributes that are not = already present. If we don't then at some point we will end up with = the need to for a new attribute and we will have to revisit all this = again. =20 > I think we have a couple of options: >=20 > 1) encourage the RADEXT work to extend the RADIUS namespace and work > with RADEXT to make sure they will be OK if they have to approve a > couple of attributes that we only expect to be used for channel = binding. > I still expect there will be few of these. >=20 [Joe] While I think this would be good to do, I think this work should = be largely independent of and not tightly coupled to channel bindings . > 2) Have multiple namespaces for attributes we support. This may = remove > a lot of the overhead savings for RADIUS over Diameter; in the obvious > implementation I'd expect we would waste a byte per AVP. >=20 [Joe] To me this sounds the simplest, but I previously favored this = approach. =20 > 3) Decide Diameter is fine after all. >=20 > I don't care much what option we adopt. I'd like to decide soon and > propose that option 2 is most conservative. If no other consensus > emerges I'd like to move forward with that option, effectively = reversing > our IETF 78 decision. >=20 > Thoughts? > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu