source: draft-ietf-httpbis/00/draft-ietf-httpbis-p7-auth-00.xml @ 61

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

fix draft name prefix ("draft-fielding-" -> "draft-ietf-httpbis-")

  • Property svn:eol-style set to native
File size: 22.3 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!--
3    This XML document is the output of clean-for-DTD.xslt; a tool that strips
4    extensions to RFC2629(bis) from documents for processing with xml2rfc.
5-->
6<?rfc toc="yes" ?>
7<?rfc symrefs="yes" ?>
8<?rfc sortrefs="yes" ?>
9<?rfc compact="yes"?>
10<?rfc subcompact="no" ?>
11<?rfc linkmailto="no" ?>
12<?rfc editing="no" ?>
13<!DOCTYPE rfc
14  PUBLIC "" "rfc2629.dtd">
15<rfc obsoletes="2068, 2616" updates="2617" category="std" ipr="full3978" docName="draft-ietf-httpbis-p7-auth-00">
16<front>
17
18  <title abbrev="HTTP/1.1">HTTP/1.1, part 7: Authentication</title>
19
20  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
21    <organization abbrev="Day Software">Day Software</organization>
22    <address>
23      <postal>
24        <street>23 Corporate Plaza DR, Suite 280</street>
25        <city>Newport Beach</city>
26        <region>CA</region>
27        <code>92660</code>
28        <country>USA</country>
29      </postal>
30      <phone>+1-949-706-5300</phone>
31      <facsimile>+1-949-706-5305</facsimile>
32      <email>fielding@gbiv.com</email>
33      <uri>http://roy.gbiv.com/</uri>
34    </address>
35  </author>
36
37  <author initials="J." surname="Gettys" fullname="Jim Gettys">
38    <organization>One Laptop per Child</organization>
39    <address>
40      <postal>
41        <street>21 Oak Knoll Road</street>
42        <city>Carlisle</city>
43        <region>MA</region>
44        <code>01741</code>
45        <country>USA</country>
46      </postal>
47      <email>jg@laptop.org</email>
48      <uri>http://www.laptop.org/</uri>
49    </address>
50  </author>
51 
52  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
53    <organization abbrev="HP">Hewlett-Packard Company</organization>
54    <address>
55      <postal>
56        <street>HP Labs, Large Scale Systems Group</street>
57        <street>1501 Page Mill Road, MS 1177</street>
58        <city>Palo Alto</city>
59        <region>CA</region>
60        <code>94304</code>
61        <country>USA</country>
62      </postal>
63      <email>JeffMogul@acm.org</email>
64    </address>
65  </author>
66
67  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
68    <organization abbrev="Microsoft">Microsoft Corporation</organization>
69    <address>
70      <postal>
71        <street>1 Microsoft Way</street>
72        <city>Redmond</city>
73        <region>WA</region>
74        <code>98052</code>
75        <country>USA</country>
76      </postal>
77      <email>henrikn@microsoft.com</email>
78    </address>
79  </author>
80
81  <author initials="L." surname="Masinter" fullname="Larry Masinter">
82    <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
83    <address>
84      <postal>
85        <street>345 Park Ave</street>
86        <city>San Jose</city>
87        <region>CA</region>
88        <code>95110</code>
89        <country>USA</country>
90      </postal>
91      <email>LMM@acm.org</email>
92      <uri>http://larry.masinter.net/</uri>
93    </address>
94  </author>
95 
96  <author initials="P." surname="Leach" fullname="Paul J. Leach">
97    <organization abbrev="Microsoft">Microsoft Corporation</organization>
98    <address>
99      <postal>
100        <street>1 Microsoft Way</street>
101        <city>Redmond</city>
102        <region>WA</region>
103        <code>98052</code>
104      </postal>
105      <email>paulle@microsoft.com</email>
106    </address>
107  </author>
108   
109  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
110    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
111    <address>
112      <postal>
113        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
114        <street>The Stata Center, Building 32</street>
115        <street>32 Vassar Street</street>
116        <city>Cambridge</city>
117        <region>MA</region>
118        <code>02139</code>
119        <country>USA</country>
120      </postal>
121      <email>timbl@w3.org</email>
122      <uri>http://www.w3.org/People/Berners-Lee/</uri>
123    </address>
124  </author>
125
126  <date month="December" year="2007"/>
127
128<abstract>
129<t>
130   The Hypertext Transfer Protocol (HTTP) is an application-level
131   protocol for distributed, collaborative, hypermedia information
132   systems. HTTP has been in use by the World Wide Web global information
133   initiative since 1990. This document is Part 7 of the seven-part specification
134   that defines the protocol referred to as "HTTP/1.1" and, taken together,
135   obsoletes RFC 2616.  Part 7 defines HTTP Authentication.
136</t>
137</abstract>
138
139<note title="Editorial Note (To be removed by RFC Editor)">
140  <t>
141    This version of the HTTP specification contains only minimal editorial
142    changes from <xref target="RFC2616"/> (abstract, introductory paragraph,
143    and authors' addresses).  All other changes are due to partitioning the
144    original into seven mostly independent parts.  The intent is for readers
145    of future drafts to able to use draft 00 as the basis for comparison
146    when the WG makes later changes to the specification text.  This draft
147    will shortly be followed by draft 01 (containing the first round of changes
148    that have already been agreed to on the mailing list). There is no point in
149    reviewing this draft other than to verify that the partitioning has been
150    done correctly.  Roy T. Fielding, Yves Lafon, and Julian Reschke
151    will be the editors after draft 00 is submitted.
152  </t>
153  <t>
154    Discussion of this draft should take place on the HTTPBIS working group
155    mailing list (ietf-http-wg@w3.org). The current issues list is
156    at <eref target="http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/"/>
157    and related documents (including fancy diffs) can be found at
158    <eref target="http://www3.tools.ietf.org/wg/httpbis/"/>.
159  </t>
160</note>
161</front>
162<middle>
163<section title="Introduction" anchor="introduction">
164<t>
165   This document will define aspects of HTTP related to access control and
166   authentication. Right now it only includes the extracted relevant sections
167   of <xref target="RFC2616">RFC 2616</xref> with only minor edits.
168</t>
169<t>
170   HTTP provides several OPTIONAL challenge-response authentication
171   mechanisms which can be used by a server to challenge a client
172   request and by a client to provide authentication information. The
173   general framework for access authentication, and the specification of
174   "basic" and "digest" authentication, are specified in "HTTP
175   Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. This
176   specification adopts the definitions of "challenge" and "credentials"
177   from that specification.
178</t>
179</section>
180
181<section title="Status Code Definitions">
182<section title="401 Unauthorized" anchor="status.401">
183  <iref primary="true" item="401 Unauthorized (status code)"/>
184  <iref primary="true" item="Status Codes" subitem="401 Unauthorized"/>
185<t>
186   The request requires user authentication. The response MUST include a
187   WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge
188   applicable to the requested resource. The client MAY repeat the
189   request with a suitable Authorization header field (<xref target="header.authorization"/>). If
190   the request already included Authorization credentials, then the 401
191   response indicates that authorization has been refused for those
192   credentials. If the 401 response contains the same challenge as the
193   prior response, and the user agent has already attempted
194   authentication at least once, then the user SHOULD be presented the
195   entity that was given in the response, since that entity might
196   include relevant diagnostic information. HTTP access authentication
197   is explained in "HTTP Authentication: Basic and Digest Access
198   Authentication" <xref target="RFC2617"/>.
199</t>
200</section>
201<section title="407 Proxy Authentication Required" anchor="status.407">
202  <iref primary="true" item="407 Proxy Authentication Required (status code)"/>
203  <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required"/>
204<t>
205   This code is similar to 401 (Unauthorized), but indicates that the
206   client must first authenticate itself with the proxy. The proxy MUST
207   return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
208   challenge applicable to the proxy for the requested resource. The
209   client MAY repeat the request with a suitable Proxy-Authorization
210   header field (<xref target="header.proxy-authorization"/>). HTTP access authentication is explained
211   in "HTTP Authentication: Basic and Digest Access Authentication"
212   <xref target="RFC2617"/>.
213</t>
214</section>
215</section>
216
217<section title="Header Field Definitions" anchor="header.fields">
218<t>
219   This section defines the syntax and semantics of all standard
220   HTTP/1.1 header fields. For entity-header fields, both sender and
221   recipient refer to either the client or the server, depending on who
222   sends and who receives the entity.
223</t>
224
225<section title="Authorization" anchor="header.authorization">
226  <iref primary="true" item="Authorization header"/>
227  <iref primary="true" item="Headers" subitem="Authorization"/>
228<t>
229      A user agent that wishes to authenticate itself with a server--
230      usually, but not necessarily, after receiving a 401 response--does
231      so by including an Authorization request-header field with the
232      request.  The Authorization field value consists of credentials
233      containing the authentication information of the user agent for
234      the realm of the resource being requested.
235</t>
236<figure><iref primary="true" item="Grammar" subitem="Authorization"/><artwork type="abnf2616"><![CDATA[
237       Authorization  = "Authorization" ":" credentials
238]]></artwork></figure>
239<t>
240      HTTP access authentication is described in "HTTP Authentication:
241      Basic and Digest Access Authentication" <xref target="RFC2617"/>. If a request is
242      authenticated and a realm specified, the same credentials SHOULD
243      be valid for all other requests within this realm (assuming that
244      the authentication scheme itself does not require otherwise, such
245      as credentials that vary according to a challenge value or using
246      synchronized clocks).
247</t>
248<t>
249      When a shared cache (see Section 2.7 of <xref target="Part6"/>) receives a request
250      containing an Authorization field, it MUST NOT return the
251      corresponding response as a reply to any other request, unless one
252      of the following specific exceptions holds:
253</t>
254<t>
255  <list style="numbers">
256      <t>If the response includes the "s-maxage" cache-control
257         directive, the cache MAY use that response in replying to a
258         subsequent request. But (if the specified maximum age has
259         passed) a proxy cache MUST first revalidate it with the origin
260         server, using the request-headers from the new request to allow
261         the origin server to authenticate the new request. (This is the
262         defined behavior for s-maxage.) If the response includes "s-maxage=0",
263         the proxy MUST always revalidate it before re-using
264         it.</t>
265
266      <t>If the response includes the "must-revalidate" cache-control
267         directive, the cache MAY use that response in replying to a
268         subsequent request. But if the response is stale, all caches
269         MUST first revalidate it with the origin server, using the
270         request-headers from the new request to allow the origin server
271         to authenticate the new request.</t>
272
273      <t>If the response includes the "public" cache-control directive,
274         it MAY be returned in reply to any subsequent request.</t>
275  </list>
276</t>
277</section>
278
279<section title="Proxy-Authenticate" anchor="header.proxy-authenticate">
280  <iref primary="true" item="Proxy-Authenticate header"/>
281  <iref primary="true" item="Headers" subitem="Proxy-Authenticate"/>
282<t>
283   The Proxy-Authenticate response-header field MUST be included as part
284   of a 407 (Proxy Authentication Required) response. The field value
285   consists of a challenge that indicates the authentication scheme and
286   parameters applicable to the proxy for this Request-URI.
287</t>
288<figure><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/><artwork type="abnf2616"><![CDATA[
289    Proxy-Authenticate  = "Proxy-Authenticate" ":" 1#challenge
290]]></artwork></figure>
291<t>
292   The HTTP access authentication process is described in "HTTP
293   Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike
294   WWW-Authenticate, the Proxy-Authenticate header field applies only to
295   the current connection and SHOULD NOT  be passed on to downstream
296   clients. However, an intermediate proxy might need to obtain its own
297   credentials by requesting them from the downstream client, which in
298   some circumstances will appear as if the proxy is forwarding the
299   Proxy-Authenticate header field.
300</t>
301</section>
302
303<section title="Proxy-Authorization" anchor="header.proxy-authorization">
304  <iref primary="true" item="Proxy-Authorization header"/>
305  <iref primary="true" item="Headers" subitem="Proxy-Authorization"/>
306<t>
307   The Proxy-Authorization request-header field allows the client to
308   identify itself (or its user) to a proxy which requires
309   authentication. The Proxy-Authorization field value consists of
310   credentials containing the authentication information of the user
311   agent for the proxy and/or realm of the resource being requested.
312</t>
313<figure><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/><artwork type="abnf2616"><![CDATA[
314    Proxy-Authorization     = "Proxy-Authorization" ":" credentials
315]]></artwork></figure>
316<t>
317   The HTTP access authentication process is described in "HTTP
318   Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike
319   Authorization, the Proxy-Authorization header field applies only to
320   the next outbound proxy that demanded authentication using the Proxy-Authenticate
321   field. When multiple proxies are used in a chain, the
322   Proxy-Authorization header field is consumed by the first outbound
323   proxy that was expecting to receive credentials. A proxy MAY relay
324   the credentials from the client request to the next proxy if that is
325   the mechanism by which the proxies cooperatively authenticate a given
326   request.
327</t>
328</section>
329
330<section title="WWW-Authenticate" anchor="header.www-authenticate">
331  <iref primary="true" item="WWW-Authenticate header"/>
332  <iref primary="true" item="Headers" subitem="WWW-Authenticate"/>
333<t>
334   The WWW-Authenticate response-header field MUST be included in 401
335   (Unauthorized) response messages. The field value consists of at
336   least one challenge that indicates the authentication scheme(s) and
337   parameters applicable to the Request-URI.
338</t>
339<figure><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/><artwork type="abnf2616"><![CDATA[
340    WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
341]]></artwork></figure>
342<t>
343   The HTTP access authentication process is described in "HTTP
344   Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. User
345   agents are advised to take special care in parsing the WWW-Authenticate
346   field value as it might contain more than one challenge,
347   or if more than one WWW-Authenticate header field is provided, the
348   contents of a challenge itself can contain a comma-separated list of
349   authentication parameters.
350</t>
351</section>
352
353</section>
354
355<section title="IANA Considerations" anchor="IANA.considerations">
356<t>
357   TBD.
358</t>
359</section>
360
361<section title="Security Considerations" anchor="security.considerations">
362<t>
363   This section is meant to inform application developers, information
364   providers, and users of the security limitations in HTTP/1.1 as
365   described by this document. The discussion does not include
366   definitive solutions to the problems revealed, though it does make
367   some suggestions for reducing security risks.
368</t>
369
370<section title="Authentication Credentials and Idle Clients" anchor="auth.credentials.and.idle.clients">
371<t>
372   Existing HTTP clients and user agents typically retain authentication
373   information indefinitely. HTTP/1.1. does not provide a method for a
374   server to direct clients to discard these cached credentials. This is
375   a significant defect that requires further extensions to HTTP.
376   Circumstances under which credential caching can interfere with the
377   application's security model include but are not limited to:
378  <list style="symbols">
379     <t>Clients which have been idle for an extended period following
380        which the server might wish to cause the client to reprompt the
381        user for credentials.</t>
382
383     <t>Applications which include a session termination indication
384        (such as a `logout' or `commit' button on a page) after which
385        the server side of the application `knows' that there is no
386        further reason for the client to retain the credentials.</t>
387  </list>
388</t>
389<t>
390   This is currently under separate study. There are a number of work-arounds
391   to parts of this problem, and we encourage the use of
392   password protection in screen savers, idle time-outs, and other
393   methods which mitigate the security problems inherent in this
394   problem. In particular, user agents which cache credentials are
395   encouraged to provide a readily accessible mechanism for discarding
396   cached credentials under user control.
397</t>
398</section>
399</section>
400
401<section title="Acknowledgments" anchor="ack">
402<t>
403   Based on an XML translation of RFC 2616 by Julian Reschke.
404</t>
405</section>
406</middle>
407<back>
408<references>
409
410<reference anchor="Part6">
411   <front>
412      <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
413      <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
414         <organization abbrev="Day Software">Day Software</organization>
415         <address><email>fielding@gbiv.com</email></address>
416      </author>
417      <author initials="J." surname="Gettys" fullname="Jim Gettys">
418         <organization>One Laptop per Child</organization>
419         <address><email>jg@laptop.org</email></address>
420      </author>
421      <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
422         <organization abbrev="HP">Hewlett-Packard Company</organization>
423         <address><email>JeffMogul@acm.org</email></address>
424      </author>
425      <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
426         <organization abbrev="Microsoft">Microsoft Corporation</organization>
427         <address><email>henrikn@microsoft.com</email></address>
428      </author>
429      <author initials="L." surname="Masinter" fullname="Larry Masinter">
430         <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
431         <address><email>LMM@acm.org</email></address>
432      </author>
433      <author initials="P." surname="Leach" fullname="Paul J. Leach">
434         <organization abbrev="Microsoft">Microsoft Corporation</organization>
435         <address><email>paulle@microsoft.com</email></address>
436      </author>
437      <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
438         <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
439         <address><email>timbl@w3.org</email></address>
440      </author>
441      <date month="December" year="2007"/>
442   </front>
443   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-00"/>
444   
445</reference>
446
447<reference anchor="RFC2616">
448   <front>
449      <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
450      <author initials="R." surname="Fielding" fullname="R. Fielding">
451         <organization>University of California, Irvine</organization>
452         <address><email>fielding@ics.uci.edu</email></address>
453      </author>
454      <author initials="J." surname="Gettys" fullname="J. Gettys">
455         <organization>W3C</organization>
456         <address><email>jg@w3.org</email></address>
457      </author>
458      <author initials="J." surname="Mogul" fullname="J. Mogul">
459         <organization>Compaq Computer Corporation</organization>
460         <address><email>mogul@wrl.dec.com</email></address>
461      </author>
462      <author initials="H." surname="Frystyk" fullname="H. Frystyk">
463         <organization>MIT Laboratory for Computer Science</organization>
464         <address><email>frystyk@w3.org</email></address>
465      </author>
466      <author initials="L." surname="Masinter" fullname="L. Masinter">
467         <organization>Xerox Corporation</organization>
468         <address><email>masinter@parc.xerox.com</email></address>
469      </author>
470      <author initials="P." surname="Leach" fullname="P. Leach">
471         <organization>Microsoft Corporation</organization>
472         <address><email>paulle@microsoft.com</email></address>
473      </author>
474      <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
475         <organization>W3C</organization>
476         <address><email>timbl@w3.org</email></address>
477      </author>
478      <date month="June" year="1999"/>
479   </front>
480   <seriesInfo name="RFC" value="2616"/>
481</reference>
482
483<reference anchor="RFC2617">
484   <front>
485      <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
486      <author initials="J." surname="Franks" fullname="John Franks">
487         <organization>Northwestern University, Department of Mathematics</organization>
488         <address><email>john@math.nwu.edu</email></address>
489      </author>
490      <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
491         <organization>Verisign Inc.</organization>
492         <address><email>pbaker@verisign.com</email></address>
493      </author>
494      <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
495         <organization>AbiSource, Inc.</organization>
496         <address><email>jeff@AbiSource.com</email></address>
497      </author>
498      <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
499         <organization>Agranat Systems, Inc.</organization>
500         <address><email>lawrence@agranat.com</email></address>
501      </author>
502      <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
503         <organization>Microsoft Corporation</organization>
504         <address><email>paulle@microsoft.com</email></address>
505      </author>
506      <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
507         <organization>Netscape Communications Corporation</organization>
508      </author>
509      <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
510         <organization>Open Market, Inc.</organization>
511         <address><email>stewart@OpenMarket.com</email></address>
512      </author>
513      <date month="June" year="1999"/>
514   </front>
515   <seriesInfo name="RFC" value="2617"/>
516</reference>
517
518</references>
519</back>
520</rfc>
Note: See TracBrowser for help on using the repository browser.