Network Working Group T. Clancy Internet-Draft LTS Intended status: Standards Track K. Hoeper Expires: February 1, 2009 NIST July 31, 2008 Channel Binding Support for EAP Methods draft-clancy-emu-chbind-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 1, 2009. Abstract This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS problem. Clancy & Hoeper Expires February 1, 2009 [Page 1] Internet-Draft EAP-CHBIND July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 5 5. Channel Binding Protocol . . . . . . . . . . . . . . . . . . . 6 6. System Requirements . . . . . . . . . . . . . . . . . . . . . 8 7. Lower-Layer Bindings . . . . . . . . . . . . . . . . . . . . . 8 7.1. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. IEEE 802.16 . . . . . . . . . . . . . . . . . . . . . . . 9 7.3. Wired 802.1X . . . . . . . . . . . . . . . . . . . . . . . 9 7.4. Point to Point Protocol (PPP) . . . . . . . . . . . . . . 9 7.5. Internet Key Exchange v2 (IKEv2) . . . . . . . . . . . . . 10 7.6. 3GPP2 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.7. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 10 8.2. Consequences of Trust Violation . . . . . . . . . . . . . 10 9. Operations and Management Considerations . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Clancy & Hoeper Expires February 1, 2009 [Page 2] Internet-Draft EAP-CHBIND July 2008 1. Introduction 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. A concrete example of this may be an IEEE 802.11 access point with a security association to a particular AAA server. While there may be some identity tied to that security association, there's no reason the access point needs to advertise the same identity to clients. In fact, it may include whatever information in its beacons (e.g. different SSID or security properties) it desires. This could lead to situations where, for example, a client joins one network that is masquerading as another. This document uses a process in which the EAP client provides information about the characteristics of the service provided by the authenticator to the AAA server protected within the EAP method, allowing the server to verify the authenticator is providing valid information to the peer. The server can also respond back with additional information that could be useful for the client to decide whether or not to continue its session with the authenticator. "AAA Payloads" defined in [I-D.clancy-emu-aaapay] proposes a mechanism to carry this information. 2. Terminology In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Problem Statement In a [RFC4017] and [RFC4962]-compliant EAP authentication, the EAP client and EAP server mutually authenticate each other, and derive keying material. However, when operating in pass-through mode, the EAP server can be far removed from the authenticator. A malicious or compromised authenticator may represent incorrect information about the network to the client in an effort to affect its operation in Clancy & Hoeper Expires February 1, 2009 [Page 3] Internet-Draft EAP-CHBIND July 2008 some way. Additionally, while an authenticator may not be compromised, other compromised elements in the network could provide false information to the authenticator that it could simply be relaying to EAP clients. Our goal is to ensure that the authenticator is providing correct information to the EAP client during the initial network discovery, selection, and authentication. 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. The following are a couple example attacks possible by presenting false network information to clients. o Enterprise Network: A corporate network may have multiple virtual LANs (VLANs) running throughout their campus network, and have IEEE 802.11 access points connected to each VLAN. Assume one VLAN connects users to the firewalled corporate network, while the other connects users to a public guest network. The corporate network is assumed to be free of adversarial elements, while the guest network is assumed to possibly have malicious elements. Access Points on both VLANs are serviced by the same EAP server, but broadcast different SSIDs to differentiate. A compromised access point connected to the guest network could advertise the SSID of the corporate network in an effort to lure clients to connect to a network with a false sense of security regarding their traffic. 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. To address these problems, a mechanism is required to validate unauthenticated information advertised by EAP authenticators. Clancy & Hoeper Expires February 1, 2009 [Page 4] Internet-Draft EAP-CHBIND July 2008 4. Channel Bindings EAP channel bindings seek to authenticate previously unauthenticated information provided by the authenticator to the EAP peer, by allowing the client and server to compare their perception of network properties in a secure channel. It should be noted that the definition of EAP channel bindings differs somewhat from channel bindings documented in [RFC5056], which seek to securely bind together the end points of a multi-layer protocol, allowing lower layers to protect data from higher layers. Unlike [RFC5056], EAP channel bindings do not ensure the binding different layers of a session but rather the information advertised to EAP client by an authenticator acting as pass-through device during an EAP session. There are two main approaches to EAP channel bindings: o After keys have been derived during an EAP authentication, the peer and server can, in an integrity-protected channel, exchange plaintext information about the network with each other, and verify consistency and correctness. o Network information can be uniquely encoded into an opaque blob that can be included directly in to the derivation of the EAP session keys. Both approaches have advantages and disadvantages. Advantages of exchanging plaintext information include: 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. o EAP methods that support extensible, integrity-protected channels can easily include support for exchanging this network information. Direct inclusion into the key derivation would require revisions to existing EAP methods or a wrapper EAP method. 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. The following are advantages of directly including channel binding information in the key derivation: Clancy & Hoeper Expires February 1, 2009 [Page 5] Internet-Draft EAP-CHBIND July 2008 o EAP methods not supporting extensible, integrity-protected channels could still be supported, either by revising their key derivation, revising EAP, or wrapping them in a universal method that supports channel binding. o It can guarantee proper channel information, since subsequent communication would be impossible if differences in channel information yielded different session keys on the EAP client and server. 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. Also, a peer's expectations of a network may also differ. In a mobile phone network, peers generally don't care what the name of the network is, as long as they can make their phone call and are charged the expected amount for the call. However, in an enterprise network a peer may be more concerned with specifics of where their network traffic is being routed. Any deployment of channel bindings should take into consideration both what knowledge the EAP server is likely to know, and also what type of network information the peer would want and need authenticated. 5. Channel Binding Protocol This section defines a protocol for verifying channel binding information during an EAP authentication. The protocol uses the approach where plaintext data is exchanged, since it allows channel bindings to be used more flexibly in varied deployment models. Clancy & Hoeper Expires February 1, 2009 [Page 6] Internet-Draft EAP-CHBIND July 2008 --- -------- ------------- / \ ---------- |EAP peer|<---->|Authenticator|<-->( AAA )<-->|EAP Server| -------- ------------- \ / ---------- . i1 . --- . | ______ .<-----------------. . | (______) . . i1 . \--| | .--------------------------------------------->. | DB | . isConsistant(i1, i2), [i2] . | i2 | .<---------------------------------------------. (______) Figure 1: Overview of Channel Binding 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. 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). 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. The protocol defined in this document is a single round trip between the EAP peer and server, and formats data elements as Diameter AVPs. We provide requirements for a transport protocol. Clancy & Hoeper Expires February 1, 2009 [Page 7] Internet-Draft EAP-CHBIND July 2008 6. System Requirements The channel binding protocol defined in this document must be transported after keying material has been derived between the EAP peer and server, and before the peer would suffer adverse affects from joining an adversarial network. To satisfy this requirement, it should occur either during the EAP method execution or during the EAP lower layer's secure association protocol. The transport protocol for carrying channel binding information MUST support end-to-end (i.e. between the EAP peer and server) message integrity protection to prevent the adversarial NAS or AAA device from manipulating the transported data. The transport protocol SHOULD provide confidentiality. The motivation for this that the channel bindings could contain private information, including peer identities, which SHOULD be protected. If transporting data directly within an EAP method, it MUST be able to carry integrity protected data from the EAP peer to server. EAP methods SHOULD provide a mechanism to carry protected data from server to peer. EAP methods MUST export channel binding data to the AAA subsystem on the EAP server. EAP methods MUST be able to import channel binding data from the lower layer on the EAP peer. The AAA subsystem MUST be able to process channel binding data returned from the EAP method. It must be possible to pass the channel binding data in AAA attributes to proxy AAA if a proxy AAA will need to evaluate the data. 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. 7. Lower-Layer Bindings This section discusses AVPs of some EAP-employing lower layer link protocols that seem appropriate for providing channel bindings. The discussion is limited to protocols that establish fresh authentic keying material because such keying material is necessary to protect the integrity of all AVPs that are exchanged as part of the channel binding. For each protocol, a variety of network information that can be encapsulated in AVPs is of interest for server and peer to ensure channel binding. The respective appropriate AVPs depend on the lower layer protocol as well as on the network type (i.e. Clancy & Hoeper Expires February 1, 2009 [Page 8] Internet-Draft EAP-CHBIND July 2008 enterprise network or service provider network) of an application. For each EAP lower layer, a variety of AAA properties may be of interest to the server. These values may already be known by the server, or may be transported to the server via an existing RADIUS or Diameter connection. As part of the channel binding protocol, the EAP peer sends encapsulated AVPs to the server. The server then validates the received information by comparing it to information stored in a local database. If the received information is unsatisfactory given some validation policy, the server SHOULD respond by halting the EAP authentication and returning an EAP-Failure. If validation is successful, the server SHOULD send a message indicating the success to the client. In addition, the server MAY respond back to the EAP peer with information encapsulated in AVPs that can be of use to the peer, and information the peer may not have any way of otherwise knowing. 7.1. IEEE 802.11 The client SHOULD transmit to the server the following fields, encapsulated within the appropriate Diameter AVPs: 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. 7.2. IEEE 802.16 TBD 7.3. Wired 802.1X TBD 7.4. Point to Point Protocol (PPP) TBD Clancy & Hoeper Expires February 1, 2009 [Page 9] Internet-Draft EAP-CHBIND July 2008 7.5. Internet Key Exchange v2 (IKEv2) TBD 7.6. 3GPP2 TBD 7.7. PANA TBD 8. Security Considerations 8.1. Trust Model We consider a trust model in which the peer and server trust each other. This is not unreasonable, considering they already have a trust relationship. In this trust model, client and authentication server are honest while the authenticator is maliciously sending false information to client and/or server. The following are the trust relationships: o The server trusts that the channel binding information received from the client is the information that the client received from the authenticator. o The client trusts the channel binding result received from the server. o The server trusts the information contained within its local database. In order to establish the first two trust relationships during an EAP execution, an EAP method MUST provide the following: o mutual authentication between client and server o derivation of keying material including a key for integrity protection of channel binding messages o sending i1 from client to server over an integrity-protected channel o sending the result and optionally i2 from server to client over an integrity-protected channel 8.2. Consequences of Trust Violation If any of the trust relationships listed in Section 7.1 are violated, channel binding cannot be provided. In other words, if mutual authentication with key establishment as part of the EAP method as Clancy & Hoeper Expires February 1, 2009 [Page 10] Internet-Draft EAP-CHBIND July 2008 well as protected database access are not provided, then achieving channel binding is not feasible. Dishonest peers can only manipulate the first message i1 of the channel binding protocol. In this scenario, a peer sends i1' to the server. If i1' is invalid, the channel binding validation will fail and the server will abort the EAP authentication. On the other hand if i1' passes the validation, either the original i1 was wrong and i1' corrected the problem or both i1 and i1' constitute valid information. All cases do not seem to be of any benefit to a peer and do no pose a security risk. Dishonest servers can send EAP-Failure messages and abort the EAP authentication even if the received i1 is valid. However, servers can always abort any EAP session independent of whether channel binding is offered or not. On the other hand, dishonest servers can claim a successful validation even for an invalid i1. This can be seen as collaboration of authenticator and server. Channel binding can neither prevent nor detect such attacks. In general such attacks cannot be prevented by cryptographic means and should be addressed using policies making servers liable for their provided information and services. Additional network entities (such as proxies) might be on the communication path between peer and server and may attempt to manipulate the channel binding protocol. If these entities do not possess the keying material used for integrity protection of the channel binding messages, the same threat analysis applies as for the dishonest authenticators. Hence, such entities can neither manipulate single channel binding messages nor the outcome. On the other hand, entities with access to the keying material must be treated like a server in a threat analysis. Hence such entities are able to manipulate the channel binding protocol without being detected. However, the required knowledge of keying material is unlikely since channel binding is executed before the EAP method is completed, and thus before keying material is typically transported to other entities. 9. Operations and Management Considerations As with any extension to existing protocols, there will be an impact on existing systems. Typically the goal is to develop an extension that minimizes the impact on both development and deployment of the new system, subject to the system requirements. In this section we discuss the impact on existing devices that currently utilize EAP, assuming the channel binding information is transported within the EAP method execution. Clancy & Hoeper Expires February 1, 2009 [Page 11] Internet-Draft EAP-CHBIND July 2008 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. No changes to the pass-through authenticator would be required. The EAP server would need an API between the database storing NAS information and the individual EAP server. The EAP methods need to be able to export received channel binding information to the EAP server so it can be validated. 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. Channel binding validation can also be implemented incrementally. An initial database may be empty, and all channel bindings are automatically approved. Operators can then incrementally add parameters to the database regarding specific authenticators or groups of authenticators that must be validated. Additionally, a network could also self-form this database by putting the network into a "learning" mode, and could then recognize inconsistencies in the future. 10. IANA Considerations This document contains no IANA considerations. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Clancy & Hoeper Expires February 1, 2009 [Page 12] Internet-Draft EAP-CHBIND July 2008 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 11.2. Informative References [I-D.ietf-eap-keying] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-22 (work in progress), November 2007. [I-D.clancy-emu-aaapay] Clancy, T., "EAP Method Support for Transporting AAA Payloads", Internet Draft draft-clancy-emu-aaapay-01, July 2008. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005. [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007. [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007. [HC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", ICST QShine, August 2007. Authors' Addresses T. Charles Clancy Laboratory for Telecommunications Sciences US Department of Defense College Park, MD USA Email: clancy@ltsnet.net Clancy & Hoeper Expires February 1, 2009 [Page 13] Internet-Draft EAP-CHBIND July 2008 Katrin Hoeper National Institute of Standards and Technology 100 Bureau Drive, mail stop 8930 Gaithersburg, MD 20878 USA Email: khoeper@nist.gov Clancy & Hoeper Expires February 1, 2009 [Page 14] Internet-Draft EAP-CHBIND July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Clancy & Hoeper Expires February 1, 2009 [Page 15]