idnits 2.17.1 draft-ietf-httpauth-digest-update-05.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. -- The draft header indicates that this document updates RFC2617, 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 RFC2617, updated by this document, for RFC5378 checks: 1997-12-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2, 2013) is 3889 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: 'FIPS 180-3' is mentioned on line 84, but not defined == Unused Reference: 'RFC2617' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC6365' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'FIPS180-3' is defined on line 386, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAuth Working Group R. Shekh-Yusef 3 Internet-Draft D. Ahrens 4 Updates: 2617 (if approved) Avaya 5 Intended Status: Standards Track September 2, 2013 6 Expires: March 6, 2014 8 HTTP Digest Update 9 draft-ietf-httpauth-digest-update-05 11 Abstract 13 This documents specifies extensions to the HTTP Digest Authentication 14 mechanism to add support for new digest algorithms to the HTTP Digest 15 Access Authentication scheme. 17 This document also defines an extension to the HTTP Digest 18 Authentication mechanism to allow the server to indicate its support 19 for the UTF-8 character encoding scheme. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2 Syntax Convention . . . . . . . . . . . . . . . . . . . . . . . 3 62 3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 3 63 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1.1 Representation of digest values . . . . . . . . . . . . 4 65 3.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2 Specification of Digest Headers . . . . . . . . . . . . . . 5 67 3.2.1 The WWW-Authenticate Response Header . . . . . . . . . . 5 68 3.2.2 The Authorization Request Header . . . . . . . . . . . . 6 69 3.3 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 6 70 3.4 Security Protocol Operation . . . . . . . . . . . . . . . . 6 71 3.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4 Internationalization . . . . . . . . . . . . . . . . . . . . . 9 73 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 74 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7.1 Normative References . . . . . . . . . . . . . . . . . . . 10 77 7.2 Informative References . . . . . . . . . . . . . . . . . . 10 78 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 80 1 Introduction 82 This document specifies extensions to the HTTP Digest Access 83 Authentication scheme by adding support for SHA2-256 [FIPS 180-3] and 84 SHA2-512/256 [FIPS 180-3] hash algorithms. RFC2617 specifies the MD5 85 algorithm as the default hash algorithm used in the digest access 86 authentication scheme. Since RFC2617 was first proposed, the MD5 87 algorithm has been broken. In 2008 the US-CERT issued a note that 88 MD5 "should be considered cryptographically broken and unsuitable for 89 further use" [CERT-VU]. 91 RFC2617 does not define how to treat Unicode characters [UNICODE] 92 outside the ASCII range [RFC20] with the "Digest" scheme. This 93 document also defines an extension to the HTTP Digest Authentication 94 mechanism to allow the server to indicate its support for the UTF-8 95 character encoding scheme. 97 1.1 Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC2119 [RFC2119]. 103 2 Syntax Convention 105 In the interest of clarity and readability, the extended parameters 106 or the headers and parameters in the examples in this document might 107 be broken into multiple lines. Any line that is indented in this 108 document is a continuation of the preceding line. 110 3 Digest Access Authentication Scheme 112 The Digest Access Authentication scheme is based on a simple 113 challenge-response paradigm. The Digest scheme challenges using a 114 nonce value. A valid response contains a checksum of the username, 115 the password, the given nonce value and the requested URI. In this 116 way the password is never sent in the clear. 118 3.1 Introduction 120 3.1.1 Representation of digest values 122 An optional header allows the server to specify the algorithm used to 123 create the checksum or digest. By default the SHA2-256 algorithm is 124 used, with SHA2-512/256 being used as a backup algorithm. To 125 maintain backwards compatibility, the MD5 algorithm is still 126 supported but not recommended. 128 The size of the digest depends on the algorithm used. The bits in 129 the digest are converted from the most significant to the least 130 significant bit, four bits at a time to the ASCII representation as 131 follows. Each four bits is represented by its familiar hexadecimal 132 notation from the characters 0123456789abcdef, that is binary 0000 is 133 represented by the character '0', 0001 by '1' and so on up to the 134 representation of 1111 as 'f'. If the MD5 algorithm is used to 135 calculate the digest, then the digest will be represented as 32 136 hexadecimal characters, SHA2-256 and SHA2-512/256 by 64 hexadecimal 137 characters. 139 3.1.2 Limitations 141 The Digest authentication scheme suffers from many known limitations 142 as specified in RFC2617, section 3.1.4. The update in this document 143 does not address those limitations. 145 HTTP Digest authentication, when used with human-memorable passwords, 146 is vulnerable to dictionary attacks. Such attacks are much easier 147 than cryptographic attacks on any widely used algorithm, including 148 those that are no longer considered secure. In other words, algorithm 149 agility does not make this usage any more secure. 151 As a result, Digest authentication SHOULD be used only with passwords 152 that have a reasonable amount of entropy, e.g. 128-bit or more. Such 153 passwords typically cannot be memorized by humans but can be used for 154 automated web services. 156 It is recommended that Digest authentication be used over a secure 157 channel like HTTPS. 159 3.2 Specification of Digest Headers 161 The modifications to the formats of the WWW-Authenticate Header line 162 and the Authorization header line are specified below. 164 3.2.1 The WWW-Authenticate Response Header 166 If a server receives a request for an access protected object, and an 167 acceptable Authorization header is not sent, the server responds with 168 a "401 Unauthorized" status code, and a WWW-Authenticate header. The 169 server MAY include multiple WWW-Authenticate headers to allow the 170 server to utilize the best available algorithm supported by the 171 client. 173 The algorithm directive is extended as follows: 175 algorithm = "algorithm" "=" ( 176 "MD5" | "MD5-sess" | 177 "SHA2-256" | "SHA2-256-sess" | 178 "SHA2-512-256" | "SHA2-512-256-sess" | 179 token) 181 Algorithm 182 A string indicating a pair of algorithms used to produce the 183 digest and a checksum. If the algorithm parameter is not present 184 it is assumed to be "MD5" to maintain backwards compatibility 185 with existing implementations. If the algorithm is not 186 understood, the challenge should be ignored and a different 187 challenge used if there is more than one. 189 The string obtained by applying the digest algorithm to the data 190 "data" with "secret" will be denoted KD(secret, data) and the 191 string obtained by applying the checksum algorithm to the data 192 "data" will be denoted H(data). The notation unq(x) means the 193 value of the quoted string X without the surrounding quotes. 195 For the "MD5 and "MD5-sess" algorithms 196 H(data) = MD5(data) 198 For the "SHA2-256" and "SHA2-256-sess" algorithms 199 H(data) = SHA2-256(data) 201 For the "SHA2-512-256" and "SHA2-512-256-sess" algorithms 202 H(data) = SHA2-512-256(data) 204 and 205 KD(secret, data) = H(concat(secret, ":", data)) 207 i.e the digest is the hash of the secret concatenated with a 208 colon concatenated with the data. The " -sess" algorithm is 209 intended to allow efficient 3rd party authentication servers; 210 for the difference in usage see the description in section 211 RFC2617, Section 3.2.2.2. 213 3.2.2 The Authorization Request Header 215 The client is expected to retry the request, passing an Authorization 216 Request Header line. The Authorization Request Header line is 217 modified as follows: 219 request-digest = <"> digest-size LHEX <"> 220 digest-size = "32" | "64" 222 The values of the opaque and algorithm fields must match those 223 supplied in the WWW-Authenticate response header for the entity being 224 requested. 226 response 227 A string of hex digits as defined in RFC2617 which proves 228 that the user knows a password. 230 3.3 Digest Operation 232 The modifications specified in this document does not introduce any 233 change to the digest operation specified in RFC2617. 235 3.4 Security Protocol Operation 237 When a server receives a request to access a resource, the server 238 might challenge the client by responding with "401 Unauthorized" 239 status code, and include one or more WWW-Authenticate headers. If the 240 server challenges with multiple Digest headers, then each one of 241 these headers MUST use a different digest algorithm. The server MUST 242 add these Digest headers to the response in order of preference, 243 starting with the most preferred header, followed by the less 244 preferred headers. 246 This specification defines the following preference list, starting 247 with the most preferred algorithm: 249 * SHA2-256 as the default algorithm. 250 * SHA2-512/256 as a backup algorithm. 251 * MD5 for backward compatibility. 253 A future version of this document might add SHA3 [SHA3] as a backup 254 algorithm, once its definition has been finalized and published. 256 When the client receives the response it SHOULD use the topmost 257 header that it supports, unless a local policy dictates otherwise. 258 The client should ignore any challenge it does not understand. 260 NOTE: There is some concern around the support for the SHA2-512/256 261 algorithm in the common implementation of SHA2. 263 3.5 Example 265 The following example is borrowed from RFC2617 and assumes that an 266 access protected document is being requested from the server via a 267 GET request. The URI of the document is 268 http://www.nowhere.org/dir/index.html". Both client and server know 269 that the username for this document is "Mufasa" and the password is 270 "Circle of Life" ( with one space between each of the three words). 272 The first time the client requests the document, no Authorization 273 header is sent, so the server responds with: 275 HTTP/1.1 401 Unauthorized 276 WWW-Authenticate: Digest 277 realm = "testrealm@host.com", 278 qop="auth, auth-int", 279 algorithm="SHA2-256", 280 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 281 opaque="5ccc069c403ebaf9f0171e9517f40e41" 282 WWW-Authenticate: Digest 283 realm="testrealm@host.com", 284 qop="auth, auth-int", 285 algorithm="MD5", 286 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 287 opaque="5ccc069c403ebaf9f0171e9517f40ef41" 289 The client may prompt the user for their username and password, after 290 which it will respond with a new request, including the following 291 Authorization header if the client chooses MD5 digest: 293 Authorization:Digest username="Mufasa", 294 realm="testrealm@host.com", 295 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 296 uri="/dir/index.html", 297 qop="auth", 298 algorithm="MD5", 299 nc=00000001, 300 cnonce="0a4f113b", 301 response="6629fae49393a05397450978507c4ef1", 302 opaque="5ccc069c403ebaf9f0171e9517f40e41" 304 If the client chooses to use the SHA2-256 algorithm for calculating 305 the response, the client responds with a new request including the 306 following Authorization header: 308 Authorization:Digest username="Mufasa", 309 realm="testrealm@host.com", 310 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 311 uri="/dir/index.html", 312 qop="auth", 313 algorithm="SHA2-256", 314 nc=00000001, 315 cnonce="0a4f113b", 316 response="5abdd07184ba512a22c53f41470e5eea7dcaa3a93 317 a59b630c13dfe0a5dc6e38b", 318 opaque="5ccc069c403ebaf9f0171e9517f40e41" 320 4 Internationalization 322 The "Digest" mechanism allows for new parameters to be defined and 323 used with Authenticate and Authorization requests. This document 324 defines a new optional "charset" auth-param that could be used by the 325 server to indicate the encoding scheme it supports. 327 In challenges, servers MAY use the "charset" authentication parameter 328 (case-insensitive) to express the character encoding they expect the 329 user agent to use. 331 The only allowed value is "UTF-8", to be matched case-insensitively, 332 indicating that the server expects the UTF-8 character encoding to be 333 used ([RFC3629]). 335 5 Security Considerations 337 This specification updates the Digest Access Authentication scheme 338 specified in RFC2617 to add support for the SHA2-256 and SHA2-512/256 339 hash algorithms. Support for these additional hash algorithms does 340 not alter the security properties of the Digest Access Authentication 341 scheme. 343 6 Acknowledgments 345 The authors would like to thank Geoff Baskwill and Eric Cooper for 346 their careful review and comments on the pre published version of 347 this document. 349 The authors would also like to thank Stephen Farrell, Yoav Nir, 350 Phillip Hallam-Baker, Manu Sporny, Paul Hoffman, Julian Reschke, and 351 Sean Turner for their careful review and comments on and off the 352 mailing list. 354 Special thanks to Yaron Sheffer for his thorough review, comments on 355 and off the list, and for the text he provided for the limitation 356 section. 358 7 References 360 7.1 Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, March 1997. 365 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 366 Leach, P., Luotonen, A., and L. Stewart, "HTTP 367 Authentication: Basic and Digest Access Authentication", 368 RFC 2617, June 1999. 370 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 371 10646", STD 63, RFC 3629, November 2003. 373 [RFC6365] Hoffman, P., Klensin, J., "Terminology Used in 374 Internationalization in the IETF", BCP: 166, RFC 6365, 375 September 2011. 377 [UNICODE] The Unicode Consortium, "The Unicode Standard, 378 Version 6.0". 379 . 381 [RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20, 382 October 1969. 384 7.2 Informative References 386 [FIPS180-3] National Institute of Standards and Technology 387 (NIST), FIPS Publication 180-3: Digital Signature 388 Standard, June 2009. 390 [CERT-VU] Vulnerability Note VU#836068, "MD5 vulnerable to 391 collision attacks", December 2008. 393 [SHA3] National Institute of Standards and Technology (NIST), 394 "CRYPTOGRAPHIC HASH AND SHA-3 STANDARD DEVELOPMENT". 395 http://csrc.nist.gov/groups/ST/hash/index.html 397 8 Authors' Addresses 399 Rifaat Shekh-Yusef 400 Avaya 401 250 Sydney Street 402 Belleville, Ontario 403 Canada 405 Phone: +1-613-967-5267 406 Email: rifaat.ietf@gmail.com 408 David Ahrens 409 Avaya 411 EMail: ahrensdc@gmail.com