1 | <?xml version="1.0" encoding="utf-8"?> |
---|
2 | <?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?> |
---|
3 | <!DOCTYPE rfc [ |
---|
4 | <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>"> |
---|
5 | <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>"> |
---|
6 | <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>"> |
---|
7 | <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>"> |
---|
8 | <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>"> |
---|
9 | <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>"> |
---|
10 | <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>"> |
---|
11 | <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>"> |
---|
12 | <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>"> |
---|
13 | <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>"> |
---|
14 | <!ENTITY ID-VERSION "latest"> |
---|
15 | <!ENTITY ID-MONTH "December"> |
---|
16 | <!ENTITY ID-YEAR "2010"> |
---|
17 | <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
18 | <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
19 | <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
20 | <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
21 | <!ENTITY end-to-end.and-hop-by-hop "<xref target='Part1' x:rel='#end-to-end.and.hop-by-hop.header-fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
22 | <!ENTITY shared-and-non-shared-caches "<xref target='Part6' x:rel='#shared.and.non-shared.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
23 | ]> |
---|
24 | <?rfc toc="yes" ?> |
---|
25 | <?rfc symrefs="yes" ?> |
---|
26 | <?rfc sortrefs="yes" ?> |
---|
27 | <?rfc compact="yes"?> |
---|
28 | <?rfc subcompact="no" ?> |
---|
29 | <?rfc linkmailto="no" ?> |
---|
30 | <?rfc editing="no" ?> |
---|
31 | <?rfc comments="yes"?> |
---|
32 | <?rfc inline="yes"?> |
---|
33 | <?rfc rfcedstyle="yes"?> |
---|
34 | <?rfc-ext allow-markup-in-artwork="yes" ?> |
---|
35 | <?rfc-ext include-references-in-index="yes" ?> |
---|
36 | <rfc obsoletes="2616" updates="2617" category="std" x:maturity-level="draft" |
---|
37 | ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p7-auth-&ID-VERSION;" |
---|
38 | xmlns:x='http://purl.org/net/xml2rfc/ext'> |
---|
39 | <front> |
---|
40 | |
---|
41 | <title abbrev="HTTP/1.1, Part 7">HTTP/1.1, part 7: Authentication</title> |
---|
42 | |
---|
43 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
44 | <organization abbrev="Day Software">Day Software</organization> |
---|
45 | <address> |
---|
46 | <postal> |
---|
47 | <street>23 Corporate Plaza DR, Suite 280</street> |
---|
48 | <city>Newport Beach</city> |
---|
49 | <region>CA</region> |
---|
50 | <code>92660</code> |
---|
51 | <country>USA</country> |
---|
52 | </postal> |
---|
53 | <phone>+1-949-706-5300</phone> |
---|
54 | <facsimile>+1-949-706-5305</facsimile> |
---|
55 | <email>fielding@gbiv.com</email> |
---|
56 | <uri>http://roy.gbiv.com/</uri> |
---|
57 | </address> |
---|
58 | </author> |
---|
59 | |
---|
60 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
61 | <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization> |
---|
62 | <address> |
---|
63 | <postal> |
---|
64 | <street>21 Oak Knoll Road</street> |
---|
65 | <city>Carlisle</city> |
---|
66 | <region>MA</region> |
---|
67 | <code>01741</code> |
---|
68 | <country>USA</country> |
---|
69 | </postal> |
---|
70 | <email>jg@freedesktop.org</email> |
---|
71 | <uri>http://gettys.wordpress.com/</uri> |
---|
72 | </address> |
---|
73 | </author> |
---|
74 | |
---|
75 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
76 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
77 | <address> |
---|
78 | <postal> |
---|
79 | <street>HP Labs, Large Scale Systems Group</street> |
---|
80 | <street>1501 Page Mill Road, MS 1177</street> |
---|
81 | <city>Palo Alto</city> |
---|
82 | <region>CA</region> |
---|
83 | <code>94304</code> |
---|
84 | <country>USA</country> |
---|
85 | </postal> |
---|
86 | <email>JeffMogul@acm.org</email> |
---|
87 | </address> |
---|
88 | </author> |
---|
89 | |
---|
90 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
91 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
92 | <address> |
---|
93 | <postal> |
---|
94 | <street>1 Microsoft Way</street> |
---|
95 | <city>Redmond</city> |
---|
96 | <region>WA</region> |
---|
97 | <code>98052</code> |
---|
98 | <country>USA</country> |
---|
99 | </postal> |
---|
100 | <email>henrikn@microsoft.com</email> |
---|
101 | </address> |
---|
102 | </author> |
---|
103 | |
---|
104 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
105 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
106 | <address> |
---|
107 | <postal> |
---|
108 | <street>345 Park Ave</street> |
---|
109 | <city>San Jose</city> |
---|
110 | <region>CA</region> |
---|
111 | <code>95110</code> |
---|
112 | <country>USA</country> |
---|
113 | </postal> |
---|
114 | <email>LMM@acm.org</email> |
---|
115 | <uri>http://larry.masinter.net/</uri> |
---|
116 | </address> |
---|
117 | </author> |
---|
118 | |
---|
119 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
120 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
121 | <address> |
---|
122 | <postal> |
---|
123 | <street>1 Microsoft Way</street> |
---|
124 | <city>Redmond</city> |
---|
125 | <region>WA</region> |
---|
126 | <code>98052</code> |
---|
127 | </postal> |
---|
128 | <email>paulle@microsoft.com</email> |
---|
129 | </address> |
---|
130 | </author> |
---|
131 | |
---|
132 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
133 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
134 | <address> |
---|
135 | <postal> |
---|
136 | <street>MIT Computer Science and Artificial Intelligence Laboratory</street> |
---|
137 | <street>The Stata Center, Building 32</street> |
---|
138 | <street>32 Vassar Street</street> |
---|
139 | <city>Cambridge</city> |
---|
140 | <region>MA</region> |
---|
141 | <code>02139</code> |
---|
142 | <country>USA</country> |
---|
143 | </postal> |
---|
144 | <email>timbl@w3.org</email> |
---|
145 | <uri>http://www.w3.org/People/Berners-Lee/</uri> |
---|
146 | </address> |
---|
147 | </author> |
---|
148 | |
---|
149 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
150 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
151 | <address> |
---|
152 | <postal> |
---|
153 | <street>W3C / ERCIM</street> |
---|
154 | <street>2004, rte des Lucioles</street> |
---|
155 | <city>Sophia-Antipolis</city> |
---|
156 | <region>AM</region> |
---|
157 | <code>06902</code> |
---|
158 | <country>France</country> |
---|
159 | </postal> |
---|
160 | <email>ylafon@w3.org</email> |
---|
161 | <uri>http://www.raubacapeu.net/people/yves/</uri> |
---|
162 | </address> |
---|
163 | </author> |
---|
164 | |
---|
165 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
166 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
167 | <address> |
---|
168 | <postal> |
---|
169 | <street>Hafenweg 16</street> |
---|
170 | <city>Muenster</city><region>NW</region><code>48155</code> |
---|
171 | <country>Germany</country> |
---|
172 | </postal> |
---|
173 | <phone>+49 251 2807760</phone> |
---|
174 | <facsimile>+49 251 2807761</facsimile> |
---|
175 | <email>julian.reschke@greenbytes.de</email> |
---|
176 | <uri>http://greenbytes.de/tech/webdav/</uri> |
---|
177 | </address> |
---|
178 | </author> |
---|
179 | |
---|
180 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
181 | <workgroup>HTTPbis Working Group</workgroup> |
---|
182 | |
---|
183 | <abstract> |
---|
184 | <t> |
---|
185 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
186 | protocol for distributed, collaborative, hypermedia information |
---|
187 | systems. HTTP has been in use by the World Wide Web global information |
---|
188 | initiative since 1990. This document is Part 7 of the seven-part specification |
---|
189 | that defines the protocol referred to as "HTTP/1.1" and, taken together, |
---|
190 | obsoletes RFC 2616. Part 7 defines HTTP Authentication. |
---|
191 | </t> |
---|
192 | </abstract> |
---|
193 | |
---|
194 | <note title="Editorial Note (To be removed by RFC Editor)"> |
---|
195 | <t> |
---|
196 | Discussion of this draft should take place on the HTTPBIS working group |
---|
197 | mailing list (ietf-http-wg@w3.org). The current issues list is |
---|
198 | at <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> |
---|
199 | and related documents (including fancy diffs) can be found at |
---|
200 | <eref target="http://tools.ietf.org/wg/httpbis/"/>. |
---|
201 | </t> |
---|
202 | <t> |
---|
203 | The changes in this draft are summarized in <xref target="changes.since.12"/>. |
---|
204 | </t> |
---|
205 | </note> |
---|
206 | </front> |
---|
207 | <middle> |
---|
208 | <section title="Introduction" anchor="introduction"> |
---|
209 | <t> |
---|
210 | This document defines HTTP/1.1 access control and authentication. It |
---|
211 | includes the relevant parts of <xref target="RFC2616" x:fmt="none">RFC 2616</xref> |
---|
212 | with only minor changes, plus the general framework for HTTP authentication, |
---|
213 | as previously defined in "HTTP Authentication: Basic and Digest Access |
---|
214 | Authentication" (<xref target="RFC2617"/>). |
---|
215 | </t> |
---|
216 | <t> |
---|
217 | HTTP provides several &OPTIONAL; challenge-response authentication |
---|
218 | mechanisms which can be used by a server to challenge a client request and |
---|
219 | by a client to provide authentication information. The "basic" and "digest" |
---|
220 | authentication schemes continue to be specified in |
---|
221 | <xref target="RFC2617" x:fmt="none">RFC 2617</xref>. |
---|
222 | </t> |
---|
223 | |
---|
224 | <section title="Requirements" anchor="intro.requirements"> |
---|
225 | <t> |
---|
226 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
227 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
228 | document are to be interpreted as described in <xref target="RFC2119"/>. |
---|
229 | </t> |
---|
230 | <t> |
---|
231 | An implementation is not compliant if it fails to satisfy one or more |
---|
232 | of the "MUST" or "REQUIRED" level requirements for the protocols it |
---|
233 | implements. An implementation that satisfies all the "MUST" or "REQUIRED" |
---|
234 | level and all the "SHOULD" level requirements for its protocols is said |
---|
235 | to be "unconditionally compliant"; one that satisfies all the "MUST" |
---|
236 | level requirements but not all the "SHOULD" level requirements for its |
---|
237 | protocols is said to be "conditionally compliant". |
---|
238 | </t> |
---|
239 | </section> |
---|
240 | |
---|
241 | <section title="Syntax Notation" anchor="notation"> |
---|
242 | <x:anchor-alias value="ALPHA"/> |
---|
243 | <x:anchor-alias value="CR"/> |
---|
244 | <x:anchor-alias value="DIGIT"/> |
---|
245 | <x:anchor-alias value="LF"/> |
---|
246 | <x:anchor-alias value="OCTET"/> |
---|
247 | <x:anchor-alias value="VCHAR"/> |
---|
248 | <x:anchor-alias value="SP"/> |
---|
249 | <x:anchor-alias value="WSP"/> |
---|
250 | <t> |
---|
251 | This specification uses the ABNF syntax defined in ¬ation; (which |
---|
252 | extends the syntax defined in <xref target="RFC5234"/> with a list rule). |
---|
253 | <xref target="collected.abnf"/> shows the collected ABNF, with the list |
---|
254 | rule expanded. |
---|
255 | </t> |
---|
256 | <t> |
---|
257 | The following core rules are included by |
---|
258 | reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>: |
---|
259 | ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), |
---|
260 | DIGIT (decimal 0-9), DQUOTE (double quote), |
---|
261 | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), |
---|
262 | OCTET (any 8-bit sequence of data), SP (space), |
---|
263 | VCHAR (any visible USASCII character), |
---|
264 | and WSP (whitespace). |
---|
265 | </t> |
---|
266 | |
---|
267 | <section title="Core Rules" anchor="core.rules"> |
---|
268 | <x:anchor-alias value="quoted-string"/> |
---|
269 | <x:anchor-alias value="token"/> |
---|
270 | <x:anchor-alias value="OWS"/> |
---|
271 | <t> |
---|
272 | The core rules below are defined in &basic-rules;: |
---|
273 | </t> |
---|
274 | <figure><artwork type="abnf2616"> |
---|
275 | <x:ref>quoted-string</x:ref> = <quoted-string, defined in &basic-rules;> |
---|
276 | <x:ref>token</x:ref> = <token, defined in &basic-rules;> |
---|
277 | <x:ref>OWS</x:ref> = <OWS, defined in &basic-rules;> |
---|
278 | </artwork></figure> |
---|
279 | </section> |
---|
280 | </section> |
---|
281 | </section> |
---|
282 | |
---|
283 | <section title="Access Authentication Framework" anchor="access.authentication.framework"> |
---|
284 | <x:anchor-alias value="auth-scheme"/> |
---|
285 | <x:anchor-alias value="auth-param"/> |
---|
286 | <x:anchor-alias value="challenge"/> |
---|
287 | <x:anchor-alias value="credentials"/> |
---|
288 | <t> |
---|
289 | HTTP provides a simple challenge-response authentication mechanism |
---|
290 | that can be used by a server to challenge a client request and by a |
---|
291 | client to provide authentication information. It uses an extensible, |
---|
292 | case-insensitive token to identify the authentication scheme, |
---|
293 | followed by a comma-separated list of attribute-value pairs which |
---|
294 | carry the parameters necessary for achieving authentication via that |
---|
295 | scheme. |
---|
296 | </t> |
---|
297 | <figure><artwork type="abnf2616"><iref item="auth-scheme" primary="true"/><iref item="auth-param" primary="true"/> |
---|
298 | auth-scheme = token |
---|
299 | auth-param = token "=" ( token / quoted-string ) |
---|
300 | </artwork></figure> |
---|
301 | <t> |
---|
302 | The 401 (Unauthorized) response message is used by an origin server |
---|
303 | to challenge the authorization of a user agent. This response &MUST; |
---|
304 | include a WWW-Authenticate header field containing at least one |
---|
305 | challenge applicable to the requested resource. The 407 (Proxy |
---|
306 | Authentication Required) response message is used by a proxy to |
---|
307 | challenge the authorization of a client and &MUST; include a Proxy-Authenticate |
---|
308 | header field containing at least one challenge |
---|
309 | applicable to the proxy for the requested resource. |
---|
310 | </t> |
---|
311 | <figure><artwork type="abnf2616"><iref item="challenge" primary="true"/> |
---|
312 | <x:ref>challenge</x:ref> = <x:ref>auth-scheme</x:ref> 1*<x:ref>SP</x:ref> 1#<x:ref>auth-param</x:ref> |
---|
313 | </artwork></figure> |
---|
314 | <x:note> |
---|
315 | <t> |
---|
316 | <x:h>Note:</x:h> User agents will need to take special care in parsing the WWW-Authenticate |
---|
317 | or Proxy-Authenticate header field value if it contains |
---|
318 | more than one challenge, or if more than one WWW-Authenticate header |
---|
319 | field is provided, since the contents of a challenge can itself |
---|
320 | contain a comma-separated list of authentication parameters. |
---|
321 | </t> |
---|
322 | </x:note> |
---|
323 | <x:note> |
---|
324 | <t> |
---|
325 | <x:h>Note:</x:h> Many browsers fail to parse challenges containing unknown |
---|
326 | schemes. A workaround for this problem is to list well-supported schemes |
---|
327 | (such as "basic") first. |
---|
328 | </t> |
---|
329 | </x:note> |
---|
330 | <t> |
---|
331 | The authentication parameter realm is defined for all authentication |
---|
332 | schemes: |
---|
333 | </t> |
---|
334 | <figure><artwork type="abnf2616"><iref item="realm" primary="true"/><iref item="realm-value" primary="true"/> |
---|
335 | realm = "realm" "=" realm-value |
---|
336 | realm-value = quoted-string |
---|
337 | </artwork></figure> |
---|
338 | <t> |
---|
339 | The realm directive (case-insensitive) is required for all |
---|
340 | authentication schemes that issue a challenge. The realm value |
---|
341 | (case-sensitive), in combination with the canonical root URI |
---|
342 | (the scheme and authority components of the effective request URI; see |
---|
343 | <xref target="Part1" x:fmt="of" x:rel="#effective.request.uri"/>) of the server being accessed, defines the protection space. |
---|
344 | These realms allow the protected resources on a server to be |
---|
345 | partitioned into a set of protection spaces, each with its own |
---|
346 | authentication scheme and/or authorization database. The realm value |
---|
347 | is a string, generally assigned by the origin server, which can have |
---|
348 | additional semantics specific to the authentication scheme. Note that |
---|
349 | there can be multiple challenges with the same auth-scheme but |
---|
350 | different realms. |
---|
351 | </t> |
---|
352 | <t> |
---|
353 | A user agent that wishes to authenticate itself with an origin |
---|
354 | server -- usually, but not necessarily, after receiving a 401 |
---|
355 | (Unauthorized) -- &MAY; do so by including an Authorization header field |
---|
356 | with the request. A client that wishes to authenticate itself with a |
---|
357 | proxy -- usually, but not necessarily, after receiving a 407 (Proxy |
---|
358 | Authentication Required) -- &MAY; do so by including a Proxy-Authorization |
---|
359 | header field with the request. Both the Authorization |
---|
360 | field value and the Proxy-Authorization field value consist of |
---|
361 | credentials containing the authentication information of the client |
---|
362 | for the realm of the resource being requested. The user agent &MUST; |
---|
363 | choose to use one of the challenges with the strongest auth-scheme it |
---|
364 | understands and request credentials from the user based upon that |
---|
365 | challenge. |
---|
366 | </t> |
---|
367 | <figure><artwork type="abnf2616"><iref item="credentials" primary="true"/> |
---|
368 | <x:ref>credentials</x:ref> = <x:ref>auth-scheme</x:ref> ( <x:ref>token</x:ref> |
---|
369 | / <x:ref>quoted-string</x:ref> |
---|
370 | / #<x:ref>auth-param</x:ref> ) |
---|
371 | </artwork></figure> |
---|
372 | <t> |
---|
373 | The protection space determines the domain over which credentials can |
---|
374 | be automatically applied. If a prior request has been authorized, the |
---|
375 | same credentials &MAY; be reused for all other requests within that |
---|
376 | protection space for a period of time determined by the |
---|
377 | authentication scheme, parameters, and/or user preference. Unless |
---|
378 | otherwise defined by the authentication scheme, a single protection |
---|
379 | space cannot extend outside the scope of its server. |
---|
380 | </t> |
---|
381 | <t> |
---|
382 | If the origin server does not wish to accept the credentials sent |
---|
383 | with a request, it &SHOULD; return a 401 (Unauthorized) response. The |
---|
384 | response &MUST; include a WWW-Authenticate header field containing at |
---|
385 | least one (possibly new) challenge applicable to the requested |
---|
386 | resource. If a proxy does not accept the credentials sent with a |
---|
387 | request, it &SHOULD; return a 407 (Proxy Authentication Required). The |
---|
388 | response &MUST; include a Proxy-Authenticate header field containing a |
---|
389 | (possibly new) challenge applicable to the proxy for the requested |
---|
390 | resource. |
---|
391 | </t> |
---|
392 | <t> |
---|
393 | The HTTP protocol does not restrict applications to this simple |
---|
394 | challenge-response mechanism for access authentication. Additional |
---|
395 | mechanisms &MAY; be used, such as encryption at the transport level or |
---|
396 | via message encapsulation, and with additional header fields |
---|
397 | specifying authentication information. However, these additional |
---|
398 | mechanisms are not defined by this specification. |
---|
399 | </t> |
---|
400 | <t> |
---|
401 | Proxies &MUST; be completely transparent regarding user agent |
---|
402 | authentication by origin servers. That is, they &MUST; forward the |
---|
403 | WWW-Authenticate and Authorization headers untouched, and follow the |
---|
404 | rules found in <xref target="header.authorization"/>. Both the Proxy-Authenticate and |
---|
405 | the Proxy-Authorization header fields are hop-by-hop headers (see |
---|
406 | &end-to-end.and-hop-by-hop;). |
---|
407 | </t> |
---|
408 | |
---|
409 | <section title="Authentication Scheme Registry" anchor="authentication.scheme.registry"> |
---|
410 | <t> |
---|
411 | The HTTP Authentication Scheme Registry defines the name space for the |
---|
412 | authentication schemes in challenges and credentials. |
---|
413 | </t> |
---|
414 | <t> |
---|
415 | Registrations &MUST; include the following fields: |
---|
416 | <list style="symbols"> |
---|
417 | <t>Authentication Scheme Name</t> |
---|
418 | <t>Pointer to specification text</t> |
---|
419 | </list> |
---|
420 | </t> |
---|
421 | <t> |
---|
422 | Values to be added to this name space are subject to IETF review |
---|
423 | (<xref target="RFC5226" x:fmt="," x:sec="4.1"/>). |
---|
424 | </t> |
---|
425 | <t> |
---|
426 | The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-authschemes"/>. |
---|
427 | </t> |
---|
428 | </section> |
---|
429 | |
---|
430 | </section> |
---|
431 | |
---|
432 | <section title="Status Code Definitions" anchor="status.code.definitions"> |
---|
433 | <section title="401 Unauthorized" anchor="status.401"> |
---|
434 | <iref primary="true" item="401 Unauthorized (status code)" x:for-anchor=""/> |
---|
435 | <iref primary="true" item="Status Codes" subitem="401 Unauthorized" x:for-anchor=""/> |
---|
436 | <t> |
---|
437 | The request requires user authentication. The response &MUST; include a |
---|
438 | WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge |
---|
439 | applicable to the target resource. The client &MAY; repeat the |
---|
440 | request with a suitable Authorization header field (<xref target="header.authorization"/>). If |
---|
441 | the request already included Authorization credentials, then the 401 |
---|
442 | response indicates that authorization has been refused for those |
---|
443 | credentials. If the 401 response contains the same challenge as the |
---|
444 | prior response, and the user agent has already attempted |
---|
445 | authentication at least once, then the user &SHOULD; be presented the |
---|
446 | representation that was given in the response, since that representation might |
---|
447 | include relevant diagnostic information. |
---|
448 | </t> |
---|
449 | </section> |
---|
450 | <section title="407 Proxy Authentication Required" anchor="status.407"> |
---|
451 | <iref primary="true" item="407 Proxy Authentication Required (status code)" x:for-anchor=""/> |
---|
452 | <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required" x:for-anchor=""/> |
---|
453 | <t> |
---|
454 | This code is similar to 401 (Unauthorized), but indicates that the |
---|
455 | client ought to first authenticate itself with the proxy. The proxy &MUST; |
---|
456 | return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a |
---|
457 | challenge applicable to the proxy for the target resource. The |
---|
458 | client &MAY; repeat the request with a suitable Proxy-Authorization |
---|
459 | header field (<xref target="header.proxy-authorization"/>). |
---|
460 | </t> |
---|
461 | </section> |
---|
462 | </section> |
---|
463 | |
---|
464 | <section title="Header Field Definitions" anchor="header.fields"> |
---|
465 | <t> |
---|
466 | This section defines the syntax and semantics of HTTP/1.1 header fields |
---|
467 | related to authentication. |
---|
468 | </t> |
---|
469 | |
---|
470 | <section title="Authorization" anchor="header.authorization"> |
---|
471 | <iref primary="true" item="Authorization header" x:for-anchor=""/> |
---|
472 | <iref primary="true" item="Headers" subitem="Authorization" x:for-anchor=""/> |
---|
473 | <x:anchor-alias value="Authorization"/> |
---|
474 | <x:anchor-alias value="Authorization-v"/> |
---|
475 | <t> |
---|
476 | The "Authorization" request-header field allows a user agent to authenticate |
---|
477 | itself with a server -- usually, but not necessarily, after receiving a 401 |
---|
478 | (Unauthorized) response. Its value consists of credentials containing |
---|
479 | information of the user agent for the realm of the resource being |
---|
480 | requested. |
---|
481 | </t> |
---|
482 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/><iref primary="true" item="Grammar" subitem="Authorization-v"/> |
---|
483 | <x:ref>Authorization</x:ref> = "Authorization" ":" <x:ref>OWS</x:ref> <x:ref>Authorization-v</x:ref> |
---|
484 | <x:ref>Authorization-v</x:ref> = <x:ref>credentials</x:ref> |
---|
485 | </artwork></figure> |
---|
486 | <t> |
---|
487 | If a request is |
---|
488 | authenticated and a realm specified, the same credentials &SHOULD; |
---|
489 | be valid for all other requests within this realm (assuming that |
---|
490 | the authentication scheme itself does not require otherwise, such |
---|
491 | as credentials that vary according to a challenge value or using |
---|
492 | synchronized clocks). |
---|
493 | </t> |
---|
494 | <t> |
---|
495 | When a shared cache (see &shared-and-non-shared-caches;) receives a request |
---|
496 | containing an Authorization field, it &MUST-NOT; return the |
---|
497 | corresponding response as a reply to any other request, unless one |
---|
498 | of the following specific exceptions holds: |
---|
499 | </t> |
---|
500 | <t> |
---|
501 | <list style="numbers"> |
---|
502 | <t>If the response includes the "s-maxage" cache-control |
---|
503 | directive, the cache &MAY; use that response in replying to a |
---|
504 | subsequent request. But (if the specified maximum age has |
---|
505 | passed) a proxy cache &MUST; first revalidate it with the origin |
---|
506 | server, using the request-header fields from the new request to allow |
---|
507 | the origin server to authenticate the new request. (This is the |
---|
508 | defined behavior for s-maxage.) If the response includes "s-maxage=0", |
---|
509 | the proxy &MUST; always revalidate it before re-using |
---|
510 | it.</t> |
---|
511 | |
---|
512 | <t>If the response includes the "must-revalidate" cache-control |
---|
513 | directive, the cache &MAY; use that response in replying to a |
---|
514 | subsequent request. But if the response is stale, all caches |
---|
515 | &MUST; first revalidate it with the origin server, using the |
---|
516 | request-header fields from the new request to allow the origin server |
---|
517 | to authenticate the new request.</t> |
---|
518 | |
---|
519 | <t>If the response includes the "public" cache-control directive, |
---|
520 | it &MAY; be returned in reply to any subsequent request.</t> |
---|
521 | </list> |
---|
522 | </t> |
---|
523 | </section> |
---|
524 | |
---|
525 | <section title="Proxy-Authenticate" anchor="header.proxy-authenticate"> |
---|
526 | <iref primary="true" item="Proxy-Authenticate header" x:for-anchor=""/> |
---|
527 | <iref primary="true" item="Headers" subitem="Proxy-Authenticate" x:for-anchor=""/> |
---|
528 | <x:anchor-alias value="Proxy-Authenticate"/> |
---|
529 | <x:anchor-alias value="Proxy-Authenticate-v"/> |
---|
530 | <t> |
---|
531 | The "Proxy-Authenticate" response-header field consists of a challenge that |
---|
532 | indicates the authentication scheme and parameters applicable to the proxy |
---|
533 | for this effective request URI (&effective-request-uri;). It &MUST; be included as part |
---|
534 | of a 407 (Proxy Authentication Required) response. |
---|
535 | </t> |
---|
536 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/><iref primary="true" item="Grammar" subitem="Proxy-Authenticate-v"/> |
---|
537 | <x:ref>Proxy-Authenticate</x:ref> = "Proxy-Authenticate" ":" <x:ref>OWS</x:ref> |
---|
538 | <x:ref>Proxy-Authenticate-v</x:ref> |
---|
539 | <x:ref>Proxy-Authenticate-v</x:ref> = 1#<x:ref>challenge</x:ref> |
---|
540 | </artwork></figure> |
---|
541 | <t> |
---|
542 | Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to |
---|
543 | the current connection and &SHOULD-NOT; be passed on to downstream |
---|
544 | clients. However, an intermediate proxy might need to obtain its own |
---|
545 | credentials by requesting them from the downstream client, which in |
---|
546 | some circumstances will appear as if the proxy is forwarding the |
---|
547 | Proxy-Authenticate header field. |
---|
548 | </t> |
---|
549 | </section> |
---|
550 | |
---|
551 | <section title="Proxy-Authorization" anchor="header.proxy-authorization"> |
---|
552 | <iref primary="true" item="Proxy-Authorization header" x:for-anchor=""/> |
---|
553 | <iref primary="true" item="Headers" subitem="Proxy-Authorization" x:for-anchor=""/> |
---|
554 | <x:anchor-alias value="Proxy-Authorization"/> |
---|
555 | <x:anchor-alias value="Proxy-Authorization-v"/> |
---|
556 | <t> |
---|
557 | The "Proxy-Authorization" request-header field allows the client to |
---|
558 | identify itself (or its user) to a proxy which requires |
---|
559 | authentication. Its value consists of |
---|
560 | credentials containing the authentication information of the user |
---|
561 | agent for the proxy and/or realm of the resource being requested. |
---|
562 | </t> |
---|
563 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/><iref primary="true" item="Grammar" subitem="Proxy-Authorization-v"/> |
---|
564 | <x:ref>Proxy-Authorization</x:ref> = "Proxy-Authorization" ":" <x:ref>OWS</x:ref> |
---|
565 | <x:ref>Proxy-Authorization-v</x:ref> |
---|
566 | <x:ref>Proxy-Authorization-v</x:ref> = <x:ref>credentials</x:ref> |
---|
567 | </artwork></figure> |
---|
568 | <t> |
---|
569 | Unlike Authorization, the Proxy-Authorization header field applies only to |
---|
570 | the next outbound proxy that demanded authentication using the Proxy-Authenticate |
---|
571 | field. When multiple proxies are used in a chain, the |
---|
572 | Proxy-Authorization header field is consumed by the first outbound |
---|
573 | proxy that was expecting to receive credentials. A proxy &MAY; relay |
---|
574 | the credentials from the client request to the next proxy if that is |
---|
575 | the mechanism by which the proxies cooperatively authenticate a given |
---|
576 | request. |
---|
577 | </t> |
---|
578 | </section> |
---|
579 | |
---|
580 | <section title="WWW-Authenticate" anchor="header.www-authenticate"> |
---|
581 | <iref primary="true" item="WWW-Authenticate header" x:for-anchor=""/> |
---|
582 | <iref primary="true" item="Headers" subitem="WWW-Authenticate" x:for-anchor=""/> |
---|
583 | <x:anchor-alias value="WWW-Authenticate"/> |
---|
584 | <x:anchor-alias value="WWW-Authenticate-v"/> |
---|
585 | <t> |
---|
586 | The "WWW-Authenticate" response-header field consists of at least one |
---|
587 | challenge that indicates the authentication scheme(s) and parameters |
---|
588 | applicable to the effective request URI (&effective-request-uri;). It &MUST; be included in 401 |
---|
589 | (Unauthorized) response messages. |
---|
590 | </t> |
---|
591 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/><iref primary="true" item="Grammar" subitem="WWW-Authenticate-v"/> |
---|
592 | <x:ref>WWW-Authenticate</x:ref> = "WWW-Authenticate" ":" <x:ref>OWS</x:ref> <x:ref>WWW-Authenticate-v</x:ref> |
---|
593 | <x:ref>WWW-Authenticate-v</x:ref> = 1#<x:ref>challenge</x:ref> |
---|
594 | </artwork></figure> |
---|
595 | <t> |
---|
596 | User agents are advised to take special care in parsing the WWW-Authenticate |
---|
597 | field value as it might contain more than one challenge, |
---|
598 | or if more than one WWW-Authenticate header field is provided, the |
---|
599 | contents of a challenge itself can contain a comma-separated list of |
---|
600 | authentication parameters. |
---|
601 | </t> |
---|
602 | </section> |
---|
603 | |
---|
604 | </section> |
---|
605 | |
---|
606 | <section title="IANA Considerations" anchor="IANA.considerations"> |
---|
607 | |
---|
608 | <section title="Authenticaton Scheme Registry" anchor="authentication.scheme.registration"> |
---|
609 | <t> |
---|
610 | The registration procedure for HTTP Authentication Schemes is defined by |
---|
611 | <xref target="authentication.scheme.registry"/> of this document. |
---|
612 | </t> |
---|
613 | <t> |
---|
614 | The HTTP Method Authentication Scheme shall be created at <eref target="http://www.iana.org/assignments/http-authschemes"/>. |
---|
615 | </t> |
---|
616 | </section> |
---|
617 | |
---|
618 | <section title="Status Code Registration" anchor="status.code.registration"> |
---|
619 | <t> |
---|
620 | The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/> |
---|
621 | shall be updated with the registrations below: |
---|
622 | </t> |
---|
623 | <?BEGININC p7-auth.iana-status-codes ?> |
---|
624 | <!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually--> |
---|
625 | <texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table"> |
---|
626 | <ttcol>Value</ttcol> |
---|
627 | <ttcol>Description</ttcol> |
---|
628 | <ttcol>Reference</ttcol> |
---|
629 | <c>401</c> |
---|
630 | <c>Unauthorized</c> |
---|
631 | <c> |
---|
632 | <xref target="status.401"/> |
---|
633 | </c> |
---|
634 | <c>407</c> |
---|
635 | <c>Proxy Authentication Required</c> |
---|
636 | <c> |
---|
637 | <xref target="status.407"/> |
---|
638 | </c> |
---|
639 | </texttable> |
---|
640 | <!--(END)--> |
---|
641 | <?ENDINC p7-auth.iana-status-codes ?> |
---|
642 | </section> |
---|
643 | |
---|
644 | <section title="Header Field Registration" anchor="header.field.registration"> |
---|
645 | <t> |
---|
646 | The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated |
---|
647 | with the permanent registrations below (see <xref target="RFC3864"/>): |
---|
648 | </t> |
---|
649 | <?BEGININC p7-auth.iana-headers ?> |
---|
650 | <!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually--> |
---|
651 | <texttable align="left" suppress-title="true" anchor="iana.header.registration.table"> |
---|
652 | <ttcol>Header Field Name</ttcol> |
---|
653 | <ttcol>Protocol</ttcol> |
---|
654 | <ttcol>Status</ttcol> |
---|
655 | <ttcol>Reference</ttcol> |
---|
656 | |
---|
657 | <c>Authorization</c> |
---|
658 | <c>http</c> |
---|
659 | <c>standard</c> |
---|
660 | <c> |
---|
661 | <xref target="header.authorization"/> |
---|
662 | </c> |
---|
663 | <c>Proxy-Authenticate</c> |
---|
664 | <c>http</c> |
---|
665 | <c>standard</c> |
---|
666 | <c> |
---|
667 | <xref target="header.proxy-authenticate"/> |
---|
668 | </c> |
---|
669 | <c>Proxy-Authorization</c> |
---|
670 | <c>http</c> |
---|
671 | <c>standard</c> |
---|
672 | <c> |
---|
673 | <xref target="header.proxy-authorization"/> |
---|
674 | </c> |
---|
675 | <c>WWW-Authenticate</c> |
---|
676 | <c>http</c> |
---|
677 | <c>standard</c> |
---|
678 | <c> |
---|
679 | <xref target="header.www-authenticate"/> |
---|
680 | </c> |
---|
681 | </texttable> |
---|
682 | <!--(END)--> |
---|
683 | <?ENDINC p7-auth.iana-headers ?> |
---|
684 | <t> |
---|
685 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". |
---|
686 | </t> |
---|
687 | </section> |
---|
688 | </section> |
---|
689 | |
---|
690 | <section title="Security Considerations" anchor="security.considerations"> |
---|
691 | <t> |
---|
692 | This section is meant to inform application developers, information |
---|
693 | providers, and users of the security limitations in HTTP/1.1 as |
---|
694 | described by this document. The discussion does not include |
---|
695 | definitive solutions to the problems revealed, though it does make |
---|
696 | some suggestions for reducing security risks. |
---|
697 | </t> |
---|
698 | |
---|
699 | <section title="Authentication Credentials and Idle Clients" anchor="auth.credentials.and.idle.clients"> |
---|
700 | <t> |
---|
701 | Existing HTTP clients and user agents typically retain authentication |
---|
702 | information indefinitely. HTTP/1.1 does not provide a method for a |
---|
703 | server to direct clients to discard these cached credentials. This is |
---|
704 | a significant defect that requires further extensions to HTTP. |
---|
705 | Circumstances under which credential caching can interfere with the |
---|
706 | application's security model include but are not limited to: |
---|
707 | <list style="symbols"> |
---|
708 | <t>Clients which have been idle for an extended period following |
---|
709 | which the server might wish to cause the client to reprompt the |
---|
710 | user for credentials.</t> |
---|
711 | |
---|
712 | <t>Applications which include a session termination indication |
---|
713 | (such as a "logout" or "commit" button on a page) after which |
---|
714 | the server side of the application "knows" that there is no |
---|
715 | further reason for the client to retain the credentials.</t> |
---|
716 | </list> |
---|
717 | </t> |
---|
718 | <t> |
---|
719 | This is currently under separate study. There are a number of work-arounds |
---|
720 | to parts of this problem, and we encourage the use of |
---|
721 | password protection in screen savers, idle time-outs, and other |
---|
722 | methods which mitigate the security problems inherent in this |
---|
723 | problem. In particular, user agents which cache credentials are |
---|
724 | encouraged to provide a readily accessible mechanism for discarding |
---|
725 | cached credentials under user control. |
---|
726 | </t> |
---|
727 | </section> |
---|
728 | </section> |
---|
729 | |
---|
730 | <section title="Acknowledgments" anchor="ack"> |
---|
731 | <t> |
---|
732 | This specification takes over the definition of the HTTP Authentication |
---|
733 | Framework, previously defined in <xref target="RFC2616" x:fmt="none">RFC 2617</xref>. We thank to John Franks, |
---|
734 | Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, |
---|
735 | Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work |
---|
736 | on that specification. |
---|
737 | </t> |
---|
738 | <t> |
---|
739 | <cref anchor="acks">HTTPbis acknowledgements.</cref> |
---|
740 | </t> |
---|
741 | </section> |
---|
742 | </middle> |
---|
743 | |
---|
744 | <back> |
---|
745 | |
---|
746 | <references title="Normative References"> |
---|
747 | |
---|
748 | <reference anchor="Part1"> |
---|
749 | <front> |
---|
750 | <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title> |
---|
751 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
752 | <organization abbrev="Day Software">Day Software</organization> |
---|
753 | <address><email>fielding@gbiv.com</email></address> |
---|
754 | </author> |
---|
755 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
756 | <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization> |
---|
757 | <address><email>jg@freedesktop.org</email></address> |
---|
758 | </author> |
---|
759 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
760 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
761 | <address><email>JeffMogul@acm.org</email></address> |
---|
762 | </author> |
---|
763 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
764 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
765 | <address><email>henrikn@microsoft.com</email></address> |
---|
766 | </author> |
---|
767 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
768 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
769 | <address><email>LMM@acm.org</email></address> |
---|
770 | </author> |
---|
771 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
772 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
773 | <address><email>paulle@microsoft.com</email></address> |
---|
774 | </author> |
---|
775 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
776 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
777 | <address><email>timbl@w3.org</email></address> |
---|
778 | </author> |
---|
779 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
780 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
781 | <address><email>ylafon@w3.org</email></address> |
---|
782 | </author> |
---|
783 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
784 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
785 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
786 | </author> |
---|
787 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
788 | </front> |
---|
789 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/> |
---|
790 | <x:source href="p1-messaging.xml" basename="p1-messaging"/> |
---|
791 | </reference> |
---|
792 | |
---|
793 | <reference anchor="Part6"> |
---|
794 | <front> |
---|
795 | <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title> |
---|
796 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
797 | <organization abbrev="Day Software">Day Software</organization> |
---|
798 | <address><email>fielding@gbiv.com</email></address> |
---|
799 | </author> |
---|
800 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
801 | <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization> |
---|
802 | <address><email>jg@freedesktop.org</email></address> |
---|
803 | </author> |
---|
804 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
805 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
806 | <address><email>JeffMogul@acm.org</email></address> |
---|
807 | </author> |
---|
808 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
809 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
810 | <address><email>henrikn@microsoft.com</email></address> |
---|
811 | </author> |
---|
812 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
813 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
814 | <address><email>LMM@acm.org</email></address> |
---|
815 | </author> |
---|
816 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
817 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
818 | <address><email>paulle@microsoft.com</email></address> |
---|
819 | </author> |
---|
820 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
821 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
822 | <address><email>timbl@w3.org</email></address> |
---|
823 | </author> |
---|
824 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
825 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
826 | <address><email>ylafon@w3.org</email></address> |
---|
827 | </author> |
---|
828 | <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor"> |
---|
829 | <address><email>mnot@mnot.net</email></address> |
---|
830 | </author> |
---|
831 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
832 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
833 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
834 | </author> |
---|
835 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
836 | </front> |
---|
837 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/> |
---|
838 | <x:source href="p6-cache.xml" basename="p6-cache"/> |
---|
839 | </reference> |
---|
840 | |
---|
841 | <reference anchor="RFC2119"> |
---|
842 | <front> |
---|
843 | <title>Key words for use in RFCs to Indicate Requirement Levels</title> |
---|
844 | <author initials="S." surname="Bradner" fullname="Scott Bradner"> |
---|
845 | <organization>Harvard University</organization> |
---|
846 | <address><email>sob@harvard.edu</email></address> |
---|
847 | </author> |
---|
848 | <date month="March" year="1997"/> |
---|
849 | </front> |
---|
850 | <seriesInfo name="BCP" value="14"/> |
---|
851 | <seriesInfo name="RFC" value="2119"/> |
---|
852 | </reference> |
---|
853 | |
---|
854 | <reference anchor="RFC5234"> |
---|
855 | <front> |
---|
856 | <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title> |
---|
857 | <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"> |
---|
858 | <organization>Brandenburg InternetWorking</organization> |
---|
859 | <address> |
---|
860 | <email>dcrocker@bbiw.net</email> |
---|
861 | </address> |
---|
862 | </author> |
---|
863 | <author initials="P." surname="Overell" fullname="Paul Overell"> |
---|
864 | <organization>THUS plc.</organization> |
---|
865 | <address> |
---|
866 | <email>paul.overell@thus.net</email> |
---|
867 | </address> |
---|
868 | </author> |
---|
869 | <date month="January" year="2008"/> |
---|
870 | </front> |
---|
871 | <seriesInfo name="STD" value="68"/> |
---|
872 | <seriesInfo name="RFC" value="5234"/> |
---|
873 | </reference> |
---|
874 | |
---|
875 | </references> |
---|
876 | |
---|
877 | <references title="Informative References"> |
---|
878 | |
---|
879 | <reference anchor="RFC2616"> |
---|
880 | <front> |
---|
881 | <title>Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
882 | <author initials="R." surname="Fielding" fullname="R. Fielding"> |
---|
883 | <organization>University of California, Irvine</organization> |
---|
884 | <address><email>fielding@ics.uci.edu</email></address> |
---|
885 | </author> |
---|
886 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
887 | <organization>W3C</organization> |
---|
888 | <address><email>jg@w3.org</email></address> |
---|
889 | </author> |
---|
890 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
891 | <organization>Compaq Computer Corporation</organization> |
---|
892 | <address><email>mogul@wrl.dec.com</email></address> |
---|
893 | </author> |
---|
894 | <author initials="H." surname="Frystyk" fullname="H. Frystyk"> |
---|
895 | <organization>MIT Laboratory for Computer Science</organization> |
---|
896 | <address><email>frystyk@w3.org</email></address> |
---|
897 | </author> |
---|
898 | <author initials="L." surname="Masinter" fullname="L. Masinter"> |
---|
899 | <organization>Xerox Corporation</organization> |
---|
900 | <address><email>masinter@parc.xerox.com</email></address> |
---|
901 | </author> |
---|
902 | <author initials="P." surname="Leach" fullname="P. Leach"> |
---|
903 | <organization>Microsoft Corporation</organization> |
---|
904 | <address><email>paulle@microsoft.com</email></address> |
---|
905 | </author> |
---|
906 | <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"> |
---|
907 | <organization>W3C</organization> |
---|
908 | <address><email>timbl@w3.org</email></address> |
---|
909 | </author> |
---|
910 | <date month="June" year="1999"/> |
---|
911 | </front> |
---|
912 | <seriesInfo name="RFC" value="2616"/> |
---|
913 | </reference> |
---|
914 | |
---|
915 | <reference anchor="RFC2617"> |
---|
916 | <front> |
---|
917 | <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title> |
---|
918 | <author initials="J." surname="Franks" fullname="John Franks"> |
---|
919 | <organization>Northwestern University, Department of Mathematics</organization> |
---|
920 | <address><email>john@math.nwu.edu</email></address> |
---|
921 | </author> |
---|
922 | <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker"> |
---|
923 | <organization>Verisign Inc.</organization> |
---|
924 | <address><email>pbaker@verisign.com</email></address> |
---|
925 | </author> |
---|
926 | <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler"> |
---|
927 | <organization>AbiSource, Inc.</organization> |
---|
928 | <address><email>jeff@AbiSource.com</email></address> |
---|
929 | </author> |
---|
930 | <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence"> |
---|
931 | <organization>Agranat Systems, Inc.</organization> |
---|
932 | <address><email>lawrence@agranat.com</email></address> |
---|
933 | </author> |
---|
934 | <author initials="P.J." surname="Leach" fullname="Paul J. Leach"> |
---|
935 | <organization>Microsoft Corporation</organization> |
---|
936 | <address><email>paulle@microsoft.com</email></address> |
---|
937 | </author> |
---|
938 | <author initials="A." surname="Luotonen" fullname="Ari Luotonen"> |
---|
939 | <organization>Netscape Communications Corporation</organization> |
---|
940 | </author> |
---|
941 | <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart"> |
---|
942 | <organization>Open Market, Inc.</organization> |
---|
943 | <address><email>stewart@OpenMarket.com</email></address> |
---|
944 | </author> |
---|
945 | <date month="June" year="1999"/> |
---|
946 | </front> |
---|
947 | <seriesInfo name="RFC" value="2617"/> |
---|
948 | </reference> |
---|
949 | |
---|
950 | <reference anchor='RFC3864'> |
---|
951 | <front> |
---|
952 | <title>Registration Procedures for Message Header Fields</title> |
---|
953 | <author initials='G.' surname='Klyne' fullname='G. Klyne'> |
---|
954 | <organization>Nine by Nine</organization> |
---|
955 | <address><email>GK-IETF@ninebynine.org</email></address> |
---|
956 | </author> |
---|
957 | <author initials='M.' surname='Nottingham' fullname='M. Nottingham'> |
---|
958 | <organization>BEA Systems</organization> |
---|
959 | <address><email>mnot@pobox.com</email></address> |
---|
960 | </author> |
---|
961 | <author initials='J.' surname='Mogul' fullname='J. Mogul'> |
---|
962 | <organization>HP Labs</organization> |
---|
963 | <address><email>JeffMogul@acm.org</email></address> |
---|
964 | </author> |
---|
965 | <date year='2004' month='September' /> |
---|
966 | </front> |
---|
967 | <seriesInfo name='BCP' value='90' /> |
---|
968 | <seriesInfo name='RFC' value='3864' /> |
---|
969 | </reference> |
---|
970 | |
---|
971 | <reference anchor='RFC5226'> |
---|
972 | <front> |
---|
973 | <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> |
---|
974 | <author initials='T.' surname='Narten' fullname='T. Narten'> |
---|
975 | <organization>IBM</organization> |
---|
976 | <address><email>narten@us.ibm.com</email></address> |
---|
977 | </author> |
---|
978 | <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'> |
---|
979 | <organization>Google</organization> |
---|
980 | <address><email>Harald@Alvestrand.no</email></address> |
---|
981 | </author> |
---|
982 | <date year='2008' month='May' /> |
---|
983 | </front> |
---|
984 | <seriesInfo name='BCP' value='26' /> |
---|
985 | <seriesInfo name='RFC' value='5226' /> |
---|
986 | </reference> |
---|
987 | |
---|
988 | </references> |
---|
989 | |
---|
990 | <!-- re-add this once we have changes |
---|
991 | <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> |
---|
992 | </section> |
---|
993 | --> |
---|
994 | |
---|
995 | <?BEGININC p7-auth.abnf-appendix ?> |
---|
996 | <section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf"> |
---|
997 | <figure> |
---|
998 | <artwork type="abnf" name="p7-auth.parsed-abnf"> |
---|
999 | <x:ref>Authorization</x:ref> = "Authorization:" OWS Authorization-v |
---|
1000 | <x:ref>Authorization-v</x:ref> = credentials |
---|
1001 | |
---|
1002 | <x:ref>OWS</x:ref> = <OWS, defined in [Part1], Section 1.2.2> |
---|
1003 | |
---|
1004 | <x:ref>Proxy-Authenticate</x:ref> = "Proxy-Authenticate:" OWS Proxy-Authenticate-v |
---|
1005 | <x:ref>Proxy-Authenticate-v</x:ref> = *( "," OWS ) challenge *( OWS "," [ OWS |
---|
1006 | challenge ] ) |
---|
1007 | <x:ref>Proxy-Authorization</x:ref> = "Proxy-Authorization:" OWS |
---|
1008 | Proxy-Authorization-v |
---|
1009 | <x:ref>Proxy-Authorization-v</x:ref> = credentials |
---|
1010 | |
---|
1011 | <x:ref>WWW-Authenticate</x:ref> = "WWW-Authenticate:" OWS WWW-Authenticate-v |
---|
1012 | <x:ref>WWW-Authenticate-v</x:ref> = *( "," OWS ) challenge *( OWS "," [ OWS |
---|
1013 | challenge ] ) |
---|
1014 | |
---|
1015 | <x:ref>auth-param</x:ref> = token "=" ( token / quoted-string ) |
---|
1016 | <x:ref>auth-scheme</x:ref> = token |
---|
1017 | |
---|
1018 | <x:ref>challenge</x:ref> = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS |
---|
1019 | auth-param ] ) |
---|
1020 | <x:ref>credentials</x:ref> = auth-scheme ( token / quoted-string / [ ( "," / |
---|
1021 | auth-param ) *( OWS "," [ OWS auth-param ] ) ] ) |
---|
1022 | |
---|
1023 | <x:ref>quoted-string</x:ref> = <quoted-string, defined in [Part1], Section 1.2.2> |
---|
1024 | |
---|
1025 | realm = "realm=" realm-value |
---|
1026 | realm-value = quoted-string |
---|
1027 | |
---|
1028 | <x:ref>token</x:ref> = <token, defined in [Part1], Section 1.2.2> |
---|
1029 | </artwork> |
---|
1030 | </figure> |
---|
1031 | <figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"> |
---|
1032 | ; Authorization defined but not used |
---|
1033 | ; Proxy-Authenticate defined but not used |
---|
1034 | ; Proxy-Authorization defined but not used |
---|
1035 | ; WWW-Authenticate defined but not used |
---|
1036 | ; realm defined but not used |
---|
1037 | </artwork></figure></section> |
---|
1038 | <?ENDINC p7-auth.abnf-appendix ?> |
---|
1039 | |
---|
1040 | <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> |
---|
1041 | |
---|
1042 | <section title="Since RFC 2616"> |
---|
1043 | <t> |
---|
1044 | Extracted relevant partitions from <xref target="RFC2616"/>. |
---|
1045 | </t> |
---|
1046 | </section> |
---|
1047 | |
---|
1048 | <section title="Since draft-ietf-httpbis-p7-auth-00"> |
---|
1049 | <t> |
---|
1050 | Closed issues: |
---|
1051 | <list style="symbols"> |
---|
1052 | <t> |
---|
1053 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>: |
---|
1054 | "Normative and Informative references" |
---|
1055 | </t> |
---|
1056 | </list> |
---|
1057 | </t> |
---|
1058 | </section> |
---|
1059 | |
---|
1060 | <section title="Since draft-ietf-httpbis-p7-auth-01"> |
---|
1061 | <t> |
---|
1062 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
1063 | <list style="symbols"> |
---|
1064 | <t> |
---|
1065 | Explicitly import BNF rules for "challenge" and "credentials" from RFC2617. |
---|
1066 | </t> |
---|
1067 | <t> |
---|
1068 | Add explicit references to BNF syntax and rules imported from other parts of the specification. |
---|
1069 | </t> |
---|
1070 | </list> |
---|
1071 | </t> |
---|
1072 | </section> |
---|
1073 | |
---|
1074 | <section title="Since draft-ietf-httpbis-p7-auth-02" anchor="changes.since.02"> |
---|
1075 | <t> |
---|
1076 | Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>): |
---|
1077 | <list style="symbols"> |
---|
1078 | <t> |
---|
1079 | Reference RFC 3984, and update header field registrations for header fields defined |
---|
1080 | in this document. |
---|
1081 | </t> |
---|
1082 | </list> |
---|
1083 | </t> |
---|
1084 | </section> |
---|
1085 | |
---|
1086 | <section title="Since draft-ietf-httpbis-p7-auth-03" anchor="changes.since.03"> |
---|
1087 | <t> |
---|
1088 | </t> |
---|
1089 | </section> |
---|
1090 | |
---|
1091 | <section title="Since draft-ietf-httpbis-p7-auth-04" anchor="changes.since.04"> |
---|
1092 | <t> |
---|
1093 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
1094 | <list style="symbols"> |
---|
1095 | <t> |
---|
1096 | Use "/" instead of "|" for alternatives. |
---|
1097 | </t> |
---|
1098 | <t> |
---|
1099 | Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
---|
1100 | whitespace ("OWS") and required whitespace ("RWS"). |
---|
1101 | </t> |
---|
1102 | <t> |
---|
1103 | Rewrite ABNFs to spell out whitespace rules, factor out |
---|
1104 | header field value format definitions. |
---|
1105 | </t> |
---|
1106 | </list> |
---|
1107 | </t> |
---|
1108 | </section> |
---|
1109 | |
---|
1110 | <section title="Since draft-ietf-httpbis-p7-auth-05" anchor="changes.since.05"> |
---|
1111 | <t> |
---|
1112 | Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
1113 | <list style="symbols"> |
---|
1114 | <t> |
---|
1115 | Add appendix containing collected and expanded ABNF, reorganize ABNF introduction. |
---|
1116 | </t> |
---|
1117 | </list> |
---|
1118 | </t> |
---|
1119 | </section> |
---|
1120 | |
---|
1121 | <section title="Since draft-ietf-httpbis-p7-auth-06" anchor="changes.since.06"> |
---|
1122 | <t> |
---|
1123 | None. |
---|
1124 | </t> |
---|
1125 | </section> |
---|
1126 | |
---|
1127 | <section title="Since draft-ietf-httpbis-p7-auth-07" anchor="changes.since.07"> |
---|
1128 | <t> |
---|
1129 | Closed issues: |
---|
1130 | <list style="symbols"> |
---|
1131 | <t> |
---|
1132 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/198"/>: |
---|
1133 | "move IANA registrations for optional status codes" |
---|
1134 | </t> |
---|
1135 | </list> |
---|
1136 | </t> |
---|
1137 | </section> |
---|
1138 | |
---|
1139 | <section title="Since draft-ietf-httpbis-p7-auth-08" anchor="changes.since.08"> |
---|
1140 | <t> |
---|
1141 | No significant changes. |
---|
1142 | </t> |
---|
1143 | </section> |
---|
1144 | |
---|
1145 | <section title="Since draft-ietf-httpbis-p7-auth-09" anchor="changes.since.09"> |
---|
1146 | <t> |
---|
1147 | Partly resolved issues: |
---|
1148 | <list style="symbols"> |
---|
1149 | <t> |
---|
1150 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: |
---|
1151 | "Term for the requested resource's URI" |
---|
1152 | </t> |
---|
1153 | </list> |
---|
1154 | </t> |
---|
1155 | </section> |
---|
1156 | |
---|
1157 | <section title="Since draft-ietf-httpbis-p7-auth-10" anchor="changes.since.10"> |
---|
1158 | <t> |
---|
1159 | None yet. |
---|
1160 | </t> |
---|
1161 | </section> |
---|
1162 | |
---|
1163 | <section title="Since draft-ietf-httpbis-p7-auth-11" anchor="changes.since.11"> |
---|
1164 | <t> |
---|
1165 | Closed issues: |
---|
1166 | <list style="symbols"> |
---|
1167 | <t> |
---|
1168 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/130"/>: |
---|
1169 | "introduction to part 7 is work-in-progress" |
---|
1170 | </t> |
---|
1171 | <t> |
---|
1172 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/195"/>: |
---|
1173 | "auth-param syntax" |
---|
1174 | </t> |
---|
1175 | <t> |
---|
1176 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/237"/>: |
---|
1177 | "absorbing the auth framework from 2617" |
---|
1178 | </t> |
---|
1179 | </list> |
---|
1180 | </t> |
---|
1181 | <t> |
---|
1182 | Partly resolved issues: |
---|
1183 | <list style="symbols"> |
---|
1184 | <t> |
---|
1185 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/141"/>: |
---|
1186 | "should we have an auth scheme registry" |
---|
1187 | </t> |
---|
1188 | </list> |
---|
1189 | </t> |
---|
1190 | </section> |
---|
1191 | |
---|
1192 | <section title="Since draft-ietf-httpbis-p7-auth-12" anchor="changes.since.12"> |
---|
1193 | <t> |
---|
1194 | None yet. |
---|
1195 | </t> |
---|
1196 | </section> |
---|
1197 | |
---|
1198 | </section> |
---|
1199 | |
---|
1200 | </back> |
---|
1201 | </rfc> |
---|