source: draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.xml @ 279

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

remove *.redxml from Subversion, remove SYSTEM identifier, rebuild HTML version

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