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

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

reorganize ABNF introductions to match Part1 (related to #36)

  • Property svn:eol-style set to native
File size: 36.0 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 "November">
16  <!ENTITY ID-YEAR "2008">
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="full3978" 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
179<abstract>
180<t>
181   The Hypertext Transfer Protocol (HTTP) is an application-level
182   protocol for distributed, collaborative, hypermedia information
183   systems. HTTP has been in use by the World Wide Web global information
184   initiative since 1990. This document is Part 7 of the seven-part specification
185   that defines the protocol referred to as "HTTP/1.1" and, taken together,
186   obsoletes RFC 2616.  Part 7 defines HTTP Authentication.
187</t>
188</abstract>
189
190<note title="Editorial Note (To be removed by RFC Editor)">
191  <t>
192    Discussion of this draft should take place on the HTTPBIS working group
193    mailing list (ietf-http-wg@w3.org). The current issues list is
194    at <eref target="http://tools.ietf.org/wg/httpbis/trac/report/11"/>
195    and related documents (including fancy diffs) can be found at
196    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
197  </t>
198  <t>
199    The changes in this draft are summarized in <xref target="changes.since.05"/>.
200  </t>
201</note>
202</front>
203<middle>
204<section title="Introduction" anchor="introduction">
205<t>
206   This document defines HTTP/1.1 access control and authentication. Right now it
207   includes the extracted relevant sections of
208   <xref target="RFC2616" x:fmt="none">RFC 2616</xref> with only minor changes.
209   The intention is to move the general framework for HTTP authentication here,
210   as currently specified in <xref target="RFC2617"/>, and allow the individual
211   authentication mechanisms to be defined elsewhere.  This introduction will
212   be rewritten when that occurs.
213</t>
214<t>
215   HTTP provides several &OPTIONAL; challenge-response authentication
216   mechanisms which can be used by a server to challenge a client
217   request and by a client to provide authentication information. The
218   general framework for access authentication, and the specification of
219   "basic" and "digest" authentication, are specified in "HTTP
220   Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. This
221   specification adopts the definitions of "challenge" and "credentials"
222   from that specification.
223</t>
224
225<section title="Requirements" anchor="intro.requirements">
226<t>
227   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
228   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
229   document are to be interpreted as described in <xref target="RFC2119"/>.
230</t>
231<t>
232   An implementation is not compliant if it fails to satisfy one or more
233   of the &MUST; or &REQUIRED; level requirements for the protocols it
234   implements. An implementation that satisfies all the &MUST; or &REQUIRED;
235   level and all the &SHOULD; level requirements for its protocols is said
236   to be "unconditionally compliant"; one that satisfies all the &MUST;
237   level requirements but not all the &SHOULD; level requirements for its
238   protocols is said to be "conditionally compliant."
239</t>
240</section>
241
242<section title="Syntax Notation" anchor="notation">
243<t>
244  This specification uses the ABNF syntax defined in &notation;.
245</t>
246
247<section title="Core Rules" anchor="core.rules">
248  <x:anchor-alias value="OWS"/>
249<t>
250  The core rules below are defined in &basic-rules;:
251</t>
252<figure><artwork type="abnf2616">
253  <x:ref>OWS</x:ref>         = &lt;OWS, defined in &basic-rules;&gt;
254</artwork></figure>
255</section>
256
257<section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">
258  <x:anchor-alias value="challenge"/>
259  <x:anchor-alias value="credentials"/>
260<t>
261  <x:anchor-alias value="OWS"/>
262  The ABNF rules below are defined in other specifications:
263</t>
264<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="challenge"/><iref primary="true" item="Grammar" subitem="credentials"/>
265  <x:ref>challenge</x:ref>   = &lt;challenge, defined in <xref target="RFC2617" x:fmt="," x:sec="1.2"/>&gt;
266  <x:ref>credentials</x:ref> = &lt;credentials, defined in <xref target="RFC2617" x:fmt="," x:sec="1.2"/>&gt;
267</artwork></figure>
268</section>
269
270</section>
271
272</section>
273
274
275<section title="Status Code Definitions">
276<section title="401 Unauthorized" anchor="status.401">
277  <iref primary="true" item="401 Unauthorized (status code)" x:for-anchor=""/>
278  <iref primary="true" item="Status Codes" subitem="401 Unauthorized" x:for-anchor=""/>
279<t>
280   The request requires user authentication. The response &MUST; include a
281   WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge
282   applicable to the requested resource. The client &MAY; repeat the
283   request with a suitable Authorization header field (<xref target="header.authorization"/>). If
284   the request already included Authorization credentials, then the 401
285   response indicates that authorization has been refused for those
286   credentials. If the 401 response contains the same challenge as the
287   prior response, and the user agent has already attempted
288   authentication at least once, then the user &SHOULD; be presented the
289   entity that was given in the response, since that entity might
290   include relevant diagnostic information. HTTP access authentication
291   is explained in "HTTP Authentication: Basic and Digest Access
292   Authentication" <xref target="RFC2617"/>.
293</t>
294</section>
295<section title="407 Proxy Authentication Required" anchor="status.407">
296  <iref primary="true" item="407 Proxy Authentication Required (status code)" x:for-anchor=""/>
297  <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required" x:for-anchor=""/>
298<t>
299   This code is similar to 401 (Unauthorized), but indicates that the
300   client must first authenticate itself with the proxy. The proxy &MUST;
301   return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
302   challenge applicable to the proxy for the requested resource. The
303   client &MAY; repeat the request with a suitable Proxy-Authorization
304   header field (<xref target="header.proxy-authorization"/>). HTTP access authentication is explained
305   in "HTTP Authentication: Basic and Digest Access Authentication"
306   <xref target="RFC2617"/>.
307</t>
308</section>
309</section>
310
311<section title="Header Field Definitions" anchor="header.fields">
312<t>
313   This section defines the syntax and semantics of HTTP/1.1 header fields
314   related to authentication.
315</t>
316
317<section title="Authorization" anchor="header.authorization">
318  <iref primary="true" item="Authorization header" x:for-anchor=""/>
319  <iref primary="true" item="Headers" subitem="Authorization" x:for-anchor=""/>
320  <x:anchor-alias value="Authorization"/>
321  <x:anchor-alias value="Authorization-v"/>
322<t>
323      A user agent that wishes to authenticate itself with a server--
324      usually, but not necessarily, after receiving a 401 response--does
325      so by including an Authorization request-header field with the
326      request.  The field "Authorization" consists of credentials
327      containing the authentication information of the user agent for
328      the realm of the resource being requested.
329</t>
330<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/><iref primary="true" item="Grammar" subitem="Authorization-v"/>
331  <x:ref>Authorization</x:ref>   = "Authorization" ":" <x:ref>OWS</x:ref> <x:ref>Authorization-v</x:ref>
332  <x:ref>Authorization-v</x:ref> = <x:ref>credentials</x:ref>
333</artwork></figure>
334<t>
335      HTTP access authentication is described in "HTTP Authentication:
336      Basic and Digest Access Authentication" <xref target="RFC2617"/>. If a request is
337      authenticated and a realm specified, the same credentials &SHOULD;
338      be valid for all other requests within this realm (assuming that
339      the authentication scheme itself does not require otherwise, such
340      as credentials that vary according to a challenge value or using
341      synchronized clocks).
342</t>
343<t>
344      When a shared cache (see &shared-and-non-shared-caches;) receives a request
345      containing an Authorization field, it &MUST-NOT; return the
346      corresponding response as a reply to any other request, unless one
347      of the following specific exceptions holds:
348</t>
349<t>
350  <list style="numbers">
351      <t>If the response includes the "s-maxage" cache-control
352         directive, the cache &MAY; use that response in replying to a
353         subsequent request. But (if the specified maximum age has
354         passed) a proxy cache &MUST; first revalidate it with the origin
355         server, using the request-headers from the new request to allow
356         the origin server to authenticate the new request. (This is the
357         defined behavior for s-maxage.) If the response includes "s-maxage=0",
358         the proxy &MUST; always revalidate it before re-using
359         it.</t>
360
361      <t>If the response includes the "must-revalidate" cache-control
362         directive, the cache &MAY; use that response in replying to a
363         subsequent request. But if the response is stale, all caches
364         &MUST; first revalidate it with the origin server, using the
365         request-headers from the new request to allow the origin server
366         to authenticate the new request.</t>
367
368      <t>If the response includes the "public" cache-control directive,
369         it &MAY; be returned in reply to any subsequent request.</t>
370  </list>
371</t>
372</section>
373
374<section title="Proxy-Authenticate" anchor="header.proxy-authenticate">
375  <iref primary="true" item="Proxy-Authenticate header" x:for-anchor=""/>
376  <iref primary="true" item="Headers" subitem="Proxy-Authenticate" x:for-anchor=""/>
377  <x:anchor-alias value="Proxy-Authenticate"/>
378  <x:anchor-alias value="Proxy-Authenticate-v"/>
379<t>
380   The response-header field "Proxy-Authenticate" &MUST; be included as part
381   of a 407 (Proxy Authentication Required) response. The field value
382   consists of a challenge that indicates the authentication scheme and
383   parameters applicable to the proxy for this request-target.
384</t>
385<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/><iref primary="true" item="Grammar" subitem="Proxy-Authenticate-v"/>
386  <x:ref>Proxy-Authenticate</x:ref>   = "Proxy-Authenticate" ":" <x:ref>OWS</x:ref>
387                         <x:ref>Proxy-Authenticate-v</x:ref>
388  <x:ref>Proxy-Authenticate-v</x:ref> = 1#<x:ref>challenge</x:ref>
389</artwork></figure>
390<t>
391   The HTTP access authentication process is described in "HTTP
392   Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike
393   WWW-Authenticate, the Proxy-Authenticate header field applies only to
394   the current connection and &SHOULD-NOT;  be passed on to downstream
395   clients. However, an intermediate proxy might need to obtain its own
396   credentials by requesting them from the downstream client, which in
397   some circumstances will appear as if the proxy is forwarding the
398   Proxy-Authenticate header field.
399</t>
400</section>
401
402<section title="Proxy-Authorization" anchor="header.proxy-authorization">
403  <iref primary="true" item="Proxy-Authorization header" x:for-anchor=""/>
404  <iref primary="true" item="Headers" subitem="Proxy-Authorization" x:for-anchor=""/>
405  <x:anchor-alias value="Proxy-Authorization"/>
406  <x:anchor-alias value="Proxy-Authorization-v"/>
407<t>
408   The request-header field "Proxy-Authorization" allows the client to
409   identify itself (or its user) to a proxy which requires
410   authentication. The Proxy-Authorization field value consists of
411   credentials containing the authentication information of the user
412   agent for the proxy and/or realm of the resource being requested.
413</t>
414<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/><iref primary="true" item="Grammar" subitem="Proxy-Authorization-v"/>
415  <x:ref>Proxy-Authorization</x:ref>   = "Proxy-Authorization" ":" <x:ref>OWS</x:ref>
416                          <x:ref>Proxy-Authorization-v</x:ref>
417  <x:ref>Proxy-Authorization-v</x:ref> = <x:ref>credentials</x:ref>
418</artwork></figure>
419<t>
420   The HTTP access authentication process is described in "HTTP
421   Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike
422   Authorization, the Proxy-Authorization header field applies only to
423   the next outbound proxy that demanded authentication using the Proxy-Authenticate
424   field. When multiple proxies are used in a chain, the
425   Proxy-Authorization header field is consumed by the first outbound
426   proxy that was expecting to receive credentials. A proxy &MAY; relay
427   the credentials from the client request to the next proxy if that is
428   the mechanism by which the proxies cooperatively authenticate a given
429   request.
430</t>
431</section>
432
433<section title="WWW-Authenticate" anchor="header.www-authenticate">
434  <iref primary="true" item="WWW-Authenticate header" x:for-anchor=""/>
435  <iref primary="true" item="Headers" subitem="WWW-Authenticate" x:for-anchor=""/>
436  <x:anchor-alias value="WWW-Authenticate"/>
437  <x:anchor-alias value="WWW-Authenticate-v"/>
438<t>
439   The WWW-Authenticate response-header field &MUST; be included in 401
440   (Unauthorized) response messages. The field value consists of at
441   least one challenge that indicates the authentication scheme(s) and
442   parameters applicable to the request-target.
443</t>
444<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/><iref primary="true" item="Grammar" subitem="WWW-Authenticate-v"/>
445  <x:ref>WWW-Authenticate</x:ref>   = "WWW-Authenticate" ":" <x:ref>OWS</x:ref> <x:ref>WWW-Authenticate-v</x:ref>
446  <x:ref>WWW-Authenticate-v</x:ref> = 1#<x:ref>challenge</x:ref>
447</artwork></figure>
448<t>
449   The HTTP access authentication process is described in "HTTP
450   Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. User
451   agents are advised to take special care in parsing the WWW-Authenticate
452   field value as it might contain more than one challenge,
453   or if more than one WWW-Authenticate header field is provided, the
454   contents of a challenge itself can contain a comma-separated list of
455   authentication parameters.
456</t>
457</section>
458
459</section>
460
461<section title="IANA Considerations" anchor="IANA.considerations">
462<section title="Message Header Registration" anchor="message.header.registration">
463<t>
464   The Message Header Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated
465   with the permanent registrations below (see <xref target="RFC3864"/>):
466</t>
467<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
468<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
469   <ttcol>Header Field Name</ttcol>
470   <ttcol>Protocol</ttcol>
471   <ttcol>Status</ttcol>
472   <ttcol>Reference</ttcol>
473
474   <c>Authorization</c>
475   <c>http</c>
476   <c>standard</c>
477   <c>
478      <xref target="header.authorization"/>
479   </c>
480   <c>Proxy-Authenticate</c>
481   <c>http</c>
482   <c>standard</c>
483   <c>
484      <xref target="header.proxy-authenticate"/>
485   </c>
486   <c>Proxy-Authorization</c>
487   <c>http</c>
488   <c>standard</c>
489   <c>
490      <xref target="header.proxy-authorization"/>
491   </c>
492   <c>WWW-Authenticate</c>
493   <c>http</c>
494   <c>standard</c>
495   <c>
496      <xref target="header.www-authenticate"/>
497   </c>
498</texttable>
499<!--(END)-->
500<t>
501   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
502</t>
503</section>
504</section>
505
506<section title="Security Considerations" anchor="security.considerations">
507<t>
508   This section is meant to inform application developers, information
509   providers, and users of the security limitations in HTTP/1.1 as
510   described by this document. The discussion does not include
511   definitive solutions to the problems revealed, though it does make
512   some suggestions for reducing security risks.
513</t>
514
515<section title="Authentication Credentials and Idle Clients" anchor="auth.credentials.and.idle.clients">
516<t>
517   Existing HTTP clients and user agents typically retain authentication
518   information indefinitely. HTTP/1.1 does not provide a method for a
519   server to direct clients to discard these cached credentials. This is
520   a significant defect that requires further extensions to HTTP.
521   Circumstances under which credential caching can interfere with the
522   application's security model include but are not limited to:
523  <list style="symbols">
524     <t>Clients which have been idle for an extended period following
525        which the server might wish to cause the client to reprompt the
526        user for credentials.</t>
527
528     <t>Applications which include a session termination indication
529        (such as a `logout' or `commit' button on a page) after which
530        the server side of the application `knows' that there is no
531        further reason for the client to retain the credentials.</t>
532  </list>
533</t>
534<t>
535   This is currently under separate study. There are a number of work-arounds
536   to parts of this problem, and we encourage the use of
537   password protection in screen savers, idle time-outs, and other
538   methods which mitigate the security problems inherent in this
539   problem. In particular, user agents which cache credentials are
540   encouraged to provide a readily accessible mechanism for discarding
541   cached credentials under user control.
542</t>
543</section>
544</section>
545
546<section title="Acknowledgments" anchor="ack">
547<t>
548  <cref>TBD.</cref>
549</t>
550</section>
551</middle>
552
553<back>
554
555<references title="Normative References">
556
557<reference anchor="Part1">
558  <front>
559    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
560    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
561      <organization abbrev="Day Software">Day Software</organization>
562      <address><email>fielding@gbiv.com</email></address>
563    </author>
564    <author initials="J." surname="Gettys" fullname="Jim Gettys">
565      <organization>One Laptop per Child</organization>
566      <address><email>jg@laptop.org</email></address>
567    </author>
568    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
569      <organization abbrev="HP">Hewlett-Packard Company</organization>
570      <address><email>JeffMogul@acm.org</email></address>
571    </author>
572    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
573      <organization abbrev="Microsoft">Microsoft Corporation</organization>
574      <address><email>henrikn@microsoft.com</email></address>
575    </author>
576    <author initials="L." surname="Masinter" fullname="Larry Masinter">
577      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
578      <address><email>LMM@acm.org</email></address>
579    </author>
580    <author initials="P." surname="Leach" fullname="Paul J. Leach">
581      <organization abbrev="Microsoft">Microsoft Corporation</organization>
582      <address><email>paulle@microsoft.com</email></address>
583    </author>
584    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
585      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
586      <address><email>timbl@w3.org</email></address>
587    </author>
588    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
589      <organization abbrev="W3C">World Wide Web Consortium</organization>
590      <address><email>ylafon@w3.org</email></address>
591    </author>
592    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
593      <organization abbrev="greenbytes">greenbytes GmbH</organization>
594      <address><email>julian.reschke@greenbytes.de</email></address>
595    </author>
596    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
597  </front>
598  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
599  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
600</reference>
601
602<reference anchor="Part6">
603  <front>
604    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
605    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
606      <organization abbrev="Day Software">Day Software</organization>
607      <address><email>fielding@gbiv.com</email></address>
608    </author>
609    <author initials="J." surname="Gettys" fullname="Jim Gettys">
610      <organization>One Laptop per Child</organization>
611      <address><email>jg@laptop.org</email></address>
612    </author>
613    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
614      <organization abbrev="HP">Hewlett-Packard Company</organization>
615      <address><email>JeffMogul@acm.org</email></address>
616    </author>
617    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
618      <organization abbrev="Microsoft">Microsoft Corporation</organization>
619      <address><email>henrikn@microsoft.com</email></address>
620    </author>
621    <author initials="L." surname="Masinter" fullname="Larry Masinter">
622      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
623      <address><email>LMM@acm.org</email></address>
624    </author>
625    <author initials="P." surname="Leach" fullname="Paul J. Leach">
626      <organization abbrev="Microsoft">Microsoft Corporation</organization>
627      <address><email>paulle@microsoft.com</email></address>
628    </author>
629    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
630      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
631      <address><email>timbl@w3.org</email></address>
632    </author>
633    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
634      <organization abbrev="W3C">World Wide Web Consortium</organization>
635      <address><email>ylafon@w3.org</email></address>
636    </author>
637    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
638      <organization abbrev="greenbytes">greenbytes GmbH</organization>
639      <address><email>julian.reschke@greenbytes.de</email></address>
640    </author>
641    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
642  </front>
643  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
644  <x:source href="p6-cache.xml" basename="p6-cache"/>
645</reference>
646
647<reference anchor="RFC2119">
648  <front>
649    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
650    <author initials="S." surname="Bradner" fullname="Scott Bradner">
651      <organization>Harvard University</organization>
652      <address><email>sob@harvard.edu</email></address>
653    </author>
654    <date month="March" year="1997"/>
655  </front>
656  <seriesInfo name="BCP" value="14"/>
657  <seriesInfo name="RFC" value="2119"/>
658</reference>
659
660<reference anchor="RFC2617">
661  <front>
662    <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
663    <author initials="J." surname="Franks" fullname="John Franks">
664      <organization>Northwestern University, Department of Mathematics</organization>
665      <address><email>john@math.nwu.edu</email></address>
666    </author>
667    <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
668      <organization>Verisign Inc.</organization>
669      <address><email>pbaker@verisign.com</email></address>
670    </author>
671    <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
672      <organization>AbiSource, Inc.</organization>
673      <address><email>jeff@AbiSource.com</email></address>
674    </author>
675    <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
676      <organization>Agranat Systems, Inc.</organization>
677      <address><email>lawrence@agranat.com</email></address>
678    </author>
679    <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
680      <organization>Microsoft Corporation</organization>
681      <address><email>paulle@microsoft.com</email></address>
682    </author>
683    <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
684      <organization>Netscape Communications Corporation</organization>
685    </author>
686    <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
687      <organization>Open Market, Inc.</organization>
688      <address><email>stewart@OpenMarket.com</email></address>
689    </author>
690    <date month="June" year="1999"/>
691  </front>
692  <seriesInfo name="RFC" value="2617"/>
693</reference>
694
695</references>
696
697<references title="Informative References">
698
699<reference anchor="RFC2616">
700  <front>
701    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
702    <author initials="R." surname="Fielding" fullname="R. Fielding">
703      <organization>University of California, Irvine</organization>
704      <address><email>fielding@ics.uci.edu</email></address>
705    </author>
706    <author initials="J." surname="Gettys" fullname="J. Gettys">
707      <organization>W3C</organization>
708      <address><email>jg@w3.org</email></address>
709    </author>
710    <author initials="J." surname="Mogul" fullname="J. Mogul">
711      <organization>Compaq Computer Corporation</organization>
712      <address><email>mogul@wrl.dec.com</email></address>
713    </author>
714    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
715      <organization>MIT Laboratory for Computer Science</organization>
716      <address><email>frystyk@w3.org</email></address>
717    </author>
718    <author initials="L." surname="Masinter" fullname="L. Masinter">
719      <organization>Xerox Corporation</organization>
720      <address><email>masinter@parc.xerox.com</email></address>
721    </author>
722    <author initials="P." surname="Leach" fullname="P. Leach">
723      <organization>Microsoft Corporation</organization>
724      <address><email>paulle@microsoft.com</email></address>
725    </author>
726    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
727      <organization>W3C</organization>
728      <address><email>timbl@w3.org</email></address>
729    </author>
730    <date month="June" year="1999"/>
731  </front>
732  <seriesInfo name="RFC" value="2616"/>
733</reference>
734
735<reference anchor='RFC3864'>
736  <front>
737    <title>Registration Procedures for Message Header Fields</title>
738    <author initials='G.' surname='Klyne' fullname='G. Klyne'>
739      <organization>Nine by Nine</organization>
740      <address><email>GK-IETF@ninebynine.org</email></address>
741    </author>
742    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
743      <organization>BEA Systems</organization>
744      <address><email>mnot@pobox.com</email></address>
745    </author>
746    <author initials='J.' surname='Mogul' fullname='J. Mogul'>
747      <organization>HP Labs</organization>
748      <address><email>JeffMogul@acm.org</email></address>
749    </author>
750    <date year='2004' month='September' />
751  </front>
752  <seriesInfo name='BCP' value='90' />
753  <seriesInfo name='RFC' value='3864' />
754</reference>
755
756</references>
757
758
759<section title="Compatibility with Previous Versions" anchor="compatibility">
760
761<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
762</section>
763
764</section>
765
766<section title="Collected ABNF" anchor="collected.abnf">
767   <figure>
768      <artwork type="abnf" name="p7-auth.parsed-abnf">Authorization = "Authorization:" OWS Authorization-v&#xD;
769Authorization-v = credentials&#xD;
770OWS = &lt;OWS, defined in [Part1], Section 1.2.2&gt;&#xD;
771Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v&#xD;
772Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS&#xD;
773 challenge ] )&#xD;
774Proxy-Authorization = "Proxy-Authorization:" OWS&#xD;
775 Proxy-Authorization-v&#xD;
776Proxy-Authorization-v = credentials&#xD;
777WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v&#xD;
778WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS&#xD;
779 challenge ] )&#xD;
780challenge = &lt;challenge, defined in [RFC2617], Section 1.2&gt;&#xD;
781credentials = &lt;credentials, defined in [RFC2617], Section 1.2&gt;&#xD;
782; Authorization defined but not used&#xD;
783; Proxy-Authenticate defined but not used&#xD;
784; Proxy-Authorization defined but not used&#xD;
785; WWW-Authenticate defined but not used&#xD;
786</artwork>
787   </figure>
788</section>
789
790<section title="Change Log (to be removed by RFC Editor before publication)"  anchor="change.log">
791
792<section title="Since RFC2616">
793<t>
794  Extracted relevant partitions from <xref target="RFC2616"/>.
795</t>
796</section>
797
798<section title="Since draft-ietf-httpbis-p7-auth-00">
799<t>
800  Closed issues:
801  <list style="symbols"> 
802    <t>
803      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>:
804      "Normative and Informative references"
805    </t>
806  </list>
807</t>
808</section>
809
810<section title="Since draft-ietf-httpbis-p7-auth-01">
811<t>
812  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
813  <list style="symbols"> 
814    <t>
815      Explicitly import BNF rules for "challenge" and "credentials" from RFC2617.
816    </t>
817    <t>
818      Add explicit references to BNF syntax and rules imported from other parts of the specification.
819    </t>
820  </list>
821</t>
822</section>
823
824<section title="Since draft-ietf-httpbis-p7-auth-02" anchor="changes.since.02">
825<t>
826  Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
827  <list style="symbols"> 
828    <t>
829      Reference RFC 3984, and update header registrations for headers defined
830      in this document.
831    </t>
832  </list>
833</t>
834</section>
835
836<section title="Since draft-ietf-httpbis-p7-auth-03" anchor="changes.since.03">
837<t>
838</t>
839</section>
840
841<section title="Since draft-ietf-httpbis-p7-auth-04" anchor="changes.since.04">
842<t>
843  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
844  <list style="symbols"> 
845    <t>
846      Use "/" instead of "|" for alternatives.
847    </t>
848    <t>
849      Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
850      whitespace ("OWS") and required whitespace ("RWS").
851    </t>
852    <t>
853      Rewrite ABNFs to spell out whitespace rules, factor out
854      header value format definitions.
855    </t>
856  </list>
857</t>
858</section>
859
860<section title="Since draft-ietf-httpbis-p7-auth-05" anchor="changes.since.05">
861<t>
862  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
863  <list style="symbols"> 
864    <t>
865      Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.
866    </t>
867  </list>
868</t>
869</section>
870
871</section>
872
873</back>
874</rfc>
Note: See TracBrowser for help on using the repository browser.