idnits 2.17.1 draft-yusef-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 25, 2014) is 3734 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: 'RFC3261' is mentioned on line 74, but not defined == Missing Reference: 'CERT-VU' is mentioned on line 92, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'HTTP-DIGEST' Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group R. Shekh-Yusef 3 INTERNET-DRAFT Avaya 4 Intended Status: Standards Track January 25, 2014 5 Expires: July 29, 2014 7 The Session Initiation Protocol (SIP) Digest Authentication Scheme 8 draft-yusef-sipcore-digest-scheme-04 10 Abstract 12 This document updates the Digest Access Authentication scheme used by 13 the Session Initiation Protocol (SIP) to add support for SHA2 digest 14 algorithms to replace the MD5 algorithm. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright and License Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2 The SIP Digest Authentication Scheme . . . . . . . . . . . . . 4 57 2.1 Hash Algorithms . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2 Representation of Digest Values . . . . . . . . . . . . . . 4 59 2.3 The Authenticate Response Header . . . . . . . . . . . . . 4 60 2.4 The Authorization Request Header . . . . . . . . . . . . . 5 61 2.5 Forking . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.6 HTTP Modifications . . . . . . . . . . . . . . . . . . . . 6 63 3 Augmented BNF for the SIP Protocol . . . . . . . . . . . . . . 8 64 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 65 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1 Normative References . . . . . . . . . . . . . . . . . . . 9 69 7.2 Informative References . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1 Introduction 74 The SIP protocol [RFC3261] uses the same mechanism used by the HTTP 75 protocol for authenticating users, which is a simple challenge- 76 response authentication mechanism that allows a server to challenge a 77 client request and allows a client to provide authentication 78 information in response to that challenge. 80 The SIP protocol uses the Digest Authentication scheme that is used 81 with the HTTP authentication mechanism, which by default uses MD5 as 82 the default algorithm. 84 The HTTP Digest Access Authentication [HTTP-DIGEST] document defines 85 the challenge-response authentication mechanism and the Digest 86 Authentication scheme, and defines few algorithms that could be used 87 with the Digest Authentication scheme, and establishes a registry for 88 these algorithms to allow for additional algorithms to be added in 89 the future. 91 In 2008 the US-CERT issued a note that MD5 "should be considered 92 cryptographically broken and unsuitable for further use" [CERT-VU]. 94 This document updates the Digest Access Authentication scheme used by 95 SIP to add support for SHA2 digest algorithms to replace the MD5 96 algorithm. 98 1.1 Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2 The SIP Digest Authentication Scheme 106 This section describes the modifications to the operation of the 107 Digest mechanism as specified in RFC3261 in order to support the SHA- 108 256 and SHA-512/256 algorithms as described in [HTTP-DIGEST], and 109 also to require support for the "qop" option." 111 2.1 Hash Algorithms 113 The Digest scheme has an 'algorithm' parameter that specifies the 114 algorithm to be used to compute the digest of the response. The IANA 115 registry named "HTTP Digest Hash Algorithms" specifies the algorithms 116 that correspond to 'algorithm' values, and specifies a priority for 117 each algorithm. 119 RFC3261 specifies only one algorithm, MD5, which is used by default. 120 This document adds two new algorithms, to align with the [HTTP- 121 DIGEST], that SHOULD be used instead of MD5: SHA-256 & SHA-512/256. 123 The priority of the algorithm defines its usage preference. UAs 124 SHOULD prefer algorithms with higher priorities. 126 Note that [HTTP-DIGEST] defines a -sess variant for each algorithm; 127 the -sess variants are not used with SIP. 129 2.2 Representation of Digest Values 131 The size of the digest depends on the algorithm used. The bits in 132 the digest are converted from the most significant to the least 133 significant bit, four bits at a time to the ASCII representation as 134 follows. Each four bits is represented by its familiar hexadecimal 135 notation from the characters 0123456789abcdef, that is binary 0000 is 136 represented by the character '0', 0001 by '1' and so on up to the 137 representation of 1111 as 'f'. If the MD5 algorithm is used to 138 calculate the digest, then the digest will be represented as 32 139 hexadecimal characters, SHA-256 and SHA-512/256 by 64 hexadecimal 140 characters. 142 2.3 The Authenticate Response Header 144 When a UAS receives a request from a UAC, and an acceptable 145 Authorization header is not sent, the UAS can challenge the 146 originator to provide credentials by rejecting the request with a 147 401/407 status code with the WWW-Authenticate/Proxy-Authenticate 148 header field. The UAS MAY include multiple WWW-Authenticate/Proxy- 149 Authenticate headers to allow the UAS to utilize the best available 150 algorithm supported by the client. 152 If the UAS challenges with multiple WWW-Authenticate/Proxy- 153 Authenticate headers with the same realm, then each one of these 154 headers MUST use a different digest algorithm. The UAS MUST add these 155 headers to the response in the order that it would prefer to see them 156 used, starting with the most preferred algorithm at the top, followed 157 by the less preferred algorithms. 159 2.4 The Authorization Request Header 161 When the UAC receives a response with multiple headers with the same 162 realm it SHOULD use the topmost header that it supports, unless a 163 local policy dictates otherwise. The client should ignore any 164 challenge it does not understand. 166 When the UAC receives a response with multiple headers with different 167 realms it SHOULD provide all credentials that it possesses that match 168 any one of the challenges. 170 If the UAC cannot respond to any of the challenges in the response, 171 then it should abandon attempts to send the request; e.g., if the UAC 172 does not have credentials for any of the realms. 174 2.5 Forking 176 RFC3261, section 22.3, discusses the operation of the proxy-to-user 177 authentication, which describes the operation of the proxy when it 178 forks a request. This section introduces some clarification to that 179 operation. 181 If a request is forked, various proxy servers and/or UAs may wish to 182 challenge the UAC. In this case, the forking proxy server is 183 responsible for aggregating these challenges into a single response. 184 Each WWW-Authenticate and Proxy-Authenticate value received in 185 responses to the forked request MUST be placed into the single 186 response that is sent by the forking proxy to the UA. 188 When the forking proxy places multiple WWW-Authenticate and Proxy- 189 Authenticate header fields from one received response into the single 190 response it MUST maintain the order of these header fields. The 191 ordering of the header field values from the various proxies is not 192 significant. 194 2.6 HTTP Modifications 196 This section describes the modifications and clarifications required 197 to apply the HTTP Digest authentication scheme to SIP. The SIP scheme 198 usage is similar to that for HTTP. 200 SIP clients and servers MUST NOT accept or request Basic 201 authentication. 203 The rules for Digest authentication follow those defined in HTTP, 204 with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following 205 differences: 207 1. The URI included in the challenge has the following BNF: 209 URI = SIP-URI / SIPS-URI 211 2. The BNF for digest-uri-value is: 213 digest-uri-value = Request-URI ; as defined in Section 25 215 3. The example procedure for choosing a nonce based on Etag does not 216 work for SIP. 218 4. The text in [HTTP-DIGEST] regarding cache operation does not 219 apply to SIP. 221 5. [HTTP-DIGEST] requires that a server check that the URI in the 222 request line and the URI included in the Authorization header 223 field point to the same resource. In a SIP context, these two 224 URIs may refer to different users, due to forwarding at some 225 proxy. Therefore, in SIP, a server MAY check that the 226 Request-URI in the Authorization header field value 227 corresponds to a user for whom the server is willing to accept 228 forwarded or direct requests, but it is not necessarily a 229 failure if the two fields are not equivalent. 231 6. As a clarification to the calculation of the A2 value for 232 message integrity assurance in the Digest authentication 233 scheme, implementers should assume, when the entity-body is 234 empty (that is, when SIP messages have no body) that the hash 235 of the entity-body resolves to the hash of an empty 236 string: 238 H(entity-body) = chosen-algorithm("") 240 For example, when the chosen algorithm is SHA-256, then: 242 H(entity-body) = SHA-256("") = 243 "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" 245 7. Servers MUST be able to properly handle "qop" parameter received 246 in an authorization header field, and clients MUST be able to 247 properly handle "qop" parameter received in WWW-Authenticate and 248 Proxy-Authenticate header fields. 250 Servers MUST always send a "qop" parameter in WWW-Authenticate 251 and Proxy-Authenticate header field values, and clients MUST 252 send the "qop" parameter in any resulting authorization header 253 field. 255 The usage of the Authentication-Info header field continue to be 256 allowed, since it provides integrity checks over the bodies and 257 provides mutual authentication. 259 ***[OPEN ISSUE]*** 261 This section does NOT maintain backward compatibility with RFC 2069. 262 Are there SIP servers and clients out there that support only RFC 263 2069 that would break because of this? 265 3 Augmented BNF for the SIP Protocol 267 This document updates the Augmented BNF for the SIP Protocol as 268 follows. 270 It extends the request-digest as follows to allow for different 271 digest sizes: 273 request-digest = LDQUOT *LHEX RDQUOT 275 The number of hex digits must be specified by the specification of 276 the algorithm used. 278 It extends the algorithm parameter as follows to allow for SHA2 279 algorithms to be used: 281 algorithm = "algorithm" EQUAL ( 282 283 / token ) 285 4 Security Considerations 287 289 5 IANA Considerations 291 The [HTTP-DIGEST] defines an IANA registry named "HTTP Digest Hash 292 Algorithms" to simplify the introduction of new algorithms in the 293 future. This document will use the algorithms defined in that 294 registry. 296 6 Acknowledgments 298 300 7 References 302 7.1 Normative References 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [HTTP-DIGEST] Shekh-Yusef, R., Ahrens, D., and Bremer, S., "HTTP 308 Digest Access Authentication", Work in Progress, January 309 2014. 311 https://datatracker.ietf.org/doc/draft-ietf-httpauth- 312 digest/ 314 7.2 Informative References 316 Authors' Addresses 318 Rifaat Shekh-Yusef 319 Avaya 320 250 Sydney Street 321 Belleville, Ontario 322 Canada 324 Phone: +1-613-967-5267 325 Email: rifaat.ietf@gmail.com