source: draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.html @ 221

Last change on this file since 221 was 220, checked in by paul.hoffman@…, 15 years ago

With a few nits from Julian
  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/html;charset=utf-8
File size: 36.3 KB
Line 
1<!DOCTYPE html
2  PUBLIC "-//W3C//DTD HTML 4.01//EN">
3<html lang="en">
4   <head profile="http://www.w3.org/2006/03/hcard">
5      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
6      <title>Security Requirements for HTTP</title><style type="text/css" title="Xml2Rfc (sans serif)">
7a {
8  text-decoration: none;
9}
10a.smpl {
11  color: black;
12}
13a:hover {
14  text-decoration: underline;
15}
16a:active {
17  text-decoration: underline;
18}
19address {
20  margin-top: 1em;
21  margin-left: 2em;
22  font-style: normal;
23}
24body {
25  color: black;
26  font-family: verdana, helvetica, arial, sans-serif;
27  font-size: 10pt;
28}
29cite {
30  font-style: normal;
31}
32dd {
33  margin-right: 2em;
34}
35dl {
36  margin-left: 2em;
37}
38
39dl.empty dd {
40  margin-top: .5em;
41}
42dl p {
43  margin-left: 0em;
44}
45dt {
46  margin-top: .5em;
47}
48h1 {
49  font-size: 14pt;
50  line-height: 21pt;
51  page-break-after: avoid;
52}
53h1.np {
54  page-break-before: always;
55}
56h1 a {
57  color: #333333;
58}
59h2 {
60  font-size: 12pt;
61  line-height: 15pt;
62  page-break-after: avoid;
63}
64h2 a {
65  color: black;
66}
67h3 {
68  font-size: 10pt;
69  page-break-after: avoid;
70}
71h3 a {
72  color: black;
73}
74h4 {
75  font-size: 10pt;
76  page-break-after: avoid;
77}
78h4 a {
79  color: black;
80}
81h5 {
82  font-size: 10pt;
83  page-break-after: avoid;
84}
85h5 a {
86  color: black;
87}
88img {
89  margin-left: 3em;
90}
91li {
92  margin-left: 2em;
93  margin-right: 2em;
94}
95ol {
96  margin-left: 2em;
97  margin-right: 2em;
98}
99ol p {
100  margin-left: 0em;
101}
102p {
103  margin-left: 2em;
104  margin-right: 2em;
105}
106pre {
107  margin-left: 3em;
108  background-color: lightyellow;
109  padding: .25em;
110}
111pre.text2 {
112  border-style: dotted;
113  border-width: 1px;
114  background-color: #f0f0f0;
115  width: 69em;
116}
117pre.inline {
118  background-color: white;
119  padding: 0em;
120}
121pre.text {
122  border-style: dotted;
123  border-width: 1px;
124  background-color: #f8f8f8;
125  width: 69em;
126}
127pre.drawing {
128  border-style: solid;
129  border-width: 1px;
130  background-color: #f8f8f8;
131  padding: 2em;
132}
133table {
134  margin-left: 2em;
135}
136table.header {
137  width: 95%;
138  font-size: 10pt;
139  color: white;
140}
141td.top {
142  vertical-align: top;
143}
144td.topnowrap {
145  vertical-align: top;
146  white-space: nowrap;
147}
148td.header {
149  background-color: gray;
150  width: 50%;
151}
152td.reference {
153  vertical-align: top;
154  white-space: nowrap;
155  padding-right: 1em;
156}
157thead {
158  display:table-header-group;
159}
160ul.toc {
161  list-style: none;
162  margin-left: 1.5em;
163  margin-right: 0em;
164  padding-left: 0em;
165}
166li.tocline0 {
167  line-height: 150%;
168  font-weight: bold;
169  font-size: 10pt;
170  margin-left: 0em;
171  margin-right: 0em;
172}
173li.tocline1 {
174  line-height: normal;
175  font-weight: normal;
176  font-size: 9pt;
177  margin-left: 0em;
178  margin-right: 0em;
179}
180li.tocline2 {
181  font-size: 0pt;
182}
183ul p {
184  margin-left: 0em;
185}
186ul.ind {
187  list-style: none;
188  margin-left: 1.5em;
189  margin-right: 0em;
190  padding-left: 0em;
191}
192li.indline0 {
193  font-weight: bold;
194  line-height: 200%;
195  margin-left: 0em;
196  margin-right: 0em;
197}
198li.indline1 {
199  font-weight: normal;
200  line-height: 150%;
201  margin-left: 0em;
202  margin-right: 0em;
203}
204
205.comment {
206  background-color: yellow;
207}
208.center {
209  text-align: center;
210}
211.error {
212  color: red;
213  font-style: italic;
214  font-weight: bold;
215}
216.figure {
217  font-weight: bold;
218  text-align: center;
219  font-size: 9pt;
220}
221.filename {
222  color: #333333;
223  font-weight: bold;
224  font-size: 12pt;
225  line-height: 21pt;
226  text-align: center;
227}
228.fn {
229  font-weight: bold;
230}
231.hidden {
232  display: none;
233}
234.left {
235  text-align: left;
236}
237.right {
238  text-align: right;
239}
240.title {
241  color: #990000;
242  font-size: 18pt;
243  line-height: 18pt;
244  font-weight: bold;
245  text-align: center;
246  margin-top: 36pt;
247}
248.vcardline {
249  display: block;
250}
251.warning {
252  font-size: 14pt;
253  background-color: yellow;
254}
255
256
257@media print {
258  .noprint {
259    display: none;
260  }
261 
262  a {
263    color: black;
264    text-decoration: none;
265  }
266
267  table.header {
268    width: 90%;
269  }
270
271  td.header {
272    width: 50%;
273    color: black;
274    background-color: white;
275    vertical-align: top;
276    font-size: 12pt;
277  }
278
279  ul.toc a::after {
280    content: leader('.') target-counter(attr(href), page);
281  }
282 
283  a.iref {
284    content: target-counter(attr(href), page);
285  }
286 
287  .print2col {
288    column-count: 2;
289    -moz-column-count: 2;
290    column-fill: auto;
291  }
292}
293
294@page {
295  @top-left {
296       content: "INTERNET DRAFT";
297  }
298  @top-right {
299       content: "February 2008";
300  }
301  @top-center {
302       content: "Security Requirements for HTTP";
303  }
304  @bottom-left {
305       content: "Hoffman & Melnikov";
306  }
307  @bottom-center {
308       content: "Informational";
309  }
310  @bottom-right {
311       content: "[Page " counter(page) "]";
312  }
313}
314
315@page:first {
316    @top-left {
317      content: normal;
318    }
319    @top-right {
320      content: normal;
321    }
322    @top-center {
323      content: normal;
324    }
325}
326</style><link rel="Author" href="#rfc.authors">
327      <link rel="Copyright" href="#rfc.copyright">
328      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
329      <link rel="Chapter" title="2 Existing HTTP Security Mechanisms" href="#rfc.section.2">
330      <link rel="Chapter" title="3 Revisions To HTTP" href="#rfc.section.3">
331      <link rel="Chapter" title="4 Security Considerations" href="#rfc.section.4">
332      <link rel="Chapter" href="#rfc.section.5" title="5 Normative References">
333      <link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A">
334      <link rel="Appendix" title="B Document History" href="#rfc.section.B">
335      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.358, 2008-02-17 16:03:10, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
336      <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
337      <meta name="DC.Creator" content="Hoffman, P.">
338      <meta name="DC.Creator" content="Melnikov, A.">
339      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-01">
340      <meta name="DC.Date.Issued" scheme="ISO8601" content="2008-02">
341      <meta name="DC.Description.Abstract" content="Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade-offs of each.">
342   </head>
343   <body>
344      <table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1">
345         <tr>
346            <td class="header left">Network Working Group</td>
347            <td class="header right">P. Hoffman</td>
348         </tr>
349         <tr>
350            <td class="header left">Internet Draft</td>
351            <td class="header right">VPN Consortium</td>
352         </tr>
353         <tr>
354            <td class="header left">
355               &lt;draft-ietf-httpbis-security-properties-01&gt;
356               
357            </td>
358            <td class="header right">A. Melnikov</td>
359         </tr>
360         <tr>
361            <td class="header left">Intended status: Informational</td>
362            <td class="header right">Isode Ltd.</td>
363         </tr>
364         <tr>
365            <td class="header left">Expires: August 2008</td>
366            <td class="header right">February 2008</td>
367         </tr>
368      </table>
369      <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-01</span></p>
370      <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
371      <p>By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she
372         is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section
373         6 of BCP 79.
374      </p>
375      <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
376         that other groups may also distribute working documents as Internet-Drafts.
377      </p>
378      <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
379         documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
380         in progress”.
381      </p>
382      <p>The list of current Internet-Drafts can be accessed at &lt;<a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>&gt;.
383      </p>
384      <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
385      </p>
386      <p>This Internet-Draft will expire in August 2008.</p>
387      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
388      <p>Copyright © The IETF Trust (2008). All Rights Reserved.</p>
389      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
390      <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant
391         implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes
392         the trade-offs of each.
393      </p>
394      <hr class="noprint">
395      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
396      </h1>
397      <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols are required to specify mandatory to implement security mechanisms. "The
398         IETF Standards Process" <a href="#RFC2026"><cite title="The Internet Standards Process -- Revision 3">[RFC2026]</cite></a> does not require that protocols specify mandatory security mechanisms. "Strong Security Requirements for IETF Standard Protocols" <a href="#RFC3365"><cite title="Strong Security Requirements for Internet Engineering Task Force Standard Protocols">[RFC3365]</cite></a> requires that all IETF protocols provide a mechanism for implementers to provide strong security. RFC 3365 does not define
399         the term "strong security".
400      </p>
401      <p id="rfc.section.1.p.2">"Security Mechanisms for the Internet" <a href="#RFC3631"><cite title="Security Mechanisms for the Internet">[RFC3631]</cite></a> is not an IETF procedural RFC, but it is perhaps most relevant. Section 2.2 states:
402      </p>
403      <div id="rfc.figure.u.1"></div><pre>
404  We have evolved in the IETF the notion of "mandatory to implement"
405  mechanisms.  This philosophy evolves from our primary desire to
406  ensure interoperability between different implementations of a
407  protocol.  If a protocol offers many options for how to perform a
408  particular task, but fails to provide for at least one that all
409  must implement, it may be possible that multiple, non-interoperable
410  implementations may result.  This is the consequence of the
411  selection of non-overlapping mechanisms being deployed in the
412  different implementations.
413</pre><p id="rfc.section.1.p.4">This document examines the effects of applying security constraints to Web applications, documents the properties that result
414         from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
415         moment, it is mostly a laundry list of security technologies and tradeoffs.
416      </p>
417      <hr class="noprint">
418      <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Existing HTTP Security Mechanisms
419      </h1>
420      <p id="rfc.section.2.p.1">For HTTP, the IETF generally defines "security mechanisms" as some combination of access authentication and/or a secure transport.</p>
421      <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. ]]</p>
422      <p id="rfc.section.2.p.3">[[ NTLM (shudder) was brought up in the WG a few times in the discussion of the -00 draft. Should we add a section on it?
423         ]]
424      </p>
425      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
426      </h2>
427      <p id="rfc.section.2.1.p.1">Almost all HTTP authentication that involves a human using a web browser is accomplished through HTML forms, with session
428         identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
429         loosely in section 10 of "HTTP State Management Mechanism" <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>. The protocol in RFC 2109 is relatively widely implemented, but most clients don't advertise support for it. RFC 2109 was
430         later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
431      </p>
432      <p id="rfc.section.2.1.p.2">Forms and cookies have many properties that make them an excellent solution for some implementers. However, many of those
433         properties introduce serious security trade-offs.
434      </p>
435      <p id="rfc.section.2.1.p.3">HTML forms provide a large degree of control over presentation, which is an imperative for many websites. However, this increases
436         user reliance on the appearance of the interface. Many users do not understand the construction of URIs <a href="#RFC3986"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, or their presentation in common clients <a href="#PhishingHOWTO"><cite title="Phishing Tips and Techniques">[PhishingHOWTO]</cite></a>. As a result, forms are extremely vulnerable to spoofing.
437      </p>
438      <p id="rfc.section.2.1.p.4">HTML forms provide acceptable internationalization if used carefully, at the cost of being transmitted as normal HTTP content
439         in all cases (credentials are not differentiated in the protocol).
440      </p>
441      <p id="rfc.section.2.1.p.5">HTML forms provide a facility for sites to indicate that a password should never be pre-populated. [[ More needed here on
442         autocomplete ]]
443      </p>
444      <p id="rfc.section.2.1.p.6">The cookies that result from a successful form submission make it unnecessary to validate credentials with each HTTP request;
445         this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
446         attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
447         cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries
448         and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the
449         data.
450      </p>
451      <p id="rfc.section.2.1.p.7">HTML forms and cookies provide flexible ways of ending a session from the client.</p>
452      <p id="rfc.section.2.1.p.8">HTML forms require an HTML rendering engine for which many protocols have no use.</p>
453      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
454      </h2>
455      <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies,
456         but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
457         logout capabilities, or interoperable internationalization.
458      </p>
459      <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Basic Authentication
460      </h3>
461      <p id="rfc.section.2.2.1.p.1">Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement,
462         but not at all secure unless used over a secure transport.
463      </p>
464      <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure
465         transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials,
466         but there is no standard method of doing so.
467      </p>
468      <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication
469         database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.
470      </p>
471      <p id="rfc.section.2.2.1.p.4">Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
472      <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Digest Authentication
473      </h3>
474      <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and
475         values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.
476      </p>
477      <p id="rfc.section.2.2.2.p.2">Digest has some properties that are preferable to Basic and Cookies. Credentials are not immediately reusable by parties that
478         observe or receive them, and session data can be transmitted along side credentials with each request, allowing servers to
479         validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.
480      </p>
481      <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most
482         implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation
483         experience has shown that in some cases, especially those involving large requests or responses such as streams, the message
484         integrity mode is impractical because it requires servers to analyze the full request before determining whether the client
485         knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.
486      </p>
487      <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk
488         consisting of a few million passwords [[ CITATION NEEDED ]].
489      </p>
490      <p id="rfc.section.2.2.2.p.5">Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <a href="#Apache_Digest"><cite title="Apache HTTP Server - mod_auth_digest">[Apache_Digest]</cite></a>.
491      </p>
492      <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext
493         passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common
494         method of storing passwords for use with Forms and Cookies.
495      </p>
496      <p id="rfc.section.2.2.2.p.7">Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</p>
497      <p id="rfc.section.2.2.2.p.8">Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
498      <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a>&nbsp;Other Access Authentication Schemes
499      </h3>
500      <p id="rfc.section.2.2.3.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are
501         bound to transport layer connections.
502      </p>
503      <h4 id="rfc.section.2.2.3.1"><a href="#rfc.section.2.2.3.1">2.2.3.1</a>&nbsp;Negotiate (GSS-API) Authentication
504      </h4>
505      <p id="rfc.section.2.2.3.1.p.1">[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows" <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a> goes here. ]]
506      </p>
507      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
508      </h2>
509      <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited
510         ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ
511         one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more
512         than a sophisticated application of forms and cookies.
513      </p>
514      <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization
515         efforts in progress, as usual.
516      </p>
517      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;Web Services
518      </h2>
519      <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for
520         TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination
521         of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture
522         of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based
523         application protocols.
524      </p>
525      <p id="rfc.section.2.4.p.2">[[ This section could really use a good definition of "Web Services" to differentiate it from REST. ]]</p>
526      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
527      </h2>
528      <p id="rfc.section.2.5.p.1">[[ A discussion of HTTP over TLS needs to be added here. ]]</p>
529      <p id="rfc.section.2.5.p.2">[[ Discussion of connection confidentiality should be separate from the discussion of access authentication based on mutual
530         authentication with certificates in TLS. ]]
531      </p>
532      <hr class="noprint">
533      <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Revisions To HTTP
534      </h1>
535      <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and
536         no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate
537         will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.
538      </p>
539      <hr class="noprint">
540      <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;Security Considerations
541      </h1>
542      <p id="rfc.section.4.p.1">This entire document is about security considerations.</p>
543      <h1 class="np" id="rfc.references"><a href="#rfc.section.5" id="rfc.section.5">5.</a> Normative References
544      </h1>
545      <table summary="Normative References">
546         <tr>
547            <td class="reference"><b id="RFC2026">[RFC2026]</b></td>
548            <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP&nbsp;9, RFC&nbsp;2026, October&nbsp;1996.
549            </td>
550         </tr> 
551         <tr>
552            <td class="reference"><b id="RFC2109">[RFC2109]</b></td>
553            <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.M.</a> and <a href="mailto:montulli@netscape.com" title="Netscape Communications Corp.">L. Montulli</a>, “<a href="http://tools.ietf.org/html/rfc2109">HTTP State Management Mechanism</a>”, RFC&nbsp;2109, February&nbsp;1997.
554            </td>
555         </tr> 
556         <tr>
557            <td class="reference"><b id="RFC2145">[RFC2145]</b></td>
558            <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.C.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.T.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC&nbsp;2145, May&nbsp;1997.
559            </td>
560         </tr> 
561         <tr>
562            <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
563            <td class="top"><a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="World Wide Web Consortium">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="World Wide Web Consortium">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
564            </td>
565         </tr> 
566         <tr>
567            <td class="reference"><b id="RFC2617">[RFC2617]</b></td>
568            <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.M.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.L.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.D.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.J.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC&nbsp;2617, June&nbsp;1999.
569            </td>
570         </tr> 
571         <tr>
572            <td class="reference"><b id="RFC2965">[RFC2965]</b></td>
573            <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D. M.</a> and <a href="mailto:lou@montulli.org" title="Epinions.com, Inc.">L. Montulli</a>, “<a href="http://tools.ietf.org/html/rfc2965">HTTP State Management Mechanism</a>”, RFC&nbsp;2965, October&nbsp;2000.
574            </td>
575         </tr> 
576         <tr>
577            <td class="reference"><b id="RFC3365">[RFC3365]</b></td>
578            <td class="top">Schiller, J., “<a href="http://tools.ietf.org/html/rfc3365">Strong Security Requirements for Internet Engineering Task Force Standard Protocols</a>”, BCP&nbsp;61, RFC&nbsp;3365, August&nbsp;2002.
579            </td>
580         </tr> 
581         <tr>
582            <td class="reference"><b id="RFC3631">[RFC3631]</b></td>
583            <td class="top">Bellovin, S., Schiller, J., and C. Kaufman, “<a href="http://tools.ietf.org/html/rfc3631">Security Mechanisms for the Internet</a>”, RFC&nbsp;3631, December&nbsp;2003.
584            </td>
585         </tr> 
586         <tr>
587            <td class="reference"><b id="RFC3986">[RFC3986]</b></td>
588            <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005.
589            </td>
590         </tr> 
591         <tr>
592            <td class="reference"><b id="RFC4559">[RFC4559]</b></td>
593            <td class="top">Jaganathan, K., Zhu, L., and J. Brezak, “<a href="http://tools.ietf.org/html/rfc4559">SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</a>”, RFC&nbsp;4559, June&nbsp;2006.
594            </td>
595         </tr> 
596         <tr>
597            <td class="reference"><b id="Apache_Digest">[Apache_Digest]</b></td>
598            <td class="top">Apache Software Foundation, , “<a href="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">Apache HTTP Server - mod_auth_digest</a>”, &lt;<a href="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html</a>&gt;.
599            </td>
600         </tr> 
601         <tr>
602            <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td>
603            <td class="top">Gutmann, P., “<a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf">Phishing Tips and Techniques</a>”, February&nbsp;2008, &lt;<a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf">http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf</a>&gt;.
604            </td>
605         </tr> 
606         <tr>
607            <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td>
608            <td class="top">Bray, T., “<a href="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research">WS-Pagecount</a>”, September&nbsp;2004, &lt;<a href="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research">http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research</a>&gt;.
609            </td>
610         </tr>
611      </table>
612      <hr class="noprint">
613      <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>
614      <address class="vcard"><span class="vcardline"><span class="fn">Paul Hoffman</span><span class="n hidden"><span class="family-name">Hoffman</span><span class="given-name">Paul</span></span></span><span class="org vcardline">VPN Consortium</span><span class="vcardline">EMail: <a href="mailto:paul.hoffman@vpnc.org"><span class="email">paul.hoffman@vpnc.org</span></a></span></address>
615      <address class="vcard"><span class="vcardline"><span class="fn">Alexey Melnikov</span><span class="n hidden"><span class="family-name">Melnikov</span><span class="given-name">Alexey</span></span></span><span class="org vcardline">Isode Ltd.</span><span class="vcardline">EMail: <a href="mailto:alexey.melnikov@isode.com"><span class="email">alexey.melnikov@isode.com</span></a></span></address>
616      <hr class="noprint">
617      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
618      </h1>
619      <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working
620         Group have contributed to this document in the discussion.
621      </p>
622      <hr class="noprint">
623      <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a>&nbsp;Document History
624      </h1>
625      <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>
626      <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;Changes between draft-sayre-http-security-variance-00 and   draft-ietf-httpbis-security-properties-00
627      </h2>
628      <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
629      <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>
630      <p id="rfc.section.B.1.p.3">Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</p>
631      <p id="rfc.section.B.1.p.4">In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 repertoire" to match the definition of "TEXT" in RFC 2616.</p>
632      <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>
633      <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>
634      <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Changes between -00 and -01
635      </h2>
636      <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>
637      <p id="rfc.section.B.2.p.2">Added the suggestions about splitting for browsers and automation, and about adding NTLM, to be beginning of 2.</p>
638      <p id="rfc.section.B.2.p.3">In 2.1, added "that involves a human using a web browser" in the first sentence.</p>
639      <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>
640      <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p>
641      <div id="rfc.figure.u.2"></div><pre>
642Digest includes many modes of operation, but only the simplest modes
643enjoy any degree of interoperability.  For example, most
644implementations do not implement the mode that provides full message
645integrity.  Additionally, implementation experience has shown that
646the message integrity mode is impractical because it requires servers
647to analyze the full request before determining whether the client
648knows the shared secret.
649</pre><p> to </p>
650      <div id="rfc.figure.u.3"></div><pre>
651Digest includes many modes of operation, but only the simplest
652modes enjoy any degree of interoperability.  For example, most
653implementations do not implement the mode that provides full message
654integrity.  Perhaps one reason is that implementation experience has
655shown that in some cases, especially those involving large requests
656or responses such as streams, the message integrity mode is
657impractical because it requires servers to analyze the full request
658before determining whether the client knows the shared secret or
659whether message-body integrity has been violated and hence whether
660the request can be processed.
661</pre><p id="rfc.section.B.2.p.6">In 2.4, asked for a definition of "Web Services".</p>
662      <p id="rfc.section.B.2.p.7">In A, added the WG.</p>
663      <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
664      <p>Copyright © The IETF Trust (2008).</p>
665      <p>This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the
666         authors retain all their rights.
667      </p>
668      <p>This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION
669         HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
670         DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
671         WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
672      </p>
673      <hr class="noprint">
674      <h1 class="np"><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>
675      <p>The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might
676         be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any
677         license under such rights might or might not be available; nor does it represent that it has made any independent effort to
678         identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and
679         BCP 79.
680      </p>
681      <p>Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result
682         of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users
683         of this specification can be obtained from the IETF on-line IPR repository at &lt;<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>&gt;.
684      </p>
685      <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
686         rights that may cover technology that may be required to implement this standard. Please address the information to the IETF
687         at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>.
688      </p>
689      <h1>Acknowledgement</h1>
690      <p>Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).</p>
691   </body>
692</html>
Note: See TracBrowser for help on using the repository browser.