source: draft-ietf-httpbis/13/draft-ietf-httpbis-p7-auth-13.xml @ 1180

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

prepare publication of -13

  • Property svn:eol-style set to native
File size: 44.0 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!--
3    This XML document is the output of clean-for-DTD.xslt; a tool that strips
4    extensions to RFC2629(bis) from documents for processing with xml2rfc.
5-->
6<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
7<?rfc toc="yes" ?>
8<?rfc symrefs="yes" ?>
9<?rfc sortrefs="yes" ?>
10<?rfc compact="yes"?>
11<?rfc subcompact="no" ?>
12<?rfc linkmailto="no" ?>
13<?rfc editing="no" ?>
14<?rfc comments="yes"?>
15<?rfc inline="yes"?>
16<?rfc rfcedstyle="yes"?>
17<!DOCTYPE rfc
18  PUBLIC "" "rfc2629.dtd">
19<rfc obsoletes="2616" updates="2617" category="std" ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p7-auth-13">
20<front>
21
22  <title abbrev="HTTP/1.1, Part 7">HTTP/1.1, part 7: Authentication</title>
23
24  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
25    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
26    <address>
27      <postal>
28        <street>345 Park Ave</street>
29        <city>San Jose</city>
30        <region>CA</region>
31        <code>95110</code>
32        <country>USA</country>
33      </postal>
34      <email>fielding@gbiv.com</email>
35      <uri>http://roy.gbiv.com/</uri>
36    </address>
37  </author>
38
39  <author initials="J." surname="Gettys" fullname="Jim Gettys">
40    <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
41    <address>
42      <postal>
43        <street>21 Oak Knoll Road</street>
44        <city>Carlisle</city>
45        <region>MA</region>
46        <code>01741</code>
47        <country>USA</country>
48      </postal>
49      <email>jg@freedesktop.org</email>
50      <uri>http://gettys.wordpress.com/</uri>
51    </address>
52  </author>
53 
54  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
55    <organization abbrev="HP">Hewlett-Packard Company</organization>
56    <address>
57      <postal>
58        <street>HP Labs, Large Scale Systems Group</street>
59        <street>1501 Page Mill Road, MS 1177</street>
60        <city>Palo Alto</city>
61        <region>CA</region>
62        <code>94304</code>
63        <country>USA</country>
64      </postal>
65      <email>JeffMogul@acm.org</email>
66    </address>
67  </author>
68
69  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
70    <organization abbrev="Microsoft">Microsoft Corporation</organization>
71    <address>
72      <postal>
73        <street>1 Microsoft Way</street>
74        <city>Redmond</city>
75        <region>WA</region>
76        <code>98052</code>
77        <country>USA</country>
78      </postal>
79      <email>henrikn@microsoft.com</email>
80    </address>
81  </author>
82
83  <author initials="L." surname="Masinter" fullname="Larry Masinter">
84    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
85    <address>
86      <postal>
87        <street>345 Park Ave</street>
88        <city>San Jose</city>
89        <region>CA</region>
90        <code>95110</code>
91        <country>USA</country>
92      </postal>
93      <email>LMM@acm.org</email>
94      <uri>http://larry.masinter.net/</uri>
95    </address>
96  </author>
97 
98  <author initials="P." surname="Leach" fullname="Paul J. Leach">
99    <organization abbrev="Microsoft">Microsoft Corporation</organization>
100    <address>
101      <postal>
102        <street>1 Microsoft Way</street>
103        <city>Redmond</city>
104        <region>WA</region>
105        <code>98052</code>
106      </postal>
107      <email>paulle@microsoft.com</email>
108    </address>
109  </author>
110   
111  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
112    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
113    <address>
114      <postal>
115        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
116        <street>The Stata Center, Building 32</street>
117        <street>32 Vassar Street</street>
118        <city>Cambridge</city>
119        <region>MA</region>
120        <code>02139</code>
121        <country>USA</country>
122      </postal>
123      <email>timbl@w3.org</email>
124      <uri>http://www.w3.org/People/Berners-Lee/</uri>
125    </address>
126  </author>
127
128  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
129    <organization abbrev="W3C">World Wide Web Consortium</organization>
130    <address>
131      <postal>
132        <street>W3C / ERCIM</street>
133        <street>2004, rte des Lucioles</street>
134        <city>Sophia-Antipolis</city>
135        <region>AM</region>
136        <code>06902</code>
137        <country>France</country>
138      </postal>
139      <email>ylafon@w3.org</email>
140      <uri>http://www.raubacapeu.net/people/yves/</uri>
141    </address>
142  </author>
143
144  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
145    <organization abbrev="greenbytes">greenbytes GmbH</organization>
146    <address>
147      <postal>
148        <street>Hafenweg 16</street>
149        <city>Muenster</city><region>NW</region><code>48155</code>
150        <country>Germany</country>
151      </postal>
152      <phone>+49 251 2807760</phone>
153      <facsimile>+49 251 2807761</facsimile>
154      <email>julian.reschke@greenbytes.de</email>
155      <uri>http://greenbytes.de/tech/webdav/</uri>
156    </address>
157  </author>
158
159  <date month="March" year="2011" day="14"/>
160  <workgroup>HTTPbis Working Group</workgroup>
161
162<abstract>
163<t>
164   The Hypertext Transfer Protocol (HTTP) is an application-level
165   protocol for distributed, collaborative, hypermedia information
166   systems. HTTP has been in use by the World Wide Web global information
167   initiative since 1990. This document is Part 7 of the seven-part specification
168   that defines the protocol referred to as "HTTP/1.1" and, taken together,
169   obsoletes RFC 2616.  Part 7 defines HTTP Authentication.
170</t>
171</abstract>
172
173<note title="Editorial Note (To be removed by RFC Editor)">
174  <t>
175    Discussion of this draft should take place on the HTTPBIS working group
176    mailing list (ietf-http-wg@w3.org). The current issues list is
177    at <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/>
178    and related documents (including fancy diffs) can be found at
179    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
180  </t>
181  <t>
182    The changes in this draft are summarized in <xref target="changes.since.12"/>.
183  </t>
184</note>
185</front>
186<middle>
187<section title="Introduction" anchor="introduction">
188<t>
189   This document defines HTTP/1.1 access control and authentication. It
190   includes the relevant parts of RFC 2616
191   with only minor changes, plus the general framework for HTTP authentication,
192   as previously defined in "HTTP Authentication: Basic and Digest Access
193   Authentication" (<xref target="RFC2617"/>).
194</t>
195<t>
196   HTTP provides several OPTIONAL challenge-response authentication
197   mechanisms which can be used by a server to challenge a client request and
198   by a client to provide authentication information. The "basic" and "digest"
199   authentication schemes continue to be specified in
200   RFC 2617.
201</t>
202
203<section title="Requirements" anchor="intro.requirements">
204<t>
205   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
206   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
207   document are to be interpreted as described in <xref target="RFC2119"/>.
208</t>
209<t>
210   An implementation is not compliant if it fails to satisfy one or more
211   of the "MUST" or "REQUIRED" level requirements for the protocols it
212   implements. An implementation that satisfies all the "MUST" or "REQUIRED"
213   level and all the "SHOULD" level requirements for its protocols is said
214   to be "unconditionally compliant"; one that satisfies all the "MUST"
215   level requirements but not all the "SHOULD" level requirements for its
216   protocols is said to be "conditionally compliant".
217</t>
218</section>
219
220<section title="Syntax Notation" anchor="notation">
221 
222 
223 
224 
225 
226 
227 
228 
229<t>
230  This specification uses the ABNF syntax defined in Section 1.2 of <xref target="Part1"/> (which
231  extends the syntax defined in <xref target="RFC5234"/> with a list rule).
232  <xref target="collected.abnf"/> shows the collected ABNF, with the list
233  rule expanded.
234</t>
235<t>
236  The following core rules are included by
237  reference, as defined in <xref target="RFC5234"/>, Appendix B.1:
238  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
239  DIGIT (decimal 0-9), DQUOTE (double quote),
240  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
241  OCTET (any 8-bit sequence of data), SP (space),
242  VCHAR (any visible USASCII character),
243  and WSP (whitespace).
244</t>
245
246<section title="Core Rules" anchor="core.rules">
247   
248   
249   
250<t>
251   The core rules below are defined in Section 1.2.2 of <xref target="Part1"/>:
252</t>
253<figure><artwork type="abnf2616"><![CDATA[
254  quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
255  token         = <token, defined in [Part1], Section 1.2.2>
256  OWS           = <OWS, defined in [Part1], Section 1.2.2>
257]]></artwork></figure>
258</section>
259</section>
260</section>
261
262<section title="Access Authentication Framework" anchor="access.authentication.framework">
263 
264 
265 
266 
267<t>
268   HTTP provides a simple challenge-response authentication mechanism
269   that can be used by a server to challenge a client request and by a
270   client to provide authentication information. It uses an extensible,
271   case-insensitive token to identify the authentication scheme,
272   followed by a comma-separated list of attribute-value pairs which
273   carry the parameters necessary for achieving authentication via that
274   scheme.
275</t>
276<figure><iref item="auth-scheme" primary="true"/><iref item="auth-param" primary="true"/><artwork type="abnf2616"><![CDATA[
277  auth-scheme    = token
278  auth-param     = token "=" ( token / quoted-string )
279]]></artwork></figure>
280<t>
281   The 401 (Unauthorized) response message is used by an origin server
282   to challenge the authorization of a user agent. This response MUST
283   include a WWW-Authenticate header field containing at least one
284   challenge applicable to the requested resource. The 407 (Proxy
285   Authentication Required) response message is used by a proxy to
286   challenge the authorization of a client and MUST include a Proxy-Authenticate
287   header field containing at least one challenge
288   applicable to the proxy for the requested resource.
289</t>
290<figure><iref item="challenge" primary="true"/><artwork type="abnf2616"><![CDATA[
291  challenge   = auth-scheme 1*SP 1#auth-param
292]]></artwork></figure>
293<t><list>
294  <t>
295   Note: User agents will need to take special care in parsing the WWW-Authenticate
296   or Proxy-Authenticate header field value if it contains
297   more than one challenge, or if more than one WWW-Authenticate header
298   field is provided, since the contents of a challenge can itself
299   contain a comma-separated list of authentication parameters.
300  </t>
301</list></t>
302<t><list>
303  <t>
304      Note: Many browsers fail to parse challenges containing unknown
305      schemes. A workaround for this problem is to list well-supported schemes
306      (such as "basic") first.
307  </t>
308</list></t>
309<t>
310   The authentication parameter realm is defined for all authentication
311   schemes:
312</t>
313<figure><iref item="realm" primary="true"/><iref item="realm-value" primary="true"/><artwork type="abnf2616"><![CDATA[
314  realm       = "realm" "=" realm-value
315  realm-value = quoted-string
316]]></artwork></figure>
317<t>
318   The realm directive (case-insensitive) is required for all
319   authentication schemes that issue a challenge. The realm value
320   (case-sensitive), in combination with the canonical root URI
321   (the scheme and authority components of the effective request URI; see
322   Section 4.3 of <xref target="Part1"/>) of the server being accessed, defines the protection space.
323   These realms allow the protected resources on a server to be
324   partitioned into a set of protection spaces, each with its own
325   authentication scheme and/or authorization database. The realm value
326   is a string, generally assigned by the origin server, which can have
327   additional semantics specific to the authentication scheme. Note that
328   there can be multiple challenges with the same auth-scheme but
329   different realms.
330</t>
331<t>
332   A user agent that wishes to authenticate itself with an origin
333   server — usually, but not necessarily, after receiving a 401
334   (Unauthorized) — MAY do so by including an Authorization header field
335   with the request. A client that wishes to authenticate itself with a
336   proxy — usually, but not necessarily, after receiving a 407 (Proxy
337   Authentication Required) — MAY do so by including a Proxy-Authorization
338   header field with the request.  Both the Authorization
339   field value and the Proxy-Authorization field value consist of
340   credentials containing the authentication information of the client
341   for the realm of the resource being requested. The user agent MUST
342   choose to use one of the challenges with the strongest auth-scheme it
343   understands and request credentials from the user based upon that
344   challenge.
345</t>
346<figure><iref item="credentials" primary="true"/><artwork type="abnf2616"><![CDATA[
347  credentials = auth-scheme ( token
348                            / quoted-string
349                            / #auth-param )
350]]></artwork></figure>
351<t>
352   The protection space determines the domain over which credentials can
353   be automatically applied. If a prior request has been authorized, the
354   same credentials MAY be reused for all other requests within that
355   protection space for a period of time determined by the
356   authentication scheme, parameters, and/or user preference. Unless
357   otherwise defined by the authentication scheme, a single protection
358   space cannot extend outside the scope of its server.
359</t>
360<t>
361   If the origin server does not wish to accept the credentials sent
362   with a request, it SHOULD return a 401 (Unauthorized) response. The
363   response MUST include a WWW-Authenticate header field containing at
364   least one (possibly new) challenge applicable to the requested
365   resource. If a proxy does not accept the credentials sent with a
366   request, it SHOULD return a 407 (Proxy Authentication Required). The
367   response MUST include a Proxy-Authenticate header field containing a
368   (possibly new) challenge applicable to the proxy for the requested
369   resource.
370</t>
371<t>
372   The HTTP protocol does not restrict applications to this simple
373   challenge-response mechanism for access authentication. Additional
374   mechanisms MAY be used, such as encryption at the transport level or
375   via message encapsulation, and with additional header fields
376   specifying authentication information. However, such additional
377   mechanisms are not defined by this specification.
378</t>
379<t>
380   Proxies MUST forward the WWW-Authenticate and Authorization headers
381   unmodified and follow the rules found in <xref target="header.authorization"/>.
382</t>
383
384<section title="Authentication Scheme Registry" anchor="authentication.scheme.registry">
385<t>
386  The HTTP Authentication Scheme Registry defines the name space for the
387  authentication schemes in challenges and credentials.
388</t>
389<t>
390  Registrations MUST include the following fields:
391  <list style="symbols">
392    <t>Authentication Scheme Name</t>
393    <t>Pointer to specification text</t>
394  </list>
395</t>
396<t>
397  Values to be added to this name space are subject to IETF review
398  (<xref target="RFC5226"/>, Section 4.1).
399</t>
400<t>
401  The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-authschemes"/>.
402</t>
403</section>
404
405</section>
406
407<section title="Status Code Definitions" anchor="status.code.definitions">
408<section title="401 Unauthorized" anchor="status.401">
409  <iref primary="true" item="401 Unauthorized (status code)"/>
410  <iref primary="true" item="Status Codes" subitem="401 Unauthorized"/>
411<t>
412   The request requires user authentication. The response MUST include a
413   WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge
414   applicable to the target resource. The client MAY repeat the
415   request with a suitable Authorization header field (<xref target="header.authorization"/>). If
416   the request already included Authorization credentials, then the 401
417   response indicates that authorization has been refused for those
418   credentials. If the 401 response contains the same challenge as the
419   prior response, and the user agent has already attempted
420   authentication at least once, then the user SHOULD be presented the
421   representation that was given in the response, since that representation might
422   include relevant diagnostic information.
423</t>
424</section>
425<section title="407 Proxy Authentication Required" anchor="status.407">
426  <iref primary="true" item="407 Proxy Authentication Required (status code)"/>
427  <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required"/>
428<t>
429   This code is similar to 401 (Unauthorized), but indicates that the
430   client ought to first authenticate itself with the proxy. The proxy MUST
431   return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
432   challenge applicable to the proxy for the target resource. The
433   client MAY repeat the request with a suitable Proxy-Authorization
434   header field (<xref target="header.proxy-authorization"/>).
435</t>
436</section>
437</section>
438
439<section title="Header Field Definitions" anchor="header.fields">
440<t>
441   This section defines the syntax and semantics of HTTP/1.1 header fields
442   related to authentication.
443</t>
444
445<section title="Authorization" anchor="header.authorization">
446  <iref primary="true" item="Authorization header field"/>
447  <iref primary="true" item="Header Fields" subitem="Authorization"/>
448 
449 
450<t>
451   The "Authorization" header field allows a user agent to authenticate
452   itself with a server — usually, but not necessarily, after receiving a 401
453   (Unauthorized) response. Its value consists of credentials containing
454   information of the user agent for the realm of the resource being
455   requested.
456</t>
457<figure><iref primary="true" item="Grammar" subitem="Authorization"/><iref primary="true" item="Grammar" subitem="Authorization-v"/><artwork type="abnf2616"><![CDATA[
458  Authorization   = "Authorization" ":" OWS Authorization-v
459  Authorization-v = credentials
460]]></artwork></figure>
461<t>
462   If a request is
463   authenticated and a realm specified, the same credentials SHOULD
464   be valid for all other requests within this realm (assuming that
465   the authentication scheme itself does not require otherwise, such
466   as credentials that vary according to a challenge value or using
467   synchronized clocks).
468</t>
469<t>
470      When a shared cache (see Section 1.2 of <xref target="Part6"/>) receives a request
471      containing an Authorization field, it MUST NOT return the
472      corresponding response as a reply to any other request, unless one
473      of the following specific exceptions holds:
474</t>
475<t>
476  <list style="numbers">
477      <t>If the response includes the "s-maxage" cache-control
478         directive, the cache MAY use that response in replying to a
479         subsequent request. But (if the specified maximum age has
480         passed) a proxy cache MUST first revalidate it with the origin
481         server, using the header fields from the new request to allow
482         the origin server to authenticate the new request. (This is the
483         defined behavior for s-maxage.) If the response includes "s-maxage=0",
484         the proxy MUST always revalidate it before re-using
485         it.</t>
486
487      <t>If the response includes the "must-revalidate" cache-control
488         directive, the cache MAY use that response in replying to a
489         subsequent request. But if the response is stale, all caches
490         MUST first revalidate it with the origin server, using the
491         header fields from the new request to allow the origin server
492         to authenticate the new request.</t>
493
494      <t>If the response includes the "public" cache-control directive,
495         it MAY be returned in reply to any subsequent request.</t>
496  </list>
497</t>
498</section>
499
500<section title="Proxy-Authenticate" anchor="header.proxy-authenticate">
501  <iref primary="true" item="Proxy-Authenticate header field"/>
502  <iref primary="true" item="Header Fields" subitem="Proxy-Authenticate"/>
503 
504 
505<t>
506   The "Proxy-Authenticate" header field consists of a challenge that
507   indicates the authentication scheme and parameters applicable to the proxy
508   for this effective request URI (Section 4.3 of <xref target="Part1"/>). It MUST be included as part
509   of a 407 (Proxy Authentication Required) response.
510</t>
511<figure><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/><iref primary="true" item="Grammar" subitem="Proxy-Authenticate-v"/><artwork type="abnf2616"><![CDATA[
512  Proxy-Authenticate   = "Proxy-Authenticate" ":" OWS
513                         Proxy-Authenticate-v
514  Proxy-Authenticate-v = 1#challenge
515]]></artwork></figure>
516<t>
517   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to
518   the current connection and SHOULD NOT  be passed on to downstream
519   clients. However, an intermediate proxy might need to obtain its own
520   credentials by requesting them from the downstream client, which in
521   some circumstances will appear as if the proxy is forwarding the
522   Proxy-Authenticate header field.
523</t>
524</section>
525
526<section title="Proxy-Authorization" anchor="header.proxy-authorization">
527  <iref primary="true" item="Proxy-Authorization header field"/>
528  <iref primary="true" item="Header Fields" subitem="Proxy-Authorization"/>
529 
530 
531<t>
532   The "Proxy-Authorization" header field allows the client to
533   identify itself (or its user) to a proxy which requires
534   authentication. Its value consists of
535   credentials containing the authentication information of the user
536   agent for the proxy and/or realm of the resource being requested.
537</t>
538<figure><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/><iref primary="true" item="Grammar" subitem="Proxy-Authorization-v"/><artwork type="abnf2616"><![CDATA[
539  Proxy-Authorization   = "Proxy-Authorization" ":" OWS
540                          Proxy-Authorization-v
541  Proxy-Authorization-v = credentials
542]]></artwork></figure>
543<t>
544   Unlike Authorization, the Proxy-Authorization header field applies only to
545   the next outbound proxy that demanded authentication using the Proxy-Authenticate
546   field. When multiple proxies are used in a chain, the
547   Proxy-Authorization header field is consumed by the first outbound
548   proxy that was expecting to receive credentials. A proxy MAY relay
549   the credentials from the client request to the next proxy if that is
550   the mechanism by which the proxies cooperatively authenticate a given
551   request.
552</t>
553</section>
554
555<section title="WWW-Authenticate" anchor="header.www-authenticate">
556  <iref primary="true" item="WWW-Authenticate header field"/>
557  <iref primary="true" item="Header Fields" subitem="WWW-Authenticate"/>
558 
559 
560<t>
561   The "WWW-Authenticate" header field consists of at least one
562   challenge that indicates the authentication scheme(s) and parameters
563   applicable to the effective request URI (Section 4.3 of <xref target="Part1"/>). It MUST be included in 401
564   (Unauthorized) response messages.
565</t>
566<figure><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/><iref primary="true" item="Grammar" subitem="WWW-Authenticate-v"/><artwork type="abnf2616"><![CDATA[
567  WWW-Authenticate   = "WWW-Authenticate" ":" OWS WWW-Authenticate-v
568  WWW-Authenticate-v = 1#challenge
569]]></artwork></figure>
570<t>
571   User agents are advised to take special care in parsing the WWW-Authenticate
572   field value as it might contain more than one challenge,
573   or if more than one WWW-Authenticate header field is provided, the
574   contents of a challenge itself can contain a comma-separated list of
575   authentication parameters.
576</t>
577</section>
578
579</section>
580
581<section title="IANA Considerations" anchor="IANA.considerations">
582
583<section title="Authenticaton Scheme Registry" anchor="authentication.scheme.registration">
584<t>
585  The registration procedure for HTTP Authentication Schemes is defined by
586  <xref target="authentication.scheme.registry"/> of this document.
587</t>
588<t>
589   The HTTP Method Authentication Scheme shall be created at <eref target="http://www.iana.org/assignments/http-authschemes"/>.
590</t>
591</section>
592
593<section title="Status Code Registration" anchor="status.code.registration">
594<t>
595   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
596   shall be updated with the registrations below:
597</t>
598
599<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
600<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
601   <ttcol>Value</ttcol>
602   <ttcol>Description</ttcol>
603   <ttcol>Reference</ttcol>
604   <c>401</c>
605   <c>Unauthorized</c>
606   <c>
607      <xref target="status.401"/>
608   </c>
609   <c>407</c>
610   <c>Proxy Authentication Required</c>
611   <c>
612      <xref target="status.407"/>
613   </c>
614</texttable>
615<!--(END)-->
616
617</section>
618
619<section title="Header Field Registration" anchor="header.field.registration">
620<t>
621   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
622   with the permanent registrations below (see <xref target="RFC3864"/>):
623</t>
624
625<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
626<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
627   <ttcol>Header Field Name</ttcol>
628   <ttcol>Protocol</ttcol>
629   <ttcol>Status</ttcol>
630   <ttcol>Reference</ttcol>
631
632   <c>Authorization</c>
633   <c>http</c>
634   <c>standard</c>
635   <c>
636      <xref target="header.authorization"/>
637   </c>
638   <c>Proxy-Authenticate</c>
639   <c>http</c>
640   <c>standard</c>
641   <c>
642      <xref target="header.proxy-authenticate"/>
643   </c>
644   <c>Proxy-Authorization</c>
645   <c>http</c>
646   <c>standard</c>
647   <c>
648      <xref target="header.proxy-authorization"/>
649   </c>
650   <c>WWW-Authenticate</c>
651   <c>http</c>
652   <c>standard</c>
653   <c>
654      <xref target="header.www-authenticate"/>
655   </c>
656</texttable>
657<!--(END)-->
658
659<t>
660   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
661</t>
662</section>
663</section>
664
665<section title="Security Considerations" anchor="security.considerations">
666<t>
667   This section is meant to inform application developers, information
668   providers, and users of the security limitations in HTTP/1.1 as
669   described by this document. The discussion does not include
670   definitive solutions to the problems revealed, though it does make
671   some suggestions for reducing security risks.
672</t>
673
674<section title="Authentication Credentials and Idle Clients" anchor="auth.credentials.and.idle.clients">
675<t>
676   Existing HTTP clients and user agents typically retain authentication
677   information indefinitely. HTTP/1.1 does not provide a method for a
678   server to direct clients to discard these cached credentials. This is
679   a significant defect that requires further extensions to HTTP.
680   Circumstances under which credential caching can interfere with the
681   application's security model include but are not limited to:
682  <list style="symbols">
683     <t>Clients which have been idle for an extended period following
684        which the server might wish to cause the client to reprompt the
685        user for credentials.</t>
686
687     <t>Applications which include a session termination indication
688        (such as a "logout" or "commit" button on a page) after which
689        the server side of the application "knows" that there is no
690        further reason for the client to retain the credentials.</t>
691  </list>
692</t>
693<t>
694   This is currently under separate study. There are a number of work-arounds
695   to parts of this problem, and we encourage the use of
696   password protection in screen savers, idle time-outs, and other
697   methods which mitigate the security problems inherent in this
698   problem. In particular, user agents which cache credentials are
699   encouraged to provide a readily accessible mechanism for discarding
700   cached credentials under user control.
701</t>
702</section>
703</section>
704
705<section title="Acknowledgments" anchor="ack">
706<t>
707  This specification takes over the definition of the HTTP Authentication
708  Framework, previously defined in RFC 2617. We thank to John Franks,
709  Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence,
710  Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work
711  on that specification.
712</t>
713<t>
714  <cref anchor="acks">HTTPbis acknowledgements.</cref>
715</t>
716</section>
717</middle>
718
719<back>
720
721<references title="Normative References">
722
723<reference anchor="Part1">
724  <front>
725    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
726    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
727      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
728      <address><email>fielding@gbiv.com</email></address>
729    </author>
730    <author initials="J." surname="Gettys" fullname="Jim Gettys">
731      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
732      <address><email>jg@freedesktop.org</email></address>
733    </author>
734    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
735      <organization abbrev="HP">Hewlett-Packard Company</organization>
736      <address><email>JeffMogul@acm.org</email></address>
737    </author>
738    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
739      <organization abbrev="Microsoft">Microsoft Corporation</organization>
740      <address><email>henrikn@microsoft.com</email></address>
741    </author>
742    <author initials="L." surname="Masinter" fullname="Larry Masinter">
743      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
744      <address><email>LMM@acm.org</email></address>
745    </author>
746    <author initials="P." surname="Leach" fullname="Paul J. Leach">
747      <organization abbrev="Microsoft">Microsoft Corporation</organization>
748      <address><email>paulle@microsoft.com</email></address>
749    </author>
750    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
751      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
752      <address><email>timbl@w3.org</email></address>
753    </author>
754    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
755      <organization abbrev="W3C">World Wide Web Consortium</organization>
756      <address><email>ylafon@w3.org</email></address>
757    </author>
758    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
759      <organization abbrev="greenbytes">greenbytes GmbH</organization>
760      <address><email>julian.reschke@greenbytes.de</email></address>
761    </author>
762    <date month="March" year="2011"/>
763  </front>
764  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-13"/>
765 
766</reference>
767
768<reference anchor="Part6">
769  <front>
770    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
771    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
772      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
773      <address><email>fielding@gbiv.com</email></address>
774    </author>
775    <author initials="J." surname="Gettys" fullname="Jim Gettys">
776      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
777      <address><email>jg@freedesktop.org</email></address>
778    </author>
779    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
780      <organization abbrev="HP">Hewlett-Packard Company</organization>
781      <address><email>JeffMogul@acm.org</email></address>
782    </author>
783    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
784      <organization abbrev="Microsoft">Microsoft Corporation</organization>
785      <address><email>henrikn@microsoft.com</email></address>
786    </author>
787    <author initials="L." surname="Masinter" fullname="Larry Masinter">
788      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
789      <address><email>LMM@acm.org</email></address>
790    </author>
791    <author initials="P." surname="Leach" fullname="Paul J. Leach">
792      <organization abbrev="Microsoft">Microsoft Corporation</organization>
793      <address><email>paulle@microsoft.com</email></address>
794    </author>
795    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
796      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
797      <address><email>timbl@w3.org</email></address>
798    </author>
799    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
800      <organization abbrev="W3C">World Wide Web Consortium</organization>
801      <address><email>ylafon@w3.org</email></address>
802    </author>
803    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
804      <address><email>mnot@mnot.net</email></address>
805    </author>
806    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
807      <organization abbrev="greenbytes">greenbytes GmbH</organization>
808      <address><email>julian.reschke@greenbytes.de</email></address>
809    </author>
810    <date month="March" year="2011"/>
811  </front>
812  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-13"/>
813 
814</reference>
815
816<reference anchor="RFC2119">
817  <front>
818    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
819    <author initials="S." surname="Bradner" fullname="Scott Bradner">
820      <organization>Harvard University</organization>
821      <address><email>sob@harvard.edu</email></address>
822    </author>
823    <date month="March" year="1997"/>
824  </front>
825  <seriesInfo name="BCP" value="14"/>
826  <seriesInfo name="RFC" value="2119"/>
827</reference>
828
829<reference anchor="RFC5234">
830  <front>
831    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
832    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
833      <organization>Brandenburg InternetWorking</organization>
834      <address>
835        <email>dcrocker@bbiw.net</email>
836      </address> 
837    </author>
838    <author initials="P." surname="Overell" fullname="Paul Overell">
839      <organization>THUS plc.</organization>
840      <address>
841        <email>paul.overell@thus.net</email>
842      </address>
843    </author>
844    <date month="January" year="2008"/>
845  </front>
846  <seriesInfo name="STD" value="68"/>
847  <seriesInfo name="RFC" value="5234"/>
848</reference>
849
850</references>
851
852<references title="Informative References">
853
854<reference anchor="RFC2616">
855  <front>
856    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
857    <author initials="R." surname="Fielding" fullname="R. Fielding">
858      <organization>University of California, Irvine</organization>
859      <address><email>fielding@ics.uci.edu</email></address>
860    </author>
861    <author initials="J." surname="Gettys" fullname="J. Gettys">
862      <organization>W3C</organization>
863      <address><email>jg@w3.org</email></address>
864    </author>
865    <author initials="J." surname="Mogul" fullname="J. Mogul">
866      <organization>Compaq Computer Corporation</organization>
867      <address><email>mogul@wrl.dec.com</email></address>
868    </author>
869    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
870      <organization>MIT Laboratory for Computer Science</organization>
871      <address><email>frystyk@w3.org</email></address>
872    </author>
873    <author initials="L." surname="Masinter" fullname="L. Masinter">
874      <organization>Xerox Corporation</organization>
875      <address><email>masinter@parc.xerox.com</email></address>
876    </author>
877    <author initials="P." surname="Leach" fullname="P. Leach">
878      <organization>Microsoft Corporation</organization>
879      <address><email>paulle@microsoft.com</email></address>
880    </author>
881    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
882      <organization>W3C</organization>
883      <address><email>timbl@w3.org</email></address>
884    </author>
885    <date month="June" year="1999"/>
886  </front>
887  <seriesInfo name="RFC" value="2616"/>
888</reference>
889
890<reference anchor="RFC2617">
891  <front>
892    <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
893    <author initials="J." surname="Franks" fullname="John Franks">
894      <organization>Northwestern University, Department of Mathematics</organization>
895      <address><email>john@math.nwu.edu</email></address>
896    </author>
897    <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
898      <organization>Verisign Inc.</organization>
899      <address><email>pbaker@verisign.com</email></address>
900    </author>
901    <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
902      <organization>AbiSource, Inc.</organization>
903      <address><email>jeff@AbiSource.com</email></address>
904    </author>
905    <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
906      <organization>Agranat Systems, Inc.</organization>
907      <address><email>lawrence@agranat.com</email></address>
908    </author>
909    <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
910      <organization>Microsoft Corporation</organization>
911      <address><email>paulle@microsoft.com</email></address>
912    </author>
913    <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
914      <organization>Netscape Communications Corporation</organization>
915    </author>
916    <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
917      <organization>Open Market, Inc.</organization>
918      <address><email>stewart@OpenMarket.com</email></address>
919    </author>
920    <date month="June" year="1999"/>
921  </front>
922  <seriesInfo name="RFC" value="2617"/>
923</reference>
924
925<reference anchor="RFC3864">
926  <front>
927    <title>Registration Procedures for Message Header Fields</title>
928    <author initials="G." surname="Klyne" fullname="G. Klyne">
929      <organization>Nine by Nine</organization>
930      <address><email>GK-IETF@ninebynine.org</email></address>
931    </author>
932    <author initials="M." surname="Nottingham" fullname="M. Nottingham">
933      <organization>BEA Systems</organization>
934      <address><email>mnot@pobox.com</email></address>
935    </author>
936    <author initials="J." surname="Mogul" fullname="J. Mogul">
937      <organization>HP Labs</organization>
938      <address><email>JeffMogul@acm.org</email></address>
939    </author>
940    <date year="2004" month="September"/>
941  </front>
942  <seriesInfo name="BCP" value="90"/>
943  <seriesInfo name="RFC" value="3864"/>
944</reference>
945
946<reference anchor="RFC5226">
947  <front>
948    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
949    <author initials="T." surname="Narten" fullname="T. Narten">
950      <organization>IBM</organization>
951      <address><email>narten@us.ibm.com</email></address>
952    </author>
953    <author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
954      <organization>Google</organization>
955      <address><email>Harald@Alvestrand.no</email></address>
956    </author>
957    <date year="2008" month="May"/>
958  </front>
959  <seriesInfo name="BCP" value="26"/>
960  <seriesInfo name="RFC" value="5226"/>
961</reference>
962
963</references>
964
965<!-- re-add this once we have changes
966<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
967</section>
968 -->
969 
970
971<section title="Collected ABNF" anchor="collected.abnf">
972<figure>
973<artwork type="abnf" name="p7-auth.parsed-abnf"><![CDATA[
974Authorization = "Authorization:" OWS Authorization-v
975Authorization-v = credentials
976
977OWS = <OWS, defined in [Part1], Section 1.2.2>
978
979Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v
980Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
981 challenge ] )
982Proxy-Authorization = "Proxy-Authorization:" OWS
983 Proxy-Authorization-v
984Proxy-Authorization-v = credentials
985
986WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v
987WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
988 challenge ] )
989
990auth-param = token "=" ( token / quoted-string )
991auth-scheme = token
992
993challenge = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS
994 auth-param ] )
995credentials = auth-scheme ( token / quoted-string / [ ( "," /
996 auth-param ) *( OWS "," [ OWS auth-param ] ) ] )
997
998quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
999
1000realm = "realm=" realm-value
1001realm-value = quoted-string
1002
1003token = <token, defined in [Part1], Section 1.2.2>
1004]]></artwork>
1005</figure>
1006<figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"><![CDATA[
1007; Authorization defined but not used
1008; Proxy-Authenticate defined but not used
1009; Proxy-Authorization defined but not used
1010; WWW-Authenticate defined but not used
1011; realm defined but not used
1012]]></artwork></figure></section>
1013
1014
1015<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
1016
1017<section title="Since RFC 2616">
1018<t>
1019  Extracted relevant partitions from <xref target="RFC2616"/>.
1020</t>
1021</section>
1022
1023<section title="Since draft-ietf-httpbis-p7-auth-00">
1024<t>
1025  Closed issues:
1026  <list style="symbols">
1027    <t>
1028      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>:
1029      "Normative and Informative references"
1030    </t>
1031  </list>
1032</t>
1033</section>
1034
1035<section title="Since draft-ietf-httpbis-p7-auth-01">
1036<t>
1037  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1038  <list style="symbols">
1039    <t>
1040      Explicitly import BNF rules for "challenge" and "credentials" from RFC2617.
1041    </t>
1042    <t>
1043      Add explicit references to BNF syntax and rules imported from other parts of the specification.
1044    </t>
1045  </list>
1046</t>
1047</section>
1048
1049<section title="Since draft-ietf-httpbis-p7-auth-02" anchor="changes.since.02">
1050<t>
1051  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
1052  <list style="symbols">
1053    <t>
1054      Reference RFC 3984, and update header field registrations for header fields defined
1055      in this document.
1056    </t>
1057  </list>
1058</t>
1059</section>
1060
1061<section title="Since draft-ietf-httpbis-p7-auth-03" anchor="changes.since.03">
1062<t>
1063</t>
1064</section>
1065
1066<section title="Since draft-ietf-httpbis-p7-auth-04" anchor="changes.since.04">
1067<t>
1068  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1069  <list style="symbols">
1070    <t>
1071      Use "/" instead of "|" for alternatives.
1072    </t>
1073    <t>
1074      Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
1075      whitespace ("OWS") and required whitespace ("RWS").
1076    </t>
1077    <t>
1078      Rewrite ABNFs to spell out whitespace rules, factor out
1079      header field value format definitions.
1080    </t>
1081  </list>
1082</t>
1083</section>
1084
1085<section title="Since draft-ietf-httpbis-p7-auth-05" anchor="changes.since.05">
1086<t>
1087  Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1088  <list style="symbols">
1089    <t>
1090      Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.
1091    </t>
1092  </list>
1093</t>
1094</section>
1095
1096<section title="Since draft-ietf-httpbis-p7-auth-06" anchor="changes.since.06">
1097<t>
1098  None.
1099</t>
1100</section>
1101
1102<section title="Since draft-ietf-httpbis-p7-auth-07" anchor="changes.since.07">
1103<t>
1104  Closed issues:
1105  <list style="symbols">
1106    <t>
1107      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/198"/>:
1108      "move IANA registrations for optional status codes"
1109    </t>
1110  </list>
1111</t>
1112</section>
1113
1114<section title="Since draft-ietf-httpbis-p7-auth-08" anchor="changes.since.08">
1115<t>
1116  No significant changes.
1117</t>
1118</section>
1119
1120<section title="Since draft-ietf-httpbis-p7-auth-09" anchor="changes.since.09">
1121<t>
1122  Partly resolved issues:
1123  <list style="symbols">
1124    <t>
1125      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>:
1126      "Term for the requested resource's URI"
1127    </t>
1128  </list>
1129</t>
1130</section>
1131
1132<section title="Since draft-ietf-httpbis-p7-auth-10" anchor="changes.since.10">
1133<t>
1134  None yet.
1135</t>
1136</section>
1137
1138<section title="Since draft-ietf-httpbis-p7-auth-11" anchor="changes.since.11">
1139<t>
1140  Closed issues:
1141  <list style="symbols">
1142    <t>
1143      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/130"/>:
1144      "introduction to part 7 is work-in-progress"
1145    </t>
1146    <t>
1147      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/195"/>:
1148      "auth-param syntax"
1149    </t>
1150    <t>
1151      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>:
1152      "Header Classification"
1153    </t>
1154    <t>
1155      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/237"/>:
1156      "absorbing the auth framework from 2617"
1157    </t>
1158  </list>
1159</t>
1160<t>
1161  Partly resolved issues:
1162  <list style="symbols">
1163    <t>
1164      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/141"/>:
1165      "should we have an auth scheme registry"
1166    </t>
1167  </list>
1168</t>
1169</section>
1170
1171<section title="Since draft-ietf-httpbis-p7-auth-12" anchor="changes.since.12">
1172<t>
1173  None.
1174</t>
1175</section>
1176
1177</section>
1178
1179</back>
1180</rfc>
Note: See TracBrowser for help on using the repository browser.