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

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

update to latest version of rfc2629.xslt; bump up document dates

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