source: draft-ietf-httpbis/latest/p7-auth.xml @ 799

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

latest versions of rfc2629.xslt and xml2rfc.tcl, bump up document dates

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