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

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

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