idnits 2.17.1 draft-ietf-sipcore-digest-scheme-01.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 7, 2019) is 1813 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) 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) May 7, 2019 5 Intended status: Standards Track 6 Expires: November 8, 2019 8 The Session Initiation Protocol (SIP) Digest Authentication Scheme 9 draft-ietf-sipcore-digest-scheme-01 11 Abstract 13 This document updates the Digest Access Authentication scheme used by 14 the Session Initiation Protocol (SIP) to add support for secure 15 digest algorithms to replace the broken MD5 algorithm. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 8, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. The SIP Digest Authentication Scheme . . . . . . . . . . . . 3 66 2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 3 67 2.2. Representation of Digest Values . . . . . . . . . . . . . 3 68 2.3. The Authenticate Response Header Field . . . . . . . . . 4 69 2.4. The Authorization Request Header Field . . . . . . . . . 4 70 2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.6. HTTP Modifications . . . . . . . . . . . . . . . . . . . 5 72 3. Augmented BNF for the SIP Protocol . . . . . . . . . . . . . 6 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 76 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 The SIP protocol [RFC3261] uses the same mechanism used by the HTTP 82 protocol for authenticating users, which is a simple challenge- 83 response authentication mechanism that allows a server to challenge a 84 client request and allows a client to provide authentication 85 information in response to that challenge. 87 The SIP protocol uses the Digest Authentication scheme that is used 88 with the HTTP authentication mechanism, which by default uses MD5 as 89 the default algorithm. 91 The HTTP Digest Access Authentication [RFC7616] document defines the 92 Digest Authentication scheme and defines a few algorithms that could 93 be used with the Digest Authentication scheme, and establishes a 94 registry for these algorithms to allow for additional algorithms to 95 be added in the future. 97 This document updates the Digest Access Authentication scheme used by 98 SIP to support the list of digest algorithms defined in the "Hash 99 Algorithms for HTTP Digest Authentication" registry defined by 100 [RFC7616]. 102 1.1. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. The SIP Digest Authentication Scheme 110 This section describes the modifications to the operation of the 111 Digest mechanism as specified in [RFC3261] in order to support the 112 SHA- 256 and SHA-512/256 algorithms as described in [RFC7616], and 113 also to require support for the "qop" option." 115 2.1. Hash Algorithms 117 The Digest scheme has an 'algorithm' parameter that specifies the 118 algorithm to be used to compute the digest of the response. The IANA 119 registry named "HTTP Digest Hash Algorithms" specifies the algorithms 120 that correspond to 'algorithm' values, and specifies a priority for 121 each algorithm. 123 [RFC3261] specifies only one algorithm, MD5, which is used by 124 default. This document extends [RFC3261] to allow use of any 125 registered algorithm. 127 The priority of the algorithm defines its usage preference. UAs 128 SHOULD prefer algorithms with higher priorities. 130 Note that [RFC7616] defines a -sess variant for each algorithm; the 131 -sess variants are not used with SIP. 133 2.2. Representation of Digest Values 135 The size of the digest depends on the algorithm used. The bits in 136 the digest are converted from the most significant to the least 137 significant bit, four bits at a time to the ASCII representation as 138 follows. Each four bits is represented by its familiar hexadecimal 139 notation from the characters 0123456789abcdef, that is binary 0000 is 140 represented by the character '0', 0001 by '1' and so on up to the 141 representation of 1111 as 'f'. If the MD5 algorithm is used to 142 calculate the digest, then the digest will be represented as 32 143 hexadecimal characters, SHA-256 and SHA-512/256 by 64 hexadecimal 144 characters. 146 2.3. The Authenticate Response Header Field 148 When a UAS receives a request from a UAC, and an acceptable 149 Authorization header field is not sent, the UAS can challenge the 150 originator to provide credentials by rejecting the request with a 151 401/407 status code with the WWW-Authenticate/Proxy-Authenticate 152 header field. The UAS MAY include multiple WWW-Authenticate/Proxy- 153 Authenticate headers to allow the UAS to utilize the best available 154 algorithm supported by the client. 156 If the UAS challenges with multiple WWW-Authenticate/Proxy- 157 Authenticate headers with the same realm, then each one of these 158 headers MUST use a different digest algorithm. The UAS MUST add 159 these headers to the response in the order that it would prefer to 160 see them used, starting with the most preferred algorithm at the top, 161 followed by the less preferred algorithms. 163 2.4. The Authorization Request Header Field 165 When the UAC receives a response with multiple header fields with the 166 same realm it SHOULD use the topmost header field that it supports, 167 unless a local policy dictates otherwise. The client MUST ignore any 168 challenge it does not understand. 170 When the UAC receives a 401 response with multiple WWW-Authenticate 171 header fields with different realms it SHOULD retry and include an 172 Authorization header field containing credentials that match the 173 topmost header field of any one of the realms. 175 If the UAC cannot respond to any of the challenges in the response, 176 then it should abandon attempts to send the request; e.g., if the UAC 177 does not have credentials for any of the realms. 179 2.5. Forking 181 Section 22.3 of [RFC3261] discusses the operation of the proxy-to- 182 user authentication, which describes the operation of the proxy when 183 it forks a request. This section introduces some clarification to 184 that operation. 186 If a request is forked, various proxy servers and/or UAs may wish to 187 challenge the UAC. In this case, the forking proxy server is 188 responsible for aggregating these challenges into a single response. 189 Each WWW-Authenticate and Proxy-Authenticate value received in 190 responses to the forked request MUST be placed into the single 191 response that is sent by the forking proxy to the UA. 193 When the forking proxy places multiple WWW-Authenticate and Proxy- 194 Authenticate header fields from one received response into the single 195 response it MUST maintain the order of these header fields. The 196 ordering of the header field values from the various proxies is not 197 significant. 199 2.6. HTTP Modifications 201 This section describes the modifications and clarifications required 202 to apply the HTTP Digest authentication scheme to SIP. The SIP 203 scheme usage is similar to that for HTTP. For completeness, the 204 bullets specified below are mostly copied from section 22.4 of 205 [RFC3261]; the only semantic changes are specified in bullets 7 and 8 206 below. 208 SIP clients and servers MUST NOT accept or request Basic 209 authentication. 211 The rules for Digest authentication follow those defined in HTTP, 212 with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following 213 differences: 215 1. The URI included in the challenge has the following BNF: 217 URI = Request-URI ; as defined in [RFC3261], Section 25 219 2. The 'uri' parameter of the Authorization header field MUST be 220 enclosed in quotation marks. 222 3. The BNF for digest-uri-value is: 224 digest-uri-value = Request-URI 226 4. The example procedure for choosing a nonce based on Etag does not 227 work for SIP. 229 5. The text in [RFC7234] regarding cache operation does not apply to 230 SIP. 232 6. [RFC7616] requires that a server check that the URI in the 233 request line and the URI included in the Authorization header field 234 point to the same resource. In a SIP context, these two URIs may 235 refer to different users, due to forwarding at some proxy. 236 Therefore, in SIP, a server MAY check that the Request-URI in the 237 Authorization header field value corresponds to a user for whom the 238 server is willing to accept forwarded or direct requests, but it is 239 not necessarily a failure if the two fields are not equivalent. 241 7. As a clarification to the calculation of the A2 value for message 242 integrity assurance in the Digest authentication scheme, implementers 243 should assume, when the entity-body is empty (that is, when SIP 244 messages have no body) that the hash of the entity-body resolves to 245 the hash of an empty string: 247 H(entity-body) = ("") 249 For example, when the chosen algorithm is SHA-256, then: 251 H(entity-body) = SHA-256("") = 252 "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" 254 8. Servers MUST be able to properly handle "qop" parameter received 255 in an authorization header field, and clients MUST be able to 256 properly handle "qop" parameter received in WWW-Authenticate and 257 Proxy-Authenticate header fields. Servers MUST always send a "qop" 258 parameter in WWW-Authenticate and Proxy-Authenticate header field 259 values, and clients MUST send the "qop" parameter in any resulting 260 authorization header field. 262 The usage of the Authentication-Info header field continue to be 263 allowed, since it provides integrity checks over the bodies and 264 provides mutual authentication. 266 3. Augmented BNF for the SIP Protocol 268 This document updates the Augmented BNF for the SIP Protocol as 269 follows. 271 It extends the request-digest as follows to allow for different 272 digest sizes: 274 request-digest = LDQUOT *LHEX RDQUOT 276 The number of hex digits must be specified by the specification of 277 the algorithm used. 279 It extends the algorithm parameter as follows to allow for SHA2 280 algorithms to be used: 282 algorithm = "algorithm" EQUAL ( "MD5" / "SHA-512-256" / "SHA-256" 283 / token ) 285 4. Security Considerations 287 This specification adds new secure algorithms to be used to with the 288 Digest mechanism to authenticate users, but leaves the broken MD5 289 algorithm for backward compatibility. 291 This opens the system to the potential of a downgrade attack by man- 292 in-the-middle. The most effective way of dealing with this type of 293 attack is to either validate the client and challenge it accordingly, 294 or remove the support for backward compatibility by not supporting 295 MD5. 297 See section 5 of [RFC7616] for a detailed security discussion of the 298 Digest scheme. 300 5. IANA Considerations 302 [RFC7616] defines an IANA registry named "Hash Algorithms for HTTP 303 Digest Authentication" to simplify the introduction of new algorithms 304 in the future. This document will use the algorithms defined in that 305 registry. 307 6. Acknowledgments 309 The author would like to thank the following individuals for their 310 careful reviews, comments, and suggestions: Paul Kyzivat, Olle 311 Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga 312 Asveren, Christer Holmberg, and Brian Rosen. 314 7. Normative References 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, 320 A., Peterson, J., Sparks, R., Handley, M., and E. 321 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 322 June 2002. 324 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 325 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 326 2014. 328 [RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest 329 Access Authentication", RFC 7616, September 2015. 331 Author's Address 333 Rifaat Shekh-Yusef 334 Avaya 335 425 Legget Dr. 336 Ottawa, Ontario 337 Canada 339 Phone: +1-613-595-9106 340 EMail: rifaat.ietf@gmail.com