idnits 2.17.1 draft-ietf-httpbis-p7-auth-02.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 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 547. 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 (February 24, 2008) is 5900 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-02 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-02 ** 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: August 27, 2008 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 February 24, 2008 22 HTTP/1.1, part 7: Authentication 23 draft-ietf-httpbis-p7-auth-02 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 August 27, 2008. 50 Copyright Notice 52 Copyright (C) The IETF Trust (2008). 54 Abstract 56 The Hypertext Transfer Protocol (HTTP) is an application-level 57 protocol for distributed, collaborative, hypermedia information 58 systems. HTTP has been in use by the World Wide Web global 59 information initiative since 1990. This document is Part 7 of the 60 seven-part specification that defines the protocol referred to as 61 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines 62 HTTP Authentication. 64 Editorial Note (To be removed by RFC Editor) 66 Discussion of this draft should take place on the HTTPBIS working 67 group mailing list (ietf-http-wg@w3.org). The current issues list is 68 at and related 69 documents (including fancy diffs) can be found at 70 . 72 This draft incorporates those issue resolutions that were either 73 collected in the original RFC2616 errata list 74 (), or which were agreed upon on the 75 mailing list between October 2006 and November 2007 (as published in 76 "draft-lafon-rfc2616bis-03"). 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 82 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 83 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 84 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 5 85 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 5 86 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 5 87 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 5 88 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 6 89 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 7 90 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 93 6.1. Authentication Credentials and Idle Clients . . . . . . . 8 94 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 96 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 97 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 98 Appendix A. Compatibility with Previous Versions . . . . . . . . 9 99 A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 9 100 Appendix B. Change Log (to be removed by RFC Editor before 101 publication) . . . . . . . . . . . . . . . . . . . . 9 102 B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 9 103 B.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 9 104 B.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 9 105 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 107 Intellectual Property and Copyright Statements . . . . . . . . . . 14 109 1. Introduction 111 This document defines HTTP/1.1 access control and authentication. 112 Right now it includes the extracted relevant sections of RFC 2616 113 with only minor changes. The intention is to move the general 114 framework for HTTP authentication here, as currently specified in 115 [RFC2617], and allow the individual authentication mechanisms to be 116 defined elsewhere. This introduction will be rewritten when that 117 occurs. 119 HTTP provides several OPTIONAL challenge-response authentication 120 mechanisms which can be used by a server to challenge a client 121 request and by a client to provide authentication information. The 122 general framework for access authentication, and the specification of 123 "basic" and "digest" authentication, are specified in "HTTP 124 Authentication: Basic and Digest Access Authentication" [RFC2617]. 125 This specification adopts the definitions of "challenge" and 126 "credentials" from that specification. 128 1.1. Requirements 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 An implementation is not compliant if it fails to satisfy one or more 135 of the MUST or REQUIRED level requirements for the protocols it 136 implements. An implementation that satisfies all the MUST or 137 REQUIRED level and all the SHOULD level requirements for its 138 protocols is said to be "unconditionally compliant"; one that 139 satisfies all the MUST level requirements but not all the SHOULD 140 level requirements for its protocols is said to be "conditionally 141 compliant." 143 2. Notational Conventions and Generic Grammar 145 This specification uses the ABNF syntax defined in Section 2.1 of 146 [Part1]. [[abnf.dep: ABNF syntax and basic rules will be adopted from 147 RFC 5234, see .]] 149 The ABNF rules below are defined in other specifications: 151 challenge = 152 credentials = 154 3. Status Code Definitions 156 3.1. 401 Unauthorized 158 The request requires user authentication. The response MUST include 159 a WWW-Authenticate header field (Section 4.4) containing a challenge 160 applicable to the requested resource. The client MAY repeat the 161 request with a suitable Authorization header field (Section 4.1). If 162 the request already included Authorization credentials, then the 401 163 response indicates that authorization has been refused for those 164 credentials. If the 401 response contains the same challenge as the 165 prior response, and the user agent has already attempted 166 authentication at least once, then the user SHOULD be presented the 167 entity that was given in the response, since that entity might 168 include relevant diagnostic information. HTTP access authentication 169 is explained in "HTTP Authentication: Basic and Digest Access 170 Authentication" [RFC2617]. 172 3.2. 407 Proxy Authentication Required 174 This code is similar to 401 (Unauthorized), but indicates that the 175 client must first authenticate itself with the proxy. The proxy MUST 176 return a Proxy-Authenticate header field (Section 4.2) containing a 177 challenge applicable to the proxy for the requested resource. The 178 client MAY repeat the request with a suitable Proxy-Authorization 179 header field (Section 4.3). HTTP access authentication is explained 180 in "HTTP Authentication: Basic and Digest Access Authentication" 181 [RFC2617]. 183 4. Header Field Definitions 185 This section defines the syntax and semantics of HTTP/1.1 header 186 fields related to authentication. 188 4.1. Authorization 190 A user agent that wishes to authenticate itself with a server-- 191 usually, but not necessarily, after receiving a 401 response--does so 192 by including an Authorization request-header field with the request. 193 The Authorization field value consists of credentials containing the 194 authentication information of the user agent for the realm of the 195 resource being requested. 197 Authorization = "Authorization" ":" credentials 199 HTTP access authentication is described in "HTTP Authentication: 200 Basic and Digest Access Authentication" [RFC2617]. If a request is 201 authenticated and a realm specified, the same credentials SHOULD be 202 valid for all other requests within this realm (assuming that the 203 authentication scheme itself does not require otherwise, such as 204 credentials that vary according to a challenge value or using 205 synchronized clocks). 207 When a shared cache (see Section 9 of [Part6]) receives a request 208 containing an Authorization field, it MUST NOT return the 209 corresponding response as a reply to any other request, unless one of 210 the following specific exceptions holds: 212 1. If the response includes the "s-maxage" cache-control directive, 213 the cache MAY use that response in replying to a subsequent 214 request. But (if the specified maximum age has passed) a proxy 215 cache MUST first revalidate it with the origin server, using the 216 request-headers from the new request to allow the origin server 217 to authenticate the new request. (This is the defined behavior 218 for s-maxage.) If the response includes "s-maxage=0", the proxy 219 MUST always revalidate it before re-using it. 221 2. If the response includes the "must-revalidate" cache-control 222 directive, the cache MAY use that response in replying to a 223 subsequent request. But if the response is stale, all caches 224 MUST first revalidate it with the origin server, using the 225 request-headers from the new request to allow the origin server 226 to authenticate the new request. 228 3. If the response includes the "public" cache-control directive, it 229 MAY be returned in reply to any subsequent request. 231 4.2. Proxy-Authenticate 233 The Proxy-Authenticate response-header field MUST be included as part 234 of a 407 (Proxy Authentication Required) response. The field value 235 consists of a challenge that indicates the authentication scheme and 236 parameters applicable to the proxy for this Request-URI. 238 Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge 240 The HTTP access authentication process is described in "HTTP 241 Authentication: Basic and Digest Access Authentication" [RFC2617]. 242 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 243 only to the current connection and SHOULD NOT be passed on to 244 downstream clients. However, an intermediate proxy might need to 245 obtain its own credentials by requesting them from the downstream 246 client, which in some circumstances will appear as if the proxy is 247 forwarding the Proxy-Authenticate header field. 249 4.3. Proxy-Authorization 251 The Proxy-Authorization request-header field allows the client to 252 identify itself (or its user) to a proxy which requires 253 authentication. The Proxy-Authorization field value consists of 254 credentials containing the authentication information of the user 255 agent for the proxy and/or realm of the resource being requested. 257 Proxy-Authorization = "Proxy-Authorization" ":" credentials 259 The HTTP access authentication process is described in "HTTP 260 Authentication: Basic and Digest Access Authentication" [RFC2617]. 261 Unlike Authorization, the Proxy-Authorization header field applies 262 only to the next outbound proxy that demanded authentication using 263 the Proxy-Authenticate field. When multiple proxies are used in a 264 chain, the Proxy-Authorization header field is consumed by the first 265 outbound proxy that was expecting to receive credentials. A proxy 266 MAY relay the credentials from the client request to the next proxy 267 if that is the mechanism by which the proxies cooperatively 268 authenticate a given request. 270 4.4. WWW-Authenticate 272 The WWW-Authenticate response-header field MUST be included in 401 273 (Unauthorized) response messages. The field value consists of at 274 least one challenge that indicates the authentication scheme(s) and 275 parameters applicable to the Request-URI. 277 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge 279 The HTTP access authentication process is described in "HTTP 280 Authentication: Basic and Digest Access Authentication" [RFC2617]. 281 User agents are advised to take special care in parsing the WWW- 282 Authenticate field value as it might contain more than one challenge, 283 or if more than one WWW-Authenticate header field is provided, the 284 contents of a challenge itself can contain a comma-separated list of 285 authentication parameters. 287 5. IANA Considerations 289 [[anchor2: TBD.]] 291 6. Security Considerations 293 This section is meant to inform application developers, information 294 providers, and users of the security limitations in HTTP/1.1 as 295 described by this document. The discussion does not include 296 definitive solutions to the problems revealed, though it does make 297 some suggestions for reducing security risks. 299 6.1. Authentication Credentials and Idle Clients 301 Existing HTTP clients and user agents typically retain authentication 302 information indefinitely. HTTP/1.1 does not provide a method for a 303 server to direct clients to discard these cached credentials. This 304 is a significant defect that requires further extensions to HTTP. 305 Circumstances under which credential caching can interfere with the 306 application's security model include but are not limited to: 308 o Clients which have been idle for an extended period following 309 which the server might wish to cause the client to reprompt the 310 user for credentials. 312 o Applications which include a session termination indication (such 313 as a `logout' or `commit' button on a page) after which the server 314 side of the application `knows' that there is no further reason 315 for the client to retain the credentials. 317 This is currently under separate study. There are a number of work- 318 arounds to parts of this problem, and we encourage the use of 319 password protection in screen savers, idle time-outs, and other 320 methods which mitigate the security problems inherent in this 321 problem. In particular, user agents which cache credentials are 322 encouraged to provide a readily accessible mechanism for discarding 323 cached credentials under user control. 325 7. Acknowledgments 327 TBD. 329 8. References 331 8.1. Normative References 333 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 334 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 335 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 336 and Message Parsing", draft-ietf-httpbis-p1-messaging-02 337 (work in progress), February 2008. 339 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 340 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 341 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 342 draft-ietf-httpbis-p6-cache-02 (work in progress), 343 February 2008. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 349 Leach, P., Luotonen, A., and L. Stewart, "HTTP 350 Authentication: Basic and Digest Access Authentication", 351 RFC 2617, June 1999. 353 8.2. Informative References 355 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 356 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 357 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 359 Appendix A. Compatibility with Previous Versions 361 A.1. Changes from RFC 2616 363 Appendix B. Change Log (to be removed by RFC Editor before publication) 365 B.1. Since RFC2616 367 Extracted relevant partitions from [RFC2616]. 369 B.2. Since draft-ietf-httpbis-p7-auth-00 371 Closed issues: 373 o : "Normative 374 and Informative references" 376 B.3. Since draft-ietf-httpbis-p7-auth-01 378 Ongoing work on ABNF conversion 379 (): 381 o Explicitly import BNF rules for "challenge" and "credentials" from 382 RFC2617. 384 o Add explicit references to BNF syntax and rules imported from 385 other parts of the specification. 387 Index 389 4 390 401 Unauthorized (status code) 5 391 407 Proxy Authentication Required (status code) 5 393 A 394 Authorization header 5 396 G 397 Grammar 398 Authorization 5 399 challenge 4 400 credentials 4 401 Proxy-Authenticate 6 402 Proxy-Authorization 7 403 WWW-Authenticate 7 405 H 406 Headers 407 Authorization 5 408 Proxy-Authenticate 6 409 Proxy-Authorization 7 410 WWW-Authenticate 7 412 P 413 Proxy-Authenticate header 6 414 Proxy-Authorization header 7 416 S 417 Status Codes 418 401 Unauthorized 5 419 407 Proxy Authentication Required 5 421 W 422 WWW-Authenticate header 7 424 Authors' Addresses 426 Roy T. Fielding (editor) 427 Day Software 428 23 Corporate Plaza DR, Suite 280 429 Newport Beach, CA 92660 430 USA 432 Phone: +1-949-706-5300 433 Fax: +1-949-706-5305 434 Email: fielding@gbiv.com 435 URI: http://roy.gbiv.com/ 437 Jim Gettys 438 One Laptop per Child 439 21 Oak Knoll Road 440 Carlisle, MA 01741 441 USA 443 Email: jg@laptop.org 444 URI: http://www.laptop.org/ 446 Jeffrey C. Mogul 447 Hewlett-Packard Company 448 HP Labs, Large Scale Systems Group 449 1501 Page Mill Road, MS 1177 450 Palo Alto, CA 94304 451 USA 453 Email: JeffMogul@acm.org 455 Henrik Frystyk Nielsen 456 Microsoft Corporation 457 1 Microsoft Way 458 Redmond, WA 98052 459 USA 461 Email: henrikn@microsoft.com 462 Larry Masinter 463 Adobe Systems, Incorporated 464 345 Park Ave 465 San Jose, CA 95110 466 USA 468 Email: LMM@acm.org 469 URI: http://larry.masinter.net/ 471 Paul J. Leach 472 Microsoft Corporation 473 1 Microsoft Way 474 Redmond, WA 98052 476 Email: paulle@microsoft.com 478 Tim Berners-Lee 479 World Wide Web Consortium 480 MIT Computer Science and Artificial Intelligence Laboratory 481 The Stata Center, Building 32 482 32 Vassar Street 483 Cambridge, MA 02139 484 USA 486 Email: timbl@w3.org 487 URI: http://www.w3.org/People/Berners-Lee/ 489 Yves Lafon (editor) 490 World Wide Web Consortium 491 W3C / ERCIM 492 2004, rte des Lucioles 493 Sophia-Antipolis, AM 06902 494 France 496 Email: ylafon@w3.org 497 URI: http://www.raubacapeu.net/people/yves/ 498 Julian F. Reschke (editor) 499 greenbytes GmbH 500 Hafenweg 16 501 Muenster, NW 48155 502 Germany 504 Phone: +49 251 2807760 505 Fax: +49 251 2807761 506 Email: julian.reschke@greenbytes.de 507 URI: http://greenbytes.de/tech/webdav/ 509 Full Copyright Statement 511 Copyright (C) The IETF Trust (2008). 513 This document is subject to the rights, licenses and restrictions 514 contained in BCP 78, and except as set forth therein, the authors 515 retain all their rights. 517 This document and the information contained herein are provided on an 518 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 519 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 520 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 521 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 522 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 523 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 525 Intellectual Property 527 The IETF takes no position regarding the validity or scope of any 528 Intellectual Property Rights or other rights that might be claimed to 529 pertain to the implementation or use of the technology described in 530 this document or the extent to which any license under such rights 531 might or might not be available; nor does it represent that it has 532 made any independent effort to identify any such rights. Information 533 on the procedures with respect to rights in RFC documents can be 534 found in BCP 78 and BCP 79. 536 Copies of IPR disclosures made to the IETF Secretariat and any 537 assurances of licenses to be made available, or the result of an 538 attempt made to obtain a general license or permission for the use of 539 such proprietary rights by implementers or users of this 540 specification can be obtained from the IETF on-line IPR repository at 541 http://www.ietf.org/ipr. 543 The IETF invites any interested party to bring to its attention any 544 copyrights, patents or patent applications, or other proprietary 545 rights that may cover technology that may be required to implement 546 this standard. Please address the information to the IETF at 547 ietf-ipr@ietf.org. 549 Acknowledgment 551 Funding for the RFC Editor function is provided by the IETF 552 Administrative Support Activity (IASA).