source: draft-ietf-httpbis/16/draft-ietf-httpbis-p7-auth-16.txt @ 2323

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

prepare for publication of -16 on Aug 24.

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 40.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: February 25, 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                                                         August 24, 2011
23
24
25                    HTTP/1.1, part 7: Authentication
26                     draft-ietf-httpbis-p7-auth-16
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.
36
37   Part 7 defines the HTTP Authentication framework.
38
39Editorial Note (To be removed by RFC Editor)
40
41   Discussion of this draft should take place on the HTTPBIS working
42   group mailing list (ietf-http-wg@w3.org), which is archived at
43   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
44
45   The current issues list is at
46   <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
47   documents (including fancy diffs) can be found at
48   <http://tools.ietf.org/wg/httpbis/>.
49
50   The changes in this draft are summarized in Appendix C.17.
51
52
53
54
55Fielding, et al.        Expires February 25, 2012               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7                 August 2011
58
59
60Status of This Memo
61
62   This Internet-Draft is submitted in full conformance with the
63   provisions of BCP 78 and BCP 79.
64
65   Internet-Drafts are working documents of the Internet Engineering
66   Task Force (IETF).  Note that other groups may also distribute
67   working documents as Internet-Drafts.  The list of current Internet-
68   Drafts is at http://datatracker.ietf.org/drafts/current/.
69
70   Internet-Drafts are draft documents valid for a maximum of six months
71   and may be updated, replaced, or obsoleted by other documents at any
72   time.  It is inappropriate to use Internet-Drafts as reference
73   material or to cite them other than as "work in progress."
74
75   This Internet-Draft will expire on February 25, 2012.
76
77Copyright Notice
78
79   Copyright (c) 2011 IETF Trust and the persons identified as the
80   document authors.  All rights reserved.
81
82   This document is subject to BCP 78 and the IETF Trust's Legal
83   Provisions Relating to IETF Documents
84   (http://trustee.ietf.org/license-info) in effect on the date of
85   publication of this document.  Please review these documents
86   carefully, as they describe your rights and restrictions with respect
87   to this document.  Code Components extracted from this document must
88   include Simplified BSD License text as described in Section 4.e of
89   the Trust Legal Provisions and are provided without warranty as
90   described in the Simplified BSD License.
91
92   This document may contain material from IETF Documents or IETF
93   Contributions published or made publicly available before November
94   10, 2008.  The person(s) controlling the copyright in some of this
95   material may not have granted the IETF Trust the right to allow
96   modifications of such material outside the IETF Standards Process.
97   Without obtaining an adequate license from the person(s) controlling
98   the copyright in such materials, this document may not be modified
99   outside the IETF Standards Process, and derivative works of it may
100   not be created outside the IETF Standards Process, except to format
101   it for publication as an RFC or to translate it into languages other
102   than English.
103
104Table of Contents
105
106   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
107     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
108
109
110
111Fielding, et al.        Expires February 25, 2012               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7                 August 2011
114
115
116     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
117       1.2.1.  Core Rules . . . . . . . . . . . . . . . . . . . . . .  4
118   2.  Access Authentication Framework  . . . . . . . . . . . . . . .  5
119     2.1.  Challenge and Response . . . . . . . . . . . . . . . . . .  5
120     2.2.  Protection Space (Realm) . . . . . . . . . . . . . . . . .  7
121     2.3.  Authentication Scheme Registry . . . . . . . . . . . . . .  7
122       2.3.1.  Considerations for New Authentication Schemes  . . . .  8
123   3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  8
124     3.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  8
125     3.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  9
126   4.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  9
127     4.1.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  9
128     4.2.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10
129     4.3.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . . 10
130     4.4.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11
131   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
132     5.1.  Authenticaton Scheme Registry  . . . . . . . . . . . . . . 11
133     5.2.  Status Code Registration . . . . . . . . . . . . . . . . . 11
134     5.3.  Header Field Registration  . . . . . . . . . . . . . . . . 11
135   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
136     6.1.  Authentication Credentials and Idle Clients  . . . . . . . 12
137   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
138   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
139     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
140     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
141   Appendix A.  Changes from RFCs 2616 and 2617 . . . . . . . . . . . 14
142   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 15
143   Appendix C.  Change Log (to be removed by RFC Editor before
144                publication)  . . . . . . . . . . . . . . . . . . . . 15
145     C.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 15
146     C.2.  Since draft-ietf-httpbis-p7-auth-00  . . . . . . . . . . . 16
147     C.3.  Since draft-ietf-httpbis-p7-auth-01  . . . . . . . . . . . 16
148     C.4.  Since draft-ietf-httpbis-p7-auth-02  . . . . . . . . . . . 16
149     C.5.  Since draft-ietf-httpbis-p7-auth-03  . . . . . . . . . . . 16
150     C.6.  Since draft-ietf-httpbis-p7-auth-04  . . . . . . . . . . . 16
151     C.7.  Since draft-ietf-httpbis-p7-auth-05  . . . . . . . . . . . 16
152     C.8.  Since draft-ietf-httpbis-p7-auth-06  . . . . . . . . . . . 17
153     C.9.  Since draft-ietf-httpbis-p7-auth-07  . . . . . . . . . . . 17
154     C.10. Since draft-ietf-httpbis-p7-auth-08  . . . . . . . . . . . 17
155     C.11. Since draft-ietf-httpbis-p7-auth-09  . . . . . . . . . . . 17
156     C.12. Since draft-ietf-httpbis-p7-auth-10  . . . . . . . . . . . 17
157     C.13. Since draft-ietf-httpbis-p7-auth-11  . . . . . . . . . . . 17
158     C.14. Since draft-ietf-httpbis-p7-auth-12  . . . . . . . . . . . 18
159     C.15. Since draft-ietf-httpbis-p7-auth-13  . . . . . . . . . . . 18
160     C.16. Since draft-ietf-httpbis-p7-auth-14  . . . . . . . . . . . 18
161     C.17. Since draft-ietf-httpbis-p7-auth-15  . . . . . . . . . . . 18
162   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
163
164
165
166
167Fielding, et al.        Expires February 25, 2012               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7                 August 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 [Part1]:
218
219
220
221
222
223Fielding, et al.        Expires February 25, 2012               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7                 August 2011
226
227
228     BWS           = <BWS, defined in [Part1], Section 1.2.2>
229     OWS           = <OWS, defined in [Part1], Section 1.2.2>
230     quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
231     token         = <token, defined in [Part1], Section 3.2.3>
232
2332.  Access Authentication Framework
234
2352.1.  Challenge and Response
236
237   HTTP provides a simple challenge-response authentication mechanism
238   that can be used by a server to challenge a client request and by a
239   client to provide authentication information.  It uses an extensible,
240   case-insensitive token to identify the authentication scheme,
241   followed by additional information necessary for achieving
242   authentication via that scheme.  The latter can either be a comma-
243   separated list of attribute-value pairs or a single sequence of
244   characters capable of holding base64-encoded information.
245
246     auth-scheme    = token
247
248     auth-param     = token BWS "=" BWS ( token / quoted-string )
249
250     b64token       = 1*( ALPHA / DIGIT /
251                          "-" / "." / "_" / "~" / "+" / "/" ) *"="
252
253   The "b64token" syntax allows the 66 unreserved URI characters
254   ([RFC3986]), plus a few others, so that it can hold a base64,
255   base64url (URL and filename safe alphabet), base32, or base16 (hex)
256   encoding, with or without padding, but excluding whitespace
257   ([RFC4648]).
258
259   The 401 (Unauthorized) response message is used by an origin server
260   to challenge the authorization of a user agent.  This response MUST
261   include a WWW-Authenticate header field containing at least one
262   challenge applicable to the requested resource.
263
264   The 407 (Proxy Authentication Required) response message is used by a
265   proxy to challenge the authorization of a client and MUST include a
266   Proxy-Authenticate header field containing at least one challenge
267   applicable to the proxy for the requested resource.
268
269     challenge   = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
270
271      Note: User agents will need to take special care in parsing the
272      WWW-Authenticate and Proxy-Authenticate header field values
273      because they can contain more than one challenge, or if more than
274      one of each is provided, since the contents of a challenge can
275      itself contain a comma-separated list of authentication
276
277
278
279Fielding, et al.        Expires February 25, 2012               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7                 August 2011
282
283
284      parameters.
285
286      Note: Many browsers fail to parse challenges containing unknown
287      schemes.  A workaround for this problem is to list well-supported
288      schemes (such as "basic") first.
289
290   A user agent that wishes to authenticate itself with an origin server
291   -- usually, but not necessarily, after receiving a 401 (Unauthorized)
292   -- MAY do so by including an Authorization header field with the
293   request.
294
295   A client that wishes to authenticate itself with a proxy -- usually,
296   but not necessarily, after receiving a 407 (Proxy Authentication
297   Required) -- MAY do so by including a Proxy-Authorization header
298   field with the request.
299
300   Both the Authorization field value and the Proxy-Authorization field
301   value consist of credentials containing the authentication
302   information of the client for the realm of the resource being
303   requested.  The user agent MUST choose to use one of the challenges
304   with the strongest auth-scheme it understands and request credentials
305   from the user based upon that challenge.
306
307     credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
308
309   If the origin server does not wish to accept the credentials sent
310   with a request, it SHOULD return a 401 (Unauthorized) response.  The
311   response MUST include a WWW-Authenticate header field containing at
312   least one (possibly new) challenge applicable to the requested
313   resource.
314
315   If a proxy does not accept the credentials sent with a request, it
316   SHOULD return a 407 (Proxy Authentication Required).  The response
317   MUST include a Proxy-Authenticate header field containing a (possibly
318   new) challenge applicable to the proxy for the requested resource.
319
320   The HTTP protocol does not restrict applications to this simple
321   challenge-response mechanism for access authentication.  Additional
322   mechanisms MAY be used, such as encryption at the transport level or
323   via message encapsulation, and with additional header fields
324   specifying authentication information.  However, such additional
325   mechanisms are not defined by this specification.
326
327   Proxies MUST forward the WWW-Authenticate and Authorization headers
328   unmodified and follow the rules found in Section 4.1.
329
330
331
332
333
334
335Fielding, et al.        Expires February 25, 2012               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7                 August 2011
338
339
3402.2.  Protection Space (Realm)
341
342   The authentication parameter realm is reserved for use by
343   authentication schemes that wish to indicate the scope of protection:
344
345     realm       = "realm" BWS "=" BWS realm-value
346     realm-value = quoted-string
347
348   A protection space is defined by the canonical root URI (the scheme
349   and authority components of the effective request URI; see Section
350   4.3 of [Part1]) of the server being accessed, in combination with the
351   realm value if present.  These realms allow the protected resources
352   on a server to be partitioned into a set of protection spaces, each
353   with its own authentication scheme and/or authorization database.
354   The realm value is a string, generally assigned by the origin server,
355   which can have additional semantics specific to the authentication
356   scheme.  Note that there can be multiple challenges with the same
357   auth-scheme but different realms.
358
359   The protection space determines the domain over which credentials can
360   be automatically applied.  If a prior request has been authorized,
361   the same credentials MAY be reused for all other requests within that
362   protection space for a period of time determined by the
363   authentication scheme, parameters, and/or user preference.  Unless
364   otherwise defined by the authentication scheme, a single protection
365   space cannot extend outside the scope of its server.
366
3672.3.  Authentication Scheme Registry
368
369   The HTTP Authentication Scheme Registry defines the name space for
370   the authentication schemes in challenges and credentials.
371
372   Registrations MUST include the following fields:
373
374   o  Authentication Scheme Name
375
376   o  Pointer to specification text
377
378   o  Notes (optional)
379
380   Values to be added to this name space are subject to IETF review
381   ([RFC5226], Section 4.1).
382
383   The registry itself is maintained at
384   <http://www.iana.org/assignments/http-authschemes>.
385
386
387
388
389
390
391Fielding, et al.        Expires February 25, 2012               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7                 August 2011
394
395
3962.3.1.  Considerations for New Authentication Schemes
397
398   There are certain aspects of the HTTP Authentication Framework that
399   put constraints on how new authentication schemes can work:
400
401   o  Authentication schemes need to be compatible with the inherent
402      constraints of HTTP; for instance, that messages need to keep
403      their semantics when inspected in isolation, thus an
404      authentication scheme can not bind information to the TCP session
405      over which the message was received (see Section 2.2 of [Part1]).
406
407   o  The authentication parameter "realm" is reserved for defining
408      Protection Spaces as defined in Section 2.2.  New schemes MUST NOT
409      use it in a way incompatible with that definition.
410
411   o  The "b64token" notation was introduced for compatibility with
412      existing authentication schemes and can only be used once per
413      challenge/credentials.  New schemes thus ought to use the "auth-
414      param" syntax instead, because otherwise future extensions will be
415      impossible.
416
417   o  Authentication schemes need to document whether they are usable in
418      origin-server authentication (i.e., using WWW-Authenticate),
419      and/or proxy authentication (i.e., using Proxy-Authenticate).
420
421   o  The credentials carried in an Authorization header field are
422      specific to the User Agent, and therefore have the same effect on
423      HTTP caches as the "private" Cache-Control response directive,
424      within the scope of the request they appear in.
425
426      Therefore, new authentication schemes which choose not to carry
427      credentials in the Authorization header (e.g., using a newly
428      defined header) will need to explicitly disallow caching, by
429      mandating the use of either Cache-Control request directives
430      (e.g., "no-store") or response directives (e.g., "private").
431
4323.  Status Code Definitions
433
4343.1.  401 Unauthorized
435
436   The request requires user authentication.  The response MUST include
437   a WWW-Authenticate header field (Section 4.4) containing a challenge
438   applicable to the target resource.  The client MAY repeat the request
439   with a suitable Authorization header field (Section 4.1).  If the
440   request already included Authorization credentials, then the 401
441   response indicates that authorization has been refused for those
442   credentials.  If the 401 response contains the same challenge as the
443   prior response, and the user agent has already attempted
444
445
446
447Fielding, et al.        Expires February 25, 2012               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7                 August 2011
450
451
452   authentication at least once, then the user SHOULD be presented the
453   representation that was given in the response, since that
454   representation might include relevant diagnostic information.
455
4563.2.  407 Proxy Authentication Required
457
458   This code is similar to 401 (Unauthorized), but indicates that the
459   client ought to first authenticate itself with the proxy.  The proxy
460   MUST return a Proxy-Authenticate header field (Section 4.2)
461   containing a challenge applicable to the proxy for the target
462   resource.  The client MAY repeat the request with a suitable Proxy-
463   Authorization header field (Section 4.3).
464
4654.  Header Field Definitions
466
467   This section defines the syntax and semantics of HTTP/1.1 header
468   fields related to authentication.
469
4704.1.  Authorization
471
472   The "Authorization" header field allows a user agent to authenticate
473   itself with a server -- usually, but not necessarily, after receiving
474   a 401 (Unauthorized) response.  Its value consists of credentials
475   containing information of the user agent for the realm of the
476   resource being requested.
477
478     Authorization = credentials
479
480   If a request is authenticated and a realm specified, the same
481   credentials SHOULD be valid for all other requests within this realm
482   (assuming that the authentication scheme itself does not require
483   otherwise, such as credentials that vary according to a challenge
484   value or using synchronized clocks).
485
486   When a shared cache (see Section 1.2 of [Part6]) receives a request
487   containing an Authorization field, it MUST NOT return the
488   corresponding response as a reply to any other request, unless one of
489   the following specific exceptions holds:
490
491   1.  If the response includes the "s-maxage" cache-control directive,
492       the cache MAY use that response in replying to a subsequent
493       request.  But (if the specified maximum age has passed) a proxy
494       cache MUST first revalidate it with the origin server, using the
495       header fields from the new request to allow the origin server to
496       authenticate the new request.  (This is the defined behavior for
497       s-maxage.)  If the response includes "s-maxage=0", the proxy MUST
498       always revalidate it before re-using it.
499
500
501
502
503Fielding, et al.        Expires February 25, 2012               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7                 August 2011
506
507
508   2.  If the response includes the "must-revalidate" cache-control
509       directive, the cache MAY use that response in replying to a
510       subsequent request.  But if the response is stale, all caches
511       MUST first revalidate it with the origin server, using the header
512       fields from the new request to allow the origin server to
513       authenticate the new request.
514
515   3.  If the response includes the "public" cache-control directive, it
516       MAY be returned in reply to any subsequent request.
517
5184.2.  Proxy-Authenticate
519
520   The "Proxy-Authenticate" header field consists of a challenge that
521   indicates the authentication scheme and parameters applicable to the
522   proxy for this effective request URI (Section 4.3 of [Part1]).  It
523   MUST be included as part of a 407 (Proxy Authentication Required)
524   response.
525
526     Proxy-Authenticate = 1#challenge
527
528   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
529   only to the current connection and SHOULD NOT be passed on to
530   downstream clients.  However, an intermediate proxy might need to
531   obtain its own credentials by requesting them from the downstream
532   client, which in some circumstances will appear as if the proxy is
533   forwarding the Proxy-Authenticate header field.
534
5354.3.  Proxy-Authorization
536
537   The "Proxy-Authorization" header field allows the client to identify
538   itself (or its user) to a proxy which requires authentication.  Its
539   value consists of credentials containing the authentication
540   information of the user agent for the proxy and/or realm of the
541   resource being requested.
542
543     Proxy-Authorization = credentials
544
545   Unlike Authorization, the Proxy-Authorization header field applies
546   only to the next outbound proxy that demanded authentication using
547   the Proxy-Authenticate field.  When multiple proxies are used in a
548   chain, the Proxy-Authorization header field is consumed by the first
549   outbound proxy that was expecting to receive credentials.  A proxy
550   MAY relay the credentials from the client request to the next proxy
551   if that is the mechanism by which the proxies cooperatively
552   authenticate a given request.
553
554
555
556
557
558
559Fielding, et al.        Expires February 25, 2012              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7                 August 2011
562
563
5644.4.  WWW-Authenticate
565
566   The "WWW-Authenticate" header field consists of at least one
567   challenge that indicates the authentication scheme(s) and parameters
568   applicable to the effective request URI (Section 4.3 of [Part1]).
569
570   It MUST be included in 401 (Unauthorized) response messages and MAY
571   be included in other response messages to indicate that supplying
572   credentials (or different credentials) might affect the response.
573
574     WWW-Authenticate = 1#challenge
575
576   User agents are advised to take special care in parsing the WWW-
577   Authenticate field value as it might contain more than one challenge,
578   or if more than one WWW-Authenticate header field is provided, the
579   contents of a challenge itself can contain a comma-separated list of
580   authentication parameters.
581
5825.  IANA Considerations
583
5845.1.  Authenticaton Scheme Registry
585
586   The registration procedure for HTTP Authentication Schemes is defined
587   by Section 2.3 of this document.
588
589   The HTTP Method Authentication Scheme shall be created at
590   <http://www.iana.org/assignments/http-authschemes>.
591
5925.2.  Status Code Registration
593
594   The HTTP Status Code Registry located at
595   <http://www.iana.org/assignments/http-status-codes> shall be updated
596   with the registrations below:
597
598   +-------+-------------------------------+-------------+
599   | Value | Description                   | Reference   |
600   +-------+-------------------------------+-------------+
601   | 401   | Unauthorized                  | Section 3.1 |
602   | 407   | Proxy Authentication Required | Section 3.2 |
603   +-------+-------------------------------+-------------+
604
6055.3.  Header Field Registration
606
607   The Message Header Field Registry located at <http://www.iana.org/
608   assignments/message-headers/message-header-index.html> shall be
609   updated with the permanent registrations below (see [RFC3864]):
610
611
612
613
614
615Fielding, et al.        Expires February 25, 2012              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7                 August 2011
618
619
620   +---------------------+----------+----------+-------------+
621   | Header Field Name   | Protocol | Status   | Reference   |
622   +---------------------+----------+----------+-------------+
623   | Authorization       | http     | standard | Section 4.1 |
624   | Proxy-Authenticate  | http     | standard | Section 4.2 |
625   | Proxy-Authorization | http     | standard | Section 4.3 |
626   | WWW-Authenticate    | http     | standard | Section 4.4 |
627   +---------------------+----------+----------+-------------+
628
629   The change controller is: "IETF (iesg@ietf.org) - Internet
630   Engineering Task Force".
631
6326.  Security Considerations
633
634   This section is meant to inform application developers, information
635   providers, and users of the security limitations in HTTP/1.1 as
636   described by this document.  The discussion does not include
637   definitive solutions to the problems revealed, though it does make
638   some suggestions for reducing security risks.
639
6406.1.  Authentication Credentials and Idle Clients
641
642   Existing HTTP clients and user agents typically retain authentication
643   information indefinitely.  HTTP/1.1 does not provide a method for a
644   server to direct clients to discard these cached credentials.  This
645   is a significant defect that requires further extensions to HTTP.
646   Circumstances under which credential caching can interfere with the
647   application's security model include but are not limited to:
648
649   o  Clients which have been idle for an extended period following
650      which the server might wish to cause the client to reprompt the
651      user for credentials.
652
653   o  Applications which include a session termination indication (such
654      as a "logout" or "commit" button on a page) after which the server
655      side of the application "knows" that there is no further reason
656      for the client to retain the credentials.
657
658   This is currently under separate study.  There are a number of work-
659   arounds to parts of this problem, and we encourage the use of
660   password protection in screen savers, idle time-outs, and other
661   methods which mitigate the security problems inherent in this
662   problem.  In particular, user agents which cache credentials are
663   encouraged to provide a readily accessible mechanism for discarding
664   cached credentials under user control.
665
666
667
668
669
670
671Fielding, et al.        Expires February 25, 2012              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7                 August 2011
674
675
6767.  Acknowledgments
677
678   This specification takes over the definition of the HTTP
679   Authentication Framework, previously defined in RFC 2617.  We thank
680   John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D.
681   Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for
682   their work on that specification.  See Section 6 of [RFC2617] for
683   further acknowledgements.
684
685   See Section 12 of [Part1] for the Acknowledgments related to this
686   document revision.
687
6888.  References
689
6908.1.  Normative References
691
692   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
693              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
694              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
695              and Message Parsing", draft-ietf-httpbis-p1-messaging-16
696              (work in progress), August 2011.
697
698   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
699              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
700              Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
701              6: Caching", draft-ietf-httpbis-p6-cache-16 (work in
702              progress), August 2011.
703
704   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
705              Requirement Levels", BCP 14, RFC 2119, March 1997.
706
707   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
708              Specifications: ABNF", STD 68, RFC 5234, January 2008.
709
7108.2.  Informative References
711
712   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
713              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
714              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
715
716   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
717              Leach, P., Luotonen, A., and L. Stewart, "HTTP
718              Authentication: Basic and Digest Access Authentication",
719              RFC 2617, June 1999.
720
721   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
722              Procedures for Message Header Fields", BCP 90, RFC 3864,
723              September 2004.
724
725
726
727Fielding, et al.        Expires February 25, 2012              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 7                 August 2011
730
731
732   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
733              Resource Identifier (URI): Generic Syntax", STD 66,
734              RFC 3986, January 2005.
735
736   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
737              Encodings", RFC 4648, October 2006.
738
739   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
740              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
741              May 2008.
742
743Appendix A.  Changes from RFCs 2616 and 2617
744
745   The "realm" parameter isn't required anymore in general;
746   consequently, the ABNF allows challenges without any auth parameters.
747   (Section 2)
748
749   The "b64token" alternative to auth-param lists has been added for
750   consistency with legacy authentication schemes such as "Basic".
751   (Section 2)
752
753   Change ABNF productions for header fields to only define the field
754   value.  (Section 4)
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783Fielding, et al.        Expires February 25, 2012              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 7                 August 2011
786
787
788Appendix B.  Collected ABNF
789
790   Authorization = credentials
791
792   BWS = <BWS, defined in [Part1], Section 1.2.2>
793
794   OWS = <OWS, defined in [Part1], Section 1.2.2>
795
796   Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
797    challenge ] )
798   Proxy-Authorization = credentials
799
800   WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
801    ] )
802
803   auth-param = token BWS "=" BWS ( token / quoted-string )
804   auth-scheme = token
805
806   b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
807    *"="
808
809   challenge = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) *(
810    OWS "," [ OWS auth-param ] ) ] ) ]
811   credentials = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param )
812    *( OWS "," [ OWS auth-param ] ) ] ) ]
813
814   quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
815
816   realm = "realm" BWS "=" BWS realm-value
817   realm-value = quoted-string
818
819   token = <token, defined in [Part1], Section 3.2.3>
820
821   ABNF diagnostics:
822
823   ; Authorization defined but not used
824   ; Proxy-Authenticate defined but not used
825   ; Proxy-Authorization defined but not used
826   ; WWW-Authenticate defined but not used
827   ; realm defined but not used
828
829Appendix C.  Change Log (to be removed by RFC Editor before publication)
830
831C.1.  Since RFC 2616
832
833   Extracted relevant partitions from [RFC2616].
834
835
836
837
838
839Fielding, et al.        Expires February 25, 2012              [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 7                 August 2011
842
843
844C.2.  Since draft-ietf-httpbis-p7-auth-00
845
846   Closed issues:
847
848   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
849      Informative references"
850
851C.3.  Since draft-ietf-httpbis-p7-auth-01
852
853   Ongoing work on ABNF conversion
854   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
855
856   o  Explicitly import BNF rules for "challenge" and "credentials" from
857      RFC2617.
858
859   o  Add explicit references to BNF syntax and rules imported from
860      other parts of the specification.
861
862C.4.  Since draft-ietf-httpbis-p7-auth-02
863
864   Ongoing work on IANA Message Header Field Registration
865   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
866
867   o  Reference RFC 3984, and update header field registrations for
868      header fields defined in this document.
869
870C.5.  Since draft-ietf-httpbis-p7-auth-03
871
872   None.
873
874C.6.  Since draft-ietf-httpbis-p7-auth-04
875
876   Ongoing work on ABNF conversion
877   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
878
879   o  Use "/" instead of "|" for alternatives.
880
881   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
882      whitespace ("OWS") and required whitespace ("RWS").
883
884   o  Rewrite ABNFs to spell out whitespace rules, factor out header
885      field value format definitions.
886
887C.7.  Since draft-ietf-httpbis-p7-auth-05
888
889   Final work on ABNF conversion
890   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
891
892
893
894
895Fielding, et al.        Expires February 25, 2012              [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 7                 August 2011
898
899
900   o  Add appendix containing collected and expanded ABNF, reorganize
901      ABNF introduction.
902
903C.8.  Since draft-ietf-httpbis-p7-auth-06
904
905   None.
906
907C.9.  Since draft-ietf-httpbis-p7-auth-07
908
909   Closed issues:
910
911   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
912      registrations for optional status codes"
913
914C.10.  Since draft-ietf-httpbis-p7-auth-08
915
916   No significant changes.
917
918C.11.  Since draft-ietf-httpbis-p7-auth-09
919
920   Partly resolved issues:
921
922   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
923      requested resource's URI"
924
925C.12.  Since draft-ietf-httpbis-p7-auth-10
926
927   None.
928
929C.13.  Since draft-ietf-httpbis-p7-auth-11
930
931   Closed issues:
932
933   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/130>: "introduction
934      to part 7 is work-in-progress"
935
936   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/195>: "auth-param
937      syntax"
938
939   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
940      Classification"
941
942   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/237>: "absorbing the
943      auth framework from 2617"
944
945   Partly resolved issues:
946
947
948
949
950
951Fielding, et al.        Expires February 25, 2012              [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 7                 August 2011
954
955
956   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/141>: "should we
957      have an auth scheme registry"
958
959C.14.  Since draft-ietf-httpbis-p7-auth-12
960
961   None.
962
963C.15.  Since draft-ietf-httpbis-p7-auth-13
964
965   Closed issues:
966
967   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
968      ABNFs for header fields"
969
970C.16.  Since draft-ietf-httpbis-p7-auth-14
971
972   None.
973
974C.17.  Since draft-ietf-httpbis-p7-auth-15
975
976   Closed issues:
977
978   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/78>: "Relationship
979      between 401, Authorization and WWW-Authenticate"
980
981   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/177>: "Realm
982      required on challenges"
983
984   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/195>: "auth-param
985      syntax"
986
987   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/257>:
988      "Considerations for new authentications schemes"
989
990   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/287>: "LWS in auth-
991      param ABNF"
992
993   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/309>: "credentials
994      ABNF missing SP (still using implied LWS?)"
995
996Index
997
998   4
999      401 Unauthorized (status code)  8
1000      407 Proxy Authentication Required (status code)  9
1001
1002   A
1003      auth-param  5
1004
1005
1006
1007Fielding, et al.        Expires February 25, 2012              [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 7                 August 2011
1010
1011
1012      auth-scheme  5
1013      Authorization header field  9
1014
1015   B
1016      b64token  5
1017
1018   C
1019      challenge  5
1020      credentials  6
1021
1022   G
1023      Grammar
1024         auth-param  5
1025         auth-scheme  5
1026         Authorization  9
1027         b64token  5
1028         challenge  5
1029         credentials  6
1030         Proxy-Authenticate  10
1031         Proxy-Authorization  10
1032         realm  7
1033         WWW-Authenticate  11
1034
1035   H
1036      Header Fields
1037         Authorization  9
1038         Proxy-Authenticate  10
1039         Proxy-Authorization  10
1040         WWW-Authenticate  11
1041
1042   P
1043      Protection Space  7
1044      Proxy-Authenticate header field  10
1045      Proxy-Authorization header field  10
1046
1047   R
1048      Realm  7
1049      realm  7
1050      realm-value  7
1051
1052   S
1053      Status Codes
1054         401 Unauthorized  8
1055         407 Proxy Authentication Required  9
1056
1057   W
1058      WWW-Authenticate header field  11
1059
1060
1061
1062
1063Fielding, et al.        Expires February 25, 2012              [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 7                 August 2011
1066
1067
1068Authors' Addresses
1069
1070   Roy T. Fielding (editor)
1071   Adobe Systems Incorporated
1072   345 Park Ave
1073   San Jose, CA  95110
1074   USA
1075
1076   EMail: fielding@gbiv.com
1077   URI:   http://roy.gbiv.com/
1078
1079
1080   Jim Gettys
1081   Alcatel-Lucent Bell Labs
1082   21 Oak Knoll Road
1083   Carlisle, MA  01741
1084   USA
1085
1086   EMail: jg@freedesktop.org
1087   URI:   http://gettys.wordpress.com/
1088
1089
1090   Jeffrey C. Mogul
1091   Hewlett-Packard Company
1092   HP Labs, Large Scale Systems Group
1093   1501 Page Mill Road, MS 1177
1094   Palo Alto, CA  94304
1095   USA
1096
1097   EMail: JeffMogul@acm.org
1098
1099
1100   Henrik Frystyk Nielsen
1101   Microsoft Corporation
1102   1 Microsoft Way
1103   Redmond, WA  98052
1104   USA
1105
1106   EMail: henrikn@microsoft.com
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119Fielding, et al.        Expires February 25, 2012              [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 7                 August 2011
1122
1123
1124   Larry Masinter
1125   Adobe Systems Incorporated
1126   345 Park Ave
1127   San Jose, CA  95110
1128   USA
1129
1130   EMail: LMM@acm.org
1131   URI:   http://larry.masinter.net/
1132
1133
1134   Paul J. Leach
1135   Microsoft Corporation
1136   1 Microsoft Way
1137   Redmond, WA  98052
1138
1139   EMail: paulle@microsoft.com
1140
1141
1142   Tim Berners-Lee
1143   World Wide Web Consortium
1144   MIT Computer Science and Artificial Intelligence Laboratory
1145   The Stata Center, Building 32
1146   32 Vassar Street
1147   Cambridge, MA  02139
1148   USA
1149
1150   EMail: timbl@w3.org
1151   URI:   http://www.w3.org/People/Berners-Lee/
1152
1153
1154   Yves Lafon (editor)
1155   World Wide Web Consortium
1156   W3C / ERCIM
1157   2004, rte des Lucioles
1158   Sophia-Antipolis, AM  06902
1159   France
1160
1161   EMail: ylafon@w3.org
1162   URI:   http://www.raubacapeu.net/people/yves/
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175Fielding, et al.        Expires February 25, 2012              [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 7                 August 2011
1178
1179
1180   Julian F. Reschke (editor)
1181   greenbytes GmbH
1182   Hafenweg 16
1183   Muenster, NW  48155
1184   Germany
1185
1186   Phone: +49 251 2807760
1187   Fax:   +49 251 2807761
1188   EMail: julian.reschke@greenbytes.de
1189   URI:   http://greenbytes.de/tech/webdav/
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231Fielding, et al.        Expires February 25, 2012              [Page 22]
1232
Note: See TracBrowser for help on using the repository browser.