source: draft-ietf-httpbis/13/draft-ietf-httpbis-p7-auth-13.txt @ 1450

Last change on this file since 1450 was 1180, checked in by julian.reschke@…, 9 years ago

prepare publication of -13

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 35.7 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                                     Adobe
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Updates: 2617 (if approved)                               Alcatel-Lucent
8Intended status: Standards Track                                J. Mogul
9Expires: September 15, 2011                                           HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                                   Adobe
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 14, 2011
23
24
25                    HTTP/1.1, part 7: Authentication
26                     draft-ietf-httpbis-p7-auth-13
27
28Abstract
29
30   The Hypertext Transfer Protocol (HTTP) is an application-level
31   protocol for distributed, collaborative, hypermedia information
32   systems.  HTTP has been in use by the World Wide Web global
33   information initiative since 1990.  This document is Part 7 of the
34   seven-part specification that defines the protocol referred to as
35   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 7 defines
36   HTTP Authentication.
37
38Editorial Note (To be removed by RFC Editor)
39
40   Discussion of this draft should take place on the HTTPBIS working
41   group mailing list (ietf-http-wg@w3.org).  The current issues list is
42   at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
43   documents (including fancy diffs) can be found at
44   <http://tools.ietf.org/wg/httpbis/>.
45
46   The changes in this draft are summarized in Appendix B.14.
47
48Status of This Memo
49
50   This Internet-Draft is submitted in full conformance with the
51   provisions of BCP 78 and BCP 79.
52
53
54
55Fielding, et al.       Expires September 15, 2011               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7                  March 2011
58
59
60   Internet-Drafts are working documents of the Internet Engineering
61   Task Force (IETF).  Note that other groups may also distribute
62   working documents as Internet-Drafts.  The list of current Internet-
63   Drafts is at http://datatracker.ietf.org/drafts/current/.
64
65   Internet-Drafts are draft documents valid for a maximum of six months
66   and may be updated, replaced, or obsoleted by other documents at any
67   time.  It is inappropriate to use Internet-Drafts as reference
68   material or to cite them other than as "work in progress."
69
70   This Internet-Draft will expire on September 15, 2011.
71
72Copyright Notice
73
74   Copyright (c) 2011 IETF Trust and the persons identified as the
75   document authors.  All rights reserved.
76
77   This document is subject to BCP 78 and the IETF Trust's Legal
78   Provisions Relating to IETF Documents
79   (http://trustee.ietf.org/license-info) in effect on the date of
80   publication of this document.  Please review these documents
81   carefully, as they describe your rights and restrictions with respect
82   to this document.  Code Components extracted from this document must
83   include Simplified BSD License text as described in Section 4.e of
84   the Trust Legal Provisions and are provided without warranty as
85   described in the Simplified BSD License.
86
87   This document may contain material from IETF Documents or IETF
88   Contributions published or made publicly available before November
89   10, 2008.  The person(s) controlling the copyright in some of this
90   material may not have granted the IETF Trust the right to allow
91   modifications of such material outside the IETF Standards Process.
92   Without obtaining an adequate license from the person(s) controlling
93   the copyright in such materials, this document may not be modified
94   outside the IETF Standards Process, and derivative works of it may
95   not be created outside the IETF Standards Process, except to format
96   it for publication as an RFC or to translate it into languages other
97   than English.
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.       Expires September 15, 2011               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7                  March 2011
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 . . . . . . . . . . . . . . . . . . . . . .  4
122   2.  Access Authentication Framework  . . . . . . . . . . . . . . .  5
123     2.1.  Authentication Scheme Registry . . . . . . . . . . . . . .  7
124   3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  7
125     3.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  7
126     3.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  7
127   4.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  8
128     4.1.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  8
129     4.2.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  9
130     4.3.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  9
131     4.4.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  9
132   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
133     5.1.  Authenticaton Scheme Registry  . . . . . . . . . . . . . . 10
134     5.2.  Status Code Registration . . . . . . . . . . . . . . . . . 10
135     5.3.  Header Field Registration  . . . . . . . . . . . . . . . . 10
136   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
137     6.1.  Authentication Credentials and Idle Clients  . . . . . . . 11
138   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
139   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
140     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
141     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
142   Appendix A.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 13
143   Appendix B.  Change Log (to be removed by RFC Editor before
144                publication)  . . . . . . . . . . . . . . . . . . . . 13
145     B.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 13
146     B.2.  Since draft-ietf-httpbis-p7-auth-00  . . . . . . . . . . . 14
147     B.3.  Since draft-ietf-httpbis-p7-auth-01  . . . . . . . . . . . 14
148     B.4.  Since draft-ietf-httpbis-p7-auth-02  . . . . . . . . . . . 14
149     B.5.  Since draft-ietf-httpbis-p7-auth-03  . . . . . . . . . . . 14
150     B.6.  Since draft-ietf-httpbis-p7-auth-04  . . . . . . . . . . . 14
151     B.7.  Since draft-ietf-httpbis-p7-auth-05  . . . . . . . . . . . 14
152     B.8.  Since draft-ietf-httpbis-p7-auth-06  . . . . . . . . . . . 15
153     B.9.  Since draft-ietf-httpbis-p7-auth-07  . . . . . . . . . . . 15
154     B.10. Since draft-ietf-httpbis-p7-auth-08  . . . . . . . . . . . 15
155     B.11. Since draft-ietf-httpbis-p7-auth-09  . . . . . . . . . . . 15
156     B.12. Since draft-ietf-httpbis-p7-auth-10  . . . . . . . . . . . 15
157     B.13. Since draft-ietf-httpbis-p7-auth-11  . . . . . . . . . . . 15
158     B.14. Since draft-ietf-httpbis-p7-auth-12  . . . . . . . . . . . 16
159   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
160
161
162
163
164
165
166
167Fielding, et al.       Expires September 15, 2011               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7                  March 2011
170
171
1721.  Introduction
173
174   This document defines HTTP/1.1 access control and authentication.  It
175   includes the relevant parts of RFC 2616 with only minor changes, plus
176   the general framework for HTTP authentication, as previously defined
177   in "HTTP Authentication: Basic and Digest Access Authentication"
178   ([RFC2617]).
179
180   HTTP provides several OPTIONAL challenge-response authentication
181   mechanisms which can be used by a server to challenge a client
182   request and by a client to provide authentication information.  The
183   "basic" and "digest" authentication schemes continue to be specified
184   in RFC 2617.
185
1861.1.  Requirements
187
188   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
189   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
190   document are to be interpreted as described in [RFC2119].
191
192   An implementation is not compliant if it fails to satisfy one or more
193   of the "MUST" or "REQUIRED" level requirements for the protocols it
194   implements.  An implementation that satisfies all the "MUST" or
195   "REQUIRED" level and all the "SHOULD" level requirements for its
196   protocols is said to be "unconditionally compliant"; one that
197   satisfies all the "MUST" level requirements but not all the "SHOULD"
198   level requirements for its protocols is said to be "conditionally
199   compliant".
200
2011.2.  Syntax Notation
202
203   This specification uses the ABNF syntax defined in Section 1.2 of
204   [Part1] (which extends the syntax defined in [RFC5234] with a list
205   rule).  Appendix A shows the collected ABNF, with the list rule
206   expanded.
207
208   The following core rules are included by reference, as defined in
209   [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
210   (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
211   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
212   sequence of data), SP (space), VCHAR (any visible USASCII character),
213   and WSP (whitespace).
214
2151.2.1.  Core Rules
216
217   The core rules below are defined in Section 1.2.2 of [Part1]:
218
219
220
221
222
223Fielding, et al.       Expires September 15, 2011               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7                  March 2011
226
227
228     quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
229     token         = <token, defined in [Part1], Section 1.2.2>
230     OWS           = <OWS, defined in [Part1], Section 1.2.2>
231
2322.  Access Authentication Framework
233
234   HTTP provides a simple challenge-response authentication mechanism
235   that can be used by a server to challenge a client request and by a
236   client to provide authentication information.  It uses an extensible,
237   case-insensitive token to identify the authentication scheme,
238   followed by a comma-separated list of attribute-value pairs which
239   carry the parameters necessary for achieving authentication via that
240   scheme.
241
242     auth-scheme    = token
243     auth-param     = token "=" ( token / quoted-string )
244
245   The 401 (Unauthorized) response message is used by an origin server
246   to challenge the authorization of a user agent.  This response MUST
247   include a WWW-Authenticate header field containing at least one
248   challenge applicable to the requested resource.  The 407 (Proxy
249   Authentication Required) response message is used by a proxy to
250   challenge the authorization of a client and MUST include a Proxy-
251   Authenticate header field containing at least one challenge
252   applicable to the proxy for the requested resource.
253
254     challenge   = auth-scheme 1*SP 1#auth-param
255
256      Note: User agents will need to take special care in parsing the
257      WWW-Authenticate or Proxy-Authenticate header field value if it
258      contains more than one challenge, or if more than one WWW-
259      Authenticate header field is provided, since the contents of a
260      challenge can itself contain a comma-separated list of
261      authentication parameters.
262
263      Note: Many browsers fail to parse challenges containing unknown
264      schemes.  A workaround for this problem is to list well-supported
265      schemes (such as "basic") first.
266
267   The authentication parameter realm is defined for all authentication
268   schemes:
269
270     realm       = "realm" "=" realm-value
271     realm-value = quoted-string
272
273   The realm directive (case-insensitive) is required for all
274   authentication schemes that issue a challenge.  The realm value
275   (case-sensitive), in combination with the canonical root URI (the
276
277
278
279Fielding, et al.       Expires September 15, 2011               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7                  March 2011
282
283
284   scheme and authority components of the effective request URI; see
285   Section 4.3 of [Part1]) of the server being accessed, defines the
286   protection space.  These realms allow the protected resources on a
287   server to be partitioned into a set of protection spaces, each with
288   its own authentication scheme and/or authorization database.  The
289   realm value is a string, generally assigned by the origin server,
290   which can have additional semantics specific to the authentication
291   scheme.  Note that there can be multiple challenges with the same
292   auth-scheme but different realms.
293
294   A user agent that wishes to authenticate itself with an origin server
295   -- usually, but not necessarily, after receiving a 401 (Unauthorized)
296   -- MAY do so by including an Authorization header field with the
297   request.  A client that wishes to authenticate itself with a proxy --
298   usually, but not necessarily, after receiving a 407 (Proxy
299   Authentication Required) -- MAY do so by including a Proxy-
300   Authorization header field with the request.  Both the Authorization
301   field value and the Proxy-Authorization field value consist of
302   credentials containing the authentication information of the client
303   for the realm of the resource being requested.  The user agent MUST
304   choose to use one of the challenges with the strongest auth-scheme it
305   understands and request credentials from the user based upon that
306   challenge.
307
308     credentials = auth-scheme ( token
309                               / quoted-string
310                               / #auth-param )
311
312   The protection space determines the domain over which credentials can
313   be automatically applied.  If a prior request has been authorized,
314   the same credentials MAY be reused for all other requests within that
315   protection space for a period of time determined by the
316   authentication scheme, parameters, and/or user preference.  Unless
317   otherwise defined by the authentication scheme, a single protection
318   space cannot extend outside the scope of its server.
319
320   If the origin server does not wish to accept the credentials sent
321   with a request, it SHOULD return a 401 (Unauthorized) response.  The
322   response MUST include a WWW-Authenticate header field containing at
323   least one (possibly new) challenge applicable to the requested
324   resource.  If a proxy does not accept the credentials sent with a
325   request, it SHOULD return a 407 (Proxy Authentication Required).  The
326   response MUST include a Proxy-Authenticate header field containing a
327   (possibly new) challenge applicable to the proxy for the requested
328   resource.
329
330   The HTTP protocol does not restrict applications to this simple
331   challenge-response mechanism for access authentication.  Additional
332
333
334
335Fielding, et al.       Expires September 15, 2011               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7                  March 2011
338
339
340   mechanisms MAY be used, such as encryption at the transport level or
341   via message encapsulation, and with additional header fields
342   specifying authentication information.  However, such additional
343   mechanisms are not defined by this specification.
344
345   Proxies MUST forward the WWW-Authenticate and Authorization headers
346   unmodified and follow the rules found in Section 4.1.
347
3482.1.  Authentication Scheme Registry
349
350   The HTTP Authentication Scheme Registry defines the name space for
351   the authentication schemes in challenges and credentials.
352
353   Registrations MUST include the following fields:
354
355   o  Authentication Scheme Name
356
357   o  Pointer to specification text
358
359   Values to be added to this name space are subject to IETF review
360   ([RFC5226], Section 4.1).
361
362   The registry itself is maintained at
363   <http://www.iana.org/assignments/http-authschemes>.
364
3653.  Status Code Definitions
366
3673.1.  401 Unauthorized
368
369   The request requires user authentication.  The response MUST include
370   a WWW-Authenticate header field (Section 4.4) containing a challenge
371   applicable to the target resource.  The client MAY repeat the request
372   with a suitable Authorization header field (Section 4.1).  If the
373   request already included Authorization credentials, then the 401
374   response indicates that authorization has been refused for those
375   credentials.  If the 401 response contains the same challenge as the
376   prior response, and the user agent has already attempted
377   authentication at least once, then the user SHOULD be presented the
378   representation that was given in the response, since that
379   representation might include relevant diagnostic information.
380
3813.2.  407 Proxy Authentication Required
382
383   This code is similar to 401 (Unauthorized), but indicates that the
384   client ought to first authenticate itself with the proxy.  The proxy
385   MUST return a Proxy-Authenticate header field (Section 4.2)
386   containing a challenge applicable to the proxy for the target
387   resource.  The client MAY repeat the request with a suitable Proxy-
388
389
390
391Fielding, et al.       Expires September 15, 2011               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7                  March 2011
394
395
396   Authorization header field (Section 4.3).
397
3984.  Header Field Definitions
399
400   This section defines the syntax and semantics of HTTP/1.1 header
401   fields related to authentication.
402
4034.1.  Authorization
404
405   The "Authorization" header field allows a user agent to authenticate
406   itself with a server -- usually, but not necessarily, after receiving
407   a 401 (Unauthorized) response.  Its value consists of credentials
408   containing information of the user agent for the realm of the
409   resource being requested.
410
411     Authorization   = "Authorization" ":" OWS Authorization-v
412     Authorization-v = credentials
413
414   If a request is authenticated and a realm specified, the same
415   credentials SHOULD be valid for all other requests within this realm
416   (assuming that the authentication scheme itself does not require
417   otherwise, such as credentials that vary according to a challenge
418   value or using synchronized clocks).
419
420   When a shared cache (see Section 1.2 of [Part6]) receives a request
421   containing an Authorization field, it MUST NOT return the
422   corresponding response as a reply to any other request, unless one of
423   the following specific exceptions holds:
424
425   1.  If the response includes the "s-maxage" cache-control directive,
426       the cache MAY use that response in replying to a subsequent
427       request.  But (if the specified maximum age has passed) a proxy
428       cache MUST first revalidate it with the origin server, using the
429       header fields from the new request to allow the origin server to
430       authenticate the new request.  (This is the defined behavior for
431       s-maxage.)  If the response includes "s-maxage=0", the proxy MUST
432       always revalidate it before re-using it.
433
434   2.  If the response includes the "must-revalidate" cache-control
435       directive, the cache MAY use that response in replying to a
436       subsequent request.  But if the response is stale, all caches
437       MUST first revalidate it with the origin server, using the header
438       fields from the new request to allow the origin server to
439       authenticate the new request.
440
441   3.  If the response includes the "public" cache-control directive, it
442       MAY be returned in reply to any subsequent request.
443
444
445
446
447Fielding, et al.       Expires September 15, 2011               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7                  March 2011
450
451
4524.2.  Proxy-Authenticate
453
454   The "Proxy-Authenticate" header field consists of a challenge that
455   indicates the authentication scheme and parameters applicable to the
456   proxy for this effective request URI (Section 4.3 of [Part1]).  It
457   MUST be included as part of a 407 (Proxy Authentication Required)
458   response.
459
460     Proxy-Authenticate   = "Proxy-Authenticate" ":" OWS
461                            Proxy-Authenticate-v
462     Proxy-Authenticate-v = 1#challenge
463
464   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
465   only to the current connection and SHOULD NOT be passed on to
466   downstream clients.  However, an intermediate proxy might need to
467   obtain its own credentials by requesting them from the downstream
468   client, which in some circumstances will appear as if the proxy is
469   forwarding the Proxy-Authenticate header field.
470
4714.3.  Proxy-Authorization
472
473   The "Proxy-Authorization" header field allows the client to identify
474   itself (or its user) to a proxy which requires authentication.  Its
475   value consists of credentials containing the authentication
476   information of the user agent for the proxy and/or realm of the
477   resource being requested.
478
479     Proxy-Authorization   = "Proxy-Authorization" ":" OWS
480                             Proxy-Authorization-v
481     Proxy-Authorization-v = credentials
482
483   Unlike Authorization, the Proxy-Authorization header field applies
484   only to the next outbound proxy that demanded authentication using
485   the Proxy-Authenticate field.  When multiple proxies are used in a
486   chain, the Proxy-Authorization header field is consumed by the first
487   outbound proxy that was expecting to receive credentials.  A proxy
488   MAY relay the credentials from the client request to the next proxy
489   if that is the mechanism by which the proxies cooperatively
490   authenticate a given request.
491
4924.4.  WWW-Authenticate
493
494   The "WWW-Authenticate" header field consists of at least one
495   challenge that indicates the authentication scheme(s) and parameters
496   applicable to the effective request URI (Section 4.3 of [Part1]).  It
497   MUST be included in 401 (Unauthorized) response messages.
498
499     WWW-Authenticate   = "WWW-Authenticate" ":" OWS WWW-Authenticate-v
500
501
502
503Fielding, et al.       Expires September 15, 2011               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7                  March 2011
506
507
508     WWW-Authenticate-v = 1#challenge
509
510   User agents are advised to take special care in parsing the WWW-
511   Authenticate field value as it might contain more than one challenge,
512   or if more than one WWW-Authenticate header field is provided, the
513   contents of a challenge itself can contain a comma-separated list of
514   authentication parameters.
515
5165.  IANA Considerations
517
5185.1.  Authenticaton Scheme Registry
519
520   The registration procedure for HTTP Authentication Schemes is defined
521   by Section 2.1 of this document.
522
523   The HTTP Method Authentication Scheme shall be created at
524   <http://www.iana.org/assignments/http-authschemes>.
525
5265.2.  Status Code Registration
527
528   The HTTP Status Code Registry located at
529   <http://www.iana.org/assignments/http-status-codes> shall be updated
530   with the registrations below:
531
532   +-------+-------------------------------+-------------+
533   | Value | Description                   | Reference   |
534   +-------+-------------------------------+-------------+
535   | 401   | Unauthorized                  | Section 3.1 |
536   | 407   | Proxy Authentication Required | Section 3.2 |
537   +-------+-------------------------------+-------------+
538
5395.3.  Header Field Registration
540
541   The Message Header Field Registry located at <http://www.iana.org/
542   assignments/message-headers/message-header-index.html> shall be
543   updated with the permanent registrations below (see [RFC3864]):
544
545   +---------------------+----------+----------+-------------+
546   | Header Field Name   | Protocol | Status   | Reference   |
547   +---------------------+----------+----------+-------------+
548   | Authorization       | http     | standard | Section 4.1 |
549   | Proxy-Authenticate  | http     | standard | Section 4.2 |
550   | Proxy-Authorization | http     | standard | Section 4.3 |
551   | WWW-Authenticate    | http     | standard | Section 4.4 |
552   +---------------------+----------+----------+-------------+
553
554   The change controller is: "IETF (iesg@ietf.org) - Internet
555   Engineering Task Force".
556
557
558
559Fielding, et al.       Expires September 15, 2011              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7                  March 2011
562
563
5646.  Security Considerations
565
566   This section is meant to inform application developers, information
567   providers, and users of the security limitations in HTTP/1.1 as
568   described by this document.  The discussion does not include
569   definitive solutions to the problems revealed, though it does make
570   some suggestions for reducing security risks.
571
5726.1.  Authentication Credentials and Idle Clients
573
574   Existing HTTP clients and user agents typically retain authentication
575   information indefinitely.  HTTP/1.1 does not provide a method for a
576   server to direct clients to discard these cached credentials.  This
577   is a significant defect that requires further extensions to HTTP.
578   Circumstances under which credential caching can interfere with the
579   application's security model include but are not limited to:
580
581   o  Clients which have been idle for an extended period following
582      which the server might wish to cause the client to reprompt the
583      user for credentials.
584
585   o  Applications which include a session termination indication (such
586      as a "logout" or "commit" button on a page) after which the server
587      side of the application "knows" that there is no further reason
588      for the client to retain the credentials.
589
590   This is currently under separate study.  There are a number of work-
591   arounds to parts of this problem, and we encourage the use of
592   password protection in screen savers, idle time-outs, and other
593   methods which mitigate the security problems inherent in this
594   problem.  In particular, user agents which cache credentials are
595   encouraged to provide a readily accessible mechanism for discarding
596   cached credentials under user control.
597
5987.  Acknowledgments
599
600   This specification takes over the definition of the HTTP
601   Authentication Framework, previously defined in RFC 2617.  We thank
602   to John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott
603   D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for
604   their work on that specification.
605
606   [[acks: HTTPbis acknowledgements.]]
607
6088.  References
609
610
611
612
613
614
615Fielding, et al.       Expires September 15, 2011              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7                  March 2011
618
619
6208.1.  Normative References
621
622   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
623              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
624              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
625              and Message Parsing", draft-ietf-httpbis-p1-messaging-13
626              (work in progress), March 2011.
627
628   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
629              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
630              Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
631              6: Caching", draft-ietf-httpbis-p6-cache-13 (work in
632              progress), March 2011.
633
634   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
635              Requirement Levels", BCP 14, RFC 2119, March 1997.
636
637   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
638              Specifications: ABNF", STD 68, RFC 5234, January 2008.
639
6408.2.  Informative References
641
642   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
643              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
644              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
645
646   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
647              Leach, P., Luotonen, A., and L. Stewart, "HTTP
648              Authentication: Basic and Digest Access Authentication",
649              RFC 2617, June 1999.
650
651   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
652              Procedures for Message Header Fields", BCP 90, RFC 3864,
653              September 2004.
654
655   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
656              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
657              May 2008.
658
659
660
661
662
663
664
665
666
667
668
669
670
671Fielding, et al.       Expires September 15, 2011              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7                  March 2011
674
675
676Appendix A.  Collected ABNF
677
678   Authorization = "Authorization:" OWS Authorization-v
679   Authorization-v = credentials
680
681   OWS = <OWS, defined in [Part1], Section 1.2.2>
682
683   Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v
684   Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
685    challenge ] )
686   Proxy-Authorization = "Proxy-Authorization:" OWS
687    Proxy-Authorization-v
688   Proxy-Authorization-v = credentials
689
690   WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v
691   WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
692    challenge ] )
693
694   auth-param = token "=" ( token / quoted-string )
695   auth-scheme = token
696
697   challenge = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS
698    auth-param ] )
699   credentials = auth-scheme ( token / quoted-string / [ ( "," /
700    auth-param ) *( OWS "," [ OWS auth-param ] ) ] )
701
702   quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
703
704   realm = "realm=" realm-value
705   realm-value = quoted-string
706
707   token = <token, defined in [Part1], Section 1.2.2>
708
709   ABNF diagnostics:
710
711   ; Authorization defined but not used
712   ; Proxy-Authenticate defined but not used
713   ; Proxy-Authorization defined but not used
714   ; WWW-Authenticate defined but not used
715   ; realm defined but not used
716
717Appendix B.  Change Log (to be removed by RFC Editor before publication)
718
719B.1.  Since RFC 2616
720
721   Extracted relevant partitions from [RFC2616].
722
723
724
725
726
727Fielding, et al.       Expires September 15, 2011              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 7                  March 2011
730
731
732B.2.  Since draft-ietf-httpbis-p7-auth-00
733
734   Closed issues:
735
736   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
737      Informative references"
738
739B.3.  Since draft-ietf-httpbis-p7-auth-01
740
741   Ongoing work on ABNF conversion
742   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
743
744   o  Explicitly import BNF rules for "challenge" and "credentials" from
745      RFC2617.
746
747   o  Add explicit references to BNF syntax and rules imported from
748      other parts of the specification.
749
750B.4.  Since draft-ietf-httpbis-p7-auth-02
751
752   Ongoing work on IANA Message Header Field Registration
753   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
754
755   o  Reference RFC 3984, and update header field registrations for
756      header fields defined in this document.
757
758B.5.  Since draft-ietf-httpbis-p7-auth-03
759
760B.6.  Since draft-ietf-httpbis-p7-auth-04
761
762   Ongoing work on ABNF conversion
763   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
764
765   o  Use "/" instead of "|" for alternatives.
766
767   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
768      whitespace ("OWS") and required whitespace ("RWS").
769
770   o  Rewrite ABNFs to spell out whitespace rules, factor out header
771      field value format definitions.
772
773B.7.  Since draft-ietf-httpbis-p7-auth-05
774
775   Final work on ABNF conversion
776   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
777
778   o  Add appendix containing collected and expanded ABNF, reorganize
779      ABNF introduction.
780
781
782
783Fielding, et al.       Expires September 15, 2011              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 7                  March 2011
786
787
788B.8.  Since draft-ietf-httpbis-p7-auth-06
789
790   None.
791
792B.9.  Since draft-ietf-httpbis-p7-auth-07
793
794   Closed issues:
795
796   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
797      registrations for optional status codes"
798
799B.10.  Since draft-ietf-httpbis-p7-auth-08
800
801   No significant changes.
802
803B.11.  Since draft-ietf-httpbis-p7-auth-09
804
805   Partly resolved issues:
806
807   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
808      requested resource's URI"
809
810B.12.  Since draft-ietf-httpbis-p7-auth-10
811
812   None yet.
813
814B.13.  Since draft-ietf-httpbis-p7-auth-11
815
816   Closed issues:
817
818   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/130>: "introduction
819      to part 7 is work-in-progress"
820
821   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/195>: "auth-param
822      syntax"
823
824   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
825      Classification"
826
827   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/237>: "absorbing the
828      auth framework from 2617"
829
830   Partly resolved issues:
831
832   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/141>: "should we
833      have an auth scheme registry"
834
835
836
837
838
839Fielding, et al.       Expires September 15, 2011              [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 7                  March 2011
842
843
844B.14.  Since draft-ietf-httpbis-p7-auth-12
845
846   None.
847
848Index
849
850   4
851      401 Unauthorized (status code)  7
852      407 Proxy Authentication Required (status code)  7
853
854   A
855      auth-param  5
856      auth-scheme  5
857      Authorization header field  8
858
859   C
860      challenge  5
861      credentials  6
862
863   G
864      Grammar
865         Authorization  8
866         Authorization-v  8
867         Proxy-Authenticate  9
868         Proxy-Authenticate-v  9
869         Proxy-Authorization  9
870         Proxy-Authorization-v  9
871         WWW-Authenticate  9
872         WWW-Authenticate-v  9
873
874   H
875      Header Fields
876         Authorization  8
877         Proxy-Authenticate  9
878         Proxy-Authorization  9
879         WWW-Authenticate  9
880
881   P
882      Proxy-Authenticate header field  9
883      Proxy-Authorization header field  9
884
885   R
886      realm  5
887      realm-value  5
888
889   S
890      Status Codes
891         401 Unauthorized  7
892
893
894
895Fielding, et al.       Expires September 15, 2011              [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 7                  March 2011
898
899
900         407 Proxy Authentication Required  7
901
902   W
903      WWW-Authenticate header field  9
904
905Authors' Addresses
906
907   Roy T. Fielding (editor)
908   Adobe Systems Incorporated
909   345 Park Ave
910   San Jose, CA  95110
911   USA
912
913   EMail: fielding@gbiv.com
914   URI:   http://roy.gbiv.com/
915
916
917   Jim Gettys
918   Alcatel-Lucent Bell Labs
919   21 Oak Knoll Road
920   Carlisle, MA  01741
921   USA
922
923   EMail: jg@freedesktop.org
924   URI:   http://gettys.wordpress.com/
925
926
927   Jeffrey C. Mogul
928   Hewlett-Packard Company
929   HP Labs, Large Scale Systems Group
930   1501 Page Mill Road, MS 1177
931   Palo Alto, CA  94304
932   USA
933
934   EMail: JeffMogul@acm.org
935
936
937   Henrik Frystyk Nielsen
938   Microsoft Corporation
939   1 Microsoft Way
940   Redmond, WA  98052
941   USA
942
943   EMail: henrikn@microsoft.com
944
945
946
947
948
949
950
951Fielding, et al.       Expires September 15, 2011              [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 7                  March 2011
954
955
956   Larry Masinter
957   Adobe Systems Incorporated
958   345 Park Ave
959   San Jose, CA  95110
960   USA
961
962   EMail: LMM@acm.org
963   URI:   http://larry.masinter.net/
964
965
966   Paul J. Leach
967   Microsoft Corporation
968   1 Microsoft Way
969   Redmond, WA  98052
970
971   EMail: paulle@microsoft.com
972
973
974   Tim Berners-Lee
975   World Wide Web Consortium
976   MIT Computer Science and Artificial Intelligence Laboratory
977   The Stata Center, Building 32
978   32 Vassar Street
979   Cambridge, MA  02139
980   USA
981
982   EMail: timbl@w3.org
983   URI:   http://www.w3.org/People/Berners-Lee/
984
985
986   Yves Lafon (editor)
987   World Wide Web Consortium
988   W3C / ERCIM
989   2004, rte des Lucioles
990   Sophia-Antipolis, AM  06902
991   France
992
993   EMail: ylafon@w3.org
994   URI:   http://www.raubacapeu.net/people/yves/
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007Fielding, et al.       Expires September 15, 2011              [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 7                  March 2011
1010
1011
1012   Julian F. Reschke (editor)
1013   greenbytes GmbH
1014   Hafenweg 16
1015   Muenster, NW  48155
1016   Germany
1017
1018   Phone: +49 251 2807760
1019   Fax:   +49 251 2807761
1020   EMail: julian.reschke@greenbytes.de
1021   URI:   http://greenbytes.de/tech/webdav/
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063Fielding, et al.       Expires September 15, 2011              [Page 19]
1064
Note: See TracBrowser for help on using the repository browser.