source: draft-ietf-httpbis/22/draft-ietf-httpbis-p7-auth-22.txt @ 2190

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

prepare -22 for release

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 36.1 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                       February 23, 2013
9Expires: August 27, 2013
10
11
12         Hypertext Transfer Protocol (HTTP/1.1): Authentication
13                     draft-ietf-httpbis-p7-auth-22
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.3.
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 August 27, 2013.
50
51Copyright Notice
52
53
54
55Fielding & Reschke       Expires August 27, 2013                [Page 1]
56
57Internet-Draft           HTTP/1.1 Authentication           February 2013
58
59
60   Copyright (c) 2013 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 August 27, 2013                [Page 2]
112
113Internet-Draft           HTTP/1.1 Authentication           February 2013
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 . . . . . . . . . . . . . . . . . . . . . 10
134   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
135     5.1.  Authentication Scheme Registry . . . . . . . . . . . . . . 11
136     5.2.  Status Code Registration . . . . . . . . . . . . . . . . . 11
137     5.3.  Header Field Registration  . . . . . . . . . . . . . . . . 12
138   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
139     6.1.  Authentication Credentials and Idle Clients  . . . . . . . 12
140     6.2.  Protection Spaces  . . . . . . . . . . . . . . . . . . . . 13
141   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
142   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
143     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
144     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
145   Appendix A.  Changes from RFCs 2616 and 2617 . . . . . . . . . . . 14
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     D.3.  Since draft-ietf-httpbis-p7-auth-21  . . . . . . . . . . . 17
153   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
154
155
156
157
158
159
160
161
162
163
164
165
166
167Fielding & Reschke       Expires August 27, 2013                [Page 3]
168
169Internet-Draft           HTTP/1.1 Authentication           February 2013
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 that can be used by a server to challenge a client request
182   and by a client to provide authentication information.  The "basic"
183   and "digest" authentication schemes continue to be specified in RFC
184   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 August 27, 2013                [Page 4]
224
225Internet-Draft           HTTP/1.1 Authentication           February 2013
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 August 27, 2013                [Page 5]
280
281Internet-Draft           HTTP/1.1 Authentication           February 2013
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 send a 401 (Unauthorized)
296   response that contains a WWW-Authenticate header field with at least
297   one (possibly new) challenge applicable to the requested resource.
298
299   Likewise, upon a request that requires authentication by proxies that
300   omit credentials or contain invalid or partial credentials, a proxy
301   SHOULD send a 407 (Proxy Authentication Required) response that
302   contains a Proxy-Authenticate header field with a (possibly new)
303   challenge applicable to the proxy.
304
305   A server receiving credentials that are valid, but not adequate to
306   gain access, ought to respond with the 403 (Forbidden) status code
307   (Section 6.5.3 of [Part2]).
308
309   The HTTP protocol does not restrict applications to this simple
310   challenge-response mechanism for access authentication.  Additional
311   mechanisms MAY be used, such as encryption at the transport level or
312   via message encapsulation, and with additional header fields
313   specifying authentication information.  However, such additional
314   mechanisms are not defined by this specification.
315
316   Proxies MUST forward the WWW-Authenticate and Authorization header
317   fields unmodified and follow the rules found in Section 4.1.
318
3192.2.  Protection Space (Realm)
320
321   The authentication parameter realm is reserved for use by
322   authentication schemes that wish to indicate the scope of protection.
323
324   A protection space is defined by the canonical root URI (the scheme
325   and authority components of the effective request URI; see Section
326   5.5 of [Part1]) of the server being accessed, in combination with the
327   realm value if present.  These realms allow the protected resources
328   on a server to be partitioned into a set of protection spaces, each
329   with its own authentication scheme and/or authorization database.
330   The realm value is a string, generally assigned by the origin server,
331   that can have additional semantics specific to the authentication
332
333
334
335Fielding & Reschke       Expires August 27, 2013                [Page 6]
336
337Internet-Draft           HTTP/1.1 Authentication           February 2013
338
339
340   scheme.  Note that there can be multiple challenges with the same
341   auth-scheme but different realms.
342
343   The protection space determines the domain over which credentials can
344   be automatically applied.  If a prior request has been authorized,
345   the same credentials MAY be reused for all other requests within that
346   protection space for a period of time determined by the
347   authentication scheme, parameters, and/or user preference.  Unless
348   otherwise defined by the authentication scheme, a single protection
349   space cannot extend outside the scope of its server.
350
351   For historical reasons, senders MUST only use the quoted-string
352   syntax.  Recipients might have to support both token and quoted-
353   string syntax for maximum interoperability with existing clients that
354   have been accepting both notations for a long time.
355
3562.3.  Authentication Scheme Registry
357
358   The HTTP Authentication Scheme Registry defines the name space for
359   the authentication schemes in challenges and credentials.
360
361   Registrations MUST include the following fields:
362
363   o  Authentication Scheme Name
364
365   o  Pointer to specification text
366
367   o  Notes (optional)
368
369   Values to be added to this name space require IETF Review (see
370   [RFC5226], Section 4.1).
371
372   The registry itself is maintained at
373   <http://www.iana.org/assignments/http-authschemes>.
374
3752.3.1.  Considerations for New Authentication Schemes
376
377   There are certain aspects of the HTTP Authentication Framework that
378   put constraints on how new authentication schemes can work:
379
380   o  HTTP authentication is presumed to be stateless: all of the
381      information necessary to authenticate a request MUST be provided
382      in the request, rather than be dependent on the server remembering
383      prior requests.  Authentication based on, or bound to, the
384      underlying connection is outside the scope of this specification
385      and inherently flawed unless steps are taken to ensure that the
386      connection cannot be used by any party other than the
387      authenticated user (see Section 2.3 of [Part1]).
388
389
390
391Fielding & Reschke       Expires August 27, 2013                [Page 7]
392
393Internet-Draft           HTTP/1.1 Authentication           February 2013
394
395
396   o  The authentication parameter "realm" is reserved for defining
397      Protection Spaces as defined in Section 2.2.  New schemes MUST NOT
398      use it in a way incompatible with that definition.
399
400   o  The "token68" notation was introduced for compatibility with
401      existing authentication schemes and can only be used once per
402      challenge/credentials.  New schemes thus ought to use the "auth-
403      param" syntax instead, because otherwise future extensions will be
404      impossible.
405
406   o  The parsing of challenges and credentials is defined by this
407      specification, and cannot be modified by new authentication
408      schemes.  When the auth-param syntax is used, all parameters ought
409      to support both token and quoted-string syntax, and syntactical
410      constraints ought to be defined on the field value after parsing
411      (i.e., quoted-string processing).  This is necessary so that
412      recipients can use a generic parser that applies to all
413      authentication schemes.
414
415      Note: The fact that the value syntax for the "realm" parameter is
416      restricted to quoted-string was a bad design choice not to be
417      repeated for new parameters.
418
419   o  Definitions of new schemes ought to define the treatment of
420      unknown extension parameters.  In general, a "must-ignore" rule is
421      preferable over "must-understand", because otherwise it will be
422      hard to introduce new parameters in the presence of legacy
423      recipients.  Furthermore, it's good to describe the policy for
424      defining new parameters (such as "update the specification", or
425      "use this registry").
426
427   o  Authentication schemes need to document whether they are usable in
428      origin-server authentication (i.e., using WWW-Authenticate),
429      and/or proxy authentication (i.e., using Proxy-Authenticate).
430
431   o  The credentials carried in an Authorization header field are
432      specific to the User Agent, and therefore have the same effect on
433      HTTP caches as the "private" Cache-Control response directive,
434      within the scope of the request they appear in.
435
436      Therefore, new authentication schemes that choose not to carry
437      credentials in the Authorization header field (e.g., using a newly
438      defined header field) will need to explicitly disallow caching, by
439      mandating the use of either Cache-Control request directives
440      (e.g., "no-store") or response directives (e.g., "private").
441
442
443
444
445
446
447Fielding & Reschke       Expires August 27, 2013                [Page 8]
448
449Internet-Draft           HTTP/1.1 Authentication           February 2013
450
451
4523.  Status Code Definitions
453
4543.1.  401 Unauthorized
455
456   The 401 (Unauthorized) status code indicates that the request has not
457   been applied because it lacks valid authentication credentials for
458   the target resource.  The origin server MUST send a WWW-Authenticate
459   header field (Section 4.4) containing at least one challenge
460   applicable to the target resource.  If the request included
461   authentication credentials, then the 401 response indicates that
462   authorization has been refused for those credentials.  The client MAY
463   repeat the request with a new or replaced Authorization header field
464   (Section 4.1).  If the 401 response contains the same challenge as
465   the prior response, and the user agent has already attempted
466   authentication at least once, then the user agent SHOULD present the
467   enclosed representation to the user, since it usually contains
468   relevant diagnostic information.
469
4703.2.  407 Proxy Authentication Required
471
472   The 407 (Proxy Authentication Required) status code is similar to 401
473   (Unauthorized), but indicates that the client needs to authenticate
474   itself in order to use a proxy.  The proxy MUST send a Proxy-
475   Authenticate header field (Section 4.2) containing a challenge
476   applicable to that proxy for the target resource.  The client MAY
477   repeat the request with a new or replaced Proxy-Authorization header
478   field (Section 4.3).
479
4804.  Header Field Definitions
481
482   This section defines the syntax and semantics of HTTP/1.1 header
483   fields related to authentication.
484
4854.1.  Authorization
486
487   The "Authorization" header field allows a user agent to authenticate
488   itself with a server -- usually, but not necessarily, after receiving
489   a 401 (Unauthorized) response.  Its value consists of credentials
490   containing information of the user agent for the realm of the
491   resource being requested.
492
493     Authorization = credentials
494
495   If a request is authenticated and a realm specified, the same
496   credentials SHOULD be valid for all other requests within this realm
497   (assuming that the authentication scheme itself does not require
498   otherwise, such as credentials that vary according to a challenge
499   value or using synchronized clocks).
500
501
502
503Fielding & Reschke       Expires August 27, 2013                [Page 9]
504
505Internet-Draft           HTTP/1.1 Authentication           February 2013
506
507
508   See Section 3.2 of [Part6] for details of and requirements pertaining
509   to handling of the Authorization field by HTTP caches.
510
5114.2.  Proxy-Authenticate
512
513   The "Proxy-Authenticate" header field consists of at least one
514   challenge that indicates the authentication scheme(s) and parameters
515   applicable to the proxy for this effective request URI (Section 5.5
516   of [Part1]).  It MUST be included as part of a 407 (Proxy
517   Authentication Required) response.
518
519     Proxy-Authenticate = 1#challenge
520
521   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
522   only to the current connection, and intermediaries SHOULD NOT forward
523   it to downstream clients.  However, an intermediate proxy might need
524   to obtain its own credentials by requesting them from the downstream
525   client, which in some circumstances will appear as if the proxy is
526   forwarding the Proxy-Authenticate header field.
527
528   Note that the parsing considerations for WWW-Authenticate apply to
529   this header field as well; see Section 4.4 for details.
530
5314.3.  Proxy-Authorization
532
533   The "Proxy-Authorization" header field allows the client to identify
534   itself (or its user) to a proxy that requires authentication.  Its
535   value consists of credentials containing the authentication
536   information of the user agent for the proxy and/or realm of the
537   resource being requested.
538
539     Proxy-Authorization = credentials
540
541   Unlike Authorization, the Proxy-Authorization header field applies
542   only to the next outbound proxy that demanded authentication using
543   the Proxy-Authenticate field.  When multiple proxies are used in a
544   chain, the Proxy-Authorization header field is consumed by the first
545   outbound proxy that was expecting to receive credentials.  A proxy
546   MAY relay the credentials from the client request to the next proxy
547   if that is the mechanism by which the proxies cooperatively
548   authenticate a given request.
549
5504.4.  WWW-Authenticate
551
552   The "WWW-Authenticate" header field consists of at least one
553   challenge that indicates the authentication scheme(s) and parameters
554   applicable to the effective request URI (Section 5.5 of [Part1]).
555
556
557
558
559Fielding & Reschke       Expires August 27, 2013               [Page 10]
560
561Internet-Draft           HTTP/1.1 Authentication           February 2013
562
563
564   It MUST be included in 401 (Unauthorized) response messages and MAY
565   be included in other response messages to indicate that supplying
566   credentials (or different credentials) might affect the response.
567
568     WWW-Authenticate = 1#challenge
569
570   User agents are advised to take special care in parsing the WWW-
571   Authenticate field value as it might contain more than one challenge,
572   or if more than one WWW-Authenticate header field is provided, the
573   contents of a challenge itself can contain a comma-separated list of
574   authentication parameters.
575
576   For instance:
577
578     WWW-Authenticate: Newauth realm="apps", type=1,
579                       title="Login to \"apps\"", Basic realm="simple"
580
581   This header field contains two challenges; one for the "Newauth"
582   scheme with a realm value of "apps", and two additional parameters
583   "type" and "title", and another one for the "Basic" scheme with a
584   realm value of "simple".
585
586      Note: The challenge grammar production uses the list syntax as
587      well.  Therefore, a sequence of comma, whitespace, and comma can
588      be considered both as applying to the preceding challenge, or to
589      be an empty entry in the list of challenges.  In practice, this
590      ambiguity does not affect the semantics of the header field value
591      and thus is harmless.
592
5935.  IANA Considerations
594
5955.1.  Authentication Scheme Registry
596
597   The registration procedure for HTTP Authentication Schemes is defined
598   by Section 2.3 of this document.
599
600   The HTTP Method Authentication Scheme shall be created at
601   <http://www.iana.org/assignments/http-authschemes>.
602
6035.2.  Status Code Registration
604
605   The HTTP Status Code Registry located at
606   <http://www.iana.org/assignments/http-status-codes> shall be updated
607   with the registrations below:
608
609
610
611
612
613
614
615Fielding & Reschke       Expires August 27, 2013               [Page 11]
616
617Internet-Draft           HTTP/1.1 Authentication           February 2013
618
619
620   +-------+-------------------------------+-------------+
621   | Value | Description                   | Reference   |
622   +-------+-------------------------------+-------------+
623   | 401   | Unauthorized                  | Section 3.1 |
624   | 407   | Proxy Authentication Required | Section 3.2 |
625   +-------+-------------------------------+-------------+
626
6275.3.  Header Field Registration
628
629   The Message Header Field Registry located at <http://www.iana.org/
630   assignments/message-headers/message-header-index.html> shall be
631   updated with the permanent registrations below (see [BCP90]):
632
633   +---------------------+----------+----------+-------------+
634   | Header Field Name   | Protocol | Status   | Reference   |
635   +---------------------+----------+----------+-------------+
636   | Authorization       | http     | standard | Section 4.1 |
637   | Proxy-Authenticate  | http     | standard | Section 4.2 |
638   | Proxy-Authorization | http     | standard | Section 4.3 |
639   | WWW-Authenticate    | http     | standard | Section 4.4 |
640   +---------------------+----------+----------+-------------+
641
642   The change controller is: "IETF (iesg@ietf.org) - Internet
643   Engineering Task Force".
644
6456.  Security Considerations
646
647   This section is meant to inform developers, information providers,
648   and users of known security concerns specific to HTTP/1.1
649   authentication.  More general security considerations are addressed
650   in HTTP messaging [Part1] and semantics [Part2].
651
6526.1.  Authentication Credentials and Idle Clients
653
654   Existing HTTP clients and user agents typically retain authentication
655   information indefinitely.  HTTP/1.1 does not provide a method for a
656   server to direct clients to discard these cached credentials.  This
657   is a significant defect that requires further extensions to HTTP.
658   Circumstances under which credential caching can interfere with the
659   application's security model include but are not limited to:
660
661   o  Clients that have been idle for an extended period, following
662      which the server might wish to cause the client to re-prompt the
663      user for credentials.
664
665   o  Applications that include a session termination indication (such
666      as a "logout" or "commit" button on a page) after which the server
667      side of the application "knows" that there is no further reason
668
669
670
671Fielding & Reschke       Expires August 27, 2013               [Page 12]
672
673Internet-Draft           HTTP/1.1 Authentication           February 2013
674
675
676      for the client to retain the credentials.
677
678   This is currently under separate study.  There are a number of work-
679   arounds to parts of this problem, and we encourage the use of
680   password protection in screen savers, idle time-outs, and other
681   methods that mitigate the security problems inherent in this problem.
682   In particular, user agents that cache credentials are encouraged to
683   provide a readily accessible mechanism for discarding cached
684   credentials under user control.
685
6866.2.  Protection Spaces
687
688   Authentication schemes that solely rely on the "realm" mechanism for
689   establishing a protection space will expose credentials to all
690   resources on a server.  Clients that have successfully made
691   authenticated requests with a resource can use the same
692   authentication credentials for other resources on the same server.
693   This makes it possible for a different resource to harvest
694   authentication credentials for other resources.
695
696   This is of particular concern when a server hosts resources for
697   multiple parties under the same canonical root URI (Section 2.2).
698   Possible mitigation strategies include restricting direct access to
699   authentication credentials (i.e., not making the content of the
700   Authorization request header field available), and separating
701   protection spaces by using a different host name for each party.
702
7037.  Acknowledgments
704
705   This specification takes over the definition of the HTTP
706   Authentication Framework, previously defined in RFC 2617.  We thank
707   John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D.
708   Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for
709   their work on that specification.  See Section 6 of [RFC2617] for
710   further acknowledgements.
711
712   See Section 9 of [Part1] for the Acknowledgments related to this
713   document revision.
714
7158.  References
716
7178.1.  Normative References
718
719   [Part1]    Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
720              Protocol (HTTP/1.1): Message Syntax and Routing",
721              draft-ietf-httpbis-p1-messaging-22 (work in progress),
722              February 2013.
723
724
725
726
727Fielding & Reschke       Expires August 27, 2013               [Page 13]
728
729Internet-Draft           HTTP/1.1 Authentication           February 2013
730
731
732   [Part2]    Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
733              Protocol (HTTP/1.1): Semantics and Content",
734              draft-ietf-httpbis-p2-semantics-22 (work in progress),
735              February 2013.
736
737   [Part6]    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
738              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
739              draft-ietf-httpbis-p6-cache-22 (work in progress),
740              February 2013.
741
742   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
743              Requirement Levels", BCP 14, RFC 2119, March 1997.
744
745   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
746              Specifications: ABNF", STD 68, RFC 5234, January 2008.
747
7488.2.  Informative References
749
750   [BCP90]    Klyne, G., Nottingham, M., and J. Mogul, "Registration
751              Procedures for Message Header Fields", BCP 90, RFC 3864,
752              September 2004.
753
754   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
755              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
756              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
757
758   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
759              Leach, P., Luotonen, A., and L. Stewart, "HTTP
760              Authentication: Basic and Digest Access Authentication",
761              RFC 2617, June 1999.
762
763   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
764              Resource Identifier (URI): Generic Syntax", STD 66,
765              RFC 3986, January 2005.
766
767   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
768              Encodings", RFC 4648, October 2006.
769
770   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
771              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
772              May 2008.
773
774Appendix A.  Changes from RFCs 2616 and 2617
775
776   The framework for HTTP Authentication is now defined by this
777   document, rather than RFC 2617.
778
779   The "realm" parameter is no longer always required on challenges;
780
781
782
783Fielding & Reschke       Expires August 27, 2013               [Page 14]
784
785Internet-Draft           HTTP/1.1 Authentication           February 2013
786
787
788   consequently, the ABNF allows challenges without any auth parameters.
789   (Section 2)
790
791   The "token68" alternative to auth-param lists has been added for
792   consistency with legacy authentication schemes such as "Basic".
793   (Section 2)
794
795   This specification introduces the Authentication Scheme Registry,
796   along with considerations for new authentication schemes.
797   (Section 2.3)
798
799Appendix B.  Imported ABNF
800
801   The following core rules are included by reference, as defined in
802   Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
803   CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
804   quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
805   8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
806   character).
807
808   The rules below are defined in [Part1]:
809
810     BWS           = <BWS, defined in [Part1], Section 3.2.3>
811     OWS           = <OWS, defined in [Part1], Section 3.2.3>
812     quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
813     token         = <token, defined in [Part1], Section 3.2.6>
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839Fielding & Reschke       Expires August 27, 2013               [Page 15]
840
841Internet-Draft           HTTP/1.1 Authentication           February 2013
842
843
844Appendix C.  Collected ABNF
845
846   Authorization = credentials
847
848   BWS = <BWS, defined in [Part1], Section 3.2.3>
849
850   OWS = <OWS, defined in [Part1], Section 3.2.3>
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.6>
868
869   token = <token, defined in [Part1], Section 3.2.6>
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 August 27, 2013               [Page 16]
896
897Internet-Draft           HTTP/1.1 Authentication           February 2013
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
918D.3.  Since draft-ietf-httpbis-p7-auth-21
919
920   Closed issues:
921
922   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/403>:
923      "Authentication and caching - max-age"
924
925Index
926
927   4
928      401 Unauthorized (status code)  9
929      407 Proxy Authentication Required (status code)  9
930
931   A
932      Authorization header field  9
933
934   C
935      Canonical Root URI  6
936
937   G
938      Grammar
939         auth-param  5
940         auth-scheme  5
941         Authorization  9
942         challenge  5
943         credentials  6
944         Proxy-Authenticate  10
945         Proxy-Authorization  10
946         token68  5
947         WWW-Authenticate  11
948
949
950
951Fielding & Reschke       Expires August 27, 2013               [Page 17]
952
953Internet-Draft           HTTP/1.1 Authentication           February 2013
954
955
956   P
957      Protection Space  6
958      Proxy-Authenticate header field  10
959      Proxy-Authorization header field  10
960
961   R
962      Realm  6
963
964   W
965      WWW-Authenticate header field  10
966
967Authors' Addresses
968
969   Roy T. Fielding (editor)
970   Adobe Systems Incorporated
971   345 Park Ave
972   San Jose, CA  95110
973   USA
974
975   EMail: fielding@gbiv.com
976   URI:   http://roy.gbiv.com/
977
978
979   Julian F. Reschke (editor)
980   greenbytes GmbH
981   Hafenweg 16
982   Muenster, NW  48155
983   Germany
984
985   EMail: julian.reschke@greenbytes.de
986   URI:   http://greenbytes.de/tech/webdav/
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007Fielding & Reschke       Expires August 27, 2013               [Page 18]
1008
Note: See TracBrowser for help on using the repository browser.