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