idnits 2.17.1 draft-ietf-sipcore-digest-scheme-09.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 (September 16, 2019) is 1683 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) ** 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 (~~), 1 warning (==), 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) September 16, 2019 5 Intended status: Standards Track 6 Expires: March 19, 2020 8 The Session Initiation Protocol (SIP) Digest Authentication Scheme 9 draft-ietf-sipcore-digest-scheme-09 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, which might be used 17 for backward compatibility reasons only. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 19, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. SIP Digest Authentication Scheme Updates . . . . . . . . . . 3 68 2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 3 69 2.2. Representation of Digest Values . . . . . . . . . . . . . 4 70 2.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 4 71 2.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 5 72 2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.6. HTTP Digest Authentication Scheme Modifications . . . . . 5 74 2.7. Augmented BNF for SIP . . . . . . . . . . . . . . . . . . 7 75 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 78 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 6.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 The Session Initiation Protocol [RFC3261] uses the same mechanism 86 that the Hypertext Transfer Protocol (HTTP) uses for authenticating 87 users. This mechanism is called Digest Access Authentication, and it 88 is a simple challenge-response mechanism that allows a server to 89 challenge a client request and allows a client to provide 90 authentication information in response to that challenge. The 91 version of Digest Access Authentication that [RFC3261] references is 92 specified in [RFC2617]. 94 The default hash algorithm for Digest Access Authentication is MD5. 95 However, it has been demonstrated that the MD5 algorithm is not 96 collision resistant, and is now considered a bad choice for a hash 97 function [RFC6151]. 99 The HTTP Digest Access Authentication [RFC7616] document obsoletes 100 [RFC2617] and adds stronger algorithms that can be used with the 101 Digest Authentication scheme, and establishes a registry for these 102 algorithms, known as the "Hash Algorithms for HTTP Digest 103 Authentication" registry, so that algorithms can be added in the 104 future. 106 This document updates the Digest Access Authentication scheme used by 107 SIP to support the algorithms listed in the "Hash Algorithms for HTTP 108 Digest Authentication" registry defined by [RFC7616]. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC8174]. 116 2. SIP Digest Authentication Scheme Updates 118 This section describes the modifications to the operation of the 119 Digest mechanism as specified in [RFC3261] in order to support the 120 algorithms defined in the "Hash Algorithms for HTTP Digest 121 Authentication" registry described in [RFC7616]. 123 It replaces the reference to [RFC2617] with a reference to [RFC7616] 124 in [RFC3261], and describes the modifications to the usage of the 125 Digest mechanism in [RFC3261] resulting from that reference update. 126 It adds support for the SHA-256 and SHA-512/256 algorithms. It adds 127 required support for the "qop" parameter. It provides additional 128 User Agent Client (UAC) and User Agent Server (UAS) procedures 129 regarding usage of multiple SIP Authorization, WWW-Authenticate and 130 Proxy-Authenticate header fields, including in which order to insert 131 and process them. It provides guidance regarding forking. Finally, 132 it updates the SIP BNF as required by the updates. 134 2.1. Hash Algorithms 136 The Digest scheme has an 'algorithm' parameter that specifies the 137 algorithm to be used to compute the digest of the response. The IANA 138 registry named "HTTP Digest Hash Algorithms" specifies the algorithms 139 that correspond to 'algorithm' values. 141 [RFC3261] specifies only one algorithm, MD5, which is used by 142 default. This document extends [RFC3261] to allow use of any 143 algorithm listed in the "Hash Algorithms for HTTP Digest 144 Authentication" registry. 146 A UAS prioritizes which algorithm to use based on the ordering of the 147 challenge header fields in the response it is processing. That 148 process is specified in section 2.3 and parallels the process used in 149 HTTP specified by [RFC7616]. 151 2.2. Representation of Digest Values 153 The size of the digest depends on the algorithm used. The bits in 154 the digest are converted from the most significant to the least 155 significant bit, four bits at a time to the ASCII representation as 156 follows. Each four bits is represented by its familiar hexadecimal 157 notation from the characters 0123456789abcdef, that is binary 0000 is 158 represented by the character '0', 0001 by '1' and so on up to the 159 representation of 1111 as 'f'. If the MD5 algorithm is used to 160 calculate the digest, then the digest will be represented as 32 161 hexadecimal characters, SHA-256 and SHA-512/256 by 64 hexadecimal 162 characters. 164 2.3. UAS Behavior 166 When a UAS receives a request from a UAC, and an acceptable 167 Authorization header field is not received, the UAS can challenge the 168 originator to provide credentials by rejecting the request with a 169 401/407 status code with the WWW-Authenticate/Proxy-Authenticate 170 header field respectively. The UAS MAY add multiple WWW- 171 Authenticate/Proxy-Authenticate header fields to allow the UAS to 172 utilize the best available algorithm supported by the client. 174 If the UAS challenges with multiple WWW-Authenticate/Proxy- 175 Authenticate header fields with the same realm, then each one of 176 these header fields MUST use a different digest algorithm. The UAS 177 MUST add these header fields to the response in the order that it 178 would prefer to see them used, starting with the most preferred 179 algorithm at the top, followed by the less preferred algorithms. The 180 UAS cannot assume that the client will use the algorithm specified at 181 the topmost header field. 183 2.4. UAC Behavior 185 When the UAC receives a response with multiple WWW-Authenticate/ 186 Proxy-Authenticate header fields with the same realm it SHOULD use 187 the topmost header field that it supports, unless a local policy 188 dictates otherwise. The client MUST ignore any challenge it does not 189 understand. 191 When the UAC receives a 401 response with multiple WWW-Authenticate 192 header fields with different realms it SHOULD retry and add an 193 Authorization header field containing credentials that match the 194 topmost header field of any one of the realms. 196 If the UAC cannot respond to any of the challenges in the response, 197 then it SHOULD abandon attempts to send the request, e.g. if the UAC 198 does not have credentials or has stale credentials for any of the 199 realms, unless a local policy dictates otherwise. 201 2.5. Forking 203 Section 22.3 of [RFC3261] discusses the operation of the proxy-to- 204 user authentication, which describes the operation of the proxy when 205 it forks a request. This section clarifies that operation. 207 If a request is forked, various proxy servers and/or UAs may wish to 208 challenge the UAC. In this case, the forking proxy server is 209 responsible for aggregating these challenges into a single response. 210 Each WWW-Authenticate and Proxy-Authenticate value received in 211 responses to the forked request MUST be placed into the single 212 response that is sent by the forking proxy to the UAC. 214 When the forking proxy places multiple WWW-Authenticate and Proxy- 215 Authenticate header fields from one received response into the single 216 response it MUST maintain the order of these header fields. The 217 ordering of values received from proxies relative to values received 218 from other proxies is not significant. 220 2.6. HTTP Digest Authentication Scheme Modifications 222 This section describes the modifications and clarifications required 223 to apply the HTTP Digest authentication scheme to SIP. The SIP 224 scheme usage is similar to that for HTTP. For completeness, the 225 bullets specified below are mostly copied from section 22.4 of 226 [RFC3261]; the only semantic changes are specified in bullets 1, 7, 227 and 8 below. 229 SIP clients and servers MUST NOT accept or request Basic 230 authentication. 232 The rules for Digest authentication follow those defined in HTTP, 233 with "HTTP/1.1" [RFC7616] replaced by "SIP/2.0" in addition to the 234 following differences: 236 1. The URI included in the challenge has the following BNF 237 [RFC5234]: 239 URI = Request-URI ; as defined in [RFC3261], Section 25 241 2. The 'uri' parameter of the Authorization header field MUST be 242 enclosed in quotation marks. 244 3. The BNF for digest-uri-value is: 246 digest-uri-value = Request-URI 248 4. The example procedure for choosing a nonce based on Etag does not 249 work for SIP. 251 5. The text in [RFC7234] regarding cache operation does not apply to 252 SIP. 254 6. [RFC7616] requires that a server check that the URI in the 255 request line and the URI included in the Authorization header field 256 point to the same resource. In a SIP context, these two URIs may 257 refer to different users, due to forwarding at some proxy. 258 Therefore, in SIP, a UAS MAY check that the Request-URI in the 259 Authorization/Proxy-Authorization header field value corresponds to a 260 user for whom the UAS is willing to accept forwarded or direct 261 requests, but it is not necessarily a failure if the two fields are 262 not equivalent. 264 7. As a clarification to the calculation of the A2 value for message 265 integrity assurance in the Digest authentication scheme, implementers 266 should assume, when the entity-body is empty (that is, when SIP 267 messages have no body) that the hash of the entity-body resolves to 268 the hash of an empty string: 270 H(entity-body) = ("") 272 For example, when the chosen algorithm is SHA-256, then: 274 H(entity-body) = SHA-256("") = 275 "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" 277 8. A UAS MUST be able to properly handle "qop" parameter received in 278 an Authorization/Proxy-Authorization header field, and a UAC MUST be 279 able to properly handle "qop" parameter received in WWW-Authenticate 280 and Proxy-Authenticate header fields. However, for backward 281 compatibility reasons, the "qop" parameter is optional for 282 RFC3261-based clients and servers to receive. 284 A UAS MUST always send a "qop" parameter in WWW-Authenticate and 285 Proxy-Authenticate header field values, and a UAC MUST send the "qop" 286 parameter in any resulting authorization header field. 288 The usage of the Authentication-Info header field continues to be 289 allowed, since it provides integrity checks over the bodies and 290 provides mutual authentication. 292 2.7. Augmented BNF for SIP 294 This document updates the Augmented BNF [RFC5234] for SIP as follows. 296 It extends the request-digest as follows to allow for different 297 digest sizes: 299 request-digest = LDQUOT *LHEX RDQUOT 301 The number of hex digits is implied by the length of the value of the 302 algorithm used. 304 It extends the algorithm parameter as follows to allow for any 305 algorithm in the registry to be used: 307 algorithm = "algorithm" EQUAL ( "MD5" / "SHA-512-256" / "SHA-256" 308 / token ) 310 3. Security Considerations 312 This specification adds new secure algorithms to be used with the 313 Digest mechanism to authenticate users, but leaves the broken MD5 314 algorithm for backward compatibility. 316 This opens the system to the potential of a downgrade attack by an 317 on-path attacker. The most effective way of dealing with this type 318 of attack is to either validate the client and challenge it 319 accordingly, or remove the support for backward compatibility by not 320 supporting MD5. 322 See section 5 of [RFC7616] for a detailed security discussion of the 323 Digest scheme. 325 4. IANA Considerations 327 [RFC7616] defines an IANA registry named "Hash Algorithms for HTTP 328 Digest Authentication" to simplify the introduction of new algorithms 329 in the future. This document specifies that algorithms defined in 330 that registry may be used in SIP digest authentication. 332 This document has no actions for IANA. 334 5. Acknowledgments 336 The author would like to thank the following individuals for their 337 careful reviews, comments, and suggestions: Paul Kyzivat, Olle 338 Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga 339 Asveren, Christer Holmberg, Brian Rosen, Jean Mahoney, and Adam 340 Roach. 342 6. References 344 6.1. Normative References 346 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, 347 A., Peterson, J., Sparks, R., Handley, M., and E. 348 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 349 June 2002. 351 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 352 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 353 2014. 355 [RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest 356 Access Authentication", RFC 7616, September 2015. 358 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 359 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 360 May 2017, . 362 6.2. Informative References 364 [RFC2617] Franks, J., M. Hallam-Baker, P., L. Hostetler, J., D. 365 Lawrence, S., J. Leach, P., Luotonen, A., and L. C. 366 Stewart, "HTTP Authentication: Basic and Digest Access 367 Authentication", RFC 2617, June 1999. 369 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 370 Specifications: ABNF", STD 68, RFC 5234, 371 DOI 10.17487/RFC5234, January 2008, 372 . 374 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 375 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 376 RFC 6151, DOI 10.17487/RFC6151, March 2011, 377 . 379 Author's Address 381 Rifaat Shekh-Yusef 382 Avaya 383 425 Legget Dr. 384 Ottawa, Ontario 385 Canada 387 Phone: +1-613-595-9106 388 EMail: rifaat.ietf@gmail.com