source: draft-ietf-httpbis/12/p7-auth.xml @ 1691

Last change on this file since 1691 was 1500, checked in by julian.reschke@…, 8 years ago

fix mime types

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