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

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

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

  • Property svn:executable set to *
File size: 20.1 KB
Line 
1
2
3
4Network Working Group                                         P. Hoffman
5Internet-Draft                                            VPN Consortium
6Intended status: Informational                               A. Melnikov
7Expires: July 27, 2008                                        Isode Ltd.
8                                                        January 24, 2008
9
10
11                     Security Requirements for HTTP
12             draft-ietf-httpbis-security-properties-latest
13
14Status of this Memo
15
16   By submitting this Internet-Draft, each author represents that any
17   applicable patent or other IPR claims of which he or she is aware
18   have been or will be disclosed, and any of which he or she becomes
19   aware will be disclosed, in accordance with Section 6 of BCP 79.
20
21   Internet-Drafts are working documents of the Internet Engineering
22   Task Force (IETF), its areas, and its working groups.  Note that
23   other groups may also distribute working documents as Internet-
24   Drafts.
25
26   Internet-Drafts are draft documents valid for a maximum of six months
27   and may be updated, replaced, or obsoleted by other documents at any
28   time.  It is inappropriate to use Internet-Drafts as reference
29   material or to cite them other than as "work in progress."
30
31   The list of current Internet-Drafts can be accessed at
32   http://www.ietf.org/ietf/1id-abstracts.txt.
33
34   The list of Internet-Draft Shadow Directories can be accessed at
35   http://www.ietf.org/shadow.html.
36
37   This Internet-Draft will expire on July 27, 2008.
38
39Copyright Notice
40
41   Copyright (C) The IETF Trust (2008).
42
43Abstract
44
45   Recent IESG practice dictates that IETF protocols must specify
46   mandatory-to-implement security mechanisms, so that all conformant
47   implementations share a common baseline.  This document examines all
48   widely deployed HTTP security technologies, and analyzes the trade-
49   offs of each.
50
51
52
53
54
55Hoffman & Melnikov        Expires July 27, 2008                 [Page 1]
56
57Internet-Draft       Security Requirements for HTTP         January 2008
58
59
60Table of Contents
61
62   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
63   2.  Existing HTTP Security Mechanisms  . . . . . . . . . . . . . .  3
64     2.1.  Forms And Cookies  . . . . . . . . . . . . . . . . . . . .  3
65     2.2.  HTTP Access Authentication . . . . . . . . . . . . . . . .  4
66       2.2.1.  Basic Authentication . . . . . . . . . . . . . . . . .  4
67       2.2.2.  Digest Authentication  . . . . . . . . . . . . . . . .  5
68       2.2.3.  Other Access Authentication Schemes  . . . . . . . . .  6
69     2.3.  Centrally-Issued Tickets . . . . . . . . . . . . . . . . .  6
70     2.4.  Web Services . . . . . . . . . . . . . . . . . . . . . . .  6
71     2.5.  Transport Layer Security . . . . . . . . . . . . . . . . .  7
72   3.  Revisions To HTTP  . . . . . . . . . . . . . . . . . . . . . .  7
73   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
74   5.  Normative References . . . . . . . . . . . . . . . . . . . . .  7
75   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . .  8
76   Appendix B.  Document History  . . . . . . . . . . . . . . . . . .  8
77     B.1.  Changes between draft-sayre-http-security-variance-00
78           and   draft-ietf-http-security-properties-00 . . . . . . .  8
79   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
80   Intellectual Property and Copyright Statements . . . . . . . . . . 10
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Hoffman & Melnikov        Expires July 27, 2008                 [Page 2]
112
113Internet-Draft       Security Requirements for HTTP         January 2008
114
115
1161.  Introduction
117
118   Recent IESG practice dictates that IETF protocols are required to
119   specify mandatory to implement security mechanisms.  "The IETF
120   Standards Process" [RFC2026] does not require that protocols specify
121   mandatory security mechanisms.  "Strong Security Requirements for
122   IETF Standard Protocols" [RFC3365] requires that all IETF protocols
123   provide a mechanism for implementors to provide strong security.  RFC
124   3365 does not define the term "strong security".
125
126   "Security Mechanisms for the Internet" [RFC3631] is not an IETF
127   procedural RFC, but it is perhaps most relevant.  Section 2.2 states:
128
129
130     We have evolved in the IETF the notion of "mandatory to implement"
131     mechanisms.  This philosophy evolves from our primary desire to
132     ensure interoperability between different implementations of a
133     protocol.  If a protocol offers many options for how to perform a
134     particular task, but fails to provide for at least one that all
135     must implement, it may be possible that multiple, non-interoperable
136     implementations may result.  This is the consequence of the
137     selection of non-overlapping mechanisms being deployed in the
138     different implementations.
139
140   This document examines the effects of applying security constraints
141   to Web applications, documents the properties that result from each
142   method, and will make Best Current Practice recommendations for HTTP
143   security in a later document version.  At the moment, it is mostly a
144   laundry list of security technologies and tradeoffs.
145
146
1472.  Existing HTTP Security Mechanisms
148
149   For HTTP, the IETF generally defines "security mechanisms" as some
150   combination of access authentication and/or a secure transport.
151
1522.1.  Forms And Cookies
153
154   Almost all HTTP authentication is accomplished through HTML forms,
155   with session keys stored in cookies.  For cookies, most
156   implementations rely on the "Netscape specification", which is
157   described loosely in section 10 of "HTTP State Management Mechanism"
158   [RFC2109].  The protocol in RFC 2109 is relatively widely
159   implemented, but most clients don't advertise support for it.  RFC
160   2109 was later updated [RFC2965], but the newer version is not widely
161   implemented.
162
163   Forms and cookies have number of properties that make them an
164
165
166
167Hoffman & Melnikov        Expires July 27, 2008                 [Page 3]
168
169Internet-Draft       Security Requirements for HTTP         January 2008
170
171
172   excellent solution for some implementors.  However, many of those
173   properties introduce serious security trade-offs.
174
175   HTML forms provide a large degree of control over presentation, which
176   is an imperative for many websites.  However, this increases user
177   reliance on the appearance of the interface.  Many users do not
178   understand the construction of URIs [RFC3986], or their presentation
179   in common clients [[ CITATION NEEDED ]].  As a result, forms are
180   extremely vulnerable to spoofing.
181
182   HTML forms provide acceptable internationalization if used carefully,
183   at the cost of being transmitted as normal HTTP content in all cases
184   (credentials are not differentiated in the protocol).
185
186   HTML forms provide a facility for sites to indicate that a password
187   should never be pre-populated. [[ More needed here on autocomplete ]]
188
189   The cookies that result from a successful form submission make it
190   unessecary to validate credentials with each HTTP request; this makes
191   cookies an excellent property for scalability.  Cookies are
192   susceptible to a large variety of XSS (cross-site scripting) attacks,
193   and measures to prevent such attacks will never be as stringent as
194   necessary for authentication credentials because cookies are used for
195   many purposes.  Cookies are also susceptible to a wide variety of
196   attacks from malicious intermediaries and observers.  The possible
197   attacks depend on the contents of the cookie data.  There is no
198   standard format for most of the data.
199
200   HTML forms and cookies provide flexible ways of ending a session from
201   the client.
202
203   HTML forms require an HTML rendering engine, which many protocols
204   have no use for.
205
2062.2.  HTTP Access Authentication
207
208   HTTP 1.1 provides a simple authentication framework, and "HTTP
209   Authentication: Basic and Digest Access Authentication" [RFC2617]
210   defines two optional mechanisms.  Both of these mechanisms are
211   extremely rarely used in comparison to forms and cookies, but some
212   degree of support for one or both is available in many
213   implementations.  Neither scheme provides presentation control,
214   logout capabilities, or interoperable internationalization.
215
2162.2.1.  Basic Authentication
217
218   Basic Authentication (normally called just "Basic") transmits
219   usernames and passwords in the clear.  It is very easy to implement,
220
221
222
223Hoffman & Melnikov        Expires July 27, 2008                 [Page 4]
224
225Internet-Draft       Security Requirements for HTTP         January 2008
226
227
228   but not at all secure unless used over a secure transport.
229
230   Basic has very poor scalability properties because credentials must
231   be revalidated with every request, and because secure transports
232   negate many of HTTP's caching mechanisms.  Some implementations use
233   cookies in combination with Basic credentials, but there is no
234   standard method of doing so.
235
236   Since Basic credentials are clear text, they are reusable by any
237   party.  This makes them compatible with any authentication database,
238   at the cost of making the user vulnerable to mismanaged or malicious
239   servers, even over a secure channel.
240
241   Basic is not interoperable when used with credentials that contain
242   characters outside of the ISO 8859-1 repertoire.
243
2442.2.2.  Digest Authentication
245
246   In Digest Authentication, the client transmits the results of hashing
247   user credentials with properties of the request and values from the
248   server challenge.  Digest is susceptible to man-in-the-middle attacks
249   when not used over a secure transport.
250
251   Digest has some properties that are preferable to Basic and Cookies.
252   Credentials are not immediately reusable by parties that observe or
253   receive them, and session data can be transmitted along side
254   credentials with each request, allowing servers to validate
255   credentials only when absolutely necessary.  Authentication data
256   session keys are distinct from other protocol traffic.
257
258   Digest includes many modes of operation, but only the simplest modes
259   enjoy any degree of interoperability.  For example, most
260   implementations do not implement the mode that provides full message
261   integrity.  Additionally, implementation experience has shown that
262   the message integrity mode is impractical because it requires servers
263   to analyze the full request before determining whether the client
264   knows the shared secret.
265
266   Digest is extremely susceptible to offline dictionary attacks, making
267   it practical for attackers to perform a namespace walk consisting of
268   a few million passwords [[ CITATION NEEDED ]].
269
270   Many of the most widely-deployed HTTP/1.1 clients are not compliant
271   when GET requests include a query string [Apache_Digest].
272
273   Digest either requires that authentication databases be expressly
274   designed to accomodate it, or requires access to cleartext passwords.
275   As a result, many authentication databases that chose to do the
276
277
278
279Hoffman & Melnikov        Expires July 27, 2008                 [Page 5]
280
281Internet-Draft       Security Requirements for HTTP         January 2008
282
283
284   former are incompatible, including the most common method of storing
285   passwords for use with Forms and Cookies.
286
287   Many Digest capabilities included to prevent replay attacks expose
288   the server to Denial of Service attacks.
289
290   Digest is not interoperable when used with credentials that contain
291   characters outside of the ISO 8859-1 repertoire.
292
2932.2.3.  Other Access Authentication Schemes
294
295   There are many niche schemes that make use of the HTTP Authentication
296   framework, but very few are well documented.  Some are bound to
297   transport layer connections.
298
2992.2.3.1.  Negotiate (GSS-API) Authentication
300
301   [[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP
302   Authentication in Microsoft Windows" [RFC4559] goes here.]]
303
3042.3.  Centrally-Issued Tickets
305
306   Many large Internet services rely on authentication schemes that
307   center on clients consulting a single service for a time-limited
308   ticket that is validated with undocumented heuristics.  Centralized
309   ticket issuing has the advantage that users may employ one set of
310   credentials for many services, and clients don't send credentials to
311   many servers.  This approach is often no more than a sophisticated
312   application of forms and cookies.
313
314   All of the schemes in wide use are proprietary and non-standard, and
315   usually are undocumented.  There are many standardization efforts in
316   progress, as usual.
317
3182.4.  Web Services
319
320   Many security properties mentioned in this document have been recast
321   in XML-based protocols, using HTTP as a substitute for TCP.  Like the
322   amalgam of HTTP technologies mentioned above, the XML-based protocols
323   are defined by an ever-changing combination of standard and vendor-
324   produced specifications, some of which may be obsoleted at any time
325   [WS-Pagecount] without any documented change control procedures.
326   These protocols usually don't have much in common with the
327   Architecture of the World Wide Web. It's not clear why term "Web" is
328   used to group them, but they are obviously out of scope for HTTP-
329   based application protocols.
330
331
332
333
334
335Hoffman & Melnikov        Expires July 27, 2008                 [Page 6]
336
337Internet-Draft       Security Requirements for HTTP         January 2008
338
339
3402.5.  Transport Layer Security
341
342   [[ A discussion of HTTP over TLS needs to be added here. ]]
343
344   [[ Discussion of connection confidentiality should be separate from
345   the discussion of access authentication based on mutual
346   authentication with certificates in TLS. ]]
347
348
3493.  Revisions To HTTP
350
351   Is is possible that HTTP will be revised in the future.  "HTTP/1.1"
352   [RFC2616] and "Use and Interpretation of HTTP Version Numbers"
353   [RFC2145] define conformance requirements in relation to version
354   numbers.  In HTTP 1.1, all authentication mechanisms are optional,
355   and no single transport substrate is specified.  Any HTTP revision
356   that adds a mandatory security mechanism or transport substrate will
357   have to increment the HTTP version number appropriately.  All widely
358   used schemes are non-standard and/or proprietary.
359
360
3614.  Security Considerations
362
363   This entire document is about security considerations.
364
365
3665.  Normative References
367
368   [Apache_Digest]
369              Apache Software Foundation, "Apache HTTP Server -
370              mod_auth_digest", <http://httpd.apache.org/docs/1.3/mod/
371              mod_auth_digest.html>.
372
373   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
374              3", BCP 9, RFC 2026, October 1996.
375
376   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
377              Mechanism", RFC 2109, February 1997.
378
379   [RFC2145]  Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
380              and Interpretation of HTTP Version Numbers", RFC 2145,
381              May 1997.
382
383   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
384              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
385              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
386
387   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
388
389
390
391Hoffman & Melnikov        Expires July 27, 2008                 [Page 7]
392
393Internet-Draft       Security Requirements for HTTP         January 2008
394
395
396              Leach, P., Luotonen, A., and L. Stewart, "HTTP
397              Authentication: Basic and Digest Access Authentication",
398              RFC 2617, June 1999.
399
400   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
401              Mechanism", RFC 2965, October 2000.
402
403   [RFC3365]  Schiller, J., "Strong Security Requirements for Internet
404              Engineering Task Force Standard Protocols", BCP 61,
405              RFC 3365, August 2002.
406
407   [RFC3631]  Bellovin, S., Schiller, J., and C. Kaufman, "Security
408              Mechanisms for the Internet", RFC 3631, December 2003.
409
410   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
411              Resource Identifier (URI): Generic Syntax", STD 66,
412              RFC 3986, January 2005.
413
414   [RFC4559]  Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
415              Kerberos and NTLM HTTP Authentication in Microsoft
416              Windows", RFC 4559, June 2006.
417
418   [WS-Pagecount]
419              Bray, T., "WS-Pagecount", September 2004, <http://
420              www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>.
421
422
423Appendix A.  Acknowledgements
424
425   Much of the material in this document was written by Rob Sayre, who
426   first promoted the topic.
427
428
429Appendix B.  Document History
430
431   [This entire section is to be removed when published as an RFC.]
432
433B.1.  Changes between draft-sayre-http-security-variance-00 and
434      draft-ietf-http-security-properties-00
435
436   Changed the authors to Paul Hoffman and Alexey Melnikov, with
437   permission of Rob Sayre.
438
439   Made lots of minor editorial changes.
440
441   Removed what was section 2 (Requirements Notation), the reference to
442   RFC 2119, and any use of 2119ish all-caps words.
443
444
445
446
447Hoffman & Melnikov        Expires July 27, 2008                 [Page 8]
448
449Internet-Draft       Security Requirements for HTTP         January 2008
450
451
452   In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
453   repertoire" to match the defintion of "TEXT" in RFC 2616.
454
455   Added minor text to the Security Considerations section.
456
457   Added URLs to the two non-RFC references.
458
459
460Authors' Addresses
461
462   Paul Hoffman
463   VPN Consortium
464
465   Email: paul.hoffman@vpnc.org
466
467
468   Alexey Melnikov
469   Isode Ltd.
470
471   Email: alexey.melnikov@isode.com
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503Hoffman & Melnikov        Expires July 27, 2008                 [Page 9]
504
505Internet-Draft       Security Requirements for HTTP         January 2008
506
507
508Full Copyright Statement
509
510   Copyright (C) The IETF Trust (2008).
511
512   This document is subject to the rights, licenses and restrictions
513   contained in BCP 78, and except as set forth therein, the authors
514   retain all their rights.
515
516   This document and the information contained herein are provided on an
517   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
518   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
519   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
520   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
521   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
522   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
523
524
525Intellectual Property
526
527   The IETF takes no position regarding the validity or scope of any
528   Intellectual Property Rights or other rights that might be claimed to
529   pertain to the implementation or use of the technology described in
530   this document or the extent to which any license under such rights
531   might or might not be available; nor does it represent that it has
532   made any independent effort to identify any such rights.  Information
533   on the procedures with respect to rights in RFC documents can be
534   found in BCP 78 and BCP 79.
535
536   Copies of IPR disclosures made to the IETF Secretariat and any
537   assurances of licenses to be made available, or the result of an
538   attempt made to obtain a general license or permission for the use of
539   such proprietary rights by implementers or users of this
540   specification can be obtained from the IETF on-line IPR repository at
541   http://www.ietf.org/ipr.
542
543   The IETF invites any interested party to bring to its attention any
544   copyrights, patents or patent applications, or other proprietary
545   rights that may cover technology that may be required to implement
546   this standard.  Please address the information to the IETF at
547   ietf-ipr@ietf.org.
548
549
550Acknowledgment
551
552   Funding for the RFC Editor function is provided by the IETF
553   Administrative Support Activity (IASA).
554
555
556
557
558
559Hoffman & Melnikov        Expires July 27, 2008                [Page 10]
560
Note: See TracBrowser for help on using the repository browser.