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

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