source: draft-ietf-httpbis/17/draft-ietf-httpbis-p7-auth-17.txt @ 1529

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

Prepare publication of -17.

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