source: draft-ietf-httpbis/latest/auth48/rfc7235-to-be.unpg.txt @ 2705

Last change on this file since 2705 was 2700, checked in by julian.reschke@…, 6 years ago

updated AUTH48 versions of RFC7230 and RFC7235 (#553)

File size: 36.9 KB
Line 
1
2
3
4Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
5Request for Comments: 7235                                         Adobe
6Obsoletes: 2616                                          J. Reschke, Ed.
7Updates: 2617                                                 greenbytes
8Category: Standards Track                                       May 2014
9ISSN: 2070-1721
10
11
12         Hypertext Transfer Protocol (HTTP/1.1): Authentication
13
14Abstract
15
16   The Hypertext Transfer Protocol (HTTP) is a stateless application-
17   level protocol for distributed, collaborative, hypermedia information
18   systems.  This document defines the HTTP Authentication framework.
19
20Status of This Memo
21
22   This is an Internet Standards Track document.
23
24   This document is a product of the Internet Engineering Task Force
25   (IETF).  It represents the consensus of the IETF community.  It has
26   received public review and has been approved for publication by the
27   Internet Engineering Steering Group (IESG).  Further information on
28   Internet Standards is available in Section 2 of RFC 5741.
29
30   Information about the current status of this document, any errata,
31   and how to provide feedback on it may be obtained at
32   http://www.rfc-editor.org/info/rfc7235.
33
34Copyright Notice
35
36   Copyright (c) 2014 IETF Trust and the persons identified as the
37   document authors.  All rights reserved.
38
39   This document is subject to BCP 78 and the IETF Trust's Legal
40   Provisions Relating to IETF Documents
41   (http://trustee.ietf.org/license-info) in effect on the date of
42   publication of this document.  Please review these documents
43   carefully, as they describe your rights and restrictions with respect
44   to this document.  Code Components extracted from this document must
45   include Simplified BSD License text as described in Section 4.e of
46   the Trust Legal Provisions and are provided without warranty as
47   described in the Simplified BSD License.
48
49   This document may contain material from IETF Documents or IETF
50   Contributions published or made publicly available before November
51   10, 2008.  The person(s) controlling the copyright in some of this
52
53
54
55Fielding & Reschke           Standards Track                    [Page 1]
56
57RFC 7235                 HTTP/1.1 Authentication                May 2014
58
59
60   material may not have granted the IETF Trust the right to allow
61   modifications of such material outside the IETF Standards Process.
62   Without obtaining an adequate license from the person(s) controlling
63   the copyright in such materials, this document may not be modified
64   outside the IETF Standards Process, and derivative works of it may
65   not be created outside the IETF Standards Process, except to format
66   it for publication as an RFC or to translate it into languages other
67   than English.
68
69Table of Contents
70
71   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
72     1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  3
73     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  3
74   2.  Access Authentication Framework  . . . . . . . . . . . . . . .  3
75     2.1.  Challenge and Response . . . . . . . . . . . . . . . . . .  3
76     2.2.  Protection Space (Realm) . . . . . . . . . . . . . . . . .  5
77   3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  6
78     3.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  6
79     3.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  6
80   4.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  7
81     4.1.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  7
82     4.2.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  8
83     4.3.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  8
84     4.4.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  9
85   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
86     5.1.  Authentication Scheme Registry . . . . . . . . . . . . . .  9
87       5.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . .  9
88       5.1.2.  Considerations for New Authentication Schemes  . . . .  9
89     5.2.  Status Code Registration . . . . . . . . . . . . . . . . . 11
90     5.3.  Header Field Registration  . . . . . . . . . . . . . . . . 11
91   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
92     6.1.  Confidentiality of Credentials . . . . . . . . . . . . . . 12
93     6.2.  Authentication Credentials and Idle Clients  . . . . . . . 12
94     6.3.  Protection Spaces  . . . . . . . . . . . . . . . . . . . . 13
95   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
96   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
97     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
98     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
99   Appendix A.  Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15
100   Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 15
101   Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 15
102   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
103
104
105
106
107
108
109
110
111Fielding & Reschke           Standards Track                    [Page 2]
112
113RFC 7235                 HTTP/1.1 Authentication                May 2014
114
115
1161.  Introduction
117
118   HTTP provides a general framework for access control and
119   authentication, via an extensible set of challenge-response
120   authentication schemes, which can be used by a server to challenge a
121   client request and by a client to provide authentication information.
122   This document defines HTTP/1.1 authentication in terms of the
123   architecture defined in "Hypertext Transfer Protocol (HTTP/1.1):
124   Message Syntax and Routing" [RFC7230], including the general
125   framework previously described in "HTTP Authentication: Basic and
126   Digest Access Authentication" [RFC2617] and the related fields and
127   status codes previously defined in "Hypertext Transfer Protocol --
128   HTTP/1.1" [RFC2616].
129
130   The IANA Authentication Scheme Registry (Section 5.1) lists
131   registered authentication schemes and their corresponding
132   specifications, including the "basic" and "digest" authentication
133   schemes previously defined by RFC 2617.
134
1351.1.  Conformance and Error Handling
136
137   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
138   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
139   document are to be interpreted as described in [RFC2119].
140
141   Conformance criteria and considerations regarding error handling are
142   defined in Section 2.5 of [RFC7230].
143
1441.2.  Syntax Notation
145
146   This specification uses the Augmented Backus-Naur Form (ABNF)
147   notation of [RFC5234] with a list extension, defined in Section 7 of
148   [RFC7230], that allows for compact definition of comma-separated
149   lists using a '#' operator (similar to how the '*' operator indicates
150   repetition).  Appendix B describes rules imported from other
151   documents.  Appendix C shows the collected grammar with all list
152   operators expanded to standard ABNF notation.
153
1542.  Access Authentication Framework
155
1562.1.  Challenge and Response
157
158   HTTP provides a simple challenge-response authentication framework
159   that can be used by a server to challenge a client request and by a
160   client to provide authentication information.  It uses a case-
161   insensitive token as a means to identify the authentication scheme,
162   followed by additional information necessary for achieving
163   authentication via that scheme.  The latter can be either a comma-
164
165
166
167Fielding & Reschke           Standards Track                    [Page 3]
168
169RFC 7235                 HTTP/1.1 Authentication                May 2014
170
171
172   separated list of parameters or a single sequence of characters
173   capable of holding base64-encoded information.
174
175   Authentication parameters are name=value pairs, where the name token
176   is matched case-insensitively, and each parameter name MUST only
177   occur once per challenge.
178
179     auth-scheme    = token
180
181     auth-param     = token BWS "=" BWS ( token / quoted-string )
182
183     token68        = 1*( ALPHA / DIGIT /
184                          "-" / "." / "_" / "~" / "+" / "/" ) *"="
185
186   The "token68" syntax allows the 66 unreserved URI characters
187   ([RFC3986]), plus a few others, so that it can hold a base64,
188   base64url (URL and filename safe alphabet), base32, or base16 (hex)
189   encoding, with or without padding, but excluding whitespace
190   ([RFC4648]).
191
192   A 401 (Unauthorized) response message is used by an origin server to
193   challenge the authorization of a user agent, including a WWW-
194   Authenticate header field containing at least one challenge
195   applicable to the requested resource.
196
197   A 407 (Proxy Authentication Required) response message is used by a
198   proxy to challenge the authorization of a client, including a Proxy-
199   Authenticate header field containing at least one challenge
200   applicable to the proxy for the requested resource.
201
202     challenge   = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
203
204      Note: Many clients fail to parse a challenge that contains an
205      unknown scheme.  A workaround for this problem is to list well-
206      supported schemes (such as "basic") first.
207
208   A user agent that wishes to authenticate itself with an origin server
209   -- usually, but not necessarily, after receiving a 401 (Unauthorized)
210   -- can do so by including an Authorization header field with the
211   request.
212
213   A client that wishes to authenticate itself with a proxy -- usually,
214   but not necessarily, after receiving a 407 (Proxy Authentication
215   Required) -- can do so by including a Proxy-Authorization header
216   field with the request.
217
218   Both the Authorization field value and the Proxy-Authorization field
219   value contain the client's credentials for the realm of the resource
220
221
222
223Fielding & Reschke           Standards Track                    [Page 4]
224
225RFC 7235                 HTTP/1.1 Authentication                May 2014
226
227
228   being requested, based upon a challenge received in a response
229   (possibly at some point in the past).  When creating their values,
230   the user agent ought to do so by selecting the challenge with what it
231   considers to be the most secure auth-scheme that it understands,
232   obtaining credentials from the user as appropriate.  Transmission of
233   credentials within header field values implies significant security
234   considerations regarding the confidentiality of the underlying
235   connection, as described in Section 6.1.
236
237     credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
238
239   Upon receipt of a request for a protected resource that omits
240   credentials, contains invalid credentials (e.g., a bad password) or
241   partial credentials (e.g., when the authentication scheme requires
242   more than one round trip), an origin server SHOULD send a 401
243   (Unauthorized) response that contains a WWW-Authenticate header field
244   with at least one (possibly new) challenge applicable to the
245   requested resource.
246
247   Likewise, upon receipt of a request that omits proxy credentials or
248   contains invalid or partial proxy credentials, a proxy that requires
249   authentication SHOULD generate a 407 (Proxy Authentication Required)
250   response that contains a Proxy-Authenticate header field with at
251   least one (possibly new) challenge applicable to the proxy.
252
253   A server that receives valid credentials that are not adequate to
254   gain access ought to respond with the 403 (Forbidden) status code
255   (Section 6.5.3 of [RFC7231]).
256
257   HTTP does not restrict applications to this simple challenge-response
258   framework for access authentication.  Additional mechanisms can be
259   used, such as authentication at the transport level or via message
260   encapsulation, and with additional header fields specifying
261   authentication information.  However, such additional mechanisms are
262   not defined by this specification.
263
2642.2.  Protection Space (Realm)
265
266   The "realm" authentication parameter is reserved for use by
267   authentication schemes that wish to indicate a scope of protection.
268
269   A protection space is defined by the canonical root URI (the scheme
270   and authority components of the effective request URI; see Section
271   5.5 of [RFC7230]) of the server being accessed, in combination with
272   the realm value if present.  These realms allow the protected
273   resources on a server to be partitioned into a set of protection
274   spaces, each with its own authentication scheme and/or authorization
275   database.  The realm value is a string, generally assigned by the
276
277
278
279Fielding & Reschke           Standards Track                    [Page 5]
280
281RFC 7235                 HTTP/1.1 Authentication                May 2014
282
283
284   origin server, that can have additional semantics specific to the
285   authentication scheme.  Note that a response can have multiple
286   challenges with the same auth-scheme but with different realms.
287
288   The protection space determines the domain over which credentials can
289   be automatically applied.  If a prior request has been authorized,
290   the user agent MAY reuse the same credentials for all other requests
291   within that protection space for a period of time determined by the
292   authentication scheme, parameters, and/or user preferences (such as a
293   configurable inactivity timeout).  Unless specifically allowed by the
294   authentication scheme, a single protection space cannot extend
295   outside the scope of its server.
296
297   For historical reasons, a sender MUST only generate the quoted-string
298   syntax.  Recipients might have to support both token and quoted-
299   string syntax for maximum interoperability with existing clients that
300   have been accepting both notations for a long time.
301
3023.  Status Code Definitions
303
3043.1.  401 Unauthorized
305
306   The 401 (Unauthorized) status code indicates that the request has not
307   been applied because it lacks valid authentication credentials for
308   the target resource.  The server generating a 401 response MUST send
309   a WWW-Authenticate header field (Section 4.1) containing at least one
310   challenge applicable to the target resource.
311
312   If the request included authentication credentials, then the 401
313   response indicates that authorization has been refused for those
314   credentials.  The user agent MAY repeat the request with a new or
315   replaced Authorization header field (Section 4.2).  If the 401
316   response contains the same challenge as the prior response, and the
317   user agent has already attempted authentication at least once, then
318   the user agent SHOULD present the enclosed representation to the
319   user, since it usually contains relevant diagnostic information.
320
3213.2.  407 Proxy Authentication Required
322
323   The 407 (Proxy Authentication Required) status code is similar to 401
324   (Unauthorized), but it indicates that the client needs to
325   authenticate itself in order to use a proxy.  The proxy MUST send a
326   Proxy-Authenticate header field (Section 4.3) containing a challenge
327   applicable to that proxy for the target resource.  The client MAY
328   repeat the request with a new or replaced Proxy-Authorization header
329   field (Section 4.4).
330
331
332
333
334
335Fielding & Reschke           Standards Track                    [Page 6]
336
337RFC 7235                 HTTP/1.1 Authentication                May 2014
338
339
3404.  Header Field Definitions
341
342   This section defines the syntax and semantics of header fields
343   related to the HTTP authentication framework.
344
3454.1.  WWW-Authenticate
346
347   The "WWW-Authenticate" header field indicates the authentication
348   scheme(s) and parameters applicable to the target resource.
349
350     WWW-Authenticate = 1#challenge
351
352   A server generating a 401 (Unauthorized) response MUST send a WWW-
353   Authenticate header field containing at least one challenge.  A
354   server MAY generate a WWW-Authenticate header field in other response
355   messages to indicate that supplying credentials (or different
356   credentials) might affect the response.
357
358   A proxy forwarding a response MUST NOT modify any WWW-Authenticate
359   fields in that response.
360
361   User agents are advised to take special care in parsing the field
362   value, as it might contain more than one challenge, and each
363   challenge can contain a comma-separated list of authentication
364   parameters.  Furthermore, the header field itself can occur multiple
365   times.
366
367   For instance:
368
369     WWW-Authenticate: Newauth realm="apps", type=1,
370                       title="Login to \"apps\"", Basic realm="simple"
371
372   This header field contains two challenges; one for the "Newauth"
373   scheme with a realm value of "apps", and two additional parameters
374   "type" and "title", and another one for the "Basic" scheme with a
375   realm value of "simple".
376
377      Note: The challenge grammar production uses the list syntax as
378      well.  Therefore, a sequence of comma, whitespace, and comma can
379      be considered either as applying to the preceding challenge, or to
380      be an empty entry in the list of challenges.  In practice, this
381      ambiguity does not affect the semantics of the header field value
382      and thus is harmless.
383
384
385
386
387
388
389
390
391Fielding & Reschke           Standards Track                    [Page 7]
392
393RFC 7235                 HTTP/1.1 Authentication                May 2014
394
395
3964.2.  Authorization
397
398   The "Authorization" header field allows a user agent to authenticate
399   itself with an origin server -- usually, but not necessarily, after
400   receiving a 401 (Unauthorized) response.  Its value consists of
401   credentials containing the authentication information of the user
402   agent for the realm of the resource being requested.
403
404     Authorization = credentials
405
406   If a request is authenticated and a realm specified, the same
407   credentials are presumed to be valid for all other requests within
408   this realm (assuming that the authentication scheme itself does not
409   require otherwise, such as credentials that vary according to a
410   challenge value or using synchronized clocks).
411
412   A proxy forwarding a request MUST NOT modify any Authorization fields
413   in that request.  See Section 3.2 of [RFC7234] for details of and
414   requirements pertaining to handling of the Authorization field by
415   HTTP caches.
416
4174.3.  Proxy-Authenticate
418
419   The "Proxy-Authenticate" header field consists of at least one
420   challenge that indicates the authentication scheme(s) and parameters
421   applicable to the proxy for this effective request URI (Section 5.5
422   of [RFC7230]).  A proxy MUST send at least one Proxy-Authenticate
423   header field in each 407 (Proxy Authentication Required) response
424   that it generates.
425
426     Proxy-Authenticate = 1#challenge
427
428   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
429   only to the next outbound client on the response chain.  This is
430   because only the client that chose a given proxy is likely to have
431   the credentials necessary for authentication.  However, when multiple
432   proxies are used within the same administrative domain, such as
433   office and regional caching proxies within a large corporate network,
434   it is common for credentials to be generated by the user agent and
435   passed through the hierarchy until consumed.  Hence, in such a
436   configuration, it will appear as if Proxy-Authenticate is being
437   forwarded because each proxy will send the same challenge set.
438
439   Note that the parsing considerations for WWW-Authenticate apply to
440   this header field as well; see Section 4.1 for details.
441
442
443
444
445
446
447Fielding & Reschke           Standards Track                    [Page 8]
448
449RFC 7235                 HTTP/1.1 Authentication                May 2014
450
451
4524.4.  Proxy-Authorization
453
454   The "Proxy-Authorization" header field allows the client to identify
455   itself (or its user) to a proxy that requires authentication.  Its
456   value consists of credentials containing the authentication
457   information of the client for the proxy and/or realm of the resource
458   being requested.
459
460     Proxy-Authorization = credentials
461
462   Unlike Authorization, the Proxy-Authorization header field applies
463   only to the next inbound proxy that demanded authentication using the
464   Proxy-Authenticate field.  When multiple proxies are used in a chain,
465   the Proxy-Authorization header field is consumed by the first inbound
466   proxy that was expecting to receive credentials.  A proxy MAY relay
467   the credentials from the client request to the next proxy if that is
468   the mechanism by which the proxies cooperatively authenticate a given
469   request.
470
4715.  IANA Considerations
472
4735.1.  Authentication Scheme Registry
474
475   The "Hypertext Transfer Protocol (HTTP) Authentication Scheme
476   Registry" defines the namespace for the authentication schemes in
477   challenges and credentials.  It has been created and is now
478   maintained at <http://www.iana.org/assignments/http-authschemes>.
479
4805.1.1.  Procedure
481
482   Registrations MUST include the following fields:
483
484   o  Authentication Scheme Name
485
486   o  Pointer to specification text
487
488   o  Notes (optional)
489
490   Values to be added to this namespace require IETF Review (see
491   [RFC5226], Section 4.1).
492
4935.1.2.  Considerations for New Authentication Schemes
494
495   There are certain aspects of the HTTP Authentication Framework that
496   put constraints on how new authentication schemes can work:
497
498
499
500
501
502
503Fielding & Reschke           Standards Track                    [Page 9]
504
505RFC 7235                 HTTP/1.1 Authentication                May 2014
506
507
508   o  HTTP authentication is presumed to be stateless: all of the
509      information necessary to authenticate a request MUST be provided
510      in the request, rather than be dependent on the server remembering
511      prior requests.  Authentication based on, or bound to, the
512      underlying connection is outside the scope of this specification
513      and inherently flawed unless steps are taken to ensure that the
514      connection cannot be used by any party other than the
515      authenticated user (see Section 2.3 of [RFC7230]).
516
517   o  The authentication parameter "realm" is reserved for defining
518      protection spaces as described in Section 2.2.  New schemes MUST
519      NOT use it in a way incompatible with that definition.
520
521   o  The "token68" notation was introduced for compatibility with
522      existing authentication schemes and can only be used once per
523      challenge or credential.  Thus, new schemes ought to use the auth-
524      param syntax instead, because otherwise future extensions will be
525      impossible.
526
527   o  The parsing of challenges and credentials is defined by this
528      specification and cannot be modified by new authentication
529      schemes.  When the auth-param syntax is used, all parameters ought
530      to support both token and quoted-string syntax, and syntactical
531      constraints ought to be defined on the field value after parsing
532      (i.e., quoted-string processing).  This is necessary so that
533      recipients can use a generic parser that applies to all
534      authentication schemes.
535
536      Note: The fact that the value syntax for the "realm" parameter is
537      restricted to quoted-string was a bad design choice not to be
538      repeated for new parameters.
539
540   o  Definitions of new schemes ought to define the treatment of
541      unknown extension parameters.  In general, a "must-ignore" rule is
542      preferable to a "must-understand" rule, because otherwise it will
543      be hard to introduce new parameters in the presence of legacy
544      recipients.  Furthermore, it's good to describe the policy for
545      defining new parameters (such as "update the specification" or
546      "use this registry").
547
548   o  Authentication schemes need to document whether they are usable in
549      origin-server authentication (i.e., using WWW-Authenticate),
550      and/or proxy authentication (i.e., using Proxy-Authenticate).
551
552   o  The credentials carried in an Authorization header field are
553      specific to the user agent and, therefore, have the same effect on
554      HTTP caches as the "private" Cache-Control response directive
555      (Section 5.2.2.6 of [RFC7234]), within the scope of the request in
556
557
558
559Fielding & Reschke           Standards Track                   [Page 10]
560
561RFC 7235                 HTTP/1.1 Authentication                May 2014
562
563
564      which they appear.
565
566      Therefore, new authentication schemes that choose not to carry
567      credentials in the Authorization header field (e.g., using a newly
568      defined header field) will need to explicitly disallow caching, by
569      mandating the use of either Cache-Control request directives
570      (e.g., "no-store", Section 5.2.1.5 of [RFC7234]) or response
571      directives (e.g., "private").
572
5735.2.  Status Code Registration
574
575   The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
576   at <http://www.iana.org/assignments/http-status-codes> has been
577   updated with the registrations below:
578
579   +-------+-------------------------------+-------------+
580   | Value | Description                   | Reference   |
581   +-------+-------------------------------+-------------+
582   | 401   | Unauthorized                  | Section 3.1 |
583   | 407   | Proxy Authentication Required | Section 3.2 |
584   +-------+-------------------------------+-------------+
585
5865.3.  Header Field Registration
587
588   HTTP header fields are registered within the "Message Headers"
589   registry maintained at
590   <http://www.iana.org/assignments/message-headers/>.
591
592   This document defines the following HTTP header fields, so the
593   "Permanent Message Header Field Names" registry has been updated
594   accordingly (see [BCP90]).
595
596   +---------------------+----------+----------+-------------+
597   | Header Field Name   | Protocol | Status   | Reference   |
598   +---------------------+----------+----------+-------------+
599   | Authorization       | http     | standard | Section 4.2 |
600   | Proxy-Authenticate  | http     | standard | Section 4.3 |
601   | Proxy-Authorization | http     | standard | Section 4.4 |
602   | WWW-Authenticate    | http     | standard | Section 4.1 |
603   +---------------------+----------+----------+-------------+
604
605   The change controller is: "IETF (iesg@ietf.org) - Internet
606   Engineering Task Force".
607
6086.  Security Considerations
609
610   This section is meant to inform developers, information providers,
611   and users of known security concerns specific to HTTP authentication.
612
613
614
615Fielding & Reschke           Standards Track                   [Page 11]
616
617RFC 7235                 HTTP/1.1 Authentication                May 2014
618
619
620   More general security considerations are addressed in HTTP messaging
621   [RFC7230] and semantics [RFC7231].
622
623   Everything about the topic of HTTP authentication is a security
624   consideration, so the list of considerations below is not exhaustive.
625   Furthermore, it is limited to security considerations regarding the
626   authentication framework, in general, rather than discussing all of
627   the potential considerations for specific authentication schemes
628   (which ought to be documented in the specifications that define those
629   schemes).  Various organizations maintain topical information and
630   links to current research on Web application security (e.g.,
631   [OWASP]), including common pitfalls for implementing and using the
632   authentication schemes found in practice.
633
6346.1.  Confidentiality of Credentials
635
636   The HTTP authentication framework does not define a single mechanism
637   for maintaining the confidentiality of credentials; instead, each
638   authentication scheme defines how the credentials are encoded prior
639   to transmission.  While this provides flexibility for the development
640   of future authentication schemes, it is inadequate for the protection
641   of existing schemes that provide no confidentiality on their own, or
642   that do not sufficiently protect against replay attacks.
643   Furthermore, if the server expects credentials that are specific to
644   each individual user, the exchange of those credentials will have the
645   effect of identifying that user even if the content within
646   credentials remains confidential.
647
648   HTTP depends on the security properties of the underlying transport-
649   or session-level connection to provide confidential transmission of
650   header fields.  In other words, if a server limits access to
651   authenticated users using this framework, the server needs to ensure
652   that the connection is properly secured in accordance with the nature
653   of the authentication scheme used.  For example, services that depend
654   on individual user authentication often require a connection to be
655   secured with TLS ("Transport Layer Security", [RFC5246]) prior to
656   exchanging any credentials.
657
6586.2.  Authentication Credentials and Idle Clients
659
660   Existing HTTP clients and user agents typically retain authentication
661   information indefinitely.  HTTP does not provide a mechanism for the
662   origin server to direct clients to discard these cached credentials,
663   since the protocol has no awareness of how credentials are obtained
664   or managed by the user agent.  The mechanisms for expiring or
665   revoking credentials can be specified as part of an authentication
666   scheme definition.
667
668
669
670
671Fielding & Reschke           Standards Track                   [Page 12]
672
673RFC 7235                 HTTP/1.1 Authentication                May 2014
674
675
676   Circumstances under which credential caching can interfere with the
677   application's security model include but are not limited to:
678
679   o  Clients that have been idle for an extended period, following
680      which the server might wish to cause the client to re-prompt the
681      user for credentials.
682
683   o  Applications that include a session termination indication (such
684      as a "logout" or "commit" button on a page) after which the server
685      side of the application "knows" that there is no further reason
686      for the client to retain the credentials.
687
688   User agents that cache credentials are encouraged to provide a
689   readily accessible mechanism for discarding cached credentials under
690   user control.
691
6926.3.  Protection Spaces
693
694   Authentication schemes that solely rely on the "realm" mechanism for
695   establishing a protection space will expose credentials to all
696   resources on an origin server.  Clients that have successfully made
697   authenticated requests with a resource can use the same
698   authentication credentials for other resources on the same origin
699   server.  This makes it possible for a different resource to harvest
700   authentication credentials for other resources.
701
702   This is of particular concern when an origin server hosts resources
703   for multiple parties under the same canonical root URI (Section 2.2).
704   Possible mitigation strategies include restricting direct access to
705   authentication credentials (i.e., not making the content of the
706   Authorization request header field available), and separating
707   protection spaces by using a different host name (or port number) for
708   each party.
709
7107.  Acknowledgments
711
712   This specification takes over the definition of the HTTP
713   Authentication Framework, previously defined in RFC 2617.  We thank
714   John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D.
715   Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for
716   their work on that specification.  See Section 6 of [RFC2617] for
717   further acknowledgements.
718
719   See Section 10 of [RFC7230] for the Acknowledgments related to this
720   document revision.
721
7228.  References
723
724
725
726
727Fielding & Reschke           Standards Track                   [Page 13]
728
729RFC 7235                 HTTP/1.1 Authentication                May 2014
730
731
7328.1.  Normative References
733
734   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
735              Requirement Levels", BCP 14, RFC 2119, March 1997.
736
737   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
738              Specifications: ABNF", STD 68, RFC 5234, January 2008.
739
740   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
741              Protocol (HTTP/1.1): Message Syntax and Routing",
742              RFC 7230, May 2014.
743
744   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
745              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
746              May 2014.
747
748   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
749              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
750              RFC 7234, May 2014.
751
7528.2.  Informative References
753
754   [BCP90]    Klyne, G., Nottingham, M., and J. Mogul, "Registration
755              Procedures for Message Header Fields", BCP 90, RFC 3864,
756              September 2004.
757
758   [OWASP]    van der Stock, A., Ed., "A Guide to Building Secure Web
759              Applications and Web Services", The Open Web Application
760              Security Project (OWASP) 2.0.1, July 2005,
761              <https://www.owasp.org/>.
762
763   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
764              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
765              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
766
767   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
768              Leach, P., Luotonen, A., and L. Stewart, "HTTP
769              Authentication: Basic and Digest Access Authentication",
770              RFC 2617, June 1999.
771
772   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
773              Resource Identifier (URI): Generic Syntax", STD 66,
774              RFC 3986, January 2005.
775
776   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
777              Encodings", RFC 4648, October 2006.
778
779   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
780
781
782
783Fielding & Reschke           Standards Track                   [Page 14]
784
785RFC 7235                 HTTP/1.1 Authentication                May 2014
786
787
788              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
789              May 2008.
790
791   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
792              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
793
794Appendix A.  Changes from RFCs 2616 and 2617
795
796   The framework for HTTP Authentication is now defined by this
797   document, rather than RFC 2617.
798
799   The "realm" parameter is no longer always required on challenges;
800   consequently, the ABNF allows challenges without any auth parameters.
801   (Section 2)
802
803   The "token68" alternative to auth-param lists has been added for
804   consistency with legacy authentication schemes such as "Basic".
805   (Section 2)
806
807   This specification introduces the Authentication Scheme Registry,
808   along with considerations for new authentication schemes.
809   (Section 5.1)
810
811Appendix B.  Imported ABNF
812
813   The following core rules are included by reference, as defined in
814   Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
815   CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
816   quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
817   8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
818   character).
819
820   The rules below are defined in [RFC7230]:
821
822     BWS           = <BWS, see [RFC7230], Section 3.2.3>
823     OWS           = <OWS, see [RFC7230], Section 3.2.3>
824     quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
825     token         = <token, see [RFC7230], Section 3.2.6>
826
827Appendix C.  Collected ABNF
828
829   In the collected ABNF below, list rules are expanded as per Section
830   1.2 of [RFC7230].
831
832
833
834
835
836
837
838
839Fielding & Reschke           Standards Track                   [Page 15]
840
841RFC 7235                 HTTP/1.1 Authentication                May 2014
842
843
844   Authorization = credentials
845
846   BWS = <BWS, see [RFC7230], Section 3.2.3>
847
848   OWS = <OWS, see [RFC7230], Section 3.2.3>
849
850   Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
851    challenge ] )
852   Proxy-Authorization = credentials
853
854   WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
855    ] )
856
857   auth-param = token BWS "=" BWS ( token / quoted-string )
858   auth-scheme = token
859
860   challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
861    OWS "," [ OWS auth-param ] ) ] ) ]
862   credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
863    *( OWS "," [ OWS auth-param ] ) ] ) ]
864
865   quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
866
867   token = <token, see [RFC7230], Section 3.2.6>
868   token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
869    *"="
870
871Index
872
873   4
874      401 Unauthorized (status code)  6
875      407 Proxy Authentication Required (status code)  6
876
877   A
878      Authorization header field  8
879
880   C
881      Canonical Root URI  5
882
883   G
884      Grammar
885         auth-param  4
886         auth-scheme  4
887         Authorization  8
888         challenge  4
889         credentials  5
890         Proxy-Authenticate  8
891         Proxy-Authorization  9
892
893
894
895Fielding & Reschke           Standards Track                   [Page 16]
896
897RFC 7235                 HTTP/1.1 Authentication                May 2014
898
899
900         token68  4
901         WWW-Authenticate  7
902
903   P
904      Protection Space  5
905      Proxy-Authenticate header field  8
906      Proxy-Authorization header field  9
907
908   R
909      Realm  5
910
911   W
912      WWW-Authenticate header field  7
913
914Authors' Addresses
915
916   Roy T. Fielding (editor)
917   Adobe Systems Incorporated
918   345 Park Ave
919   San Jose, CA  95110
920   USA
921
922   EMail: fielding@gbiv.com
923   URI:   http://roy.gbiv.com/
924
925
926   Julian F. Reschke (editor)
927   greenbytes GmbH
928   Hafenweg 16
929   Muenster, NW  48155
930   Germany
931
932   EMail: julian.reschke@greenbytes.de
933   URI:   http://greenbytes.de/tech/webdav/
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951Fielding & Reschke           Standards Track                   [Page 17]
952
Note: See TracBrowser for help on using the repository browser.