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

Last change on this file since 573 was 551, checked in by julian.reschke@…, 14 years ago

Reflect publication of draft 03 in svn.
  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/html;charset=utf-8
File size: 38.0 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}
64h3, h4, h5, h6 {
65  font-size: 10pt;
66  page-break-after: avoid;
67}
68h2 a, h3 a, h4 a, h5 a, h6 a {
69  color: black;
70}
71img {
72  margin-left: 3em;
73}
74li {
75  margin-left: 2em;
76  margin-right: 2em;
77}
78ol {
79  margin-left: 2em;
80  margin-right: 2em;
81}
82ol p {
83  margin-left: 0em;
84}
85p {
86  margin-left: 2em;
87  margin-right: 2em;
88}
89pre {
90  margin-left: 3em;
91  background-color: lightyellow;
92  padding: .25em;
93}
94pre.text2 {
95  border-style: dotted;
96  border-width: 1px;
97  background-color: #f0f0f0;
98  width: 69em;
99}
100pre.inline {
101  background-color: white;
102  padding: 0em;
103}
104pre.text {
105  border-style: dotted;
106  border-width: 1px;
107  background-color: #f8f8f8;
108  width: 69em;
109}
110pre.drawing {
111  border-style: solid;
112  border-width: 1px;
113  background-color: #f8f8f8;
114  padding: 2em;
115}
116table {
117  margin-left: 2em;
118}
119table.header {
120  width: 95%;
121  font-size: 10pt;
122  color: white;
123}
124td.top {
125  vertical-align: top;
126}
127td.topnowrap {
128  vertical-align: top;
129  white-space: nowrap;
130}
131td.header {
132  background-color: gray;
133  width: 50%;
134}
135td.reference {
136  vertical-align: top;
137  white-space: nowrap;
138  padding-right: 1em;
139}
140thead {
141  display:table-header-group;
142}
143ul.toc {
144  list-style: none;
145  margin-left: 1.5em;
146  margin-right: 0em;
147  padding-left: 0em;
148}
149li.tocline0 {
150  line-height: 150%;
151  font-weight: bold;
152  font-size: 10pt;
153  margin-left: 0em;
154  margin-right: 0em;
155}
156li.tocline1 {
157  line-height: normal;
158  font-weight: normal;
159  font-size: 9pt;
160  margin-left: 0em;
161  margin-right: 0em;
162}
163li.tocline2 {
164  font-size: 0pt;
165}
166ul p {
167  margin-left: 0em;
168}
169
170.comment {
171  background-color: yellow;
172}
173.center {
174  text-align: center;
175}
176.error {
177  color: red;
178  font-style: italic;
179  font-weight: bold;
180}
181.figure {
182  font-weight: bold;
183  text-align: center;
184  font-size: 9pt;
185}
186.filename {
187  color: #333333;
188  font-weight: bold;
189  font-size: 12pt;
190  line-height: 21pt;
191  text-align: center;
192}
193.fn {
194  font-weight: bold;
195}
196.hidden {
197  display: none;
198}
199.left {
200  text-align: left;
201}
202.right {
203  text-align: right;
204}
205.title {
206  color: #990000;
207  font-size: 18pt;
208  line-height: 18pt;
209  font-weight: bold;
210  text-align: center;
211  margin-top: 36pt;
212}
213.vcardline {
214  display: block;
215}
216.warning {
217  font-size: 14pt;
218  background-color: yellow;
219}
220
221
222@media print {
223  .noprint {
224    display: none;
225  }
226 
227  a {
228    color: black;
229    text-decoration: none;
230  }
231
232  table.header {
233    width: 90%;
234  }
235
236  td.header {
237    width: 50%;
238    color: black;
239    background-color: white;
240    vertical-align: top;
241    font-size: 12pt;
242  }
243
244  ul.toc a::after {
245    content: leader('.') target-counter(attr(href), page);
246  }
247 
248  a.iref {
249    content: target-counter(attr(href), page);
250  }
251 
252  .print2col {
253    column-count: 2;
254    -moz-column-count: 2;
255    column-fill: auto;
256  }
257}
258
259@page {
260  @top-left {
261       content: "INTERNET DRAFT";
262  }
263  @top-right {
264       content: "March 2009";
265  }
266  @top-center {
267       content: "Security Requirements for HTTP";
268  }
269  @bottom-left {
270       content: "Hoffman & Melnikov";
271  }
272  @bottom-center {
273       content: "Informational";
274  }
275  @bottom-right {
276       content: "[Page " counter(page) "]";
277  }
278}
279
280@page:first {
281    @top-left {
282      content: normal;
283    }
284    @top-right {
285      content: normal;
286    }
287    @top-center {
288      content: normal;
289    }
290}
291</style><link rel="Author" href="#rfc.authors">
292      <link rel="Copyright" href="#rfc.copyright">
293      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
294      <link rel="Chapter" title="2 Existing HTTP Security Mechanisms" href="#rfc.section.2">
295      <link rel="Chapter" title="3 Revisions To HTTP" href="#rfc.section.3">
296      <link rel="Chapter" title="4 Security Considerations" href="#rfc.section.4">
297      <link rel="Chapter" href="#rfc.section.5" title="5 Normative References">
298      <link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A">
299      <link rel="Appendix" title="B Document History" href="#rfc.section.B">
300      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.426, 2009-03-07 10:31:10, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
301      <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
302      <meta name="DC.Creator" content="Hoffman, P.">
303      <meta name="DC.Creator" content="Melnikov, A.">
304      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-latest">
305      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-03">
306      <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.">
307   </head>
308   <body>
309      <table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1">
310         <tr>
311            <td class="header left">Network Working Group</td>
312            <td class="header right">P. Hoffman</td>
313         </tr>
314         <tr>
315            <td class="header left">Internet Draft</td>
316            <td class="header right">VPN Consortium</td>
317         </tr>
318         <tr>
319            <td class="header left">
320               &lt;draft-ietf-httpbis-security-properties-latest&gt;
321               
322            </td>
323            <td class="header right">A. Melnikov</td>
324         </tr>
325         <tr>
326            <td class="header left">Intended status: Informational</td>
327            <td class="header right">Isode Ltd.</td>
328         </tr>
329         <tr>
330            <td class="header left">Expires: September 2009</td>
331            <td class="header right">March 9, 2009</td>
332         </tr>
333      </table>
334      <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-latest</span></p>
335      <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
336      <p>This Internet-Draft is submitted to IETF pursuant to, and in full conformance with, the provisions of BCP 78 and BCP 79. This
337         document may contain material from IETF Documents or IETF Contributions published or made publicly available before November
338         10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to
339         allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)
340         controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative
341         works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate
342         it into languages other than English.
343      </p>
344      <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
345         that other groups may also distribute working documents as Internet-Drafts.
346      </p>
347      <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
348         documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
349         in progress”.
350      </p>
351      <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;.
352      </p>
353      <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;.
354      </p>
355      <p>This Internet-Draft will expire in September 2009.</p>
356      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
357      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
358      <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date
359         of publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
360      </p>
361      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
362      <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant
363         implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes
364         the trade-offs of each.
365      </p>
366      <hr class="noprint">
367      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
368      </h1>
369      <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols are required to specify mandatory to implement security mechanisms. "The
370         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
371         the term "strong security".
372      </p>
373      <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:
374      </p>
375      <div id="rfc.figure.u.1"></div><pre>
376  We have evolved in the IETF the notion of "mandatory to implement"
377  mechanisms.  This philosophy evolves from our primary desire to
378  ensure interoperability between different implementations of a
379  protocol.  If a protocol offers many options for how to perform a
380  particular task, but fails to provide for at least one that all
381  must implement, it may be possible that multiple, non-interoperable
382  implementations may result.  This is the consequence of the
383  selection of non-overlapping mechanisms being deployed in the
384  different implementations.
385</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
386         from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
387         moment, it is mostly a laundry list of security technologies and tradeoffs.
388      </p>
389      <hr class="noprint">
390      <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Existing HTTP Security Mechanisms
391      </h1>
392      <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>
393      <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. ]]</p>
394      <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?
395         ]]
396      </p>
397      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
398      </h2>
399      <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
400         identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
401         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
402         later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
403      </p>
404      <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
405         properties introduce serious security trade-offs.
406      </p>
407      <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
408         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.
409      </p>
410      <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
411         in all cases (credentials are not differentiated in the protocol).
412      </p>
413      <p id="rfc.section.2.1.p.5">Many Web browsers have an auto-complete feature that stores a user's information and pre-populates fields in forms. This is
414         considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security
415         concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML
416         forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it
417         is clear that some form creators do not use this facility when they should.
418      </p>
419      <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;
420         this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
421         attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
422         cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries
423         and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the
424         data.
425      </p>
426      <p id="rfc.section.2.1.p.7">HTML forms and cookies provide flexible ways of ending a session from the client.</p>
427      <p id="rfc.section.2.1.p.8">HTML forms require an HTML rendering engine for which many protocols have no use.</p>
428      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
429      </h2>
430      <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,
431         but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
432         logout capabilities, or interoperable internationalization.
433      </p>
434      <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Basic Authentication
435      </h3>
436      <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,
437         but not at all secure unless used over a secure transport.
438      </p>
439      <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
440         transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials,
441         but there is no standard method of doing so.
442      </p>
443      <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
444         database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.
445      </p>
446      <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>
447      <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Digest Authentication
448      </h3>
449      <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
450         values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.
451      </p>
452      <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
453         observe or receive them, and session data can be transmitted along side credentials with each request, allowing servers to
454         validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.
455      </p>
456      <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
457         implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation
458         experience has shown that in some cases, especially those involving large requests or responses such as streams, the message
459         integrity mode is impractical because it requires servers to analyze the full request before determining whether the client
460         knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.
461      </p>
462      <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
463         consisting of a few million passwords for most users.
464      </p>
465      <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>.
466      </p>
467      <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
468         passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common
469         method of storing passwords for use with Forms and Cookies.
470      </p>
471      <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>
472      <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>
473      <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a>&nbsp;Authentication Using Certificates in TLS
474      </h3>
475      <p id="rfc.section.2.2.3.p.1">Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication
476         of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers,
477         TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates
478         in TLS can be rooted in public trust anchors or can be based on local trust anchors.
479      </p>
480      <h3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a>&nbsp;Other Access Authentication Schemes
481      </h3>
482      <p id="rfc.section.2.2.4.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are
483         bound to transport layer connections.
484      </p>
485      <h4 id="rfc.section.2.2.4.1"><a href="#rfc.section.2.2.4.1">2.2.4.1</a>&nbsp;Negotiate (GSS-API) Authentication
486      </h4>
487      <p id="rfc.section.2.2.4.1.p.1">Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO <a href="#RFC4178"><cite title="The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism">[RFC4178]</cite></a> GSSAPI <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>. In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols).
488      </p>
489      <p id="rfc.section.2.2.4.1.p.2">In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication
490         database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms
491         such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets
492         traveling along the network can be read, modified, and inserted at will.
493      </p>
494      <p id="rfc.section.2.2.4.1.p.3">Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization,
495         server sending authentication data in WWW-Authenticate) to complete.
496      </p>
497      <p id="rfc.section.2.2.4.1.p.4">Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication
498         service might be a barrier to deployment.
499      </p>
500      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
501      </h2>
502      <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
503         ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ
504         one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more
505         than a sophisticated application of forms and cookies.
506      </p>
507      <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
508         efforts in progress, as usual.
509      </p>
510      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;Web Services
511      </h2>
512      <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
513         TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination
514         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
515         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
516         application protocols.
517      </p>
518      <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>
519      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
520      </h2>
521      <p id="rfc.section.2.5.p.1">In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality
522         and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping
523         by TLS.
524      </p>
525      <p id="rfc.section.2.5.p.2">It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against
526         a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable
527         and does not address that weakness.
528      </p>
529      <hr class="noprint">
530      <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Revisions To HTTP
531      </h1>
532      <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
533         no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate
534         will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.
535      </p>
536      <hr class="noprint">
537      <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;Security Considerations
538      </h1>
539      <p id="rfc.section.4.p.1">This entire document is about security considerations.</p>
540      <h1 class="np" id="rfc.references"><a href="#rfc.section.5" id="rfc.section.5">5.</a> Normative References
541      </h1>
542      <table summary="Normative References">
543         <tr>
544            <td class="reference"><b id="RFC2026">[RFC2026]</b></td>
545            <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.
546            </td>
547         </tr> 
548         <tr>
549            <td class="reference"><b id="RFC2109">[RFC2109]</b></td>
550            <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.
551            </td>
552         </tr> 
553         <tr>
554            <td class="reference"><b id="RFC2145">[RFC2145]</b></td>
555            <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.
556            </td>
557         </tr> 
558         <tr>
559            <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
560            <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.
561            </td>
562         </tr> 
563         <tr>
564            <td class="reference"><b id="RFC2617">[RFC2617]</b></td>
565            <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.
566            </td>
567         </tr> 
568         <tr>
569            <td class="reference"><b id="RFC2965">[RFC2965]</b></td>
570            <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.
571            </td>
572         </tr> 
573         <tr>
574            <td class="reference"><b id="RFC3365">[RFC3365]</b></td>
575            <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.
576            </td>
577         </tr> 
578         <tr>
579            <td class="reference"><b id="RFC3631">[RFC3631]</b></td>
580            <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.
581            </td>
582         </tr> 
583         <tr>
584            <td class="reference"><b id="RFC3986">[RFC3986]</b></td>
585            <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.
586            </td>
587         </tr> 
588         <tr>
589            <td class="reference"><b id="RFC4178">[RFC4178]</b></td>
590            <td class="top">Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, “<a href="http://tools.ietf.org/html/rfc4178">The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism</a>”, RFC&nbsp;4178, October&nbsp;2005.
591            </td>
592         </tr> 
593         <tr>
594            <td class="reference"><b id="RFC4559">[RFC4559]</b></td>
595            <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.
596            </td>
597         </tr> 
598         <tr>
599            <td class="reference"><b id="Apache_Digest">[Apache_Digest]</b></td>
600            <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;.
601            </td>
602         </tr> 
603         <tr>
604            <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td>
605            <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;.
606            </td>
607         </tr> 
608         <tr>
609            <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td>
610            <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;.
611            </td>
612         </tr>
613      </table>
614      <hr class="noprint">
615      <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>
616      <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>
617      <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>
618      <hr class="noprint">
619      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
620      </h1>
621      <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
622         Group have contributed to this document in the discussion.
623      </p>
624      <hr class="noprint">
625      <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a>&nbsp;Document History
626      </h1>
627      <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>
628      <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
629      </h2>
630      <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
631      <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>
632      <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>
633      <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>
634      <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>
635      <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>
636      <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Changes between -00 and -01
637      </h2>
638      <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>
639      <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>
640      <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>
641      <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>
642      <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p>
643      <div id="rfc.figure.u.2"></div><pre>
644Digest includes many modes of operation, but only the simplest modes
645enjoy any degree of interoperability.  For example, most
646implementations do not implement the mode that provides full message
647integrity.  Additionally, implementation experience has shown that
648the message integrity mode is impractical because it requires servers
649to analyze the full request before determining whether the client
650knows the shared secret.
651</pre><p> to </p>
652      <div id="rfc.figure.u.3"></div><pre>
653Digest includes many modes of operation, but only the simplest
654modes enjoy any degree of interoperability.  For example, most
655implementations do not implement the mode that provides full message
656integrity.  Perhaps one reason is that implementation experience has
657shown that in some cases, especially those involving large requests
658or responses such as streams, the message integrity mode is
659impractical because it requires servers to analyze the full request
660before determining whether the client knows the shared secret or
661whether message-body integrity has been violated and hence whether
662the request can be processed.
663</pre><p id="rfc.section.B.2.p.6">In 2.4, asked for a definition of "Web Services".</p>
664      <p id="rfc.section.B.2.p.7">In A, added the WG.</p>
665      <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;Changes between -01 and -02
666      </h2>
667      <p id="rfc.section.B.3.p.1">In section 2.1, added more to the paragraph on auto-completion of HTML forms.</p>
668      <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p>
669      <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p>
670   </body>
671</html>
Note: See TracBrowser for help on using the repository browser.