idnits 2.17.1 draft-ahrens-httpbis-digest-auth-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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 30, 2012) is 4282 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 88, but not defined == Unused Reference: 'KEYWORDS' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 287, 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT David Ahrens 3 Intended Status: Standards Track Rifaat Shekh-Yusef 4 Expires: January 31, 2013 Avaya 5 July 30, 2012 7 HTTP Digest Access Authentication Algorithm Update 8 draft-ahrens-httpbis-digest-auth-update-00 10 Abstract 12 This document specifies extensions to the HTTP Digest Authentication 13 mechanism to add support for the SHA1 and SHA2 digest algorithms to 14 the HTTP Digest access authentication scheme. 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) 2012 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. Digest Access Authentication Scheme Update . . . . . . . . . . 3 57 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1.1 Representation of digest values . . . . . . . . . . . . 3 59 2.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2 Specification of Digest Headers . . . . . . . . . . . . . . 4 61 2.2.1 The WWW-Authenticate Response Header . . . . . . . . . . 4 62 2.2.2 The Authorization Request Header . . . . . . . . . . . . 5 63 2.3 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 6 64 2.4 Security Protocol Operation . . . . . . . . . . . . . . . . 6 65 2.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 4 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.1 Normative References . . . . . . . . . . . . . . . . . . . 8 70 5.2 Informative References . . . . . . . . . . . . . . . . . . 8 71 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 73 1 Introduction 75 This document specifies extensions to the HTTP Digest Access 76 Authentication scheme by adding support for the SHA1 and SHA2 suite 77 of hash algorithms. RFC 2617 specifies the MD5 algorithm as the 78 default hash algorithm used in the digest access authentication 79 scheme. Since RFC 2617 was first proposed, the MD5 algorithm has 80 been broken. In 2008 the US-CERT issued a note that MD5 "should be 81 considered cryptographically broken and unsuitable for further use." 83 1.1 Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 2. Digest Access Authentication Scheme Update 91 The Digest Access Authentication scheme is based on a simple 92 challenge-response paradigm. The Digest scheme challenges using a 93 nonce value. A valid response contains a checksum of the username, 94 the password, the given nonce value and the requested URI. In this 95 way the password is never sent in the clear. 97 2.1 Introduction 99 2.1.1 Representation of digest values 101 An optional header allows the server to specify the algorithm used to 102 create the checksum or digest. By default and to maintain backwards 103 compatibility, the MD5 algorithm is used. 105 The size of the digest depends on the algorithm used. The bits in 106 the digest are converted from the most significant to the least 107 significant bit, four bits at a time to the ASCII representation as 108 follows. Each four bits is represented by its familiar hexadecimal 109 notation from the characters 0123456789abcdef, that is binary 0000 is 110 represented by the character '0', 0001 by '1' and so on up to the 111 representation of 1111 as 'f'. If the MD5 algorithm is used to 112 calculate the digest, then the digest will be represented as 32 113 hexadecimal characters, SHA1 by 40 hexadecimal characters, SHA2-224 114 by 56 hexadecimal characters, SHA2-256 by 64 hexadecimal characters, 115 SHA2-384 by 96 hexadecimal characters, and SHA2-512 by 128 116 hexadecimal characters. 118 2.1.2 Limitations 120 The Digest authentication scheme specified in RFC 2617 suffers from 121 many known limitations. The update proposed in this draft does not 122 address those limitations. 124 2.2 Specification of Digest Headers 126 The modifications to the formats of the WWW-Authenticate Header line 127 and the Authorization header line are specified below. 129 2.2.1 The WWW-Authenticate Response Header 131 If a server receives a request for an access protected object, and an 132 acceptable Authorization header is not sent, the server responds with 133 a "401 Unauthorized" status code, and a WWW-Authenticate header. The 134 server MAY include multiple WWW-Authenticate headers to allow the 135 server to utilize the best available algorithm supported by the 136 client. 138 The algorithm directive is extended as follows: 140 algorithm = "algorithm" "=" ("MD5" | "MD5-sess" | 141 "SHA1" | "SHA1-sess" | 142 "SHA224" | "SHA224-sess" | 143 "SHA256" | "SHA256-sess" | 144 "SHA384" | "SHA384-sess" | 145 "SHA512" | "SHA512-sess" | 146 token) 148 Algorithm 149 A string indicating a pair of algorithms used to produce the 150 digest and a checksum. If the algorithm parameter is not present 151 it is assumed to be "MD5" to maintain backwards compatibility 152 with existing implementations. If the algorithm is not 153 understood, the challenge should be ignored and a different 154 challenge used if there is more than one. 156 The string obtained by applying the digest algorithm to the data 157 "data" with "secret" will be denoted KD(secret, data) and the 158 string obtained by applying the checksum algorithm to the data 159 "data" will be denoted H(data). The notation unq(x) means the 160 value of the quoted string X without the surrounding quotes. 162 For the "MD5 and "MD5-sess" algorithms 163 H(data) = MD5(data) 165 For the "SHA1" and "SHA1-sess" algorithms 166 H(data) = SHA1(data) 168 For the "SHA224" and "SHA224-sess" algorithms 169 H(data) = SHA224(data) 171 For the "SHA256" and "SHA256-sess" algorithms 172 H(data) = SHA256(data) 174 For the "SHA384" and "SHA384-sess" algorithms 175 H(data) = SHA384(data) 177 For the "SHA512" and "SHA512-sess" algorithms 178 H(data) = SHA512(data) 180 and 181 KD(secret, data) = H(concat(secret, ":", data)) 183 i.e the digest is the hash of the secret concatenated with a 184 colon concatenated with the data. The " -sess" algorithm is 185 intended to allow efficient 3rd party authentication servers; 186 for the difference in usage see the description in section 187 RFC2617, Section 3.2.2.2. 189 2.2.2 The Authorization Request Header 191 The client is expected to retry the request, passing an Authorization 192 Request Header line. The Authorization Request Header line is 193 modified as follows: 195 request-digest = <"> digest-size LHEX <"> 196 digest-size = "32" | "40" | "56" | "64" | "96" | "128" 198 The values of the opaque and algorithm fields must match those 199 supplied in the WWW-Authenticate response header for the entity being 200 requested. 202 response 203 A string of hex digits as defined in RFC2617 which proves 204 that the user knows a password. 206 2.3 Digest Operation 208 The modifications specified in this document does not introduce any 209 change to the digest operation specified in RFC2617. 211 2.4 Security Protocol Operation 213 When a server receives a request to access a resource, the server 214 might challenge the client by responding with "401 Unauthorized" 215 status code, and include one or more WWW-Authenticate headers. If the 216 server challenges with multiple Digest headers, then each one of 217 these headers MUST use a different digest algorithm. The server MUST 218 add these Digest headers to the response in order of preference, 219 starting with the most preferred header, followed by the less 220 preferred headers. 222 When the client receives the response it SHOULD use the topmost 223 header that it supports, unless a local policy dictates otherwise. 224 The client should ignore any challenge it does not understand. 226 2.5 Example 228 The following example is borrowed from RFC 2617 and assumes that an 229 access protected document is being requested from the server via a 230 GET request. The URI of the document is 231 http://www.nowhere.org/dir/index.html". Both client and server know 232 that the username for this document is "Mufasa" and the password is 233 "Circle of Life" ( with one space between each of the three words). 235 The first time the client requests the document, no Authorization 236 header is sent, so the server responds with: 238 HTTP/1.1 401 Unauthorized 239 WWW-Authenticate: Digest 240 realm = "testrealm@host.com", 241 qop="auth, auth-int", 242 algorithm="SHA1", 243 nonce=dcd98b7102dd2f0e8b11d0f600bfb0c093", 244 opaque=5ccc069c403ebaf9f0171e9517f40e41" 246 WWW-Authenticate: Digest 247 realm="testrealm@host.com", 248 qop="auth, auth-int", 249 algorithm="MD5", 250 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 251 opaque="5ccc069c403ebaf9f0171e9517f40ef41" 253 The client may prompt the user for their username and password, after 254 which it will respond with a new request, including the following 255 Authorization header: 257 Authorization:Digest username="Mufasa", 258 realm="testrealm@host.com" 259 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 260 uri="/dir/index.html", 261 qop=auth, 262 algorithm="MD5" 263 nc=00000001, 264 cnonce="0a4f113b", 265 response="6629fae49393a05397450978507c4ef1", 266 opaque="5ccc069c403ebaf9f0171e9517f40e41" 268 3 Security Considerations 270 This specification updates the Digest Access Authentication scheme 271 specified in RFC 2617 to add support for the SHA1 and SHA2 algorithm 272 suites. Support for these additional hash algorithms does not alter 273 the security properties of the Digest Access Authentication scheme. 275 4 Acknowledgments 277 The authors would like to thank Geoff Baskwill and Eric Cooper for 278 their careful review and comments. 280 5 References 282 5.1 Normative References 284 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 288 Leach, P., Luotonen, A., and L. Stewart, "HTTP 289 Authentication: Basic and Digest Access Authentication", 290 RFC 2617, June 1999. 292 5.2 Informative References 293 6 Authors' Addresses 295 David Ahrens 296 Avaya, Inc. 297 4655 Great America Parkway 298 Santa Clara, CA 95054 300 Phone: (408) 562-5502 301 EMail: davidahrens@avaya.com 303 Rifaat Shekh-Yusef 304 Avaya, Inc. 305 250 Sydney Street 306 Belleville, Ontario 307 Canada 309 Phone: +1-613-967-5267 310 Email: rifatyu@avaya.com