source: draft-ietf-httpbis-security-properties/01/draft-ietf-httpbis-security-properties-01.xml @ 1030

Last change on this file since 1030 was 740, checked in by julian.reschke@…, 11 years ago

add missing date element

File size: 17.0 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
3<!ENTITY rfc2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">
4<!ENTITY rfc2109 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2109.xml">
5<!ENTITY rfc2145 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2145.xml">
6<!ENTITY rfc2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
7<!ENTITY rfc2617 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
8<!ENTITY rfc2965 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2965.xml">
9<!ENTITY rfc3365 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3365.xml">
10<!ENTITY rfc3631 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3631.xml">
11<!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
12<!ENTITY rfc4559 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559.xml">
13]>
14
15<rfc category="info" ipr="full3978"
16  docName="draft-ietf-httpbis-security-properties-01.txt">
17
18<?xml-stylesheet type='text/xsl' href='rfc2629xslt/rfc2629.xslt' ?>
19
20<?rfc toc="yes" ?>
21<?rfc symrefs="yes" ?>
22<?rfc sortrefs="yes"?>
23<?rfc strict="yes" ?>
24<?rfc compact="yes" ?>
25<?rfc subcompact="no" ?>
26<?rfc linkmailto='no'?>
27<?rfc comments="yes"?>
28<?rfc inline="yes"?>
29
30<front>
31  <title>Security Requirements for HTTP</title>
32  <author initials='P.' surname="Hoffman" fullname='Paul Hoffman'>
33    <organization>VPN Consortium</organization>
34    <address><email>paul.hoffman@vpnc.org</email> </address>
35  </author>
36  <author initials='A.' surname="Melnikov" fullname='Alexey Melnikov'>
37     <organization>Isode Ltd.</organization>
38     <address><email>alexey.melnikov@isode.com</email> </address>
39  </author>
40  <date year="2008" month="February" day="22"/>
41  <abstract>
42    <t>Recent IESG practice dictates that IETF protocols must specify
43      mandatory-to-implement security mechanisms, so that
44      all conformant implementations share a common baseline. This
45      document examines all widely deployed HTTP security
46      technologies, and analyzes the trade-offs of
47      each.</t>
48  </abstract>
49</front>
50
51<middle>
52 
53<section title="Introduction">
54
55<t>Recent IESG practice dictates that IETF protocols are required to
56specify mandatory to implement security mechanisms. "The IETF
57Standards Process" <xref target="RFC2026"/> does not require that
58protocols specify mandatory security mechanisms. "Strong Security
59Requirements for IETF Standard Protocols" <xref target="RFC3365"/>
60requires that all IETF protocols provide a mechanism for implementers
61to provide strong security. RFC 3365 does not define the term "strong
62security".</t>
63
64<t>"Security Mechanisms for the Internet" <xref target="RFC3631"/> is
65not an IETF procedural RFC, but it is perhaps most relevant. Section
662.2 states:</t>
67
68<figure><artwork>
69  We have evolved in the IETF the notion of "mandatory to implement"
70  mechanisms.  This philosophy evolves from our primary desire to
71  ensure interoperability between different implementations of a
72  protocol.  If a protocol offers many options for how to perform a
73  particular task, but fails to provide for at least one that all
74  must implement, it may be possible that multiple, non-interoperable
75  implementations may result.  This is the consequence of the
76  selection of non-overlapping mechanisms being deployed in the
77  different implementations.
78</artwork></figure>
79
80<t>This document examines the effects of applying security constraints
81to Web applications, documents the properties that result from each
82method, and will make Best Current Practice recommendations for HTTP
83security in a later document version. At the moment, it is mostly a
84laundry list of security technologies and tradeoffs.</t>
85
86</section>
87
88<section title="Existing HTTP Security Mechanisms">
89
90<t>For HTTP, the IETF generally defines "security mechanisms" as some
91combination of access authentication and/or a secure transport.</t>
92
93<t>[[ There is a suggestion that this section be split into
94"browser-like" and "automation-like" subsections. ]]</t>
95
96<t>[[ NTLM (shudder) was brought up in the WG a few times in
97the discussion of the -00 draft. Should we add a section on it? ]]</t>
98
99<section title="Forms And Cookies">
100
101<t>Almost all HTTP authentication that involves a human
102using a web browser is accomplished through HTML forms,
103with session identifiers stored in cookies. For cookies, most implementations
104rely on the "Netscape specification", which is described loosely in
105section 10 of "HTTP State Management Mechanism" <xref
106target="RFC2109"/>. The protocol in RFC 2109 is relatively widely
107implemented, but most clients don't advertise support for it. RFC 2109
108was later updated <xref target="RFC2965"/>, but the newer version is
109not widely implemented.</t>
110
111<t>Forms and cookies have many properties that make them an
112excellent solution for some implementers. However, many of those
113properties introduce serious security trade-offs.</t>
114
115<t>HTML forms provide a large degree of control over presentation,
116which is an imperative for many websites. However, this increases user
117reliance on the appearance of the interface. Many users do not
118understand the construction of URIs <xref target="RFC3986"/>, or their
119presentation in common clients <xref target="PhishingHOWTO"/>.
120As a result,
121forms are extremely vulnerable to spoofing.</t>
122
123<t>HTML forms provide acceptable internationalization if used
124carefully, at the cost of being transmitted as normal HTTP content in
125all cases (credentials are not differentiated in the protocol).</t>
126
127<t>HTML forms provide a facility for sites to indicate that a password
128should never be pre-populated.
129[[ More needed here on autocomplete ]]</t>
130
131<t>The cookies that result from a successful form submission make it
132unnecessary to validate credentials with each HTTP request; this makes
133cookies an excellent property for scalability. Cookies are susceptible
134to a large variety of XSS (cross-site scripting) attacks, and measures
135to prevent such attacks will never be as stringent as necessary for
136authentication credentials because cookies are used for many purposes.
137Cookies are also susceptible to a wide variety of attacks from
138malicious intermediaries and observers. The possible attacks depend on
139the contents of the cookie data. There is no standard format for most
140of the data.</t>
141
142<t>HTML forms and cookies provide flexible ways of ending a session
143from the client.</t>
144
145<t>HTML forms require an HTML rendering engine for which many protocols
146have no use.</t>
147
148</section>
149
150<section title="HTTP Access Authentication">
151
152<t>HTTP 1.1 provides a simple authentication framework, "HTTP
153Authentication: Basic and Digest Access Authentication" <xref
154target="RFC2617"/>, which defines two optional mechanisms. Both of these
155mechanisms are extremely rarely used in comparison to forms and
156cookies, but some degree of support for one or both is available in
157many implementations. Neither scheme provides presentation control,
158logout capabilities, or interoperable internationalization.</t>
159
160<section title="Basic Authentication">
161
162<t>Basic Authentication (normally called just "Basic") transmits
163usernames and passwords in the clear. It is very easy to implement,
164but not at all secure unless used over a secure transport.</t>
165
166<t>Basic has very poor scalability properties because credentials must
167be revalidated with every request, and because secure transports
168negate many of HTTP's caching mechanisms. Some implementations use
169cookies in combination with Basic credentials, but there is no
170standard method of doing so.</t>
171
172<t>Since Basic credentials are clear text, they are reusable by any
173party. This makes them compatible with any authentication database, at
174the cost of making the user vulnerable to mismanaged or malicious
175servers, even over a secure channel.</t>
176
177<t>Basic is not interoperable when used with credentials that contain
178characters outside of the ISO 8859-1 repertoire.</t>
179
180</section>
181
182<section title="Digest Authentication">
183
184<t>In Digest Authentication, the client transmits the results of
185hashing user credentials with properties of the request and values
186from the server challenge. Digest is susceptible to man-in-the-middle
187attacks when not used over a secure transport.</t>
188
189<t>Digest has some properties that are preferable to Basic and
190Cookies. Credentials are not immediately reusable by parties that
191observe or receive them, and session data can be transmitted along
192side credentials with each request, allowing servers to validate
193credentials only when absolutely necessary. Authentication data
194session keys are distinct from other protocol traffic.</t>
195
196<t>Digest includes many modes of operation, but only the simplest
197modes enjoy any degree of interoperability.  For example, most
198implementations do not implement the mode that provides full message
199integrity.  Perhaps one reason is that implementation experience has
200shown that in some cases, especially those involving large requests or
201responses such as streams, the message integrity mode is impractical
202because it requires servers to analyze the full request before
203determining whether the client knows the shared secret or whether
204message-body integrity has been violated and hence whether the request
205can be processed.</t>
206
207<t>Digest is extremely susceptible to offline dictionary attacks,
208making it practical for attackers to perform a namespace walk
209consisting of a few million passwords
210[[ CITATION NEEDED ]].</t>
211
212<t>Many of the most widely-deployed HTTP/1.1 clients are not compliant
213when GET requests include a query string <xref target="Apache_Digest"/>.</t>
214
215<t>Digest either requires that authentication databases be expressly designed
216to accommodate it, or requires access to cleartext passwords.
217As a result, many authentication databases that chose to do the former are
218incompatible, including the most common method of storing passwords
219for use with Forms and Cookies.</t>
220
221<t>Many Digest capabilities included to prevent replay attacks expose
222the server to Denial of Service attacks.</t>
223
224<t>Digest is not interoperable when used with credentials that contain
225characters outside of the ISO 8859-1 repertoire.</t>
226
227</section>
228
229<section title="Other Access Authentication Schemes">
230
231<t>There are many niche schemes that make use of the HTTP
232Authentication framework, but very few are well documented. Some are
233bound to transport layer connections.</t>
234
235<section title="Negotiate (GSS-API) Authentication">
236
237<t>[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP
238Authentication in Microsoft Windows" <xref target='RFC4559'/>
239goes here. ]]</t>
240
241</section>
242
243</section>
244
245</section>
246
247<section title="Centrally-Issued Tickets">
248
249<t>Many large Internet services rely on authentication schemes that
250center on clients consulting a single service for a time-limited
251ticket that is validated with undocumented heuristics. Centralized
252ticket issuing has the advantage that users may employ one set of
253credentials for many services, and clients don't send credentials to
254many servers. This approach is often no more than a sophisticated
255application of forms and cookies.</t>
256
257<t>All of the schemes in wide use are proprietary and non-standard,
258and usually are undocumented. There are many standardization efforts
259in progress, as usual.</t>
260
261</section>
262
263<section title='Web Services'>
264
265<t>Many security properties mentioned in this document have been recast in
266XML-based protocols, using HTTP as a substitute for TCP. Like the
267amalgam of HTTP technologies mentioned above, the XML-based protocols
268are defined by an ever-changing combination of standard and
269vendor-produced specifications, some of which may be obsoleted at any
270time <xref target="WS-Pagecount"/> without any documented change control
271procedures. These protocols usually don't have much in common with the
272Architecture of the World Wide Web. It's not clear why the term "Web" is
273used to group them, but they are obviously out of scope for HTTP-based
274application protocols.</t>
275
276<t>[[ This section could really use a good definition of
277"Web Services" to differentiate it from REST. ]]</t>
278
279</section>
280
281<section title="Transport Layer Security">
282
283<t>[[ A discussion of HTTP over TLS needs to be added
284here. ]]</t>
285
286<t>[[ Discussion of connection confidentiality should be separate from
287the discussion of access authentication based on mutual authentication with
288certificates in TLS. ]]</t>
289
290</section>
291
292</section>
293
294<section title="Revisions To HTTP">
295
296<t>Is is possible that HTTP will be revised in the future. "HTTP/1.1"
297<xref target="RFC2616"/> and "Use and Interpretation of HTTP Version
298Numbers" <xref target="RFC2145"/> define conformance requirements in
299relation to version numbers. In HTTP 1.1, all authentication
300mechanisms are optional, and no single transport substrate is
301specified. Any HTTP revision that adds a mandatory security mechanism
302or transport substrate will have to increment the HTTP version number
303appropriately. All widely used schemes are non-standard and/or
304proprietary.</t>
305
306</section>
307
308<section title="Security Considerations">
309
310<t>This entire document is about security considerations.</t>
311
312</section>
313
314</middle>
315
316<back>
317
318<references title='Normative References'>
319
320&rfc2026;
321&rfc2109;
322&rfc2145;
323&rfc2616;
324&rfc2617;
325&rfc2965;
326&rfc3365;
327&rfc3631;
328&rfc3986;
329&rfc4559;
330
331<reference anchor='Apache_Digest'
332  target='http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html'>
333<front>
334  <title>Apache HTTP Server - mod_auth_digest</title>
335  <author surname="Apache Software Foundation">
336  <organization />
337  </author>
338  <date/>
339</front>
340</reference>
341
342<reference anchor='PhishingHOWTO'
343  target='http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf'>
344<front>
345  <title>Phishing Tips and Techniques</title>
346  <author initials="P." surname="Gutmann" fullname="Peter Gutmann">
347  <organization /></author>
348  <date year='2008' month='February' />
349</front>
350</reference>
351
352<reference anchor='WS-Pagecount'
353  target='http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research'>
354<front>
355  <title>WS-Pagecount</title>
356  <author initials="T." surname="Bray" fullname="Tim Bray">
357  <organization />
358  </author>
359  <date year='2004' month='September' />
360</front>
361</reference>
362
363</references>
364
365<section title='Acknowledgements'>
366
367<t>Much of the material in this document was written by Rob Sayre,
368who first promoted the topic. Many others on the HTTPbis Working
369Group have contributed to this document in the discussion.</t>
370
371</section>
372
373<section title='Document History'>
374
375<t>[This entire section is to be removed when published as an RFC.]</t>
376
377<section title='Changes between draft-sayre-http-security-variance-00 and
378  draft-ietf-httpbis-security-properties-00'>
379
380<t>Changed the authors to Paul Hoffman and Alexey Melnikov, with permission
381of Rob Sayre.</t>
382
383<t>Made lots of minor editorial changes.</t>
384
385<t>Removed what was section 2 (Requirements Notation), the reference
386to RFC 2119, and any use of 2119ish all-caps words.</t>
387
388<t>In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
389repertoire" to match the definition of "TEXT" in RFC 2616.</t>
390
391<t>Added minor text to the Security Considerations section.</t>
392
393<t>Added URLs to the two non-RFC references.</t>
394
395</section>
396
397<section title='Changes between -00 and -01'>
398
399<t>Fixed some editorial nits reported by Iain Calder.</t>
400
401<t>Added the suggestions about splitting for browsers and
402automation, and about adding NTLM, to be beginning of 2.</t>
403
404<t>In 2.1, added "that involves a human
405using a web browser" in the first sentence.</t>
406
407<t>In 2.1, changed "session key" to "session identifier".</t>
408
409<t>In 2.2.2, changed
410<figure><artwork><![CDATA[
411Digest includes many modes of operation, but only the simplest modes
412enjoy any degree of interoperability.  For example, most
413implementations do not implement the mode that provides full message
414integrity.  Additionally, implementation experience has shown that
415the message integrity mode is impractical because it requires servers
416to analyze the full request before determining whether the client
417knows the shared secret.
418]]></artwork></figure>
419to
420<figure><artwork><![CDATA[
421Digest includes many modes of operation, but only the simplest
422modes enjoy any degree of interoperability.  For example, most
423implementations do not implement the mode that provides full message
424integrity.  Perhaps one reason is that implementation experience has
425shown that in some cases, especially those involving large requests
426or responses such as streams, the message integrity mode is
427impractical because it requires servers to analyze the full request
428before determining whether the client knows the shared secret or
429whether message-body integrity has been violated and hence whether
430the request can be processed.
431]]></artwork></figure>
432</t>
433
434<t>In 2.4, asked for a definition of "Web Services".</t>
435
436<t>In A, added the WG.</t>
437
438</section>
439
440</section>
441
442</back>
443
444</rfc>
445
Note: See TracBrowser for help on using the repository browser.