EAP Working Group Y. Ohba Internet-Draft Toshiba Expires: July 5, 2006 M. Parthasarathy Nokia M. Yanagiya NTT Jan 2006 Channel Binding Mechanism based on Parameter Binding in Key Derivation draft-ohba-eap-channel-binding-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 July 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a channel binding mechanism based on parameter binding in the key derivation procedure. The method cryptographically binds service information to a key without need to carry the service information in EAP methods. Ohba, et al. Expires July 5, 2006 [Page 1] Internet-Draft Channel Binding Mechanism Jan 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Channel Binding Mechanism . . . . . . . . . . . . . . . 7 3.1. Key Derivation Function . . . . . . . . . . . . . . . . . 7 3.2. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Key Name . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Key Caching . . . . . . . . . . . . . . . . . . . . . . . 8 4. Channel Binding Mechanism Variants . . . . . . . . . . . . . . 9 4.1. Multiple CBKs . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Transferring CBMK . . . . . . . . . . . . . . . . . . . . 9 4.3. Hierarchical Channel Binding . . . . . . . . . . . . . . . 9 5. EAP Authenticator Consideration . . . . . . . . . . . . . . . 10 6. Authenticator-Supplicant Protocol Requirements . . . . . . . . 11 7. EAP Method Requirements . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Ohba, et al. Expires July 5, 2006 [Page 2] Internet-Draft Channel Binding Mechanism Jan 2006 1. Introduction EAP (Extensible Authentication Protocol) is an authentication framework which supports multiple authentication algorithms known as "EAP methods" [RFC3748]. In the framework, an EAP peer and an EAP authenticator use a key generated and exported by an EAP method to bootstrap ciphersuites used for protecting their access network. This key is referred to as MSK (Master Session Key). A framework for the generation, transport and usage of MSK is described in [I-D.ietf- eap-keying]. Each access network has its own set of parameters advertised by the EAP authenticator to EAP peers. The identity of the EAP authenticator is one of such parameters. Such parameters are referred to as service information. The service information should be bound to the MSK in a secure way to avoid possible security flaws. A mechanism that is described in [RFC3748] to create such a binding is based on communicating the service information over a protected channel of an EAP method to help the EAP peer and the authentication server detect a mismatch between the service information exchanged over the protected channel and the one advertised by the EAP authenticator to the EAP peer and the authentication server. In any Channel binding solution the authentication server should be able to authenticate the service information provided by the EAP authenticator. It is not sufficient if it just ensures that the same information is available at both the EAP peer and authentication server. The EAP authenticator can provide the same false information to both the EAP peer and authentication server. So, the authentication server needs to be configured with the service information of the EAP authenticators (out-of band) for authenticating the service information. As the service information needs to be explicitly configured on the server, there is not much use for the peer to explicitly send it through the EAP method as specified in [RFC3748]. On the other hand, in roaming situations, this becomes difficult if there is no direct trust relationship with the visited network. In that case, an intermediary should be able to authenticate the service information on behalf of the authentication server. This document describes an alternative Channel Binding mechanism to create a binding between a key exported by EAP method and the service information. The mechanism has the following characteristics: o The mechanism retains EAP invariants, i.e., mode independence, media independence, method independence and ciphersuite Ohba, et al. Expires July 5, 2006 [Page 3] Internet-Draft Channel Binding Mechanism Jan 2006 independence. o The mechanism does not necessarily require any change to existing EAP authenticators. o The mechanism is scalable to support a large number of EAP authenticators. 1.1. Specification of Requirements 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]. Ohba, et al. Expires July 5, 2006 [Page 4] Internet-Draft Channel Binding Mechanism Jan 2006 2. Terminology Channel Binding Key (CBK) A key that is derived from a Channel Binding Master Key (CBMK) and cryptographically bound to a Key Binding Blob (KBB) using a Key Derivation Function (KDF). A CBK is at lest 64 octets in length. Channel Binding Master Key (CBMK) A key from which a CBK is derived using a KDF. An MSK or an EMSK is a CBMK. A CBMK is at lest 64 octets in length. Key Binding Blob (KBB) An octet-string that is constructed from the service information advertised by an authenticator using an Authenticator-Supplicant Protocol (ASP). Key Derivation Function (KDF) A function by which a CBK is generated using a CBMK and a KBB as input. Server An entity that creates a CBK and transfers it to the authenticator. An EAP server is a server of this mechanism. Authenticator A network-side entity that uses a CBK for an Authenticator- Supplicant Protocol (SAP). An authenticator may or may not be co- located with the server in the same equipment. An EAP authenticator is an authenticator of this mechanism. Supplicant A user-side entity that uses a CBK for an Authenticator-Supplicant Protocol (SAP). An EAP peer is a supplicant of this mechanism. Authenticator-Supplicant Protocol (ASP) A protocol that is executed between an supplicant and an authenticator and uses a CBK for binding an authenticated identity to the protocol. The supplicant obtains the service information from the authenticator using the ASP where the service information is used for constructing a KBB. The specification of the ASP Ohba, et al. Expires July 5, 2006 [Page 5] Internet-Draft Channel Binding Mechanism Jan 2006 defines how to construct a KBB from the service information. The notion of ASP is broader than Secure Association Protocol (SAP) [I-D.ietf-eap-keying] in that an ASP is used not only for secure association but also for advertising the service information. IKEv2, PANA, IEEE 802.11i, IEEE 802.11r and IEEE 802.16e are ASPs. Ohba, et al. Expires July 5, 2006 [Page 6] Internet-Draft Channel Binding Mechanism Jan 2006 3. Basic Channel Binding Mechanism The basic channel binding mechanism is described as follows (see Figure 1. +------------+ +-------------+ +--------------+ | Server | |Authenticator| | Supplicant | | | | | | | | | | | | KBB | | KBB CBMK | | | | +---+ CBMK | | | | | | | | | | | | | v v | | | | | v v | | +-----+ | | | | | +-----+ | | | KDF |(1)| | | | | | KDF |(1)| | +-----+ | | | | | +-----+ | | | | | | | \ | | | | | | | | \ v CBK | | | CBK | (2) | +----+ | (3) | +----+ | | +---------------->|ASPI|<------------->|ASPI| | | | | +----+ | | +----+ | +------------+ +-------------+ +--------------+ ASPI: Instance of ASP Figure 1: Basic Channel Binding Mechanism 1. CBK Creation: A server and supplicant creates a CBK used for an authenticator. The CBK is derived from a CBMK and bound to a KBB associated with the authenticator using a KDF. The KBB is pre- configured on the server. 2. CBK Tranfser: The server transfers the CBK to the authenticator. 3. CBK Verification: The supplicant and authenticator verifies proof of possession of the CBK over the ASP. After successful verification of proof of possession of the CBK, the supplicant and authenticator are able to use the CBK in the ASP. 3.1. Key Derivation Function A CBK is computed using prf+ defined in IKEv2 [RFC4306] in the following way. CBK = prf+(CBMK, KBB) 3.2. Key Scope The scope of a CBK MUST be within the pair of the supplicant and Ohba, et al. Expires July 5, 2006 [Page 7] Internet-Draft Channel Binding Mechanism Jan 2006 authenticator that use the CBK. 3.3. Key Name The name of a CBK is the string concatenation of the name of the CBMK and "CBK". 3.4. Key Lifetime The lifetime of a CBK is determined based on the guidelines on exported and calculated key lifetimes described in [I-D.ietf-eap- keying]. 3.5. Key Caching Where explicitly supported by the ASP, the ASP MAY cache a CBK. Ohba, et al. Expires July 5, 2006 [Page 8] Internet-Draft Channel Binding Mechanism Jan 2006 4. Channel Binding Mechanism Variants 4.1. Multiple CBKs In this scenario, a server creates multiple CBKs from a single CBMK for multiple authenticators by using different KBBs for different authenticators. 4.2. Transferring CBMK An entity that owns a CBMK MAY transfer the ownership of the CBMK to a trusted entity by transferring the CBMK to that entity. The recipient or the new owner of the CBMK MAY then act as the server on behalf of the previous owner or further transfer the ownership to another trusted entity. 4.3. Hierarchical Channel Binding This channel binding mechanism allows CBKs to form a hierarchy (see Figure 2). As the service information needs to be explicitly configured for each authenticator at the server, it may become cumbersome to support large number of authenticators. The hierarchical Channel Binding mechanism helps solve the scalability problems when such large number of authenticators are present in a single visited network domain. CBMK0 / .. \ / \ CBK0_1 CBK0_n (=CBMK1_1) (=CBMK1_n) / .. \ / .. \ / \ / \ .. .. .. .. Figure 2: Hierarchical Channel Binding In hierarchical Channel Binding, CBK verification may be performed at each level of the key hierarchy or only at the lowest level of the hierarchy. In the latter case, the lowest level authenticator MUST advertise, in the lowest level ASP, the service information necessary to construct a KBB at each level of the hierarchy. Ohba, et al. Expires July 5, 2006 [Page 9] Internet-Draft Channel Binding Mechanism Jan 2006 5. EAP Authenticator Consideration When this mechanism is used, an EAP authenticator will receive and process a CBK as if it were an MSK. This enables the mechanism to work with the already deployed EAP authenticators without any modifications to them. Ohba, et al. Expires July 5, 2006 [Page 10] Internet-Draft Channel Binding Mechanism Jan 2006 6. Authenticator-Supplicant Protocol Requirements Any ASP that claims to support this mechanism MUST define how a KBB is constructed from the service information specific to the ASP where the KBB construction mechanism MUST satisfy all of the following requirements: o Only static service information such as the identity of the authenticator is used for constructing KBBs. o Probability of KBB collision in which the same KBB is associated with different authenticators of the ASP is either zero or reasonably low. A KBB collision may occur (i) when the KBB is computed as a hash of the service information or (ii) if the authenticators use different ASPs among which uniqueness of KBB is not guaranteed. A KBB collision may lead to domino effect [I-D.housley-aaa-key-mgmt] among authenticators associated with the collided KBB. Ohba, et al. Expires July 5, 2006 [Page 11] Internet-Draft Channel Binding Mechanism Jan 2006 7. EAP Method Requirements Any EAP method that claims to support the mechanism descried in this document MUST provide at least all of the following functionalities. 1. Negotiation on enabling this mechanism. The EAP method MUST support the following negotiation over a protected channel. * A functionality for the EAP peer to indicate the EAP server the desire to use this mechanism. * A functionality to enable this mechanism when the EAP peer indicated the desire to use this mechanism and the EAP server implements this mechanism. * A functionality to disable this mechanism when the EAP peer did not indicate the desire to use this mechanism. * A functionality to fail the EAP method conversation when the EAP peer indicated the desire to use this mechanism while the EAP server does not implement this mechanism. 2. Negotiation on or specification of a hash algorithm. The EAP method MUST either provide, over a protected channel, a mechanism for negotiating on a hash algorithm used for prf+, or specify one hash algorithm used for prf+. Ohba, et al. Expires July 5, 2006 [Page 12] Internet-Draft Channel Binding Mechanism Jan 2006 8. Security Considerations The mechanism described in this document improves the security characteristics of the EAP key management framework in the following aspects. o A secure association can never be established via the ASP if there is a difference in the KBB advertised by the EAP authenticator to the EAP peer and the KBB configured on the EAP server. o Even if a CBK is somehow transferred to an authenticator other than the intended one, the CBK can never be used by the non- intended authenticator as long as the KBB used for deriving the CBK does not collide between the intended and unintended authenticators. The security level of this mechanism depends on probability of KBB collision among authenticators of the same ASP and among authenticators of different ASPs. Ohba, et al. Expires July 5, 2006 [Page 13] Internet-Draft Channel Binding Mechanism Jan 2006 9. IANA Considerations This document has no actions for IANA. Ohba, et al. Expires July 5, 2006 [Page 14] Internet-Draft Channel Binding Mechanism Jan 2006 10. Acknowledgments TBD. Ohba, et al. Expires July 5, 2006 [Page 15] Internet-Draft Channel Binding Mechanism Jan 2006 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. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-09 (work in progress), January 2006. 11.2. Informative References [I-D.housley-aaa-key-mgmt] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-01 (work in progress), November 2005. Ohba, et al. Expires July 5, 2006 [Page 16] Internet-Draft Channel Binding Mechanism Jan 2006 Authors' Addresses Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway, NJ 08854 USA Phone: +1 732 699 5365 Email: yohba@tari.toshiba.com Mohan Parthasarathy 313 Fairchild Drive Mountain View CA 94043 USA Email: mohan.parthasarathy@nokia.com Mayumi Yanagiya NTT Network service systems laboratories, NTT Corporation 9-11, Midori-Cho, 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Email: yanagiya.mayumi@lab.ntt.co.jp Ohba, et al. Expires July 5, 2006 [Page 17] Internet-Draft Channel Binding Mechanism Jan 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ohba, et al. Expires July 5, 2006 [Page 18]