idnits 2.17.1 draft-ietf-http-digest-aa-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 359 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 47 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 122: '... OPTIONAL...' RFC 2119 keyword, line 136: '... OPTIONAL...' RFC 2119 keyword, line 143: '... OPTIONAL...' RFC 2119 keyword, line 159: '..."", -- OPTIONAL...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 273 has weird spacing: '... Digest rea...' -- 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 (March 10, 1995) is 10639 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) -- Looks like a reference, but probably isn't: 'PROPOSED' on line 1 -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 [PROPOSED] HTTP Working Group Jeffery L. Hostetler 2 INTERNET-DRAFT John Franks 3 Philip Hallam-Baker 4 Ari Luotonen 5 Eric W. Sink 6 Lawrence C. Stewart 7 Expires SIX MONTHS FROM---> March 10, 1995 9 A Proposed Extension to HTTP : Digest Access Authentication 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 To learn the current status of any Internet-Draft, please check 25 the "1id-abstracts.txt" listing contained in the Internet- 26 Drafts Shadow Directories on ds.internic.net (US East Coast), 27 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 28 munnari.oz.au (Pacific Rim). 30 Distribution of this document is unlimited. Please send comments 31 to the proposed HTTP working group at . 32 Discussions of the working group are archived at 33 . General discussions 34 about HTTP and the applications which use HTTP should take place 35 on the mailing list. 37 Abstract 39 The protocol referred to as "HTTP/1.0" includes specification 40 for a Basic Access Authentication scheme. This scheme is not 41 considered to be a secure method of user authentication, as the 42 user name and password are passed over the network in an 43 unencrypted form. A specification for a new authentication scheme 44 is needed for future versions of the HTTP protocol. This document 45 provides specification for such a scheme, referred to as "Digest 46 Access Authentication". The encryption method used is the RSA Data 47 Security, Inc. MD5 Message-Digest Algorithm. 49 Table of Contents 51 1. Introduction 52 1.1 Purpose 53 1.2 Overall Operation 54 2. Basic Access Authentication Scheme 55 2.1 Specification 56 2.2 Security protocol negotiation 57 2.3 Example 58 3. Acknowledgments 59 4. References 60 5. Authors Addresses 62 1. Introduction 64 1.1 Purpose 66 The protocol referred to as "HTTP/1.0" includes specification 67 for a Basic Access Authentication scheme[1]. This scheme is not 68 considered to be a secure method of user authentication, as the 69 user name and password are passed over the network in an 70 unencrypted form. A specification for a new authentication scheme 71 is needed for future versions of the HTTP protocol. This document 72 provides specification for such a scheme, referred to as "Digest 73 Access Authentication". 75 The Digest Access Authentication scheme is not intended to be 76 a complete answer to the need for security in the World Wide Web. 77 This scheme provides no encryption of object content. The intent 78 is simply to facilitate secure access authentication. 80 It is proposed that this access authentication scheme be included 81 in the the proposed HTTP/1.1 specification. 83 1.2 Overall Operation 85 Like Basic Access Authentication, the Digest scheme is based on 86 a simple challenge-response paradigm. The Digest scheme challenges 87 using a nonce value. A valid response contains the MD5 checksum of 88 the password and the given nonce value. In this way, the password 89 is never sent in the clear. Just as with the Basic scheme, the 90 username and password must be prearranged in some fashion. 92 2. Digest Access Authentication Scheme 94 2.1 Specification 96 The Digest Access Authentication scheme is conceptually similar to the Basic 97 scheme. The formats of the modified WWW-Authenticate header line and the 98 Authorization header line are specified below. In addition, a new header, 99 Digest-MessageDigest, is specified as well. 101 Due to formatting constraints, all of the headers are depicted on multiple 102 lines. In actual usage, they are required to be a single line of 103 comma-separated attribute-value pairs, terminated by . Whitespace 104 between the attribute-value pairs is allowed. 106 If a server receives a request for an access-protected object, and an 107 acceptable Authorizatation header is not sent, the server responds with: 109 HTTP/1.1 401 Unauthorized 110 WWW-Authenticate: Digest realm="", 111 domain="", 112 nonce="", 113 opaque="", 114 stale="" 116 The meanings of the identifers used above are as follows: 118 119 A name given to users so they know which username and password 120 to send. 122 OPTIONAL 123 A comma separated list of URIs, as specified for HTTP/1.0. The 124 intent is that the client could use this information to know the 125 set of URIs for which the same authentication information should be 126 sent. The URIs in this list may exist on different servers. If 127 this keyword is omitted or empty, the client should assume that 128 the domain consists of all URIs on the responding server. 130 131 A server-specified integer value which may be uniquely generated each 132 time a 401 response is made. Servers may defend themselves against 133 replay attacks by refusing to reuse nonce values. The nonce should be 134 considered opqaue by the client. 136 OPTIONAL 137 A string of data, specified by the server, which should returned by 138 the client unchanged. It is recommended that this string be 139 base64 or hexadecimal data. Specifically, since the string is passed 140 in the header lines as a quoted string, the double-quote character 141 is not allowed. 143 OPTIONAL 144 A flag, indicating that the previous request from the client 145 was rejected because the nonce value was stale. If stale 146 is TRUE, the client may wish to simply retry the request with 147 a new encrypted response, without reprompting the user for a 148 new username and password. 150 The client is expected to retry the request, passing an Authorization header 151 line as follows: 153 Authorization: Digest 154 username="", -- required 155 realm="", -- required 156 nonce="", -- required 157 uri="", -- required 158 response="", -- required 159 message="", -- OPTIONAL 160 opaque="" -- required if provided by server 162 where := H( H(A1) + ":" + N + ":" + H(A2) ) 163 and := H( H(A1) + ":" + N + ":" + H() ) 165 where: 167 A1 := U + ':' + R + ':' + P 168 A2 := + ':' + 170 with: 171 N -- nonce value 172 U -- username 173 R -- realm 174 P -- password 175 -- from header line 0 176 -- uri sans proxy/routing 178 When authorization succeeds, the Server may optionally provide the 179 following: 181 HTTP/1.1 200 OK 182 Digest-MessageDigest: 183 username="", 184 realm="", 185 nonce="", 186 message="" 188 The Digest-MessageDigest header indicates that the server wants to 189 communicate some info regarding the successful 190 authentication (such as a message digest or a 191 receipt of some kind). 193 is computed as given above for 194 the client. this allows the client to verify that 195 the message body has not been changed en-route. 197 (The server would probably only send this when it 198 has the document and can compute it (like the 199 content-length field); the server would probably 200 not bother generating this header for CGI output.) 202 Upon receiving the Authorization information, the server may check its 203 validity by looking up its known password which corresponds to the submitted 204 . Then, the server must perform the same MD5 operation performed 205 by the client, and compare the result to the given . 207 Note that the HTTP server does not actually need to know the user's 208 clear text password. As long as H(A1) is available to the server, the 209 validity of an Authorization header may be verified. 211 All keyword-value pairs must be expressed in characters from the 212 US-ASCII character set, excluding control characters. 214 A client may remember the username, password and nonce values, so that 215 future requests within the specified may include the Authorization 216 line preemptively. The server may choose to accept the old Authorization 217 information, even though the nonce value included might not be fresh. 218 Alternatively, the server could return a 401 response with a new nonce 219 value, causing the client to retry the request. By specifying stale=TRUE 220 with this response, the server hints to the client that the request should 221 be retried with the new nonce, without reprompting the user for a new 222 username and password. 224 The data is useful for transporting state information around. 225 For example, a server could be responsible for authenticating content 226 which actual sits on another server. The first 401 response would include 227 a which includes the URI on the second server, and the 228 for specifying state information. The client will retry the request, at 229 which time the server may respond with a 301/302 redirection, pointing 230 to the URI on the second server. The client will follow the redirection, 231 and pass the same Authorization line, including the data which 232 the second server may require. 234 As with the basic scheme, proxies must be completely transparent in 235 the Digest access authentication scheme. That is, they must forward the 236 WWW-Authenticate, Digest-MessageDigest and Authorization headers untouched. 237 If a proxy wants to authenticate a client before a request is forwarded to 238 the server, it can be done using the Proxy-Authenticate and 239 Proxy-Authorization headers. 241 2.2 Security Protocol Negotiation 243 It is useful for a server to be able to know which security schemes 244 a client is capable of handling. It is recommended that the HTTP extension 245 mechanism proposed by Dave Kristol [2] be used. If the client includes 246 the following header line with the request, then a server can safely assume 247 that the client can handle Digest authentication. 249 Extension: Security/Digest 251 If this proposal is accepted as a required part of the HTTP/1.1 252 specification, then a server may assume Digest support when a client 253 identifies itself as HTTP/1.1 compliant. 255 It is possible that a server may want to require Digest as its 256 authentication method, even if the server does not know that the client 257 supports it. A client is encouraged to fail gracefully if the server 258 specifies any authorization scheme it cannot handle. 260 2.3 Example 262 The following example assumes that an access-protected document is being 263 requested from the server. The URI of the document is 264 "http://www.nowhere.org/simp/". 266 Both client and server know that the username for this document is "eric", 267 and the password is "spyglass". 269 The first time the client requests the document, no Authorization header 270 is sent, so the server responds with: 272 HTTP/1.1 401 Unauthorized 273 WWW-Authenticate: Digest realm="testrealm", 274 nonce="72540723369", 275 opaque="5ccc069c403ebaf9f0171e9517f40e41" 277 The client may prompt the user for the username and password, after which it 278 will respond with a new request, including the following Authorization 279 header: 281 Authorization: Digest username="eric", 282 realm="testrealm", 283 nonce="72540723369", 284 uri="/simp/", 285 response="e966c932a9242554e42c8ee200cec7f6", 286 opaque="5ccc069c403ebaf9f0171e9517f40e41" 288 3. Acknowledgments 290 Source code in C for the RSA Data Security, Inc. MD5 Message-Digest 291 Algorithm is available free of charge from RSA Data Security, Inc. 293 4. References 295 [1] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen. 296 "Hypertext Transfer Protocol -- HTTP/1.0" 297 Internet-Draft (work in progress), UC Irvine, 298 , December 1994. 301 [2] D. Kristol. "A Proposed Extension Mechanism for HTTP" 302 , 303 December 1994. 305 5. Authors Addresses 307 John Franks 308 john@math.nwu.edu 309 Professor of Mathematics 310 Department of Mathematics 311 Northwestern University 312 Evanston, IL 60208-2730 314 Phillip M. Hallam-Baker 315 hallam@w3.org 316 European Union Fellow 317 CERN 318 Geneva 319 Switzerland 321 Jeffery L. Hostetler 322 jeff@spyglass.com 323 Senior Software Engineer 324 Spyglass, Inc. 325 1800 Woodfield Drive 326 Savoy, IL 61874 328 Ari Luotonen 329 luotonen@netscape.com 330 Member of Technical Staff 331 501 East Middlefield Road 332 Mountain View, CA 94043, USA 334 Eric W. Sink 335 eric@spyglass.com 336 Senior Software Engineer 337 Spyglass, Inc. 338 1800 Woodfield Drive 339 Savoy, IL 61874 341 Lawrence C. Stewart 342 stewart@OpenMarket.com 343 Open Market, Inc. 344 215 First Street 345 Cambridge, MA 02142 347 -- 348 Eric W. Sink, Senior Software Engineer -- eric@spyglass.com 350 http://www.spyglass.com/~eric/home.htm