Network Working Group J. Arkko INTERNET-DRAFT V. Torvinen draft-uusitalo-sipping-authentication-00.txt I. Uusitalo Expires: August 2002 Ericsson February 2002 3GPP Requirements for SIP Authentication 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 1. Abstract The 3rd Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) [1] as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem. This document discusses requirements identified by 3GPP concerning SIP authentication methods. 2. Conventions used in this document 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 [RFC 2119]. Arkko et al. February 2002 [Page 1] SIP AUTHENTICATION REQUIREMENTS January 2002 3. Table of contents 1. Abstract........................................................1 2. Conventions used in this document...............................1 3. Table of contents...............................................2 4. Introduction and Motivation.....................................2 5. Definitions.....................................................3 6. Requirements....................................................3 7. Discussion......................................................4 8. Acknowledgments.................................................4 9. References......................................................4 10. Author's Address...............................................5 4. Introduction and Motivation 3GPP has selected SIP [1] as the protocol to establish and tear down multimedia sessions in the IP Multimedia Core Network Subsystem (IM CN Subsystem). See [3] for a description of the IP CN Subsystem. A comprehensive set of session flows can be found in [4]. This document is an effort to define requirements applicable for authentication methods used with SIP protocol, particularly in the 3GPP IM CN Subsystem. The requirements are listed in "3GPP Requirements on SIP" [2], but we consider them to be beneficial also to infrastructures other than 3GPP. Therefore they've been separated into this new draft that's easier to deal with. In addition to [2], also [8] list general requirements identified by 3GPP to support SIP for IM CN Subsystem in cellular networks. Authentication and Key Agreement (AKA) [5] is an authentication and session key distribution protocol defined by the 3GPP. It is based on a challenge-response mechanism and symmetric cryptography. AKA typically runs in smart card devices like the ISIM, but it can be implemented also in host software. AKA provides mutual authentication by the ISIM and the home environment showing knowledge of a secret key K that is shared between and available only to the two parties. AKA operates in the following manner: - The ISIM and the home environment (HE) have agreed on the secret key K beforehand. - The end-user terminal including the ISIM and the home environment are communicating over an insecure channel. - The HE produces an authentication vector basically based on K, a random number RAND and on a sequence number SQN. The authentication vector consists of a random part RAND, an authenticator part AUTN used by the ISIM for authenticating the HE to the ISIM, an expected result XRES, a session key IK for integrity check, and a session key CK for encryption. Arkko et al. February 2002 [Page 2] SIP AUTHENTICATION REQUIREMENTS January 2002 - The RAND and AUTN are delivered to the ISIM - The ISIM uses K and the SQN to verify the AUTN. If this operation is successful, the ISIM calculates IK and CK from K and RAND using the same key generating functions as the HE. The ISIM calculates also the response, RES, from K and the RAND and sends this to the HE. - The HE verifies the result from the ISIM. If the result is correct, IK and CK can be used to protect further communications ISIM calculates IK and CK from RAND using key generating functions. See [5] for further details on AKA. 5. Definitions AKA: Authentication and Key Agreement ISIM: IM Services Identity Module UMTS: Universal Mobile Telecommunications System 6. Requirements 3GPP SIP capable terminals possess SIM-cards (ISIM) to securely store identity information and e.g. shared secret keys shared with the home environment. It is necessary to re-use authentication based on the shared key stored in ISIM also with SIP authentication. Significant costs are involved in building a large, global security infrastructure that involves hundreds of millions of secure tamper- proof devices, many authentication servers, procedures, personnel, and equipment to distribute passwords or tokens to users, and so on. It is necessary to be able to re-use an existing infrastructure built for another purpose also when the same terminals are used for multimedia communications and need authenticate their SIP signaling. >> Req 1: AKA authentication MUST be supported with SIP. AKA needs to follow the regular SIP authentication such that the authentication can be performed not just for hop-by-hop but also in other cases. >> Req 2: AKA authentication in SIP MUST support end-to-middle, end- to-end as well as hop-by-hop authentication. Initial authentication is performed between the SIP UA and the authenticating SIP proxy or registrar residing in the home network. However, the authentication method must not require knowledge of the long-term authentication credentials in these nodes. It must be possible to delegate the actual authentication task to a central server. This is necessary in order to avoid duplicating the shared Arkko et al. February 2002 [Page 3] SIP AUTHENTICATION REQUIREMENTS January 2002 AKA secrets in a SIP server farm, and to ensure that the storage of the secrets is kept in specialized nodes. >> Req 3: AKA authentication in SIP MUST NOT require access to long- term authentication credentials in the SIP and it MUST be possible to delegate the authentication task to e.g. an AAA node. 7. Discussion AKA will be used in thin devices such as PDAs or mobile terminals. Resources are limited in such devices, so authentication using only symmetric methods must be possible. Asymmetric cryptography and certificates could be optionally used but their use should not be mandated. Also, in cellular networks bandwidth is limited, so the authentication method should have a small amount of roundtrips. The authentication shouldn't have a noticeable negative impact on the session setup delay. TLS [7] doesn't fulfil the requirements of chapter 6. For example, TLS provides hop-by-hop authentication, but not the other two mentioned in requirement 2. Work conducted at IETF IPsec Remote Access working group (IPSRA) doesn't suite to requirements above either. Providing AKA for SIP can be done in several ways. One approach is to provide AKA for one of the general authentication frameworks in IETF such as EAP, SASL, or GSS_API, and then allow that framework to be used in SIP. An example of this approach is in [9]. Another approach is to provide AKA as a new algorithm under the existing Digest framework in SIP, as described in [10]. Recent discussions with IETF authentication experts indicate that the latter approach may be preferable, as it can be progressed to an RFC status faster and without discussions on which of the general frameworks should be selected. It also results in less likely interoperability problems as there isn't as much freedom to implement different authentication schemes as there is in the general frameworks. In the long run, it is also expected that application layer protocols will all migrate to the use of certificates and tickets when sufficient CPU and communication bandwidth becomes available. 8. Acknowledgments We would like to thank Allison Mankin, Dean Willis, Rohan Mahy, Bernard Aboba, Miguel Garcia, as well as numerous people at 3GPP SA3 and Ericsson for interesting discussions in this problem space. 9. References 1. Rosenberg, J., et al., "SIP:Session Initiation Protocol", draft-ietf-sip-rfc2543bis-05.txt, October 2001, work in progress. Arkko et al. February 2002 [Page 4] SIP AUTHENTICATION REQUIREMENTS January 2002 2. Garcia, M., et al., "3GPP requirements on SIP", draft-garcia- sipping-3gpp-regs-02.txt, November 2001, work in progress. 3. 3GPP TS 23.228: "IP Multimedia (IM) Subsystem (Stage 2) - Release 5". Version 5.3.0 is available at ftp://ftp.3gpp.org/Specs/2001-12/Rel-5/23_series/23228-530.zip 4. 3GPP TS 24.228: "Signaling flows for the IP Multimedia call control based on SIP and SDP". Version 1.9.0 is available at ftp://ftp.3gpp.org/tsg_cn/WG1_mm-cc-sm/TSGN1_22/Docs/N1- 020280_24228-190.zip 5. 3GPP TS 33.102: "Security Architecture (Release 4)". Version 4.3.0 is available at ftp://ftp.3gpp.org/Specs/2001-12/Rel- 4/33_series/33102-430.zip 6. Franks, J., et al., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999 7. Dierks, T., Allen, C., "The TLS Protocol, Version 1.0", RCF 2246, January 1999 8. 3GPP TS 33.203: "Access security for IP-based services (Release 5)". Version 1.00 is available at ftp://ftp.3gpp.org/Specs/Latest-drafts/33203-100.zip 9. Arkko, J., Torvinen, V., Niemi, A., "HTTP Authentication with EAP", draft-torvinen-http-eap-01.txt, November 2001, work in progress. 10. Arkko, J., Torvinen, V., Niemi, A., "HTTP Digest Authentication using AKA", draft-niemi-sip-digest-aka-00.txt, to appear. 10. Authors' Addresses Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com Vesa Torvinen Oy LM Ericsson Ab Joukahaisenkatu 1 20520 Turku Finland Phone: +358 40 7230822 EMail: vesa.torvinen@ericsson.fi Arkko et al. February 2002 [Page 5] SIP AUTHENTICATION REQUIREMENTS January 2002 Ilkka Uusitalo Oy LM Ericsson Ab Tutkijantie 2C 90570 Oulu Finland Phone: +358 40 7245404 EMail: ilkka.uusitalo@ericsson.fi Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Arkko et al. February 2002 [Page 6]