source: draft-ietf-httpbis/06/draft-ietf-httpbis-p7-auth-06.txt @ 558

Last change on this file since 558 was 558, checked in by fielding@…, 11 years ago

Draft 06 (as recorded by www.ietf.org)

  • Property svn:eol-style set to native
File size: 27.5 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Updates: 2617 (if approved)                         One Laptop per Child
8Intended status: Standards Track                                J. Mogul
9Expires: September 10, 2009                                           HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                           March 9, 2009
23
24
25                    HTTP/1.1, part 7: Authentication
26                     draft-ietf-httpbis-p7-auth-06
27
28Status of this Memo
29
30   This Internet-Draft is submitted to IETF in full conformance with the
31   provisions of BCP 78 and BCP 79.  This document may contain material
32   from IETF Documents or IETF Contributions published or made publicly
33   available before November 10, 2008.  The person(s) controlling the
34   copyright in some of this material may not have granted the IETF
35   Trust the right to allow modifications of such material outside the
36   IETF Standards Process.  Without obtaining an adequate license from
37   the person(s) controlling the copyright in such materials, this
38   document may not be modified outside the IETF Standards Process, and
39   derivative works of it may not be created outside the IETF Standards
40   Process, except to format it for publication as an RFC or to
41   translate it into languages other than English.
42
43   Internet-Drafts are working documents of the Internet Engineering
44   Task Force (IETF), its areas, and its working groups.  Note that
45   other groups may also distribute working documents as Internet-
46   Drafts.
47
48   Internet-Drafts are draft documents valid for a maximum of six months
49   and may be updated, replaced, or obsoleted by other documents at any
50   time.  It is inappropriate to use Internet-Drafts as reference
51   material or to cite them other than as "work in progress."
52
53
54
55Fielding, et al.       Expires September 10, 2009               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7                  March 2009
58
59
60   The list of current Internet-Drafts can be accessed at
61   http://www.ietf.org/ietf/1id-abstracts.txt.
62
63   The list of Internet-Draft Shadow Directories can be accessed at
64   http://www.ietf.org/shadow.html.
65
66   This Internet-Draft will expire on September 10, 2009.
67
68Copyright Notice
69
70   Copyright (c) 2009 IETF Trust and the persons identified as the
71   document authors.  All rights reserved.
72
73   This document is subject to BCP 78 and the IETF Trust's Legal
74   Provisions Relating to IETF Documents in effect on the date of
75   publication of this document (http://trustee.ietf.org/license-info).
76   Please review these documents carefully, as they describe your rights
77   and restrictions with respect to this document.
78
79Abstract
80
81   The Hypertext Transfer Protocol (HTTP) is an application-level
82   protocol for distributed, collaborative, hypermedia information
83   systems.  HTTP has been in use by the World Wide Web global
84   information initiative since 1990.  This document is Part 7 of the
85   seven-part specification that defines the protocol referred to as
86   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 7 defines
87   HTTP Authentication.
88
89Editorial Note (To be removed by RFC Editor)
90
91   Discussion of this draft should take place on the HTTPBIS working
92   group mailing list (ietf-http-wg@w3.org).  The current issues list is
93   at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
94   documents (including fancy diffs) can be found at
95   <http://tools.ietf.org/wg/httpbis/>.
96
97   The changes in this draft are summarized in Appendix C.7.
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.       Expires September 10, 2009               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7                  March 2009
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
120     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
121       1.2.1.  Core Rules . . . . . . . . . . . . . . . . . . . . . .  5
122       1.2.2.  ABNF Rules defined in other Parts of the
123               Specification  . . . . . . . . . . . . . . . . . . . .  5
124   2.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  5
125     2.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  5
126     2.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  5
127   3.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  5
128     3.1.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  6
129     3.2.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  7
130     3.3.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  7
131     3.4.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  7
132   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
133     4.1.  Message Header Registration  . . . . . . . . . . . . . . .  8
134   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
135     5.1.  Authentication Credentials and Idle Clients  . . . . . . .  8
136   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
137   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
138     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
139     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
140   Appendix A.  Compatibility with Previous Versions  . . . . . . . . 10
141     A.1.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 10
142   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 10
143   Appendix C.  Change Log (to be removed by RFC Editor before
144                publication)  . . . . . . . . . . . . . . . . . . . . 11
145     C.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 11
146     C.2.  Since draft-ietf-httpbis-p7-auth-00  . . . . . . . . . . . 11
147     C.3.  Since draft-ietf-httpbis-p7-auth-01  . . . . . . . . . . . 11
148     C.4.  Since draft-ietf-httpbis-p7-auth-02  . . . . . . . . . . . 11
149     C.5.  Since draft-ietf-httpbis-p7-auth-03  . . . . . . . . . . . 11
150     C.6.  Since draft-ietf-httpbis-p7-auth-04  . . . . . . . . . . . 11
151     C.7.  Since draft-ietf-httpbis-p7-auth-05  . . . . . . . . . . . 12
152   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
153   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
154
155
156
157
158
159
160
161
162
163
164
165
166
167Fielding, et al.       Expires September 10, 2009               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7                  March 2009
170
171
1721.  Introduction
173
174   This document defines HTTP/1.1 access control and authentication.
175   Right now it includes the extracted relevant sections of RFC 2616
176   with only minor changes.  The intention is to move the general
177   framework for HTTP authentication here, as currently specified in
178   [RFC2617], and allow the individual authentication mechanisms to be
179   defined elsewhere.  This introduction will be rewritten when that
180   occurs.
181
182   HTTP provides several OPTIONAL challenge-response authentication
183   mechanisms which can be used by a server to challenge a client
184   request and by a client to provide authentication information.  The
185   general framework for access authentication, and the specification of
186   "basic" and "digest" authentication, are specified in "HTTP
187   Authentication: Basic and Digest Access Authentication" [RFC2617].
188   This specification adopts the definitions of "challenge" and
189   "credentials" from that specification.
190
1911.1.  Requirements
192
193   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
194   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
195   document are to be interpreted as described in [RFC2119].
196
197   An implementation is not compliant if it fails to satisfy one or more
198   of the MUST or REQUIRED level requirements for the protocols it
199   implements.  An implementation that satisfies all the MUST or
200   REQUIRED level and all the SHOULD level requirements for its
201   protocols is said to be "unconditionally compliant"; one that
202   satisfies all the MUST level requirements but not all the SHOULD
203   level requirements for its protocols is said to be "conditionally
204   compliant."
205
2061.2.  Syntax Notation
207
208   This specification uses the ABNF syntax defined in Section 1.2 of
209   [Part1] (which extends the syntax defined in [RFC5234] with a list
210   rule).  Appendix B shows the collected ABNF, with the list rule
211   expanded.
212
213   The following core rules are included by reference, as defined in
214   [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
215   (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
216   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
217   sequence of data), SP (space), VCHAR (any visible USASCII character),
218   and WSP (whitespace).
219
220
221
222
223Fielding, et al.       Expires September 10, 2009               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7                  March 2009
226
227
2281.2.1.  Core Rules
229
230   The core rules below are defined in Section 1.2.2 of [Part1]:
231
232     OWS         = <OWS, defined in [Part1], Section 1.2.2>
233
2341.2.2.  ABNF Rules defined in other Parts of the Specification
235
236   The ABNF rules below are defined in other specifications:
237
238     challenge   = <challenge, defined in [RFC2617], Section 1.2>
239     credentials = <credentials, defined in [RFC2617], Section 1.2>
240
241
2422.  Status Code Definitions
243
2442.1.  401 Unauthorized
245
246   The request requires user authentication.  The response MUST include
247   a WWW-Authenticate header field (Section 3.4) containing a challenge
248   applicable to the requested resource.  The client MAY repeat the
249   request with a suitable Authorization header field (Section 3.1).  If
250   the request already included Authorization credentials, then the 401
251   response indicates that authorization has been refused for those
252   credentials.  If the 401 response contains the same challenge as the
253   prior response, and the user agent has already attempted
254   authentication at least once, then the user SHOULD be presented the
255   entity that was given in the response, since that entity might
256   include relevant diagnostic information.  HTTP access authentication
257   is explained in "HTTP Authentication: Basic and Digest Access
258   Authentication" [RFC2617].
259
2602.2.  407 Proxy Authentication Required
261
262   This code is similar to 401 (Unauthorized), but indicates that the
263   client must first authenticate itself with the proxy.  The proxy MUST
264   return a Proxy-Authenticate header field (Section 3.2) containing a
265   challenge applicable to the proxy for the requested resource.  The
266   client MAY repeat the request with a suitable Proxy-Authorization
267   header field (Section 3.3).  HTTP access authentication is explained
268   in "HTTP Authentication: Basic and Digest Access Authentication"
269   [RFC2617].
270
271
2723.  Header Field Definitions
273
274   This section defines the syntax and semantics of HTTP/1.1 header
275   fields related to authentication.
276
277
278
279Fielding, et al.       Expires September 10, 2009               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7                  March 2009
282
283
2843.1.  Authorization
285
286   A user agent that wishes to authenticate itself with a server--
287   usually, but not necessarily, after receiving a 401 response--does so
288   by including an Authorization request-header field with the request.
289   The field "Authorization" consists of credentials containing the
290   authentication information of the user agent for the realm of the
291   resource being requested.
292
293     Authorization   = "Authorization" ":" OWS Authorization-v
294     Authorization-v = credentials
295
296   HTTP access authentication is described in "HTTP Authentication:
297   Basic and Digest Access Authentication" [RFC2617].  If a request is
298   authenticated and a realm specified, the same credentials SHOULD be
299   valid for all other requests within this realm (assuming that the
300   authentication scheme itself does not require otherwise, such as
301   credentials that vary according to a challenge value or using
302   synchronized clocks).
303
304   When a shared cache (see Section 1.2 of [Part6]) receives a request
305   containing an Authorization field, it MUST NOT return the
306   corresponding response as a reply to any other request, unless one of
307   the following specific exceptions holds:
308
309   1.  If the response includes the "s-maxage" cache-control directive,
310       the cache MAY use that response in replying to a subsequent
311       request.  But (if the specified maximum age has passed) a proxy
312       cache MUST first revalidate it with the origin server, using the
313       request-headers from the new request to allow the origin server
314       to authenticate the new request.  (This is the defined behavior
315       for s-maxage.)  If the response includes "s-maxage=0", the proxy
316       MUST always revalidate it before re-using it.
317
318   2.  If the response includes the "must-revalidate" cache-control
319       directive, the cache MAY use that response in replying to a
320       subsequent request.  But if the response is stale, all caches
321       MUST first revalidate it with the origin server, using the
322       request-headers from the new request to allow the origin server
323       to authenticate the new request.
324
325   3.  If the response includes the "public" cache-control directive, it
326       MAY be returned in reply to any subsequent request.
327
328
329
330
331
332
333
334
335Fielding, et al.       Expires September 10, 2009               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7                  March 2009
338
339
3403.2.  Proxy-Authenticate
341
342   The response-header field "Proxy-Authenticate" MUST be included as
343   part of a 407 (Proxy Authentication Required) response.  The field
344   value consists of a challenge that indicates the authentication
345   scheme and parameters applicable to the proxy for this request-
346   target.
347
348     Proxy-Authenticate   = "Proxy-Authenticate" ":" OWS
349                            Proxy-Authenticate-v
350     Proxy-Authenticate-v = 1#challenge
351
352   The HTTP access authentication process is described in "HTTP
353   Authentication: Basic and Digest Access Authentication" [RFC2617].
354   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
355   only to the current connection and SHOULD NOT be passed on to
356   downstream clients.  However, an intermediate proxy might need to
357   obtain its own credentials by requesting them from the downstream
358   client, which in some circumstances will appear as if the proxy is
359   forwarding the Proxy-Authenticate header field.
360
3613.3.  Proxy-Authorization
362
363   The request-header field "Proxy-Authorization" allows the client to
364   identify itself (or its user) to a proxy which requires
365   authentication.  The Proxy-Authorization field value consists of
366   credentials containing the authentication information of the user
367   agent for the proxy and/or realm of the resource being requested.
368
369     Proxy-Authorization   = "Proxy-Authorization" ":" OWS
370                             Proxy-Authorization-v
371     Proxy-Authorization-v = credentials
372
373   The HTTP access authentication process is described in "HTTP
374   Authentication: Basic and Digest Access Authentication" [RFC2617].
375   Unlike Authorization, the Proxy-Authorization header field applies
376   only to the next outbound proxy that demanded authentication using
377   the Proxy-Authenticate field.  When multiple proxies are used in a
378   chain, the Proxy-Authorization header field is consumed by the first
379   outbound proxy that was expecting to receive credentials.  A proxy
380   MAY relay the credentials from the client request to the next proxy
381   if that is the mechanism by which the proxies cooperatively
382   authenticate a given request.
383
3843.4.  WWW-Authenticate
385
386   The WWW-Authenticate response-header field MUST be included in 401
387   (Unauthorized) response messages.  The field value consists of at
388
389
390
391Fielding, et al.       Expires September 10, 2009               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7                  March 2009
394
395
396   least one challenge that indicates the authentication scheme(s) and
397   parameters applicable to the request-target.
398
399     WWW-Authenticate   = "WWW-Authenticate" ":" OWS WWW-Authenticate-v
400     WWW-Authenticate-v = 1#challenge
401
402   The HTTP access authentication process is described in "HTTP
403   Authentication: Basic and Digest Access Authentication" [RFC2617].
404   User agents are advised to take special care in parsing the WWW-
405   Authenticate field value as it might contain more than one challenge,
406   or if more than one WWW-Authenticate header field is provided, the
407   contents of a challenge itself can contain a comma-separated list of
408   authentication parameters.
409
410
4114.  IANA Considerations
412
4134.1.  Message Header Registration
414
415   The Message Header Registry located at <http://www.iana.org/
416   assignments/message-headers/message-header-index.html> should be
417   updated with the permanent registrations below (see [RFC3864]):
418
419   +---------------------+----------+----------+-------------+
420   | Header Field Name   | Protocol | Status   | Reference   |
421   +---------------------+----------+----------+-------------+
422   | Authorization       | http     | standard | Section 3.1 |
423   | Proxy-Authenticate  | http     | standard | Section 3.2 |
424   | Proxy-Authorization | http     | standard | Section 3.3 |
425   | WWW-Authenticate    | http     | standard | Section 3.4 |
426   +---------------------+----------+----------+-------------+
427
428   The change controller is: "IETF (iesg@ietf.org) - Internet
429   Engineering Task Force".
430
431
4325.  Security Considerations
433
434   This section is meant to inform application developers, information
435   providers, and users of the security limitations in HTTP/1.1 as
436   described by this document.  The discussion does not include
437   definitive solutions to the problems revealed, though it does make
438   some suggestions for reducing security risks.
439
4405.1.  Authentication Credentials and Idle Clients
441
442   Existing HTTP clients and user agents typically retain authentication
443   information indefinitely.  HTTP/1.1 does not provide a method for a
444
445
446
447Fielding, et al.       Expires September 10, 2009               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7                  March 2009
450
451
452   server to direct clients to discard these cached credentials.  This
453   is a significant defect that requires further extensions to HTTP.
454   Circumstances under which credential caching can interfere with the
455   application's security model include but are not limited to:
456
457   o  Clients which have been idle for an extended period following
458      which the server might wish to cause the client to reprompt the
459      user for credentials.
460
461   o  Applications which include a session termination indication (such
462      as a `logout' or `commit' button on a page) after which the server
463      side of the application `knows' that there is no further reason
464      for the client to retain the credentials.
465
466   This is currently under separate study.  There are a number of work-
467   arounds to parts of this problem, and we encourage the use of
468   password protection in screen savers, idle time-outs, and other
469   methods which mitigate the security problems inherent in this
470   problem.  In particular, user agents which cache credentials are
471   encouraged to provide a readily accessible mechanism for discarding
472   cached credentials under user control.
473
474
4756.  Acknowledgments
476
477   [[anchor2: TBD.]]
478
479
4807.  References
481
4827.1.  Normative References
483
484   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
485              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
486              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
487              and Message Parsing", draft-ietf-httpbis-p1-messaging-06
488              (work in progress), March 2009.
489
490   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
491              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
492              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
493              draft-ietf-httpbis-p6-cache-06 (work in progress),
494              March 2009.
495
496   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
497              Requirement Levels", BCP 14, RFC 2119, March 1997.
498
499   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
500
501
502
503Fielding, et al.       Expires September 10, 2009               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7                  March 2009
506
507
508              Leach, P., Luotonen, A., and L. Stewart, "HTTP
509              Authentication: Basic and Digest Access Authentication",
510              RFC 2617, June 1999.
511
512   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
513              Specifications: ABNF", STD 68, RFC 5234, January 2008.
514
5157.2.  Informative References
516
517   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
518              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
519              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
520
521   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
522              Procedures for Message Header Fields", BCP 90, RFC 3864,
523              September 2004.
524
525
526Appendix A.  Compatibility with Previous Versions
527
528A.1.  Changes from RFC 2616
529
530
531Appendix B.  Collected ABNF
532
533   Authorization = "Authorization:" OWS Authorization-v
534   Authorization-v = credentials
535
536   OWS = <OWS, defined in [Part1], Section 1.2.2>
537
538   Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v
539   Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
540    challenge ] )
541   Proxy-Authorization = "Proxy-Authorization:" OWS
542    Proxy-Authorization-v
543   Proxy-Authorization-v = credentials
544
545   WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v
546   WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
547    challenge ] )
548
549   challenge = <challenge, defined in [RFC2617], Section 1.2>
550   credentials = <credentials, defined in [RFC2617], Section 1.2>
551
552
553
554
555
556
557
558
559Fielding, et al.       Expires September 10, 2009              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7                  March 2009
562
563
564   ABNF diagnostics:
565
566   ; Authorization defined but not used
567   ; Proxy-Authenticate defined but not used
568   ; Proxy-Authorization defined but not used
569   ; WWW-Authenticate defined but not used
570
571
572Appendix C.  Change Log (to be removed by RFC Editor before publication)
573
574C.1.  Since RFC2616
575
576   Extracted relevant partitions from [RFC2616].
577
578C.2.  Since draft-ietf-httpbis-p7-auth-00
579
580   Closed issues:
581
582   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
583      Informative references"
584
585C.3.  Since draft-ietf-httpbis-p7-auth-01
586
587   Ongoing work on ABNF conversion
588   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
589
590   o  Explicitly import BNF rules for "challenge" and "credentials" from
591      RFC2617.
592
593   o  Add explicit references to BNF syntax and rules imported from
594      other parts of the specification.
595
596C.4.  Since draft-ietf-httpbis-p7-auth-02
597
598   Ongoing work on IANA Message Header Registration
599   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
600
601   o  Reference RFC 3984, and update header registrations for headers
602      defined in this document.
603
604C.5.  Since draft-ietf-httpbis-p7-auth-03
605
606C.6.  Since draft-ietf-httpbis-p7-auth-04
607
608   Ongoing work on ABNF conversion
609   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
610
611
612
613
614
615Fielding, et al.       Expires September 10, 2009              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7                  March 2009
618
619
620   o  Use "/" instead of "|" for alternatives.
621
622   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
623      whitespace ("OWS") and required whitespace ("RWS").
624
625   o  Rewrite ABNFs to spell out whitespace rules, factor out header
626      value format definitions.
627
628C.7.  Since draft-ietf-httpbis-p7-auth-05
629
630   Final work on ABNF conversion
631   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
632
633   o  Add appendix containing collected and expanded ABNF, reorganize
634      ABNF introduction.
635
636
637Index
638
639   4
640      401 Unauthorized (status code)  5
641      407 Proxy Authentication Required (status code)  5
642
643   A
644      Authorization header  6
645
646   G
647      Grammar
648         Authorization  6
649         Authorization-v  6
650         challenge  5
651         credentials  5
652         Proxy-Authenticate  7
653         Proxy-Authenticate-v  7
654         Proxy-Authorization  7
655         Proxy-Authorization-v  7
656         WWW-Authenticate  8
657         WWW-Authenticate-v  8
658
659   H
660      Headers
661         Authorization  6
662         Proxy-Authenticate  7
663         Proxy-Authorization  7
664         WWW-Authenticate  7
665
666   P
667      Proxy-Authenticate header  7
668
669
670
671Fielding, et al.       Expires September 10, 2009              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7                  March 2009
674
675
676      Proxy-Authorization header  7
677
678   S
679      Status Codes
680         401 Unauthorized  5
681         407 Proxy Authentication Required  5
682
683   W
684      WWW-Authenticate header  7
685
686
687Authors' Addresses
688
689   Roy T. Fielding (editor)
690   Day Software
691   23 Corporate Plaza DR, Suite 280
692   Newport Beach, CA  92660
693   USA
694
695   Phone: +1-949-706-5300
696   Fax:   +1-949-706-5305
697   Email: fielding@gbiv.com
698   URI:   http://roy.gbiv.com/
699
700
701   Jim Gettys
702   One Laptop per Child
703   21 Oak Knoll Road
704   Carlisle, MA  01741
705   USA
706
707   Email: jg@laptop.org
708   URI:   http://www.laptop.org/
709
710
711   Jeffrey C. Mogul
712   Hewlett-Packard Company
713   HP Labs, Large Scale Systems Group
714   1501 Page Mill Road, MS 1177
715   Palo Alto, CA  94304
716   USA
717
718   Email: JeffMogul@acm.org
719
720
721
722
723
724
725
726
727Fielding, et al.       Expires September 10, 2009              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 7                  March 2009
730
731
732   Henrik Frystyk Nielsen
733   Microsoft Corporation
734   1 Microsoft Way
735   Redmond, WA  98052
736   USA
737
738   Email: henrikn@microsoft.com
739
740
741   Larry Masinter
742   Adobe Systems, Incorporated
743   345 Park Ave
744   San Jose, CA  95110
745   USA
746
747   Email: LMM@acm.org
748   URI:   http://larry.masinter.net/
749
750
751   Paul J. Leach
752   Microsoft Corporation
753   1 Microsoft Way
754   Redmond, WA  98052
755
756   Email: paulle@microsoft.com
757
758
759   Tim Berners-Lee
760   World Wide Web Consortium
761   MIT Computer Science and Artificial Intelligence Laboratory
762   The Stata Center, Building 32
763   32 Vassar Street
764   Cambridge, MA  02139
765   USA
766
767   Email: timbl@w3.org
768   URI:   http://www.w3.org/People/Berners-Lee/
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783Fielding, et al.       Expires September 10, 2009              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 7                  March 2009
786
787
788   Yves Lafon (editor)
789   World Wide Web Consortium
790   W3C / ERCIM
791   2004, rte des Lucioles
792   Sophia-Antipolis, AM  06902
793   France
794
795   Email: ylafon@w3.org
796   URI:   http://www.raubacapeu.net/people/yves/
797
798
799   Julian F. Reschke (editor)
800   greenbytes GmbH
801   Hafenweg 16
802   Muenster, NW  48155
803   Germany
804
805   Phone: +49 251 2807760
806   Fax:   +49 251 2807761
807   Email: julian.reschke@greenbytes.de
808   URI:   http://greenbytes.de/tech/webdav/
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839Fielding, et al.       Expires September 10, 2009              [Page 15]
840
Note: See TracBrowser for help on using the repository browser.