idnits 2.17.1 draft-uusitalo-sipping-authentication-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 101 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 139: '...A authentication MUST be supported wit...' RFC 2119 keyword, line 145: '...ntication in SIP MUST support end-to-m...' RFC 2119 keyword, line 160: '...ntication in SIP MUST NOT require acce...' RFC 2119 keyword, line 161: '...als in the SIP and it MUST be possible...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8105 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 63 looks like a reference -- Missing reference section? 'RFC 2119' on line 45 looks like a reference -- Missing reference section? '3' on line 65 looks like a reference -- Missing reference section? '4' on line 66 looks like a reference -- Missing reference section? '2' on line 73 looks like a reference -- Missing reference section? '8' on line 74 looks like a reference -- Missing reference section? '5' on line 115 looks like a reference -- Missing reference section? '7' on line 175 looks like a reference -- Missing reference section? '9' on line 184 looks like a reference -- Missing reference section? '10' on line 186 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 INTERNET-DRAFT V. Torvinen 4 draft-uusitalo-sipping-authentication-00.txt I. Uusitalo 5 Expires: August 2002 Ericsson 6 February 2002 8 3GPP Requirements for SIP Authentication 10 Status of this Memo 12 This document is an Internet Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 1. Abstract 34 The 3rd Generation Partnership Project (3GPP) has selected Session 35 Initiation Protocol (SIP) [1] as the session establishment protocol 36 for the 3GPP IP Multimedia Core Network Subsystem. This document 37 discusses requirements identified by 3GPP concerning SIP 38 authentication methods. 40 2. Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in 44 this document are to be interpreted as described in [RFC 2119]. 46 SIP AUTHENTICATION REQUIREMENTS January 2002 48 3. Table of contents 50 1. Abstract........................................................1 51 2. Conventions used in this document...............................1 52 3. Table of contents...............................................2 53 4. Introduction and Motivation.....................................2 54 5. Definitions.....................................................3 55 6. Requirements....................................................3 56 7. Discussion......................................................4 57 8. Acknowledgments.................................................4 58 9. References......................................................4 59 10. Author's Address...............................................5 61 4. Introduction and Motivation 63 3GPP has selected SIP [1] as the protocol to establish and tear down 64 multimedia sessions in the IP Multimedia Core Network Subsystem (IM 65 CN Subsystem). See [3] for a description of the IP CN Subsystem. A 66 comprehensive set of session flows can be found in [4]. 68 This document is an effort to define requirements applicable for 69 authentication methods used with SIP protocol, particularly in the 70 3GPP IM CN Subsystem. The requirements are listed in "3GPP 71 Requirements on SIP" [2], but we consider them to be beneficial also 72 to infrastructures other than 3GPP. Therefore they've been separated 73 into this new draft that's easier to deal with. In addition to [2], 74 also [8] list general requirements identified by 3GPP to support SIP 75 for IM CN Subsystem in cellular networks. 77 Authentication and Key Agreement (AKA) [5] is an authentication and 78 session key distribution protocol defined by the 3GPP. It is based 79 on a challenge-response mechanism and symmetric cryptography. AKA 80 typically runs in smart card devices like the ISIM, but it can be 81 implemented also in host software. AKA provides mutual 82 authentication by the ISIM and the home environment showing 83 knowledge of a secret key K that is shared between and available 84 only to the two parties. 86 AKA operates in the following manner: 88 - The ISIM and the home environment (HE) have agreed on the secret 89 key K beforehand. 91 - The end-user terminal including the ISIM and the home environment 92 are communicating over an insecure channel. 94 - The HE produces an authentication vector basically based on K, a 95 random number RAND and on a sequence number SQN. The authentication 96 vector consists of a random part RAND, an authenticator part AUTN 97 used by the ISIM for authenticating the HE to the ISIM, an expected 98 result XRES, a session key IK for integrity check, and a session key 99 CK for encryption. 101 SIP AUTHENTICATION REQUIREMENTS January 2002 103 - The RAND and AUTN are delivered to the ISIM 105 - The ISIM uses K and the SQN to verify the AUTN. If 106 this operation is successful, the ISIM calculates IK and CK from K 107 and RAND using the same key generating functions as the HE. The ISIM 108 calculates also the response, RES, from K and the RAND and sends 109 this to the HE. 111 - The HE verifies the result from the ISIM. If the result is 112 correct, IK and CK can be used to protect further communications 113 ISIM calculates IK and CK from RAND using key generating functions. 115 See [5] for further details on AKA. 117 5. Definitions 119 AKA: Authentication and Key Agreement 121 ISIM: IM Services Identity Module 123 UMTS: Universal Mobile Telecommunications System 125 6. Requirements 127 3GPP SIP capable terminals possess SIM-cards (ISIM) to securely 128 store identity information and e.g. shared secret keys shared with 129 the home environment. It is necessary to re-use authentication based 130 on the shared key stored in ISIM also with SIP authentication. 131 Significant costs are involved in building a large, global security 132 infrastructure that involves hundreds of millions of secure tamper- 133 proof devices, many authentication servers, procedures, personnel, 134 and equipment to distribute passwords or tokens to users, and so on. 135 It is necessary to be able to re-use an existing infrastructure 136 built for another purpose also when the same terminals are used for 137 multimedia communications and need authenticate their SIP signaling. 139 >> Req 1: AKA authentication MUST be supported with SIP. 141 AKA needs to follow the regular SIP authentication such that the 142 authentication can be performed not just for hop-by-hop but also in 143 other cases. 145 >> Req 2: AKA authentication in SIP MUST support end-to-middle, end- 146 to-end as well as hop-by-hop authentication. 148 Initial authentication is performed between the SIP UA and the 149 authenticating SIP proxy or registrar residing in the home network. 150 However, the authentication method must not require knowledge of the 151 long-term authentication credentials in these nodes. It must be 152 possible to delegate the actual authentication task to a central 153 server. This is necessary in order to avoid duplicating the shared 155 SIP AUTHENTICATION REQUIREMENTS January 2002 157 AKA secrets in a SIP server farm, and to ensure that the storage of 158 the secrets is kept in specialized nodes. 160 >> Req 3: AKA authentication in SIP MUST NOT require access to long- 161 term authentication credentials in the SIP and it MUST be possible 162 to delegate the authentication task to e.g. an AAA node. 164 7. Discussion 166 AKA will be used in thin devices such as PDAs or mobile terminals. 167 Resources are limited in such devices, so authentication using only 168 symmetric methods must be possible. Asymmetric cryptography and 169 certificates could be optionally used but their use should not be 170 mandated. Also, in cellular networks bandwidth is limited, so the 171 authentication method should have a small amount of roundtrips. The 172 authentication shouldn't have a noticeable negative impact on the 173 session setup delay. 175 TLS [7] doesn't fulfil the requirements of chapter 6. For example, 176 TLS provides hop-by-hop authentication, but not the other two 177 mentioned in requirement 2. Work conducted at IETF IPsec Remote 178 Access working group (IPSRA) doesn't suite to requirements above 179 either. 181 Providing AKA for SIP can be done in several ways. One approach is 182 to provide AKA for one of the general authentication frameworks in 183 IETF such as EAP, SASL, or GSS_API, and then allow that framework to 184 be used in SIP. An example of this approach is in [9]. Another 185 approach is to provide AKA as a new algorithm under the existing 186 Digest framework in SIP, as described in [10]. Recent discussions 187 with IETF authentication experts indicate that the latter approach 188 may be preferable, as it can be progressed to an RFC status faster 189 and without discussions on which of the general frameworks should be 190 selected. It also results in less likely interoperability problems 191 as there isn't as much freedom to implement different authentication 192 schemes as there is in the general frameworks. In the long run, it 193 is also expected that application layer protocols will all migrate 194 to the use of certificates and tickets when sufficient CPU and 195 communication bandwidth becomes available. 197 8. Acknowledgments 199 We would like to thank Allison Mankin, Dean Willis, Rohan Mahy, 200 Bernard Aboba, Miguel Garcia, as well as numerous people at 3GPP SA3 201 and Ericsson for interesting discussions in this problem space. 203 9. References 205 1. Rosenberg, J., et al., "SIP:Session Initiation Protocol", 206 draft-ietf-sip-rfc2543bis-05.txt, October 2001, work in 207 progress. 209 SIP AUTHENTICATION REQUIREMENTS January 2002 211 2. Garcia, M., et al., "3GPP requirements on SIP", draft-garcia- 212 sipping-3gpp-regs-02.txt, November 2001, work in progress. 214 3. 3GPP TS 23.228: "IP Multimedia (IM) Subsystem (Stage 2) - 215 Release 5". Version 5.3.0 is available at 216 ftp://ftp.3gpp.org/Specs/2001-12/Rel-5/23_series/23228-530.zip 218 4. 3GPP TS 24.228: "Signaling flows for the IP Multimedia call 219 control based on SIP and SDP". Version 1.9.0 is available at 220 ftp://ftp.3gpp.org/tsg_cn/WG1_mm-cc-sm/TSGN1_22/Docs/N1- 221 020280_24228-190.zip 223 5. 3GPP TS 33.102: "Security Architecture (Release 4)". Version 224 4.3.0 is available at ftp://ftp.3gpp.org/Specs/2001-12/Rel- 225 4/33_series/33102-430.zip 227 6. Franks, J., et al., "HTTP Authentication: Basic and Digest 228 Access Authentication", RFC 2617, June 1999 230 7. Dierks, T., Allen, C., "The TLS Protocol, Version 1.0", RCF 231 2246, January 1999 233 8. 3GPP TS 33.203: "Access security for IP-based services (Release 234 5)". Version 1.00 is available at 235 ftp://ftp.3gpp.org/Specs/Latest-drafts/33203-100.zip 237 9. Arkko, J., Torvinen, V., Niemi, A., "HTTP Authentication with 238 EAP", draft-torvinen-http-eap-01.txt, November 2001, work in 239 progress. 241 10. Arkko, J., Torvinen, V., Niemi, A., "HTTP Digest 242 Authentication using AKA", draft-niemi-sip-digest-aka-00.txt, 243 to appear. 245 10. Authors' Addresses 247 Jari Arkko 248 Oy LM Ericsson Ab 249 02420 Jorvas 250 Finland 252 Phone: +358 40 5079256 253 EMail: jari.arkko@ericsson.com 255 Vesa Torvinen 256 Oy LM Ericsson Ab 257 Joukahaisenkatu 1 258 20520 Turku 259 Finland 261 Phone: +358 40 7230822 262 EMail: vesa.torvinen@ericsson.fi 264 SIP AUTHENTICATION REQUIREMENTS January 2002 266 Ilkka Uusitalo 267 Oy LM Ericsson Ab 268 Tutkijantie 2C 269 90570 Oulu 270 Finland 272 Phone: +358 40 7245404 273 EMail: ilkka.uusitalo@ericsson.fi 275 Full Copyright Statement 277 Copyright (C) The Internet Society (2002). All Rights Reserved. 279 This document and translations of it may be copied and furnished to 280 others, and derivative works that comment on or otherwise explain it 281 or assist in its implementation may be prepared, copied, published 282 and distributed, in whole or in part, without restriction of any 283 kind, provided that the above copyright notice and this paragraph 284 are 285 included on all such copies and derivative works. However, this 286 document itself may not be modified in any way, such as by removing 287 the copyright notice or references to the Internet Society or other 288 Internet organizations, except as needed for the purpose of 289 developing Internet standards in which case the procedures for 290 copyrights defined in the Internet Standards process must be 291 followed, or as required to translate it into languages other than 292 English. 294 The limited permissions granted above are perpetual and will not be 295 revoked by the Internet Society or its successors or assigns. 297 This document and the information contained herein is provided on an 298 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 299 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 300 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 301 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 302 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.