source: draft-ietf-httpbis/12/draft-ietf-httpbis-p7-auth-12.txt @ 1515

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

prepare publication of -12 drafts on 2010-10-25

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 35.8 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)                               Alcatel-Lucent
8Intended status: Standards Track                                J. Mogul
9Expires: April 28, 2011                                               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                                                        October 25, 2010
23
24
25                    HTTP/1.1, part 7: Authentication
26                     draft-ietf-httpbis-p7-auth-12
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.13.
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 April 28, 2011                 [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7                October 2010
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 April 28, 2011.
71
72Copyright Notice
73
74   Copyright (c) 2010 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 April 28, 2011                 [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7                October 2010
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  . . . . . . . . . . . .  8
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 . . . . . . . . . . . . . . . . . . . . . 10
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  . . . . . . . . . . . . . . . . . . . . . . . 12
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)  . . . . . . . . . . . . . . . . . . . . 14
145     B.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 14
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  . . . . . . . . . . . 15
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   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
159
160
161
162
163
164
165
166
167Fielding, et al.         Expires April 28, 2011                 [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7                October 2010
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 April 28, 2011                 [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7                October 2010
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 April 28, 2011                 [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7                October 2010
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 April 28, 2011                 [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7                October 2010
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, these additional
343   mechanisms are not defined by this specification.
344
345   Proxies MUST be completely transparent regarding user agent
346   authentication by origin servers.  That is, they MUST forward the
347   WWW-Authenticate and Authorization headers untouched, and follow the
348   rules found in Section 4.1.  Both the Proxy-Authenticate and the
349   Proxy-Authorization header fields are hop-by-hop headers (see Section
350   7.1.3.1 of [Part1]).
351
3522.1.  Authentication Scheme Registry
353
354   The HTTP Authentication Scheme Registry defines the name space for
355   the authentication schemes in challenges and credentials.
356
357   Registrations MUST include the following fields:
358
359   o  Authentication Scheme Name
360
361   o  Pointer to specification text
362
363   Values to be added to this name space are subject to IETF review
364   ([RFC5226], Section 4.1).
365
366   The registry itself is maintained at
367   <http://www.iana.org/assignments/http-authschemes>.
368
3693.  Status Code Definitions
370
3713.1.  401 Unauthorized
372
373   The request requires user authentication.  The response MUST include
374   a WWW-Authenticate header field (Section 4.4) containing a challenge
375   applicable to the target resource.  The client MAY repeat the request
376   with a suitable Authorization header field (Section 4.1).  If the
377   request already included Authorization credentials, then the 401
378   response indicates that authorization has been refused for those
379   credentials.  If the 401 response contains the same challenge as the
380   prior response, and the user agent has already attempted
381   authentication at least once, then the user SHOULD be presented the
382   representation that was given in the response, since that
383   representation might include relevant diagnostic information.
384
385
386
387
388
389
390
391Fielding, et al.         Expires April 28, 2011                 [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7                October 2010
394
395
3963.2.  407 Proxy Authentication Required
397
398   This code is similar to 401 (Unauthorized), but indicates that the
399   client ought to first authenticate itself with the proxy.  The proxy
400   MUST return a Proxy-Authenticate header field (Section 4.2)
401   containing a challenge applicable to the proxy for the target
402   resource.  The client MAY repeat the request with a suitable Proxy-
403   Authorization header field (Section 4.3).
404
4054.  Header Field Definitions
406
407   This section defines the syntax and semantics of HTTP/1.1 header
408   fields related to authentication.
409
4104.1.  Authorization
411
412   The "Authorization" request-header field allows a user agent to
413   authenticate itself with a server -- usually, but not necessarily,
414   after receiving a 401 (Unauthorized) response.  Its value consists of
415   credentials containing information of the user agent for the realm of
416   the resource being requested.
417
418     Authorization   = "Authorization" ":" OWS Authorization-v
419     Authorization-v = credentials
420
421   If a request is authenticated and a realm specified, the same
422   credentials SHOULD be valid for all other requests within this realm
423   (assuming that the authentication scheme itself does not require
424   otherwise, such as credentials that vary according to a challenge
425   value or using synchronized clocks).
426
427   When a shared cache (see Section 1.2 of [Part6]) receives a request
428   containing an Authorization field, it MUST NOT return the
429   corresponding response as a reply to any other request, unless one of
430   the following specific exceptions holds:
431
432   1.  If the response includes the "s-maxage" cache-control directive,
433       the cache MAY use that response in replying to a subsequent
434       request.  But (if the specified maximum age has passed) a proxy
435       cache MUST first revalidate it with the origin server, using the
436       request-header fields from the new request to allow the origin
437       server to authenticate the new request.  (This is the defined
438       behavior for s-maxage.)  If the response includes "s-maxage=0",
439       the proxy MUST always revalidate it before re-using it.
440
441   2.  If the response includes the "must-revalidate" cache-control
442       directive, the cache MAY use that response in replying to a
443       subsequent request.  But if the response is stale, all caches
444
445
446
447Fielding, et al.         Expires April 28, 2011                 [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7                October 2010
450
451
452       MUST first revalidate it with the origin server, using the
453       request-header fields from the new request to allow the origin
454       server to authenticate the new request.
455
456   3.  If the response includes the "public" cache-control directive, it
457       MAY be returned in reply to any subsequent request.
458
4594.2.  Proxy-Authenticate
460
461   The "Proxy-Authenticate" response-header field consists of a
462   challenge that indicates the authentication scheme and parameters
463   applicable to the proxy for this effective request URI (Section 4.3
464   of [Part1]).  It MUST be included as part of a 407 (Proxy
465   Authentication Required) response.
466
467     Proxy-Authenticate   = "Proxy-Authenticate" ":" OWS
468                            Proxy-Authenticate-v
469     Proxy-Authenticate-v = 1#challenge
470
471   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
472   only to the current connection and SHOULD NOT be passed on to
473   downstream clients.  However, an intermediate proxy might need to
474   obtain its own credentials by requesting them from the downstream
475   client, which in some circumstances will appear as if the proxy is
476   forwarding the Proxy-Authenticate header field.
477
4784.3.  Proxy-Authorization
479
480   The "Proxy-Authorization" request-header field allows the client to
481   identify itself (or its user) to a proxy which requires
482   authentication.  Its value consists of credentials containing the
483   authentication information of the user agent for the proxy and/or
484   realm of the resource being requested.
485
486     Proxy-Authorization   = "Proxy-Authorization" ":" OWS
487                             Proxy-Authorization-v
488     Proxy-Authorization-v = credentials
489
490   Unlike Authorization, the Proxy-Authorization header field applies
491   only to the next outbound proxy that demanded authentication using
492   the Proxy-Authenticate field.  When multiple proxies are used in a
493   chain, the Proxy-Authorization header field is consumed by the first
494   outbound proxy that was expecting to receive credentials.  A proxy
495   MAY relay the credentials from the client request to the next proxy
496   if that is the mechanism by which the proxies cooperatively
497   authenticate a given request.
498
499
500
501
502
503Fielding, et al.         Expires April 28, 2011                 [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7                October 2010
506
507
5084.4.  WWW-Authenticate
509
510   The "WWW-Authenticate" response-header field consists of at least one
511   challenge that indicates the authentication scheme(s) and parameters
512   applicable to the effective request URI (Section 4.3 of [Part1]).  It
513   MUST be included in 401 (Unauthorized) response messages.
514
515     WWW-Authenticate   = "WWW-Authenticate" ":" OWS WWW-Authenticate-v
516     WWW-Authenticate-v = 1#challenge
517
518   User agents are advised to take special care in parsing the WWW-
519   Authenticate field value as it might contain more than one challenge,
520   or if more than one WWW-Authenticate header field is provided, the
521   contents of a challenge itself can contain a comma-separated list of
522   authentication parameters.
523
5245.  IANA Considerations
525
5265.1.  Authenticaton Scheme Registry
527
528   The registration procedure for HTTP Authentication Schemes is defined
529   by Section 2.1 of this document.
530
531   The HTTP Method Authentication Scheme shall be created at
532   <http://www.iana.org/assignments/http-authschemes>.
533
5345.2.  Status Code Registration
535
536   The HTTP Status Code Registry located at
537   <http://www.iana.org/assignments/http-status-codes> shall be updated
538   with the registrations below:
539
540   +-------+-------------------------------+-------------+
541   | Value | Description                   | Reference   |
542   +-------+-------------------------------+-------------+
543   | 401   | Unauthorized                  | Section 3.1 |
544   | 407   | Proxy Authentication Required | Section 3.2 |
545   +-------+-------------------------------+-------------+
546
5475.3.  Header Field Registration
548
549   The Message Header Field Registry located at <http://www.iana.org/
550   assignments/message-headers/message-header-index.html> shall be
551   updated with the permanent registrations below (see [RFC3864]):
552
553
554
555
556
557
558
559Fielding, et al.         Expires April 28, 2011                [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7                October 2010
562
563
564   +---------------------+----------+----------+-------------+
565   | Header Field Name   | Protocol | Status   | Reference   |
566   +---------------------+----------+----------+-------------+
567   | Authorization       | http     | standard | Section 4.1 |
568   | Proxy-Authenticate  | http     | standard | Section 4.2 |
569   | Proxy-Authorization | http     | standard | Section 4.3 |
570   | WWW-Authenticate    | http     | standard | Section 4.4 |
571   +---------------------+----------+----------+-------------+
572
573   The change controller is: "IETF (iesg@ietf.org) - Internet
574   Engineering Task Force".
575
5766.  Security Considerations
577
578   This section is meant to inform application developers, information
579   providers, and users of the security limitations in HTTP/1.1 as
580   described by this document.  The discussion does not include
581   definitive solutions to the problems revealed, though it does make
582   some suggestions for reducing security risks.
583
5846.1.  Authentication Credentials and Idle Clients
585
586   Existing HTTP clients and user agents typically retain authentication
587   information indefinitely.  HTTP/1.1 does not provide a method for a
588   server to direct clients to discard these cached credentials.  This
589   is a significant defect that requires further extensions to HTTP.
590   Circumstances under which credential caching can interfere with the
591   application's security model include but are not limited to:
592
593   o  Clients which have been idle for an extended period following
594      which the server might wish to cause the client to reprompt the
595      user for credentials.
596
597   o  Applications which include a session termination indication (such
598      as a "logout" or "commit" button on a page) after which the server
599      side of the application "knows" that there is no further reason
600      for the client to retain the credentials.
601
602   This is currently under separate study.  There are a number of work-
603   arounds to parts of this problem, and we encourage the use of
604   password protection in screen savers, idle time-outs, and other
605   methods which mitigate the security problems inherent in this
606   problem.  In particular, user agents which cache credentials are
607   encouraged to provide a readily accessible mechanism for discarding
608   cached credentials under user control.
609
610
611
612
613
614
615Fielding, et al.         Expires April 28, 2011                [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7                October 2010
618
619
6207.  Acknowledgments
621
622   This specification takes over the definition of the HTTP
623   Authentication Framework, previously defined in RFC 2617.  We thank
624   to John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott
625   D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for
626   their work on that specification.
627
628   [[acks: HTTPbis acknowledgements.]]
629
6308.  References
631
6328.1.  Normative References
633
634   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
635              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
636              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
637              and Message Parsing", draft-ietf-httpbis-p1-messaging-12
638              (work in progress), October 2010.
639
640   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
641              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
642              Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
643              6: Caching", draft-ietf-httpbis-p6-cache-12 (work in
644              progress), October 2010.
645
646   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
647              Requirement Levels", BCP 14, RFC 2119, March 1997.
648
649   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
650              Specifications: ABNF", STD 68, RFC 5234, January 2008.
651
6528.2.  Informative References
653
654   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
655              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
656              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
657
658   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
659              Leach, P., Luotonen, A., and L. Stewart, "HTTP
660              Authentication: Basic and Digest Access Authentication",
661              RFC 2617, June 1999.
662
663   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
664              Procedures for Message Header Fields", BCP 90, RFC 3864,
665              September 2004.
666
667   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
668
669
670
671Fielding, et al.         Expires April 28, 2011                [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7                October 2010
674
675
676              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
677              May 2008.
678
679Appendix A.  Collected ABNF
680
681   Authorization = "Authorization:" OWS Authorization-v
682   Authorization-v = credentials
683
684   OWS = <OWS, defined in [Part1], Section 1.2.2>
685
686   Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v
687   Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
688    challenge ] )
689   Proxy-Authorization = "Proxy-Authorization:" OWS
690    Proxy-Authorization-v
691   Proxy-Authorization-v = credentials
692
693   WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v
694   WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
695    challenge ] )
696
697   auth-param = token "=" ( token / quoted-string )
698   auth-scheme = token
699
700   challenge = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS
701    auth-param ] )
702   credentials = auth-scheme ( token / quoted-string / [ ( "," /
703    auth-param ) *( OWS "," [ OWS auth-param ] ) ] )
704
705   quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
706
707   realm = "realm=" realm-value
708   realm-value = quoted-string
709
710   token = <token, defined in [Part1], Section 1.2.2>
711
712   ABNF diagnostics:
713
714   ; Authorization defined but not used
715   ; Proxy-Authenticate defined but not used
716   ; Proxy-Authorization defined but not used
717   ; WWW-Authenticate defined but not used
718   ; realm defined but not used
719
720
721
722
723
724
725
726
727Fielding, et al.         Expires April 28, 2011                [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 7                October 2010
730
731
732Appendix B.  Change Log (to be removed by RFC Editor before publication)
733
734B.1.  Since RFC 2616
735
736   Extracted relevant partitions from [RFC2616].
737
738B.2.  Since draft-ietf-httpbis-p7-auth-00
739
740   Closed issues:
741
742   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
743      Informative references"
744
745B.3.  Since draft-ietf-httpbis-p7-auth-01
746
747   Ongoing work on ABNF conversion
748   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
749
750   o  Explicitly import BNF rules for "challenge" and "credentials" from
751      RFC2617.
752
753   o  Add explicit references to BNF syntax and rules imported from
754      other parts of the specification.
755
756B.4.  Since draft-ietf-httpbis-p7-auth-02
757
758   Ongoing work on IANA Message Header Field Registration
759   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
760
761   o  Reference RFC 3984, and update header field registrations for
762      header fields defined in this document.
763
764B.5.  Since draft-ietf-httpbis-p7-auth-03
765
766B.6.  Since draft-ietf-httpbis-p7-auth-04
767
768   Ongoing work on ABNF conversion
769   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
770
771   o  Use "/" instead of "|" for alternatives.
772
773   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
774      whitespace ("OWS") and required whitespace ("RWS").
775
776   o  Rewrite ABNFs to spell out whitespace rules, factor out header
777      field value format definitions.
778
779
780
781
782
783Fielding, et al.         Expires April 28, 2011                [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 7                October 2010
786
787
788B.7.  Since draft-ietf-httpbis-p7-auth-05
789
790   Final work on ABNF conversion
791   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
792
793   o  Add appendix containing collected and expanded ABNF, reorganize
794      ABNF introduction.
795
796B.8.  Since draft-ietf-httpbis-p7-auth-06
797
798   None.
799
800B.9.  Since draft-ietf-httpbis-p7-auth-07
801
802   Closed issues:
803
804   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
805      registrations for optional status codes"
806
807B.10.  Since draft-ietf-httpbis-p7-auth-08
808
809   No significant changes.
810
811B.11.  Since draft-ietf-httpbis-p7-auth-09
812
813   Partly resolved issues:
814
815   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
816      requested resource's URI"
817
818B.12.  Since draft-ietf-httpbis-p7-auth-10
819
820   None yet.
821
822B.13.  Since draft-ietf-httpbis-p7-auth-11
823
824   Closed issues:
825
826   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/130>: "introduction
827      to part 7 is work-in-progress"
828
829   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/195>: "auth-param
830      syntax"
831
832   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/237>: "absorbing the
833      auth framework from 2617"
834
835   Partly resolved issues:
836
837
838
839Fielding, et al.         Expires April 28, 2011                [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 7                October 2010
842
843
844   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/141>: "should we
845      have an auth scheme registry"
846
847Index
848
849   4
850      401 Unauthorized (status code)  7
851      407 Proxy Authentication Required (status code)  8
852
853   A
854      auth-param  5
855      auth-scheme  5
856      Authorization header  8
857
858   C
859      challenge  5
860      credentials  6
861
862   G
863      Grammar
864         Authorization  8
865         Authorization-v  8
866         Proxy-Authenticate  9
867         Proxy-Authenticate-v  9
868         Proxy-Authorization  9
869         Proxy-Authorization-v  9
870         WWW-Authenticate  10
871         WWW-Authenticate-v  10
872
873   H
874      Headers
875         Authorization  8
876         Proxy-Authenticate  9
877         Proxy-Authorization  9
878         WWW-Authenticate  10
879
880   P
881      Proxy-Authenticate header  9
882      Proxy-Authorization header  9
883
884   R
885      realm  5
886      realm-value  5
887
888   S
889      Status Codes
890         401 Unauthorized  7
891         407 Proxy Authentication Required  8
892
893
894
895Fielding, et al.         Expires April 28, 2011                [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 7                October 2010
898
899
900   W
901      WWW-Authenticate header  10
902
903Authors' Addresses
904
905   Roy T. Fielding (editor)
906   Day Software
907   23 Corporate Plaza DR, Suite 280
908   Newport Beach, CA  92660
909   USA
910
911   Phone: +1-949-706-5300
912   Fax:   +1-949-706-5305
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 April 28, 2011                [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 7                October 2010
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 April 28, 2011                [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 7                October 2010
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 April 28, 2011                [Page 19]
1064
Note: See TracBrowser for help on using the repository browser.