Internet DRAFT - draft-floroiu-u2u-ake

draft-floroiu-u2u-ake



                                                              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 <AUTN_A, RAND_A,
   XRES_A, b, E{CK_A, g^b}> 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]