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

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

add RFC7234-to-be and RFC7235-to-be (#553)

File size: 36.7 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 . . . . . . . . . . . . . . . . . . .  6
81     4.1.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  7
82     4.2.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  7
83     4.3.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  8
84     4.4.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  8
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
97     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
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 [RFC7230], including the general framework
124   previously described in [RFC2617] and the related fields and status
125   codes previously defined in [RFC2616].
126
127   The IANA Authentication Scheme Registry (Section 5.1) lists
128   registered authentication schemes and their corresponding
129   specifications, including the "basic" and "digest" authentication
130   schemes previously defined by RFC 2617.
131
1321.1.  Conformance and Error Handling
133
134   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
135   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
136   document are to be interpreted as described in [RFC2119].
137
138   Conformance criteria and considerations regarding error handling are
139   defined in Section 2.5 of [RFC7230].
140
1411.2.  Syntax Notation
142
143   This specification uses the Augmented Backus-Naur Form (ABNF)
144   notation of [RFC5234] with a list extension, defined in Section 7 of
145   [RFC7230], that allows for compact definition of comma-separated
146   lists using a '#' operator (similar to how the '*' operator indicates
147   repetition).  Appendix B describes rules imported from other
148   documents.  Appendix C shows the collected grammar with all list
149   operators expanded to standard ABNF notation.
150
1512.  Access Authentication Framework
152
1532.1.  Challenge and Response
154
155   HTTP provides a simple challenge-response authentication framework
156   that can be used by a server to challenge a client request and by a
157   client to provide authentication information.  It uses a case-
158   insensitive token as a means to identify the authentication scheme,
159   followed by additional information necessary for achieving
160   authentication via that scheme.  The latter can be either a comma-
161   separated list of parameters or a single sequence of characters
162   capable of holding base64-encoded information.
163
164
165
166
167Fielding & Reschke           Standards Track                    [Page 3]
168
169RFC 7235                 HTTP/1.1 Authentication                May 2014
170
171
172   Authentication parameters are name=value pairs, where the name token
173   is matched case-insensitively, and each parameter name MUST only
174   occur once per challenge.
175
176     auth-scheme    = token
177
178     auth-param     = token BWS "=" BWS ( token / quoted-string )
179
180     token68        = 1*( ALPHA / DIGIT /
181                          "-" / "." / "_" / "~" / "+" / "/" ) *"="
182
183   The "token68" syntax allows the 66 unreserved URI characters
184   ([RFC3986]), plus a few others, so that it can hold a base64,
185   base64url (URL and filename safe alphabet), base32, or base16 (hex)
186   encoding, with or without padding, but excluding whitespace
187   ([RFC4648]).
188
189   A 401 (Unauthorized) response message is used by an origin server to
190   challenge the authorization of a user agent, including a WWW-
191   Authenticate header field containing at least one challenge
192   applicable to the requested resource.
193
194   A 407 (Proxy Authentication Required) response message is used by a
195   proxy to challenge the authorization of a client, including a Proxy-
196   Authenticate header field containing at least one challenge
197   applicable to the proxy for the requested resource.
198
199     challenge   = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
200
201      Note: Many clients fail to parse a challenge that contains an
202      unknown scheme.  A workaround for this problem is to list well-
203      supported schemes (such as "basic") first.
204
205   A user agent that wishes to authenticate itself with an origin server
206   -- usually, but not necessarily, after receiving a 401 (Unauthorized)
207   -- can do so by including an Authorization header field with the
208   request.
209
210   A client that wishes to authenticate itself with a proxy -- usually,
211   but not necessarily, after receiving a 407 (Proxy Authentication
212   Required) -- can do so by including a Proxy-Authorization header
213   field with the request.
214
215   Both the Authorization field value and the Proxy-Authorization field
216   value contain the client's credentials for the realm of the resource
217   being requested, based upon a challenge received in a response
218   (possibly at some point in the past).  When creating their values,
219   the user agent ought to do so by selecting the challenge with what it
220
221
222
223Fielding & Reschke           Standards Track                    [Page 4]
224
225RFC 7235                 HTTP/1.1 Authentication                May 2014
226
227
228   considers to be the most secure auth-scheme that it understands,
229   obtaining credentials from the user as appropriate.  Transmission of
230   credentials within header field values implies significant security
231   considerations regarding the confidentiality of the underlying
232   connection, as described in Section 6.1.
233
234     credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
235
236   Upon receipt of a request for a protected resource that omits
237   credentials, contains invalid credentials (e.g., a bad password) or
238   partial credentials (e.g., when the authentication scheme requires
239   more than one round trip), an origin server SHOULD send a 401
240   (Unauthorized) response that contains a WWW-Authenticate header field
241   with at least one (possibly new) challenge applicable to the
242   requested resource.
243
244   Likewise, upon receipt of a request that omits proxy credentials or
245   contains invalid or partial proxy credentials, a proxy that requires
246   authentication SHOULD generate a 407 (Proxy Authentication Required)
247   response that contains a Proxy-Authenticate header field with at
248   least one (possibly new) challenge applicable to the proxy.
249
250   A server that receives valid credentials that are not adequate to
251   gain access ought to respond with the 403 (Forbidden) status code
252   (Section 6.5.3 of [RFC7231]).
253
254   HTTP does not restrict applications to this simple challenge-response
255   framework for access authentication.  Additional mechanisms can be
256   used, such as authentication at the transport level or via message
257   encapsulation, and with additional header fields specifying
258   authentication information.  However, such additional mechanisms are
259   not defined by this specification.
260
2612.2.  Protection Space (Realm)
262
263   The "realm" authentication parameter is reserved for use by
264   authentication schemes that wish to indicate a scope of protection.
265
266   A protection space is defined by the canonical root URI (the scheme
267   and authority components of the effective request URI; see Section
268   5.5 of [RFC7230]) of the server being accessed, in combination with
269   the realm value if present.  These realms allow the protected
270   resources on a server to be partitioned into a set of protection
271   spaces, each with its own authentication scheme and/or authorization
272   database.  The realm value is a string, generally assigned by the
273   origin server, that can have additional semantics specific to the
274   authentication scheme.  Note that a response can have multiple
275   challenges with the same auth-scheme but with different realms.
276
277
278
279Fielding & Reschke           Standards Track                    [Page 5]
280
281RFC 7235                 HTTP/1.1 Authentication                May 2014
282
283
284   The protection space determines the domain over which credentials can
285   be automatically applied.  If a prior request has been authorized,
286   the user agent MAY reuse the same credentials for all other requests
287   within that protection space for a period of time determined by the
288   authentication scheme, parameters, and/or user preferences (such as a
289   configurable inactivity timeout).  Unless specifically allowed by the
290   authentication scheme, a single protection space cannot extend
291   outside the scope of its server.
292
293   For historical reasons, a sender MUST only generate the quoted-string
294   syntax.  Recipients might have to support both token and quoted-
295   string syntax for maximum interoperability with existing clients that
296   have been accepting both notations for a long time.
297
2983.  Status Code Definitions
299
3003.1.  401 Unauthorized
301
302   The 401 (Unauthorized) status code indicates that the request has not
303   been applied because it lacks valid authentication credentials for
304   the target resource.  The server generating a 401 response MUST send
305   a WWW-Authenticate header field (Section 4.1) containing at least one
306   challenge applicable to the target resource.
307
308   If the request included authentication credentials, then the 401
309   response indicates that authorization has been refused for those
310   credentials.  The user agent MAY repeat the request with a new or
311   replaced Authorization header field (Section 4.2).  If the 401
312   response contains the same challenge as the prior response, and the
313   user agent has already attempted authentication at least once, then
314   the user agent SHOULD present the enclosed representation to the
315   user, since it usually contains relevant diagnostic information.
316
3173.2.  407 Proxy Authentication Required
318
319   The 407 (Proxy Authentication Required) status code is similar to 401
320   (Unauthorized), but it indicates that the client needs to
321   authenticate itself in order to use a proxy.  The proxy MUST send a
322   Proxy-Authenticate header field (Section 4.3) containing a challenge
323   applicable to that proxy for the target resource.  The client MAY
324   repeat the request with a new or replaced Proxy-Authorization header
325   field (Section 4.4).
326
3274.  Header Field Definitions
328
329   This section defines the syntax and semantics of header fields
330   related to the HTTP authentication framework.
331
332
333
334
335Fielding & Reschke           Standards Track                    [Page 6]
336
337RFC 7235                 HTTP/1.1 Authentication                May 2014
338
339
3404.1.  WWW-Authenticate
341
342   The "WWW-Authenticate" header field indicates the authentication
343   scheme(s) and parameters applicable to the target resource.
344
345     WWW-Authenticate = 1#challenge
346
347   A server generating a 401 (Unauthorized) response MUST send a WWW-
348   Authenticate header field containing at least one challenge.  A
349   server MAY generate a WWW-Authenticate header field in other response
350   messages to indicate that supplying credentials (or different
351   credentials) might affect the response.
352
353   A proxy forwarding a response MUST NOT modify any WWW-Authenticate
354   fields in that response.
355
356   User agents are advised to take special care in parsing the field
357   value, as it might contain more than one challenge, and each
358   challenge can contain a comma-separated list of authentication
359   parameters.  Furthermore, the header field itself can occur multiple
360   times.
361
362   For instance:
363
364     WWW-Authenticate: Newauth realm="apps", type=1,
365                       title="Login to \"apps\"", Basic realm="simple"
366
367   This header field contains two challenges; one for the "Newauth"
368   scheme with a realm value of "apps", and two additional parameters
369   "type" and "title", and another one for the "Basic" scheme with a
370   realm value of "simple".
371
372      Note: The challenge grammar production uses the list syntax as
373      well.  Therefore, a sequence of comma, whitespace, and comma can
374      be considered either as applying to the preceding challenge, or to
375      be an empty entry in the list of challenges.  In practice, this
376      ambiguity does not affect the semantics of the header field value
377      and thus is harmless.
378
3794.2.  Authorization
380
381   The "Authorization" header field allows a user agent to authenticate
382   itself with an origin server -- usually, but not necessarily, after
383   receiving a 401 (Unauthorized) response.  Its value consists of
384   credentials containing the authentication information of the user
385   agent for the realm of the resource being requested.
386
387     Authorization = credentials
388
389
390
391Fielding & Reschke           Standards Track                    [Page 7]
392
393RFC 7235                 HTTP/1.1 Authentication                May 2014
394
395
396   If a request is authenticated and a realm specified, the same
397   credentials are presumed to be valid for all other requests within
398   this realm (assuming that the authentication scheme itself does not
399   require otherwise, such as credentials that vary according to a
400   challenge value or using synchronized clocks).
401
402   A proxy forwarding a request MUST NOT modify any Authorization fields
403   in that request.  See Section 3.2 of [RFC7234] for details of and
404   requirements pertaining to handling of the Authorization field by
405   HTTP caches.
406
4074.3.  Proxy-Authenticate
408
409   The "Proxy-Authenticate" header field consists of at least one
410   challenge that indicates the authentication scheme(s) and parameters
411   applicable to the proxy for this effective request URI (Section 5.5
412   of [RFC7230]).  A proxy MUST send at least one Proxy-Authenticate
413   header field in each 407 (Proxy Authentication Required) response
414   that it generates.
415
416     Proxy-Authenticate = 1#challenge
417
418   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
419   only to the next outbound client on the response chain.  This is
420   because only the client that chose a given proxy is likely to have
421   the credentials necessary for authentication.  However, when multiple
422   proxies are used within the same administrative domain, such as
423   office and regional caching proxies within a large corporate network,
424   it is common for credentials to be generated by the user agent and
425   passed through the hierarchy until consumed.  Hence, in such a
426   configuration, it will appear as if Proxy-Authenticate is being
427   forwarded because each proxy will send the same challenge set.
428
429   Note that the parsing considerations for WWW-Authenticate apply to
430   this header field as well; see Section 4.1 for details.
431
4324.4.  Proxy-Authorization
433
434   The "Proxy-Authorization" header field allows the client to identify
435   itself (or its user) to a proxy that requires authentication.  Its
436   value consists of credentials containing the authentication
437   information of the client for the proxy and/or realm of the resource
438   being requested.
439
440     Proxy-Authorization = credentials
441
442   Unlike Authorization, the Proxy-Authorization header field applies
443   only to the next inbound proxy that demanded authentication using the
444
445
446
447Fielding & Reschke           Standards Track                    [Page 8]
448
449RFC 7235                 HTTP/1.1 Authentication                May 2014
450
451
452   Proxy-Authenticate field.  When multiple proxies are used in a chain,
453   the Proxy-Authorization header field is consumed by the first inbound
454   proxy that was expecting to receive credentials.  A proxy MAY relay
455   the credentials from the client request to the next proxy if that is
456   the mechanism by which the proxies cooperatively authenticate a given
457   request.
458
4595.  IANA Considerations
460
4615.1.  Authentication Scheme Registry
462
463   The "HTTP Authentication Schemes" registry defines the name space for
464   the authentication schemes in challenges and credentials.  The
465   registry has been created and is now maintained at
466   <http://www.iana.org/assignments/http-authschemes>.
467
4685.1.1.  Procedure
469
470   Registrations MUST include the following fields:
471
472   o  Authentication Scheme Name
473
474   o  Pointer to specification text
475
476   o  Notes (optional)
477
478   Values to be added to this name space require IETF Review (see
479   [RFC5226], Section 4.1).
480
4815.1.2.  Considerations for New Authentication Schemes
482
483   There are certain aspects of the HTTP Authentication Framework that
484   put constraints on how new authentication schemes can work:
485
486   o  HTTP authentication is presumed to be stateless: all of the
487      information necessary to authenticate a request MUST be provided
488      in the request, rather than be dependent on the server remembering
489      prior requests.  Authentication based on, or bound to, the
490      underlying connection is outside the scope of this specification
491      and inherently flawed unless steps are taken to ensure that the
492      connection cannot be used by any party other than the
493      authenticated user (see Section 2.3 of [RFC7230]).
494
495   o  The authentication parameter "realm" is reserved for defining
496      protection spaces as described in Section 2.2.  New schemes MUST
497      NOT use it in a way incompatible with that definition.
498
499
500
501
502
503Fielding & Reschke           Standards Track                    [Page 9]
504
505RFC 7235                 HTTP/1.1 Authentication                May 2014
506
507
508   o  The "token68" notation was introduced for compatibility with
509      existing authentication schemes and can only be used once per
510      challenge or credential.  Thus, new schemes ought to use the auth-
511      param syntax instead, because otherwise future extensions will be
512      impossible.
513
514   o  The parsing of challenges and credentials is defined by this
515      specification and cannot be modified by new authentication
516      schemes.  When the auth-param syntax is used, all parameters ought
517      to support both token and quoted-string syntax, and syntactical
518      constraints ought to be defined on the field value after parsing
519      (i.e., quoted-string processing).  This is necessary so that
520      recipients can use a generic parser that applies to all
521      authentication schemes.
522
523      Note: The fact that the value syntax for the "realm" parameter is
524      restricted to quoted-string was a bad design choice not to be
525      repeated for new parameters.
526
527   o  Definitions of new schemes ought to define the treatment of
528      unknown extension parameters.  In general, a "must-ignore" rule is
529      preferable to a "must-understand" rule, because otherwise it will
530      be hard to introduce new parameters in the presence of legacy
531      recipients.  Furthermore, it's good to describe the policy for
532      defining new parameters (such as "update the specification" or
533      "use this registry").
534
535   o  Authentication schemes need to document whether they are usable in
536      origin-server authentication (i.e., using WWW-Authenticate),
537      and/or proxy authentication (i.e., using Proxy-Authenticate).
538
539   o  The credentials carried in an Authorization header field are
540      specific to the user agent and, therefore, have the same effect on
541      HTTP caches as the "private" Cache-Control response directive
542      (Section 5.2.2.6 of [RFC7234]), within the scope of the request in
543      which they appear.
544
545      Therefore, new authentication schemes that choose not to carry
546      credentials in the Authorization header field (e.g., using a newly
547      defined header field) will need to explicitly disallow caching, by
548      mandating the use of either Cache-Control request directives
549      (e.g., "no-store", Section 5.2.1.5 of [RFC7234]) or response
550      directives (e.g., "private").
551
552
553
554
555
556
557
558
559Fielding & Reschke           Standards Track                   [Page 10]
560
561RFC 7235                 HTTP/1.1 Authentication                May 2014
562
563
5645.2.  Status Code Registration
565
566   The HTTP Status Code Registry located at
567   <http://www.iana.org/assignments/http-status-codes> shall be updated
568   with the registrations below:
569
570   +-------+-------------------------------+-------------+
571   | Value | Description                   | Reference   |
572   +-------+-------------------------------+-------------+
573   | 401   | Unauthorized                  | Section 3.1 |
574   | 407   | Proxy Authentication Required | Section 3.2 |
575   +-------+-------------------------------+-------------+
576
5775.3.  Header Field Registration
578
579   HTTP header fields are registered within the Message Header Field
580   Registry maintained at
581   <http://www.iana.org/assignments/message-headers>.
582
583   This document defines the following HTTP header fields, so their
584   associated registry entries have been updated according to the
585   permanent registrations below (see [BCP90]):
586
587   +---------------------+----------+----------+-------------+
588   | Header Field Name   | Protocol | Status   | Reference   |
589   +---------------------+----------+----------+-------------+
590   | Authorization       | http     | standard | Section 4.2 |
591   | Proxy-Authenticate  | http     | standard | Section 4.3 |
592   | Proxy-Authorization | http     | standard | Section 4.4 |
593   | WWW-Authenticate    | http     | standard | Section 4.1 |
594   +---------------------+----------+----------+-------------+
595
596   The change controller is: "IETF (iesg@ietf.org) - Internet
597   Engineering Task Force".
598
5996.  Security Considerations
600
601   This section is meant to inform developers, information providers,
602   and users of known security concerns specific to HTTP authentication.
603   More general security considerations are addressed in HTTP messaging
604   [RFC7230] and semantics [RFC7231].
605
606   Everything about the topic of HTTP authentication is a security
607   consideration, so the list of considerations below is not exhaustive.
608   Furthermore, it is limited to security considerations regarding the
609   authentication framework, in general, rather than discussing all of
610   the potential considerations for specific authentication schemes
611   (which ought to be documented in the specifications that define those
612
613
614
615Fielding & Reschke           Standards Track                   [Page 11]
616
617RFC 7235                 HTTP/1.1 Authentication                May 2014
618
619
620   schemes).  Various organizations maintain topical information and
621   links to current research on Web application security (e.g.,
622   [OWASP]), including common pitfalls for implementing and using the
623   authentication schemes found in practice.
624
6256.1.  Confidentiality of Credentials
626
627   The HTTP authentication framework does not define a single mechanism
628   for maintaining the confidentiality of credentials; instead, each
629   authentication scheme defines how the credentials are encoded prior
630   to transmission.  While this provides flexibility for the development
631   of future authentication schemes, it is inadequate for the protection
632   of existing schemes that provide no confidentiality on their own, or
633   that do not sufficiently protect against replay attacks.
634   Furthermore, if the server expects credentials that are specific to
635   each individual user, the exchange of those credentials will have the
636   effect of identifying that user even if the content within
637   credentials remains confidential.
638
639   HTTP depends on the security properties of the underlying transport
640   or session-level connection to provide confidential transmission of
641   header fields.  In other words, if a server limits access to
642   authenticated users using this framework, the server needs to ensure
643   that the connection is properly secured in accordance with the nature
644   of the authentication scheme used.  For example, services that depend
645   on individual user authentication often require a connection to be
646   secured with TLS ("Transport Layer Security", [RFC5246]) prior to
647   exchanging any credentials.
648
6496.2.  Authentication Credentials and Idle Clients
650
651   Existing HTTP clients and user agents typically retain authentication
652   information indefinitely.  HTTP does not provide a mechanism for the
653   origin server to direct clients to discard these cached credentials,
654   since the protocol has no awareness of how credentials are obtained
655   or managed by the user agent.  The mechanisms for expiring or
656   revoking credentials can be specified as part of an authentication
657   scheme definition.
658
659   Circumstances under which credential caching can interfere with the
660   application's security model include but are not limited to:
661
662   o  Clients that have been idle for an extended period, following
663      which the server might wish to cause the client to re-prompt the
664      user for credentials.
665
666   o  Applications that include a session termination indication (such
667      as a "logout" or "commit" button on a page) after which the server
668
669
670
671Fielding & Reschke           Standards Track                   [Page 12]
672
673RFC 7235                 HTTP/1.1 Authentication                May 2014
674
675
676      side of the application "knows" that there is no further reason
677      for the client to retain the credentials.
678
679   User agents that cache credentials are encouraged to provide a
680   readily accessible mechanism for discarding cached credentials under
681   user control.
682
6836.3.  Protection Spaces
684
685   Authentication schemes that solely rely on the "realm" mechanism for
686   establishing a protection space will expose credentials to all
687   resources on an origin server.  Clients that have successfully made
688   authenticated requests with a resource can use the same
689   authentication credentials for other resources on the same origin
690   server.  This makes it possible for a different resource to harvest
691   authentication credentials for other resources.
692
693   This is of particular concern when an origin server hosts resources
694   for multiple parties under the same canonical root URI (Section 2.2).
695   Possible mitigation strategies include restricting direct access to
696   authentication credentials (i.e., not making the content of the
697   Authorization request header field available), and separating
698   protection spaces by using a different host name (or port number) for
699   each party.
700
7017.  Acknowledgments
702
703   This specification takes over the definition of the HTTP
704   Authentication Framework, previously defined in RFC 2617.  We thank
705   John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D.
706   Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for
707   their work on that specification.  See Section 6 of [RFC2617] for
708   further acknowledgements.
709
710   See Section 10 of [RFC7230] for the Acknowledgments related to this
711   document revision.
712
7138.  References
714
7158.1.  Normative References
716
717   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
718              Requirement Levels", BCP 14, RFC 2119, March 1997.
719
720   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
721              Specifications: ABNF", STD 68, RFC 5234, January 2008.
722
723   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
724
725
726
727Fielding & Reschke           Standards Track                   [Page 13]
728
729RFC 7235                 HTTP/1.1 Authentication                May 2014
730
731
732              Protocol (HTTP/1.1): Message Syntax and Routing",
733              RFC 7230, May 2014.
734
735   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
736              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
737              May 2014.
738
739   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
740              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
741              RFC 7234, May 2014.
742
7438.2.  Informative References
744
745   [BCP90]    Klyne, G., Nottingham, M., and J. Mogul, "Registration
746              Procedures for Message Header Fields", BCP 90, RFC 3864,
747              September 2004.
748
749   [OWASP]    van der Stock, A., Ed., "A Guide to Building Secure Web
750              Applications and Web Services", The Open Web Application
751              Security Project (OWASP) 2.0.1, July 2005,
752              <https://www.owasp.org/>.
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
774   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
775              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
776
777
778
779
780
781
782
783Fielding & Reschke           Standards Track                   [Page 14]
784
785RFC 7235                 HTTP/1.1 Authentication                May 2014
786
787
788Appendix A.  Changes from RFCs 2616 and 2617
789
790   The framework for HTTP Authentication is now defined by this
791   document, rather than RFC 2617.
792
793   The "realm" parameter is no longer always required on challenges;
794   consequently, the ABNF allows challenges without any auth parameters.
795   (Section 2)
796
797   The "token68" alternative to auth-param lists has been added for
798   consistency with legacy authentication schemes such as "Basic".
799   (Section 2)
800
801   This specification introduces the Authentication Scheme Registry,
802   along with considerations for new authentication schemes.
803   (Section 5.1)
804
805Appendix B.  Imported ABNF
806
807   The following core rules are included by reference, as defined in
808   Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
809   CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
810   quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
811   8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
812   character).
813
814   The rules below are defined in [RFC7230]:
815
816     BWS           = <BWS, see [RFC7230], Section 3.2.3>
817     OWS           = <OWS, see [RFC7230], Section 3.2.3>
818     quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
819     token         = <token, see [RFC7230], Section 3.2.6>
820
821Appendix C.  Collected ABNF
822
823   In the collected ABNF below, list rules are expanded as per Section
824   1.2 of [RFC7230].
825
826
827
828
829
830
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  7
879
880   C
881      Canonical Root URI  5
882
883   G
884      Grammar
885         auth-param  4
886         auth-scheme  4
887         Authorization  7
888         challenge  4
889         credentials  5
890         Proxy-Authenticate  8
891         Proxy-Authorization  8
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  8
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.