idnits 2.17.1 draft-ietf-sipcore-digest-scheme-04.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to mention this, which it should. 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 (May 28, 2019) is 1795 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 (==), 4 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) May 28, 2019 5 Intended status: Standards Track 6 Expires: November 29, 2019 8 The Session Initiation Protocol (SIP) Digest Authentication Scheme 9 draft-ietf-sipcore-digest-scheme-04 11 Abstract 13 This document updates the Digest Access Authentication scheme used by 14 the Session Initiation Protocol (SIP) to add support for more secure 15 digest algorithms, e.g. SHA-256 and SHA-512-256, to replace the 16 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 November 29, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . 4 71 2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.6. HTTP Modifications . . . . . . . . . . . . . . . . . . . 5 73 2.7. Augmented BNF for the SIP Protocol . . . . . . . . . . . 7 74 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 6.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 The SIP protocol [RFC3261] uses the same mechanism used by the HTTP 85 protocol for authenticating users, which is a simple challenge- 86 response authentication mechanism that allows a server to challenge a 87 client request and allows a client to provide authentication 88 information in response to that challenge. 90 The SIP protocol uses the Digest Authentication scheme that is used 91 with the HTTP authentication mechanism, which uses MD5 as the default 92 algorithm. 94 The HTTP Digest Access Authentication [RFC7616] document defines the 95 Digest Authentication scheme and defines a few algorithms that could 96 be used with the Digest Authentication scheme, and establishes a 97 registry for these algorithms to allow for additional algorithms to 98 be added in the future. 100 This document updates the Digest Access Authentication scheme used by 101 SIP to support the algorithms defined in the "Hash Algorithms for 102 HTTP Digest Authentication" registry defined by [RFC7616]. 104 1.1. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. SIP Digest Authentication Scheme Updates 112 This section describes the modifications to the operation of the 113 Digest mechanism as specified in [RFC3261] in order to support the 114 algorithms defined in the "Hash Algorithms for HTTP Digest 115 Authentication" registry described in [RFC7616]. 117 It replaces the reference to [RFC2617] with a reference to [RFC7616] 118 in [RFC3261], and describes the modifications to the usage of the 119 Digest mechanism in [RFC3261] resulting from that reference update. 120 It adds support for the SHA-256 and SHA-512/256 algorithms. It adds 121 required support for the "qop" option. It provides additional UAC 122 and UAS procedures regarding usage of multiple SIP Authorization, 123 WWW-Authenticate and Proxy-Authenticate header fields, including in 124 which order to insert and process them. It provides guidance 125 regarding forking. Finally, it updates the SIP protocol BNF as 126 required by the updates. 128 2.1. Hash Algorithms 130 The Digest scheme has an 'algorithm' parameter that specifies the 131 algorithm to be used to compute the digest of the response. The IANA 132 registry named "HTTP Digest Hash Algorithms" specifies the algorithms 133 that correspond to 'algorithm' values, and specifies a priority for 134 each algorithm. 136 [RFC3261] specifies only one algorithm, MD5, which is used by 137 default. This document extends [RFC3261] to allow use of any 138 registered algorithm. 140 A UAS prioritizes which algorithm to use based on the ordering of the 141 challenge header fields in the response it is processing. That 142 process is specified in section 2.3 and parallels the process used in 143 HTTP specified by [RFC7616]. 145 2.2. Representation of Digest Values 147 The size of the digest depends on the algorithm used. The bits in 148 the digest are converted from the most significant to the least 149 significant bit, four bits at a time to the ASCII representation as 150 follows. Each four bits is represented by its familiar hexadecimal 151 notation from the characters 0123456789abcdef, that is binary 0000 is 152 represented by the character '0', 0001 by '1' and so on up to the 153 representation of 1111 as 'f'. If the MD5 algorithm is used to 154 calculate the digest, then the digest will be represented as 32 155 hexadecimal characters, SHA-256 and SHA-512/256 by 64 hexadecimal 156 characters. 158 2.3. UAS Behavior 160 When a UAS receives a request from a UAC, and an acceptable 161 Authorization header field is not received, the UAS can challenge the 162 originator to provide credentials by rejecting the request with a 163 401/407 status code with the WWW-Authenticate/Proxy-Authenticate 164 header field respectively. The UAS MAY add multiple WWW- 165 Authenticate/Proxy-Authenticate header fields to allow the UAS to 166 utilize the best available algorithm supported by the client. 168 If the UAS challenges with multiple WWW-Authenticate/Proxy- 169 Authenticate header fields with the same realm, then each one of 170 these header fields MUST use a different digest algorithm. The UAS 171 MUST add these header fields to the response in the order that it 172 would prefer to see them used, starting with the most preferred 173 algorithm at the top, followed by the less preferred algorithms. The 174 UAS cannot assume that the client will use the algorithm specified at 175 the topmost header field. 177 2.4. UAC Behavior 179 When the UAC receives a response with multiple WWW-Authenticate/ 180 Proxy- Authenticate header fields with the same realm it SHOULD use 181 the topmost header field that it supports, unless a local policy 182 dictates otherwise. The client MUST ignore any challenge it does not 183 understand. 185 When the UAC receives a 401 response with multiple WWW-Authenticate 186 header fields with different realms it SHOULD retry and add an 187 Authorization header field containing credentials that match the 188 topmost header field of any one of the realms. 190 If the UAC cannot respond to any of the challenges in the response, 191 then it SHOULD abandon attempts to send the request, e.g. if the UAC 192 does not have credentials or has stale credentials for any of the 193 realms, unless a local policy dictates otherwise. 195 2.5. Forking 197 Section 22.3 of [RFC3261] discusses the operation of the proxy-to- 198 user authentication, which describes the operation of the proxy when 199 it forks a request. This section introduces some clarification to 200 that operation. 202 If a request is forked, various proxy servers and/or UAs may wish to 203 challenge the UAC. In this case, the forking proxy server is 204 responsible for aggregating these challenges into a single response. 205 Each WWW-Authenticate and Proxy-Authenticate value received in 206 responses to the forked request MUST be placed into the single 207 response that is sent by the forking proxy to the UA. 209 When the forking proxy places multiple WWW-Authenticate and Proxy- 210 Authenticate header fields from one received response into the single 211 response it MUST maintain the order of these header fields. The 212 ordering of the header field values from the various proxies is not 213 significant. 215 2.6. HTTP Modifications 217 This section describes the modifications and clarifications required 218 to apply the HTTP Digest authentication scheme to SIP. The SIP 219 scheme usage is similar to that for HTTP. For completeness, the 220 bullets specified below are mostly copied from section 22.4 of 221 [RFC3261]; the only semantic changes are specified in bullets 7 and 8 222 below. 224 SIP clients and servers MUST NOT accept or request Basic 225 authentication. 227 The rules for Digest authentication follow those defined in HTTP, 228 with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following 229 differences: 231 1. The URI included in the challenge has the following BNF: 233 URI = Request-URI ; as defined in [RFC3261], Section 25 235 2. The 'uri' parameter of the Authorization header field MUST be 236 enclosed in quotation marks. 238 3. The BNF for digest-uri-value is: 240 digest-uri-value = Request-URI 242 4. The example procedure for choosing a nonce based on Etag does not 243 work for SIP. 245 5. The text in [RFC7234] regarding cache operation does not apply to 246 SIP. 248 6. [RFC7616] requires that a server check that the URI in the 249 request line and the URI included in the Authorization header field 250 point to the same resource. In a SIP context, these two URIs may 251 refer to different users, due to forwarding at some proxy. 252 Therefore, in SIP, a server MAY check that the Request-URI in the 253 Authorization header field value corresponds to a user for whom the 254 server is willing to accept forwarded or direct requests, but it is 255 not necessarily a failure if the two fields are not equivalent. 257 7. As a clarification to the calculation of the A2 value for message 258 integrity assurance in the Digest authentication scheme, implementers 259 should assume, when the entity-body is empty (that is, when SIP 260 messages have no body) that the hash of the entity-body resolves to 261 the hash of an empty string: 263 H(entity-body) = ("") 265 For example, when the chosen algorithm is SHA-256, then: 267 H(entity-body) = SHA-256("") = 268 "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" 270 8. Servers MUST be able to properly handle "qop" parameter received 271 in an authorization header field, and clients MUST be able to 272 properly handle "qop" parameter received in WWW-Authenticate and 273 Proxy-Authenticate header fields. However, for backward 274 compatibility reasons, the "qop" parameter is optional for 275 RFC3261-based clients and servers to receive. 277 Servers MUST always send a "qop" parameter in WWW-Authenticate and 278 Proxy-Authenticate header field values, and clients MUST send the 279 "qop" parameter in any resulting authorization header field. 281 The usage of the Authentication-Info header field continue to be 282 allowed, since it provides integrity checks over the bodies and 283 provides mutual authentication. 285 2.7. Augmented BNF for the SIP Protocol 287 This document updates the Augmented BNF for the SIP Protocol as 288 follows. 290 It extends the request-digest as follows to allow for different 291 digest sizes: 293 request-digest = LDQUOT *LHEX RDQUOT 295 The number of hex digits is implied by the length of the value of the 296 algorithm used. 298 It extends the algorithm parameter as follows to allow for any 299 algorithm in the registry to be used: 301 algorithm = "algorithm" EQUAL ( "MD5" / "SHA-512-256" / "SHA-256" 302 / token ) 304 3. Security Considerations 306 This specification adds new secure algorithms to be used to with the 307 Digest mechanism to authenticate users, but leaves the broken MD5 308 algorithm for backward compatibility. 310 This opens the system to the potential of a downgrade attack by man- 311 in-the-middle. The most effective way of dealing with this type of 312 attack is to either validate the client and challenge it accordingly, 313 or remove the support for backward compatibility by not supporting 314 MD5. 316 See section 5 of [RFC7616] for a detailed security discussion of the 317 Digest scheme. 319 4. IANA Considerations 321 [RFC7616] defines an IANA registry named "Hash Algorithms for HTTP 322 Digest Authentication" to simplify the introduction of new algorithms 323 in the future. This document specifies that algorithms defined in 324 that registry may be used in SIP digest authentication. 326 5. Acknowledgments 328 The author would like to thank the following individuals for their 329 careful reviews, comments, and suggestions: Paul Kyzivat, Olle 330 Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga 331 Asveren, Christer Holmberg, and Brian Rosen. 333 6. References 335 6.1. Normative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, 341 A., Peterson, J., Sparks, R., Handley, M., and E. 342 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 343 June 2002. 345 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 346 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 347 2014. 349 [RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest 350 Access Authentication", RFC 7616, September 2015. 352 6.2. Informative References 354 [RFC2617] Franks, J., M. Hallam-Baker, P., L. Hostetler, J., D. 355 Lawrence, S., J. Leach, P., Luotonen, A., and L. C. 356 Stewart, "HTTP Authentication: Basic and Digest Access 357 Authentication", RFC 2617, June 1999. 359 Author's Address 361 Rifaat Shekh-Yusef 362 Avaya 363 425 Legget Dr. 364 Ottawa, Ontario 365 Canada 367 Phone: +1-613-595-9106 368 EMail: rifaat.ietf@gmail.com