source: draft-ietf-httpbis/15/draft-ietf-httpbis-p7-auth-15.txt @ 2082

Last change on this file since 2082 was 1328, checked in by julian.reschke@…, 8 years ago

Fix "none yet" entries in -15 change log entries, update -latest accordingly.

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 35.6 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: January 12, 2012                                             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                                                           July 11, 2011
23
24
25                    HTTP/1.1, part 7: Authentication
26                     draft-ietf-httpbis-p7-auth-15
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), which is archived at
42   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
43
44   The current issues list is at
45   <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
46   documents (including fancy diffs) can be found at
47   <http://tools.ietf.org/wg/httpbis/>.
48
49   The changes in this draft are summarized in Appendix C.16.
50
51Status of This Memo
52
53
54
55Fielding, et al.        Expires January 12, 2012                [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7                   July 2011
58
59
60   This Internet-Draft is submitted in full conformance with the
61   provisions of BCP 78 and BCP 79.
62
63   Internet-Drafts are working documents of the Internet Engineering
64   Task Force (IETF).  Note that other groups may also distribute
65   working documents as Internet-Drafts.  The list of current Internet-
66   Drafts is at http://datatracker.ietf.org/drafts/current/.
67
68   Internet-Drafts are draft documents valid for a maximum of six months
69   and may be updated, replaced, or obsoleted by other documents at any
70   time.  It is inappropriate to use Internet-Drafts as reference
71   material or to cite them other than as "work in progress."
72
73   This Internet-Draft will expire on January 12, 2012.
74
75Copyright Notice
76
77   Copyright (c) 2011 IETF Trust and the persons identified as the
78   document authors.  All rights reserved.
79
80   This document is subject to BCP 78 and the IETF Trust's Legal
81   Provisions Relating to IETF Documents
82   (http://trustee.ietf.org/license-info) in effect on the date of
83   publication of this document.  Please review these documents
84   carefully, as they describe your rights and restrictions with respect
85   to this document.  Code Components extracted from this document must
86   include Simplified BSD License text as described in Section 4.e of
87   the Trust Legal Provisions and are provided without warranty as
88   described in the Simplified BSD License.
89
90   This document may contain material from IETF Documents or IETF
91   Contributions published or made publicly available before November
92   10, 2008.  The person(s) controlling the copyright in some of this
93   material may not have granted the IETF Trust the right to allow
94   modifications of such material outside the IETF Standards Process.
95   Without obtaining an adequate license from the person(s) controlling
96   the copyright in such materials, this document may not be modified
97   outside the IETF Standards Process, and derivative works of it may
98   not be created outside the IETF Standards Process, except to format
99   it for publication as an RFC or to translate it into languages other
100   than English.
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.        Expires January 12, 2012                [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7                   July 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  . . . . . . . . . . . . . . . . . . . 10
137     6.1.  Authentication Credentials and Idle Clients  . . . . . . . 11
138   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
139   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
140     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
141     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
142   Appendix A.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 12
143   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 13
144   Appendix C.  Change Log (to be removed by RFC Editor before
145                publication)  . . . . . . . . . . . . . . . . . . . . 13
146     C.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 13
147     C.2.  Since draft-ietf-httpbis-p7-auth-00  . . . . . . . . . . . 13
148     C.3.  Since draft-ietf-httpbis-p7-auth-01  . . . . . . . . . . . 14
149     C.4.  Since draft-ietf-httpbis-p7-auth-02  . . . . . . . . . . . 14
150     C.5.  Since draft-ietf-httpbis-p7-auth-03  . . . . . . . . . . . 14
151     C.6.  Since draft-ietf-httpbis-p7-auth-04  . . . . . . . . . . . 14
152     C.7.  Since draft-ietf-httpbis-p7-auth-05  . . . . . . . . . . . 14
153     C.8.  Since draft-ietf-httpbis-p7-auth-06  . . . . . . . . . . . 14
154     C.9.  Since draft-ietf-httpbis-p7-auth-07  . . . . . . . . . . . 15
155     C.10. Since draft-ietf-httpbis-p7-auth-08  . . . . . . . . . . . 15
156     C.11. Since draft-ietf-httpbis-p7-auth-09  . . . . . . . . . . . 15
157     C.12. Since draft-ietf-httpbis-p7-auth-10  . . . . . . . . . . . 15
158     C.13. Since draft-ietf-httpbis-p7-auth-11  . . . . . . . . . . . 15
159     C.14. Since draft-ietf-httpbis-p7-auth-12  . . . . . . . . . . . 15
160     C.15. Since draft-ietf-httpbis-p7-auth-13  . . . . . . . . . . . 16
161     C.16. Since draft-ietf-httpbis-p7-auth-14  . . . . . . . . . . . 16
162   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
163
164
165
166
167Fielding, et al.        Expires January 12, 2012                [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7                   July 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 B 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 January 12, 2012                [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7                   July 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 January 12, 2012                [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7                   July 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 January 12, 2012                [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7                   July 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 January 12, 2012                [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7                   July 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 = credentials
412
413   If a request is authenticated and a realm specified, the same
414   credentials SHOULD be valid for all other requests within this realm
415   (assuming that the authentication scheme itself does not require
416   otherwise, such as credentials that vary according to a challenge
417   value or using synchronized clocks).
418
419   When a shared cache (see Section 1.2 of [Part6]) receives a request
420   containing an Authorization field, it MUST NOT return the
421   corresponding response as a reply to any other request, unless one of
422   the following specific exceptions holds:
423
424   1.  If the response includes the "s-maxage" cache-control directive,
425       the cache MAY use that response in replying to a subsequent
426       request.  But (if the specified maximum age has passed) a proxy
427       cache MUST first revalidate it with the origin server, using the
428       header fields from the new request to allow the origin server to
429       authenticate the new request.  (This is the defined behavior for
430       s-maxage.)  If the response includes "s-maxage=0", the proxy MUST
431       always revalidate it before re-using it.
432
433   2.  If the response includes the "must-revalidate" cache-control
434       directive, the cache MAY use that response in replying to a
435       subsequent request.  But if the response is stale, all caches
436       MUST first revalidate it with the origin server, using the header
437       fields from the new request to allow the origin server to
438       authenticate the new request.
439
440   3.  If the response includes the "public" cache-control directive, it
441       MAY be returned in reply to any subsequent request.
442
443
444
445
446
447Fielding, et al.        Expires January 12, 2012                [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7                   July 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 = 1#challenge
461
462   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
463   only to the current connection and SHOULD NOT be passed on to
464   downstream clients.  However, an intermediate proxy might need to
465   obtain its own credentials by requesting them from the downstream
466   client, which in some circumstances will appear as if the proxy is
467   forwarding the Proxy-Authenticate header field.
468
4694.3.  Proxy-Authorization
470
471   The "Proxy-Authorization" header field allows the client to identify
472   itself (or its user) to a proxy which requires authentication.  Its
473   value consists of credentials containing the authentication
474   information of the user agent for the proxy and/or realm of the
475   resource being requested.
476
477     Proxy-Authorization = credentials
478
479   Unlike Authorization, the Proxy-Authorization header field applies
480   only to the next outbound proxy that demanded authentication using
481   the Proxy-Authenticate field.  When multiple proxies are used in a
482   chain, the Proxy-Authorization header field is consumed by the first
483   outbound proxy that was expecting to receive credentials.  A proxy
484   MAY relay the credentials from the client request to the next proxy
485   if that is the mechanism by which the proxies cooperatively
486   authenticate a given request.
487
4884.4.  WWW-Authenticate
489
490   The "WWW-Authenticate" header field consists of at least one
491   challenge that indicates the authentication scheme(s) and parameters
492   applicable to the effective request URI (Section 4.3 of [Part1]).  It
493   MUST be included in 401 (Unauthorized) response messages.
494
495     WWW-Authenticate = 1#challenge
496
497   User agents are advised to take special care in parsing the WWW-
498   Authenticate field value as it might contain more than one challenge,
499   or if more than one WWW-Authenticate header field is provided, the
500
501
502
503Fielding, et al.        Expires January 12, 2012                [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7                   July 2011
506
507
508   contents of a challenge itself can contain a comma-separated list of
509   authentication parameters.
510
5115.  IANA Considerations
512
5135.1.  Authenticaton Scheme Registry
514
515   The registration procedure for HTTP Authentication Schemes is defined
516   by Section 2.1 of this document.
517
518   The HTTP Method Authentication Scheme shall be created at
519   <http://www.iana.org/assignments/http-authschemes>.
520
5215.2.  Status Code Registration
522
523   The HTTP Status Code Registry located at
524   <http://www.iana.org/assignments/http-status-codes> shall be updated
525   with the registrations below:
526
527   +-------+-------------------------------+-------------+
528   | Value | Description                   | Reference   |
529   +-------+-------------------------------+-------------+
530   | 401   | Unauthorized                  | Section 3.1 |
531   | 407   | Proxy Authentication Required | Section 3.2 |
532   +-------+-------------------------------+-------------+
533
5345.3.  Header Field Registration
535
536   The Message Header Field Registry located at <http://www.iana.org/
537   assignments/message-headers/message-header-index.html> shall be
538   updated with the permanent registrations below (see [RFC3864]):
539
540   +---------------------+----------+----------+-------------+
541   | Header Field Name   | Protocol | Status   | Reference   |
542   +---------------------+----------+----------+-------------+
543   | Authorization       | http     | standard | Section 4.1 |
544   | Proxy-Authenticate  | http     | standard | Section 4.2 |
545   | Proxy-Authorization | http     | standard | Section 4.3 |
546   | WWW-Authenticate    | http     | standard | Section 4.4 |
547   +---------------------+----------+----------+-------------+
548
549   The change controller is: "IETF (iesg@ietf.org) - Internet
550   Engineering Task Force".
551
5526.  Security Considerations
553
554   This section is meant to inform application developers, information
555   providers, and users of the security limitations in HTTP/1.1 as
556
557
558
559Fielding, et al.        Expires January 12, 2012               [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7                   July 2011
562
563
564   described by this document.  The discussion does not include
565   definitive solutions to the problems revealed, though it does make
566   some suggestions for reducing security risks.
567
5686.1.  Authentication Credentials and Idle Clients
569
570   Existing HTTP clients and user agents typically retain authentication
571   information indefinitely.  HTTP/1.1 does not provide a method for a
572   server to direct clients to discard these cached credentials.  This
573   is a significant defect that requires further extensions to HTTP.
574   Circumstances under which credential caching can interfere with the
575   application's security model include but are not limited to:
576
577   o  Clients which have been idle for an extended period following
578      which the server might wish to cause the client to reprompt the
579      user for credentials.
580
581   o  Applications which include a session termination indication (such
582      as a "logout" or "commit" button on a page) after which the server
583      side of the application "knows" that there is no further reason
584      for the client to retain the credentials.
585
586   This is currently under separate study.  There are a number of work-
587   arounds to parts of this problem, and we encourage the use of
588   password protection in screen savers, idle time-outs, and other
589   methods which mitigate the security problems inherent in this
590   problem.  In particular, user agents which cache credentials are
591   encouraged to provide a readily accessible mechanism for discarding
592   cached credentials under user control.
593
5947.  Acknowledgments
595
596   This specification takes over the definition of the HTTP
597   Authentication Framework, previously defined in RFC 2617.  We thank
598   to John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott
599   D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for
600   their work on that specification.
601
602   [[acks: HTTPbis acknowledgements.]]
603
6048.  References
605
6068.1.  Normative References
607
608   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
609              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
610              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
611              and Message Parsing", draft-ietf-httpbis-p1-messaging-15
612
613
614
615Fielding, et al.        Expires January 12, 2012               [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7                   July 2011
618
619
620              (work in progress), July 2011.
621
622   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
623              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
624              Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
625              6: Caching", draft-ietf-httpbis-p6-cache-15 (work in
626              progress), July 2011.
627
628   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
629              Requirement Levels", BCP 14, RFC 2119, March 1997.
630
631   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
632              Specifications: ABNF", STD 68, RFC 5234, January 2008.
633
6348.2.  Informative References
635
636   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
637              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
638              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
639
640   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
641              Leach, P., Luotonen, A., and L. Stewart, "HTTP
642              Authentication: Basic and Digest Access Authentication",
643              RFC 2617, June 1999.
644
645   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
646              Procedures for Message Header Fields", BCP 90, RFC 3864,
647              September 2004.
648
649   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
650              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
651              May 2008.
652
653Appendix A.  Changes from RFC 2616
654
655   Change ABNF productions for header fields to only define the field
656   value.  (Section 4)
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671Fielding, et al.        Expires January 12, 2012               [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7                   July 2011
674
675
676Appendix B.  Collected ABNF
677
678   Authorization = credentials
679
680   OWS = <OWS, defined in [Part1], Section 1.2.2>
681
682   Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
683    challenge ] )
684   Proxy-Authorization = credentials
685
686   WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
687    ] )
688
689   auth-param = token "=" ( token / quoted-string )
690   auth-scheme = token
691
692   challenge = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS
693    auth-param ] )
694   credentials = auth-scheme ( token / quoted-string / [ ( "," /
695    auth-param ) *( OWS "," [ OWS auth-param ] ) ] )
696
697   quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
698
699   realm = "realm=" realm-value
700   realm-value = quoted-string
701
702   token = <token, defined in [Part1], Section 1.2.2>
703
704   ABNF diagnostics:
705
706   ; Authorization defined but not used
707   ; Proxy-Authenticate defined but not used
708   ; Proxy-Authorization defined but not used
709   ; WWW-Authenticate defined but not used
710   ; realm defined but not used
711
712Appendix C.  Change Log (to be removed by RFC Editor before publication)
713
714C.1.  Since RFC 2616
715
716   Extracted relevant partitions from [RFC2616].
717
718C.2.  Since draft-ietf-httpbis-p7-auth-00
719
720   Closed issues:
721
722   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
723      Informative references"
724
725
726
727Fielding, et al.        Expires January 12, 2012               [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 7                   July 2011
730
731
732C.3.  Since draft-ietf-httpbis-p7-auth-01
733
734   Ongoing work on ABNF conversion
735   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
736
737   o  Explicitly import BNF rules for "challenge" and "credentials" from
738      RFC2617.
739
740   o  Add explicit references to BNF syntax and rules imported from
741      other parts of the specification.
742
743C.4.  Since draft-ietf-httpbis-p7-auth-02
744
745   Ongoing work on IANA Message Header Field Registration
746   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
747
748   o  Reference RFC 3984, and update header field registrations for
749      header fields defined in this document.
750
751C.5.  Since draft-ietf-httpbis-p7-auth-03
752
753C.6.  Since draft-ietf-httpbis-p7-auth-04
754
755   Ongoing work on ABNF conversion
756   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
757
758   o  Use "/" instead of "|" for alternatives.
759
760   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
761      whitespace ("OWS") and required whitespace ("RWS").
762
763   o  Rewrite ABNFs to spell out whitespace rules, factor out header
764      field value format definitions.
765
766C.7.  Since draft-ietf-httpbis-p7-auth-05
767
768   Final work on ABNF conversion
769   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
770
771   o  Add appendix containing collected and expanded ABNF, reorganize
772      ABNF introduction.
773
774C.8.  Since draft-ietf-httpbis-p7-auth-06
775
776   None.
777
778
779
780
781
782
783Fielding, et al.        Expires January 12, 2012               [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 7                   July 2011
786
787
788C.9.  Since draft-ietf-httpbis-p7-auth-07
789
790   Closed issues:
791
792   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
793      registrations for optional status codes"
794
795C.10.  Since draft-ietf-httpbis-p7-auth-08
796
797   No significant changes.
798
799C.11.  Since draft-ietf-httpbis-p7-auth-09
800
801   Partly resolved issues:
802
803   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
804      requested resource's URI"
805
806C.12.  Since draft-ietf-httpbis-p7-auth-10
807
808   None.
809
810C.13.  Since draft-ietf-httpbis-p7-auth-11
811
812   Closed issues:
813
814   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/130>: "introduction
815      to part 7 is work-in-progress"
816
817   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/195>: "auth-param
818      syntax"
819
820   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
821      Classification"
822
823   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/237>: "absorbing the
824      auth framework from 2617"
825
826   Partly resolved issues:
827
828   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/141>: "should we
829      have an auth scheme registry"
830
831C.14.  Since draft-ietf-httpbis-p7-auth-12
832
833   None.
834
835
836
837
838
839Fielding, et al.        Expires January 12, 2012               [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 7                   July 2011
842
843
844C.15.  Since draft-ietf-httpbis-p7-auth-13
845
846   Closed issues:
847
848   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
849      ABNFs for header fields"
850
851C.16.  Since draft-ietf-httpbis-p7-auth-14
852
853   None.
854
855Index
856
857   4
858      401 Unauthorized (status code)  7
859      407 Proxy Authentication Required (status code)  7
860
861   A
862      auth-param  5
863      auth-scheme  5
864      Authorization header field  8
865
866   C
867      challenge  5
868      credentials  6
869
870   G
871      Grammar
872         Authorization  8
873         Proxy-Authenticate  9
874         Proxy-Authorization  9
875         WWW-Authenticate  9
876
877   H
878      Header Fields
879         Authorization  8
880         Proxy-Authenticate  9
881         Proxy-Authorization  9
882         WWW-Authenticate  9
883
884   P
885      Proxy-Authenticate header field  9
886      Proxy-Authorization header field  9
887
888   R
889      realm  5
890      realm-value  5
891
892
893
894
895Fielding, et al.        Expires January 12, 2012               [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 7                   July 2011
898
899
900   S
901      Status Codes
902         401 Unauthorized  7
903         407 Proxy Authentication Required  7
904
905   W
906      WWW-Authenticate header field  9
907
908Authors' Addresses
909
910   Roy T. Fielding (editor)
911   Adobe Systems Incorporated
912   345 Park Ave
913   San Jose, CA  95110
914   USA
915
916   EMail: fielding@gbiv.com
917   URI:   http://roy.gbiv.com/
918
919
920   Jim Gettys
921   Alcatel-Lucent Bell Labs
922   21 Oak Knoll Road
923   Carlisle, MA  01741
924   USA
925
926   EMail: jg@freedesktop.org
927   URI:   http://gettys.wordpress.com/
928
929
930   Jeffrey C. Mogul
931   Hewlett-Packard Company
932   HP Labs, Large Scale Systems Group
933   1501 Page Mill Road, MS 1177
934   Palo Alto, CA  94304
935   USA
936
937   EMail: JeffMogul@acm.org
938
939
940   Henrik Frystyk Nielsen
941   Microsoft Corporation
942   1 Microsoft Way
943   Redmond, WA  98052
944   USA
945
946   EMail: henrikn@microsoft.com
947
948
949
950
951Fielding, et al.        Expires January 12, 2012               [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 7                   July 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 January 12, 2012               [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 7                   July 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 January 12, 2012               [Page 19]
1064
Note: See TracBrowser for help on using the repository browser.