source: draft-ietf-httpbis-security-properties/02/draft-ietf-httpbis-security-properties-02.txt @ 1929

Last change on this file since 1929 was 278, checked in by paul.hoffman@…, 12 years ago

Turned in security-properties-02, failed to make the stuff in "latest".

File size: 25.2 KB
Line 
1
2
3
4Network Working Group                                         P. Hoffman
5Internet-Draft                                            VPN Consortium
6Intended status: Informational                               A. Melnikov
7Expires: January 14, 2009                                     Isode Ltd.
8                                                           July 13, 2008
9
10
11                     Security Requirements for HTTP
12               draft-ietf-httpbis-security-properties-02
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 January 14, 2009.
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 January 14, 2009                [Page 1]
56
57Internet-Draft       Security Requirements for HTTP            July 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 . . . . . . . . . . . . . . . .  5
66       2.2.1.  Basic Authentication . . . . . . . . . . . . . . . . .  5
67       2.2.2.  Digest Authentication  . . . . . . . . . . . . . . . .  5
68       2.2.3.  Authentication Using Certificates in TLS . . . . . . .  6
69       2.2.4.  Other Access Authentication Schemes  . . . . . . . . .  6
70     2.3.  Centrally-Issued Tickets . . . . . . . . . . . . . . . . .  7
71     2.4.  Web Services . . . . . . . . . . . . . . . . . . . . . . .  7
72     2.5.  Transport Layer Security . . . . . . . . . . . . . . . . .  8
73   3.  Revisions To HTTP  . . . . . . . . . . . . . . . . . . . . . .  8
74   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
75   5.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
76   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . .  9
77   Appendix B.  Document History  . . . . . . . . . . . . . . . . . . 10
78     B.1.  Changes between draft-sayre-http-security-variance-00
79           and draft-ietf-httpbis-security-properties-00  . . . . . . 10
80     B.2.  Changes between -00 and -01  . . . . . . . . . . . . . . . 10
81     B.3.  Changes between -01 and -02  . . . . . . . . . . . . . . . 11
82   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
83   Intellectual Property and Copyright Statements . . . . . . . . . . 12
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 January 14, 2009                [Page 2]
112
113Internet-Draft       Security Requirements for HTTP            July 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 implementers 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     We have evolved in the IETF the notion of "mandatory to implement"
130     mechanisms.  This philosophy evolves from our primary desire to
131     ensure interoperability between different implementations of a
132     protocol.  If a protocol offers many options for how to perform a
133     particular task, but fails to provide for at least one that all
134     must implement, it may be possible that multiple, non-interoperable
135     implementations may result.  This is the consequence of the
136     selection of non-overlapping mechanisms being deployed in the
137     different implementations.
138
139   This document examines the effects of applying security constraints
140   to Web applications, documents the properties that result from each
141   method, and will make Best Current Practice recommendations for HTTP
142   security in a later document version.  At the moment, it is mostly a
143   laundry list of security technologies and tradeoffs.
144
145
1462.  Existing HTTP Security Mechanisms
147
148   For HTTP, the IETF generally defines "security mechanisms" as some
149   combination of access authentication and/or a secure transport.
150
151   [[ There is a suggestion that this section be split into "browser-
152   like" and "automation-like" subsections. ]]
153
154   [[ NTLM (shudder) was brought up in the WG a few times in the
155   discussion of the -00 draft.  Should we add a section on it? ]]
156
1572.1.  Forms And Cookies
158
159   Almost all HTTP authentication that involves a human using a web
160   browser is accomplished through HTML forms, with session identifiers
161   stored in cookies.  For cookies, most implementations rely on the
162   "Netscape specification", which is described loosely in section 10 of
163   "HTTP State Management Mechanism" [RFC2109].  The protocol in RFC
164
165
166
167Hoffman & Melnikov      Expires January 14, 2009                [Page 3]
168
169Internet-Draft       Security Requirements for HTTP            July 2008
170
171
172   2109 is relatively widely implemented, but most clients don't
173   advertise support for it.  RFC 2109 was later updated [RFC2965], but
174   the newer version is not widely implemented.
175
176   Forms and cookies have many properties that make them an excellent
177   solution for some implementers.  However, many of those properties
178   introduce serious security trade-offs.
179
180   HTML forms provide a large degree of control over presentation, which
181   is an imperative for many websites.  However, this increases user
182   reliance on the appearance of the interface.  Many users do not
183   understand the construction of URIs [RFC3986], or their presentation
184   in common clients [PhishingHOWTO].  As a result, forms are extremely
185   vulnerable to spoofing.
186
187   HTML forms provide acceptable internationalization if used carefully,
188   at the cost of being transmitted as normal HTTP content in all cases
189   (credentials are not differentiated in the protocol).
190
191   Many Web browsers have an auto-complete feature that stores a user's
192   information and pre-populates fields in forms.  This is considered to
193   be a convenience mechanism, and convenience mechanisms often have
194   negative security properties.  The security concerns with auto-
195   completion are particularly poignant for web browsers that reside on
196   computers with multiple users.  HTML forms provide a facility for
197   sites to indicate that a field, such as a password, should never be
198   pre-populated.  However, it is clear that some form creators do not
199   use this facility when they should.
200
201   The cookies that result from a successful form submission make it
202   unnecessary to validate credentials with each HTTP request; this
203   makes cookies an excellent property for scalability.  Cookies are
204   susceptible to a large variety of XSS (cross-site scripting) attacks,
205   and measures to prevent such attacks will never be as stringent as
206   necessary for authentication credentials because cookies are used for
207   many purposes.  Cookies are also susceptible to a wide variety of
208   attacks from malicious intermediaries and observers.  The possible
209   attacks depend on the contents of the cookie data.  There is no
210   standard format for most of the data.
211
212   HTML forms and cookies provide flexible ways of ending a session from
213   the client.
214
215   HTML forms require an HTML rendering engine for which many protocols
216   have no use.
217
218
219
220
221
222
223Hoffman & Melnikov      Expires January 14, 2009                [Page 4]
224
225Internet-Draft       Security Requirements for HTTP            July 2008
226
227
2282.2.  HTTP Access Authentication
229
230   HTTP 1.1 provides a simple authentication framework, "HTTP
231   Authentication: Basic and Digest Access Authentication" [RFC2617],
232   which defines two optional mechanisms.  Both of these mechanisms are
233   extremely rarely used in comparison to forms and cookies, but some
234   degree of support for one or both is available in many
235   implementations.  Neither scheme provides presentation control,
236   logout capabilities, or interoperable internationalization.
237
2382.2.1.  Basic Authentication
239
240   Basic Authentication (normally called just "Basic") transmits
241   usernames and passwords in the clear.  It is very easy to implement,
242   but not at all secure unless used over a secure transport.
243
244   Basic has very poor scalability properties because credentials must
245   be revalidated with every request, and because secure transports
246   negate many of HTTP's caching mechanisms.  Some implementations use
247   cookies in combination with Basic credentials, but there is no
248   standard method of doing so.
249
250   Since Basic credentials are clear text, they are reusable by any
251   party.  This makes them compatible with any authentication database,
252   at the cost of making the user vulnerable to mismanaged or malicious
253   servers, even over a secure channel.
254
255   Basic is not interoperable when used with credentials that contain
256   characters outside of the ISO 8859-1 repertoire.
257
2582.2.2.  Digest Authentication
259
260   In Digest Authentication, the client transmits the results of hashing
261   user credentials with properties of the request and values from the
262   server challenge.  Digest is susceptible to man-in-the-middle attacks
263   when not used over a secure transport.
264
265   Digest has some properties that are preferable to Basic and Cookies.
266   Credentials are not immediately reusable by parties that observe or
267   receive them, and session data can be transmitted along side
268   credentials with each request, allowing servers to validate
269   credentials only when absolutely necessary.  Authentication data
270   session keys are distinct from other protocol traffic.
271
272   Digest includes many modes of operation, but only the simplest modes
273   enjoy any degree of interoperability.  For example, most
274   implementations do not implement the mode that provides full message
275   integrity.  Perhaps one reason is that implementation experience has
276
277
278
279Hoffman & Melnikov      Expires January 14, 2009                [Page 5]
280
281Internet-Draft       Security Requirements for HTTP            July 2008
282
283
284   shown that in some cases, especially those involving large requests
285   or responses such as streams, the message integrity mode is
286   impractical because it requires servers to analyze the full request
287   before determining whether the client knows the shared secret or
288   whether message-body integrity has been violated and hence whether
289   the request can be processed.
290
291   Digest is extremely susceptible to offline dictionary attacks, making
292   it practical for attackers to perform a namespace walk consisting of
293   a few million passwords for most users.
294
295   Many of the most widely-deployed HTTP/1.1 clients are not compliant
296   when GET requests include a query string [Apache_Digest].
297
298   Digest either requires that authentication databases be expressly
299   designed to accommodate it, or requires access to cleartext
300   passwords.  As a result, many authentication databases that chose to
301   do the former are incompatible, including the most common method of
302   storing passwords for use with Forms and Cookies.
303
304   Many Digest capabilities included to prevent replay attacks expose
305   the server to Denial of Service attacks.
306
307   Digest is not interoperable when used with credentials that contain
308   characters outside of the ISO 8859-1 repertoire.
309
3102.2.3.  Authentication Using Certificates in TLS
311
312   Running HTTP over TLS provides authentication of the HTTP server to
313   the client.  HTTP over TLS can also provides authentication of the
314   client to the server using certificates.  Although forms are a much
315   more common way to authenticate users to HTTP servers, TLS client
316   certificates are widely used in some environments.  The public key
317   infrastructure (PKI) used to validate certificates in TLS can be
318   rooted in public trust anchors or can be based on local trust
319   anchors.
320
3212.2.4.  Other Access Authentication Schemes
322
323   There are many niche schemes that make use of the HTTP Authentication
324   framework, but very few are well documented.  Some are bound to
325   transport layer connections.
326
3272.2.4.1.  Negotiate (GSS-API) Authentication
328
329   Microsoft has designed an HTTP authentication mechanism that utilizes
330   SPNEGO [RFC4178] GSSAPI [RFC4559].  In Microsoft's implementation,
331   SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan
332
333
334
335Hoffman & Melnikov      Expires January 14, 2009                [Page 6]
336
337Internet-Draft       Security Requirements for HTTP            July 2008
338
339
340   Manager protocols).
341
342   In Kerberos, clients and servers rely on a trusted third-party
343   authentication service which maintains its own authentication
344   database.  Kerberos is typically used with shared secret key
345   cryptography, but extensions for use of other authentication
346   mechnanisms such as PKIX certificates and two-factor tokens are also
347   common.  Kerberos was designed to work under the assumption that
348   packets traveling along the network can be read, modified, and
349   inserted at will.
350
351   Unlike Digest, Negotiate authentication can take multiple round trips
352   (client sending authentication data in Authorization, server sending
353   authentication data in WWW-Authenticate) to complete.
354
355   Kerberos authentication is generally more secure than Digest.
356   However the requirement for having a separate network authentication
357   service might be a barrier to deployment.
358
3592.3.  Centrally-Issued Tickets
360
361   Many large Internet services rely on authentication schemes that
362   center on clients consulting a single service for a time-limited
363   ticket that is validated with undocumented heuristics.  Centralized
364   ticket issuing has the advantage that users may employ one set of
365   credentials for many services, and clients don't send credentials to
366   many servers.  This approach is often no more than a sophisticated
367   application of forms and cookies.
368
369   All of the schemes in wide use are proprietary and non-standard, and
370   usually are undocumented.  There are many standardization efforts in
371   progress, as usual.
372
3732.4.  Web Services
374
375   Many security properties mentioned in this document have been recast
376   in XML-based protocols, using HTTP as a substitute for TCP.  Like the
377   amalgam of HTTP technologies mentioned above, the XML-based protocols
378   are defined by an ever-changing combination of standard and vendor-
379   produced specifications, some of which may be obsoleted at any time
380   [WS-Pagecount] without any documented change control procedures.
381   These protocols usually don't have much in common with the
382   Architecture of the World Wide Web. It's not clear why the term "Web"
383   is used to group them, but they are obviously out of scope for HTTP-
384   based application protocols.
385
386   [[ This section could really use a good definition of "Web Services"
387   to differentiate it from REST. ]]
388
389
390
391Hoffman & Melnikov      Expires January 14, 2009                [Page 7]
392
393Internet-Draft       Security Requirements for HTTP            July 2008
394
395
3962.5.  Transport Layer Security
397
398   In addition to using TLS for client and/or server authentication, it
399   is also very commonly used to protect the confidentiality and
400   integrity of the HTTP session.  For instance, both HTTP Basic
401   authentication and Cookies are often protected against snooping by
402   TLS.
403
404   It should be noted that, in that case, TLS does not protect against a
405   breach of the credential store at the server or against a keylogger
406   or phishing interface at the client.  TLS does not change the fact
407   that Basic Authentication passwords are reusable and does not address
408   that weakness.
409
410
4113.  Revisions To HTTP
412
413   Is is possible that HTTP will be revised in the future.  "HTTP/1.1"
414   [RFC2616] and "Use and Interpretation of HTTP Version Numbers"
415   [RFC2145] define conformance requirements in relation to version
416   numbers.  In HTTP 1.1, all authentication mechanisms are optional,
417   and no single transport substrate is specified.  Any HTTP revision
418   that adds a mandatory security mechanism or transport substrate will
419   have to increment the HTTP version number appropriately.  All widely
420   used schemes are non-standard and/or proprietary.
421
422
4234.  Security Considerations
424
425   This entire document is about security considerations.
426
427
4285.  Normative References
429
430   [Apache_Digest]
431              Apache Software Foundation, "Apache HTTP Server -
432              mod_auth_digest", <http://httpd.apache.org/docs/1.3/mod/
433              mod_auth_digest.html>.
434
435   [PhishingHOWTO]
436              Gutmann, P., "Phishing Tips and Techniques",
437              February 2008,
438              <http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf>.
439
440   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
441              3", BCP 9, RFC 2026, October 1996.
442
443   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
444
445
446
447Hoffman & Melnikov      Expires January 14, 2009                [Page 8]
448
449Internet-Draft       Security Requirements for HTTP            July 2008
450
451
452              Mechanism", RFC 2109, February 1997.
453
454   [RFC2145]  Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
455              and Interpretation of HTTP Version Numbers", RFC 2145,
456              May 1997.
457
458   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
459              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
460              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
461
462   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
463              Leach, P., Luotonen, A., and L. Stewart, "HTTP
464              Authentication: Basic and Digest Access Authentication",
465              RFC 2617, June 1999.
466
467   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
468              Mechanism", RFC 2965, October 2000.
469
470   [RFC3365]  Schiller, J., "Strong Security Requirements for Internet
471              Engineering Task Force Standard Protocols", BCP 61,
472              RFC 3365, August 2002.
473
474   [RFC3631]  Bellovin, S., Schiller, J., and C. Kaufman, "Security
475              Mechanisms for the Internet", RFC 3631, December 2003.
476
477   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
478              Resource Identifier (URI): Generic Syntax", STD 66,
479              RFC 3986, January 2005.
480
481   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
482              Simple and Protected Generic Security Service Application
483              Program Interface (GSS-API) Negotiation Mechanism",
484              RFC 4178, October 2005.
485
486   [RFC4559]  Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
487              Kerberos and NTLM HTTP Authentication in Microsoft
488              Windows", RFC 4559, June 2006.
489
490   [WS-Pagecount]
491              Bray, T., "WS-Pagecount", September 2004, <http://
492              www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>.
493
494
495Appendix A.  Acknowledgements
496
497   Much of the material in this document was written by Rob Sayre, who
498   first promoted the topic.  Many others on the HTTPbis Working Group
499   have contributed to this document in the discussion.
500
501
502
503Hoffman & Melnikov      Expires January 14, 2009                [Page 9]
504
505Internet-Draft       Security Requirements for HTTP            July 2008
506
507
508Appendix B.  Document History
509
510   [This entire section is to be removed when published as an RFC.]
511
512B.1.  Changes between draft-sayre-http-security-variance-00 and
513      draft-ietf-httpbis-security-properties-00
514
515   Changed the authors to Paul Hoffman and Alexey Melnikov, with
516   permission of Rob Sayre.
517
518   Made lots of minor editorial changes.
519
520   Removed what was section 2 (Requirements Notation), the reference to
521   RFC 2119, and any use of 2119ish all-caps words.
522
523   In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
524   repertoire" to match the definition of "TEXT" in RFC 2616.
525
526   Added minor text to the Security Considerations section.
527
528   Added URLs to the two non-RFC references.
529
530B.2.  Changes between -00 and -01
531
532   Fixed some editorial nits reported by Iain Calder.
533
534   Added the suggestions about splitting for browsers and automation,
535   and about adding NTLM, to be beginning of 2.
536
537   In 2.1, added "that involves a human using a web browser" in the
538   first sentence.
539
540   In 2.1, changed "session key" to "session identifier".
541
542   In 2.2.2, changed
543
544   Digest includes many modes of operation, but only the simplest modes
545   enjoy any degree of interoperability.  For example, most
546   implementations do not implement the mode that provides full message
547   integrity.  Additionally, implementation experience has shown that
548   the message integrity mode is impractical because it requires servers
549   to analyze the full request before determining whether the client
550   knows the shared secret.
551
552   to
553
554
555
556
557
558
559Hoffman & Melnikov      Expires January 14, 2009               [Page 10]
560
561Internet-Draft       Security Requirements for HTTP            July 2008
562
563
564   Digest includes many modes of operation, but only the simplest
565   modes enjoy any degree of interoperability.  For example, most
566   implementations do not implement the mode that provides full message
567   integrity.  Perhaps one reason is that implementation experience has
568   shown that in some cases, especially those involving large requests
569   or responses such as streams, the message integrity mode is
570   impractical because it requires servers to analyze the full request
571   before determining whether the client knows the shared secret or
572   whether message-body integrity has been violated and hence whether
573   the request can be processed.
574
575   In 2.4, asked for a definition of "Web Services".
576
577   In A, added the WG.
578
579B.3.  Changes between -01 and -02
580
581   In section 2.1, added more to the paragraph on auto-completion of
582   HTML forms.
583
584   Added the section on TLS for authentication.
585
586   Filled in section 2.5.
587
588
589Authors' Addresses
590
591   Paul Hoffman
592   VPN Consortium
593
594   Email: paul.hoffman@vpnc.org
595
596
597   Alexey Melnikov
598   Isode Ltd.
599
600   Email: alexey.melnikov@isode.com
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615Hoffman & Melnikov      Expires January 14, 2009               [Page 11]
616
617Internet-Draft       Security Requirements for HTTP            July 2008
618
619
620Full Copyright Statement
621
622   Copyright (C) The IETF Trust (2008).
623
624   This document is subject to the rights, licenses and restrictions
625   contained in BCP 78, and except as set forth therein, the authors
626   retain all their rights.
627
628   This document and the information contained herein are provided on an
629   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
630   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
631   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
632   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
633   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
634   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
635
636
637Intellectual Property
638
639   The IETF takes no position regarding the validity or scope of any
640   Intellectual Property Rights or other rights that might be claimed to
641   pertain to the implementation or use of the technology described in
642   this document or the extent to which any license under such rights
643   might or might not be available; nor does it represent that it has
644   made any independent effort to identify any such rights.  Information
645   on the procedures with respect to rights in RFC documents can be
646   found in BCP 78 and BCP 79.
647
648   Copies of IPR disclosures made to the IETF Secretariat and any
649   assurances of licenses to be made available, or the result of an
650   attempt made to obtain a general license or permission for the use of
651   such proprietary rights by implementers or users of this
652   specification can be obtained from the IETF on-line IPR repository at
653   http://www.ietf.org/ipr.
654
655   The IETF invites any interested party to bring to its attention any
656   copyrights, patents or patent applications, or other proprietary
657   rights that may cover technology that may be required to implement
658   this standard.  Please address the information to the IETF at
659   ietf-ipr@ietf.org.
660
661
662Acknowledgment
663
664   Funding for the RFC Editor function is provided by the IETF
665   Administrative Support Activity (IASA).
666
667
668
669
670
671Hoffman & Melnikov      Expires January 14, 2009               [Page 12]
672
Note: See TracBrowser for help on using the repository browser.