source: draft-ietf-httpbis/21/draft-ietf-httpbis-p7-auth-21.txt @ 2492

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

prepare release of -21 drafts on Oct 4

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