From internet-drafts@ietf.org Sun Sep 18 12:05: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 D22CE21F891D; Sun, 18 Sep 2011 12:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScQ1qu-iL0dh; Sun, 18 Sep 2011 12:05:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D1D21F8888; Sun, 18 Sep 2011 12:05:53 -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.60 Message-ID: <20110918190553.4930.35881.idtracker@ietfa.amsl.com> Date: Sun, 18 Sep 2011 12:05:53 -0700 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-chbind-09.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: Sun, 18 Sep 2011 19:05:54 -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 : Channel Binding Support for EAP Methods Author(s) : Sam Hartman T. Charles Clancy Katrin Hoeper Filename : draft-ietf-emu-chbind-09.txt Pages : 30 Date : 2011-09-18 This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-09.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-chbind-09.txt From hartmans@mit.edu Sun Sep 18 12:10:38 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 CA63121F849D for ; Sun, 18 Sep 2011 12:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.159 X-Spam-Level: X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=-2.494, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmNVVzyTQaQb for ; Sun, 18 Sep 2011 12:10:38 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5924921F8472 for ; Sun, 18 Sep 2011 12:10:38 -0700 (PDT) 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 E50D1203BA for ; Sun, 18 Sep 2011 15:14:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 10C7042B9; Sun, 18 Sep 2011 15:12:09 -0400 (EDT) From: Sam Hartman To: emu@ietf.org Date: Sun, 18 Sep 2011 15:12:09 -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] Channel Bindings: Ready for Last 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: Sun, 18 Sep 2011 19:10:38 -0000 Hi. I've just submitted a draft that I think is ready for last call. Changes include: * Figures, thanks Katrin ! * Text stolen from Bernard's draft for the eap lower layer attribute * IANA considerations for the eap lower layer attribute * Removal of the 802.11-specific text per WG discussion in Quebec I'd appreciate it if someone besides Katrin would confirm that the diagrams match the text. --Sam From jsalowey@cisco.com Wed Sep 28 10:50:10 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 4C75521F8C93 for ; Wed, 28 Sep 2011 10:50:10 -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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2NNE0DojFYK for ; Wed, 28 Sep 2011 10:50:09 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 86FCF21F8C98 for ; Wed, 28 Sep 2011 10:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=153; q=dns/txt; s=iport; t=1317232378; x=1318441978; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=LDyFc+B9eKYrv/opJ0o2EsG9FmxYqftZsYIojto0gJM=; b=EBnP8t2fy0BKE/jQzE8V1AG1G9uJIV3N3hZfien8mWHopvFv8XvKGCLc LXK1uOqe0DyLN32zIRq0j11OdD7Tdl8oOMBppRijTWU81ORrWwCSJB3LI vjkF7IkWP5Fw2/BhC6A0USZHBT3w39rM36L00Eh3Z+xIEQAPX+4mE3s6l Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcHAIteg06rRDoI/2dsb2JhbABCmU2OP3iBbAEKHYIyoEuBJgGeKYYrYQSHcotjhSKMMw X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4819012" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 28 Sep 2011 17:52:58 +0000 Received: from [10.33.249.43] ([10.33.249.43]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8SHqugL024274 for ; Wed, 28 Sep 2011 17:52:57 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Sep 2011 10:53:12 -0700 Message-Id: <81E742DC-02A9-4FB2-B3CD-D35282DBCE58@cisco.com> To: emu@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Emu] Working Group Last Call for draft-ietf-emu-chbind-09 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, 28 Sep 2011 17:50:10 -0000 This is the working group last call for draft-ietf-emu-chbind-09. = Please send your comments to the list by October 21, 2011. =20 Thanks, Joe= From aland@deployingradius.com Wed Sep 28 13:01:41 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 13AE71F0CEC for ; Wed, 28 Sep 2011 13:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoCKrL5bP4rZ for ; Wed, 28 Sep 2011 13:01:33 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4003C1F0CD8 for ; Wed, 28 Sep 2011 13:01:23 -0700 (PDT) Message-ID: <4E837DB8.5010004@deployingradius.com> Date: Wed, 28 Sep 2011 22:04:08 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Joe Salowey References: <81E742DC-02A9-4FB2-B3CD-D35282DBCE58@cisco.com> In-Reply-To: <81E742DC-02A9-4FB2-B3CD-D35282DBCE58@cisco.com> 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] Working Group Last Call for draft-ietf-emu-chbind-09 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, 28 Sep 2011 20:01:41 -0000 Joe Salowey wrote: > This is the working group last call for draft-ietf-emu-chbind-09. Please send your comments to the list by October 21, 2011. I've read the document, and have comments as follows. Section 4.3 Page 11: For example, information carried in AAA attributes such as the NAS IP address may have been lost in transition and are thus not known to the EAP server. Even worse, that information might exist, but be entirely useless. For example, a NAS can be in a private network, and send a NAS IP address of 192.168/16. Many AAA proxy hops later, the EAP server receives that IP. As the next piece of text says: However, often verification of the MAC or IP address of the NAS is not useful for improving the overall security posture of a network. Channel bindings can be used to verify that the NAS is not lying (i.e. it is sending the same information to the client and to the EAP server.) But that information has no useful context, and is therefore useless for any purpose. Bottom of page 11, there is a typo "lyes" should be "lies". Page 11 and 12 again: As discussed in the next section, some of the most important information to verify cannot come from AAA attributes but instead comes from local configuration. For example in the mobile phone case, the expected roaming rate cannot come from the roaming provider without being verified against the contract between the two providers. Similarly, in an enterprise, the SSID a particular access point is expected to advertize is a matter of configuration rather typo: "advertise" than something that can be trusted because it is included in an AAA exchange. I think that this point could be clearer. The EAP peer and authenticator do not share trust, but all other parties do. Channel bdingins allows the EAP peer and authenticator to gain trust in each other. 5.1. Protocol Operation It may be useful to point out that specifications have traditionally treated the AAA server and EAP server as separate entities. However, there is no specification for any protocol which allows those two servers to communicate. i.e. there is no equivalent to EAPoL for servers. Much of the rest of the text in this section is a round-about way of saying that we assume the AAA server and EAP server can communicate, via some mechanism not specified here 5.2. Channel Binding Consistency Check It may be useful to add the note from Section 4.3, where the EAP server verifies the information against it's local database. This prevents the EAP peer and authenticator from colluding to cheat the EAP server. 5.3. EAP Protocol For clarity, it would be good to add some blank lines around the definitions of NSID, Length, and NS-Specific. The use of NS-Specific should be made consistent between the text and the diagrams. The diagram also has two instances of the "NSSID, Length, NS-Specific" data, but only one instance of Code. Is it meant to show that multiple instances of channel binding data can appear in the packet? I presume so... I recommend changing the assigned code point for RADIUS from 0 to 1. The value of "0" is often used in code for uninitialized data. It may be useful to distinguish that data from the intention to send RADIUS. It says: Length: Two octets of length in network byte order, not including the length or the namespace ID. I suggest replacing this with: Length: two octets of length in network byte order, indicating the number of octets of data in the NS-Specific field. The octets for NSSID and Length are not included in this count. It says: A given NSID MUST NOT appear more than once in a channel binding data or channel binding response. I suggest adding a following sentence: Instead, all NS-Specific data for a particular NSSID MUST occur within the context of one (NSSID, Length, NS-Specific) field. It says: In channel binding data, the code is set to 0 (channel binding data) As above, I suggest leaving the value "0" as unused, and starting assignments from "1". If we want to get cute, we can re-use the values from EAP: 2 data from client 3 success 4 fail From aland@deployingradius.com Wed Sep 28 13:11:23 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 6C68621F8D5B for ; Wed, 28 Sep 2011 13:11: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzbijd3+f7SN for ; Wed, 28 Sep 2011 13:11:23 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id D0B3B21F8D57 for ; Wed, 28 Sep 2011 13:11:22 -0700 (PDT) Message-ID: <4E838011.9040204@deployingradius.com> Date: Wed, 28 Sep 2011 22:14:09 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Joe Salowey References: <81E742DC-02A9-4FB2-B3CD-D35282DBCE58@cisco.com> In-Reply-To: <81E742DC-02A9-4FB2-B3CD-D35282DBCE58@cisco.com> 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] Working Group Last Call for draft-ietf-emu-chbind-09 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, 28 Sep 2011 20:11:23 -0000 Continuing from the previous message... It says: In channel binding data, the code is set to 0 (channel binding data) As above, I suggest leaving the value "0" as unused, and starting assignments from "1". If we want to get cute, we can re-use the values from EAP: 5.3.1. Channel Binding Codes 2 data from client 3 success 4 failure 5.3.2. Namespace Identifiers Again, I suggest using "1" for RADIUS. A related question is should we allocate a code for Diameter? :) 5.3.3. Radius Namespace I suggest leaving out all re-definition of RADIUS AVPs. Instead, refer to RFC 2865 Section 5. Say that the NS-Specific data is RADIUS attributes, in the RADIUS attribute format. But the RADIUS packet header (code, length, authenticator) is not included. It also says: RADIUS AVPs are encoded with a one-octet attribute type followed by a one-octet length followed by the value of the RADIUS attribute being encoded. The length includes the type and length octets; the minimum legal length is 2 for an attribute with no value. This last bit is not true. RFC 2865 forbids attributes with "Length" of two. Instead, the entire attribute is suppressed, and never placed into a packet. The same should apply here. It says: Some RADIUS container specifications forbid sending attributes with no value. No, the base RADIUS protocol forbids sending attributes with no value. It is not clear what they mean, or how it is better to send them than to send nothing at all. This prohibition not withstanding, these attributes SHOULD be sent with no value in channel binding responses. I am not clear why the document makes that suggestion. If it's a SHOULD, there should be explanation as to why it's a good idea. Alan DeKok. From hartmans@mit.edu Wed Sep 28 14:49:54 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 4B16B21F8D9D for ; Wed, 28 Sep 2011 14:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.341 X-Spam-Level: X-Spam-Status: No, score=-103.341 tagged_above=-999 required=5 tests=[AWL=-1.076, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hI2xmJeIePQb for ; Wed, 28 Sep 2011 14:49:53 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C5BB621F8DD0 for ; Wed, 28 Sep 2011 14:49:53 -0700 (PDT) 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 EB97A20289; Wed, 28 Sep 2011 17:54:17 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9E3554234; Wed, 28 Sep 2011 17:52:39 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <81E742DC-02A9-4FB2-B3CD-D35282DBCE58@cisco.com> <4E838011.9040204@deployingradius.com> Date: Wed, 28 Sep 2011 17:52:39 -0400 In-Reply-To: <4E838011.9040204@deployingradius.com> (Alan DeKok's message of "Wed, 28 Sep 2011 22:14:09 +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] Working Group Last Call for draft-ietf-emu-chbind-09 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, 28 Sep 2011 21:49:54 -0000 I'm happy to make changes regarding your comments; a couple of them were not directly actionable but I can make best guesses. Most of them were directly actionable and I agree the changes improve the text. I'd appreciate comments from the groups on whether we start codes at 2 or 1. My default will be 1 unless a couple of other people come forward and ask for 2. I do disagree with a couple of comments however; see below. >>>>> "Alan" == Alan DeKok writes: Alan> Continuing from the previous message... It says: Alan> A related question is should we allocate a code for Alan> Diameter? :) Exactly when someone plans to use it and works through the details. I would object to that allocation now. Alan> 5.3.3. Radius Namespace Alan> I suggest leaving out all re-definition of RADIUS AVPs. Alan> Instead, refer to RFC 2865 Section 5. Say that the Alan> NS-Specific data is RADIUS attributes, in the RADIUS attribute Alan> format. But the RADIUS packet header (code, length, Alan> authenticator) is not included. I'd prefer to keep the definition in. Alan> It also says: Alan> RADIUS AVPs are encoded with a one-octet attribute type Alan> followed by a one-octet length followed by the value of the Alan> RADIUS attribute being encoded. The length includes the type Alan> and length octets; the minimum legal length is 2 for an Alan> attribute with no value. Alan> This last bit is not true. RFC 2865 forbids attributes with Alan> "Length" of two. Instead, the entire attribute is suppressed, Alan> and never placed into a packet. Alan> The same should apply here. Unfortunately, as discussed in the text, we need to be able to send empty attributes in channel binding response. I understand RADIUS has no meaning for empty attributes, but I think we have a justified meaning for expressing that. I think the text is correct as is. Alan> It says: Alan> Some RADIUS container specifications forbid sending Alan> attributes with no value. Alan> No, the base RADIUS protocol forbids sending attributes with Alan> no value. It is not clear what they mean, or how it is better Alan> to send them than to send nothing at all. Alan> This prohibition not withstanding, these attributes SHOULD Alan> be sent with no value in channel binding responses. Alan> I am not clear why the document makes that suggestion. If Alan> it's a SHOULD, there should be explanation as to why it's a Alan> good idea. It's a SHOULD because we may specify cases where you include value or where you don't fully understand the container format. The definition of channel binding responses indicates that by default you SHOULD send the attribute without a value and explains why. (You don't want to echo back all that data.)