[Emu] Review of draft-clancy-emu-chbind-02.txt
Bernard Aboba <bernard_aboba@hotmail.com> Fri, 01 August 2008 10:30 UTC
Return-Path: <emu-bounces@ietf.org>
X-Original-To: emu-archive@megatron.ietf.org
Delivered-To: ietfarch-emu-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A33228C3F5; Fri, 1 Aug 2008 03:30:24 -0700 (PDT)
X-Original-To: emu@core3.amsl.com
Delivered-To: emu@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 098A428C3F1 for <emu@core3.amsl.com>; Fri, 1 Aug 2008 03:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level:
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebwpXMHG1dkA for <emu@core3.amsl.com>; Fri, 1 Aug 2008 03:30:20 -0700 (PDT)
Received: from blu0-omc3-s15.blu0.hotmail.com (blu0-omc3-s15.blu0.hotmail.com [65.55.116.90]) by core3.amsl.com (Postfix) with ESMTP id 74C5328C21C for <emu@ietf.org>; Fri, 1 Aug 2008 03:30:20 -0700 (PDT)
Received: from BLU137-W15 ([65.55.116.72]) by blu0-omc3-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Aug 2008 03:30:23 -0700
Message-ID: <BLU137-W15D5D62B1F2A6EAAA92431937F0@phx.gbl>
X-Originating-IP: [130.129.23.7]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: emu@ietf.org
Date: Fri, 01 Aug 2008 03:30:23 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 01 Aug 2008 10:30:23.0630 (UTC) FILETIME=[9B176AE0:01C8F3C1]
Subject: [Emu] Review of draft-clancy-emu-chbind-02.txt
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/emu>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2094538033=="
Sender: emu-bounces@ietf.org
Errors-To: emu-bounces@ietf.org
Overview: This version of the document still has some issues remaining. Section 1 The so-called "lying NAS" problem is a well-documented problem with the current Extensible Authentication Protocol (EAP) architecture [RFC3748] when used in pass-through authenticator mode. Here, a Network Access Server (NAS), or pass-through authenticator, may represent one set of information (e.g. identity, capabilities, configuration, etc) to the backend Authentication, Authorization, and Accounting (AAA) infrastructure, while representing contrary information to EAP clients. [BA] As noted in the review of -00, the issue isn't just whether the NAS is sending different information to the EAP peer and AAA server. It also is possible that the NAS will send the same information to the peer and AAA server, but that both could be wrong. Section 3 There are two different types of networks to consider: enterprise networks and service provider networks. In enterprise networks, we assume a single administrative domain, making it feasible for an EAP server to have information about all the authenticators in the network. In service provider networks, global knowledge is infeasible due to indirection via roaming. When a client is outside its home administrative domain, the goal is to ensure that the level of service received by the client is consistent with the contractual agreement between the two service providers. [BA] While the AAA server might have information about all the authenticators in the enterprise case, if it is more than one hop removed from the NAS, then it might not be able to check the validity of the AAA attributes. For example, a first hop AAA server can check if the NAS-IP-Address/NAS-IPv6-Address attributes match the IP source address corresponding to the shared secret. A AAA server multiple hops away cannot verify this. o Service Provider Network: An EAP-enabled mobile phone provider operating along a geo-political boundary could boost their cell towers' transmission power and advertise the network identity of the neighboring country's indigenous provider. This would cause unknowing handsets to associate with an unintended operator, and consequently be subject to high roaming fees without realizing they had roamed off their home provider's network. [BA] This seems like a good example. My understanding is that power boosting actually does occur. It might be worthwhile to consider adding an Appendix to talk about how channel bindings might address this or other potential examples. o It allows for fuzzy comparisons of network properties, rather than requiring absolute comparisons. This allows for a broader definition of consistency, rather than bitwise equality. [BA] As discussed during the EMU WG meeting, a term other than "fuzzy" would probably be better. Also, there probably needs to be more discussion on why enabling bit-by-bit comparisons is undesirable or not important. Section 4 o Given it doesn't affect the key derivation, exact use of the results can be subject to policy, to facilitate debugging, incremental deployment, and backward compatibility. [BA] I think the major issue with the key derivation approach is that in practice, "canonicalization" and formatting issues are highly likely in a channel bindings implementation, even if formats are well specified. The implication of this is that requiring enforcement may not be practical; rather logging, or evidence gathering may be all that can be achieved. The key derivation approach can't support such a "logging only" mode; enforcement is required. The scope of EAP channel bindings differs somewhat depending on the type of deployment in which they are being used. In enterprise networks, they can be used to authenticate very specific properties of the authenticator (e.g. MAC address, supported link types and data rates, etc), while in service provider networks they can generally only authenticate broader information about a roaming partner's network (e.g. network name, roaming information, link security requirements, etc). The reason for the difference has to do with the amount of information you expect your home EAP server to know about the authenticator and/or network to which you are connected. In roaming cases, they are likely to only know information contained in their roaming agreements. [BA] It would probably also be worth talking about the inability to directly verify the correctness of some parameters in the multi-hop case (in either enterprise or service provider scenarios). Section 5 Channel bindings are always provided between two communication endpoints, here the EAP client and server, who communicate through an authenticator in pass-trough mode. During network advertisement, selection, and authentication, the authenticator presents unauthenticated information, labeled i1 for convenience, about the network to the peer. As there is no established trust relationship between the peer and authenticator, there is no way for the peer to validate this information. Our goal is to transport i1 from the peer to the server, and allow the server to validate it against information i2 it has stored in its local database, labeled DB. [BA] As we discussed in the EMU WG meeting, is Channel Bindings only about the AAA server verifying the info sent from the NAS to the EAP peer, or is it also about comparing the AAA attributes against that information? For example, would it be ok if the peer got the correct information, but the AAA attributes are incorrect? This information, i1, could include the identity of the authenticator and the network it represents, in addition to advertised network information such as offered services and roaming information. To prevent attacks by rogue authenticators, the EAP server must be able to verify that i1 either matches its knowledge of the network (enterprise model) or is consistent with the contractual agreement between itself and the roaming partner network to which the client is connected (service provider model). [BA] The term "authenticator identity" is used in multiple places, without being defined. RFC 5247 defines this as the NAS-Identifier/NAS-IP-Address/ NAS-IPv6-Address attributes, but I'm not sure this is what you mean here. One issue with highlighting this particular problem is that even in IEEE 802.11r, the NAS-Identifier is not advertised in the Beacon. Note that in addition to just returning a validation result indicating whether i1 and i2 are consistent, the EAP server can optionally return i2 in its entirety. This would allow the EAP server to provide additional, authenticated information about network or authenticator to which the client has connected that the client may wish to use in deciding whether the authenticator is authorized to provide the type of service the client desires. This goes beyond the general definition of channel binding, but allows for additional flexibility. [BA] How does the EAP server/AAA server obtain the information i2? For example, is it indexed via some key AAA attributes (e.g. NAS-Identifier)? One way to transport the single round-trip exchange is as a series of Diameter AVPs formatted and encapsulated in EAP methods per [I-D.clancy-emu-aaapay]. For each lower layer, this document defines the parameters of interest, and the appropriate Diameter AVPs for transporting them. Additionally, guidance on how to perform consistency checks on those values will be provided.[BA] One potential complicating factor will be RADIUS extended attributes. These will be encoded as Diameter vendor-specific AVPs, potentially with grouping. It might make sense to explicitly state that attributes useful for Channel Bindings should probably be allocated in the standard RADIUS space, to avoid this potential "gotcha". It also might be useful to state how the comparison is to be done (e.g. ignore Diameter AVP 'M' bit). Section 7.1 The client SHOULD transmit to the server the following fields, encapsulated within the appropriate Diameter AVP: SSID BSSID RSN IE (if present) The server MAY send the Cost-Information AVP from the Diameter Credit-Control Application [RFC4006] to the peer indicating how much peers will be billed for service. [BA] There is currently no AAA attribute for sending the SSID by itself, only the combination BSSID/SSID (e.g. Called-Station-Id). The RSN IE currently isn't carried either. You might want to review draft-aboba-radext-wlan-08.txt for a list of the new attributes that are being proposed for usage with various IEEE 802 media (including IEEE 802.11, 802.16, 802.1X-REV, etc.). Having the server send the Cost-Information AVP is an interesting idea. However, is this information 802.11-specific or might it be useful in many media? Section 9 The EAP peer will need an API between the EAP lower layer and the EAP method that exposes the necessary information from the NAS to be validated to the EAP peer, which can then feed that information into the EAP methods for transport. For example, an IEEE 802.11 system would need to make available the various information elements that require validation to the EAP peer which would properly format them and pass them to the EAP method. Additionally, the EAP peer will require updated EAP methods that support transporting channel binding information. While most method documents are written modularly to allow incorporating arbirary protected information, implementations of those methods would need to be revised to support these extensions. [BA] The issue is not just about modification of the EAP lower layer -- in many cases, drivers will need to be changed as well to provide the required information, and in the interim before this happens, there may be cased where an EAP method that is Channel-Binding capable will not be able to obtain channel binding information. Overall, I'd suggest that a section be added laying out the cost/benefit analysis. Although multiple vendors have attempted to implement Channel Bindings, to my knowledge none of those implementations have shipped, because the cost are easy to identify (and are high) and the benefits are more difficult to get a handle on (and are less amenable to quantification). Additionally, an interface is necessary for populating the EAP server database with the appropriate parameters. In the enterprise case, when a NAS is provisioned, information about what it should be advertising to peers needs to be entered into the database. In the service provider case, there should be a mechanism for entering contractual information about roaming partners. [BA] Do we really expect operators to enter in all potential AAA parameters into the database? This seems like a substantial operational burden. Instead, I'd suggest that for some parameters, auto-registration might be helpful -- allowing the database to be populated based on the AAA attributes first obtained from the NAS when it is provisioned. While this trusts that the NAS isn't sent to the operator in a compromised state, but only becomes compromised later, it would ease the operational burden. EMAILING FOR THE GREATER GOODJoin me
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
- [Emu] Review of draft-clancy-emu-chbind-02.txt Bernard Aboba
- Re: [Emu] Review of draft-clancy-emu-chbind-02.txt Stefan Winter
- Re: [Emu] Review of draft-clancy-emu-chbind-02.txt Charles Clancy
- [Emu] Review of draft-clancy-emu-chbind-03.txt Bernard Aboba