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

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

fix typo

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