idnits 2.17.1
draft-ietf-httpbis-p7-auth-18.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The draft header indicates that this document updates RFC2617, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC2617, updated by this document, for
RFC5378 checks: 1997-12-01)
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (January 4, 2012) is 4496 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p1-messaging-18
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p6-cache-18
-- Obsolete informational reference (is this intentional?): RFC 2616
(Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Obsolete informational reference (is this intentional?): RFC 2617
(Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617)
-- Obsolete informational reference (is this intentional?): RFC 5226
(Obsoleted by RFC 8126)
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 HTTPbis Working Group R. Fielding, Ed.
3 Internet-Draft Adobe
4 Obsoletes: 2616 (if approved) J. Gettys
5 Updates: 2617 (if approved) Alcatel-Lucent
6 Intended status: Standards Track J. Mogul
7 Expires: July 7, 2012 HP
8 H. Frystyk
9 Microsoft
10 L. Masinter
11 Adobe
12 P. Leach
13 Microsoft
14 T. Berners-Lee
15 W3C/MIT
16 Y. Lafon, Ed.
17 W3C
18 J. Reschke, Ed.
19 greenbytes
20 January 4, 2012
22 HTTP/1.1, part 7: Authentication
23 draft-ietf-httpbis-p7-auth-18
25 Abstract
27 The Hypertext Transfer Protocol (HTTP) is an application-level
28 protocol for distributed, collaborative, hypermedia information
29 systems. HTTP has been in use by the World Wide Web global
30 information initiative since 1990. This document is Part 7 of the
31 seven-part specification that defines the protocol referred to as
32 "HTTP/1.1" and, taken together, obsoletes RFC 2616.
34 Part 7 defines the HTTP Authentication framework.
36 Editorial Note (To be removed by RFC Editor)
38 Discussion of this draft should take place on the HTTPBIS working
39 group mailing list (ietf-http-wg@w3.org), which is archived at
40 .
42 The current issues list is at
43 and related
44 documents (including fancy diffs) can be found at
45 .
47 The changes in this draft are summarized in Appendix C.19.
49 Status of This Memo
51 This Internet-Draft is submitted in full conformance with the
52 provisions of BCP 78 and BCP 79.
54 Internet-Drafts are working documents of the Internet Engineering
55 Task Force (IETF). Note that other groups may also distribute
56 working documents as Internet-Drafts. The list of current Internet-
57 Drafts is at http://datatracker.ietf.org/drafts/current/.
59 Internet-Drafts are draft documents valid for a maximum of six months
60 and may be updated, replaced, or obsoleted by other documents at any
61 time. It is inappropriate to use Internet-Drafts as reference
62 material or to cite them other than as "work in progress."
64 This Internet-Draft will expire on July 7, 2012.
66 Copyright Notice
68 Copyright (c) 2012 IETF Trust and the persons identified as the
69 document authors. All rights reserved.
71 This document is subject to BCP 78 and the IETF Trust's Legal
72 Provisions Relating to IETF Documents
73 (http://trustee.ietf.org/license-info) in effect on the date of
74 publication of this document. Please review these documents
75 carefully, as they describe your rights and restrictions with respect
76 to this document. Code Components extracted from this document must
77 include Simplified BSD License text as described in Section 4.e of
78 the Trust Legal Provisions and are provided without warranty as
79 described in the Simplified BSD License.
81 This document may contain material from IETF Documents or IETF
82 Contributions published or made publicly available before November
83 10, 2008. The person(s) controlling the copyright in some of this
84 material may not have granted the IETF Trust the right to allow
85 modifications of such material outside the IETF Standards Process.
86 Without obtaining an adequate license from the person(s) controlling
87 the copyright in such materials, this document may not be modified
88 outside the IETF Standards Process, and derivative works of it may
89 not be created outside the IETF Standards Process, except to format
90 it for publication as an RFC or to translate it into languages other
91 than English.
93 Table of Contents
95 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
96 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 5
97 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
98 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
99 2. Access Authentication Framework . . . . . . . . . . . . . . . 6
100 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 6
101 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 8
102 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 8
103 2.3.1. Considerations for New Authentication Schemes . . . . 9
104 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 10
105 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 10
106 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 10
107 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 10
108 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 11
109 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 11
110 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 12
111 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 12
112 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
113 5.1. Authenticaton Scheme Registry . . . . . . . . . . . . . . 13
114 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 13
115 5.3. Header Field Registration . . . . . . . . . . . . . . . . 13
116 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
117 6.1. Authentication Credentials and Idle Clients . . . . . . . 14
118 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
119 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
120 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
121 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
122 Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16
123 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 16
124 Appendix C. Change Log (to be removed by RFC Editor before
125 publication) . . . . . . . . . . . . . . . . . . . . 17
126 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 17
127 C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 17
128 C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 17
129 C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 17
130 C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 17
131 C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 17
132 C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 18
133 C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 18
134 C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 18
135 C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 18
136 C.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 18
137 C.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 18
138 C.13. Since draft-ietf-httpbis-p7-auth-11 . . . . . . . . . . . 18
139 C.14. Since draft-ietf-httpbis-p7-auth-12 . . . . . . . . . . . 19
140 C.15. Since draft-ietf-httpbis-p7-auth-13 . . . . . . . . . . . 19
141 C.16. Since draft-ietf-httpbis-p7-auth-14 . . . . . . . . . . . 19
142 C.17. Since draft-ietf-httpbis-p7-auth-15 . . . . . . . . . . . 19
143 C.18. Since draft-ietf-httpbis-p7-auth-16 . . . . . . . . . . . 20
144 C.19. Since draft-ietf-httpbis-p7-auth-17 . . . . . . . . . . . 20
146 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
148 1. Introduction
150 This document defines HTTP/1.1 access control and authentication. It
151 includes the relevant parts of RFC 2616 with only minor changes, plus
152 the general framework for HTTP authentication, as previously defined
153 in "HTTP Authentication: Basic and Digest Access Authentication"
154 ([RFC2617]).
156 HTTP provides several OPTIONAL challenge-response authentication
157 mechanisms which can be used by a server to challenge a client
158 request and by a client to provide authentication information. The
159 "basic" and "digest" authentication schemes continue to be specified
160 in RFC 2617.
162 1.1. Conformance and Error Handling
164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
166 document are to be interpreted as described in [RFC2119].
168 This document defines conformance criteria for several roles in HTTP
169 communication, including Senders, Recipients, Clients, Servers, User-
170 Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
171 Section 2 of [Part1] for definitions of these terms.
173 An implementation is considered conformant if it complies with all of
174 the requirements associated with its role(s). Note that SHOULD-level
175 requirements are relevant here, unless one of the documented
176 exceptions is applicable.
178 This document also uses ABNF to define valid protocol elements
179 (Section 1.2). In addition to the prose requirements placed upon
180 them, Senders MUST NOT generate protocol elements that are invalid.
182 Unless noted otherwise, Recipients MAY take steps to recover a usable
183 protocol element from an invalid construct. However, HTTP does not
184 define specific error handling mechanisms, except in cases where it
185 has direct impact on security. This is because different uses of the
186 protocol require different error handling strategies; for example, a
187 Web browser may wish to transparently recover from a response where
188 the Location header field doesn't parse according to the ABNF,
189 whereby in a systems control protocol using HTTP, this type of error
190 recovery could lead to dangerous consequences.
192 1.2. Syntax Notation
194 This specification uses the ABNF syntax defined in Section 1.2 of
195 [Part1] (which extends the syntax defined in [RFC5234] with a list
196 rule). Appendix B shows the collected ABNF, with the list rule
197 expanded.
199 The following core rules are included by reference, as defined in
200 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
201 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
202 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
203 sequence of data), SP (space), and VCHAR (any visible US-ASCII
204 character).
206 1.2.1. Core Rules
208 The core rules below are defined in [Part1]:
210 BWS =
211 OWS =
212 quoted-string =
213 token =
215 2. Access Authentication Framework
217 2.1. Challenge and Response
219 HTTP provides a simple challenge-response authentication mechanism
220 that can be used by a server to challenge a client request and by a
221 client to provide authentication information. It uses an extensible,
222 case-insensitive token to identify the authentication scheme,
223 followed by additional information necessary for achieving
224 authentication via that scheme. The latter can either be a comma-
225 separated list of parameters or a single sequence of characters
226 capable of holding base64-encoded information.
228 Parameters are name-value pairs where the name is matched case-
229 insensitively, and each parameter name MUST only occur once per
230 challenge.
232 auth-scheme = token
234 auth-param = token BWS "=" BWS ( token / quoted-string )
236 b64token = 1*( ALPHA / DIGIT /
237 "-" / "." / "_" / "~" / "+" / "/" ) *"="
239 The "b64token" syntax allows the 66 unreserved URI characters
240 ([RFC3986]), plus a few others, so that it can hold a base64,
241 base64url (URL and filename safe alphabet), base32, or base16 (hex)
242 encoding, with or without padding, but excluding whitespace
243 ([RFC4648]).
245 The 401 (Unauthorized) response message is used by an origin server
246 to challenge the authorization of a user agent. This response MUST
247 include a WWW-Authenticate header field containing at least one
248 challenge applicable to the requested resource.
250 The 407 (Proxy Authentication Required) response message is used by a
251 proxy to challenge the authorization of a client and MUST include a
252 Proxy-Authenticate header field containing at least one challenge
253 applicable to the proxy for the requested resource.
255 challenge = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
257 Note: User agents will need to take special care in parsing the
258 WWW-Authenticate and Proxy-Authenticate header field values
259 because they can contain more than one challenge, or if more than
260 one of each is provided, since the contents of a challenge can
261 itself contain a comma-separated list of authentication
262 parameters.
264 Note: Many browsers fail to parse challenges containing unknown
265 schemes. A workaround for this problem is to list well-supported
266 schemes (such as "basic") first.
268 A user agent that wishes to authenticate itself with an origin server
269 -- usually, but not necessarily, after receiving a 401 (Unauthorized)
270 -- MAY do so by including an Authorization header field with the
271 request.
273 A client that wishes to authenticate itself with a proxy -- usually,
274 but not necessarily, after receiving a 407 (Proxy Authentication
275 Required) -- MAY do so by including a Proxy-Authorization header
276 field with the request.
278 Both the Authorization field value and the Proxy-Authorization field
279 value consist of credentials containing the authentication
280 information of the client for the realm of the resource being
281 requested. The user agent MUST choose to use one of the challenges
282 with the strongest auth-scheme it understands and request credentials
283 from the user based upon that challenge.
285 credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
287 If the origin server does not wish to accept the credentials sent
288 with a request, it SHOULD return a 401 (Unauthorized) response. The
289 response MUST include a WWW-Authenticate header field containing at
290 least one (possibly new) challenge applicable to the requested
291 resource.
293 If a proxy does not accept the credentials sent with a request, it
294 SHOULD return a 407 (Proxy Authentication Required). The response
295 MUST include a Proxy-Authenticate header field containing a (possibly
296 new) challenge applicable to the proxy for the requested resource.
298 The HTTP protocol does not restrict applications to this simple
299 challenge-response mechanism for access authentication. Additional
300 mechanisms MAY be used, such as encryption at the transport level or
301 via message encapsulation, and with additional header fields
302 specifying authentication information. However, such additional
303 mechanisms are not defined by this specification.
305 Proxies MUST forward the WWW-Authenticate and Authorization headers
306 unmodified and follow the rules found in Section 4.1.
308 2.2. Protection Space (Realm)
310 The authentication parameter realm is reserved for use by
311 authentication schemes that wish to indicate the scope of protection.
313 A protection space is defined by the canonical root URI (the scheme
314 and authority components of the effective request URI; see Section
315 4.3 of [Part1]) of the server being accessed, in combination with the
316 realm value if present. These realms allow the protected resources
317 on a server to be partitioned into a set of protection spaces, each
318 with its own authentication scheme and/or authorization database.
319 The realm value is a string, generally assigned by the origin server,
320 which can have additional semantics specific to the authentication
321 scheme. Note that there can be multiple challenges with the same
322 auth-scheme but different realms.
324 The protection space determines the domain over which credentials can
325 be automatically applied. If a prior request has been authorized,
326 the same credentials MAY be reused for all other requests within that
327 protection space for a period of time determined by the
328 authentication scheme, parameters, and/or user preference. Unless
329 otherwise defined by the authentication scheme, a single protection
330 space cannot extend outside the scope of its server.
332 For historical reasons, senders MUST only use the quoted-string
333 syntax. Recipients might have to support both token and quoted-
334 string syntax for maximum interoperability with existing clients that
335 have been accepting both notations for a long time.
337 2.3. Authentication Scheme Registry
339 The HTTP Authentication Scheme Registry defines the name space for
340 the authentication schemes in challenges and credentials.
342 Registrations MUST include the following fields:
344 o Authentication Scheme Name
346 o Pointer to specification text
348 o Notes (optional)
350 Values to be added to this name space are subject to IETF review
351 ([RFC5226], Section 4.1).
353 The registry itself is maintained at
354 .
356 2.3.1. Considerations for New Authentication Schemes
358 There are certain aspects of the HTTP Authentication Framework that
359 put constraints on how new authentication schemes can work:
361 o Authentication schemes need to be compatible with the inherent
362 constraints of HTTP; for instance, that messages need to keep
363 their semantics when inspected in isolation, thus an
364 authentication scheme can not bind information to the TCP session
365 over which the message was received (see Section 2.2 of [Part1]).
367 o The authentication parameter "realm" is reserved for defining
368 Protection Spaces as defined in Section 2.2. New schemes MUST NOT
369 use it in a way incompatible with that definition.
371 o The "b64token" notation was introduced for compatibility with
372 existing authentication schemes and can only be used once per
373 challenge/credentials. New schemes thus ought to use the "auth-
374 param" syntax instead, because otherwise future extensions will be
375 impossible.
377 o The parsing of challenges and credentials is defined by this
378 specification, and cannot be modified by new authentication
379 schemes. When the auth-param syntax is used, all parameters ought
380 to support both token and quoted-string syntax, and syntactical
381 constraints ought to be defined on the field value after parsing
382 (i.e., quoted-string processing). This is necessary so that
383 recipients can use a generic parser that applies to all
384 authentication schemes.
386 Note: the fact that the value syntax for the "realm" parameter is
387 restricted to quoted-string was a bad design choice not to be
388 repeated for new parameters.
390 o Authentication schemes need to document whether they are usable in
391 origin-server authentication (i.e., using WWW-Authenticate),
392 and/or proxy authentication (i.e., using Proxy-Authenticate).
394 o The credentials carried in an Authorization header field are
395 specific to the User Agent, and therefore have the same effect on
396 HTTP caches as the "private" Cache-Control response directive,
397 within the scope of the request they appear in.
399 Therefore, new authentication schemes which choose not to carry
400 credentials in the Authorization header (e.g., using a newly
401 defined header) will need to explicitly disallow caching, by
402 mandating the use of either Cache-Control request directives
403 (e.g., "no-store") or response directives (e.g., "private").
405 3. Status Code Definitions
407 3.1. 401 Unauthorized
409 The request requires user authentication. The response MUST include
410 a WWW-Authenticate header field (Section 4.4) containing a challenge
411 applicable to the target resource. The client MAY repeat the request
412 with a suitable Authorization header field (Section 4.1). If the
413 request already included Authorization credentials, then the 401
414 response indicates that authorization has been refused for those
415 credentials. If the 401 response contains the same challenge as the
416 prior response, and the user agent has already attempted
417 authentication at least once, then the user SHOULD be presented the
418 representation that was given in the response, since that
419 representation might include relevant diagnostic information.
421 3.2. 407 Proxy Authentication Required
423 This code is similar to 401 (Unauthorized), but indicates that the
424 client ought to first authenticate itself with the proxy. The proxy
425 MUST return a Proxy-Authenticate header field (Section 4.2)
426 containing a challenge applicable to the proxy for the target
427 resource. The client MAY repeat the request with a suitable Proxy-
428 Authorization header field (Section 4.3).
430 4. Header Field Definitions
432 This section defines the syntax and semantics of HTTP/1.1 header
433 fields related to authentication.
435 4.1. Authorization
437 The "Authorization" header field allows a user agent to authenticate
438 itself with a server -- usually, but not necessarily, after receiving
439 a 401 (Unauthorized) response. Its value consists of credentials
440 containing information of the user agent for the realm of the
441 resource being requested.
443 Authorization = credentials
445 If a request is authenticated and a realm specified, the same
446 credentials SHOULD be valid for all other requests within this realm
447 (assuming that the authentication scheme itself does not require
448 otherwise, such as credentials that vary according to a challenge
449 value or using synchronized clocks).
451 When a shared cache (see Section 1.2 of [Part6]) receives a request
452 containing an Authorization field, it MUST NOT return the
453 corresponding response as a reply to any other request, unless one of
454 the following specific exceptions holds:
456 1. If the response includes the "s-maxage" cache-control directive,
457 the cache MAY use that response in replying to a subsequent
458 request. But (if the specified maximum age has passed) a proxy
459 cache MUST first revalidate it with the origin server, using the
460 header fields from the new request to allow the origin server to
461 authenticate the new request. (This is the defined behavior for
462 s-maxage.) If the response includes "s-maxage=0", the proxy MUST
463 always revalidate it before re-using it.
465 2. If the response includes the "must-revalidate" cache-control
466 directive, the cache MAY use that response in replying to a
467 subsequent request. But if the response is stale, all caches
468 MUST first revalidate it with the origin server, using the header
469 fields from the new request to allow the origin server to
470 authenticate the new request.
472 3. If the response includes the "public" cache-control directive, it
473 MAY be returned in reply to any subsequent request.
475 4.2. Proxy-Authenticate
477 The "Proxy-Authenticate" header field consists of a challenge that
478 indicates the authentication scheme and parameters applicable to the
479 proxy for this effective request URI (Section 4.3 of [Part1]). It
480 MUST be included as part of a 407 (Proxy Authentication Required)
481 response.
483 Proxy-Authenticate = 1#challenge
485 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
486 only to the current connection and SHOULD NOT be passed on to
487 downstream clients. However, an intermediate proxy might need to
488 obtain its own credentials by requesting them from the downstream
489 client, which in some circumstances will appear as if the proxy is
490 forwarding the Proxy-Authenticate header field.
492 4.3. Proxy-Authorization
494 The "Proxy-Authorization" header field allows the client to identify
495 itself (or its user) to a proxy which requires authentication. Its
496 value consists of credentials containing the authentication
497 information of the user agent for the proxy and/or realm of the
498 resource being requested.
500 Proxy-Authorization = credentials
502 Unlike Authorization, the Proxy-Authorization header field applies
503 only to the next outbound proxy that demanded authentication using
504 the Proxy-Authenticate field. When multiple proxies are used in a
505 chain, the Proxy-Authorization header field is consumed by the first
506 outbound proxy that was expecting to receive credentials. A proxy
507 MAY relay the credentials from the client request to the next proxy
508 if that is the mechanism by which the proxies cooperatively
509 authenticate a given request.
511 4.4. WWW-Authenticate
513 The "WWW-Authenticate" header field consists of at least one
514 challenge that indicates the authentication scheme(s) and parameters
515 applicable to the effective request URI (Section 4.3 of [Part1]).
517 It MUST be included in 401 (Unauthorized) response messages and MAY
518 be included in other response messages to indicate that supplying
519 credentials (or different credentials) might affect the response.
521 WWW-Authenticate = 1#challenge
523 User agents are advised to take special care in parsing the WWW-
524 Authenticate field value as it might contain more than one challenge,
525 or if more than one WWW-Authenticate header field is provided, the
526 contents of a challenge itself can contain a comma-separated list of
527 authentication parameters.
529 For instance:
531 WWW-Authenticate: Newauth realm="apps", type=1,
532 title="Login to \"apps\"", Basic realm="simple"
534 This header field contains two challenges; one for the "Newauth"
535 scheme with a realm value of "apps", and two additional parameters
536 "type" and "title", and another one for the "Basic" scheme with a
537 realm value of "simple".
539 5. IANA Considerations
541 5.1. Authenticaton Scheme Registry
543 The registration procedure for HTTP Authentication Schemes is defined
544 by Section 2.3 of this document.
546 The HTTP Method Authentication Scheme shall be created at
547 .
549 5.2. Status Code Registration
551 The HTTP Status Code Registry located at
552 shall be updated
553 with the registrations below:
555 +-------+-------------------------------+-------------+
556 | Value | Description | Reference |
557 +-------+-------------------------------+-------------+
558 | 401 | Unauthorized | Section 3.1 |
559 | 407 | Proxy Authentication Required | Section 3.2 |
560 +-------+-------------------------------+-------------+
562 5.3. Header Field Registration
564 The Message Header Field Registry located at shall be
566 updated with the permanent registrations below (see [RFC3864]):
568 +---------------------+----------+----------+-------------+
569 | Header Field Name | Protocol | Status | Reference |
570 +---------------------+----------+----------+-------------+
571 | Authorization | http | standard | Section 4.1 |
572 | Proxy-Authenticate | http | standard | Section 4.2 |
573 | Proxy-Authorization | http | standard | Section 4.3 |
574 | WWW-Authenticate | http | standard | Section 4.4 |
575 +---------------------+----------+----------+-------------+
576 The change controller is: "IETF (iesg@ietf.org) - Internet
577 Engineering Task Force".
579 6. Security Considerations
581 This section is meant to inform application developers, information
582 providers, and users of the security limitations in HTTP/1.1 as
583 described by this document. The discussion does not include
584 definitive solutions to the problems revealed, though it does make
585 some suggestions for reducing security risks.
587 6.1. Authentication Credentials and Idle Clients
589 Existing HTTP clients and user agents typically retain authentication
590 information indefinitely. HTTP/1.1 does not provide a method for a
591 server to direct clients to discard these cached credentials. This
592 is a significant defect that requires further extensions to HTTP.
593 Circumstances under which credential caching can interfere with the
594 application's security model include but are not limited to:
596 o Clients which have been idle for an extended period following
597 which the server might wish to cause the client to reprompt the
598 user for credentials.
600 o Applications which include a session termination indication (such
601 as a "logout" or "commit" button on a page) after which the server
602 side of the application "knows" that there is no further reason
603 for the client to retain the credentials.
605 This is currently under separate study. There are a number of work-
606 arounds to parts of this problem, and we encourage the use of
607 password protection in screen savers, idle time-outs, and other
608 methods which mitigate the security problems inherent in this
609 problem. In particular, user agents which cache credentials are
610 encouraged to provide a readily accessible mechanism for discarding
611 cached credentials under user control.
613 7. Acknowledgments
615 This specification takes over the definition of the HTTP
616 Authentication Framework, previously defined in RFC 2617. We thank
617 John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D.
618 Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for
619 their work on that specification. See Section 6 of [RFC2617] for
620 further acknowledgements.
622 See Section 11 of [Part1] for the Acknowledgments related to this
623 document revision.
625 8. References
627 8.1. Normative References
629 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
630 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
631 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
632 and Message Parsing", draft-ietf-httpbis-p1-messaging-18
633 (work in progress), January 2012.
635 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
636 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
637 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
638 6: Caching", draft-ietf-httpbis-p6-cache-18 (work in
639 progress), January 2012.
641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
642 Requirement Levels", BCP 14, RFC 2119, March 1997.
644 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
645 Specifications: ABNF", STD 68, RFC 5234, January 2008.
647 8.2. Informative References
649 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
650 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
651 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
653 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
654 Leach, P., Luotonen, A., and L. Stewart, "HTTP
655 Authentication: Basic and Digest Access Authentication",
656 RFC 2617, June 1999.
658 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
659 Procedures for Message Header Fields", BCP 90, RFC 3864,
660 September 2004.
662 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
663 Resource Identifier (URI): Generic Syntax", STD 66,
664 RFC 3986, January 2005.
666 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
667 Encodings", RFC 4648, October 2006.
669 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
670 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
671 May 2008.
673 Appendix A. Changes from RFCs 2616 and 2617
675 The "realm" parameter isn't required anymore in general;
676 consequently, the ABNF allows challenges without any auth parameters.
677 (Section 2)
679 The "b64token" alternative to auth-param lists has been added for
680 consistency with legacy authentication schemes such as "Basic".
681 (Section 2)
683 Change ABNF productions for header fields to only define the field
684 value. (Section 4)
686 Appendix B. Collected ABNF
688 Authorization = credentials
690 BWS =
692 OWS =
694 Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
695 challenge ] )
696 Proxy-Authorization = credentials
698 WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
699 ] )
701 auth-param = token BWS "=" BWS ( token / quoted-string )
702 auth-scheme = token
704 b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
705 *"="
707 challenge = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) *(
708 OWS "," [ OWS auth-param ] ) ] ) ]
709 credentials = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param )
710 *( OWS "," [ OWS auth-param ] ) ] ) ]
712 quoted-string =
714 token =
715 ABNF diagnostics:
717 ; Authorization defined but not used
718 ; Proxy-Authenticate defined but not used
719 ; Proxy-Authorization defined but not used
720 ; WWW-Authenticate defined but not used
722 Appendix C. Change Log (to be removed by RFC Editor before publication)
724 C.1. Since RFC 2616
726 Extracted relevant partitions from [RFC2616].
728 C.2. Since draft-ietf-httpbis-p7-auth-00
730 Closed issues:
732 o : "Normative and
733 Informative references"
735 C.3. Since draft-ietf-httpbis-p7-auth-01
737 Ongoing work on ABNF conversion
738 ():
740 o Explicitly import BNF rules for "challenge" and "credentials" from
741 RFC2617.
743 o Add explicit references to BNF syntax and rules imported from
744 other parts of the specification.
746 C.4. Since draft-ietf-httpbis-p7-auth-02
748 Ongoing work on IANA Message Header Field Registration
749 ():
751 o Reference RFC 3984, and update header field registrations for
752 header fields defined in this document.
754 C.5. Since draft-ietf-httpbis-p7-auth-03
756 None.
758 C.6. Since draft-ietf-httpbis-p7-auth-04
760 Ongoing work on ABNF conversion
761 ():
763 o Use "/" instead of "|" for alternatives.
765 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
766 whitespace ("OWS") and required whitespace ("RWS").
768 o Rewrite ABNFs to spell out whitespace rules, factor out header
769 field value format definitions.
771 C.7. Since draft-ietf-httpbis-p7-auth-05
773 Final work on ABNF conversion
774 ():
776 o Add appendix containing collected and expanded ABNF, reorganize
777 ABNF introduction.
779 C.8. Since draft-ietf-httpbis-p7-auth-06
781 None.
783 C.9. Since draft-ietf-httpbis-p7-auth-07
785 Closed issues:
787 o : "move IANA
788 registrations for optional status codes"
790 C.10. Since draft-ietf-httpbis-p7-auth-08
792 No significant changes.
794 C.11. Since draft-ietf-httpbis-p7-auth-09
796 Partly resolved issues:
798 o : "Term for the
799 requested resource's URI"
801 C.12. Since draft-ietf-httpbis-p7-auth-10
803 None.
805 C.13. Since draft-ietf-httpbis-p7-auth-11
807 Closed issues:
809 o : "introduction
810 to part 7 is work-in-progress"
812 o : "auth-param
813 syntax"
815 o : "Header
816 Classification"
818 o : "absorbing the
819 auth framework from 2617"
821 Partly resolved issues:
823 o : "should we
824 have an auth scheme registry"
826 C.14. Since draft-ietf-httpbis-p7-auth-12
828 None.
830 C.15. Since draft-ietf-httpbis-p7-auth-13
832 Closed issues:
834 o : "untangle
835 ABNFs for header fields"
837 C.16. Since draft-ietf-httpbis-p7-auth-14
839 None.
841 C.17. Since draft-ietf-httpbis-p7-auth-15
843 Closed issues:
845 o : "Relationship
846 between 401, Authorization and WWW-Authenticate"
848 o : "Realm
849 required on challenges"
851 o : "auth-param
852 syntax"
854 o :
855 "Considerations for new authentications schemes"
857 o : "LWS in auth-
858 param ABNF"
860 o : "credentials
861 ABNF missing SP (still using implied LWS?)"
863 C.18. Since draft-ietf-httpbis-p7-auth-16
865 Closed issues:
867 o : "Document
868 HTTP's error-handling philosophy"
870 o : "add advice on
871 defining auth scheme parameters"
873 C.19. Since draft-ietf-httpbis-p7-auth-17
875 Closed issues:
877 o : "allow
878 unquoted realm parameters"
880 o : "Repeating
881 auth-params"
883 Index
885 4
886 401 Unauthorized (status code) 10
887 407 Proxy Authentication Required (status code) 10
889 A
890 auth-param 6
891 auth-scheme 6
892 Authorization header field 11
894 B
895 b64token 6
897 C
898 challenge 7
899 credentials 7
901 G
902 Grammar
903 auth-param 6
904 auth-scheme 6
905 Authorization 11
906 b64token 6
907 challenge 7
908 credentials 7
909 Proxy-Authenticate 11
910 Proxy-Authorization 12
911 WWW-Authenticate 12
913 H
914 Header Fields
915 Authorization 11
916 Proxy-Authenticate 11
917 Proxy-Authorization 12
918 WWW-Authenticate 12
920 P
921 Protection Space 8
922 Proxy-Authenticate header field 11
923 Proxy-Authorization header field 12
925 R
926 Realm 8
928 S
929 Status Codes
930 401 Unauthorized 10
931 407 Proxy Authentication Required 10
933 W
934 WWW-Authenticate header field 12
936 Authors' Addresses
938 Roy T. Fielding (editor)
939 Adobe Systems Incorporated
940 345 Park Ave
941 San Jose, CA 95110
942 USA
944 EMail: fielding@gbiv.com
945 URI: http://roy.gbiv.com/
946 Jim Gettys
947 Alcatel-Lucent Bell Labs
948 21 Oak Knoll Road
949 Carlisle, MA 01741
950 USA
952 EMail: jg@freedesktop.org
953 URI: http://gettys.wordpress.com/
955 Jeffrey C. Mogul
956 Hewlett-Packard Company
957 HP Labs, Large Scale Systems Group
958 1501 Page Mill Road, MS 1177
959 Palo Alto, CA 94304
960 USA
962 EMail: JeffMogul@acm.org
964 Henrik Frystyk Nielsen
965 Microsoft Corporation
966 1 Microsoft Way
967 Redmond, WA 98052
968 USA
970 EMail: henrikn@microsoft.com
972 Larry Masinter
973 Adobe Systems Incorporated
974 345 Park Ave
975 San Jose, CA 95110
976 USA
978 EMail: LMM@acm.org
979 URI: http://larry.masinter.net/
981 Paul J. Leach
982 Microsoft Corporation
983 1 Microsoft Way
984 Redmond, WA 98052
986 EMail: paulle@microsoft.com
987 Tim Berners-Lee
988 World Wide Web Consortium
989 MIT Computer Science and Artificial Intelligence Laboratory
990 The Stata Center, Building 32
991 32 Vassar Street
992 Cambridge, MA 02139
993 USA
995 EMail: timbl@w3.org
996 URI: http://www.w3.org/People/Berners-Lee/
998 Yves Lafon (editor)
999 World Wide Web Consortium
1000 W3C / ERCIM
1001 2004, rte des Lucioles
1002 Sophia-Antipolis, AM 06902
1003 France
1005 EMail: ylafon@w3.org
1006 URI: http://www.raubacapeu.net/people/yves/
1008 Julian F. Reschke (editor)
1009 greenbytes GmbH
1010 Hafenweg 16
1011 Muenster, NW 48155
1012 Germany
1014 Phone: +49 251 2807760
1015 Fax: +49 251 2807761
1016 EMail: julian.reschke@greenbytes.de
1017 URI: http://greenbytes.de/tech/webdav/