Network Working Group T. Clancy Internet-Draft LTS Intended status: Standards Track K. Hoeper Expires: August 21, 2008 NIST February 18, 2008 Channel Binding Support for EAP Methods draft-clancy-emu-chbind-00 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 August 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods. Clancy & Hoeper Expires August 21, 2008 [Page 1] Internet-Draft EAP-CHBIND February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Example Attacks . . . . . . . . . . . . . . . . . . . . . . . 6 6. Recommendations for Lower-Layer Bindings . . . . . . . . . . . 7 6.1. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. IEEE 802.16 . . . . . . . . . . . . . . . . . . . . . . . 7 6.3. Internet Key Exchange v2 (IKEv2) . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Clancy & Hoeper Expires August 21, 2008 [Page 2] Internet-Draft EAP-CHBIND February 2008 1. Introduction A well-documented problem with the current Extensible Authentication Protocol (EAP) architecture [RFC3748] when used in pass-through authenticator mode is the so-called "lying NAS" problem. Here, a Network Access Server (NAS), or pass-through authenticator, may authenticate to the backend AAA infrastructure using one set of credentials, 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 need advertise the same identity to clients. In fact, it may include whatever information in its beacons (to include different SSID or security properties) it desires. This could lead to situations where, for example, a client joins one network that's masquerading as another. In this document, we utilize "AAA Payloads" [I-D.clancy-emu-aaapay] to transport key channel binding characteristics from the client to the server, allowing the server to verify the authenticator has advertised 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. 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. Overview In a [RFC4017] and [RFC4962]-compliant EAP authentication, the EAP client and EAP server mutually authenticate each other, and derive keying material. When operating in pass-through mode, the EAP server then transports the resulting Master Session Key (MSK) to the authenticator. However, just because a security association exists between the client and server, and between the server and authenticator, doesn't mean the authenticator can't provide false information to the client. Channel bindings [RFC5056] seek to enforce a stronger security Clancy & Hoeper Expires August 21, 2008 [Page 3] Internet-Draft EAP-CHBIND February 2008 relationship between the three entities, by allowing the client and server to compare their relative perception of the authenticator's identity in a secure channel. This document defines how to use "AAA Payloads" [I-D.clancy-emu-aaapay] within EAP methods to implement channel bindings. Unlike [RFC5056], channel binding in EAP context does not ensure binding different layers of a session but rather the information advertized to client and authentication server by an authenticator acting as pass-through device during an EAP session. It is preferable to use this idea, rather than hashing identity information directly into keys, for a number of reasons: o It allows for fuzzy comparisons of entity names, rather than requiring absolute. This can facilitate deployment and debugging. o Any EAP method that provides mutual authentication and key derivation can easily add channel binding as proposed in this draft. On the other hand, including identities into key derivations requires the modification of EAP methods. For instance, many EAP methods specify how MSK and other keying material is derived and adding channel binding by adding identifiers would need to be specified for each method individually. o Client and authentication server may communicate on different layers with the authenticator and thus receive different identifiers that may belong to the same device. A server may be able to recognize which different identifiers belong to the same device (e.g. by performing a table look up). This scenario cannot be solved by hashing identities into keys. 4. Trust Model Channel bindings are always provided between two communication endpoints, i.e. here between client and server, who communicate through an authenticator in pass-trough mode (as illustrated in Figure 1). Channel binding prevents attacks by rogue authenticators in pass-trough mode (see Example Attacks). Clancy & Hoeper Expires August 21, 2008 [Page 4] Internet-Draft EAP-CHBIND February 2008 --------------------------------------------- -------- info1 | ------------- info2 ----------- | |EAP peer| <--------| |Authenticator| ----------> |Auth.Server| | -------- | ------------- ----------- | | | | | | | Home Domain | | | --------------------------------------------- | | | | | Channel binding | |<---------------------------------------------------->| Figure 1: Overview of Channel Binding During an EAP execution, an authenticator presents information info1 and info2 to client and server, respectively. Such information can include the authenticator's identifier/address and/or advertised network information (such as offered services and billing information). To prevent attacks by rogue authenticators, the server must be able to recognize any inconsistencies in info1 and info2. Therefore, the client sends info1 to the server and upon performing an inconsistency check, the server notifies the client about the result. Only in case of a positive result, channel binding is provided and the EAP session continues. Note that under some circumstances, the client could be able to check for inconsistencies; however the check is generally easier to implement on the server. The trust model for channel binding consists of three parties, namely a client, an authentication server and an authenticator in pass- through mode as illustrated in Figure 1. In this trust model, client and authentication server are honest while the authenticator is maliciously sending false information to client and/or server. The three parties have the following 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 (i.e. info1) o The client trusts the channel binding result received from the server o The server trusts the identifier received from the authenticator Note that the model includes all cases in which authenticator and authentication server communicate over one or more intermediate nodes as long as 1) these nodes only forward the messages (e.g. routers) and 2) authenticator and server communicate using an end-to-end protocol (e.g. AAA). However, roaming scenarios with proxies are out of the scope of this document. Clancy & Hoeper Expires August 21, 2008 [Page 5] Internet-Draft EAP-CHBIND February 2008 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 info1 from client to server over an integrity-protected channel o sending the result and optionally info2 from server to client over an integrity-protected channel Not all requirements for enabling channel binding capabilities can be achieved by EAP [HC07]. Such requirements are outside the scope of channel binding as described in this document. The following discussion points out the prerequisites any system implementing EAP methods with channel binding MUST provide. For example, the third trust relationship cannot be achieved by EAP methods. The server MUST share an authentic channel with the authenticator, e.g. using an AAA protocol. This is necessary for the server to be able to authenticate the authenticator. Otherwise, the server cannot verify the received identifier/address as part of info2 and thus an authenticator sending false but identical information to client and server would remain undetected. Furthermore, the server's capability of checking inconsistencies of provided information might not be achievable by EAP and states another necessary system prerequisite. Once the server verified the validity of info2, it MUST verify whether the provided information is consistent with the information in info1. While comparing provided service information as part of info1 and info2 is simple, comparing the provided identifiers/addresses is not always that straightforward. The authenticator communicates on different protocol layers with client and server and thus may provide different identifiers/addresses to both parties. For instance, an IEEE 802.11 access point could be identified by a BSSID, an IPv4 address (e.g., NAS-IP- Address), or a domain name (e.g., NAS-Identifier). Other identifiers, such as SSID, do not necessarily identify a single authenticator, but may be of interest to a client. Hence, the server MUST be capable to verify whether both identifiers/addresses belong to the same entity. 5. Example Attacks Section TBD. Clancy & Hoeper Expires August 21, 2008 [Page 6] Internet-Draft EAP-CHBIND February 2008 6. Recommendations for Lower-Layer Bindings This section discusses bindings to EAP lower layers, and what would be appropriate AVPs to transport to the server. We only define bindings for protocols with secure association protocols. Protocols without secure association do not derive session keys to protect data, and as such, channel bindings can do little to improve their link security. (Note: is this true??? Do we need to include PPP, 1X, etc???) Only if such keys exist, implementing channel binding as described in this draft is useful because all information exchanged between client and authentication server used for channel binding must be integrity-protected. 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. [Need to describe validation process ... TBD] 6.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) If the recieved information in 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 MAY respond back to the client with a information encapsulated in AVPs that may be of use to the client, and information the client may not have any way of otherwise knowing. For example, the Cost-Information AVP from the Diameter Credit-Control Application [RFC4006] may be useful in telling the client how much they will be billed for service. 6.2. IEEE 802.16 TBD 6.3. Internet Key Exchange v2 (IKEv2) TBD Clancy & Hoeper Expires August 21, 2008 [Page 7] Internet-Draft EAP-CHBIND February 2008 7. Security Considerations TBD 8. IANA Considerations This document contains no IANA considerations. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 9.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-00, December 2007. [HC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", ICST QShine, August 2007. [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. Clancy & Hoeper Expires August 21, 2008 [Page 8] Internet-Draft EAP-CHBIND February 2008 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007. Authors' Addresses T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmead Drive College Park, MD 20740 USA Email: clancy@ltsnet.net 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 August 21, 2008 [Page 9] Internet-Draft EAP-CHBIND February 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Clancy & Hoeper Expires August 21, 2008 [Page 10]