idnits 2.17.1 draft-ietf-sipcore-digest-scheme-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 29, 2019) is 1634 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: '-sess' is mentioned on line 313, but not defined ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Core R. Shekh-Yusef 3 Internet-Draft Avaya 4 Updates: 3261 (if approved) October 29, 2019 5 Intended status: Standards Track 6 Expires: May 1, 2020 8 The Session Initiation Protocol (SIP) Digest Authentication Scheme 9 draft-ietf-sipcore-digest-scheme-12 11 Abstract 13 This document updates RFC 3261 by updating the Digest Access 14 Authentication scheme used by the Session Initiation Protocol (SIP) 15 to add support for more secure digest algorithms, e.g., SHA-256 and 16 SHA-512-256, to replace the broken MD5 algorithm. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 1, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. SIP Digest Authentication Scheme Updates . . . . . . . . . . 3 67 2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 3 68 2.2. Representation of Digest Values . . . . . . . . . . . . . 4 69 2.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 4 70 2.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 5 71 2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.6. HTTP Digest Authentication Scheme Modifications . . . . . 5 73 2.7. Augmented BNF for SIP . . . . . . . . . . . . . . . . . . 7 74 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 6.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 The Session Initiation Protocol [RFC3261] uses the same mechanism 85 that the Hypertext Transfer Protocol (HTTP) uses for authenticating 86 users. This mechanism is called Digest Access Authentication, and it 87 is a simple challenge-response mechanism that allows a server to 88 challenge a client request and allows a client to provide 89 authentication information in response to that challenge. The 90 version of Digest Access Authentication that [RFC3261] references is 91 specified in [RFC2617]. 93 The default hash algorithm for Digest Access Authentication is MD5. 94 However, it has been demonstrated that the MD5 algorithm is not 95 collision resistant, and is now considered a bad choice for a hash 96 function [RFC6151]. 98 The HTTP Digest Access Authentication [RFC7616] document obsoletes 99 [RFC2617] and adds stronger algorithms that can be used with the 100 Digest Authentication scheme, and establishes a registry for these 101 algorithms, known as the "Hash Algorithms for HTTP Digest 102 Authentication" registry, so that algorithms can be added in the 103 future. 105 This document updates the Digest Access Authentication scheme used by 106 SIP to support the algorithms listed in the "Hash Algorithms for HTTP 107 Digest Authentication" registry defined by [RFC7616]. 109 1.1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 2. SIP Digest Authentication Scheme Updates 119 This section describes the modifications to the operation of the 120 Digest mechanism as specified in [RFC3261] in order to support the 121 algorithms defined in the "Hash Algorithms for HTTP Digest 122 Authentication" registry described in [RFC7616]. 124 It replaces the reference used in [RFC3261] for Digest Access 125 Authentication, substituting [RFC7616] for the obsolete [RFC2617], 126 and describes the modifications to the usage of the Digest mechanism 127 in [RFC3261] resulting from that reference update. It adds support 128 for the SHA-256 and SHA-512/256 algorithms. It adds required support 129 for the "qop" parameter. It provides additional User Agent Client 130 (UAC) and User Agent Server (UAS) procedures regarding usage of 131 multiple SIP Authorization, WWW-Authenticate and Proxy-Authenticate 132 header fields, including in which order to insert and process them. 133 It provides guidance regarding forking. Finally, it updates the SIP 134 BNF as required by the updates. 136 2.1. Hash Algorithms 138 The Digest scheme has an 'algorithm' parameter that specifies the 139 algorithm to be used to compute the digest of the response. The IANA 140 registry named the "Hash Algorithms for HTTP Digest Authentication" 141 specifies the algorithms that correspond to 'algorithm' values. 143 [RFC3261] specifies only one algorithm, MD5, which is used by 144 default. This document extends [RFC3261] to allow use of any 145 algorithm listed in the "Hash Algorithms for HTTP Digest 146 Authentication" registry. 148 A UAS prioritizes which algorithm to use based on the ordering of the 149 challenge header fields in the response it is preparing. That 150 process is specified in section 2.3 and parallels the process used in 151 HTTP specified by [RFC7616]. 153 2.2. Representation of Digest Values 155 The size of the digest depends on the algorithm used. The bits in 156 the digest are converted from the most significant to the least 157 significant bit, four bits at a time to the ASCII representation as 158 follows. Each four bits is represented by its familiar hexadecimal 159 notation from the characters 0123456789abcdef, that is binary 0000 is 160 represented by the character '0', 0001 by '1' and so on up to the 161 representation of 1111 as 'f'. If the SHA-256 or SHA-512/256 162 algorithm is used to calculate the digest, then the digest will be 163 represented as 64 hexadecimal characters. 165 2.3. UAS Behavior 167 When a UAS receives a request from a UAC, and an acceptable 168 Authorization header field is not received, the UAS can challenge the 169 originator to provide credentials by rejecting the request with a 170 401/407 status code with the WWW-Authenticate/Proxy-Authenticate 171 header field respectively. The UAS MAY add multiple WWW- 172 Authenticate/Proxy-Authenticate header fields to allow the UAS to 173 utilize the best available algorithm supported by the client. 175 If the UAS challenges with multiple WWW-Authenticate/Proxy- 176 Authenticate header fields with the same realm, then each one of 177 these header fields MUST use a different digest algorithm. The UAS 178 MUST add these header fields to the response in the order that it 179 would prefer to see them used, starting with the most preferred 180 algorithm at the top, followed by the less preferred algorithms. The 181 UAS cannot assume that the client will use the algorithm specified at 182 the topmost header field. 184 2.4. UAC Behavior 186 When the UAC receives a response with multiple WWW-Authenticate/ 187 Proxy-Authenticate header fields with the same realm it SHOULD use 188 the topmost header field that it supports, unless a local policy 189 dictates otherwise. The client MUST ignore any challenge it does not 190 understand. 192 When the UAC receives a 401 response with multiple WWW-Authenticate 193 header fields with different realms it SHOULD retry and add an 194 Authorization header field containing credentials that match the 195 topmost header field of any one of the realms, unless a local policy 196 dictates otherwise. 198 If the UAC cannot respond to any of the challenges in the response, 199 then it SHOULD abandon attempts to send the request unless a local 200 policy dictates otherwise. For example, if the UAC does not have 201 credentials or has stale credentials for any of the realms, the UAC 202 will abandon the request. 204 2.5. Forking 206 Section 22.3 of [RFC3261] discusses the operation of the proxy-to- 207 user authentication, which describes the operation of the proxy when 208 it forks a request. This section clarifies that operation. 210 If a request is forked, various proxy servers and/or UAs may wish to 211 challenge the UAC. In this case, the forking proxy server is 212 responsible for aggregating these challenges into a single response. 213 Each WWW-Authenticate and Proxy-Authenticate value received in 214 responses to the forked request MUST be placed into the single 215 response that is sent by the forking proxy to the UAC. 217 When the forking proxy places multiple WWW-Authenticate and Proxy- 218 Authenticate header fields received from one downstream proxy into a 219 single response, it MUST maintain the order of these header fields. 220 The ordering of values received from different downstream proxies is 221 not significant. 223 2.6. HTTP Digest Authentication Scheme Modifications 225 This section describes the modifications and clarifications required 226 to apply the HTTP Digest authentication scheme to SIP. The SIP 227 scheme usage is similar to that for HTTP. For completeness, the 228 bullets specified below are mostly copied from section 22.4 of 230 [RFC3261]; the only semantic changes are specified in bullets 1, 7, 231 and 8 below. 233 SIP clients and servers MUST NOT accept or request Basic 234 authentication. 236 The rules for Digest authentication follow those defined in HTTP, 237 with "HTTP/1.1" [RFC7616] replaced by "SIP/2.0" in addition to the 238 following differences: 240 1. The URI included in the challenge has the following BNF 241 [RFC5234]: 243 URI = Request-URI ; as defined in [RFC3261], Section 25 245 2. The 'uri' parameter of the Authorization header field MUST be 246 enclosed in quotation marks. 248 3. The BNF for digest-uri-value is: 250 digest-uri-value = Request-URI 252 4. The example procedure for choosing a nonce based on Etag does not 253 work for SIP. 255 5. The text in [RFC7234] regarding cache operation does not apply to 256 SIP. 258 6. [RFC7616] requires that a server check that the URI in the 259 request line and the URI included in the Authorization header field 260 point to the same resource. In a SIP context, these two URIs may 261 refer to different users, due to forwarding at some proxy. 262 Therefore, in SIP, a UAS MUST check if the Request-URI in the 263 Authorization/Proxy-Authorization header field value corresponds to a 264 user for whom the UAS is willing to accept forwarded or direct 265 requests, but MAY still accept it if the two fields are not 266 equivalent. 268 7. As a clarification to the calculation of the A2 value for message 269 integrity assurance in the Digest authentication scheme, implementers 270 should assume, when the entity-body is empty (that is, when SIP 271 messages have no body) that the hash of the entity-body resolves to 272 the hash of an empty string: 274 H(entity-body) = ("") 276 For example, when the chosen algorithm is SHA-256, then: 278 H(entity-body) = SHA-256("") = 279 "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" 281 8. A UAS MUST be able to properly handle "qop" parameter received in 282 an Authorization/Proxy-Authorization header field, and a UAC MUST be 283 able to properly handle "qop" parameter received in WWW-Authenticate 284 and Proxy-Authenticate header fields. However, for backward 285 compatibility reasons, the "qop" parameter is optional for 286 RFC3261-based clients and servers to receive. If the "qop" parameter 287 is not specified, then the default value is "auth". 289 A UAS MUST always send a "qop" parameter in WWW-Authenticate and 290 Proxy-Authenticate header field values, and a UAC MUST send the "qop" 291 parameter in any resulting authorization header field. 293 The usage of the Authentication-Info header field continues to be 294 allowed, since it provides integrity checks over the bodies and 295 provides mutual authentication. 297 2.7. Augmented BNF for SIP 299 This document updates the Augmented BNF [RFC5234] for SIP as follows. 301 It extends the request-digest as follows to allow for different 302 digest sizes: 304 request-digest = LDQUOT *LHEX RDQUOT 306 The number of hex digits is implied by the length of the value of the 307 algorithm used. 309 It extends the algorithm parameter as follows to allow for any 310 algorithm in the registry to be used: 312 algorithm = "algorithm" EQUAL ( ("MD5" / "SHA-512-256" / "SHA- 313 256")[-sess]) / token ) 315 Each one of these algorithms might have a "-sess" variant, e.g., 316 MD5-sess, SHA-256-sess, etc, as defined in [RFC7616] 318 3. Security Considerations 320 This specification adds new secure algorithms to be used with the 321 Digest mechanism to authenticate users. The broken MD5 algorithm 322 remains only for backward compatibility with [RFC2617] but its use is 323 NOT RECOMMENDED. 325 This opens the system to the potential of a downgrade attack by an 326 on-path attacker. The most effective way of dealing with this type 327 of attack is to either validate the client and challenge it 328 accordingly, or remove the support for backward compatibility by not 329 supporting MD5. 331 See section 5 of [RFC7616] for a detailed security discussion of the 332 Digest scheme. 334 4. IANA Considerations 336 [RFC7616] defines an IANA registry named "Hash Algorithms for HTTP 337 Digest Authentication" to simplify the introduction of new algorithms 338 in the future. This document specifies that algorithms defined in 339 that registry may be used in SIP digest authentication. 341 This document has no actions for IANA. 343 5. Acknowledgments 345 The author would like to thank the following individuals for their 346 careful reviews, comments, and suggestions: Paul Kyzivat, Olle 347 Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga 348 Asveren, Christer Holmberg, Brian Rosen, Jean Mahoney, Adam Roach, 349 Barry Leiba, Roni Even, Benjamin Kaduk, and Alissa Cooper. 351 6. References 353 6.1. Normative References 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, 357 DOI 10.17487/RFC2119, March 1997, 358 . 360 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, 361 A., Peterson, J., Sparks, R., Handley, M., and E. 362 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 363 June 2002. 365 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 366 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 367 2014. 369 [RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest 370 Access Authentication", RFC 7616, September 2015. 372 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 373 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 374 May 2017, . 376 6.2. Informative References 378 [RFC2617] Franks, J., M. Hallam-Baker, P., L. Hostetler, J., D. 379 Lawrence, S., J. Leach, P., Luotonen, A., and L. C. 380 Stewart, "HTTP Authentication: Basic and Digest Access 381 Authentication", RFC 2617, June 1999. 383 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 384 Specifications: ABNF", STD 68, RFC 5234, 385 DOI 10.17487/RFC5234, January 2008, 386 . 388 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 389 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 390 RFC 6151, DOI 10.17487/RFC6151, March 2011, 391 . 393 Author's Address 395 Rifaat Shekh-Yusef 396 Avaya 397 425 Legget Dr. 398 Ottawa, Ontario 399 Canada 401 Phone: +1-613-595-9106 402 EMail: rifaat.ietf@gmail.com