source: draft-ietf-httpbis-security-properties/03/draft-ietf-httpbis-security-properties.txt @ 551

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

Reflect publication of draft 03 in svn.

File size: 24.4 KB
Line 
1
2
3
4Network Working Group                                         P. Hoffman
5Internet-Draft                                            VPN Consortium
6Intended status: Informational                               A. Melnikov
7Expires: September 8, 2009                                    Isode Ltd.
8                                                           March 7, 2009
9
10
11                     Security Requirements for HTTP
12               draft-ietf-httpbis-security-properties-03
13
14Status of this Memo
15
16   This Internet-Draft is submitted to IETF in full conformance with the
17   provisions of BCP 78 and BCP 79.  This document may contain material
18   from IETF Documents or IETF Contributions published or made publicly
19   available before November 10, 2008.  The person(s) controlling the
20   copyright in some of this material may not have granted the IETF
21   Trust the right to allow modifications of such material outside the
22   IETF Standards Process.  Without obtaining an adequate license from
23   the person(s) controlling the copyright in such materials, this
24   document may not be modified outside the IETF Standards Process, and
25   derivative works of it may not be created outside the IETF Standards
26   Process, except to format it for publication as an RFC or to
27   translate it into languages other than English.
28
29   Internet-Drafts are working documents of the Internet Engineering
30   Task Force (IETF), its areas, and its working groups.  Note that
31   other groups may also distribute working documents as Internet-
32   Drafts.
33
34   Internet-Drafts are draft documents valid for a maximum of six months
35   and may be updated, replaced, or obsoleted by other documents at any
36   time.  It is inappropriate to use Internet-Drafts as reference
37   material or to cite them other than as "work in progress."
38
39   The list of current Internet-Drafts can be accessed at
40   http://www.ietf.org/ietf/1id-abstracts.txt.
41
42   The list of Internet-Draft Shadow Directories can be accessed at
43   http://www.ietf.org/shadow.html.
44
45   This Internet-Draft will expire on September 8, 2009.
46
47Copyright Notice
48
49   Copyright (c) 2009 IETF Trust and the persons identified as the
50   document authors.  All rights reserved.
51
52
53
54
55Hoffman & Melnikov      Expires September 8, 2009               [Page 1]
56
57Internet-Draft       Security Requirements for HTTP           March 2009
58
59
60   This document is subject to BCP 78 and the IETF Trust's Legal
61   Provisions Relating to IETF Documents in effect on the date of
62   publication of this document (http://trustee.ietf.org/license-info).
63   Please review these documents carefully, as they describe your rights
64   and restrictions with respect to this document.
65
66Abstract
67
68   Recent IESG practice dictates that IETF protocols must specify
69   mandatory-to-implement security mechanisms, so that all conformant
70   implementations share a common baseline.  This document examines all
71   widely deployed HTTP security technologies, and analyzes the trade-
72   offs of each.
73
74
75Table of Contents
76
77   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
78   2.  Existing HTTP Security Mechanisms  . . . . . . . . . . . . . .  3
79     2.1.  Forms And Cookies  . . . . . . . . . . . . . . . . . . . .  3
80     2.2.  HTTP Access Authentication . . . . . . . . . . . . . . . .  5
81       2.2.1.  Basic Authentication . . . . . . . . . . . . . . . . .  5
82       2.2.2.  Digest Authentication  . . . . . . . . . . . . . . . .  5
83       2.2.3.  Authentication Using Certificates in TLS . . . . . . .  6
84       2.2.4.  Other Access Authentication Schemes  . . . . . . . . .  6
85     2.3.  Centrally-Issued Tickets . . . . . . . . . . . . . . . . .  7
86     2.4.  Web Services . . . . . . . . . . . . . . . . . . . . . . .  7
87     2.5.  Transport Layer Security . . . . . . . . . . . . . . . . .  8
88   3.  Revisions To HTTP  . . . . . . . . . . . . . . . . . . . . . .  8
89   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
90   5.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
91   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . .  9
92   Appendix B.  Document History  . . . . . . . . . . . . . . . . . . 10
93     B.1.  Changes between draft-sayre-http-security-variance-00
94           and   draft-ietf-httpbis-security-properties-00  . . . . . 10
95     B.2.  Changes between -00 and -01  . . . . . . . . . . . . . . . 10
96     B.3.  Changes between -01 and -02  . . . . . . . . . . . . . . . 11
97   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
98
99
100
101
102
103
104
105
106
107
108
109
110
111Hoffman & Melnikov      Expires September 8, 2009               [Page 2]
112
113Internet-Draft       Security Requirements for HTTP           March 2009
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
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
152   [[ There is a suggestion that this section be split into "browser-
153   like" and "automation-like" subsections. ]]
154
155   [[ NTLM (shudder) was brought up in the WG a few times in the
156   discussion of the -00 draft.  Should we add a section on it? ]]
157
1582.1.  Forms And Cookies
159
160   Almost all HTTP authentication that involves a human using a web
161   browser is accomplished through HTML forms, with session identifiers
162   stored in cookies.  For cookies, most implementations rely on the
163   "Netscape specification", which is described loosely in section 10 of
164
165
166
167Hoffman & Melnikov      Expires September 8, 2009               [Page 3]
168
169Internet-Draft       Security Requirements for HTTP           March 2009
170
171
172   "HTTP State Management Mechanism" [RFC2109].  The protocol in RFC
173   2109 is relatively widely implemented, but most clients don't
174   advertise support for it.  RFC 2109 was later updated [RFC2965], but
175   the newer version is not widely implemented.
176
177   Forms and cookies have many properties that make them an excellent
178   solution for some implementers.  However, many of those properties
179   introduce serious security trade-offs.
180
181   HTML forms provide a large degree of control over presentation, which
182   is an imperative for many websites.  However, this increases user
183   reliance on the appearance of the interface.  Many users do not
184   understand the construction of URIs [RFC3986], or their presentation
185   in common clients [PhishingHOWTO].  As a result, forms are extremely
186   vulnerable to spoofing.
187
188   HTML forms provide acceptable internationalization if used carefully,
189   at the cost of being transmitted as normal HTTP content in all cases
190   (credentials are not differentiated in the protocol).
191
192   Many Web browsers have an auto-complete feature that stores a user's
193   information and pre-populates fields in forms.  This is considered to
194   be a convenience mechanism, and convenience mechanisms often have
195   negative security properties.  The security concerns with auto-
196   completion are particularly poignant for web browsers that reside on
197   computers with multiple users.  HTML forms provide a facility for
198   sites to indicate that a field, such as a password, should never be
199   pre-populated.  However, it is clear that some form creators do not
200   use this facility when they should.
201
202   The cookies that result from a successful form submission make it
203   unnecessary to validate credentials with each HTTP request; this
204   makes cookies an excellent property for scalability.  Cookies are
205   susceptible to a large variety of XSS (cross-site scripting) attacks,
206   and measures to prevent such attacks will never be as stringent as
207   necessary for authentication credentials because cookies are used for
208   many purposes.  Cookies are also susceptible to a wide variety of
209   attacks from malicious intermediaries and observers.  The possible
210   attacks depend on the contents of the cookie data.  There is no
211   standard format for most of the data.
212
213   HTML forms and cookies provide flexible ways of ending a session from
214   the client.
215
216   HTML forms require an HTML rendering engine for which many protocols
217   have no use.
218
219
220
221
222
223Hoffman & Melnikov      Expires September 8, 2009               [Page 4]
224
225Internet-Draft       Security Requirements for HTTP           March 2009
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 September 8, 2009               [Page 5]
280
281Internet-Draft       Security Requirements for HTTP           March 2009
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 September 8, 2009               [Page 6]
336
337Internet-Draft       Security Requirements for HTTP           March 2009
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 September 8, 2009               [Page 7]
392
393Internet-Draft       Security Requirements for HTTP           March 2009
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 September 8, 2009               [Page 8]
448
449Internet-Draft       Security Requirements for HTTP           March 2009
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 September 8, 2009               [Page 9]
504
505Internet-Draft       Security Requirements for HTTP           March 2009
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
545   Digest includes many modes of operation, but only the simplest modes
546   enjoy any degree of interoperability.  For example, most
547   implementations do not implement the mode that provides full message
548   integrity.  Additionally, implementation experience has shown that
549   the message integrity mode is impractical because it requires servers
550   to analyze the full request before determining whether the client
551   knows the shared secret.
552
553   to
554
555
556
557
558
559Hoffman & Melnikov      Expires September 8, 2009              [Page 10]
560
561Internet-Draft       Security Requirements for HTTP           March 2009
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 September 8, 2009              [Page 11]
616
Note: See TracBrowser for help on using the repository browser.