idnits 2.17.1 draft-ietf-httpauth-digest-update-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 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 22, 2013) is 3961 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) == Unused Reference: 'RFC2617' is defined on line 294, 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 (~~), 2 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 22, 2013 6 Expires: December 24, 2013 8 HTTP Digest Update 9 draft-ietf-httpauth-digest-update-01 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 Digest Access Authentication Scheme . . . . . . . . . . . . . . 3 58 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1.1 Representation of digest values . . . . . . . . . . . . 3 60 2.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2 Specification of Digest Headers . . . . . . . . . . . . . . 4 62 2.2.1 The WWW-Authenticate Response Header . . . . . . . . . . 4 63 2.2.2 The Authorization Request Header . . . . . . . . . . . . 5 64 2.3 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 6 65 2.4 Security Protocol Operation . . . . . . . . . . . . . . . . 6 66 2.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 4 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1 Normative References . . . . . . . . . . . . . . . . . . . 8 71 5.2 Informative References . . . . . . . . . . . . . . . . . . 8 72 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 74 1 Introduction 76 This document specifies extensions to the HTTP Digest Access 77 Authentication scheme by adding support for the SHA1 and SHA2 suite 78 of hash algorithms [FIPS186-3]. RFC2617 specifies the MD5 algorithm 79 as the default hash algorithm used in the digest access 80 authentication scheme. Since RFC2617 was first proposed, the MD5 81 algorithm has been broken. In 2008 the US-CERT issued a note that 82 MD5 "should be considered cryptographically broken and unsuitable for 83 further use" [CERT-VU]. 85 1.1 Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC2119 [RFC2119]. 91 2 Digest Access Authentication Scheme 93 The Digest Access Authentication scheme is based on a simple 94 challenge-response paradigm. The Digest scheme challenges using a 95 nonce value. A valid response contains a checksum of the username, 96 the password, the given nonce value and the requested URI. In this 97 way the password is never sent in the clear. 99 2.1 Introduction 101 2.1.1 Representation of digest values 103 An optional header allows the server to specify the algorithm used to 104 create the checksum or digest. By default and to maintain backwards 105 compatibility, the MD5 algorithm is used. 107 The size of the digest depends on the algorithm used. The bits in 108 the digest are converted from the most significant to the least 109 significant bit, four bits at a time to the ASCII representation as 110 follows. Each four bits is represented by its familiar hexadecimal 111 notation from the characters 0123456789abcdef, that is binary 0000 is 112 represented by the character '0', 0001 by '1' and so on up to the 113 representation of 1111 as 'f'. If the MD5 algorithm is used to 114 calculate the digest, then the digest will be represented as 32 115 hexadecimal characters, SHA1 by 40 hexadecimal characters, SHA2-224 116 by 56 hexadecimal characters, SHA2-256 by 64 hexadecimal characters, 117 SHA2-384 by 96 hexadecimal characters, and SHA2-512 by 128 118 hexadecimal characters. 120 2.1.2 Limitations 122 The Digest authentication scheme suffers from many known limitations 123 as specified in RFC2617, section 3.1.4. The update in this document 124 does not address those limitations. 126 2.2 Specification of Digest Headers 128 The modifications to the formats of the WWW-Authenticate Header line 129 and the Authorization header line are specified below. 131 2.2.1 The WWW-Authenticate Response Header 133 If a server receives a request for an access protected object, and an 134 acceptable Authorization header is not sent, the server responds with 135 a "401 Unauthorized" status code, and a WWW-Authenticate header. The 136 server MAY include multiple WWW-Authenticate headers to allow the 137 server to utilize the best available algorithm supported by the 138 client. 140 The algorithm directive is extended as follows: 142 algorithm = "algorithm" "=" ("MD5" | "MD5-sess" | 143 "SHA1" | "SHA1-sess" | 144 "SHA224" | "SHA224-sess" | 145 "SHA256" | "SHA256-sess" | 146 "SHA384" | "SHA384-sess" | 147 "SHA512" | "SHA512-sess" | 148 token) 150 Algorithm 151 A string indicating a pair of algorithms used to produce the 152 digest and a checksum. If the algorithm parameter is not present 153 it is assumed to be "MD5" to maintain backwards compatibility 154 with existing implementations. If the algorithm is not 155 understood, the challenge should be ignored and a different 156 challenge used if there is more than one. 158 The string obtained by applying the digest algorithm to the data 159 "data" with "secret" will be denoted KD(secret, data) and the 160 string obtained by applying the checksum algorithm to the data 161 "data" will be denoted H(data). The notation unq(x) means the 162 value of the quoted string X without the surrounding quotes. 164 For the "MD5 and "MD5-sess" algorithms 165 H(data) = MD5(data) 167 For the "SHA1" and "SHA1-sess" algorithms 168 H(data) = SHA1(data) 170 For the "SHA224" and "SHA224-sess" algorithms 171 H(data) = SHA224(data) 173 For the "SHA256" and "SHA256-sess" algorithms 174 H(data) = SHA256(data) 176 For the "SHA384" and "SHA384-sess" algorithms 177 H(data) = SHA384(data) 179 For the "SHA512" and "SHA512-sess" algorithms 180 H(data) = SHA512(data) 182 and 183 KD(secret, data) = H(concat(secret, ":", data)) 185 i.e the digest is the hash of the secret concatenated with a 186 colon concatenated with the data. The " -sess" algorithm is 187 intended to allow efficient 3rd party authentication servers; 188 for the difference in usage see the description in section 189 RFC2617, Section 3.2.2.2. 191 2.2.2 The Authorization Request Header 193 The client is expected to retry the request, passing an Authorization 194 Request Header line. The Authorization Request Header line is 195 modified as follows: 197 request-digest = <"> digest-size LHEX <"> 198 digest-size = "32" | "40" | "56" | "64" | "96" | "128" 200 The values of the opaque and algorithm fields must match those 201 supplied in the WWW-Authenticate response header for the entity being 202 requested. 204 response 205 A string of hex digits as defined in RFC2617 which proves 206 that the user knows a password. 208 2.3 Digest Operation 210 The modifications specified in this document does not introduce any 211 change to the digest operation specified in RFC2617. 213 2.4 Security Protocol Operation 215 When a server receives a request to access a resource, the server 216 might challenge the client by responding with "401 Unauthorized" 217 status code, and include one or more WWW-Authenticate headers. If the 218 server challenges with multiple Digest headers, then each one of 219 these headers MUST use a different digest algorithm. The server MUST 220 add these Digest headers to the response in order of preference, 221 starting with the most preferred header, followed by the less 222 preferred headers. 224 When the client receives the response it SHOULD use the topmost 225 header that it supports, unless a local policy dictates otherwise. 226 The client should ignore any challenge it does not understand. 228 2.5 Example 230 The following example is borrowed from RFC2617 and assumes that an 231 access protected document is being requested from the server via a 232 GET request. The URI of the document is 233 http://www.nowhere.org/dir/index.html". Both client and server know 234 that the username for this document is "Mufasa" and the password is 235 "Circle of Life" ( with one space between each of the three words). 237 The first time the client requests the document, no Authorization 238 header is sent, so the server responds with: 240 HTTP/1.1 401 Unauthorized 241 WWW-Authenticate: Digest 242 realm = "testrealm@host.com", 243 qop="auth, auth-int", 244 algorithm="SHA1", 245 nonce=dcd98b7102dd2f0e8b11d0f600bfb0c093", 246 opaque=5ccc069c403ebaf9f0171e9517f40e41" 247 WWW-Authenticate: Digest 248 realm="testrealm@host.com", 249 qop="auth, auth-int", 250 algorithm="MD5", 251 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 252 opaque="5ccc069c403ebaf9f0171e9517f40ef41" 254 The client may prompt the user for their username and password, after 255 which it will respond with a new request, including the following 256 Authorization header: 258 Authorization:Digest username="Mufasa", 259 realm="testrealm@host.com" 260 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 261 uri="/dir/index.html", 262 qop=auth, 263 algorithm="MD5" 264 nc=00000001, 265 cnonce="0a4f113b", 266 response="6629fae49393a05397450978507c4ef1", 267 opaque="5ccc069c403ebaf9f0171e9517f40e41" 269 3 Security Considerations 271 This specification updates the Digest Access Authentication scheme 272 specified in RFC2617 to add support for the SHA1 and SHA2 algorithm 273 suites. Support for these additional hash algorithms does not alter 274 the security properties of the Digest Access Authentication scheme. 276 4 Acknowledgments 278 The authors would like to thank Geoff Baskwill and Eric Cooper for 279 their careful review and comments on the pre published version of 280 this document. 282 The authors would also like to thank Stephen Farrell, Yoav Nir, 283 Phillip Hallam-Baker, Manu Sporny, Paul Hoffman, Julian Reschke, and 284 Sean Turner for their careful review and comments on and off the 285 mailing list. 287 5 References 289 5.1 Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, March 1997. 294 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 295 Leach, P., Luotonen, A., and L. Stewart, "HTTP 296 Authentication: Basic and Digest Access Authentication", 297 RFC 2617, June 1999. 299 5.2 Informative References 301 [FIPS186-3] National Institute of Standards and Technology (NIST), 302 FIPS Publication 186-3: Digital Signature Standard, June 2009. 304 [CERT-VU] Vulnerability Note VU#836068, MD5 vulnerable to collision 305 attacks, December 2008. 307 6 Authors' Addresses 309 Rifaat Shekh-Yusef 310 Avaya 311 250 Sydney Street 312 Belleville, Ontario 313 Canada 315 Phone: +1-613-967-5267 316 Email: rifatyu@avaya.com 318 David Ahrens 319 Avaya 320 4655 Great America Parkway 321 Santa Clara, CA 95054 323 Phone: (408) 562-5502 324 EMail: davidahrens@avaya.com