idnits 2.17.1 draft-ietf-httpbis-p7-auth-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (August 4, 2010) is 5013 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-11 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-11 ** 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: 1 error (**), 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) Alcatel-Lucent 6 Intended status: Standards Track J. Mogul 7 Expires: February 5, 2011 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 4, 2010 22 HTTP/1.1, part 7: Authentication 23 draft-ietf-httpbis-p7-auth-11 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 B.12. 45 Status of This Memo 47 This Internet-Draft is submitted 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). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on February 5, 2011. 62 Copyright Notice 64 Copyright (c) 2010 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 This document may contain material from IETF Documents or IETF 78 Contributions published or made publicly available before November 79 10, 2008. The person(s) controlling the copyright in some of this 80 material may not have granted the IETF Trust the right to allow 81 modifications of such material outside the IETF Standards Process. 82 Without obtaining an adequate license from the person(s) controlling 83 the copyright in such materials, this document may not be modified 84 outside the IETF Standards Process, and derivative works of it may 85 not be created outside the IETF Standards Process, except to format 86 it for publication as an RFC or to translate it into languages other 87 than English. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 92 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 93 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 94 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 95 1.2.2. ABNF Rules defined in other Parts of the 96 Specification . . . . . . . . . . . . . . . . . . . . 5 97 2. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 98 2.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 5 99 2.2. 407 Proxy Authentication Required . . . . . . . . . . . . 5 100 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 5 101 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 6 102 3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 6 103 3.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 7 104 3.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7 105 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 106 4.1. Status Code Registration . . . . . . . . . . . . . . . . . 8 107 4.2. Header Field Registration . . . . . . . . . . . . . . . . 8 108 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 109 5.1. Authentication Credentials and Idle Clients . . . . . . . 9 110 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 111 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 112 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 113 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 114 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 10 115 Appendix B. Change Log (to be removed by RFC Editor before 116 publication) . . . . . . . . . . . . . . . . . . . . 11 117 B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 11 118 B.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 11 119 B.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 11 120 B.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 11 121 B.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 11 122 B.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 11 123 B.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 12 124 B.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 12 125 B.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 12 126 B.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 12 127 B.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 12 128 B.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 12 129 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 131 1. Introduction 133 This document defines HTTP/1.1 access control and authentication. 134 Right now it includes the extracted relevant sections of RFC 2616 135 with only minor changes. The intention is to move the general 136 framework for HTTP authentication here, as currently specified in 137 [RFC2617], and allow the individual authentication mechanisms to be 138 defined elsewhere. This introduction will be rewritten when that 139 occurs. 141 HTTP provides several OPTIONAL challenge-response authentication 142 mechanisms which can be used by a server to challenge a client 143 request and by a client to provide authentication information. The 144 general framework for access authentication, and the specification of 145 "basic" and "digest" authentication, are specified in "HTTP 146 Authentication: Basic and Digest Access Authentication" [RFC2617]. 147 This specification adopts the definitions of "challenge" and 148 "credentials" from that specification. 150 1.1. Requirements 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 An implementation is not compliant if it fails to satisfy one or more 157 of the "MUST" or "REQUIRED" level requirements for the protocols it 158 implements. An implementation that satisfies all the "MUST" or 159 "REQUIRED" level and all the "SHOULD" level requirements for its 160 protocols is said to be "unconditionally compliant"; one that 161 satisfies all the "MUST" level requirements but not all the "SHOULD" 162 level requirements for its protocols is said to be "conditionally 163 compliant". 165 1.2. Syntax Notation 167 This specification uses the ABNF syntax defined in Section 1.2 of 168 [Part1] (which extends the syntax defined in [RFC5234] with a list 169 rule). Appendix A shows the collected ABNF, with the list rule 170 expanded. 172 The following core rules are included by reference, as defined in 173 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 174 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 175 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 176 sequence of data), SP (space), VCHAR (any visible USASCII character), 177 and WSP (whitespace). 179 1.2.1. Core Rules 181 The core rules below are defined in Section 1.2.2 of [Part1]: 183 OWS = 185 1.2.2. ABNF Rules defined in other Parts of the Specification 187 The ABNF rules below are defined in other specifications: 189 challenge = 190 credentials = 192 2. Status Code Definitions 194 2.1. 401 Unauthorized 196 The request requires user authentication. The response MUST include 197 a WWW-Authenticate header field (Section 3.4) containing a challenge 198 applicable to the target resource. The client MAY repeat the request 199 with a suitable Authorization header field (Section 3.1). If the 200 request already included Authorization credentials, then the 401 201 response indicates that authorization has been refused for those 202 credentials. If the 401 response contains the same challenge as the 203 prior response, and the user agent has already attempted 204 authentication at least once, then the user SHOULD be presented the 205 representation that was given in the response, since that 206 representation might include relevant diagnostic information. HTTP 207 access authentication is explained in "HTTP Authentication: Basic and 208 Digest Access Authentication" [RFC2617]. 210 2.2. 407 Proxy Authentication Required 212 This code is similar to 401 (Unauthorized), but indicates that the 213 client must first authenticate itself with the proxy. The proxy MUST 214 return a Proxy-Authenticate header field (Section 3.2) containing a 215 challenge applicable to the proxy for the target resource. The 216 client MAY repeat the request with a suitable Proxy-Authorization 217 header field (Section 3.3). HTTP access authentication is explained 218 in "HTTP Authentication: Basic and Digest Access Authentication" 219 [RFC2617]. 221 3. Header Field Definitions 223 This section defines the syntax and semantics of HTTP/1.1 header 224 fields related to authentication. 226 3.1. Authorization 228 The "Authorization" request-header field allows a user agent to 229 authenticate itself with a server -- usually, but not necessarily, 230 after receiving a 401 (Unauthorized) response. Its value consists of 231 credentials containing information of the user agent for the realm of 232 the resource being requested. 234 Authorization = "Authorization" ":" OWS Authorization-v 235 Authorization-v = credentials 237 HTTP access authentication is described in "HTTP Authentication: 238 Basic and Digest Access Authentication" [RFC2617]. If a request is 239 authenticated and a realm specified, the same credentials SHOULD be 240 valid for all other requests within this realm (assuming that the 241 authentication scheme itself does not require otherwise, such as 242 credentials that vary according to a challenge value or using 243 synchronized clocks). 245 When a shared cache (see Section 1.2 of [Part6]) receives a request 246 containing an Authorization field, it MUST NOT return the 247 corresponding response as a reply to any other request, unless one of 248 the following specific exceptions holds: 250 1. If the response includes the "s-maxage" cache-control directive, 251 the cache MAY use that response in replying to a subsequent 252 request. But (if the specified maximum age has passed) a proxy 253 cache MUST first revalidate it with the origin server, using the 254 request-headers from the new request to allow the origin server 255 to authenticate the new request. (This is the defined behavior 256 for s-maxage.) If the response includes "s-maxage=0", the proxy 257 MUST always revalidate it before re-using it. 259 2. If the response includes the "must-revalidate" cache-control 260 directive, the cache MAY use that response in replying to a 261 subsequent request. But if the response is stale, all caches 262 MUST first revalidate it with the origin server, using the 263 request-headers from the new request to allow the origin server 264 to authenticate the new request. 266 3. If the response includes the "public" cache-control directive, it 267 MAY be returned in reply to any subsequent request. 269 3.2. Proxy-Authenticate 271 The "Proxy-Authenticate" response-header field consists of a 272 challenge that indicates the authentication scheme and parameters 273 applicable to the proxy for this effective request URI (Section 4.3 274 of [Part1]). It MUST be included as part of a 407 (Proxy 275 Authentication Required) response. 277 Proxy-Authenticate = "Proxy-Authenticate" ":" OWS 278 Proxy-Authenticate-v 279 Proxy-Authenticate-v = 1#challenge 281 The HTTP access authentication process is described in "HTTP 282 Authentication: Basic and Digest Access Authentication" [RFC2617]. 283 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 284 only to the current connection and SHOULD NOT be passed on to 285 downstream clients. However, an intermediate proxy might need to 286 obtain its own credentials by requesting them from the downstream 287 client, which in some circumstances will appear as if the proxy is 288 forwarding the Proxy-Authenticate header field. 290 3.3. Proxy-Authorization 292 The "Proxy-Authorization" request-header field allows the client to 293 identify itself (or its user) to a proxy which requires 294 authentication. Its value consists of credentials containing the 295 authentication information of the user agent for the proxy and/or 296 realm of the resource being requested. 298 Proxy-Authorization = "Proxy-Authorization" ":" OWS 299 Proxy-Authorization-v 300 Proxy-Authorization-v = credentials 302 The HTTP access authentication process is described in "HTTP 303 Authentication: Basic and Digest Access Authentication" [RFC2617]. 304 Unlike Authorization, the Proxy-Authorization header field applies 305 only to the next outbound proxy that demanded authentication using 306 the Proxy-Authenticate field. When multiple proxies are used in a 307 chain, the Proxy-Authorization header field is consumed by the first 308 outbound proxy that was expecting to receive credentials. A proxy 309 MAY relay the credentials from the client request to the next proxy 310 if that is the mechanism by which the proxies cooperatively 311 authenticate a given request. 313 3.4. WWW-Authenticate 315 The "WWW-Authenticate" response-header field consists of at least one 316 challenge that indicates the authentication scheme(s) and parameters 317 applicable to the effective request URI (Section 4.3 of [Part1]). It 318 MUST be included in 401 (Unauthorized) response messages. 320 WWW-Authenticate = "WWW-Authenticate" ":" OWS WWW-Authenticate-v 321 WWW-Authenticate-v = 1#challenge 323 The HTTP access authentication process is described in "HTTP 324 Authentication: Basic and Digest Access Authentication" [RFC2617]. 325 User agents are advised to take special care in parsing the WWW- 326 Authenticate field value as it might contain more than one challenge, 327 or if more than one WWW-Authenticate header field is provided, the 328 contents of a challenge itself can contain a comma-separated list of 329 authentication parameters. 331 4. IANA Considerations 333 4.1. Status Code Registration 335 The HTTP Status Code Registry located at 336 shall be updated 337 with the registrations below: 339 +-------+-------------------------------+-------------+ 340 | Value | Description | Reference | 341 +-------+-------------------------------+-------------+ 342 | 401 | Unauthorized | Section 2.1 | 343 | 407 | Proxy Authentication Required | Section 2.2 | 344 +-------+-------------------------------+-------------+ 346 4.2. Header Field Registration 348 The Message Header Field Registry located at shall be 350 updated with the permanent registrations below (see [RFC3864]): 352 +---------------------+----------+----------+-------------+ 353 | Header Field Name | Protocol | Status | Reference | 354 +---------------------+----------+----------+-------------+ 355 | Authorization | http | standard | Section 3.1 | 356 | Proxy-Authenticate | http | standard | Section 3.2 | 357 | Proxy-Authorization | http | standard | Section 3.3 | 358 | WWW-Authenticate | http | standard | Section 3.4 | 359 +---------------------+----------+----------+-------------+ 361 The change controller is: "IETF (iesg@ietf.org) - Internet 362 Engineering Task Force". 364 5. Security Considerations 366 This section is meant to inform application developers, information 367 providers, and users of the security limitations in HTTP/1.1 as 368 described by this document. The discussion does not include 369 definitive solutions to the problems revealed, though it does make 370 some suggestions for reducing security risks. 372 5.1. Authentication Credentials and Idle Clients 374 Existing HTTP clients and user agents typically retain authentication 375 information indefinitely. HTTP/1.1 does not provide a method for a 376 server to direct clients to discard these cached credentials. This 377 is a significant defect that requires further extensions to HTTP. 378 Circumstances under which credential caching can interfere with the 379 application's security model include but are not limited to: 381 o Clients which have been idle for an extended period following 382 which the server might wish to cause the client to reprompt the 383 user for credentials. 385 o Applications which include a session termination indication (such 386 as a "logout" or "commit" button on a page) after which the server 387 side of the application "knows" that there is no further reason 388 for the client to retain the credentials. 390 This is currently under separate study. There are a number of work- 391 arounds to parts of this problem, and we encourage the use of 392 password protection in screen savers, idle time-outs, and other 393 methods which mitigate the security problems inherent in this 394 problem. In particular, user agents which cache credentials are 395 encouraged to provide a readily accessible mechanism for discarding 396 cached credentials under user control. 398 6. Acknowledgments 400 [[acks: TBD.]] 402 7. References 404 7.1. Normative References 406 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 407 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 408 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 409 and Message Parsing", draft-ietf-httpbis-p1-messaging-11 410 (work in progress), August 2010. 412 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 413 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 414 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 415 6: Caching", draft-ietf-httpbis-p6-cache-11 (work in 416 progress), August 2010. 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, March 1997. 421 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 422 Leach, P., Luotonen, A., and L. Stewart, "HTTP 423 Authentication: Basic and Digest Access Authentication", 424 RFC 2617, June 1999. 426 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 427 Specifications: ABNF", STD 68, RFC 5234, January 2008. 429 7.2. Informative References 431 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 432 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 433 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 435 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 436 Procedures for Message Header Fields", BCP 90, RFC 3864, 437 September 2004. 439 Appendix A. Collected ABNF 441 Authorization = "Authorization:" OWS Authorization-v 442 Authorization-v = credentials 444 OWS = 446 Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v 447 Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS 448 challenge ] ) 449 Proxy-Authorization = "Proxy-Authorization:" OWS 450 Proxy-Authorization-v 451 Proxy-Authorization-v = credentials 453 WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v 454 WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS 455 challenge ] ) 457 challenge = 458 credentials = 460 ABNF diagnostics: 462 ; Authorization defined but not used 463 ; Proxy-Authenticate defined but not used 464 ; Proxy-Authorization defined but not used 465 ; WWW-Authenticate defined but not used 467 Appendix B. Change Log (to be removed by RFC Editor before publication) 469 B.1. Since RFC2616 471 Extracted relevant partitions from [RFC2616]. 473 B.2. Since draft-ietf-httpbis-p7-auth-00 475 Closed issues: 477 o : "Normative and 478 Informative references" 480 B.3. Since draft-ietf-httpbis-p7-auth-01 482 Ongoing work on ABNF conversion 483 (): 485 o Explicitly import BNF rules for "challenge" and "credentials" from 486 RFC2617. 488 o Add explicit references to BNF syntax and rules imported from 489 other parts of the specification. 491 B.4. Since draft-ietf-httpbis-p7-auth-02 493 Ongoing work on IANA Message Header Registration 494 (): 496 o Reference RFC 3984, and update header registrations for headers 497 defined in this document. 499 B.5. Since draft-ietf-httpbis-p7-auth-03 501 B.6. Since draft-ietf-httpbis-p7-auth-04 503 Ongoing work on ABNF conversion 504 (): 506 o Use "/" instead of "|" for alternatives. 508 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 509 whitespace ("OWS") and required whitespace ("RWS"). 511 o Rewrite ABNFs to spell out whitespace rules, factor out header 512 value format definitions. 514 B.7. Since draft-ietf-httpbis-p7-auth-05 516 Final work on ABNF conversion 517 (): 519 o Add appendix containing collected and expanded ABNF, reorganize 520 ABNF introduction. 522 B.8. Since draft-ietf-httpbis-p7-auth-06 524 None. 526 B.9. Since draft-ietf-httpbis-p7-auth-07 528 Closed issues: 530 o : "move IANA 531 registrations for optional status codes" 533 B.10. Since draft-ietf-httpbis-p7-auth-08 535 No significant changes. 537 B.11. Since draft-ietf-httpbis-p7-auth-09 539 Partly resolved issues: 541 o : "Term for the 542 requested resource's URI" 544 B.12. Since draft-ietf-httpbis-p7-auth-10 546 None yet. 548 Index 550 4 551 401 Unauthorized (status code) 5 552 407 Proxy Authentication Required (status code) 5 554 A 555 Authorization header 6 557 G 558 Grammar 559 Authorization 6 560 Authorization-v 6 561 challenge 5 562 credentials 5 563 Proxy-Authenticate 7 564 Proxy-Authenticate-v 7 565 Proxy-Authorization 7 566 Proxy-Authorization-v 7 567 WWW-Authenticate 7 568 WWW-Authenticate-v 7 570 H 571 Headers 572 Authorization 6 573 Proxy-Authenticate 6 574 Proxy-Authorization 7 575 WWW-Authenticate 7 577 P 578 Proxy-Authenticate header 6 579 Proxy-Authorization header 7 581 S 582 Status Codes 583 401 Unauthorized 5 584 407 Proxy Authentication Required 5 586 W 587 WWW-Authenticate header 7 589 Authors' Addresses 591 Roy T. Fielding (editor) 592 Day Software 593 23 Corporate Plaza DR, Suite 280 594 Newport Beach, CA 92660 595 USA 597 Phone: +1-949-706-5300 598 Fax: +1-949-706-5305 599 EMail: fielding@gbiv.com 600 URI: http://roy.gbiv.com/ 601 Jim Gettys 602 Alcatel-Lucent Bell Labs 603 21 Oak Knoll Road 604 Carlisle, MA 01741 605 USA 607 EMail: jg@freedesktop.org 608 URI: http://gettys.wordpress.com/ 610 Jeffrey C. Mogul 611 Hewlett-Packard Company 612 HP Labs, Large Scale Systems Group 613 1501 Page Mill Road, MS 1177 614 Palo Alto, CA 94304 615 USA 617 EMail: JeffMogul@acm.org 619 Henrik Frystyk Nielsen 620 Microsoft Corporation 621 1 Microsoft Way 622 Redmond, WA 98052 623 USA 625 EMail: henrikn@microsoft.com 627 Larry Masinter 628 Adobe Systems, Incorporated 629 345 Park Ave 630 San Jose, CA 95110 631 USA 633 EMail: LMM@acm.org 634 URI: http://larry.masinter.net/ 636 Paul J. Leach 637 Microsoft Corporation 638 1 Microsoft Way 639 Redmond, WA 98052 641 EMail: paulle@microsoft.com 642 Tim Berners-Lee 643 World Wide Web Consortium 644 MIT Computer Science and Artificial Intelligence Laboratory 645 The Stata Center, Building 32 646 32 Vassar Street 647 Cambridge, MA 02139 648 USA 650 EMail: timbl@w3.org 651 URI: http://www.w3.org/People/Berners-Lee/ 653 Yves Lafon (editor) 654 World Wide Web Consortium 655 W3C / ERCIM 656 2004, rte des Lucioles 657 Sophia-Antipolis, AM 06902 658 France 660 EMail: ylafon@w3.org 661 URI: http://www.raubacapeu.net/people/yves/ 663 Julian F. Reschke (editor) 664 greenbytes GmbH 665 Hafenweg 16 666 Muenster, NW 48155 667 Germany 669 Phone: +49 251 2807760 670 Fax: +49 251 2807761 671 EMail: julian.reschke@greenbytes.de 672 URI: http://greenbytes.de/tech/webdav/