idnits 2.17.1 draft-ietf-httpbis-p7-auth-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5156 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-09 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-09 ** 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 (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis 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: September 9, 2010 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 March 8, 2010 22 HTTP/1.1, part 7: Authentication 23 draft-ietf-httpbis-p7-auth-09 25 Abstract 27 The Hypertext Transfer Protocol (HTTP) is an application-level 28 protocol for distributed, collaborative, hypermedia information 29 systems. HTTP has been in use by the World Wide Web global 30 information initiative since 1990. This document is Part 7 of the 31 seven-part specification that defines the protocol referred to as 32 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines 33 HTTP Authentication. 35 Editorial Note (To be removed by RFC Editor) 37 Discussion of this draft should take place on the HTTPBIS working 38 group mailing list (ietf-http-wg@w3.org). The current issues list is 39 at and related 40 documents (including fancy diffs) can be found at 41 . 43 The changes in this draft are summarized in Appendix C.10. 45 Status of this Memo 47 This Internet-Draft is submitted to IETF in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF), its areas, and its working groups. Note that 52 other groups may also distribute working documents as Internet- 53 Drafts. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 The list of current Internet-Drafts can be accessed at 61 http://www.ietf.org/ietf/1id-abstracts.txt. 63 The list of Internet-Draft Shadow Directories can be accessed at 64 http://www.ietf.org/shadow.html. 66 This Internet-Draft will expire on September 9, 2010. 68 Copyright Notice 70 Copyright (c) 2010 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the BSD License. 83 This document may contain material from IETF Documents or IETF 84 Contributions published or made publicly available before November 85 10, 2008. The person(s) controlling the copyright in some of this 86 material may not have granted the IETF Trust the right to allow 87 modifications of such material outside the IETF Standards Process. 88 Without obtaining an adequate license from the person(s) controlling 89 the copyright in such materials, this document may not be modified 90 outside the IETF Standards Process, and derivative works of it may 91 not be created outside the IETF Standards Process, except to format 92 it for publication as an RFC or to translate it into languages other 93 than English. 95 Table of Contents 97 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 98 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 99 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 100 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 101 1.2.2. ABNF Rules defined in other Parts of the 102 Specification . . . . . . . . . . . . . . . . . . . . 5 103 2. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 104 2.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 5 105 2.2. 407 Proxy Authentication Required . . . . . . . . . . . . 5 106 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 5 107 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 6 108 3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 6 109 3.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 7 110 3.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7 111 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 112 4.1. Status Code Registration . . . . . . . . . . . . . . . . . 8 113 4.2. Message Header Registration . . . . . . . . . . . . . . . 8 114 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 115 5.1. Authentication Credentials and Idle Clients . . . . . . . 9 116 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 117 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 118 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 119 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 120 Appendix A. Compatibility with Previous Versions . . . . . . . . 10 121 A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 10 122 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 11 123 Appendix C. Change Log (to be removed by RFC Editor before 124 publication) . . . . . . . . . . . . . . . . . . . . 11 125 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 11 126 C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 11 127 C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 11 128 C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 12 129 C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 12 130 C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 12 131 C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 12 132 C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 12 133 C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 12 134 C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 13 135 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 138 1. Introduction 140 This document defines HTTP/1.1 access control and authentication. 141 Right now it includes the extracted relevant sections of RFC 2616 142 with only minor changes. The intention is to move the general 143 framework for HTTP authentication here, as currently specified in 144 [RFC2617], and allow the individual authentication mechanisms to be 145 defined elsewhere. This introduction will be rewritten when that 146 occurs. 148 HTTP provides several OPTIONAL challenge-response authentication 149 mechanisms which can be used by a server to challenge a client 150 request and by a client to provide authentication information. The 151 general framework for access authentication, and the specification of 152 "basic" and "digest" authentication, are specified in "HTTP 153 Authentication: Basic and Digest Access Authentication" [RFC2617]. 154 This specification adopts the definitions of "challenge" and 155 "credentials" from that specification. 157 1.1. Requirements 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 An implementation is not compliant if it fails to satisfy one or more 164 of the MUST or REQUIRED level requirements for the protocols it 165 implements. An implementation that satisfies all the MUST or 166 REQUIRED level and all the SHOULD level requirements for its 167 protocols is said to be "unconditionally compliant"; one that 168 satisfies all the MUST level requirements but not all the SHOULD 169 level requirements for its protocols is said to be "conditionally 170 compliant." 172 1.2. Syntax Notation 174 This specification uses the ABNF syntax defined in Section 1.2 of 175 [Part1] (which extends the syntax defined in [RFC5234] with a list 176 rule). Appendix B shows the collected ABNF, with the list rule 177 expanded. 179 The following core rules are included by reference, as defined in 180 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 181 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 182 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 183 sequence of data), SP (space), VCHAR (any visible USASCII character), 184 and WSP (whitespace). 186 1.2.1. Core Rules 188 The core rules below are defined in Section 1.2.2 of [Part1]: 190 OWS = 192 1.2.2. ABNF Rules defined in other Parts of the Specification 194 The ABNF rules below are defined in other specifications: 196 challenge = 197 credentials = 199 2. Status Code Definitions 201 2.1. 401 Unauthorized 203 The request requires user authentication. The response MUST include 204 a WWW-Authenticate header field (Section 3.4) containing a challenge 205 applicable to the requested resource. The client MAY repeat the 206 request with a suitable Authorization header field (Section 3.1). If 207 the request already included Authorization credentials, then the 401 208 response indicates that authorization has been refused for those 209 credentials. If the 401 response contains the same challenge as the 210 prior response, and the user agent has already attempted 211 authentication at least once, then the user SHOULD be presented the 212 entity that was given in the response, since that entity might 213 include relevant diagnostic information. HTTP access authentication 214 is explained in "HTTP Authentication: Basic and Digest Access 215 Authentication" [RFC2617]. 217 2.2. 407 Proxy Authentication Required 219 This code is similar to 401 (Unauthorized), but indicates that the 220 client must first authenticate itself with the proxy. The proxy MUST 221 return a Proxy-Authenticate header field (Section 3.2) containing a 222 challenge applicable to the proxy for the requested resource. The 223 client MAY repeat the request with a suitable Proxy-Authorization 224 header field (Section 3.3). HTTP access authentication is explained 225 in "HTTP Authentication: Basic and Digest Access Authentication" 226 [RFC2617]. 228 3. Header Field Definitions 230 This section defines the syntax and semantics of HTTP/1.1 header 231 fields related to authentication. 233 3.1. Authorization 235 The "Authorization" request-header field allows a user agent to 236 authenticate itself with a server -- usually, but not necessarily, 237 after receiving a 401 (Unauthorized) response. Its value consists of 238 credentials containing information of the user agent for the realm of 239 the resource being requested. 241 Authorization = "Authorization" ":" OWS Authorization-v 242 Authorization-v = credentials 244 HTTP access authentication is described in "HTTP Authentication: 245 Basic and Digest Access Authentication" [RFC2617]. If a request is 246 authenticated and a realm specified, the same credentials SHOULD be 247 valid for all other requests within this realm (assuming that the 248 authentication scheme itself does not require otherwise, such as 249 credentials that vary according to a challenge value or using 250 synchronized clocks). 252 When a shared cache (see Section 1.2 of [Part6]) receives a request 253 containing an Authorization field, it MUST NOT return the 254 corresponding response as a reply to any other request, unless one of 255 the following specific exceptions holds: 257 1. If the response includes the "s-maxage" cache-control directive, 258 the cache MAY use that response in replying to a subsequent 259 request. But (if the specified maximum age has passed) a proxy 260 cache MUST first revalidate it with the origin server, using the 261 request-headers from the new request to allow the origin server 262 to authenticate the new request. (This is the defined behavior 263 for s-maxage.) If the response includes "s-maxage=0", the proxy 264 MUST always revalidate it before re-using it. 266 2. If the response includes the "must-revalidate" cache-control 267 directive, the cache MAY use that response in replying to a 268 subsequent request. But if the response is stale, all caches 269 MUST first revalidate it with the origin server, using the 270 request-headers from the new request to allow the origin server 271 to authenticate the new request. 273 3. If the response includes the "public" cache-control directive, it 274 MAY be returned in reply to any subsequent request. 276 3.2. Proxy-Authenticate 278 The "Proxy-Authenticate" response-header field consists of a 279 challenge that indicates the authentication scheme and parameters 280 applicable to the proxy for this request-target. It MUST be included 281 as part of a 407 (Proxy Authentication Required) response. 283 Proxy-Authenticate = "Proxy-Authenticate" ":" OWS 284 Proxy-Authenticate-v 285 Proxy-Authenticate-v = 1#challenge 287 The HTTP access authentication process is described in "HTTP 288 Authentication: Basic and Digest Access Authentication" [RFC2617]. 289 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 290 only to the current connection and SHOULD NOT be passed on to 291 downstream clients. However, an intermediate proxy might need to 292 obtain its own credentials by requesting them from the downstream 293 client, which in some circumstances will appear as if the proxy is 294 forwarding the Proxy-Authenticate header field. 296 3.3. Proxy-Authorization 298 The "Proxy-Authorization" request-header field allows the client to 299 identify itself (or its user) to a proxy which requires 300 authentication. Its value consists of credentials containing the 301 authentication information of the user agent for the proxy and/or 302 realm of the resource being requested. 304 Proxy-Authorization = "Proxy-Authorization" ":" OWS 305 Proxy-Authorization-v 306 Proxy-Authorization-v = credentials 308 The HTTP access authentication process is described in "HTTP 309 Authentication: Basic and Digest Access Authentication" [RFC2617]. 310 Unlike Authorization, the Proxy-Authorization header field applies 311 only to the next outbound proxy that demanded authentication using 312 the Proxy-Authenticate field. When multiple proxies are used in a 313 chain, the Proxy-Authorization header field is consumed by the first 314 outbound proxy that was expecting to receive credentials. A proxy 315 MAY relay the credentials from the client request to the next proxy 316 if that is the mechanism by which the proxies cooperatively 317 authenticate a given request. 319 3.4. WWW-Authenticate 321 The "WWW-Authenticate" response-header field consists of at least one 322 challenge that indicates the authentication scheme(s) and parameters 323 applicable to the request-target. It MUST be included in 401 324 (Unauthorized) response messages. 326 WWW-Authenticate = "WWW-Authenticate" ":" OWS WWW-Authenticate-v 327 WWW-Authenticate-v = 1#challenge 329 The HTTP access authentication process is described in "HTTP 330 Authentication: Basic and Digest Access Authentication" [RFC2617]. 331 User agents are advised to take special care in parsing the WWW- 332 Authenticate field value as it might contain more than one challenge, 333 or if more than one WWW-Authenticate header field is provided, the 334 contents of a challenge itself can contain a comma-separated list of 335 authentication parameters. 337 4. IANA Considerations 339 4.1. Status Code Registration 341 The HTTP Status Code Registry located at 342 should be updated 343 with the registrations below: 345 +-------+-------------------------------+-------------+ 346 | Value | Description | Reference | 347 +-------+-------------------------------+-------------+ 348 | 401 | Unauthorized | Section 2.1 | 349 | 407 | Proxy Authentication Required | Section 2.2 | 350 +-------+-------------------------------+-------------+ 352 4.2. Message Header Registration 354 The Message Header Registry located at should be 356 updated with the permanent registrations below (see [RFC3864]): 358 +---------------------+----------+----------+-------------+ 359 | Header Field Name | Protocol | Status | Reference | 360 +---------------------+----------+----------+-------------+ 361 | Authorization | http | standard | Section 3.1 | 362 | Proxy-Authenticate | http | standard | Section 3.2 | 363 | Proxy-Authorization | http | standard | Section 3.3 | 364 | WWW-Authenticate | http | standard | Section 3.4 | 365 +---------------------+----------+----------+-------------+ 367 The change controller is: "IETF (iesg@ietf.org) - Internet 368 Engineering Task Force". 370 5. Security Considerations 372 This section is meant to inform application developers, information 373 providers, and users of the security limitations in HTTP/1.1 as 374 described by this document. The discussion does not include 375 definitive solutions to the problems revealed, though it does make 376 some suggestions for reducing security risks. 378 5.1. Authentication Credentials and Idle Clients 380 Existing HTTP clients and user agents typically retain authentication 381 information indefinitely. HTTP/1.1 does not provide a method for a 382 server to direct clients to discard these cached credentials. This 383 is a significant defect that requires further extensions to HTTP. 384 Circumstances under which credential caching can interfere with the 385 application's security model include but are not limited to: 387 o Clients which have been idle for an extended period following 388 which the server might wish to cause the client to reprompt the 389 user for credentials. 391 o Applications which include a session termination indication (such 392 as a "logout" or "commit" button on a page) after which the server 393 side of the application "knows" that there is no further reason 394 for the client to retain the credentials. 396 This is currently under separate study. There are a number of work- 397 arounds to parts of this problem, and we encourage the use of 398 password protection in screen savers, idle time-outs, and other 399 methods which mitigate the security problems inherent in this 400 problem. In particular, user agents which cache credentials are 401 encouraged to provide a readily accessible mechanism for discarding 402 cached credentials under user control. 404 6. Acknowledgments 406 [[acks: TBD.]] 408 7. References 410 7.1. Normative References 412 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 413 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 414 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 415 and Message Parsing", draft-ietf-httpbis-p1-messaging-09 416 (work in progress), March 2010. 418 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 419 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 420 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 421 6: Caching", draft-ietf-httpbis-p6-cache-09 (work in 422 progress), March 2010. 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 428 Leach, P., Luotonen, A., and L. Stewart, "HTTP 429 Authentication: Basic and Digest Access Authentication", 430 RFC 2617, June 1999. 432 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 433 Specifications: ABNF", STD 68, RFC 5234, January 2008. 435 7.2. Informative References 437 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 438 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 439 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 441 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 442 Procedures for Message Header Fields", BCP 90, RFC 3864, 443 September 2004. 445 Appendix A. Compatibility with Previous Versions 447 A.1. Changes from RFC 2616 448 Appendix B. Collected ABNF 450 Authorization = "Authorization:" OWS Authorization-v 451 Authorization-v = credentials 453 OWS = 455 Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v 456 Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS 457 challenge ] ) 458 Proxy-Authorization = "Proxy-Authorization:" OWS 459 Proxy-Authorization-v 460 Proxy-Authorization-v = credentials 462 WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v 463 WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS 464 challenge ] ) 466 challenge = 467 credentials = 469 ABNF diagnostics: 471 ; Authorization defined but not used 472 ; Proxy-Authenticate defined but not used 473 ; Proxy-Authorization defined but not used 474 ; WWW-Authenticate defined but not used 476 Appendix C. Change Log (to be removed by RFC Editor before publication) 478 C.1. Since RFC2616 480 Extracted relevant partitions from [RFC2616]. 482 C.2. Since draft-ietf-httpbis-p7-auth-00 484 Closed issues: 486 o : "Normative and 487 Informative references" 489 C.3. Since draft-ietf-httpbis-p7-auth-01 491 Ongoing work on ABNF conversion 492 (): 494 o Explicitly import BNF rules for "challenge" and "credentials" from 495 RFC2617. 497 o Add explicit references to BNF syntax and rules imported from 498 other parts of the specification. 500 C.4. Since draft-ietf-httpbis-p7-auth-02 502 Ongoing work on IANA Message Header Registration 503 (): 505 o Reference RFC 3984, and update header registrations for headers 506 defined in this document. 508 C.5. Since draft-ietf-httpbis-p7-auth-03 510 C.6. Since draft-ietf-httpbis-p7-auth-04 512 Ongoing work on ABNF conversion 513 (): 515 o Use "/" instead of "|" for alternatives. 517 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 518 whitespace ("OWS") and required whitespace ("RWS"). 520 o Rewrite ABNFs to spell out whitespace rules, factor out header 521 value format definitions. 523 C.7. Since draft-ietf-httpbis-p7-auth-05 525 Final work on ABNF conversion 526 (): 528 o Add appendix containing collected and expanded ABNF, reorganize 529 ABNF introduction. 531 C.8. Since draft-ietf-httpbis-p7-auth-06 533 None. 535 C.9. Since draft-ietf-httpbis-p7-auth-07 537 Closed issues: 539 o : "move IANA 540 registrations for optional status codes" 542 C.10. Since draft-ietf-httpbis-p7-auth-08 544 No significant changes. 546 Index 548 4 549 401 Unauthorized (status code) 5 550 407 Proxy Authentication Required (status code) 5 552 A 553 Authorization header 6 555 G 556 Grammar 557 Authorization 6 558 Authorization-v 6 559 challenge 5 560 credentials 5 561 Proxy-Authenticate 7 562 Proxy-Authenticate-v 7 563 Proxy-Authorization 7 564 Proxy-Authorization-v 7 565 WWW-Authenticate 7 566 WWW-Authenticate-v 7 568 H 569 Headers 570 Authorization 6 571 Proxy-Authenticate 6 572 Proxy-Authorization 7 573 WWW-Authenticate 7 575 P 576 Proxy-Authenticate header 6 577 Proxy-Authorization header 7 579 S 580 Status Codes 581 401 Unauthorized 5 582 407 Proxy Authentication Required 5 584 W 585 WWW-Authenticate header 7 587 Authors' Addresses 589 Roy T. Fielding (editor) 590 Day Software 591 23 Corporate Plaza DR, Suite 280 592 Newport Beach, CA 92660 593 USA 595 Phone: +1-949-706-5300 596 Fax: +1-949-706-5305 597 Email: fielding@gbiv.com 598 URI: http://roy.gbiv.com/ 600 Jim Gettys 601 One Laptop per Child 602 21 Oak Knoll Road 603 Carlisle, MA 01741 604 USA 606 Email: jg@laptop.org 607 URI: http://www.laptop.org/ 609 Jeffrey C. Mogul 610 Hewlett-Packard Company 611 HP Labs, Large Scale Systems Group 612 1501 Page Mill Road, MS 1177 613 Palo Alto, CA 94304 614 USA 616 Email: JeffMogul@acm.org 618 Henrik Frystyk Nielsen 619 Microsoft Corporation 620 1 Microsoft Way 621 Redmond, WA 98052 622 USA 624 Email: henrikn@microsoft.com 625 Larry Masinter 626 Adobe Systems, Incorporated 627 345 Park Ave 628 San Jose, CA 95110 629 USA 631 Email: LMM@acm.org 632 URI: http://larry.masinter.net/ 634 Paul J. Leach 635 Microsoft Corporation 636 1 Microsoft Way 637 Redmond, WA 98052 639 Email: paulle@microsoft.com 641 Tim Berners-Lee 642 World Wide Web Consortium 643 MIT Computer Science and Artificial Intelligence Laboratory 644 The Stata Center, Building 32 645 32 Vassar Street 646 Cambridge, MA 02139 647 USA 649 Email: timbl@w3.org 650 URI: http://www.w3.org/People/Berners-Lee/ 652 Yves Lafon (editor) 653 World Wide Web Consortium 654 W3C / ERCIM 655 2004, rte des Lucioles 656 Sophia-Antipolis, AM 06902 657 France 659 Email: ylafon@w3.org 660 URI: http://www.raubacapeu.net/people/yves/ 661 Julian F. Reschke (editor) 662 greenbytes GmbH 663 Hafenweg 16 664 Muenster, NW 48155 665 Germany 667 Phone: +49 251 2807760 668 Fax: +49 251 2807761 669 Email: julian.reschke@greenbytes.de 670 URI: http://greenbytes.de/tech/webdav/