idnits 2.17.1 draft-ietf-httpbis-p7-auth-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 30. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 571. 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 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 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 (August 29, 2008) is 5712 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) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-04 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-04 ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Fielding, Ed. 3 Internet-Draft Day Software 4 Obsoletes: 2616 (if approved) J. Gettys 5 Updates: 2617 (if approved) One Laptop per Child 6 Intended status: Standards Track J. Mogul 7 Expires: March 2, 2009 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe Systems 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 August 29, 2008 22 HTTP/1.1, part 7: Authentication 23 draft-ietf-httpbis-p7-auth-04 25 Status of this Memo 27 By submitting this Internet-Draft, each author represents that any 28 applicable patent or other IPR claims of which he or she is aware 29 have been or will be disclosed, and any of which he or she becomes 30 aware will be disclosed, in accordance with Section 6 of BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on March 2, 2009. 50 Abstract 52 The Hypertext Transfer Protocol (HTTP) is an application-level 53 protocol for distributed, collaborative, hypermedia information 54 systems. HTTP has been in use by the World Wide Web global 55 information initiative since 1990. This document is Part 7 of the 56 seven-part specification that defines the protocol referred to as 57 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines 58 HTTP Authentication. 60 Editorial Note (To be removed by RFC Editor) 62 Discussion of this draft should take place on the HTTPBIS working 63 group mailing list (ietf-http-wg@w3.org). The current issues list is 64 at and related 65 documents (including fancy diffs) can be found at 66 . 68 The changes in this draft are summarized in Appendix B.4. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 75 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 76 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 5 77 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 5 78 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 5 79 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 5 80 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 6 81 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 7 82 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 84 5.1. Message Header Registration . . . . . . . . . . . . . . . 7 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 86 6.1. Authentication Credentials and Idle Clients . . . . . . . 8 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 91 Appendix A. Compatibility with Previous Versions . . . . . . . . 9 92 A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 9 93 Appendix B. Change Log (to be removed by RFC Editor before 94 publication) . . . . . . . . . . . . . . . . . . . . 9 95 B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 10 96 B.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 10 97 B.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 10 98 B.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 10 99 B.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 10 100 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 102 Intellectual Property and Copyright Statements . . . . . . . . . . 14 104 1. Introduction 106 This document defines HTTP/1.1 access control and authentication. 107 Right now it includes the extracted relevant sections of RFC 2616 108 with only minor changes. The intention is to move the general 109 framework for HTTP authentication here, as currently specified in 110 [RFC2617], and allow the individual authentication mechanisms to be 111 defined elsewhere. This introduction will be rewritten when that 112 occurs. 114 HTTP provides several OPTIONAL challenge-response authentication 115 mechanisms which can be used by a server to challenge a client 116 request and by a client to provide authentication information. The 117 general framework for access authentication, and the specification of 118 "basic" and "digest" authentication, are specified in "HTTP 119 Authentication: Basic and Digest Access Authentication" [RFC2617]. 120 This specification adopts the definitions of "challenge" and 121 "credentials" from that specification. 123 1.1. Requirements 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 An implementation is not compliant if it fails to satisfy one or more 130 of the MUST or REQUIRED level requirements for the protocols it 131 implements. An implementation that satisfies all the MUST or 132 REQUIRED level and all the SHOULD level requirements for its 133 protocols is said to be "unconditionally compliant"; one that 134 satisfies all the MUST level requirements but not all the SHOULD 135 level requirements for its protocols is said to be "conditionally 136 compliant." 138 2. Notational Conventions and Generic Grammar 140 This specification uses the ABNF syntax defined in Section 2.1 of 141 [Part1]. [[abnf.dep: ABNF syntax and basic rules will be adopted from 142 RFC 5234, see .]] 144 The ABNF rules below are defined in other specifications: 146 challenge = 147 credentials = 149 3. Status Code Definitions 151 3.1. 401 Unauthorized 153 The request requires user authentication. The response MUST include 154 a WWW-Authenticate header field (Section 4.4) containing a challenge 155 applicable to the requested resource. The client MAY repeat the 156 request with a suitable Authorization header field (Section 4.1). If 157 the request already included Authorization credentials, then the 401 158 response indicates that authorization has been refused for those 159 credentials. If the 401 response contains the same challenge as the 160 prior response, and the user agent has already attempted 161 authentication at least once, then the user SHOULD be presented the 162 entity that was given in the response, since that entity might 163 include relevant diagnostic information. HTTP access authentication 164 is explained in "HTTP Authentication: Basic and Digest Access 165 Authentication" [RFC2617]. 167 3.2. 407 Proxy Authentication Required 169 This code is similar to 401 (Unauthorized), but indicates that the 170 client must first authenticate itself with the proxy. The proxy MUST 171 return a Proxy-Authenticate header field (Section 4.2) containing a 172 challenge applicable to the proxy for the requested resource. The 173 client MAY repeat the request with a suitable Proxy-Authorization 174 header field (Section 4.3). HTTP access authentication is explained 175 in "HTTP Authentication: Basic and Digest Access Authentication" 176 [RFC2617]. 178 4. Header Field Definitions 180 This section defines the syntax and semantics of HTTP/1.1 header 181 fields related to authentication. 183 4.1. Authorization 185 A user agent that wishes to authenticate itself with a server-- 186 usually, but not necessarily, after receiving a 401 response--does so 187 by including an Authorization request-header field with the request. 188 The Authorization field value consists of credentials containing the 189 authentication information of the user agent for the realm of the 190 resource being requested. 192 Authorization = "Authorization" ":" credentials 194 HTTP access authentication is described in "HTTP Authentication: 195 Basic and Digest Access Authentication" [RFC2617]. If a request is 196 authenticated and a realm specified, the same credentials SHOULD be 197 valid for all other requests within this realm (assuming that the 198 authentication scheme itself does not require otherwise, such as 199 credentials that vary according to a challenge value or using 200 synchronized clocks). 202 When a shared cache (see Section 9 of [Part6]) receives a request 203 containing an Authorization field, it MUST NOT return the 204 corresponding response as a reply to any other request, unless one of 205 the following specific exceptions holds: 207 1. If the response includes the "s-maxage" cache-control directive, 208 the cache MAY use that response in replying to a subsequent 209 request. But (if the specified maximum age has passed) a proxy 210 cache MUST first revalidate it with the origin server, using the 211 request-headers from the new request to allow the origin server 212 to authenticate the new request. (This is the defined behavior 213 for s-maxage.) If the response includes "s-maxage=0", the proxy 214 MUST always revalidate it before re-using it. 216 2. If the response includes the "must-revalidate" cache-control 217 directive, the cache MAY use that response in replying to a 218 subsequent request. But if the response is stale, all caches 219 MUST first revalidate it with the origin server, using the 220 request-headers from the new request to allow the origin server 221 to authenticate the new request. 223 3. If the response includes the "public" cache-control directive, it 224 MAY be returned in reply to any subsequent request. 226 4.2. Proxy-Authenticate 228 The Proxy-Authenticate response-header field MUST be included as part 229 of a 407 (Proxy Authentication Required) response. The field value 230 consists of a challenge that indicates the authentication scheme and 231 parameters applicable to the proxy for this Request-URI. 233 Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge 235 The HTTP access authentication process is described in "HTTP 236 Authentication: Basic and Digest Access Authentication" [RFC2617]. 237 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 238 only to the current connection and SHOULD NOT be passed on to 239 downstream clients. However, an intermediate proxy might need to 240 obtain its own credentials by requesting them from the downstream 241 client, which in some circumstances will appear as if the proxy is 242 forwarding the Proxy-Authenticate header field. 244 4.3. Proxy-Authorization 246 The Proxy-Authorization request-header field allows the client to 247 identify itself (or its user) to a proxy which requires 248 authentication. The Proxy-Authorization field value consists of 249 credentials containing the authentication information of the user 250 agent for the proxy and/or realm of the resource being requested. 252 Proxy-Authorization = "Proxy-Authorization" ":" credentials 254 The HTTP access authentication process is described in "HTTP 255 Authentication: Basic and Digest Access Authentication" [RFC2617]. 256 Unlike Authorization, the Proxy-Authorization header field applies 257 only to the next outbound proxy that demanded authentication using 258 the Proxy-Authenticate field. When multiple proxies are used in a 259 chain, the Proxy-Authorization header field is consumed by the first 260 outbound proxy that was expecting to receive credentials. A proxy 261 MAY relay the credentials from the client request to the next proxy 262 if that is the mechanism by which the proxies cooperatively 263 authenticate a given request. 265 4.4. WWW-Authenticate 267 The WWW-Authenticate response-header field MUST be included in 401 268 (Unauthorized) response messages. The field value consists of at 269 least one challenge that indicates the authentication scheme(s) and 270 parameters applicable to the Request-URI. 272 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge 274 The HTTP access authentication process is described in "HTTP 275 Authentication: Basic and Digest Access Authentication" [RFC2617]. 276 User agents are advised to take special care in parsing the WWW- 277 Authenticate field value as it might contain more than one challenge, 278 or if more than one WWW-Authenticate header field is provided, the 279 contents of a challenge itself can contain a comma-separated list of 280 authentication parameters. 282 5. IANA Considerations 284 5.1. Message Header Registration 286 The Message Header Registry located at should be 288 updated with the permanent registrations below (see [RFC3864]): 290 +---------------------+----------+----------+-------------+ 291 | Header Field Name | Protocol | Status | Reference | 292 +---------------------+----------+----------+-------------+ 293 | Authorization | http | standard | Section 4.1 | 294 | Proxy-Authenticate | http | standard | Section 4.2 | 295 | Proxy-Authorization | http | standard | Section 4.3 | 296 | WWW-Authenticate | http | standard | Section 4.4 | 297 +---------------------+----------+----------+-------------+ 299 The change controller is: "IETF (iesg@ietf.org) - Internet 300 Engineering Task Force". 302 6. Security Considerations 304 This section is meant to inform application developers, information 305 providers, and users of the security limitations in HTTP/1.1 as 306 described by this document. The discussion does not include 307 definitive solutions to the problems revealed, though it does make 308 some suggestions for reducing security risks. 310 6.1. Authentication Credentials and Idle Clients 312 Existing HTTP clients and user agents typically retain authentication 313 information indefinitely. HTTP/1.1 does not provide a method for a 314 server to direct clients to discard these cached credentials. This 315 is a significant defect that requires further extensions to HTTP. 316 Circumstances under which credential caching can interfere with the 317 application's security model include but are not limited to: 319 o Clients which have been idle for an extended period following 320 which the server might wish to cause the client to reprompt the 321 user for credentials. 323 o Applications which include a session termination indication (such 324 as a `logout' or `commit' button on a page) after which the server 325 side of the application `knows' that there is no further reason 326 for the client to retain the credentials. 328 This is currently under separate study. There are a number of work- 329 arounds to parts of this problem, and we encourage the use of 330 password protection in screen savers, idle time-outs, and other 331 methods which mitigate the security problems inherent in this 332 problem. In particular, user agents which cache credentials are 333 encouraged to provide a readily accessible mechanism for discarding 334 cached credentials under user control. 336 7. Acknowledgments 338 [[anchor2: TBD.]] 340 8. References 342 8.1. Normative References 344 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 345 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 346 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 347 and Message Parsing", draft-ietf-httpbis-p1-messaging-04 348 (work in progress), August 2008. 350 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 351 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 352 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 353 draft-ietf-httpbis-p6-cache-04 (work in progress), 354 August 2008. 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, March 1997. 359 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 360 Leach, P., Luotonen, A., and L. Stewart, "HTTP 361 Authentication: Basic and Digest Access Authentication", 362 RFC 2617, June 1999. 364 8.2. Informative References 366 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 367 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 368 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 370 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 371 Procedures for Message Header Fields", BCP 90, RFC 3864, 372 September 2004. 374 Appendix A. Compatibility with Previous Versions 376 A.1. Changes from RFC 2616 378 Appendix B. Change Log (to be removed by RFC Editor before publication) 379 B.1. Since RFC2616 381 Extracted relevant partitions from [RFC2616]. 383 B.2. Since draft-ietf-httpbis-p7-auth-00 385 Closed issues: 387 o : "Normative 388 and Informative references" 390 B.3. Since draft-ietf-httpbis-p7-auth-01 392 Ongoing work on ABNF conversion 393 (): 395 o Explicitly import BNF rules for "challenge" and "credentials" from 396 RFC2617. 398 o Add explicit references to BNF syntax and rules imported from 399 other parts of the specification. 401 B.4. Since draft-ietf-httpbis-p7-auth-02 403 Ongoing work on IANA Message Header Registration 404 (): 406 o Reference RFC 3984, and update header registrations for headers 407 defined in this document. 409 B.5. Since draft-ietf-httpbis-p7-auth-03 411 Index 413 4 414 401 Unauthorized (status code) 5 415 407 Proxy Authentication Required (status code) 5 417 A 418 Authorization header 5 420 G 421 Grammar 422 Authorization 5 423 challenge 4 424 credentials 4 425 Proxy-Authenticate 6 426 Proxy-Authorization 7 427 WWW-Authenticate 7 429 H 430 Headers 431 Authorization 5 432 Proxy-Authenticate 6 433 Proxy-Authorization 7 434 WWW-Authenticate 7 436 P 437 Proxy-Authenticate header 6 438 Proxy-Authorization header 7 440 S 441 Status Codes 442 401 Unauthorized 5 443 407 Proxy Authentication Required 5 445 W 446 WWW-Authenticate header 7 448 Authors' Addresses 450 Roy T. Fielding (editor) 451 Day Software 452 23 Corporate Plaza DR, Suite 280 453 Newport Beach, CA 92660 454 USA 456 Phone: +1-949-706-5300 457 Fax: +1-949-706-5305 458 Email: fielding@gbiv.com 459 URI: http://roy.gbiv.com/ 461 Jim Gettys 462 One Laptop per Child 463 21 Oak Knoll Road 464 Carlisle, MA 01741 465 USA 467 Email: jg@laptop.org 468 URI: http://www.laptop.org/ 469 Jeffrey C. Mogul 470 Hewlett-Packard Company 471 HP Labs, Large Scale Systems Group 472 1501 Page Mill Road, MS 1177 473 Palo Alto, CA 94304 474 USA 476 Email: JeffMogul@acm.org 478 Henrik Frystyk Nielsen 479 Microsoft Corporation 480 1 Microsoft Way 481 Redmond, WA 98052 482 USA 484 Email: henrikn@microsoft.com 486 Larry Masinter 487 Adobe Systems, Incorporated 488 345 Park Ave 489 San Jose, CA 95110 490 USA 492 Email: LMM@acm.org 493 URI: http://larry.masinter.net/ 495 Paul J. Leach 496 Microsoft Corporation 497 1 Microsoft Way 498 Redmond, WA 98052 500 Email: paulle@microsoft.com 502 Tim Berners-Lee 503 World Wide Web Consortium 504 MIT Computer Science and Artificial Intelligence Laboratory 505 The Stata Center, Building 32 506 32 Vassar Street 507 Cambridge, MA 02139 508 USA 510 Email: timbl@w3.org 511 URI: http://www.w3.org/People/Berners-Lee/ 512 Yves Lafon (editor) 513 World Wide Web Consortium 514 W3C / ERCIM 515 2004, rte des Lucioles 516 Sophia-Antipolis, AM 06902 517 France 519 Email: ylafon@w3.org 520 URI: http://www.raubacapeu.net/people/yves/ 522 Julian F. Reschke (editor) 523 greenbytes GmbH 524 Hafenweg 16 525 Muenster, NW 48155 526 Germany 528 Phone: +49 251 2807760 529 Fax: +49 251 2807761 530 Email: julian.reschke@greenbytes.de 531 URI: http://greenbytes.de/tech/webdav/ 533 Full Copyright Statement 535 Copyright (C) The IETF Trust (2008). 537 This document is subject to the rights, licenses and restrictions 538 contained in BCP 78, and except as set forth therein, the authors 539 retain all their rights. 541 This document and the information contained herein are provided on an 542 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 543 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 544 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 545 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 546 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 547 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 549 Intellectual Property 551 The IETF takes no position regarding the validity or scope of any 552 Intellectual Property Rights or other rights that might be claimed to 553 pertain to the implementation or use of the technology described in 554 this document or the extent to which any license under such rights 555 might or might not be available; nor does it represent that it has 556 made any independent effort to identify any such rights. Information 557 on the procedures with respect to rights in RFC documents can be 558 found in BCP 78 and BCP 79. 560 Copies of IPR disclosures made to the IETF Secretariat and any 561 assurances of licenses to be made available, or the result of an 562 attempt made to obtain a general license or permission for the use of 563 such proprietary rights by implementers or users of this 564 specification can be obtained from the IETF on-line IPR repository at 565 http://www.ietf.org/ipr. 567 The IETF invites any interested party to bring to its attention any 568 copyrights, patents or patent applications, or other proprietary 569 rights that may cover technology that may be required to implement 570 this standard. Please address the information to the IETF at 571 ietf-ipr@ietf.org.