From aland@deployingradius.com Thu Jun 11 08:24:07 2009 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 706343A6D11 for ; Thu, 11 Jun 2009 08:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICgWkrIH4qzG for ; Thu, 11 Jun 2009 08:24:06 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 5C56828C13B for ; Thu, 11 Jun 2009 08:23:55 -0700 (PDT) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 57D261234097; Thu, 11 Jun 2009 17:24:01 +0200 (CEST) Message-ID: <4A312190.4040406@deployingradius.com> Date: Thu, 11 Jun 2009 17:24:00 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Glen Zorn References: <000901c9c622$3e70d720$bb528560$@net> In-Reply-To: <000901c9c622$3e70d720$bb528560$@net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] comments on draft-ietf-emu-eaptunnel-req-02.txt, part 1 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, 11 Jun 2009 15:24:07 -0000 Glen Zorn wrote: I would suggest that the authors submit an updated version of the document, addressing Glen's concerns. Most seem to be straightforward to resolve. > Section 3.1, first paragraph, last two sentences say: > > The tunnel method MUST support this use case. > However, it MUST NOT expose the username and password to untrusted > parties and it MUST provide protection against man-in-the-middle and > dictionary attacks. The combination of the tunnel authentication and > password authentication MUST enable mutual authentication. > > By whom (or what) are the "untrusted patties" referred to not trusted? For > example, the AAA proxies in a visited network are certainly trusted _by that > network_ (and by inference, the home network) but they may not be trusted > (at least as much) as similar entities in the home network _by the user_. > Some clarification of the trust model seems to be necessary here, especially > given the specification of absolute requirements in the text. I would say entities trusted to know the username and password can have access to them. This is normally the end user, the server validating the username/password, and no one else. > This might also be a good place to mention that certain data related to > authorization may need to be communicated to the peer; it is forbidden to do > this in an EAP Success message, but there is no such constraint (yet) upon > the TLS tunnel. It may be useful to do this in a TLS tunnel. I would suggest that doing this is permissible, and not forbidden. > Section 3.8, first sentence of first paragraph says: > > The tunnel method MUST provide extensibility so that additional types > of data can be carried inside the tunnel in the future. > > This statement seems awfully broad to me. Do we really mean _any_ > "additional types of data" or is it "additional types of security-related > data" or maybe "additional types of data related to network access"? I would suggest authentication and authorization data can be carried in the tunnel. Other types of data SHOULD NOT be carried in the tunnel. > While it is undoubtedly tempting to simply require compliance with RFC 5247, > given the rather incredible amount of drivel and nonsense present in that > RFC, it might be a better idea to be specific about precisely what > requirements need to be satisfied. This seems slightly more contentious to me. If the authors can submit a document *without* addressing this issue, we can focus discussion to obtain WG consensus on how best to resolve this issue. I would prefer not to re-visit RFC 5247. If there are things which are *wrong* in that document, we could update the tunnel requirements document to say "no need to follow section X.Y of 5247". Otherwise, the presumption should be that 5247 applies. > Same section, last paragraph: same comment as the last, but in spades. Just > one example that leaps out: Section 4.1.1, 4th paragraph of the draft in > question says "The tunnel method MUST NOT be tied to any single > cryptographic algorithm." and the last paragraph says "The tunnel method > MUST meet requirements pertinent to EAP method contained in Section 3 of RFC > 4962 [RFC4962]. This includes: cryptographic algorithm independence..." but > the subsection on algorithm independence in Section 3 of RFC 4962 says > "...an EAP method MAY depend on a specific cryptographic algorithm." While > this specific contradiction might be addressed by adding a sentence stating > that conflicts are resolved in favor of this draft other, more subtle > problems might not. This issue requires more WG discussion. I think that clarification is necessary. Given current state of affairs, having a tunneled method that is not tied to a specific cryptographic algorithm seems beneficial to me. The concern with this is that cryptographic negotiation is hard. Alan DeKok. From jsalowey@cisco.com Thu Jun 18 10:11:49 2009 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 20F7F3A680E for ; Thu, 18 Jun 2009 10:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5i6U8TOZP-k7 for ; Thu, 18 Jun 2009 10:11:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 56D293A68F3 for ; Thu, 18 Jun 2009 10:11:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,245,1243814400"; d="scan'208";a="326724588" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 18 Jun 2009 17:11:39 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5IHBdLY024624 for ; Thu, 18 Jun 2009 10:11:39 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5IHBdTj026508 for ; Thu, 18 Jun 2009 17:11:39 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 10:11:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jun 2009 10:11:38 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-emu-chbind-02 and AAA interaction Thread-Index: AcnwN9eTYg1WhivtSq6DP/qqLOnBwA== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 18 Jun 2009 17:11:39.0488 (UTC) FILETIME=[D8058E00:01C9F037] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2160; t=1245345099; x=1246209099; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20draft-ietf-emu-chbind-02=20and=20AAA=20interact ion |Sender:=20; bh=519LOEU8m7JK30bPddtTkMDrLge/arGMhZPZecjMR64=; b=oYWhiaInJBFDwiUzYdFO7CXzgZVkwsUx1EXKEDIZZW2U6LdA3/0e3E1Ypg xs9WwV5eIMkyx//cGAiB7AiYSBafHyIjQj84tC/WMBx/abHc0fbTv0C5J+Fv iHssyhqkLk; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Emu] draft-ietf-emu-chbind-02 and AAA interaction 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, 18 Jun 2009 17:11:49 -0000 After reviewing recent comments from Klaas on the list on Channel bindings there is one issue I would like to try to resolve before bringing this draft to last call. =20 In section 5.1, the draft defines a message i2, which is the message carrying AAA attributes from the authenticator to the server using a AAA protocol. While, this message does occur in the protocol interactions, it is actually not that important in the channel binding interactions because the server does not completely trust the authenticator and must know what is valid through some other mechanism, such as the local database defined in the draft. I think this section is a bit misleading and needs to emphasize this point. This is further confused by the fact that in some sections the draft focuses entirely on AAA attributes to carry channel-binding information. While AAA attributes are undoubtedly important to carry it does not appear that they should be the only type of data allowed especially since the AAA protocol is not required to be directly involved other than to carry EAP. This is demonstrated by the "TODO" 7.3 which suggests we need to add a way to carry the 802.11 RSN-IE. Since AAA protocols haven't needed to carry this information to date, it is not clear that adding this information to them would be helpful. Given this I would suggest the following modifications to the draft: 1. In sections 5.1 and 5.2 clarify the role of message i2 with respect to channel bindings. 2. In section 6.1 define channel binding data as a superset of AAA attributes. In particular the last paragraph needs work and seems inconsistent with 7.1 which allows for the inclusion of Diameter attributes without the exclusion of other attributes.=20 3. Sections 7.1, 7.2, 7.3 only recommend comparing information with what is received from the NAS and not about comparing with local information 4. Section 8 is about AAA validation and is not channel bindings, is this section necessary? =20 If the working group agrees with this direction I can provide text for the changes. =20 Please send comments to the list. Thanks, Joe=20 From khoeper@motorola.com Fri Jun 19 17:39:36 2009 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 A6D2E3A687C for ; Fri, 19 Jun 2009 17:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kInHAxvsF+h for ; Fri, 19 Jun 2009 17:39:35 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id 424123A681F for ; Fri, 19 Jun 2009 17:39:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1245458387!12170493!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27401 invoked from network); 20 Jun 2009 00:39:47 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Jun 2009 00:39:47 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n5K0dlnL000085 for ; Fri, 19 Jun 2009 17:39:47 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n5K0dkCV016035 for ; Fri, 19 Jun 2009 19:39:47 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n5K0dkEs016032 for ; Fri, 19 Jun 2009 19:39:46 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jun 2009 20:39:25 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F062634BD@de01exm68.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] draft-ietf-emu-chbind-02 and AAA interaction thread-index: AcnwN9eTYg1WhivtSq6DP/qqLOnBwAA/CzSw References: From: "Hoeper Katrin-QWKN37" To: "Joseph Salowey (jsalowey)" , X-CFilter-Loop: Reflected Subject: Re: [Emu] draft-ietf-emu-chbind-02 and AAA interaction 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: Sat, 20 Jun 2009 00:39:36 -0000 Joe, Thank you for bringing this up. Find my replies below: "1. In sections 5.1 and 5.2 clarify the role of message i2 with respect to channel bindings." [KH] I agree with your observations that the use and exchange of i2 is not well described in the draft and needs to be clarified.=20 The EAP server can utilize three pieces of information for its channel binding verification, namely: i1 received from the EAP peer, i2 received as part of AAA communications with the authenticator and i3 stored in a local database. The confusion lies in the description of i2 and its "exchange". i2 is basically information that the EAP server already "knows" about the authenticator. The information is *not* sent as payload to the EAP server, it was rather part of previous communications with the authenticator during the current EAP session. For example, the EAP server typically "knows" the NAS-IP address of the authenticator in an EAP execution. Basically, we want to utilize information for the channel binding consistency check that the EAP server already knows about the authenticator. This information is referred to as i2. I agree that the arrow with i2 from authenticator to EAP server in Figure 1 is wrong, because i2 is not a protocol message. Figure 1 does not reflect the above description and needs to be revised accordingly. On the other hand, an EAP server can optionally include i2 in its reply to the EAP peer, e.g. to enable the peer to perform its own consistency checks. In that case, i2 needs to be explicitly exchanged. "2. In section 6.1 define channel binding data as a superset of AAA attributes. In particular the last paragraph needs work and seems inconsistent with 7.1 which allows for the inclusion of Diameter attributes without the exclusion of other attributes." [KH] The reason why we chose i2 as AAA data is because the authenticator and EAP server communicate using an AAA protocol during an EAP execution. Hence, the EAP server has access to AAA attributes of the authenticator in its role as AAA client. In this way no additional exchange of information is required (again, the flow in Figure 1 is wrong) and i2 does not need to be explicitly exchanged. This is important because we want to be able to add channel binding to EAP methods without modifying the method's protocol flow. If we would allow i2 to be any type of data about the authenticator, this would require an explicit message flow from authenticator to EAP server as part of the EAP method.=20 To avoid the introduction of additional communication flows, the modification of EAP methods and potentially the involvement of other protocols, I argue that i2 should only contain AAA information about the authenticator. Any other type of information about the authenticator that seems desirable for the channel binding verification can be stored in the local database (i3).=20 " Sections 7.1, 7.2, 7.3 only recommend comparing information with what is received from the NAS and not about comparing with local information" [KH] Section 7 describes which attributes can be used in i1 for the channel binding compliance check, and Section 8 the attributes that can be used as part of i2. Comparing local information is only described as text in Section 10.1. We cannot provide concrete attributes here because i3 is protocol-independent and basically contains data derived from policies. I don't think we can provide concrete examples here, but it might be a good idea to add another section after 7 and 8, to generally outline how the comparison with the local information should be executed. In that case, Section 10 could remain the same, explaining how such a database can be set up. "4. Section 8 is about AAA validation and is not channel bindings, is this section necessary?" [KH] Disagree, see my comments to your suggestions #2. =20 Joe, I hope I could clarify some of your issues. I would also like to hear other opinions from the list on these issues. Katrin -----Original Message----- From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Joseph Salowey (jsalowey) Sent: Thursday, June 18, 2009 12:12 PM To: emu@ietf.org Subject: [Emu] draft-ietf-emu-chbind-02 and AAA interaction After reviewing recent comments from Klaas on the list on Channel bindings there is one issue I would like to try to resolve before bringing this draft to last call. =20 In section 5.1, the draft defines a message i2, which is the message carrying AAA attributes from the authenticator to the server using a AAA protocol. While, this message does occur in the protocol interactions, it is actually not that important in the channel binding interactions because the server does not completely trust the authenticator and must know what is valid through some other mechanism, such as the local database defined in the draft. I think this section is a bit misleading and needs to emphasize this point. This is further confused by the fact that in some sections the draft focuses entirely on AAA attributes to carry channel-binding information. While AAA attributes are undoubtedly important to carry it does not appear that they should be the only type of data allowed especially since the AAA protocol is not required to be directly involved other than to carry EAP. This is demonstrated by the "TODO" 7.3 which suggests we need to add a way to carry the 802.11 RSN-IE. Since AAA protocols haven't needed to carry this information to date, it is not clear that adding this information to them would be helpful. Given this I would suggest the following modifications to the draft: 1. In sections 5.1 and 5.2 clarify the role of message i2 with respect to channel bindings. 2. In section 6.1 define channel binding data as a superset of AAA attributes. In particular the last paragraph needs work and seems inconsistent with 7.1 which allows for the inclusion of Diameter attributes without the exclusion of other attributes.=20 3. Sections 7.1, 7.2, 7.3 only recommend comparing information with what is received from the NAS and not about comparing with local information 4. Section 8 is about AAA validation and is not channel bindings, is this section necessary? =20 If the working group agrees with this direction I can provide text for the changes. =20 Please send comments to the list. Thanks, Joe=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From jsalowey@cisco.com Mon Jun 22 12:32:41 2009 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 99B203A6C66 for ; Mon, 22 Jun 2009 12:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN-C8Y9pAVYz for ; Mon, 22 Jun 2009 12:32:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 942D23A69C0 for ; Mon, 22 Jun 2009 12:32:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,270,1243814400"; d="scan'208";a="172008563" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2009 19:32:55 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5MJWtv3002433; Mon, 22 Jun 2009 12:32:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n5MJWtnL024816; Mon, 22 Jun 2009 19:32:55 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Jun 2009 12:32:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Jun 2009 12:32:54 -0700 Message-ID: In-Reply-To: <3A241A6B234BE948B8B474D261FEBC2F062634BD@de01exm68.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] draft-ietf-emu-chbind-02 and AAA interaction Thread-Index: AcnwN9eTYg1WhivtSq6DP/qqLOnBwAA/CzSwAItpRmA= References: <3A241A6B234BE948B8B474D261FEBC2F062634BD@de01exm68.ds.mot.com> From: "Joseph Salowey (jsalowey)" To: "Hoeper Katrin-QWKN37" , X-OriginalArrivalTime: 22 Jun 2009 19:32:55.0113 (UTC) FILETIME=[3D8A4B90:01C9F370] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9156; t=1245699175; x=1246563175; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20draft-ietf-emu-chbind-02=20and= 20AAA=20interaction |Sender:=20; bh=pEurol+zwuA5QVEn2ebDX0H8HozeDxxSwTfzohnUU8I=; b=mifXlhR7qLdtgEla7NkFhFsf6srEGQpanxyTWKnjit4OONWofi0KOj/9R8 LzJTJsvrKj4V2oNeTX7DdIT8N7QRcS1cj2TnRDI6tVw7ZU5N4jaAOHO0K2Yb 5eEYHIxCWUpEwYE4anOnRzDZaYCl2lDybdHbq2OtpwEAQ8gj411+Q=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Emu] draft-ietf-emu-chbind-02 and AAA interaction 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, 22 Jun 2009 19:32:41 -0000 =20 > -----Original Message----- > From: Hoeper Katrin-QWKN37 [mailto:khoeper@motorola.com]=20 > Sent: Friday, June 19, 2009 5:39 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] draft-ietf-emu-chbind-02 and AAA interaction >=20 > Joe, >=20 > Thank you for bringing this up. Find my replies below: >=20 > "1. In sections 5.1 and 5.2 clarify the role of message i2=20 > with respect to channel bindings." >=20 > [KH] I agree with your observations that the use and exchange=20 > of i2 is not well described in the draft and needs to be clarified.=20 >=20 > The EAP server can utilize three pieces of information for=20 > its channel binding verification, namely: i1 received from=20 > the EAP peer, i2 received as part of AAA communications with=20 > the authenticator and i3 stored in a local database. The=20 > confusion lies in the description of i2 and its "exchange". >=20 > i2 is basically information that the EAP server already=20 > "knows" about the authenticator. The information is *not*=20 > sent as payload to the EAP server, it was rather part of=20 > previous communications with the authenticator during the=20 > current EAP session. For example, the EAP server typically=20 > "knows" the NAS-IP address of the authenticator in an EAP=20 > execution. Basically, we want to utilize information for the=20 > channel binding consistency check that the EAP server already=20 > knows about the authenticator. This information is referred to as i2. >=20 > I agree that the arrow with i2 from authenticator to EAP=20 > server in Figure 1 is wrong, because i2 is not a protocol=20 > message. Figure 1 does not reflect the above description and=20 > needs to be revised accordingly. > On the other hand, an EAP server can optionally include i2 in=20 > its reply to the EAP peer, e.g. to enable the peer to perform=20 > its own consistency checks. In that case, i2 needs to be=20 > explicitly exchanged. >=20 [Joe] OK, I think I may understand better. If I understand correctly, there are two separate consistency checks: 1. one checking the consistency of what the client sees against a database of what should be seen. (i1) 2. one checking the consistency of what the authenticator against a database of what should be seen. (i2)=20 Is this correct? =20 It seems that in your picture i2 is really between the authenticator and AAA. This affects some of your statements above. For example its not clear to me that the EAP Server would necessarily know anything about NAS-IP. =20 > "2. In section 6.1 define channel binding data as a superset=20 > of AAA attributes. In particular the last paragraph needs=20 > work and seems inconsistent with 7.1 which allows for the=20 > inclusion of Diameter attributes without the exclusion of=20 > other attributes." >=20 > [KH] The reason why we chose i2 as AAA data is because the=20 > authenticator and EAP server communicate using an AAA=20 > protocol during an EAP execution. Hence, the EAP server has=20 > access to AAA attributes of the authenticator in its role as=20 > AAA client.=20 [Joe] So I think it makes sense that i2 is AAA data, what I'm not seeing is what the EAP server is dealing with it instead of the AAA server.=20 > In this way no additional exchange of information=20 > is required (again, the flow in Figure 1 is > wrong) and i2 does not need to be explicitly exchanged. This=20 > is important because we want to be able to add channel=20 > binding to EAP methods without modifying the method's=20 > protocol flow. If we would allow > i2 to be any type of data about the authenticator, this would=20 > require an explicit message flow from authenticator to EAP=20 > server as part of the EAP method.=20 > > To avoid the introduction of additional communication flows,=20 > the modification of EAP methods and potentially the=20 > involvement of other protocols, I argue that i2 should only=20 > contain AAA information about the authenticator. Any other=20 > type of information about the authenticator that seems=20 > desirable for the channel binding verification can be stored=20 > in the local database (i3).=20 >=20 [Joe] I'm fine with i2 containing AAA information, but I don't really see how it is part of EAP channel bindings. This seems to be more about validating information in the AAA protocol. =20 For channel bindings I am more concerned with what is communicated in i1. This is what EAP methods need to carry. i1 may need to carry some data that may also be in a AAA attribute, but it may also need to carry other data. My objection is restricting everything in i1 to being AAA data. The current draft seems to requirements for i1 and i2 all together. I don't think this is correct. =20 >=20 > " Sections 7.1, 7.2, 7.3 only recommend comparing information=20 > with what is received from the NAS and not about comparing=20 > with local information" >=20 > [KH] Section 7 describes which attributes can be used in i1=20 > for the channel binding compliance check, and Section 8 the=20 > attributes that can be used as part of i2. Comparing local=20 > information is only described as text in Section 10.1. We=20 > cannot provide concrete attributes here because > i3 is protocol-independent and basically contains data=20 > derived from policies. I don't think we can provide concrete=20 > examples here, but it might be a good idea to add another=20 > section after 7 and 8, to generally outline how the=20 > comparison with the local information should be executed. In=20 > that case, Section 10 could remain the same, explaining how=20 > such a database can be set up. >=20 > "4. Section 8 is about AAA validation and is not channel=20 > bindings, is this section necessary?" >=20 > [KH] Disagree, see my comments to your suggestions #2. =20 >=20 [Joe] So, I see i1 as the messages used in EAP channel bindings. i2 looks to me like validation that should be done by the AAA protocol. I think I may not have understood your points above. I think the draft needs to focus more on the requirements of i1 exchange and less on the requirements of the i2 exchange. =20 >=20 > Joe, I hope I could clarify some of your issues. I would also=20 > like to hear other opinions from the list on these issues. >=20 > Katrin >=20 >=20 >=20 > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Joseph Salowey (jsalowey) > Sent: Thursday, June 18, 2009 12:12 PM > To: emu@ietf.org > Subject: [Emu] draft-ietf-emu-chbind-02 and AAA interaction >=20 > After reviewing recent comments from Klaas on the list on=20 > Channel bindings there is one issue I would like to try to=20 > resolve before bringing this draft to last call. =20 >=20 > In section 5.1, the draft defines a message i2, which is the=20 > message carrying AAA attributes from the authenticator to the=20 > server using a AAA protocol. While, this message does occur=20 > in the protocol interactions, it is actually not that=20 > important in the channel binding interactions because the=20 > server does not completely trust the authenticator and must=20 > know what is valid through some other mechanism, such as the=20 > local database defined in the draft. I think this section is=20 > a bit misleading and needs to emphasize this point. This is=20 > further confused by the fact that in some sections the draft=20 > focuses entirely on AAA attributes to carry channel-binding=20 > information. While AAA attributes are undoubtedly important=20 > to carry it does not appear that they should be the only type=20 > of data allowed especially since the AAA protocol is not=20 > required to be directly involved other than to carry EAP. =20 > This is demonstrated by the "TODO" 7.3 which suggests we need=20 > to add a way to carry the 802.11 RSN-IE. Since AAA protocols=20 > haven't needed to carry this information to date, it is not=20 > clear that adding this information to them would be helpful. =20 > Given this I would suggest the following modifications to the > draft: >=20 > 1. In sections 5.1 and 5.2 clarify the role of message i2=20 > with respect to channel bindings. > 2. In section 6.1 define channel binding data as a superset=20 > of AAA attributes. In particular the last paragraph needs=20 > work and seems inconsistent with 7.1 which allows for the=20 > inclusion of Diameter attributes without the exclusion of=20 > other attributes.=20 > 3. Sections 7.1, 7.2, 7.3 only recommend comparing=20 > information with what is received from the NAS and not about=20 > comparing with local information 4. Section 8 is about AAA=20 > validation and is not channel bindings, is this section necessary? =20 >=20 > If the working group agrees with this direction I can provide=20 > text for the changes. =20 >=20 > Please send comments to the list. >=20 > Thanks, >=20 > Joe > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >=20 From yaronf@checkpoint.com Tue Jun 23 00:53:24 2009 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 C2F363A6BB0 for ; Tue, 23 Jun 2009 00:53:24 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR506Nh8kR+N for ; Tue, 23 Jun 2009 00:53:23 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EAE4D3A6929 for ; Tue, 23 Jun 2009 00:53:22 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4EB8B29C007; Tue, 23 Jun 2009 10:53:46 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 19EF729C002 for ; Tue, 23 Jun 2009 10:53:46 +0300 (IDT) X-CheckPoint: {4A408773-2-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n5N7ra3d005858 for ; Tue, 23 Jun 2009 10:53:37 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 23 Jun 2009 10:53:36 +0300 From: Yaron Sheffer To: "emu@ietf.org" Date: Tue, 23 Jun 2009 10:53:35 +0300 Thread-Topic: EAP-EKE implementations Thread-Index: Acntoimsvn4Ban1jSwq1AFtgR8u5IwAA0xmAAYw3PgA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABC0DC53@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0095_01C9F3F0.DB7183C0" MIME-Version: 1.0 Subject: [Emu] EAP-EKE implementations 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, 23 Jun 2009 07:53:24 -0000 ------=_NextPart_000_0095_01C9F3F0.DB7183C0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, A few days ago I was at Tel Aviv University to see a demonstration of EAP-EKE, implemented between a WPA client (wpa_supplicant), a generic = access point and a FreeRADIUS server. All working very smoothly. The students managed to write the whole thing based on the draft (http://tools.ietf.org/html/draft-sheffer-emu-eap-eke), with very little interaction with the authors. There is a second team who is implementing EAP-EKE independently, on top = of StrongSwan (IKEv2). When they are done, we will be testing = interoperability between the two implementations. The seminar=92s page is here: = http://www.cs.tau.ac.il/~canetti/sp09-sadna.html Thanks, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yaron =20 ------=_NextPart_000_0095_01C9F3F0.DB7183C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDYyMzA3NTMzNVowIwYJKoZIhvcNAQkEMRYEFKoxgwqTsVbL K2Wi6Tv9c/9/U63aMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA ZeMYv+88kpemU2glPbuy0+qAKV+7jZggEkoVvy1MYb7jI9YL/1Zvb2O8YKUsVP1F0u6EqD+86v06 DOQEGganJBrlKGQ1yc80Gff0ekQE+1sgU7EqPWJqli5KGLdrBtNea2TYg+Jb9uWCeZU5yq1u5NLd a2LpiCkEfEQPC142jgNpQHeyAK9z9czHK/fIlqNkP/vKoMFbVeyt0mlZVW8Z4Dto7rn4LIiT6XuN 9yjT+sagl+nSG7yck7oj3woFut+ZHo3YlTqDdp32rTDEWw4k+eD+PaNLQdx2lLbkQF30OJSIWYPv nYVjOtYVgsf/qF+F5ZsXmgxpwCL3tHImpkVY4wAAAAAAAA== ------=_NextPart_000_0095_01C9F3F0.DB7183C0-- From khoeper@motorola.com Tue Jun 23 15:11:35 2009 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 5027628C2CB for ; Tue, 23 Jun 2009 15:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.561 X-Spam-Level: X-Spam-Status: No, score=-5.561 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAD7iXeKhzOQ for ; Tue, 23 Jun 2009 15:11:33 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 357B43A6D42 for ; Tue, 23 Jun 2009 15:11:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1245795107!35703707!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 5063 invoked from network); 23 Jun 2009 22:11:48 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-8.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Jun 2009 22:11:48 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n5NMBlAF028203 for ; Tue, 23 Jun 2009 15:11:47 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n5NMBlt7025072 for ; Tue, 23 Jun 2009 17:11:47 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n5NMBlVF025065 for ; Tue, 23 Jun 2009 17:11:47 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jun 2009 18:11:25 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F0626405F@de01exm68.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] draft-ietf-emu-chbind-02 and AAA interaction thread-index: AcnwN9eTYg1WhivtSq6DP/qqLOnBwAA/CzSwAItpRmAAOoMQ0A== References: <3A241A6B234BE948B8B474D261FEBC2F062634BD@de01exm68.ds.mot.com> From: "Hoeper Katrin-QWKN37" To: "Joseph Salowey (jsalowey)" , X-CFilter-Loop: Reflected Subject: Re: [Emu] draft-ietf-emu-chbind-02 and AAA interaction 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, 23 Jun 2009 22:11:35 -0000 Comments inline. > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Monday, June 22, 2009 2:33 PM > To: Hoeper Katrin-QWKN37; emu@ietf.org > Subject: RE: [Emu] draft-ietf-emu-chbind-02 and AAA interaction >=20 >=20 >=20 > > -----Original Message----- > > From: Hoeper Katrin-QWKN37 [mailto:khoeper@motorola.com] > > Sent: Friday, June 19, 2009 5:39 PM > > To: Joseph Salowey (jsalowey); emu@ietf.org > > Subject: RE: [Emu] draft-ietf-emu-chbind-02 and AAA interaction > > > > Joe, > > > > Thank you for bringing this up. Find my replies below: > > > > "1. In sections 5.1 and 5.2 clarify the role of message i2 > > with respect to channel bindings." > > > > [KH] I agree with your observations that the use and exchange > > of i2 is not well described in the draft and needs to be clarified. > > > > The EAP server can utilize three pieces of information for > > its channel binding verification, namely: i1 received from > > the EAP peer, i2 received as part of AAA communications with > > the authenticator and i3 stored in a local database. The > > confusion lies in the description of i2 and its "exchange". > > > > i2 is basically information that the EAP server already > > "knows" about the authenticator. The information is *not* > > sent as payload to the EAP server, it was rather part of > > previous communications with the authenticator during the > > current EAP session. For example, the EAP server typically > > "knows" the NAS-IP address of the authenticator in an EAP > > execution. Basically, we want to utilize information for the > > channel binding consistency check that the EAP server already > > knows about the authenticator. This information is referred to as i2. > > > > I agree that the arrow with i2 from authenticator to EAP > > server in Figure 1 is wrong, because i2 is not a protocol > > message. Figure 1 does not reflect the above description and > > needs to be revised accordingly. > > On the other hand, an EAP server can optionally include i2 in > > its reply to the EAP peer, e.g. to enable the peer to perform > > its own consistency checks. In that case, i2 needs to be > > explicitly exchanged. > > > [Joe] OK, I think I may understand better. If I understand correctly, > there are two separate consistency checks: >=20 > 1. one checking the consistency of what the client sees against a > database of what should be seen. (i1) > 2. one checking the consistency of what the authenticator against a > database of what should be seen. (i2) >=20 > Is this correct? >=20 [KH] Almost. Check 1 "is the authenticator lying to the peer?": consistency check of i1 and i2 with the aid of the database (because a direct comparison is not possible), i.e. checking whether the info submitted to the peer and known to by the EAP server are consistent. Check 2 "is the authenticator lying to both ends to violate rules": check whether i1 and i2 comply with policies stored in the database. Actually check 2 could be split into two checks: 2a) check whether authenticator lies to the EAP server and 2b) does the authenticator violate any rules. > It seems that in your picture i2 is really between the authenticator and > AAA. This affects some of your statements above. For example its not > clear to me that the EAP Server would necessarily know anything about > NAS-IP. [KH] This is true and needs to be clarified. Either the EAP server can only use the AAA attributes it knows about the authenticator from the on-going EAP execution or the EAP server needs to get this information from the AAA server to perform the consistency check. Do you see any use case for the former? >=20 > > "2. In section 6.1 define channel binding data as a superset > > of AAA attributes. In particular the last paragraph needs > > work and seems inconsistent with 7.1 which allows for the > > inclusion of Diameter attributes without the exclusion of > > other attributes." > > > > [KH] The reason why we chose i2 as AAA data is because the > > authenticator and EAP server communicate using an AAA > > protocol during an EAP execution. Hence, the EAP server has > > access to AAA attributes of the authenticator in its role as > > AAA client. >=20 > [Joe] So I think it makes sense that i2 is AAA data, what I'm not seeing > is what the EAP server is dealing with it instead of the AAA server. [KH] Agreed, this needs to be addressed-see previous comment. >=20 > > In this way no additional exchange of information > > is required (again, the flow in Figure 1 is > > wrong) and i2 does not need to be explicitly exchanged. This > > is important because we want to be able to add channel > > binding to EAP methods without modifying the method's > > protocol flow. If we would allow > > i2 to be any type of data about the authenticator, this would > > require an explicit message flow from authenticator to EAP > > server as part of the EAP method. > > > > To avoid the introduction of additional communication flows, > > the modification of EAP methods and potentially the > > involvement of other protocols, I argue that i2 should only > > contain AAA information about the authenticator. Any other > > type of information about the authenticator that seems > > desirable for the channel binding verification can be stored > > in the local database (i3). > > > [Joe] I'm fine with i2 containing AAA information, but I don't really > see how it is part of EAP channel bindings. This seems to be more about > validating information in the AAA protocol. [KH] I believe this is the only way to check whether an authenticator is lying about its identity, i.e. the identifier& addresses broadcasted to peers and identifiers & addresses used in the backend network. Again these identifiers & addresses may be of different types but should nevertheless map to the same device (check via a lookup in the database). >=20 > For channel bindings I am more concerned with what is communicated in > i1. This is what EAP methods need to carry. i1 may need to carry some > data that may also be in a AAA attribute, but it may also need to carry > other data. My objection is restricting everything in i1 to being AAA > data. The current draft seems to requirements for i1 and i2 all > together. I don't think this is correct. >=20 [KH] Agreed. This limitation of i1 was not intended and needs to be addressed. i1 can contain anything that was broadcasted in the authenticator's (NAS) beacon while i2 is restricted to AAA attributes. > > > > " Sections 7.1, 7.2, 7.3 only recommend comparing information > > with what is received from the NAS and not about comparing > > with local information" > > > > [KH] Section 7 describes which attributes can be used in i1 > > for the channel binding compliance check, and Section 8 the > > attributes that can be used as part of i2. Comparing local > > information is only described as text in Section 10.1. We > > cannot provide concrete attributes here because > > i3 is protocol-independent and basically contains data > > derived from policies. I don't think we can provide concrete > > examples here, but it might be a good idea to add another > > section after 7 and 8, to generally outline how the > > comparison with the local information should be executed. In > > that case, Section 10 could remain the same, explaining how > > such a database can be set up. > > > > "4. Section 8 is about AAA validation and is not channel > > bindings, is this section necessary?" > > > > [KH] Disagree, see my comments to your suggestions #2. > > > [Joe] So, I see i1 as the messages used in EAP channel bindings. i2 > looks to me like validation that should be done by the AAA protocol. I > think I may not have understood your points above. I think the draft > needs to focus more on the requirements of i1 exchange and less on the > requirements of the i2 exchange. [KH] In order to detect whether an authenticator is "lying" you need some data to compare i1 too. We believe that lying can be detected by comparing the views the EAP peer and EAP server have about the authenticator in an EAP session. The database is needed to enable the comparison. In addition, we check for the case that the authenticator lies to both ends (i.e. to the EAP peer and the EAP server) by checking the compliance of i1 and i2 with the policies stored in the database. >=20 > > > > Joe, I hope I could clarify some of your issues. I would also > > like to hear other opinions from the list on these issues. > > > > Katrin > > > > > > > > -----Original Message----- > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > > Behalf Of Joseph Salowey (jsalowey) > > Sent: Thursday, June 18, 2009 12:12 PM > > To: emu@ietf.org > > Subject: [Emu] draft-ietf-emu-chbind-02 and AAA interaction > > > > After reviewing recent comments from Klaas on the list on > > Channel bindings there is one issue I would like to try to > > resolve before bringing this draft to last call. > > > > In section 5.1, the draft defines a message i2, which is the > > message carrying AAA attributes from the authenticator to the > > server using a AAA protocol. While, this message does occur > > in the protocol interactions, it is actually not that > > important in the channel binding interactions because the > > server does not completely trust the authenticator and must > > know what is valid through some other mechanism, such as the > > local database defined in the draft. I think this section is > > a bit misleading and needs to emphasize this point. This is > > further confused by the fact that in some sections the draft > > focuses entirely on AAA attributes to carry channel-binding > > information. While AAA attributes are undoubtedly important > > to carry it does not appear that they should be the only type > > of data allowed especially since the AAA protocol is not > > required to be directly involved other than to carry EAP. > > This is demonstrated by the "TODO" 7.3 which suggests we need > > to add a way to carry the 802.11 RSN-IE. Since AAA protocols > > haven't needed to carry this information to date, it is not > > clear that adding this information to them would be helpful. > > Given this I would suggest the following modifications to the > > draft: > > > > 1. In sections 5.1 and 5.2 clarify the role of message i2 > > with respect to channel bindings. > > 2. In section 6.1 define channel binding data as a superset > > of AAA attributes. In particular the last paragraph needs > > work and seems inconsistent with 7.1 which allows for the > > inclusion of Diameter attributes without the exclusion of > > other attributes. > > 3. Sections 7.1, 7.2, 7.3 only recommend comparing > > information with what is received from the NAS and not about > > comparing with local information 4. Section 8 is about AAA > > validation and is not channel bindings, is this section necessary? > > > > If the working group agrees with this direction I can provide > > text for the changes. > > > > Please send comments to the list. > > > > Thanks, > > > > Joe > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > From jsalowey@cisco.com Tue Jun 23 22:16:10 2009 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 EF1E528C41C for ; Tue, 23 Jun 2009 22:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cxv1BzM--rwm for ; Tue, 23 Jun 2009 22:16:09 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id EF3783A6BA3 for ; Tue, 23 Jun 2009 22:16:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,280,1243814400"; d="scan'208";a="179716777" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 24 Jun 2009 05:16:25 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5O5GP9t012411; Tue, 23 Jun 2009 22:16:25 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n5O5GPRS018366; Wed, 24 Jun 2009 05:16:25 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 22:16:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jun 2009 22:16:24 -0700 Message-ID: In-Reply-To: <3A241A6B234BE948B8B474D261FEBC2F0626405F@de01exm68.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] draft-ietf-emu-chbind-02 and AAA interaction Thread-Index: AcnwN9eTYg1WhivtSq6DP/qqLOnBwAA/CzSwAItpRmAAOoMQ0AAOpodg References: <3A241A6B234BE948B8B474D261FEBC2F062634BD@de01exm68.ds.mot.com> <3A241A6B234BE948B8B474D261FEBC2F0626405F@de01exm68.ds.mot.com> From: "Joseph Salowey (jsalowey)" To: "Hoeper Katrin-QWKN37" , X-OriginalArrivalTime: 24 Jun 2009 05:16:25.0469 (UTC) FILETIME=[EBC06AD0:01C9F48A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13859; t=1245820585; x=1246684585; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20draft-ietf-emu-chbind-02=20and= 20AAA=20interaction |Sender:=20; bh=P14NEODSi5EWi3j+bNnIO8TlFOZlexIkJXU2KRYBAeQ=; b=NAf3VEEsrgAmwikfFeLxCmXZZkcf2Djq1PqGl+u64kUlbqVzrBz1fzt8Ym 7ft+e44/+ACBbtvj1Je11UdG8cOTnqh1SfDhImNa4n9aaU9tY/3u97zltk+F l+KXG98YKH; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Emu] draft-ietf-emu-chbind-02 and AAA interaction 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: Wed, 24 Jun 2009 05:16:11 -0000 Hi Katrin, Thanks for the clarifications, I think I understand better now. =20 Comments inline. > > > Joe, > > > > > > Thank you for bringing this up. Find my replies below: > > > > > > "1. In sections 5.1 and 5.2 clarify the role of message i2 with=20 > > > respect to channel bindings." > > > > > > [KH] I agree with your observations that the use and=20 > exchange of i2=20 > > > is not well described in the draft and needs to be clarified. > > > > > > The EAP server can utilize three pieces of information for its=20 > > > channel binding verification, namely: i1 received from=20 > the EAP peer,=20 > > > i2 received as part of AAA communications with the=20 > authenticator and=20 > > > i3 stored in a local database. The confusion lies in the=20 > description=20 > > > of i2 and its "exchange". > > > > > > i2 is basically information that the EAP server already "knows"=20 > > > about the authenticator. The information is *not* sent as=20 > payload to=20 > > > the EAP server, it was rather part of previous=20 > communications with=20 > > > the authenticator during the current EAP session. For=20 > example, the=20 > > > EAP server typically "knows" the NAS-IP address of the=20 > authenticator=20 > > > in an EAP execution. Basically, we want to utilize=20 > information for=20 > > > the channel binding consistency check that the EAP server already=20 > > > knows about the authenticator. This information is referred to as > i2. > > > > > > I agree that the arrow with i2 from authenticator to EAP=20 > server in=20 > > > Figure 1 is wrong, because i2 is not a protocol message. Figure 1=20 > > > does not reflect the above description and needs to be revised=20 > > > accordingly. > > > On the other hand, an EAP server can optionally include i2 in its=20 > > > reply to the EAP peer, e.g. to enable the peer to perform its own=20 > > > consistency checks. In that case, i2 needs to be explicitly=20 > > > exchanged. > > > > > [Joe] OK, I think I may understand better. If I understand=20 > correctly,=20 > > there are two separate consistency checks: > >=20 > > 1. one checking the consistency of what the client sees against a=20 > > database of what should be seen. (i1) 2. one checking the=20 > consistency=20 > > of what the authenticator against a database of what should=20 > be seen.=20 > > (i2) > >=20 > > Is this correct? > >=20 > [KH] Almost. Check 1 "is the authenticator lying to the peer?": > consistency check of i1 and i2 with the aid of the database=20 > (because a direct comparison is not possible), i.e. checking=20 > whether the info submitted to the peer and known to by the=20 > EAP server are consistent. > Check 2 "is the authenticator lying to both ends to violate rules": > check whether i1 and i2 comply with policies stored in the database. > Actually check 2 could be split into two checks: 2a) check=20 > whether authenticator lies to the EAP server and 2b) does the=20 > authenticator violate any rules. >=20 [Joe] Good point, so 2A would be useful in the case where the AAA is making some policy decision based on what the authenticator states and there is more than one choice for the authenticator. Perhaps if the authenticator can advertise a free and charged SSID the client associates with the free one, but the authenticator reports the charged one. This may be a bit contrived, but it seems like it could be a good thing to do. I think it would be useful to split this up into 2A and 2B. 2A is needed when there is an attribute used in AAA policy that the client is aware of and there is more than one choice for the value of the attribute for the authenticator. 2B I think is something more for AAA validation of the message. =20 > > It seems that in your picture i2 is really between the authenticator > and > > AAA. This affects some of your statements above. For=20 > example its not=20 > > clear to me that the EAP Server would necessarily know=20 > anything about=20 > > NAS-IP. > [KH] This is true and needs to be clarified. Either the EAP=20 > server can only use the AAA attributes it knows about the=20 > authenticator from the on-going EAP execution or the EAP=20 > server needs to get this information from the AAA server to=20 > perform the consistency check. Do you see any use case for the former? [Joe] So, I think some of the data, mostly 2B data, should be validated by the AAA server. Some of the type 1 data may not be passed in the AAA protocol. For 1 and 2A data that is communicated in AAA I think it will depend upon implementation as to who maintains the authoritative database for attributes. In some cases validation responsibility may be split. =20 > >=20 > > > "2. In section 6.1 define channel binding data as a=20 > superset of AAA=20 > > > attributes. In particular the last paragraph needs work=20 > and seems=20 > > > inconsistent with 7.1 which allows for the inclusion of Diameter=20 > > > attributes without the exclusion of other attributes." > > > > > > [KH] The reason why we chose i2 as AAA data is because the=20 > > > authenticator and EAP server communicate using an AAA protocol=20 > > > during an EAP execution. Hence, the EAP server has access to AAA=20 > > > attributes of the authenticator in its role as AAA client. > >=20 > > [Joe] So I think it makes sense that i2 is AAA data, what I'm not > seeing > > is what the EAP server is dealing with it instead of the AAA server. > [KH] Agreed, this needs to be addressed-see previous comment. > >=20 > > > In this way no additional exchange of information is required=20 > > > (again, the flow in Figure 1 is > > > wrong) and i2 does not need to be explicitly exchanged. This is=20 > > > important because we want to be able to add channel=20 > binding to EAP=20 > > > methods without modifying the method's protocol flow. If we would=20 > > > allow > > > i2 to be any type of data about the authenticator, this would=20 > > > require an explicit message flow from authenticator to=20 > EAP server as=20 > > > part of the EAP method. > > > > > > To avoid the introduction of additional communication flows, the=20 > > > modification of EAP methods and potentially the=20 > involvement of other=20 > > > protocols, I argue that i2 should only contain AAA=20 > information about=20 > > > the authenticator. Any other type of information about the=20 > > > authenticator that seems desirable for the channel binding=20 > > > verification can be stored in the local database (i3). > > > > > [Joe] I'm fine with i2 containing AAA information, but I=20 > don't really=20 > > see how it is part of EAP channel bindings. This seems to be more > about > > validating information in the AAA protocol. > [KH] I believe this is the only way to check whether an=20 > authenticator is lying about its identity, i.e. the=20 > identifier& addresses broadcasted to peers and identifiers &=20 > addresses used in the backend network. Again these=20 > identifiers & addresses may be of different types but should=20 > nevertheless map to the same device (check via a lookup in=20 > the database). [Joe] I'm not sure how much of this information is useful or practically verifiable by the EAP server. For example, often the client has no idea of the NAS IP address and may not have an idea of the NAS-ID. In many cases I'm not sure if spoofing addresses is a problem or if this is very manageable to maintain this information. If we split the data into i2a and i2b it may be clearer. =20 > >=20 > > For channel bindings I am more concerned with what is=20 > communicated in=20 > > i1. This is what EAP methods need to carry. i1 may need to carry > some > > data that may also be in a AAA attribute, but it may also need to > carry > > other data. My objection is restricting everything in i1 to being > AAA > > data. The current draft seems to requirements for i1 and i2 all=20 > > together. I don't think this is correct. > >=20 > [KH] Agreed. This limitation of i1 was not intended and needs=20 > to be addressed. i1 can contain anything that was broadcasted=20 > in the authenticator's (NAS) beacon while i2 is restricted to=20 > AAA attributes. > > > > > > " Sections 7.1, 7.2, 7.3 only recommend comparing=20 > information with=20 > > > what is received from the NAS and not about comparing with local=20 > > > information" > > > > > > [KH] Section 7 describes which attributes can be used in=20 > i1 for the=20 > > > channel binding compliance check, and Section 8 the=20 > attributes that=20 > > > can be used as part of i2. Comparing local information is only=20 > > > described as text in Section 10.1. We cannot provide concrete=20 > > > attributes here because > > > i3 is protocol-independent and basically contains data=20 > derived from=20 > > > policies. I don't think we can provide concrete examples=20 > here, but=20 > > > it might be a good idea to add another section after 7 and 8, to=20 > > > generally outline how the comparison with the local information=20 > > > should be executed. In that case, Section 10 could remain=20 > the same,=20 > > > explaining how such a database can be set up. > > > > > > "4. Section 8 is about AAA validation and is not channel=20 > bindings,=20 > > > is this section necessary?" > > > > > > [KH] Disagree, see my comments to your suggestions #2. > > > > > [Joe] So, I see i1 as the messages used in EAP channel=20 > bindings. i2=20 > > looks to me like validation that should be done by the AAA protocol. > I > > think I may not have understood your points above. I think=20 > the draft=20 > > needs to focus more on the requirements of i1 exchange and=20 > less on the=20 > > requirements of the i2 exchange. >=20 > [KH] In order to detect whether an authenticator is "lying"=20 > you need some data to compare i1 too. We believe that lying=20 > can be detected by comparing the views the EAP peer and EAP=20 > server have about the authenticator in an EAP session. The=20 > database is needed to enable the comparison. In addition, we=20 > check for the case that the authenticator lies to both ends=20 > (i.e. to the EAP peer and the EAP server) by checking the=20 > compliance of i1 and i2 with the policies stored in the database. [Joe] OK, so some i1 data can be compared with i2, in particular i2A data that has various options that affect policy evaluation. In general all i1 and i2 data that is important to the system should be checked against some authoritative database.=20 > >=20 > > > > > > Joe, I hope I could clarify some of your issues. I would=20 > also like=20 > > > to hear other opinions from the list on these issues. > > > > > > Katrin > > > > > > > > > > > > -----Original Message----- > > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org]=20 > On Behalf=20 > > > Of Joseph Salowey (jsalowey) > > > Sent: Thursday, June 18, 2009 12:12 PM > > > To: emu@ietf.org > > > Subject: [Emu] draft-ietf-emu-chbind-02 and AAA interaction > > > > > > After reviewing recent comments from Klaas on the list on Channel=20 > > > bindings there is one issue I would like to try to resolve before=20 > > > bringing this draft to last call. > > > > > > In section 5.1, the draft defines a message i2, which is=20 > the message=20 > > > carrying AAA attributes from the authenticator to the=20 > server using a=20 > > > AAA protocol. While, this message does occur in the protocol=20 > > > interactions, it is actually not that important in the channel=20 > > > binding interactions because the server does not completely trust=20 > > > the authenticator and must know what is valid through some other=20 > > > mechanism, such as the local database defined in the=20 > draft. I think=20 > > > this section is a bit misleading and needs to emphasize=20 > this point. =20 > > > This is further confused by the fact that in some=20 > sections the draft=20 > > > focuses entirely on AAA attributes to carry channel-binding=20 > > > information. While AAA attributes are undoubtedly important to=20 > > > carry it does not appear that they should be the only=20 > type of data=20 > > > allowed especially since the AAA protocol is not required to be=20 > > > directly involved other than to carry EAP. > > > This is demonstrated by the "TODO" 7.3 which suggests we=20 > need to add=20 > > > a way to carry the 802.11 RSN-IE. Since AAA protocols haven't=20 > > > needed to carry this information to date, it is not clear that=20 > > > adding this information to them would be helpful. > > > Given this I would suggest the following modifications to the > > > draft: > > > > > > 1. In sections 5.1 and 5.2 clarify the role of message i2 with=20 > > > respect to channel bindings. > > > 2. In section 6.1 define channel binding data as a=20 > superset of AAA=20 > > > attributes. In particular the last paragraph needs work=20 > and seems=20 > > > inconsistent with 7.1 which allows for the inclusion of Diameter=20 > > > attributes without the exclusion of other attributes. > > > 3. Sections 7.1, 7.2, 7.3 only recommend comparing=20 > information with=20 > > > what is received from the NAS and not about comparing with local=20 > > > information 4. Section 8 is about AAA validation and is=20 > not channel=20 > > > bindings, is this section necessary? > > > > > > If the working group agrees with this direction I can=20 > provide text=20 > > > for the changes. > > > > > > Please send comments to the list. > > > > > > Thanks, > > > > > > Joe > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www.ietf.org/mailman/listinfo/emu > > > >=20 From klaas@wierenga.net Fri Jun 26 06:35:28 2009 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 A8A0D3A684F for ; Fri, 26 Jun 2009 06:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8] 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 yKwUdByCh-8v for ; Fri, 26 Jun 2009 06:35:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 42E343A67AD for ; Fri, 26 Jun 2009 06:35:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,296,1243814400"; d="scan'208";a="43749496" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Jun 2009 13:35:41 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5QDZfYR027516; Fri, 26 Jun 2009 15:35:41 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5QDZdPt002867; Fri, 26 Jun 2009 13:35:41 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jun 2009 15:35:41 +0200 Received: from ams-kwiereng-8713.cisco.com ([10.55.220.244]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jun 2009 15:35:39 +0200 Message-Id: <5A93F7E9-61E0-4D2B-A322-0F55B54A777C@wierenga.net> From: Klaas Wierenga To: Joseph Salowey (jsalowey) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 26 Jun 2009 15:35:14 +0200 References: <49F6BDAE.2010101@cisco.com> <3A241A6B234BE948B8B474D261FEBC2F060EE03A@de01exm68.ds.mot.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 26 Jun 2009 13:35:39.0766 (UTC) FILETIME=[FEBAE960:01C9F662] Authentication-Results: ams-dkim-1; header.From=klaas@wierenga.net; dkim=neutral Cc: "klaas\(mailer list\)" , emu@ietf.org Subject: Re: [Emu] review of chbind-01 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: Fri, 26 Jun 2009 13:35:28 -0000 On Jun 1, 2009, at 12:42 AM, Joseph Salowey (jsalowey) wrote: Joe, (apologies for the late reply) > I'm not sure I quite understand the differences between the two cases. > > I think Klaas is saying that we need a protocol to exchange channel > binding information, but we should stop before we define rules on > how to > evaluate this information. While I think that the requirements for > the > protocol are absolutely necessary, I believe the analysis would be > incomplete if we did not provide information on how the data is > expected > to be evaluated. In many cases this evaluation needs to be done > against stored data to validate the correct operation of the system. ehm, almost, your description of both cases is correct. What I am saying is not that we should not evaluate this information, what I am saying is that it is very much non-trivial to do this evaluation, especially if you can not do some simple isEqual type comparison. I seem to remember that we had a hefty discussion in Dublin with Charles on fuzzy comparison etc. So what I am saying is that it would make sense for me to either: - just state that the evaluation of the received info is out of scope or... - do a better job at specifying how this should be done My personal preference would be to declare the evaluation bit out of scope (perhaps just mention that we expect this to be done against stored data), that would make the draft lean and mean, as well as provide a nice new topic to tackle in a future draft. Anyway, I can live with both approaches, but it would mean refining the draft wrt evaluating the data. (as you and Katrin seem to be doing now ;-) Klaas > > Joe > >> -----Original Message----- >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On >> Behalf Of Hoeper Katrin-QWKN37 >> Sent: Thursday, May 28, 2009 4:03 PM >> To: klaas(mailer list) >> Cc: emu@ietf.org >> Subject: Re: [Emu] review of chbind-01 >> >> Hello Klaas, >> >> Thank you for your very thorough review! >> And sorry that it took me so long to reply. >> >> My replies are in-line and will be reflected in the next >> draft version that I plan on posting shortly. >> >> I would appreciate your and the group's feedback on whether I >> addressed all your comments. >> >> I'd like to ask the group to check Klaas' primary comment >> since it is concerned with the scope of the draft. I'd be >> interested to know who shares this concern and whether the >> current draft should be modified accordingly. You'll find my >> opinion on this matter among my other replies below. >> >> Regards, >> Katrin >> >> >> -----Original Message----- >> From: Klaas Wierenga [mailto:klaas@cisco.com] >> Sent: Tuesday, April 28, 2009 3:26 AM >> To: Hoeper Katrin-QWKN37 >> Cc: emu@ietf.org >> Subject: review of chbind-01 >> >> Hi Katrin, >> >> I have reviewed your draft and I think the content is in >> principle in pretty good shape, see my comments further >> below. I have however a more fundamental concern that I would >> like to hear your (and others') opinion >> >> about. >> >> I have the feeling that the draft is too complicated because >> you mix two, only loosely related, problems. The way I see it >> there are 2 fundamental issues: >> >> 1) the NAS talks to both the peer and to the authentication >> server and the information given to both doesn't have to be >> consistent >> >> 2) the NAS gives information to authentication server (via the peer >> or >> not) and the authentication server needs to evaluate that >> information and make policy decisions based on that. >> >> Issue 1 is for me the one that most needs solving, and I >> would prefer this draft to focus on that one only. Issue 2 is >> not so much a technical >> >> problem as a business problem. The administrative entities >> controlling respectively the NAS and the AuthN server need to >> agree on the info they >> >> exchange and it is than up to the administrative entity to >> process that info (and log it for non-repudiation purposes >> etc.) and make policy >> >> decisions on them. >> >> Wrt to issue 1 I wonder if it is not sufficient to just >> "close the loop", i.e. have the NAS send the same info to >> both peer and AuthN server. Or alternatively, have all the >> info flow through the peer, that way you can be sure that >> peer and AuthN server have a consistent view of >> >> what the NAS offers. >> >> [KH] I agree that the solution presented in the current draft >> consists of a technical part (exchange end-to-end secured >> information between the peer & server, verify it and notify >> the peer about the result) and an administrative part >> (setting up a database to support the consistency and >> compliance checks of the exchanged channel binding information). >> >> Introducing a database to the network model is absolute >> essential for the solution to work. First of all, the >> exchanged information cannot be directly compared because >> peer and server may have a different view of the network >> information provided by the NAS/authenticator. For example, >> the peer may identify a NAS by its SSID, whereas the EAP >> server may only know the NAS-IP-Address. In order for the >> server to check whether both addresses belong to the same >> device, a table look-up is required. Such look-up tables are >> stored in the local database. Secondly, in roaming scenarios >> the server cannot "know" each NAS of all visited networks >> that the home network has a roaming agreement with. Here, the >> server can only check whether the information broadcasted by >> a NAS in a visited network complies with the roaming >> agreement with this network. For that reason, rules derived >> from the agreements and policies need to be stored in a >> database, such that the server can use these rules for its >> consistency/compliance checks. >> >> I hope we can agree on that a database is absolute essential >> for implementing meaningful channel bindings and that channel >> bindings in roaming scenarios need to make use of rules that >> have been derived from agreements and/or policies. The draft >> does not say how these rules are derived, that is indeed >> outside the scope. >> >> Bernard suggested in one of his earlier reviews to utilize >> such policy compliance checks to validate authorizations, >> e.g. checking whether a peer is authorized to access a >> particular part of a network or using a particular media. In >> addition, the solution enables the server to check whether an >> authenticator is authorized to grant access to a peer under >> the given circumstances. These authorization checks are >> included in the draft and are carried out by additional >> compliance checks. IMO this is a nice feature that can be >> achieved using channel bindings without changing the >> underlying protocol. It only requires additional information >> to be stored in the database. If there is a consensus that >> this feature should be outside the scope of the draft, it >> could be moved to a separate draft. Again, though, the local >> database and some compliance checks would still be a part of >> the remaining channel binding solution. >> ------------------------------------------------------ >> >> >> My concrete comments: >> >> 1, par 2: "while there may be some identity tied to that >> security association" >> >> What do you mean with "identity", are you talking about >> NAS-identifier, or something more generic? >> >> [KH] Yes, we are referring to NAS-IP-Address, NAS-Identifier and >> such. >> >> Proposed solution: "While there may be some identity tied to >> that security association, such as the NAS-Identifier, >> there's no reason the access point needs to advertize a >> consistent identity to clients." >> >> 1, par 4: "consistent with the defined network policy" >> >> I think it is not so much consistent as well as that is >> 'satisfies' the defined network policies >> >> [KH] Agree. What about 'compliant' instead? In addition, I >> think its best to explicitly distinguish between the >> consistency and the compliance checks. >> >> Proposed solution: "This allows the server to verify the >> authenticator is providing information to the peer that is 1) >> consistent with the information stored about this >> authenticator and 2) compliant with the defined network >> policy. In addition, the presented solution allows the server >> to verify that the peer is authorized to access the network >> in the manner described by the NAS." >> >> 3, par 1: I think you should call out here that proxy's are >> an example of that, you mention it later but it helps to give >> the reader an idea what you are talking about. >> >> [KH] Agree. >> >> Proposed solution: "Additionally, while an authenticator may >> not be compromised, other compromised elements in the >> networks (such as proxies), could provide false information >> to the authenticator..." >> >> 3, examples: I don't find the examples very compelling, how >> about for example a NAS giving wrong billing info to the peer >> "5$ all you can eat, >> >> while sending per minute rates to the Auth server? >> >> [KH] The current roaming example was chosen to illustrate an >> attack where victims are not aware of that they are actually >> roaming. If you (or anybody else) can come up with a more >> compelling example for the enterprise case, please let me know. >> >> Proposed solution: I will add another simple example to the >> Service Provider Network case along the lines of what you suggested. >> >> 4: "...do not ensure the binding different layers..." -> >> "...the binding >> >> OF different layers..." >> >> [KH] Corrected. >> >> 4.1: is the fact whether it is plaintext or opaque the unique >> difference? I would argue that it is whether it is in a >> separate channel >> >> or inline in the session key derivation. I think the >> plaintext vs opaque >> >> doesn't add anything here, later in your requirements you >> point out that >> >> the info sent needs to be protected, that seems enough to me. >> >> [KH] Here, we wanted to emphasize that only the exchange of >> the data allows an analysis of the information rather than a >> bitwise comparison. >> Latter only works for identical information (not always >> feasible, see different address/identifier discussion) that >> is exactly encoded in the same way (not really practical). >> >> Proposed solution: "The peer and server can both uniquely >> encode their respective view of the network information >> without exchanging it, resulting into an opaque blob that can >> be included directly into the derivation of EAP session keys." >> >> 4.2.: is it not enough to just say that the AuthN server and >> the peer need to get the same info? isConsistent would become >> isEqual, much easier to compute...... ;-) >> >> Unfortunately, isEqual is not feasible (see earlier >> discussion and address/identifier example). Another way to >> put it: Let's imagine peer and NAS/authenticator speak Dutch >> with each other, whereas the NAS/authenticator and the >> authentication server speak German. The isConsistent check >> allows us to verify whether both pieces of information have >> the same meaning (using the dictionary stored in the local >> database). On the other hand, the isEqual check will always fail. >> >> Proposed solution: none. >> >> 5.1, par 1: isConsistant -> isConsistent >> >> [KH] Corrected. >> >> 5.2, par 1: conistency of i1 and i2 and evaluating the policy >> is indeed nontrivial, but policy evaluation should imo be out >> of scope for this draft anyway. Policy verification is a >> local problem at the Auth server side, it has nothing to do >> withy the communication protocols. >> >> [KH] See my reply to your first comment. >> >> 6.2: "EAP methods MUST be able to import channel binding data >> from the lower layer...." >> >> I don't understand this requirement, what type of data are we >> talking about? >> >> [KH] For example, a peer should include the SSID received in >> the Beacon of a NAS/authenticator in i1. Consequently, a peer >> must be able to include information in i1 that has not been >> received as part of the EAP method. In order to do this, the >> EAP method must be able to access this kind of information >> from a lower layer. >> >> Proposed solution: none >> >> 7.2: NAS-Port-Type >> >> Why a MUST? I can imagine many use cases where from a policy >> point of view I couldn't care less what medium type I am using >> >> [KH] Agree >> >> Proposed solution: change to SHOULD >> >> 7.3: again, why a MUST? >> >> [KH] Disagree. This is not a policy question. This AVP is >> essential for mitigating lying NAS attacks and thus should be a MUST. >> >> Proposed solution: none >> >> 7.3.?: I think it worthwhile including 802.11u, after all >> this deals with NASes communicating data about their network >> to the peers, that is exactly what 11u does. >> >> [KH] Older draft versions included additional link-layers >> (admittedly not 11u), but were removed due to lack of >> feedback from the group on which AVPs should be included. >> Instead a few general attributes are provided that are useful >> to all link-layers (Section 7.2) and attributes for .11, 11r >> and 11s are listed as an example (Section 7.3). This is >> intended to provide a guideline for implementers to choose >> appropriate attributes when implementing channel bindings on >> different link layers. >> >> If you (or somebody else) happen to know which 11u AVPs >> should be used here, please let me know and I include them. >> >> Proposed solution: none, unless feedback from group is received >> >> 9.1: >> >> There is also trust between NAS/Authenticator and AuthN >> server. The Authenticator relies on the Authentication server >> for policy decisions. >> >> [KH] The trust model for channel bindings assumes that peer >> and server are honest, while the authenticator is the >> potential attacker (e.g. >> lying NAS attack, etc). In a trust model you usually don't >> care who the attacker trusts. >> >> 10.1, par 4: I don't think you put contractual info about >> roaming partners in the database, but the rules in the policy >> engine are rather the results of that. >> >> [KH] Agree >> >> Proposed solution: "In the service provider case, there >> should be a mechanism for entering policy rules that have >> been derived from the contractual information about roaming >> partners." >> >> >> Cheers, >> >> Klaas >> >> [KH] Prost, Katrin >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >> > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From klaas@wierenga.net Fri Jun 26 06:49:26 2009 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 868203A6B54 for ; Fri, 26 Jun 2009 06:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwlr8ylyeM7O for ; Fri, 26 Jun 2009 06:49:24 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DC5FB3A6AD3 for ; Fri, 26 Jun 2009 06:49:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,297,1243814400"; d="scan'208";a="180717685" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-2.cisco.com with ESMTP; 26 Jun 2009 13:49:42 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5QDnf8j011345; Fri, 26 Jun 2009 15:49:41 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5QDnfWN008283; Fri, 26 Jun 2009 13:49:41 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jun 2009 15:49:41 +0200 Received: from ams-kwiereng-8713.cisco.com ([10.55.220.244]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jun 2009 15:49:39 +0200 Message-Id: <34973ADB-AEB4-44D4-A8BB-3A21C6D8DA54@wierenga.net> From: Klaas Wierenga To: Joseph Salowey (jsalowey) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 26 Jun 2009 15:49:13 +0200 References: <3A241A6B234BE948B8B474D261FEBC2F062634BD@de01exm68.ds.mot.com> <3A241A6B234BE948B8B474D261FEBC2F0626405F@de01exm68.ds.mot.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 26 Jun 2009 13:49:40.0081 (UTC) FILETIME=[F398CE10:01C9F664] Authentication-Results: ams-dkim-2; header.From=klaas@wierenga.net; dkim=neutral Cc: emu@ietf.org Subject: Re: [Emu] draft-ietf-emu-chbind-02 and AAA interaction 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: Fri, 26 Jun 2009 13:49:26 -0000 Joe, Katrin, A few comments > Thanks for the clarifications, I think I understand better now. > > Comments inline. > > >>>> Joe, >>>> >>>> Thank you for bringing this up. Find my replies below: >>>> >>>> "1. In sections 5.1 and 5.2 clarify the role of message i2 with >>>> respect to channel bindings." >>>> >>>> [KH] I agree with your observations that the use and >> exchange of i2 >>>> is not well described in the draft and needs to be clarified. >>>> >>>> The EAP server can utilize three pieces of information for its >>>> channel binding verification, namely: i1 received from >> the EAP peer, >>>> i2 received as part of AAA communications with the >> authenticator and >>>> i3 stored in a local database. The confusion lies in the >> description >>>> of i2 and its "exchange". >>>> >>>> i2 is basically information that the EAP server already "knows" >>>> about the authenticator. The information is *not* sent as >> payload to >>>> the EAP server, it was rather part of previous >> communications with >>>> the authenticator during the current EAP session. For >> example, the >>>> EAP server typically "knows" the NAS-IP address of the >> authenticator >>>> in an EAP execution. Basically, we want to utilize >> information for >>>> the channel binding consistency check that the EAP server already >>>> knows about the authenticator. This information is referred to as >> i2. >>>> >>>> I agree that the arrow with i2 from authenticator to EAP >> server in >>>> Figure 1 is wrong, because i2 is not a protocol message. Figure 1 >>>> does not reflect the above description and needs to be revised >>>> accordingly. >>>> On the other hand, an EAP server can optionally include i2 in its >>>> reply to the EAP peer, e.g. to enable the peer to perform its own >>>> consistency checks. In that case, i2 needs to be explicitly >>>> exchanged. >>>> >>> [Joe] OK, I think I may understand better. If I understand >> correctly, >>> there are two separate consistency checks: >>> >>> 1. one checking the consistency of what the client sees against a >>> database of what should be seen. (i1) 2. one checking the >> consistency >>> of what the authenticator against a database of what should >> be seen. >>> (i2) >>> >>> Is this correct? >>> >> [KH] Almost. Check 1 "is the authenticator lying to the peer?": >> consistency check of i1 and i2 with the aid of the database >> (because a direct comparison is not possible), i.e. checking >> whether the info submitted to the peer and known to by the >> EAP server are consistent. >> Check 2 "is the authenticator lying to both ends to violate rules": >> check whether i1 and i2 comply with policies stored in the database. >> Actually check 2 could be split into two checks: 2a) check >> whether authenticator lies to the EAP server and 2b) does the >> authenticator violate any rules. >> > [Joe] Good point, so 2A would be useful in the case where the AAA is > making some policy decision based on what the authenticator states and > there is more than one choice for the authenticator. Perhaps if the > authenticator can advertise a free and charged SSID the client > associates with the free one, but the authenticator reports the > charged > one. This may be a bit contrived, but it seems like it could be a > good > thing to do. I think it would be useful to split this up into 2A and > 2B. 2A is needed when there is an attribute used in AAA policy that > the > client is aware of and there is more than one choice for the value of > the attribute for the authenticator. 2B I think is something more for > AAA validation of the message. yes, I agree > > >>> It seems that in your picture i2 is really between the authenticator >> and >>> AAA. This affects some of your statements above. For >> example its not >>> clear to me that the EAP Server would necessarily know >> anything about >>> NAS-IP. >> [KH] This is true and needs to be clarified. Either the EAP >> server can only use the AAA attributes it knows about the >> authenticator from the on-going EAP execution or the EAP >> server needs to get this information from the AAA server to >> perform the consistency check. Do you see any use case for the >> former? > > [Joe] So, I think some of the data, mostly 2B data, should be > validated > by the AAA server. Some of the type 1 data may not be passed in the > AAA > protocol. For 1 and 2A data that is communicated in AAA I think it > will > depend upon implementation as to who maintains the authoritative > database for attributes. In some cases validation responsibility > may be > split. > >>> >>>> "2. In section 6.1 define channel binding data as a >> superset of AAA >>>> attributes. In particular the last paragraph needs work >> and seems >>>> inconsistent with 7.1 which allows for the inclusion of Diameter >>>> attributes without the exclusion of other attributes." >>>> >>>> [KH] The reason why we chose i2 as AAA data is because the >>>> authenticator and EAP server communicate using an AAA protocol >>>> during an EAP execution. Hence, the EAP server has access to AAA >>>> attributes of the authenticator in its role as AAA client. >>> >>> [Joe] So I think it makes sense that i2 is AAA data, what I'm not >> seeing >>> is what the EAP server is dealing with it instead of the AAA server. >> [KH] Agreed, this needs to be addressed-see previous comment. >>> >>>> In this way no additional exchange of information is required >>>> (again, the flow in Figure 1 is >>>> wrong) and i2 does not need to be explicitly exchanged. This is >>>> important because we want to be able to add channel >> binding to EAP >>>> methods without modifying the method's protocol flow. If we would >>>> allow >>>> i2 to be any type of data about the authenticator, this would >>>> require an explicit message flow from authenticator to >> EAP server as >>>> part of the EAP method. >>>> >>>> To avoid the introduction of additional communication flows, the >>>> modification of EAP methods and potentially the >> involvement of other >>>> protocols, I argue that i2 should only contain AAA >> information about >>>> the authenticator. Any other type of information about the >>>> authenticator that seems desirable for the channel binding >>>> verification can be stored in the local database (i3). >>>> >>> [Joe] I'm fine with i2 containing AAA information, but I >> don't really >>> see how it is part of EAP channel bindings. This seems to be more >> about >>> validating information in the AAA protocol. >> [KH] I believe this is the only way to check whether an >> authenticator is lying about its identity, i.e. the >> identifier& addresses broadcasted to peers and identifiers & >> addresses used in the backend network. Again these >> identifiers & addresses may be of different types but should >> nevertheless map to the same device (check via a lookup in >> the database). > [Joe] I'm not sure how much of this information is useful or > practically > verifiable by the EAP server. For example, often the client has no > idea > of the NAS IP address and may not have an idea of the NAS-ID. In many > cases I'm not sure if spoofing addresses is a problem or if this is > very > manageable to maintain this information. If we split the data into > i2a > and i2b it may be clearer. I guess we shouldn't make assumptions as to what information is useful or practically verifiable. I think the bottom line is that the EAP- server learns a whole bunch of things, some of which may be verifiable in a particular environment and others are not. For example in the case of RadSec the EAP-server may know with some certainty what the ID of the NAS is and in other circumstances not. But splitting i2a and i2b would make things clearer. Klaas [no comments below here] > >>> >>> For channel bindings I am more concerned with what is >> communicated in >>> i1. This is what EAP methods need to carry. i1 may need to carry >> some >>> data that may also be in a AAA attribute, but it may also need to >> carry >>> other data. My objection is restricting everything in i1 to being >> AAA >>> data. The current draft seems to requirements for i1 and i2 all >>> together. I don't think this is correct. >>> >> [KH] Agreed. This limitation of i1 was not intended and needs >> to be addressed. i1 can contain anything that was broadcasted >> in the authenticator's (NAS) beacon while i2 is restricted to >> AAA attributes. >>>> >>>> " Sections 7.1, 7.2, 7.3 only recommend comparing >> information with >>>> what is received from the NAS and not about comparing with local >>>> information" >>>> >>>> [KH] Section 7 describes which attributes can be used in >> i1 for the >>>> channel binding compliance check, and Section 8 the >> attributes that >>>> can be used as part of i2. Comparing local information is only >>>> described as text in Section 10.1. We cannot provide concrete >>>> attributes here because >>>> i3 is protocol-independent and basically contains data >> derived from >>>> policies. I don't think we can provide concrete examples >> here, but >>>> it might be a good idea to add another section after 7 and 8, to >>>> generally outline how the comparison with the local information >>>> should be executed. In that case, Section 10 could remain >> the same, >>>> explaining how such a database can be set up. >>>> >>>> "4. Section 8 is about AAA validation and is not channel >> bindings, >>>> is this section necessary?" >>>> >>>> [KH] Disagree, see my comments to your suggestions #2. >>>> >>> [Joe] So, I see i1 as the messages used in EAP channel >> bindings. i2 >>> looks to me like validation that should be done by the AAA protocol. >> I >>> think I may not have understood your points above. I think >> the draft >>> needs to focus more on the requirements of i1 exchange and >> less on the >>> requirements of the i2 exchange. >> >> [KH] In order to detect whether an authenticator is "lying" >> you need some data to compare i1 too. We believe that lying >> can be detected by comparing the views the EAP peer and EAP >> server have about the authenticator in an EAP session. The >> database is needed to enable the comparison. In addition, we >> check for the case that the authenticator lies to both ends >> (i.e. to the EAP peer and the EAP server) by checking the >> compliance of i1 and i2 with the policies stored in the database. > > [Joe] OK, so some i1 data can be compared with i2, in particular i2A > data that has various options that affect policy evaluation. In > general > all i1 and i2 data that is important to the system should be checked > against some authoritative database. > >>> >>>> >>>> Joe, I hope I could clarify some of your issues. I would >> also like >>>> to hear other opinions from the list on these issues. >>>> >>>> Katrin >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] >> On Behalf >>>> Of Joseph Salowey (jsalowey) >>>> Sent: Thursday, June 18, 2009 12:12 PM >>>> To: emu@ietf.org >>>> Subject: [Emu] draft-ietf-emu-chbind-02 and AAA interaction >>>> >>>> After reviewing recent comments from Klaas on the list on Channel >>>> bindings there is one issue I would like to try to resolve before >>>> bringing this draft to last call. >>>> >>>> In section 5.1, the draft defines a message i2, which is >> the message >>>> carrying AAA attributes from the authenticator to the >> server using a >>>> AAA protocol. While, this message does occur in the protocol >>>> interactions, it is actually not that important in the channel >>>> binding interactions because the server does not completely trust >>>> the authenticator and must know what is valid through some other >>>> mechanism, such as the local database defined in the >> draft. I think >>>> this section is a bit misleading and needs to emphasize >> this point. >>>> This is further confused by the fact that in some >> sections the draft >>>> focuses entirely on AAA attributes to carry channel-binding >>>> information. While AAA attributes are undoubtedly important to >>>> carry it does not appear that they should be the only >> type of data >>>> allowed especially since the AAA protocol is not required to be >>>> directly involved other than to carry EAP. >>>> This is demonstrated by the "TODO" 7.3 which suggests we >> need to add >>>> a way to carry the 802.11 RSN-IE. Since AAA protocols haven't >>>> needed to carry this information to date, it is not clear that >>>> adding this information to them would be helpful. >>>> Given this I would suggest the following modifications to the >>>> draft: >>>> >>>> 1. In sections 5.1 and 5.2 clarify the role of message i2 with >>>> respect to channel bindings. >>>> 2. In section 6.1 define channel binding data as a >> superset of AAA >>>> attributes. In particular the last paragraph needs work >> and seems >>>> inconsistent with 7.1 which allows for the inclusion of Diameter >>>> attributes without the exclusion of other attributes. >>>> 3. Sections 7.1, 7.2, 7.3 only recommend comparing >> information with >>>> what is received from the NAS and not about comparing with local >>>> information 4. Section 8 is about AAA validation and is >> not channel >>>> bindings, is this section necessary? >>>> >>>> If the working group agrees with this direction I can >> provide text >>>> for the changes. >>>> >>>> Please send comments to the list. >>>> >>>> Thanks, >>>> >>>> Joe >>>> _______________________________________________ >>>> Emu mailing list >>>> Emu@ietf.org >>>> https://www.ietf.org/mailman/listinfo/emu >>>> >> > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From khoeper@motorola.com Fri Jun 26 07:04:30 2009 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 79A943A6B6A for ; Fri, 26 Jun 2009 07:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnnOAvWBmJt9 for ; Fri, 26 Jun 2009 07:04:28 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 14CC33A6B87 for ; Fri, 26 Jun 2009 07:03:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1246025024!43118327!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18932 invoked from network); 26 Jun 2009 14:03:45 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Jun 2009 14:03:45 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n5QE3iMG005356 for ; Fri, 26 Jun 2009 07:03:44 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n5QE3iNh005422 for ; Fri, 26 Jun 2009 09:03:44 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n5QE3h1o005417 for ; Fri, 26 Jun 2009 09:03:43 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jun 2009 10:03:22 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F0629CB0A@de01exm68.ds.mot.com> In-Reply-To: <34973ADB-AEB4-44D4-A8BB-3A21C6D8DA54@wierenga.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] draft-ietf-emu-chbind-02 and AAA interaction thread-index: Acn2ZPrZwO6bKxWzRSuTp3NRtdPDmAAAaQnQ References: <3A241A6B234BE948B8B474D261FEBC2F062634BD@de01exm68.ds.mot.com> <3A241A6B234BE948B8B474D261FEBC2F0626405F@de01exm68.ds.mot.com> <34973ADB-AEB4-44D4-A8BB-3A21C6D8DA54@wierenga.net> From: "Hoeper Katrin-QWKN37" To: "Klaas Wierenga" , "Joseph Salowey (jsalowey)" X-CFilter-Loop: Reflected Cc: emu@ietf.org Subject: Re: [Emu] draft-ietf-emu-chbind-02 and AAA interaction 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: Fri, 26 Jun 2009 14:04:30 -0000 Klaas, Thanks for your feedback. Joe and I are currently working on a revision that will hopefully address all issues raised by Joe and you. Regards, Katrin > -----Original Message----- > From: Klaas Wierenga [mailto:klaas@wierenga.net] > Sent: Friday, June 26, 2009 8:49 AM > To: Joseph Salowey (jsalowey) > Cc: Hoeper Katrin-QWKN37; emu@ietf.org > Subject: Re: [Emu] draft-ietf-emu-chbind-02 and AAA interaction >=20 > Joe, Katrin, >=20 > A few comments >=20 > > Thanks for the clarifications, I think I understand better now. > > > > Comments inline. > > > > > >>>> Joe, > >>>> > >>>> Thank you for bringing this up. Find my replies below: > >>>> > >>>> "1. In sections 5.1 and 5.2 clarify the role of message i2 with > >>>> respect to channel bindings." > >>>> > >>>> [KH] I agree with your observations that the use and > >> exchange of i2 > >>>> is not well described in the draft and needs to be clarified. > >>>> > >>>> The EAP server can utilize three pieces of information for its > >>>> channel binding verification, namely: i1 received from > >> the EAP peer, > >>>> i2 received as part of AAA communications with the > >> authenticator and > >>>> i3 stored in a local database. The confusion lies in the > >> description > >>>> of i2 and its "exchange". > >>>> > >>>> i2 is basically information that the EAP server already "knows" > >>>> about the authenticator. The information is *not* sent as > >> payload to > >>>> the EAP server, it was rather part of previous > >> communications with > >>>> the authenticator during the current EAP session. For > >> example, the > >>>> EAP server typically "knows" the NAS-IP address of the > >> authenticator > >>>> in an EAP execution. Basically, we want to utilize > >> information for > >>>> the channel binding consistency check that the EAP server already > >>>> knows about the authenticator. This information is referred to as > >> i2. > >>>> > >>>> I agree that the arrow with i2 from authenticator to EAP > >> server in > >>>> Figure 1 is wrong, because i2 is not a protocol message. Figure 1 > >>>> does not reflect the above description and needs to be revised > >>>> accordingly. > >>>> On the other hand, an EAP server can optionally include i2 in its > >>>> reply to the EAP peer, e.g. to enable the peer to perform its own > >>>> consistency checks. In that case, i2 needs to be explicitly > >>>> exchanged. > >>>> > >>> [Joe] OK, I think I may understand better. If I understand > >> correctly, > >>> there are two separate consistency checks: > >>> > >>> 1. one checking the consistency of what the client sees against a > >>> database of what should be seen. (i1) 2. one checking the > >> consistency > >>> of what the authenticator against a database of what should > >> be seen. > >>> (i2) > >>> > >>> Is this correct? > >>> > >> [KH] Almost. Check 1 "is the authenticator lying to the peer?": > >> consistency check of i1 and i2 with the aid of the database > >> (because a direct comparison is not possible), i.e. checking > >> whether the info submitted to the peer and known to by the > >> EAP server are consistent. > >> Check 2 "is the authenticator lying to both ends to violate rules": > >> check whether i1 and i2 comply with policies stored in the database. > >> Actually check 2 could be split into two checks: 2a) check > >> whether authenticator lies to the EAP server and 2b) does the > >> authenticator violate any rules. > >> > > [Joe] Good point, so 2A would be useful in the case where the AAA is > > making some policy decision based on what the authenticator states and > > there is more than one choice for the authenticator. Perhaps if the > > authenticator can advertise a free and charged SSID the client > > associates with the free one, but the authenticator reports the > > charged > > one. This may be a bit contrived, but it seems like it could be a > > good > > thing to do. I think it would be useful to split this up into 2A and > > 2B. 2A is needed when there is an attribute used in AAA policy that > > the > > client is aware of and there is more than one choice for the value of > > the attribute for the authenticator. 2B I think is something more for > > AAA validation of the message. >=20 > yes, I agree >=20 > > > > > >>> It seems that in your picture i2 is really between the authenticator > >> and > >>> AAA. This affects some of your statements above. For > >> example its not > >>> clear to me that the EAP Server would necessarily know > >> anything about > >>> NAS-IP. > >> [KH] This is true and needs to be clarified. Either the EAP > >> server can only use the AAA attributes it knows about the > >> authenticator from the on-going EAP execution or the EAP > >> server needs to get this information from the AAA server to > >> perform the consistency check. Do you see any use case for the > >> former? > > > > [Joe] So, I think some of the data, mostly 2B data, should be > > validated > > by the AAA server. Some of the type 1 data may not be passed in the > > AAA > > protocol. For 1 and 2A data that is communicated in AAA I think it > > will > > depend upon implementation as to who maintains the authoritative > > database for attributes. In some cases validation responsibility > > may be > > split. > > > >>> > >>>> "2. In section 6.1 define channel binding data as a > >> superset of AAA > >>>> attributes. In particular the last paragraph needs work > >> and seems > >>>> inconsistent with 7.1 which allows for the inclusion of Diameter > >>>> attributes without the exclusion of other attributes." > >>>> > >>>> [KH] The reason why we chose i2 as AAA data is because the > >>>> authenticator and EAP server communicate using an AAA protocol > >>>> during an EAP execution. Hence, the EAP server has access to AAA > >>>> attributes of the authenticator in its role as AAA client. > >>> > >>> [Joe] So I think it makes sense that i2 is AAA data, what I'm not > >> seeing > >>> is what the EAP server is dealing with it instead of the AAA server. > >> [KH] Agreed, this needs to be addressed-see previous comment. > >>> > >>>> In this way no additional exchange of information is required > >>>> (again, the flow in Figure 1 is > >>>> wrong) and i2 does not need to be explicitly exchanged. This is > >>>> important because we want to be able to add channel > >> binding to EAP > >>>> methods without modifying the method's protocol flow. If we would > >>>> allow > >>>> i2 to be any type of data about the authenticator, this would > >>>> require an explicit message flow from authenticator to > >> EAP server as > >>>> part of the EAP method. > >>>> > >>>> To avoid the introduction of additional communication flows, the > >>>> modification of EAP methods and potentially the > >> involvement of other > >>>> protocols, I argue that i2 should only contain AAA > >> information about > >>>> the authenticator. Any other type of information about the > >>>> authenticator that seems desirable for the channel binding > >>>> verification can be stored in the local database (i3). > >>>> > >>> [Joe] I'm fine with i2 containing AAA information, but I > >> don't really > >>> see how it is part of EAP channel bindings. This seems to be more > >> about > >>> validating information in the AAA protocol. > >> [KH] I believe this is the only way to check whether an > >> authenticator is lying about its identity, i.e. the > >> identifier& addresses broadcasted to peers and identifiers & > >> addresses used in the backend network. Again these > >> identifiers & addresses may be of different types but should > >> nevertheless map to the same device (check via a lookup in > >> the database). > > [Joe] I'm not sure how much of this information is useful or > > practically > > verifiable by the EAP server. For example, often the client has no > > idea > > of the NAS IP address and may not have an idea of the NAS-ID. In many > > cases I'm not sure if spoofing addresses is a problem or if this is > > very > > manageable to maintain this information. If we split the data into > > i2a > > and i2b it may be clearer. >=20 > I guess we shouldn't make assumptions as to what information is useful > or practically verifiable. I think the bottom line is that the EAP- > server learns a whole bunch of things, some of which may be verifiable > in a particular environment and others are not. For example in the > case of RadSec the EAP-server may know with some certainty what the ID > of the NAS is and in other circumstances not. But splitting i2a and > i2b would make things clearer. >=20 > Klaas >=20 > [no comments below here] >=20 > > > >>> > >>> For channel bindings I am more concerned with what is > >> communicated in > >>> i1. This is what EAP methods need to carry. i1 may need to carry > >> some > >>> data that may also be in a AAA attribute, but it may also need to > >> carry > >>> other data. My objection is restricting everything in i1 to being > >> AAA > >>> data. The current draft seems to requirements for i1 and i2 all > >>> together. I don't think this is correct. > >>> > >> [KH] Agreed. This limitation of i1 was not intended and needs > >> to be addressed. i1 can contain anything that was broadcasted > >> in the authenticator's (NAS) beacon while i2 is restricted to > >> AAA attributes. > >>>> > >>>> " Sections 7.1, 7.2, 7.3 only recommend comparing > >> information with > >>>> what is received from the NAS and not about comparing with local > >>>> information" > >>>> > >>>> [KH] Section 7 describes which attributes can be used in > >> i1 for the > >>>> channel binding compliance check, and Section 8 the > >> attributes that > >>>> can be used as part of i2. Comparing local information is only > >>>> described as text in Section 10.1. We cannot provide concrete > >>>> attributes here because > >>>> i3 is protocol-independent and basically contains data > >> derived from > >>>> policies. I don't think we can provide concrete examples > >> here, but > >>>> it might be a good idea to add another section after 7 and 8, to > >>>> generally outline how the comparison with the local information > >>>> should be executed. In that case, Section 10 could remain > >> the same, > >>>> explaining how such a database can be set up. > >>>> > >>>> "4. Section 8 is about AAA validation and is not channel > >> bindings, > >>>> is this section necessary?" > >>>> > >>>> [KH] Disagree, see my comments to your suggestions #2. > >>>> > >>> [Joe] So, I see i1 as the messages used in EAP channel > >> bindings. i2 > >>> looks to me like validation that should be done by the AAA protocol. > >> I > >>> think I may not have understood your points above. I think > >> the draft > >>> needs to focus more on the requirements of i1 exchange and > >> less on the > >>> requirements of the i2 exchange. > >> > >> [KH] In order to detect whether an authenticator is "lying" > >> you need some data to compare i1 too. We believe that lying > >> can be detected by comparing the views the EAP peer and EAP > >> server have about the authenticator in an EAP session. The > >> database is needed to enable the comparison. In addition, we > >> check for the case that the authenticator lies to both ends > >> (i.e. to the EAP peer and the EAP server) by checking the > >> compliance of i1 and i2 with the policies stored in the database. > > > > [Joe] OK, so some i1 data can be compared with i2, in particular i2A > > data that has various options that affect policy evaluation. In > > general > > all i1 and i2 data that is important to the system should be checked > > against some authoritative database. > > > >>> > >>>> > >>>> Joe, I hope I could clarify some of your issues. I would > >> also like > >>>> to hear other opinions from the list on these issues. > >>>> > >>>> Katrin > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] > >> On Behalf > >>>> Of Joseph Salowey (jsalowey) > >>>> Sent: Thursday, June 18, 2009 12:12 PM > >>>> To: emu@ietf.org > >>>> Subject: [Emu] draft-ietf-emu-chbind-02 and AAA interaction > >>>> > >>>> After reviewing recent comments from Klaas on the list on Channel > >>>> bindings there is one issue I would like to try to resolve before > >>>> bringing this draft to last call. > >>>> > >>>> In section 5.1, the draft defines a message i2, which is > >> the message > >>>> carrying AAA attributes from the authenticator to the > >> server using a > >>>> AAA protocol. While, this message does occur in the protocol > >>>> interactions, it is actually not that important in the channel > >>>> binding interactions because the server does not completely trust > >>>> the authenticator and must know what is valid through some other > >>>> mechanism, such as the local database defined in the > >> draft. I think > >>>> this section is a bit misleading and needs to emphasize > >> this point. > >>>> This is further confused by the fact that in some > >> sections the draft > >>>> focuses entirely on AAA attributes to carry channel-binding > >>>> information. While AAA attributes are undoubtedly important to > >>>> carry it does not appear that they should be the only > >> type of data > >>>> allowed especially since the AAA protocol is not required to be > >>>> directly involved other than to carry EAP. > >>>> This is demonstrated by the "TODO" 7.3 which suggests we > >> need to add > >>>> a way to carry the 802.11 RSN-IE. Since AAA protocols haven't > >>>> needed to carry this information to date, it is not clear that > >>>> adding this information to them would be helpful. > >>>> Given this I would suggest the following modifications to the > >>>> draft: > >>>> > >>>> 1. In sections 5.1 and 5.2 clarify the role of message i2 with > >>>> respect to channel bindings. > >>>> 2. In section 6.1 define channel binding data as a > >> superset of AAA > >>>> attributes. In particular the last paragraph needs work > >> and seems > >>>> inconsistent with 7.1 which allows for the inclusion of Diameter > >>>> attributes without the exclusion of other attributes. > >>>> 3. Sections 7.1, 7.2, 7.3 only recommend comparing > >> information with > >>>> what is received from the NAS and not about comparing with local > >>>> information 4. Section 8 is about AAA validation and is > >> not channel > >>>> bindings, is this section necessary? > >>>> > >>>> If the working group agrees with this direction I can > >> provide text > >>>> for the changes. > >>>> > >>>> Please send comments to the list. > >>>> > >>>> Thanks, > >>>> > >>>> Joe > >>>> _______________________________________________ > >>>> Emu mailing list > >>>> Emu@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/emu > >>>> > >> > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu From aland@deployingradius.com Tue Jun 30 10:01:44 2009 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 BBD763A69D5 for ; Tue, 30 Jun 2009 10:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUVIe+p6keQk for ; Tue, 30 Jun 2009 10:01:44 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 0B7C83A680D for ; Tue, 30 Jun 2009 10:01:44 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 97216123427F for ; Tue, 30 Jun 2009 18:52:09 +0200 (CEST) Message-ID: <4A4A42B9.8060402@deployingradius.com> Date: Tue, 30 Jun 2009 18:52:09 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: emu@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Emu] Call for agenda items for IETF 75 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, 30 Jun 2009 17:01:44 -0000 We currently have a 2 hour slot on Monday afternoon. Please submit agenda requests to the chairs as soon as possible. Alan DeKok.