idnits 2.17.1 draft-ietf-httpauth-digest-update-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 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 (July 13, 2013) is 3932 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 79, but not defined == Unused Reference: 'RFC2617' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'FIPS180-3' is defined on line 346, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 July 13, 2013 6 Expires: January 14, 2014 8 HTTP Digest Update 9 draft-ietf-httpauth-digest-update-04 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 Status of this Memo 19 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright and License Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2 Syntax Convention . . . . . . . . . . . . . . . . . . . . . . . 3 58 3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 3 59 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1.1 Representation of digest values . . . . . . . . . . . . 3 61 3.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2 Specification of Digest Headers . . . . . . . . . . . . . . 4 63 3.2.1 The WWW-Authenticate Response Header . . . . . . . . . . 4 64 3.2.2 The Authorization Request Header . . . . . . . . . . . . 5 65 3.3 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 6 66 3.4 Security Protocol Operation . . . . . . . . . . . . . . . . 6 67 3.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 69 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 70 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9 72 6.2 Informative References . . . . . . . . . . . . . . . . . . 9 73 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 75 1 Introduction 77 This document specifies extensions to the HTTP Digest Access 78 Authentication scheme by adding support for SHA2-256 [FIPS 180-3] and 79 SHA2-512/256 [FIPS 180-3] hash algorithms. RFC2617 specifies the MD5 80 algorithm as the default hash algorithm used in the digest access 81 authentication scheme. Since RFC2617 was first proposed, the MD5 82 algorithm has been broken. In 2008 the US-CERT issued a note that 83 MD5 "should be considered cryptographically broken and unsuitable for 84 further use" [CERT-VU]. 86 1.1 Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC2119 [RFC2119]. 92 2 Syntax Convention 94 In the interest of clarity and readability, the extended parameters 95 or the headers and parameters in the examples in this document might 96 be broken into multiple lines. Any line that is indented in this 97 document is a continuation of the preceding line. 99 3 Digest Access Authentication Scheme 101 The Digest Access Authentication scheme is based on a simple 102 challenge-response paradigm. The Digest scheme challenges using a 103 nonce value. A valid response contains a checksum of the username, 104 the password, the given nonce value and the requested URI. In this 105 way the password is never sent in the clear. 107 3.1 Introduction 109 3.1.1 Representation of digest values 111 An optional header allows the server to specify the algorithm used to 112 create the checksum or digest. By default the SHA2-256 algorithm is 113 used, with SHA2-512/256 being used as a backup algorithm. To 114 maintain backwards compatibility, the MD5 algorithm is still 115 supported but not recommended. 117 The size of the digest depends on the algorithm used. The bits in 118 the digest are converted from the most significant to the least 119 significant bit, four bits at a time to the ASCII representation as 120 follows. Each four bits is represented by its familiar hexadecimal 121 notation from the characters 0123456789abcdef, that is binary 0000 is 122 represented by the character '0', 0001 by '1' and so on up to the 123 representation of 1111 as 'f'. If the MD5 algorithm is used to 124 calculate the digest, then the digest will be represented as 32 125 hexadecimal characters, SHA2-256 and SHA2-512/256 by 64 hexadecimal 126 characters. 128 3.1.2 Limitations 130 The Digest authentication scheme suffers from many known limitations 131 as specified in RFC2617, section 3.1.4. The update in this document 132 does not address those limitations. 134 HTTP Digest authentication, when used with human-memorable passwords, 135 is vulnerable to dictionary attacks. Such attacks are much easier 136 than cryptographic attacks on any widely used algorithm, including 137 those that are no longer considered secure. In other words, algorithm 138 agility does not make this usage any more secure. 140 As a result, Digest authentication SHOULD be used only with passwords 141 that have a reasonable amount of entropy, e.g. 128-bit or more. Such 142 passwords typically cannot be memorized by humans but can be used for 143 automated web services. 145 It is recommended that Digest authentication be used over a secure 146 channel like HTTPS. 148 3.2 Specification of Digest Headers 150 The modifications to the formats of the WWW-Authenticate Header line 151 and the Authorization header line are specified below. 153 3.2.1 The WWW-Authenticate Response Header 155 If a server receives a request for an access protected object, and an 156 acceptable Authorization header is not sent, the server responds with 157 a "401 Unauthorized" status code, and a WWW-Authenticate header. The 158 server MAY include multiple WWW-Authenticate headers to allow the 159 server to utilize the best available algorithm supported by the 160 client. 162 The algorithm directive is extended as follows: 164 algorithm = "algorithm" "=" ( 165 "MD5" | "MD5-sess" | 166 "SHA2-256" | "SHA2-256-sess" | 167 "SHA2-512-256" | "SHA2-512-256-sess" | 168 token) 170 Algorithm 171 A string indicating a pair of algorithms used to produce the 172 digest and a checksum. If the algorithm parameter is not present 173 it is assumed to be "MD5" to maintain backwards compatibility 174 with existing implementations. If the algorithm is not 175 understood, the challenge should be ignored and a different 176 challenge used if there is more than one. 178 The string obtained by applying the digest algorithm to the data 179 "data" with "secret" will be denoted KD(secret, data) and the 180 string obtained by applying the checksum algorithm to the data 181 "data" will be denoted H(data). The notation unq(x) means the 182 value of the quoted string X without the surrounding quotes. 184 For the "MD5 and "MD5-sess" algorithms 185 H(data) = MD5(data) 187 For the "SHA2-256" and "SHA2-256-sess" algorithms 188 H(data) = SHA2-256(data) 190 For the "SHA2-512-256" and "SHA2-512-256-sess" algorithms 191 H(data) = SHA2-512-256(data) 193 and 194 KD(secret, data) = H(concat(secret, ":", data)) 196 i.e the digest is the hash of the secret concatenated with a 197 colon concatenated with the data. The " -sess" algorithm is 198 intended to allow efficient 3rd party authentication servers; 199 for the difference in usage see the description in section 200 RFC2617, Section 3.2.2.2. 202 3.2.2 The Authorization Request Header 204 The client is expected to retry the request, passing an Authorization 205 Request Header line. The Authorization Request Header line is 206 modified as follows: 208 request-digest = <"> digest-size LHEX <"> 209 digest-size = "32" | "64" 211 The values of the opaque and algorithm fields must match those 212 supplied in the WWW-Authenticate response header for the entity being 213 requested. 215 response 216 A string of hex digits as defined in RFC2617 which proves 217 that the user knows a password. 219 3.3 Digest Operation 221 The modifications specified in this document does not introduce any 222 change to the digest operation specified in RFC2617. 224 3.4 Security Protocol Operation 226 When a server receives a request to access a resource, the server 227 might challenge the client by responding with "401 Unauthorized" 228 status code, and include one or more WWW-Authenticate headers. If the 229 server challenges with multiple Digest headers, then each one of 230 these headers MUST use a different digest algorithm. The server MUST 231 add these Digest headers to the response in order of preference, 232 starting with the most preferred header, followed by the less 233 preferred headers. 235 This specification defines the following preference list, starting 236 with the most preferred algorithm: 238 * SHA2-256 as the default algorithm. 239 * SHA2-512/256 as a backup algorithm. 240 * MD5 for backward compatibility. 242 A future version of this document might add SHA3 [SHA3] as a backup 243 algorithm, once its definition has been finalized and published. 245 When the client receives the response it SHOULD use the topmost 246 header that it supports, unless a local policy dictates otherwise. 247 The client should ignore any challenge it does not understand. 249 NOTE: There is some concern around the support for the SHA2-512/256 250 algorithm in the common implementation of SHA2. 252 3.5 Example 254 The following example is borrowed from RFC2617 and assumes that an 255 access protected document is being requested from the server via a 256 GET request. The URI of the document is 257 http://www.nowhere.org/dir/index.html". Both client and server know 258 that the username for this document is "Mufasa" and the password is 259 "Circle of Life" ( with one space between each of the three words). 261 The first time the client requests the document, no Authorization 262 header is sent, so the server responds with: 264 HTTP/1.1 401 Unauthorized 265 WWW-Authenticate: Digest 266 realm = "testrealm@host.com", 267 qop="auth, auth-int", 268 algorithm="SHA2-256", 269 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 270 opaque="5ccc069c403ebaf9f0171e9517f40e41" 271 WWW-Authenticate: Digest 272 realm="testrealm@host.com", 273 qop="auth, auth-int", 274 algorithm="MD5", 275 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 276 opaque="5ccc069c403ebaf9f0171e9517f40ef41" 278 The client may prompt the user for their username and password, after 279 which it will respond with a new request, including the following 280 Authorization header if the client chooses MD5 digest: 282 Authorization:Digest username="Mufasa", 283 realm="testrealm@host.com", 284 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 285 uri="/dir/index.html", 286 qop="auth", 287 algorithm="MD5", 288 nc=00000001, 289 cnonce="0a4f113b", 290 response="6629fae49393a05397450978507c4ef1", 291 opaque="5ccc069c403ebaf9f0171e9517f40e41" 293 If the client chooses to use the SHA2-256 algorithm for calculating 294 the response, the client responds with a new request including the 295 following Authorization header: 297 Authorization:Digest username="Mufasa", 298 realm="testrealm@host.com", 299 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 300 uri="/dir/index.html", 301 qop="auth", 302 algorithm="SHA2-256", 303 nc=00000001, 304 cnonce="0a4f113b", 305 response="5abdd07184ba512a22c53f41470e5eea7dcaa3a93 306 a59b630c13dfe0a5dc6e38b", 307 opaque="5ccc069c403ebaf9f0171e9517f40e41" 309 4 Security Considerations 311 This specification updates the Digest Access Authentication scheme 312 specified in RFC2617 to add support for the SHA2-256 and SHA2-512/256 313 hash algorithms. Support for these additional hash algorithms does 314 not alter the security properties of the Digest Access Authentication 315 scheme. 317 5 Acknowledgments 319 The authors would like to thank Geoff Baskwill and Eric Cooper for 320 their careful review and comments on the pre published version of 321 this document. 323 The authors would also like to thank Stephen Farrell, Yoav Nir, 324 Phillip Hallam-Baker, Manu Sporny, Paul Hoffman, Julian Reschke, and 325 Sean Turner for their careful review and comments on and off the 326 mailing list. 328 Special thanks to Yaron Sheffer for his thorough review, comments on 329 and off the list, and for the text he provided for the limitation 330 section. 332 6 References 334 6.1 Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, March 1997. 339 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 340 Leach, P., Luotonen, A., and L. Stewart, "HTTP 341 Authentication: Basic and Digest Access Authentication", 342 RFC 2617, June 1999. 344 6.2 Informative References 346 [FIPS180-3] National Institute of Standards and Technology 347 (NIST), FIPS Publication 180-3: Digital Signature 348 Standard, June 2009. 350 [CERT-VU] Vulnerability Note VU#836068, "MD5 vulnerable to 351 collision attacks", December 2008. 353 [SHA3] National Institute of Standards and Technology (NIST), 354 "CRYPTOGRAPHIC HASH AND SHA-3 STANDARD DEVELOPMENT". 355 http://csrc.nist.gov/groups/ST/hash/index.html 357 7 Authors' Addresses 359 Rifaat Shekh-Yusef 360 Avaya 361 250 Sydney Street 362 Belleville, Ontario 363 Canada 365 Phone: +1-613-967-5267 366 Email: rifaat.ietf@gmail.com 368 David Ahrens 369 Avaya 370 4655 Great America Parkway 371 Santa Clara, CA 95054 373 Phone: (408) 562-5502 374 EMail: davidahrens@avaya.com