idnits 2.17.1 draft-ietf-httpauth-digest-update-00.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 (June 10, 2013) is 3965 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: 'RFC2119' is mentioned on line 106, but not defined == Unused Reference: 'KEYWORDS' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 345, 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 June 10, 2013 6 Expires: December 12, 2013 8 HTTP Digest Update 9 draft-ietf-httpauth-digest-update-00 11 Abstract 13 This documents specifies extensions to the HTTP Digest Authentication 14 mechanism to add support for more digest algorithms to the HTTP 15 Digest Access Authentication scheme. 17 This document also specifies an extension to HTTP Digest 18 Authentication mechanism to allow the server to indicate its 19 character encoding support. 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 Digest Access Authentication Scheme . . . . . . . . . . . . . . 3 62 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1.1 Representation of digest values . . . . . . . . . . . . 3 64 2.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2 Specification of Digest Headers . . . . . . . . . . . . . . 4 66 2.2.1 The WWW-Authenticate Response Header . . . . . . . . . . 4 67 2.2.2 The Authorization Request Header . . . . . . . . . . . . 5 68 2.3 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 6 69 2.4 Security Protocol Operation . . . . . . . . . . . . . . . . 6 70 2.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3 Internationalization . . . . . . . . . . . . . . . . . . . . . 7 72 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 73 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9 76 6.2 Informative References . . . . . . . . . . . . . . . . . . 9 77 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 79 1 Introduction 81 This document updates two aspects of the HTTP Digest mechanism 82 specified in RFC2617: Algorithm agility, and character set 83 internationalization. 85 This document specifies extensions to the HTTP Digest Access 86 Authentication scheme by adding support for the SHA1 and SHA2 suite 87 of hash algorithms. RFC 2617 specifies the MD5 algorithm as the 88 default hash algorithm used in the digest access authentication 89 scheme. Since RFC 2617 was first proposed, the MD5 algorithm has 90 been broken. In 2008 the US-CERT issued a note that MD5 "should be 91 considered cryptographically broken and unsuitable for further use." 93 RFC2617 does not define how to treat non-ASCII characters with the 94 "Basic" and "Digest" schemes. This has lead to interoperability 95 problems between user agents and proxies. 97 This document specifies an extension to HTTP Digest Authentication 98 mechanism to allow the server to indicate its character encoding 99 support. 101 1.1 Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 2 Digest Access Authentication Scheme 109 The Digest Access Authentication scheme is based on a simple 110 challenge-response paradigm. The Digest scheme challenges using a 111 nonce value. A valid response contains a checksum of the username, 112 the password, the given nonce value and the requested URI. In this 113 way the password is never sent in the clear. 115 2.1 Introduction 117 2.1.1 Representation of digest values 119 An optional header allows the server to specify the algorithm used to 120 create the checksum or digest. By default and to maintain backwards 121 compatibility, the MD5 algorithm is used. 123 The size of the digest depends on the algorithm used. The bits in 124 the digest are converted from the most significant to the least 125 significant bit, four bits at a time to the ASCII representation as 126 follows. Each four bits is represented by its familiar hexadecimal 127 notation from the characters 0123456789abcdef, that is binary 0000 is 128 represented by the character '0', 0001 by '1' and so on up to the 129 representation of 1111 as 'f'. If the MD5 algorithm is used to 130 calculate the digest, then the digest will be represented as 32 131 hexadecimal characters, SHA1 by 40 hexadecimal characters, SHA2-224 132 by 56 hexadecimal characters, SHA2-256 by 64 hexadecimal characters, 133 SHA2-384 by 96 hexadecimal characters, and SHA2-512 by 128 134 hexadecimal characters. 136 2.1.2 Limitations 138 The Digest authentication scheme suffers from many known limitations 139 as specified in RFC2617, section 3.1.4. The update in this document 140 does not address those limitations. 142 2.2 Specification of Digest Headers 144 The modifications to the formats of the WWW-Authenticate Header line 145 and the Authorization header line are specified below. 147 2.2.1 The WWW-Authenticate Response Header 149 If a server receives a request for an access protected object, and an 150 acceptable Authorization header is not sent, the server responds with 151 a "401 Unauthorized" status code, and a WWW-Authenticate header. The 152 server MAY include multiple WWW-Authenticate headers to allow the 153 server to utilize the best available algorithm supported by the 154 client. 156 The algorithm directive is extended as follows: 158 algorithm = "algorithm" "=" ("MD5" | "MD5-sess" | 159 "SHA1" | "SHA1-sess" | 160 "SHA224" | "SHA224-sess" | 161 "SHA256" | "SHA256-sess" | 162 "SHA384" | "SHA384-sess" | 163 "SHA512" | "SHA512-sess" | 164 token) 166 Algorithm 167 A string indicating a pair of algorithms used to produce the 168 digest and a checksum. If the algorithm parameter is not present 169 it is assumed to be "MD5" to maintain backwards compatibility 170 with existing implementations. If the algorithm is not 171 understood, the challenge should be ignored and a different 172 challenge used if there is more than one. 174 The string obtained by applying the digest algorithm to the data 175 "data" with "secret" will be denoted KD(secret, data) and the 176 string obtained by applying the checksum algorithm to the data 177 "data" will be denoted H(data). The notation unq(x) means the 178 value of the quoted string X without the surrounding quotes. 180 For the "MD5 and "MD5-sess" algorithms 181 H(data) = MD5(data) 183 For the "SHA1" and "SHA1-sess" algorithms 184 H(data) = SHA1(data) 186 For the "SHA224" and "SHA224-sess" algorithms 187 H(data) = SHA224(data) 189 For the "SHA256" and "SHA256-sess" algorithms 190 H(data) = SHA256(data) 192 For the "SHA384" and "SHA384-sess" algorithms 193 H(data) = SHA384(data) 195 For the "SHA512" and "SHA512-sess" algorithms 196 H(data) = SHA512(data) 198 and 199 KD(secret, data) = H(concat(secret, ":", data)) 201 i.e the digest is the hash of the secret concatenated with a 202 colon concatenated with the data. The " -sess" algorithm is 203 intended to allow efficient 3rd party authentication servers; 204 for the difference in usage see the description in section 205 RFC2617, Section 3.2.2.2. 207 2.2.2 The Authorization Request Header 209 The client is expected to retry the request, passing an Authorization 210 Request Header line. The Authorization Request Header line is 211 modified as follows: 213 request-digest = <"> digest-size LHEX <"> 214 digest-size = "32" | "40" | "56" | "64" | "96" | "128" 216 The values of the opaque and algorithm fields must match those 217 supplied in the WWW-Authenticate response header for the entity being 218 requested. 220 response 221 A string of hex digits as defined in RFC2617 which proves 222 that the user knows a password. 224 2.3 Digest Operation 226 The modifications specified in this document does not introduce any 227 change to the digest operation specified in RFC2617. 229 2.4 Security Protocol Operation 231 When a server receives a request to access a resource, the server 232 might challenge the client by responding with "401 Unauthorized" 233 status code, and include one or more WWW-Authenticate headers. If the 234 server challenges with multiple Digest headers, then each one of 235 these headers MUST use a different digest algorithm. The server MUST 236 add these Digest headers to the response in order of preference, 237 starting with the most preferred header, followed by the less 238 preferred headers. 240 When the client receives the response it SHOULD use the topmost 241 header that it supports, unless a local policy dictates otherwise. 242 The client should ignore any challenge it does not understand. 244 2.5 Example 246 The following example is borrowed from RFC 2617 and assumes that an 247 access protected document is being requested from the server via a 248 GET request. The URI of the document is 249 http://www.nowhere.org/dir/index.html". Both client and server know 250 that the username for this document is "Mufasa" and the password is 251 "Circle of Life" ( with one space between each of the three words). 253 The first time the client requests the document, no Authorization 254 header is sent, so the server responds with: 256 HTTP/1.1 401 Unauthorized 257 WWW-Authenticate: Digest 258 realm = "testrealm@host.com", 259 qop="auth, auth-int", 260 algorithm="SHA1", 261 nonce=dcd98b7102dd2f0e8b11d0f600bfb0c093", 262 opaque=5ccc069c403ebaf9f0171e9517f40e41" 264 WWW-Authenticate: Digest 265 realm="testrealm@host.com", 266 qop="auth, auth-int", 267 algorithm="MD5", 268 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 269 opaque="5ccc069c403ebaf9f0171e9517f40ef41" 271 The client may prompt the user for their username and password, after 272 which it will respond with a new request, including the following 273 Authorization header: 275 Authorization:Digest username="Mufasa", 276 realm="testrealm@host.com" 277 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 278 uri="/dir/index.html", 279 qop=auth, 280 algorithm="MD5" 281 nc=00000001, 282 cnonce="0a4f113b", 283 response="6629fae49393a05397450978507c4ef1", 284 opaque="5ccc069c403ebaf9f0171e9517f40e41" 286 3 Internationalization 288 In challenges, servers MAY use the "accept-charset" authentication 289 parameter (case-insensitive) to express the character encoding they 290 expect the user agent to use. 292 If the user agent supports the encoding indicated by the server, it 293 SHOULD add the "accept-charset" parameter, with the value it received 294 from the server, to the Proxy-Authenticate or WWW-Authenticate header 295 fields it sends back to the server. 297 If the user agent does not support the encoding indicated by the 298 server, it SHOULD add the "accept-charset" parameter to the Proxy- 299 Authenticate or WWW-Authenticate header fields it sends back to the 300 server, but the value in the parameter should be preceded by an 301 exclamation point (!). 303 A user agent that does not follow this specification will ignore the 304 parameter and will not include it in any response to the server. 306 When the server receives the new request with the Proxy-Authenticate 307 or WWW-Authenticate header fields, it looks for the "accept-charset" 308 parameter. If the "accept-charset" parameter is present, and its 309 value matches the encoding the server sent to the client, the server 310 will continue with its normal operation using the encoding it sent to 311 the client. If, on the other hand, the "accept-charset" parameter 312 value is preceded by an exclamation point (!), the server can 313 immediately decline the request. 315 If the new request with the Proxy-Authenticate or WWW-Authenticate 316 header fields does not have the "accept-charset" parameter, the 317 server will know that it is dealing with a client that does not 318 support this specification and should continue to perform its current 319 operation. 321 The encoding indicated by the server impacts the way the server and 322 the user agent concatenate the username-value, realm-value, and 323 password when they calculate A1, as defined in section 3.2.2.2 of 324 RFC2617. 326 4 Security Considerations 328 This specification updates the Digest Access Authentication scheme 329 specified in RFC 2617 to add support for the SHA1 and SHA2 algorithm 330 suites. Support for these additional hash algorithms does not alter 331 the security properties of the Digest Access Authentication scheme. 333 5 Acknowledgments 335 The authors would like to thank Geoff Baskwill and Eric Cooper for 336 their careful review and comments. 338 6 References 340 6.1 Normative References 342 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 346 Leach, P., Luotonen, A., and L. Stewart, "HTTP 347 Authentication: Basic and Digest Access Authentication", 348 RFC 2617, June 1999. 350 6.2 Informative References 351 7 Authors' Addresses 353 Rifaat Shekh-Yusef 354 Avaya 355 250 Sydney Street 356 Belleville, Ontario 357 Canada 359 Phone: +1-613-967-5267 360 Email: rifatyu@avaya.com 362 David Ahrens 363 Avaya 364 4655 Great America Parkway 365 Santa Clara, CA 95054 367 Phone: (408) 562-5502 368 EMail: davidahrens@avaya.com