J. Floroiu Internet-Draft Fokus Fraunhofer Expires: April 14, 2005 October 15, 2004 An User-to-User Authenticated Key Exchange Mechanism Based on the UMTS Authentication and Key Agreement (AKA) draft-floroiu-u2u-ake-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 April 14, 2005. Intellectual Property Rights (IPR) Statement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The present draft describes an user-to-user (u2u) authenticated key exchange mechanism based on the UMTS AKA mechanism [1]. The proposed scheme is based on the generation of security tokens (in fact encrypted public Diffie-Hellman keys) by the peer's operator. Such a security token along with credential information contained within the peer's AKA Authentication Vector (AV) enables two communicating peers to securely derive a shared key. Floroiu Expires April 14, 2005 [Page 1] Internet-Draft An User-to-User Authenticated Key Exchange October 2004 Introduction Many protocols define security extensions aimed at protecting the data traffic or signalling between two communicating peers. Most of the security extensions are based on symmetric cryptography due to the relative computational efficiency of the symmetric cryptographic algorithms as compared to the asymmetric ones. The establishment of a shared key between two communicating parties however requires a key establishment protocol and the presence of an infrastructure able to provide the credentials necessary to achieve the mutual authentication of the parties. The present draft describes a mechanism based on "security tokens" issued by the peer's Home Subscriber Server (HSS) that enables two peers to securely derive a shared key using relatively unexpensive cryptographic operations. The exchange requires three trips and may be easily piggybacked into other signalling protocols (for example SIP). Notations | concatenation E(K,P) encryption of payload "P" using the key "K" A, B A's respectively B's identity AUTN AKA Authentication Token RAND AKA Random Challange XRES Expected Response IK AKA Integrity Key CK AKA Cipher Key ..._X a certain piece of information pertaining to entity "X" Floroiu Expires April 14, 2005 [Page 2] Internet-Draft An User-to-User Authenticated Key Exchange October 2004 1. Security Token Acquisition Figure 1 illustrates the message exchange that enables a user to acquire a security token from the peer's HSS entity. This phase must precede the actual establishment of a secure connection between the two parties. In the example, user A gets a public Diffie-Hellman key encrypted by B's HSS, along with B's credentials that later on will help B derive the encryption key. The exchange is assumed to take place over authenticated channels. In the first message A provides the peer's identity and its public Diffie-Hellman key and gets it back encrypted with one of the B's private key along with the B's credentials that correspond to that key. HSS_A is assumed to be able to route the message based on B's identity to the appropriate HSS, with whom it must necessary share a trust relationship. A HSS_A HSS_B | 1: B, g^a | | | -------------------------> | 2: B, g^a | | | -----------------------> | | | | | | 3: AUTN_B, RAND_B, | | 4: AUTN_B, RAND_B, | XRES_B, E{CK_B, g^a} | | XRES_B, E{CK_B, g^a} | <----------------------- | | <------------------------- | | | | | Figure 1 2. The Key Exchange It is assumed that A and B have acquired such tokens prior to initiating an authenticated key exchange (Figure 2). A initiates the key exchange by sending the security token along with a challange to B. B checks the authenticity of AUTN_B, derives CK_B and retrieves g^a. It then picks up a security token it has acquired from A's operator and computes the shared key K = g^(ab). Finally it replies in message 6 with the public part of the security token and the response encrypted with the shared key K. Upon receiving message 6, A follows similar steps to authenticate the token and retrieve the shared key K. The exchange concludes with message 7, which contains A's response, based on which B can decide whether the party is indeed genuine and the exchange was sucessful. Floroiu Expires April 14, 2005 [Page 3] Internet-Draft An User-to-User Authenticated Key Exchange October 2004 A B | | | 5: AUTN_B, RAND_B, E{CK_B, g^a} | | ------------------------------------------------------------> | | 6: AUTN_A, RAND_A, E{CK_A, g^b}, E{K, CK_B, RES_B} | | <------------------------------------------------------------ | | 7: E{K, CK_A, RES_A} | | ------------------------------------------------------------> | Figure 2 In order to enable the peers to verify that the original public Diffie-Hellman keys have not been modified on the fly (for instance by the HSS entities themselves), the shared keys used in the first phase to compute the security tokens are included in the messages 6 and 7. Both parties will therefore be able to check the integrity of the security tokens, which up to this stage have been opaque data. Later versions of the draft will document the error sequences, currently missing. 3. Security Considerations The main goal of the proposed protocol is to avoid the HSS entities to act as man-in-the-middle during the authenticated key exchange between two parties. As determined so far this purpose seems to be achieved, further analysis is however necessary. 4. IANA COnsiderations None. References [1] 3GPP TS 33.102 v6.0.0 Security architecture, September 2003; Author's Address John W. Floroiu Fokus Fraunhofer Institute for Open Communication Systems Kaiserin Augusta Allee 31 10589 Berlin, Germany Email: floroiu@fokus.fraunhofer.de Floroiu Expires April 14, 2005 [Page 4] Internet-Draft An User-to-User Authenticated Key Exchange October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Full Copyright Statement "Copyright (C) The Internet Society (year). 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 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." Floroiu Expires April 14, 2005 [Page 5]