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

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

Insert cross-document references.

  • Property svn:eol-style set to native
File size: 21.0 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, 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 Laboratory for Computer Science</street>
128        <street>545 Technology Square</street>
129        <city>Cambridge</city>
130        <region>MA</region>
131        <code>02139</code>
132        <country>USA</country>
133      </postal>
134      <facsimile>+1 (617) 258 8682</facsimile>
135      <email>timbl@w3.org</email>
136    </address>
137  </author>
138
139  <date month="&ID-MONTH;" year="&ID-YEAR;"/>
140
141<abstract>
142<t>
143   The Hypertext Transfer Protocol (HTTP) is an application-level
144   protocol for distributed, collaborative, hypermedia information
145   systems. HTTP has been in use by the World Wide Web global information
146   initiative since 1990. This document is Part 7 of the eight-part specification
147   that defines the protocol referred to as "HTTP/1.1" and, taken together,
148   updates RFC 2616 and RFC 2617.  Part 7 defines HTTP Authentication.
149</t>
150</abstract>
151</front>
152<middle>
153<section title="Introduction" anchor="introduction">
154<t>
155   This document will define aspects of HTTP related to access control and
156   authentication. Right now it only includes the extracted relevant sections
157   of <xref target="RFC2616">RFC 2616</xref> with only minor edits.
158</t>
159<t>
160   HTTP provides several &OPTIONAL; challenge-response authentication
161   mechanisms which can be used by a server to challenge a client
162   request and by a client to provide authentication information. The
163   general framework for access authentication, and the specification of
164   "basic" and "digest" authentication, are specified in "HTTP
165   Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. This
166   specification adopts the definitions of "challenge" and "credentials"
167   from that specification.
168</t>
169</section>
170<section title="Header Field Definitions" anchor="header.fields">
171<t>
172   This section defines the syntax and semantics of all standard
173   HTTP/1.1 header fields. For entity-header fields, both sender and
174   recipient refer to either the client or the server, depending on who
175   sends and who receives the entity.
176</t>
177
178<section title="Authorization" anchor="header.authorization">
179  <iref primary="true" item="Authorization header" x:for-anchor=""/>
180  <iref primary="true" item="Headers" subitem="Authorization" x:for-anchor=""/>
181<t>
182      A user agent that wishes to authenticate itself with a server--
183      usually, but not necessarily, after receiving a 401 response--does
184      so by including an Authorization request-header field with the
185      request.  The Authorization field value consists of credentials
186      containing the authentication information of the user agent for
187      the realm of the resource being requested.
188</t>
189<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/>
190       Authorization  = "Authorization" ":" credentials
191</artwork></figure>
192<t>
193      HTTP access authentication is described in "HTTP Authentication:
194      Basic and Digest Access Authentication" <xref target="RFC2617"/>. If a request is
195      authenticated and a realm specified, the same credentials &SHOULD;
196      be valid for all other requests within this realm (assuming that
197      the authentication scheme itself does not require otherwise, such
198      as credentials that vary according to a challenge value or using
199      synchronized clocks).
200</t>
201<t>
202      When a shared cache (see &shared-and-non-shared-caches;) receives a request
203      containing an Authorization field, it &MUST-NOT; return the
204      corresponding response as a reply to any other request, unless one
205      of the following specific exceptions holds:
206</t>
207<t>
208  <list style="numbers">
209      <t>If the response includes the "s-maxage" cache-control
210         directive, the cache &MAY; use that response in replying to a
211         subsequent request. But (if the specified maximum age has
212         passed) a proxy cache &MUST; first revalidate it with the origin
213         server, using the request-headers from the new request to allow
214         the origin server to authenticate the new request. (This is the
215         defined behavior for s-maxage.) If the response includes "s-maxage=0",
216         the proxy &MUST; always revalidate it before re-using
217         it.</t>
218
219      <t>If the response includes the "must-revalidate" cache-control
220         directive, the cache &MAY; use that response in replying to a
221         subsequent request. But if the response is stale, all caches
222         &MUST; first revalidate it with the origin server, using the
223         request-headers from the new request to allow the origin server
224         to authenticate the new request.</t>
225
226      <t>If the response includes the "public" cache-control directive,
227         it &MAY; be returned in reply to any subsequent request.</t>
228  </list>
229</t>
230</section>
231
232<section title="Proxy-Authenticate" anchor="header.proxy-authenticate">
233  <iref primary="true" item="Proxy-Authenticate header" x:for-anchor=""/>
234  <iref primary="true" item="Headers" subitem="Proxy-Authenticate" x:for-anchor=""/>
235<t>
236   The Proxy-Authenticate response-header field &MUST; be included as part
237   of a 407 (Proxy Authentication Required) response. The field value
238   consists of a challenge that indicates the authentication scheme and
239   parameters applicable to the proxy for this Request-URI.
240</t>
241<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/>
242    Proxy-Authenticate  = "Proxy-Authenticate" ":" 1#challenge
243</artwork></figure>
244<t>
245   The HTTP access authentication process is described in "HTTP
246   Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike
247   WWW-Authenticate, the Proxy-Authenticate header field applies only to
248   the current connection and &SHOULD-NOT;  be passed on to downstream
249   clients. However, an intermediate proxy might need to obtain its own
250   credentials by requesting them from the downstream client, which in
251   some circumstances will appear as if the proxy is forwarding the
252   Proxy-Authenticate header field.
253</t>
254</section>
255
256<section title="Proxy-Authorization" anchor="header.proxy-authorization">
257  <iref primary="true" item="Proxy-Authorization header" x:for-anchor=""/>
258  <iref primary="true" item="Headers" subitem="Proxy-Authorization" x:for-anchor=""/>
259<t>
260   The Proxy-Authorization request-header field allows the client to
261   identify itself (or its user) to a proxy which requires
262   authentication. The Proxy-Authorization field value consists of
263   credentials containing the authentication information of the user
264   agent for the proxy and/or realm of the resource being requested.
265</t>
266<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/>
267    Proxy-Authorization     = "Proxy-Authorization" ":" credentials
268</artwork></figure>
269<t>
270   The HTTP access authentication process is described in "HTTP
271   Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike
272   Authorization, the Proxy-Authorization header field applies only to
273   the next outbound proxy that demanded authentication using the Proxy-Authenticate
274   field. When multiple proxies are used in a chain, the
275   Proxy-Authorization header field is consumed by the first outbound
276   proxy that was expecting to receive credentials. A proxy &MAY; relay
277   the credentials from the client request to the next proxy if that is
278   the mechanism by which the proxies cooperatively authenticate a given
279   request.
280</t>
281</section>
282
283<section title="WWW-Authenticate" anchor="header.www-authenticate">
284  <iref primary="true" item="WWW-Authenticate header" x:for-anchor=""/>
285  <iref primary="true" item="Headers" subitem="WWW-Authenticate" x:for-anchor=""/>
286<t>
287   The WWW-Authenticate response-header field &MUST; be included in 401
288   (Unauthorized) response messages. The field value consists of at
289   least one challenge that indicates the authentication scheme(s) and
290   parameters applicable to the Request-URI.
291</t>
292<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/>
293    WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
294</artwork></figure>
295<t>
296   The HTTP access authentication process is described in "HTTP
297   Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. User
298   agents are advised to take special care in parsing the WWW-Authenticate
299   field value as it might contain more than one challenge,
300   or if more than one WWW-Authenticate header field is provided, the
301   contents of a challenge itself can contain a comma-separated list of
302   authentication parameters.
303</t>
304</section>
305
306</section>
307
308<section title="IANA Considerations" anchor="IANA.considerations">
309<t>
310   TBD.
311</t>
312</section>
313
314<section title="Security Considerations" anchor="security.considerations">
315<t>
316   This section is meant to inform application developers, information
317   providers, and users of the security limitations in HTTP/1.1 as
318   described by this document. The discussion does not include
319   definitive solutions to the problems revealed, though it does make
320   some suggestions for reducing security risks.
321</t>
322
323<section title="Authentication Credentials and Idle Clients" anchor="auth.credentials.and.idle.clients">
324<t>
325   Existing HTTP clients and user agents typically retain authentication
326   information indefinitely. HTTP/1.1. does not provide a method for a
327   server to direct clients to discard these cached credentials. This is
328   a significant defect that requires further extensions to HTTP.
329   Circumstances under which credential caching can interfere with the
330   application's security model include but are not limited to:
331  <list style="symbols">
332     <t>Clients which have been idle for an extended period following
333        which the server might wish to cause the client to reprompt the
334        user for credentials.</t>
335
336     <t>Applications which include a session termination indication
337        (such as a `logout' or `commit' button on a page) after which
338        the server side of the application `knows' that there is no
339        further reason for the client to retain the credentials.</t>
340  </list>
341</t>
342<t>
343   This is currently under separate study. There are a number of work-arounds
344   to parts of this problem, and we encourage the use of
345   password protection in screen savers, idle time-outs, and other
346   methods which mitigate the security problems inherent in this
347   problem. In particular, user agents which cache credentials are
348   encouraged to provide a readily accessible mechanism for discarding
349   cached credentials under user control.
350</t>
351</section>
352</section>
353
354<section title="Acknowledgments" anchor="ack">
355<t>
356   Based on an XML translation of RFC 2616 by Julian Reschke.
357</t>
358</section>
359</middle>
360<back>
361<references>
362<reference anchor="Part6">
363  <front>
364    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
365 
366    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
367      <organization abbrev="Day Software">Day Software</organization>
368      <address>
369        <email>fielding@gbiv.com</email>
370      </address>
371    </author>
372 
373    <author initials="J." surname="Gettys" fullname="Jim Gettys">
374      <organization>One Laptop per Child</organization>
375      <address>
376        <email>jg@laptop.org</email>
377      </address>
378    </author>
379   
380    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
381      <organization abbrev="HP">Hewlett-Packard Company</organization>
382      <address>
383        <email>JeffMogul@acm.org</email>
384      </address>
385    </author>
386 
387    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
388      <organization abbrev="Microsoft">Microsoft Corporation</organization>
389      <address>
390        <email>henrikn@microsoft.com</email>
391      </address>
392    </author>
393 
394    <author initials="L." surname="Masinter" fullname="Larry Masinter">
395      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
396      <address>
397        <email>LMM@acm.org</email>
398      </address>
399    </author>
400   
401    <author initials="P." surname="Leach" fullname="Paul J. Leach">
402      <organization abbrev="Microsoft">Microsoft Corporation</organization>
403      <address>
404        <email>paulle@microsoft.com</email>
405      </address>
406    </author>
407     
408    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
409      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
410      <address>
411        <email>timbl@w3.org</email>
412      </address>
413    </author>
414 
415    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
416  </front>
417  <seriesInfo name="Internet-Draft" value="draft-fielding-p6-cache-&ID-VERSION;"/>
418  <x:source href="p6-cache.xml" basename="p6-cache"/>
419</reference>
420
421<reference anchor="RFC2616">
422  <front>
423    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
424    <author initials="R." surname="Fielding" fullname="R. Fielding">
425      <organization>University of California, Irvine</organization>
426      <address><email>fielding@ics.uci.edu</email></address>
427    </author>
428    <author initials="J." surname="Gettys" fullname="J. Gettys">
429      <organization>W3C</organization>
430      <address><email>jg@w3.org</email></address>
431    </author>
432    <author initials="J." surname="Mogul" fullname="J. Mogul">
433      <organization>Compaq Computer Corporation</organization>
434      <address><email>mogul@wrl.dec.com</email></address>
435    </author>
436    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
437      <organization>MIT Laboratory for Computer Science</organization>
438      <address><email>frystyk@w3.org</email></address>
439    </author>
440    <author initials="L." surname="Masinter" fullname="L. Masinter">
441      <organization>Xerox Corporation</organization>
442      <address><email>masinter@parc.xerox.com</email></address>
443    </author>
444    <author initials="P." surname="Leach" fullname="P. Leach">
445      <organization>Microsoft Corporation</organization>
446      <address><email>paulle@microsoft.com</email></address>
447    </author>
448    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
449      <organization>W3C</organization>
450      <address><email>timbl@w3.org</email></address>
451    </author>
452    <date month="June" year="1999"/>
453  </front>
454  <seriesInfo name="RFC" value="2616"/>
455</reference>
456
457<reference anchor="RFC2617">
458<front>
459<title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
460<author initials="J." surname="Franks" fullname="John Franks">
461<organization>Northwestern University, Department of Mathematics</organization>
462<address>
463<postal>
464<street/>
465<city>Evanston</city>
466<region>IL</region>
467<code>60208-2730</code>
468<country>US</country></postal>
469<email>john@math.nwu.edu</email></address></author>
470<author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
471<organization>Verisign Inc.</organization>
472<address>
473<postal>
474<street>301 Edgewater Place</street>
475<street>Suite 210</street>
476<city>Wakefield</city>
477<region>MA</region>
478<code>01880</code>
479<country>US</country></postal>
480<email>pbaker@verisign.com</email></address></author>
481<author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
482<organization>AbiSource, Inc.</organization>
483<address>
484<postal>
485<street>6 Dunlap Court</street>
486<city>Savoy</city>
487<region>IL</region>
488<code>61874</code>
489<country>US</country></postal>
490<email>jeff@AbiSource.com</email></address></author>
491<author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
492<organization>Agranat Systems, Inc.</organization>
493<address>
494<postal>
495<street>5 Clocktower Place</street>
496<street>Suite 400</street>
497<city>Maynard</city>
498<region>MA</region>
499<code>01754</code>
500<country>US</country></postal>
501<email>lawrence@agranat.com</email></address></author>
502<author initials="P.J." surname="Leach" fullname="Paul J. Leach">
503<organization>Microsoft Corporation</organization>
504<address>
505<postal>
506<street>1 Microsoft Way</street>
507<city>Redmond</city>
508<region>WA</region>
509<code>98052</code>
510<country>US</country></postal>
511<email>paulle@microsoft.com</email></address></author>
512<author initials="A." surname="Luotonen" fullname="Ari Luotonen">
513<organization>Netscape Communications Corporation</organization>
514<address>
515<postal>
516<street>501 East Middlefield Road</street>
517<city>Mountain View</city>
518<region>CA</region>
519<code>94043</code>
520<country>US</country></postal></address></author>
521<author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
522<organization>Open Market, Inc.</organization>
523<address>
524<postal>
525<street>215 First Street</street>
526<city>Cambridge</city>
527<region>MA</region>
528<code>02142</code>
529<country>US</country></postal>
530<email>stewart@OpenMarket.com</email></address></author>
531<date month="June" year="1999"/>
532</front>
533<seriesInfo name="RFC" value="2617"/>
534</reference>
535</references>
536</back>
537</rfc>
Note: See TracBrowser for help on using the repository browser.