source: draft-ietf-httpbis/18/draft-ietf-httpbis-p7-auth-18.txt @ 1499

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

prepare for publication of -18 on Jan 04.

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