source: draft-ietf-httpbis/20/draft-ietf-httpbis-p7-auth-20.txt @ 1807

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

Prepare release of -20 drafts

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 39.4 KB
RevLine 
[1807]1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                                     Adobe
6Obsoletes: 2616 (if approved)                              Y. Lafon, Ed.
7Updates: 2617 (if approved)                                          W3C
8Intended status: Standards Track                         J. Reschke, Ed.
9Expires: January 17, 2013                                     greenbytes
10                                                           July 16, 2012
11
12
13                    HTTP/1.1, part 7: Authentication
14                     draft-ietf-httpbis-p7-auth-20
15
16Abstract
17
18   The Hypertext Transfer Protocol (HTTP) is an application-level
19   protocol for distributed, collaborative, hypermedia information
20   systems.  HTTP has been in use by the World Wide Web global
21   information initiative since 1990.  This document is Part 7 of the
22   seven-part specification that defines the protocol referred to as
23   "HTTP/1.1" and, taken together, obsoletes RFC 2616.
24
25   Part 7 defines the HTTP Authentication framework.
26
27Editorial Note (To be removed by RFC Editor)
28
29   Discussion of this draft takes place on the HTTPBIS working group
30   mailing list (ietf-http-wg@w3.org), which is archived at
31   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
32
33   The current issues list is at
34   <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
35   documents (including fancy diffs) can be found at
36   <http://tools.ietf.org/wg/httpbis/>.
37
38   The changes in this draft are summarized in Appendix D.1.
39
40Status of This Memo
41
42   This Internet-Draft is submitted in full conformance with the
43   provisions of BCP 78 and BCP 79.
44
45   Internet-Drafts are working documents of the Internet Engineering
46   Task Force (IETF).  Note that other groups may also distribute
47   working documents as Internet-Drafts.  The list of current Internet-
48   Drafts is at http://datatracker.ietf.org/drafts/current/.
49
50   Internet-Drafts are draft documents valid for a maximum of six months
51   and may be updated, replaced, or obsoleted by other documents at any
52
53
54
55Fielding, et al.        Expires January 17, 2013                [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7                   July 2012
58
59
60   time.  It is inappropriate to use Internet-Drafts as reference
61   material or to cite them other than as "work in progress."
62
63   This Internet-Draft will expire on January 17, 2013.
64
65Copyright Notice
66
67   Copyright (c) 2012 IETF Trust and the persons identified as the
68   document authors.  All rights reserved.
69
70   This document is subject to BCP 78 and the IETF Trust's Legal
71   Provisions Relating to IETF Documents
72   (http://trustee.ietf.org/license-info) in effect on the date of
73   publication of this document.  Please review these documents
74   carefully, as they describe your rights and restrictions with respect
75   to this document.  Code Components extracted from this document must
76   include Simplified BSD License text as described in Section 4.e of
77   the Trust Legal Provisions and are provided without warranty as
78   described in the Simplified BSD License.
79
80   This document may contain material from IETF Documents or IETF
81   Contributions published or made publicly available before November
82   10, 2008.  The person(s) controlling the copyright in some of this
83   material may not have granted the IETF Trust the right to allow
84   modifications of such material outside the IETF Standards Process.
85   Without obtaining an adequate license from the person(s) controlling
86   the copyright in such materials, this document may not be modified
87   outside the IETF Standards Process, and derivative works of it may
88   not be created outside the IETF Standards Process, except to format
89   it for publication as an RFC or to translate it into languages other
90   than English.
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.        Expires January 17, 2013                [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7                   July 2012
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119     1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
120     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  5
121   2.  Access Authentication Framework  . . . . . . . . . . . . . . .  5
122     2.1.  Challenge and Response . . . . . . . . . . . . . . . . . .  5
123     2.2.  Protection Space (Realm) . . . . . . . . . . . . . . . . .  7
124     2.3.  Authentication Scheme Registry . . . . . . . . . . . . . .  8
125       2.3.1.  Considerations for New Authentication Schemes  . . . .  8
126   3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  9
127     3.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  9
128     3.2.  407 Proxy Authentication Required  . . . . . . . . . . . . 10
129   4.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 10
130     4.1.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 10
131     4.2.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 11
132     4.3.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . . 11
133     4.4.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 12
134   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
135     5.1.  Authentication Scheme Registry . . . . . . . . . . . . . . 12
136     5.2.  Status Code Registration . . . . . . . . . . . . . . . . . 13
137     5.3.  Header Field Registration  . . . . . . . . . . . . . . . . 13
138   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
139     6.1.  Authentication Credentials and Idle Clients  . . . . . . . 13
140     6.2.  Protection Spaces  . . . . . . . . . . . . . . . . . . . . 14
141   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
142   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
143     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
144     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
145   Appendix A.  Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16
146   Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 16
147   Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 17
148   Appendix D.  Change Log (to be removed by RFC Editor before
149                publication)  . . . . . . . . . . . . . . . . . . . . 17
150     D.1.  Since draft-ietf-httpbis-p7-auth-19  . . . . . . . . . . . 17
151   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167Fielding, et al.        Expires January 17, 2013                [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7                   July 2012
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
176   ([RFC2616]), plus the general framework for HTTP authentication, as
177   previously defined in "HTTP Authentication: Basic and Digest Access
178   Authentication" ([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 specification targets conformance criteria according to the role
193   of a participant in HTTP communication.  Hence, HTTP requirements are
194   placed on senders, recipients, clients, servers, user agents,
195   intermediaries, origin servers, proxies, gateways, or caches,
196   depending on what behavior is being constrained by the requirement.
197   See Section 2 of [Part1] for definitions of these terms.
198
199   The verb "generate" is used instead of "send" where a requirement
200   differentiates between creating a protocol element and merely
201   forwarding a received element downstream.
202
203   An implementation is considered conformant if it complies with all of
204   the requirements associated with the roles it partakes in HTTP.  Note
205   that SHOULD-level requirements are relevant here, unless one of the
206   documented exceptions is applicable.
207
208   This document also uses ABNF to define valid protocol elements
209   (Section 1.2).  In addition to the prose requirements placed upon
210   them, senders MUST NOT generate protocol elements that do not match
211   the grammar defined by the ABNF rules for those protocol elements
212   that are applicable to the sender's role.  If a received protocol
213   element is processed, the recipient MUST be able to parse any value
214   that would match the ABNF rules for that protocol element, excluding
215   only those rules not applicable to the recipient's role.
216
217   Unless noted otherwise, a recipient MAY attempt to recover a usable
218   protocol element from an invalid construct.  HTTP does not define
219   specific error handling mechanisms except when they have a direct
220
221
222
223Fielding, et al.        Expires January 17, 2013                [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7                   July 2012
226
227
228   impact on security, since different applications of the protocol
229   require different error handling strategies.  For example, a Web
230   browser might wish to transparently recover from a response where the
231   Location header field doesn't parse according to the ABNF, whereas a
232   systems control client might consider any form of error recovery to
233   be dangerous.
234
2351.2.  Syntax Notation
236
237   This specification uses the Augmented Backus-Naur Form (ABNF)
238   notation of [RFC5234] with the list rule extension defined in Section
239   1.2 of [Part1].  Appendix B describes rules imported from other
240   documents.  Appendix C shows the collected ABNF with the list rule
241   expanded.
242
2432.  Access Authentication Framework
244
2452.1.  Challenge and Response
246
247   HTTP provides a simple challenge-response authentication mechanism
248   that can be used by a server to challenge a client request and by a
249   client to provide authentication information.  It uses an extensible,
250   case-insensitive token to identify the authentication scheme,
251   followed by additional information necessary for achieving
252   authentication via that scheme.  The latter can either be a comma-
253   separated list of parameters or a single sequence of characters
254   capable of holding base64-encoded information.
255
256   Parameters are name-value pairs where the name is matched case-
257   insensitively, and each parameter name MUST only occur once per
258   challenge.
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 January 17, 2013                [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7                   July 2012
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 clients 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   -- can 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) -- can 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 contain the client's credentials for the realm of the resource
316   being requested, based upon a challenge received from the server
317   (possibly at some point in the past).  When creating their values,
318   the user agent ought to do so by selecting the challenge with what it
319   considers to be the most secure auth-scheme that it understands,
320   obtaining credentials from the user as appropriate.
321
322     credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
323
324   Upon a request for a protected resource that omits credentials,
325   contains invalid credentials (e.g., a bad password) or partial
326   credentials (e.g., when the authentication scheme requires more than
327   one round trip), an origin server SHOULD return a 401 (Unauthorized)
328   response.  Such responses MUST include a WWW-Authenticate header
329   field containing at least one (possibly new) challenge applicable to
330   the requested resource.
331
332
333
334
335Fielding, et al.        Expires January 17, 2013                [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7                   July 2012
338
339
340   Likewise, upon a request that requires authentication by proxies that
341   omit credentials or contain invalid or partial credentials, a proxy
342   SHOULD return a 407 (Proxy Authentication Required) response.  Such
343   responses MUST include a Proxy-Authenticate header field containing a
344   (possibly new) challenge applicable to the proxy.
345
346   A server receiving credentials that are valid, but not adequate to
347   gain access, ought to respond with the 403 (Forbidden) status code
348   (Section 4.6.3 of [Part2]).
349
350   The HTTP protocol does not restrict applications to this simple
351   challenge-response mechanism for access authentication.  Additional
352   mechanisms MAY be used, such as encryption at the transport level or
353   via message encapsulation, and with additional header fields
354   specifying authentication information.  However, such additional
355   mechanisms are not defined by this specification.
356
357   Proxies MUST forward the WWW-Authenticate and Authorization header
358   fields unmodified and follow the rules found in Section 4.1.
359
3602.2.  Protection Space (Realm)
361
362   The authentication parameter realm is reserved for use by
363   authentication schemes that wish to indicate the scope of protection.
364
365   A protection space is defined by the canonical root URI (the scheme
366   and authority components of the effective request URI; see Section
367   5.5 of [Part1]) of the server being accessed, in combination with the
368   realm value if present.  These realms allow the protected resources
369   on a server to be partitioned into a set of protection spaces, each
370   with its own authentication scheme and/or authorization database.
371   The realm value is a string, generally assigned by the origin server,
372   which can have additional semantics specific to the authentication
373   scheme.  Note that there can be multiple challenges with the same
374   auth-scheme but different realms.
375
376   The protection space determines the domain over which credentials can
377   be automatically applied.  If a prior request has been authorized,
378   the same credentials MAY be reused for all other requests within that
379   protection space for a period of time determined by the
380   authentication scheme, parameters, and/or user preference.  Unless
381   otherwise defined by the authentication scheme, a single protection
382   space cannot extend outside the scope of its server.
383
384   For historical reasons, senders MUST only use the quoted-string
385   syntax.  Recipients might have to support both token and quoted-
386   string syntax for maximum interoperability with existing clients that
387   have been accepting both notations for a long time.
388
389
390
391Fielding, et al.        Expires January 17, 2013                [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7                   July 2012
394
395
3962.3.  Authentication Scheme Registry
397
398   The HTTP Authentication Scheme Registry defines the name space for
399   the authentication schemes in challenges and credentials.
400
401   Registrations MUST include the following fields:
402
403   o  Authentication Scheme Name
404
405   o  Pointer to specification text
406
407   o  Notes (optional)
408
409   Values to be added to this name space require IETF Review (see
410   [RFC5226], Section 4.1).
411
412   The registry itself is maintained at
413   <http://www.iana.org/assignments/http-authschemes>.
414
4152.3.1.  Considerations for New Authentication Schemes
416
417   There are certain aspects of the HTTP Authentication Framework that
418   put constraints on how new authentication schemes can work:
419
420   o  HTTP authentication is presumed to be stateless: all of the
421      information necessary to authenticate a request MUST be provided
422      in the request, rather than be dependent on the server remembering
423      prior requests.  Authentication based on, or bound to, the
424      underlying connection is outside the scope of this specification
425      and inherently flawed unless steps are taken to ensure that the
426      connection cannot be used by any party other than the
427      authenticated user (see Section 2.4 of [Part1]).
428
429   o  The authentication parameter "realm" is reserved for defining
430      Protection Spaces as defined in Section 2.2.  New schemes MUST NOT
431      use it in a way incompatible with that definition.
432
433   o  The "b64token" notation was introduced for compatibility with
434      existing authentication schemes and can only be used once per
435      challenge/credentials.  New schemes thus ought to use the "auth-
436      param" syntax instead, because otherwise future extensions will be
437      impossible.
438
439   o  The parsing of challenges and credentials is defined by this
440      specification, and cannot be modified by new authentication
441      schemes.  When the auth-param syntax is used, all parameters ought
442      to support both token and quoted-string syntax, and syntactical
443      constraints ought to be defined on the field value after parsing
444
445
446
447Fielding, et al.        Expires January 17, 2013                [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7                   July 2012
450
451
452      (i.e., quoted-string processing).  This is necessary so that
453      recipients can use a generic parser that applies to all
454      authentication schemes.
455
456      Note: The fact that the value syntax for the "realm" parameter is
457      restricted to quoted-string was a bad design choice not to be
458      repeated for new parameters.
459
460   o  Definitions of new schemes ought to define the treatment of
461      unknown extension parameters.  In general, a "must-ignore" rule is
462      preferable over "must-understand", because otherwise it will be
463      hard to introduce new parameters in the presence of legacy
464      recipients.  Furthermore, it's good to describe the policy for
465      defining new parameters (such as "update the specification", or
466      "use this registry").
467
468   o  Authentication schemes need to document whether they are usable in
469      origin-server authentication (i.e., using WWW-Authenticate),
470      and/or proxy authentication (i.e., using Proxy-Authenticate).
471
472   o  The credentials carried in an Authorization header field are
473      specific to the User Agent, and therefore have the same effect on
474      HTTP caches as the "private" Cache-Control response directive,
475      within the scope of the request they appear in.
476
477      Therefore, new authentication schemes which choose not to carry
478      credentials in the Authorization header field (e.g., using a newly
479      defined header field) will need to explicitly disallow caching, by
480      mandating the use of either Cache-Control request directives
481      (e.g., "no-store") or response directives (e.g., "private").
482
4833.  Status Code Definitions
484
4853.1.  401 Unauthorized
486
487   The request requires user authentication.  The response MUST include
488   a WWW-Authenticate header field (Section 4.4) containing a challenge
489   applicable to the target resource.  The client MAY repeat the request
490   with a suitable Authorization header field (Section 4.1).  If the
491   request already included Authorization credentials, then the 401
492   response indicates that authorization has been refused for those
493   credentials.  If the 401 response contains the same challenge as the
494   prior response, and the user agent has already attempted
495   authentication at least once, then the user SHOULD be presented the
496   representation that was given in the response, since that
497   representation might include relevant diagnostic information.
498
499
500
501
502
503Fielding, et al.        Expires January 17, 2013                [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7                   July 2012
506
507
5083.2.  407 Proxy Authentication Required
509
510   This code is similar to 401 (Unauthorized), but indicates that the
511   client ought to first authenticate itself with the proxy.  The proxy
512   MUST return a Proxy-Authenticate header field (Section 4.2)
513   containing a challenge applicable to the proxy for the target
514   resource.  The client MAY repeat the request with a suitable Proxy-
515   Authorization header field (Section 4.3).
516
5174.  Header Field Definitions
518
519   This section defines the syntax and semantics of HTTP/1.1 header
520   fields related to authentication.
521
5224.1.  Authorization
523
524   The "Authorization" header field allows a user agent to authenticate
525   itself with a server -- usually, but not necessarily, after receiving
526   a 401 (Unauthorized) response.  Its value consists of credentials
527   containing information of the user agent for the realm of the
528   resource being requested.
529
530     Authorization = credentials
531
532   If a request is authenticated and a realm specified, the same
533   credentials SHOULD be valid for all other requests within this realm
534   (assuming that the authentication scheme itself does not require
535   otherwise, such as credentials that vary according to a challenge
536   value or using synchronized clocks).
537
538   When a shared cache (see Section 1.2 of [Part6]) receives a request
539   containing an Authorization field, it MUST NOT return the
540   corresponding response as a reply to any other request, unless one of
541   the following specific exceptions holds:
542
543   1.  If the response includes the "s-maxage" cache-control directive,
544       the cache MAY use that response in replying to a subsequent
545       request.  But (if the specified maximum age has passed) a proxy
546       cache MUST first revalidate it with the origin server, using the
547       header fields from the new request to allow the origin server to
548       authenticate the new request.  (This is the defined behavior for
549       s-maxage.)  If the response includes "s-maxage=0", the proxy MUST
550       always revalidate it before re-using it.
551
552   2.  If the response includes the "must-revalidate" cache-control
553       directive, the cache MAY use that response in replying to a
554       subsequent request.  But if the response is stale, all caches
555       MUST first revalidate it with the origin server, using the header
556
557
558
559Fielding, et al.        Expires January 17, 2013               [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7                   July 2012
562
563
564       fields from the new request to allow the origin server to
565       authenticate the new request.
566
567   3.  If the response includes the "public" cache-control directive, it
568       MAY be returned in reply to any subsequent request.
569
5704.2.  Proxy-Authenticate
571
572   The "Proxy-Authenticate" header field consists of at least one
573   challenge that indicates the authentication scheme(s) and parameters
574   applicable to the proxy for this effective request URI (Section 5.5
575   of [Part1]).  It MUST be included as part of a 407 (Proxy
576   Authentication Required) response.
577
578     Proxy-Authenticate = 1#challenge
579
580   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
581   only to the current connection, and intermediaries SHOULD NOT forward
582   it to downstream clients.  However, an intermediate proxy might need
583   to obtain its own credentials by requesting them from the downstream
584   client, which in some circumstances will appear as if the proxy is
585   forwarding the Proxy-Authenticate header field.
586
587   Note that the parsing considerations for WWW-Authenticate apply to
588   this header field as well; see Section 4.4 for details.
589
5904.3.  Proxy-Authorization
591
592   The "Proxy-Authorization" header field allows the client to identify
593   itself (or its user) to a proxy which requires authentication.  Its
594   value consists of credentials containing the authentication
595   information of the user agent for the proxy and/or realm of the
596   resource being requested.
597
598     Proxy-Authorization = credentials
599
600   Unlike Authorization, the Proxy-Authorization header field applies
601   only to the next outbound proxy that demanded authentication using
602   the Proxy-Authenticate field.  When multiple proxies are used in a
603   chain, the Proxy-Authorization header field is consumed by the first
604   outbound proxy that was expecting to receive credentials.  A proxy
605   MAY relay the credentials from the client request to the next proxy
606   if that is the mechanism by which the proxies cooperatively
607   authenticate a given request.
608
609
610
611
612
613
614
615Fielding, et al.        Expires January 17, 2013               [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7                   July 2012
618
619
6204.4.  WWW-Authenticate
621
622   The "WWW-Authenticate" header field consists of at least one
623   challenge that indicates the authentication scheme(s) and parameters
624   applicable to the effective request URI (Section 5.5 of [Part1]).
625
626   It MUST be included in 401 (Unauthorized) response messages and MAY
627   be included in other response messages to indicate that supplying
628   credentials (or different credentials) might affect the response.
629
630     WWW-Authenticate = 1#challenge
631
632   User agents are advised to take special care in parsing the WWW-
633   Authenticate field value as it might contain more than one challenge,
634   or if more than one WWW-Authenticate header field is provided, the
635   contents of a challenge itself can contain a comma-separated list of
636   authentication parameters.
637
638   For instance:
639
640     WWW-Authenticate: Newauth realm="apps", type=1,
641                       title="Login to \"apps\"", Basic realm="simple"
642
643   This header field contains two challenges; one for the "Newauth"
644   scheme with a realm value of "apps", and two additional parameters
645   "type" and "title", and another one for the "Basic" scheme with a
646   realm value of "simple".
647
648      Note: The challenge grammar production uses the list syntax as
649      well.  Therefore, a sequence of comma, whitespace, and comma can
650      be considered both as applying to the preceding challenge, or to
651      be an empty entry in the list of challenges.  In practice, this
652      ambiguity does not affect the semantics of the header field value
653      and thus is harmless.
654
6555.  IANA Considerations
656
6575.1.  Authentication Scheme Registry
658
659   The registration procedure for HTTP Authentication Schemes is defined
660   by Section 2.3 of this document.
661
662   The HTTP Method Authentication Scheme shall be created at
663   <http://www.iana.org/assignments/http-authschemes>.
664
665
666
667
668
669
670
671Fielding, et al.        Expires January 17, 2013               [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7                   July 2012
674
675
6765.2.  Status Code Registration
677
678   The HTTP Status Code Registry located at
679   <http://www.iana.org/assignments/http-status-codes> shall be updated
680   with the registrations below:
681
682   +-------+-------------------------------+-------------+
683   | Value | Description                   | Reference   |
684   +-------+-------------------------------+-------------+
685   | 401   | Unauthorized                  | Section 3.1 |
686   | 407   | Proxy Authentication Required | Section 3.2 |
687   +-------+-------------------------------+-------------+
688
6895.3.  Header Field Registration
690
691   The Message Header Field Registry located at <http://www.iana.org/
692   assignments/message-headers/message-header-index.html> shall be
693   updated with the permanent registrations below (see [RFC3864]):
694
695   +---------------------+----------+----------+-------------+
696   | Header Field Name   | Protocol | Status   | Reference   |
697   +---------------------+----------+----------+-------------+
698   | Authorization       | http     | standard | Section 4.1 |
699   | Proxy-Authenticate  | http     | standard | Section 4.2 |
700   | Proxy-Authorization | http     | standard | Section 4.3 |
701   | WWW-Authenticate    | http     | standard | Section 4.4 |
702   +---------------------+----------+----------+-------------+
703
704   The change controller is: "IETF (iesg@ietf.org) - Internet
705   Engineering Task Force".
706
7076.  Security Considerations
708
709   This section is meant to inform application developers, information
710   providers, and users of the security limitations in HTTP/1.1 as
711   described by this document.  The discussion does not include
712   definitive solutions to the problems revealed, though it does make
713   some suggestions for reducing security risks.
714
7156.1.  Authentication Credentials and Idle Clients
716
717   Existing HTTP clients and user agents typically retain authentication
718   information indefinitely.  HTTP/1.1 does not provide a method for a
719   server to direct clients to discard these cached credentials.  This
720   is a significant defect that requires further extensions to HTTP.
721   Circumstances under which credential caching can interfere with the
722   application's security model include but are not limited to:
723
724
725
726
727Fielding, et al.        Expires January 17, 2013               [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 7                   July 2012
730
731
732   o  Clients which have been idle for an extended period following
733      which the server might wish to cause the client to reprompt the
734      user for credentials.
735
736   o  Applications which include a session termination indication (such
737      as a "logout" or "commit" button on a page) after which the server
738      side of the application "knows" that there is no further reason
739      for the client to retain the credentials.
740
741   This is currently under separate study.  There are a number of work-
742   arounds to parts of this problem, and we encourage the use of
743   password protection in screen savers, idle time-outs, and other
744   methods which mitigate the security problems inherent in this
745   problem.  In particular, user agents which cache credentials are
746   encouraged to provide a readily accessible mechanism for discarding
747   cached credentials under user control.
748
7496.2.  Protection Spaces
750
751   Authentication schemes that solely rely on the "realm" mechanism for
752   establishing a protection space will expose credentials to all
753   resources on a server.  Clients that have successfully made
754   authenticated requests with a resource can use the same
755   authentication credentials for other resources on the same server.
756   This makes it possible for a different resource to harvest
757   authentication credentials for other resources.
758
759   This is of particular concern when a server hosts resources for
760   multiple parties under the same canonical root URI (Section 2.2).
761   Possible mitigation strategies include restricting direct access to
762   authentication credentials (i.e., not making the content of the
763   Authorization request header field available), and separating
764   protection spaces by using a different host name for each party.
765
7667.  Acknowledgments
767
768   This specification takes over the definition of the HTTP
769   Authentication Framework, previously defined in RFC 2617.  We thank
770   John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D.
771   Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for
772   their work on that specification.  See Section 6 of [RFC2617] for
773   further acknowledgements.
774
775   See Section 9 of [Part1] for the Acknowledgments related to this
776   document revision.
777
7788.  References
779
780
781
782
783Fielding, et al.        Expires January 17, 2013               [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 7                   July 2012
786
787
7888.1.  Normative References
789
790   [Part1]    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
791              "HTTP/1.1, part 1: Message Routing and Syntax"",
792              draft-ietf-httpbis-p1-messaging-20 (work in progress),
793              July 2012.
794
795   [Part2]    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
796              "HTTP/1.1, part 2: Semantics and Payloads",
797              draft-ietf-httpbis-p2-semantics-20 (work in progress),
798              July 2012.
799
800   [Part6]    Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,
801              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
802              draft-ietf-httpbis-p6-cache-20 (work in progress),
803              July 2012.
804
805   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
806              Requirement Levels", BCP 14, RFC 2119, March 1997.
807
808   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
809              Specifications: ABNF", STD 68, RFC 5234, January 2008.
810
8118.2.  Informative References
812
813   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
814              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
815              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
816
817   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
818              Leach, P., Luotonen, A., and L. Stewart, "HTTP
819              Authentication: Basic and Digest Access Authentication",
820              RFC 2617, June 1999.
821
822   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
823              Procedures for Message Header Fields", BCP 90, RFC 3864,
824              September 2004.
825
826   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
827              Resource Identifier (URI): Generic Syntax", STD 66,
828              RFC 3986, January 2005.
829
830   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
831              Encodings", RFC 4648, October 2006.
832
833   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
834              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
835              May 2008.
836
837
838
839Fielding, et al.        Expires January 17, 2013               [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 7                   July 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   Introduce Authentication Scheme Registry.  (Section 2.3)
855
856   Change ABNF productions for header fields to only define the field
857   value.  (Section 4)
858
859Appendix B.  Imported ABNF
860
861   The following core rules are included by reference, as defined in
862   Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
863   CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
864   quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
865   8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
866   character).
867
868   The rules below are defined in [Part1]:
869
870     BWS           = <BWS, defined in [Part1], Section 3.2.1>
871     OWS           = <OWS, defined in [Part1], Section 3.2.1>
872     quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
873     token         = <token, defined in [Part1], Section 3.2.4>
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895Fielding, et al.        Expires January 17, 2013               [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 7                   July 2012
898
899
900Appendix C.  Collected ABNF
901
902   Authorization = credentials
903
904   BWS = <BWS, defined in [Part1], Section 3.2.1>
905
906   OWS = <OWS, defined in [Part1], Section 3.2.1>
907
908   Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
909    challenge ] )
910   Proxy-Authorization = credentials
911
912   WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
913    ] )
914
915   auth-param = token BWS "=" BWS ( token / quoted-string )
916   auth-scheme = token
917
918   b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
919    *"="
920
921   challenge = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) *(
922    OWS "," [ OWS auth-param ] ) ] ) ]
923   credentials = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param )
924    *( OWS "," [ OWS auth-param ] ) ] ) ]
925
926   quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
927
928   token = <token, defined in [Part1], Section 3.2.4>
929
930Appendix D.  Change Log (to be removed by RFC Editor before publication)
931
932   Changes up to the first Working Group Last Call draft are summarized
933   in <http://trac.tools.ietf.org/html/
934   draft-ietf-httpbis-p7-auth-19#appendix-C>.
935
936D.1.  Since draft-ietf-httpbis-p7-auth-19
937
938   Closed issues:
939
940   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/348>: "Realms and
941      scope"
942
943   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/349>: "Strength"
944
945   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/357>:
946      "Authentication exchanges"
947
948
949
950
951Fielding, et al.        Expires January 17, 2013               [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 7                   July 2012
954
955
956   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
957      requirements for recipients"
958
959   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
960      introduction of new IANA registries as normative changes"
961
962Index
963
964   4
965      401 Unauthorized (status code)  9
966      407 Proxy Authentication Required (status code)  10
967
968   A
969      auth-param  5
970      auth-scheme  5
971      Authorization header field  10
972
973   B
974      b64token  5
975
976   C
977      Canonical Root URI  7
978      challenge  6
979      credentials  6
980
981   G
982      Grammar
983         auth-param  5
984         auth-scheme  5
985         Authorization  10
986         b64token  5
987         challenge  6
988         credentials  6
989         Proxy-Authenticate  11
990         Proxy-Authorization  11
991         WWW-Authenticate  12
992
993   H
994      Header Fields
995         Authorization  10
996         Proxy-Authenticate  11
997         Proxy-Authorization  11
998         WWW-Authenticate  12
999
1000   P
1001      Protection Space  7
1002      Proxy-Authenticate header field  11
1003      Proxy-Authorization header field  11
1004
1005
1006
1007Fielding, et al.        Expires January 17, 2013               [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 7                   July 2012
1010
1011
1012   R
1013      Realm  7
1014
1015   S
1016      Status Codes
1017         401 Unauthorized  9
1018         407 Proxy Authentication Required  10
1019
1020   W
1021      WWW-Authenticate header field  12
1022
1023Authors' Addresses
1024
1025   Roy T. Fielding (editor)
1026   Adobe Systems Incorporated
1027   345 Park Ave
1028   San Jose, CA  95110
1029   USA
1030
1031   EMail: fielding@gbiv.com
1032   URI:   http://roy.gbiv.com/
1033
1034
1035   Yves Lafon (editor)
1036   World Wide Web Consortium
1037   W3C / ERCIM
1038   2004, rte des Lucioles
1039   Sophia-Antipolis, AM  06902
1040   France
1041
1042   EMail: ylafon@w3.org
1043   URI:   http://www.raubacapeu.net/people/yves/
1044
1045
1046   Julian F. Reschke (editor)
1047   greenbytes GmbH
1048   Hafenweg 16
1049   Muenster, NW  48155
1050   Germany
1051
1052   EMail: julian.reschke@greenbytes.de
1053   URI:   http://greenbytes.de/tech/webdav/
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063Fielding, et al.        Expires January 17, 2013               [Page 19]
1064
Note: See TracBrowser for help on using the repository browser.