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

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

add build infrastructure and -latest version for security properties document.

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