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

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

Partition RFC 2616 into seven (mostly) independent documents.
No semantic changes. Some meaningless crossreferences to prior
editorial decisions have been removed from appendices.

Structural changes minimized to simplify diff versus rfc2616.
This was a lot harder than it looks.

Part 8 (Cookies) is for future specification based on RFC 2965.

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