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

Last change on this file since 91 was 62, checked in by fielding@…, 12 years ago

switch to new issue tracking system

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