Network Working Group D. Harkins Internet-Draft Tropos Networks Expires: August 30, 2007 Y. Ohba Toshiba M. Nakhjiri Huawei February 26, 2007 Problem Statement and Requirements on a 3-Party Key Distribution Protocol for Handover Keying draft-ohba-hokey-3party-keydist-ps-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 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Harkins, et al. Expires August 30, 2007 [Page 1] Internet-Draft 3-Party Key Dist. Problem Statement February 2007 Abstract The HOKEY WG is developing solutions for optimizations as well as security key hierarchy specifications for handovers. The key derivation specifications all draw from a trust relationship that is created as a result of a "2-party" EAP authentication between a peer and a backend server, while distributing the resulting keys to third parties other than the peer and the backend server. This document describes problem statement and requirements on a three-party key distribution protocol for handover keyings. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Harkins, et al. Expires August 30, 2007 [Page 2] Internet-Draft 3-Party Key Dist. Problem Statement February 2007 1. Introduction The HOKEY (Handover Keying) WG is specifying solutions for secure handover optimization relating to EAP (Extensible Authentication Protocol) [RFC3748]. The optimization solutions under considerations can for instance be categorized based on timing: The authentication and key management may occur before handoff, or alternatively, authentication and key management can occur as part of the handoff. Furthermore, HOKEY is specifying key derivation mechanisms that can be applied to generic use cases. All of these key derviation mechanisms have one thing in common; from security standpoint, the solutions have one thing in common: they draw from a trust relationship that is created as a result of a "2-party" EAP authentication between a peer and a backend server. On the other hand, the key management solutions are distributing the resulting keys to the third parties other than the initial peer and the backend server. This means the key distribution mechanism and protocol, unlike the initial authentication, involves 3 parties. This document describes problem statement and requirements on such three-party key distribution protocols used for handover and other keying applications. 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]. Harkins, et al. Expires August 30, 2007 [Page 3] Internet-Draft 3-Party Key Dist. Problem Statement February 2007 2. Problem Statement Network access authentication and authorization services have been based on two-party trust model (long term credentials established between a backend AAA server and an end client) under the assumption that the access client and the authentication server (EAP/AAA server) mutually authenticate, using a two-party protocol. Initially a network point of presence (e.g. a dial up modem up) performed the role of authentication server end-client and thus this point of presence was denoted as Network Access Server (NAS). This was a truely two party protocol. Eventually authentication and authorization services were then extended to be more scalable by separating the authentication database from the NAS. In the extended model, credentials of access clients are moved from the NAS to a centralized authentication server and a AAA (Authentication, Authorization and Accounting) protocol is used for communication between the NAS and the authentication server. This extension was designed to be transparent to the access clients. Now the NAS and authentication server are no longer one. The network point of presence typically provides conditional connectivity to the end client while the client and the backend server perfrom the authentication. +-+-+-+-+ +-+-+-+-+-+ | | | | | EAP |------------------------------| EAP/AAA | | Peer | | Server | +-+-+-+-+ +-+-+-+-+ +-+-+-+-+-+ | NAS | +-+-+-+-+ Not a party in EAP authentication Figure 1: 2-party authentication between EAP peer and EAP server The NAS (Network Access Server) has no part in determining the result of the authentication and thus this transparency is frequently argued [GZ]: the original two-party trust model remains the same. That is, even though there are three distinct entities in this transaction the two-party trust model can still be used. When the EAP authentication framework is extended to also perform key management, the initial two parties (the peer and the EAP server) both calculate the so called Master Session Key (MSK) and Extended Master Session Key (EMSK) based on the recently acquired state resulting from a successful EAP authentication. However, given that the NAS had no part in the EAP authentication, it cannot generate the Harkins, et al. Expires August 30, 2007 [Page 4] Internet-Draft 3-Party Key Dist. Problem Statement February 2007 same keying material. On the other hand, the goal of the EAP keying framework is to bootstrap a security association for the peer connectivity to the network through the very same NAS. This means either of the two initial parties must transfer the keying material resulted from the EAP authentication to the NAS. Given the assumption that the NAS is a trusted part of the network controlled by the Authentication server, it is typically the authentication server that distributes the keying material resulted from the EAP authentication to the NAS. Thus the key distribution mechanism governing the network connectivity security bootstrapping is now a true 3-party mechanism. +-+-+-+-+ +-+-+-+-+-+ | | shared MSK, EMSK | | | EAP |------------------------------| EAP/AAA | | Peer |\ /| Server | +-+-+-+-+ \ / +-+-+-+-+-+ \--------+-+-+-+-+ ------/ | NAS | transported key +-+-+-+-+ Figure 2: 3-party key distribution involving the NAS Problems with using a two-party trust model on this transaction have been noted [RFC3748] and are generally referred to as a problem with "Channel Binding". Basically the access peer infers the identity of the authenticator but has no direct indication of the identity of the entity to whom the authentication server transmitted the keying material. In other words, in an unintended situation, when a NAS is impersonating another NAS, the peer and the authentication server may have two different view of the NAS identity. A comprehensive solution to this problem has not been attempted, though, since the fallout from an attack is contained. The key sent by the authentication server to the NAS-- the MSK (Master Session Key)-- will be the same whether the NAS impersonates another NAS or not [I-D.ietf-eap-keying]. A re-authentication between the access client and the authentication server (possibly as part a handoff from one NAS to another) can somewhat limit exposure of the problem, however, it does not solve the problem completely, since potentially the lying NAS can impersonate the new NAS as well. This although difficult from the access link side, can be easier from the network side, when for instance a compromised AAA proxy is on the path between both of the NASes and the authentication server, and can observe both the EAP signaling and the AAA signaling carrying the keying material. Handover keying involves transmission of other keying material in a protocol involving three parties-- the access peer, a HOKEY server Harkins, et al. Expires August 30, 2007 [Page 5] Internet-Draft 3-Party Key Dist. Problem Statement February 2007 and an authenticator to which a handover will be performed. In a roaming scenario, the three main parties are: the access peer, the HOKEY server in a home domain, and a HOKEY server in a visited domain. The problem seems to stem from the fact that the transferred keying material is not properly scoped and the key scope is not properly enforced. Keying material with a specific scope (intended parties to share the key) will be made available to another entity, and problems arise when the peer does not have a direct indication of the identity of that entity. An impersonation attack could result in keying material for one scope bound to one entity being delivered to another entity outside that scope. Obviously, the two-party trust model is not applicable to the handover keying case. Harkins, et al. Expires August 30, 2007 [Page 6] Internet-Draft 3-Party Key Dist. Problem Statement February 2007 3. Requirements Basic requirements on a 3-party key distribution protocol for handover keying is listed below. 1. Confidentiality -- disclosure of the keying material to passive and active attackers of the key distribution protocol MUST NOT be possible. 2. Integrity protection -- it MUST be possible to detect tampering of a network access credential. 3. Message authentication -- the recipient of a network access credential MUST be able to prove who it came from and for what context the credential was delivered. 4. Validation of authorization -- the scope (intended users) of the network access credential MUST be distributed as part of the credential and MUST be protected to the same degree as the credential itself. The context (life time, labels, intended usage, etc) of the network access credentials MUST be distributed as part of the credentials and MUST be protected to the same degree. 5. Resilience -- It MUST NOT be possible for an active attacker to consent of the client. 6. Peer consent -- Either the credential MUST NOT be distributed without the consent of the client or it MUST be unusable without the consent of the client. 7. Peer Entity Authentication -- Identities of the three parties involved MUST be confirmed by all three parties. 8. Agreement by all parties -- If the protocol successfully completes all three parties MUST agree on the keying material disclosed and the identity of the entity to whom the keying material was disclosed. Harkins, et al. Expires August 30, 2007 [Page 7] Internet-Draft 3-Party Key Dist. Problem Statement February 2007 4. Security Considerations This memo discusses basic requirements to secure the distribution of keying material in HOKEY. Security requirements are placed on the key distribution protocol itself and not on the transport used to distribute the keying material. A compliant implementation SHOULD be able to run over any transport. Harkins, et al. Expires August 30, 2007 [Page 8] Internet-Draft 3-Party Key Dist. Problem Statement February 2007 5. IANA Considerations There are no IANA related issues in this document. Harkins, et al. Expires August 30, 2007 [Page 9] Internet-Draft 3-Party Key Dist. Problem Statement February 2007 6. Acknowledgments Harkins, et al. Expires August 30, 2007 [Page 10] Internet-Draft 3-Party Key Dist. Problem Statement February 2007 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [GZ] Zorn, G., "Email communication on HOKEY mailing list", February 2007. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-18 (work in progress), February 2007. Harkins, et al. Expires August 30, 2007 [Page 11] Internet-Draft 3-Party Key Dist. Problem Statement February 2007 Authors' Addresses Dan Harkins Tropos Networks 555 Del Rey avenue Sunnyvale, CA 94085 USA Phone: +1 408 470 7372 Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway, NJ 08854 USA Phone: +1 732 699 5365 Email: yohba@tari.toshiba.com Madjid Nakhjiri Huawei USA Harkins, et al. Expires August 30, 2007 [Page 12] Internet-Draft 3-Party Key Dist. Problem Statement February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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). Harkins, et al. Expires August 30, 2007 [Page 13]