Network Working Group D. Harkins Internet-Draft Tropos Networks Expires: September 5, 2007 Y. Ohba Toshiba M. Nakhjiri Huawei R. Lopez Univ. of Murcia March 4, 2007 Problem Statement and Requirements on a 3-Party Key Distribution Protocol for Handover Keying draft-ohba-hokey-3party-keydist-ps-01 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 September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Harkins, et al. Expires September 5, 2007 [Page 1] Internet-Draft 3-Party Key Dist. Problem Statement March 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. Solution Framework for HOKEY 3-Party Key Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Candidate 3-Party Key Distribution Protocols . . . . . . . 9 4.3.1. Kerberos Protocol . . . . . . . . . . . . . . . . . . 9 4.3.2. ISO/IEC 11770-2 Key Establishment Mechanism 10 . . . . 9 4.3.3. An Improved Provably Secure 3PKD protocol . . . . . . 10 4.3.4. Dan Harkins' protocol (tentative) . . . . . . . . . . 10 4.4. Candidate Key Distribution Transport Protocols . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Protocols not being considered as candidates due to known flaws . . . . . . . . . . . . . . . . . . . 16 Appendix A.1. Otway-Rees . . . . . . . . . . . . . . . . . . . . . 16 Appendix A.2. Wide Mouth Frog . . . . . . . . . . . . . . . . . . 16 Appendix A.3. Needham-Schroeder Shared Key Protocol . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Harkins, et al. Expires September 5, 2007 [Page 2] Internet-Draft 3-Party Key Dist. Problem Statement March 2007 1. Introduction This is my time tabe for the week: Monday to Friday working Saturday and Sunday working 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 derivation 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 September 5, 2007 [Page 3] Internet-Draft 3-Party Key Dist. Problem Statement March 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 perform 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 September 5, 2007 [Page 4] Internet-Draft 3-Party Key Dist. Problem Statement March 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 September 5, 2007 [Page 5] Internet-Draft 3-Party Key Dist. Problem Statement March 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 September 5, 2007 [Page 6] Internet-Draft 3-Party Key Dist. Problem Statement March 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. Validation of credential source -- 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. Verification of identity -- 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. 9. Replay protection -- replay attacks MUST NOT effect the key distribution protocol. Harkins, et al. Expires September 5, 2007 [Page 7] Internet-Draft 3-Party Key Dist. Problem Statement March 2007 4. Solution Framework for HOKEY 3-Party Key Distribution Protocol Following, we present two different main cases that need to be considered in the handover keying problem. 4.1. Use Cases Use Case 1 principals: EAP peer, HOKEY server and EAP server In this scenario, the HOKEY server is not co-located with the EAP server. That is, the EAP server and HOKEY server are considered as two completely different parties. The 3-Party Key Distribution protocol is aimed for distributing a shared key Kab between the HOKEY peer and HOKEY server where the EAP server is acting as server distributing the session key Kab. Use Case 2 principals: EAP peer, authenticator and HOKEY server In this scenario, the HOKEY peer and the HOKEY server already owns a shared secret Kas (e.g. the HOKEY server is the EAP server). The 3-Party Key Distribution protocol is aimed for distributing a shared key Kab between the HOKEY peer and the authenticator where the HOKEY server is acting as server distributing the Kab. Note that when HOKEY peer and HOKEY server do not share any key, Case 1 needs to be performed before going through Case 2. 4.2. Notation A: HOKEY client in both Use Cases 1 and 2 B: HOKEY server in Use Case 1 or Authenticator in Use Case 2 S: EAP server in Use Case 1 or HOKEY server in Use Case 2 {X}K: X encrypted with key K [X]K: Message Authentication Code of X with key K. H(x): Digest produced from a one-way hash function given x as input x|y: Concatenation of x and y Kas: A symmetric key shared between A and S Kbs: A symmetric key shared between B and S Kab: A symmetric key to be shared between A and B L : Key lifetime for Kab Tx : Timestamp generated by the party X Nx : Nonce provided by the party X Harkins, et al. Expires September 5, 2007 [Page 8] Internet-Draft 3-Party Key Dist. Problem Statement March 2007 4.3. Candidate 3-Party Key Distribution Protocols We present a set of candidate 3-Party Key Distribution protocols that may be considered suitable for deploying a handover keying solution. Note that there are other protocols that may be well considered as candidates [prot-auth]. Note also that, in this version of document no verification has been made as to whether the candidate protocols satisfy the requirements listed in Section 3. It is assumed for all candidate protocols that when Kab is encrypted in a message, authorization attributes associated with Kab are also encrypted together. However, the authorization attributes are not shown in the diagram of each candidate protocol. 4.3.1. Kerberos Protocol 1) A->S: A, B 2) S->A: {Ts, L, Kab, B, {Ts, L, Kab, A}Kbs}Kas 3) A->B: {Ts, L, Kab, A}Kbs, {A, Ta}Kab 4) B->A: {Ta+1}Kab Kerberos protocol is based on Needham-Schroeder protocol but following the recommendations given by Denning and Sacco [ds-time]. That is, they use timestamps to avoid replay attacks. Additionally, S includes a lifetime L associated to the distributed key Kab. The last message 4 allows mutual authentication between A and B and it is optional. In Kerberos v5, Ta+1 in the 4-th message is replaced with Ta and other information [RFC4120]. Additionally, Kerberos allows the client A to obtain an initial ticket to access a Ticket Granting Service (TGS) without requiring the user to re-entry the password. That initial ticket allows the client A to start a Kerberos negotiation with TGS to obtain another ticket for accessing the service B. By using this approach, Kerberos also allows a cross-realm operation where A can recover a ticket from a remote TGS (in A's Home Domain) to access a local TGS (in the visited domain). However, Kerberos requires time synchronization among the three parties. 4.3.2. ISO/IEC 11770-2 Key Establishment Mechanism 10 1) A->S: {Ta,B}Kas 2) S->A: {Ts,Kab,B}Kas 3) S->B: {Ts',Kab,A}Kbs Harkins, et al. Expires September 5, 2007 [Page 9] Internet-Draft 3-Party Key Dist. Problem Statement March 2007 This protocol has an interesting feature because it allows S to verify the authenticity and freshness of the first message before starting the key distribution process. The protocol requires that time synchronization among the three entities. 4.3.3. An Improved Provably Secure 3PKD protocol 1) A->B: Na 2) B->S: Na,Nb 3a) S->A: {Kab}Kas,[A,B,Na,Nb,Ns,{Kab}Kas]Kas,Nb 3b) S->B: {Kab}Kbs,[A,B,Na,Nb,Ns,{Kab}Kbs]Kbs The original protocol 3PKD was proposed by Bellare and Rogaway in [3pkd]. However, Choo et al. presented a small modification to the protocol by adding the value Nb and a nonce generated by the server S (Ns) which avoids A and B to accept two different session keys (e.g. Kab, Kab') for the same session [3pkd-choo]. Basically, with the inclusion of Ns, the protocol defines as session formed by the 3-tuple (Na,Nb,Ns). However as we may see the protocol does not consider mutual authentication. 4.3.4. Dan Harkins' protocol (tentative) 1) A->B: A, {A, B, Na}Kas 2) B->S: A, B, {Nb}Kbs, {A, B, Na}Kas 3) S->B: {Na, Nt, B}Kas, {A, Na, Nb, Nt, Kab}Kbs 4) B->A: {Na, Nt, B}Kas, H(Na|Nt) In this protocol, A and B derive Kab from Kas using the same key derivation function. Therefore, there is no need to carry Kab in message 4. 4.4. Candidate Key Distribution Transport Protocols The protocols presented in Section 4.3 are independent on the protocol used to transport the different messages exchanged among the the principals. Several alternatives are identified as transport protocols for a 3-party key distribution protocol. This version of document does not make any recommendation on a specific transport protocol. o Lower-layer specific transport (e.g., new link-layer management frames and new AAA attributes). The HOKEY scope limits the definition of the lower-layer to an IP protocol Harkins, et al. Expires September 5, 2007 [Page 10] Internet-Draft 3-Party Key Dist. Problem Statement March 2007 o New EAP Code o New EAP Method Harkins, et al. Expires September 5, 2007 [Page 11] Internet-Draft 3-Party Key Dist. Problem Statement March 2007 5. 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 September 5, 2007 [Page 12] Internet-Draft 3-Party Key Dist. Problem Statement March 2007 6. IANA Considerations There are no IANA related issues in this document. Harkins, et al. Expires September 5, 2007 [Page 13] Internet-Draft 3-Party Key Dist. Problem Statement March 2007 7. Acknowledgments Harkins, et al. Expires September 5, 2007 [Page 14] Internet-Draft 3-Party Key Dist. Problem Statement March 2007 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [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. [prot-auth] Boyd, C. and A. Mathuria, "Protocols for Authentication and Key Establishment", September 2003. [ds-time] Denning, D. and G. Sacco, "Timestamps in key distribution protocols", Communications of the ACM pages 533-536, August 1981. [3pkd] Bellare, M. and P. Rogaway, "Provably Secure Session Key Distribution: The Three Party Case", Advances of Cryptology - Crypto 1993 pages 110-125, August 1981. [3pkd-choo] Choo, R. and Y. Hitchock, "Security Requirements for Key Establishment Proof Models: Revisiting Bellare-Rogaway and Jeong-Katz-Lee Protocols", ACISP 2005 pages 429-442, August 1981. [or-attack] Boyd, C. and W. Mao, "On a Limitation of BAN Logic", Advances in Cryptology: Eurocrypt 93 pages 240-247, May 1993. Harkins, et al. Expires September 5, 2007 [Page 15] Internet-Draft 3-Party Key Dist. Problem Statement March 2007 Appendix A. Protocols not being considered as candidates due to known flaws Following we present a set of protocols which have recognized flaws but they serve as basis to other protocols. Appendix A.1. Otway-Rees 1) A->B: M, A, B, {M, A, B, Na}Kas 2) B->S: M, A, B, {M, A, B, Na}Kas,{M, A, B, Nb}Kbs 3) S->B: M,{Na, Kab}Kas, {Nb, Kab}Kbs 4) B->A: M,{Na, Kab}Kas The protocol adds a value M as session number but has a flaw. In fact, a replay attack is possible by malicious intruder which can end up with arranging different keys for A and B [or-attack]. Appendix A.2. Wide Mouth Frog 1) A->S: A,{Ta, Kab, B}Kas 2) S->B: {Ts, Kab, A}Kbs This simple protocol shows a flaw where an attacker may force to B to accept an old session key Kab by sending and updated message 2 (with a new Ts) [prot-auth]. Appendix A.3. Needham-Schroeder Shared Key Protocol 1) A->S: A, B, Na 2) S->A: {Na, Kab, B, {Kab, A}Kbs}Kas 3) A->B: {Kab, A}Kbs 4) B->A: {Nb}Kab 5) A->B: {Nb-1}Kab This protocol has a flaw where an attacker can launch a replay attack when Kab is compromized. The attacker can use the same Kab for different sessions. Harkins, et al. Expires September 5, 2007 [Page 16] Internet-Draft 3-Party Key Dist. Problem Statement March 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 Rafael Marin Lopez Faculty of Computer Science University of Murcia Murcia 30100 Spain Phone: +34968398501 Email: rafa@dif.um.es Harkins, et al. Expires September 5, 2007 [Page 17] Internet-Draft 3-Party Key Dist. Problem Statement March 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 September 5, 2007 [Page 18]