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

Last change on this file since 220 was 220, checked in by paul.hoffman@…, 11 years ago

With a few nits from Julian

File size: 22.2 KB
Line 
1
2
3
4Network Working Group                                         P. Hoffman
5Internet-Draft                                            VPN Consortium
6Intended status: Informational                               A. Melnikov
7Expires: August 25, 2008                                      Isode Ltd.
8                                                       February 22, 2008
9
10
11                     Security Requirements for HTTP
12               draft-ietf-httpbis-security-properties-01
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 August 25, 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 August 25, 2008                [Page 1]
56
57Internet-Draft       Security Requirements for HTTP        February 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 . . . . . . . . . . . . . . . . .  5
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  . . . . . . . . . . . . . . . . . .  9
77     B.1.  Changes between draft-sayre-http-security-variance-00
78           and   draft-ietf-httpbis-security-properties-00  . . . . .  9
79     B.2.  Changes between -00 and -01  . . . . . . . . . . . . . . .  9
80   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
81   Intellectual Property and Copyright Statements . . . . . . . . . . 11
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 August 25, 2008                [Page 2]
112
113Internet-Draft       Security Requirements for HTTP        February 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
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 August 25, 2008                [Page 3]
168
169Internet-Draft       Security Requirements for HTTP        February 2008
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   HTML forms provide a facility for sites to indicate that a password
193   should never be pre-populated. [[ More needed here on autocomplete ]]
194
195   The cookies that result from a successful form submission make it
196   unnecessary to validate credentials with each HTTP request; this
197   makes cookies an excellent property for scalability.  Cookies are
198   susceptible to a large variety of XSS (cross-site scripting) attacks,
199   and measures to prevent such attacks will never be as stringent as
200   necessary for authentication credentials because cookies are used for
201   many purposes.  Cookies are also susceptible to a wide variety of
202   attacks from malicious intermediaries and observers.  The possible
203   attacks depend on the contents of the cookie data.  There is no
204   standard format for most of the data.
205
206   HTML forms and cookies provide flexible ways of ending a session from
207   the client.
208
209   HTML forms require an HTML rendering engine for which many protocols
210   have no use.
211
2122.2.  HTTP Access Authentication
213
214   HTTP 1.1 provides a simple authentication framework, "HTTP
215   Authentication: Basic and Digest Access Authentication" [RFC2617],
216   which defines two optional mechanisms.  Both of these mechanisms are
217   extremely rarely used in comparison to forms and cookies, but some
218   degree of support for one or both is available in many
219   implementations.  Neither scheme provides presentation control,
220
221
222
223Hoffman & Melnikov       Expires August 25, 2008                [Page 4]
224
225Internet-Draft       Security Requirements for HTTP        February 2008
226
227
228   logout capabilities, or interoperable internationalization.
229
2302.2.1.  Basic Authentication
231
232   Basic Authentication (normally called just "Basic") transmits
233   usernames and passwords in the clear.  It is very easy to implement,
234   but not at all secure unless used over a secure transport.
235
236   Basic has very poor scalability properties because credentials must
237   be revalidated with every request, and because secure transports
238   negate many of HTTP's caching mechanisms.  Some implementations use
239   cookies in combination with Basic credentials, but there is no
240   standard method of doing so.
241
242   Since Basic credentials are clear text, they are reusable by any
243   party.  This makes them compatible with any authentication database,
244   at the cost of making the user vulnerable to mismanaged or malicious
245   servers, even over a secure channel.
246
247   Basic is not interoperable when used with credentials that contain
248   characters outside of the ISO 8859-1 repertoire.
249
2502.2.2.  Digest Authentication
251
252   In Digest Authentication, the client transmits the results of hashing
253   user credentials with properties of the request and values from the
254   server challenge.  Digest is susceptible to man-in-the-middle attacks
255   when not used over a secure transport.
256
257   Digest has some properties that are preferable to Basic and Cookies.
258   Credentials are not immediately reusable by parties that observe or
259   receive them, and session data can be transmitted along side
260   credentials with each request, allowing servers to validate
261   credentials only when absolutely necessary.  Authentication data
262   session keys are distinct from other protocol traffic.
263
264   Digest includes many modes of operation, but only the simplest modes
265   enjoy any degree of interoperability.  For example, most
266   implementations do not implement the mode that provides full message
267   integrity.  Perhaps one reason is that implementation experience has
268   shown that in some cases, especially those involving large requests
269   or responses such as streams, the message integrity mode is
270   impractical because it requires servers to analyze the full request
271   before determining whether the client knows the shared secret or
272   whether message-body integrity has been violated and hence whether
273   the request can be processed.
274
275   Digest is extremely susceptible to offline dictionary attacks, making
276
277
278
279Hoffman & Melnikov       Expires August 25, 2008                [Page 5]
280
281Internet-Draft       Security Requirements for HTTP        February 2008
282
283
284   it practical for attackers to perform a namespace walk consisting of
285   a few million passwords [[ CITATION NEEDED ]].
286
287   Many of the most widely-deployed HTTP/1.1 clients are not compliant
288   when GET requests include a query string [Apache_Digest].
289
290   Digest either requires that authentication databases be expressly
291   designed to accommodate it, or requires access to cleartext
292   passwords.  As a result, many authentication databases that chose to
293   do the former are incompatible, including the most common method of
294   storing passwords for use with Forms and Cookies.
295
296   Many Digest capabilities included to prevent replay attacks expose
297   the server to Denial of Service attacks.
298
299   Digest is not interoperable when used with credentials that contain
300   characters outside of the ISO 8859-1 repertoire.
301
3022.2.3.  Other Access Authentication Schemes
303
304   There are many niche schemes that make use of the HTTP Authentication
305   framework, but very few are well documented.  Some are bound to
306   transport layer connections.
307
3082.2.3.1.  Negotiate (GSS-API) Authentication
309
310   [[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP
311   Authentication in Microsoft Windows" [RFC4559] goes here. ]]
312
3132.3.  Centrally-Issued Tickets
314
315   Many large Internet services rely on authentication schemes that
316   center on clients consulting a single service for a time-limited
317   ticket that is validated with undocumented heuristics.  Centralized
318   ticket issuing has the advantage that users may employ one set of
319   credentials for many services, and clients don't send credentials to
320   many servers.  This approach is often no more than a sophisticated
321   application of forms and cookies.
322
323   All of the schemes in wide use are proprietary and non-standard, and
324   usually are undocumented.  There are many standardization efforts in
325   progress, as usual.
326
3272.4.  Web Services
328
329   Many security properties mentioned in this document have been recast
330   in XML-based protocols, using HTTP as a substitute for TCP.  Like the
331   amalgam of HTTP technologies mentioned above, the XML-based protocols
332
333
334
335Hoffman & Melnikov       Expires August 25, 2008                [Page 6]
336
337Internet-Draft       Security Requirements for HTTP        February 2008
338
339
340   are defined by an ever-changing combination of standard and vendor-
341   produced specifications, some of which may be obsoleted at any time
342   [WS-Pagecount] without any documented change control procedures.
343   These protocols usually don't have much in common with the
344   Architecture of the World Wide Web. It's not clear why the term "Web"
345   is used to group them, but they are obviously out of scope for HTTP-
346   based application protocols.
347
348   [[ This section could really use a good definition of "Web Services"
349   to differentiate it from REST. ]]
350
3512.5.  Transport Layer Security
352
353   [[ A discussion of HTTP over TLS needs to be added here. ]]
354
355   [[ Discussion of connection confidentiality should be separate from
356   the discussion of access authentication based on mutual
357   authentication with certificates in TLS. ]]
358
359
3603.  Revisions To HTTP
361
362   Is is possible that HTTP will be revised in the future.  "HTTP/1.1"
363   [RFC2616] and "Use and Interpretation of HTTP Version Numbers"
364   [RFC2145] define conformance requirements in relation to version
365   numbers.  In HTTP 1.1, all authentication mechanisms are optional,
366   and no single transport substrate is specified.  Any HTTP revision
367   that adds a mandatory security mechanism or transport substrate will
368   have to increment the HTTP version number appropriately.  All widely
369   used schemes are non-standard and/or proprietary.
370
371
3724.  Security Considerations
373
374   This entire document is about security considerations.
375
376
3775.  Normative References
378
379   [Apache_Digest]
380              Apache Software Foundation, "Apache HTTP Server -
381              mod_auth_digest", <http://httpd.apache.org/docs/1.3/mod/
382              mod_auth_digest.html>.
383
384   [PhishingHOWTO]
385              Gutmann, P., "Phishing Tips and Techniques",
386              February 2008,
387              <http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf>.
388
389
390
391Hoffman & Melnikov       Expires August 25, 2008                [Page 7]
392
393Internet-Draft       Security Requirements for HTTP        February 2008
394
395
396   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
397              3", BCP 9, RFC 2026, October 1996.
398
399   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
400              Mechanism", RFC 2109, February 1997.
401
402   [RFC2145]  Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
403              and Interpretation of HTTP Version Numbers", RFC 2145,
404              May 1997.
405
406   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
407              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
408              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
409
410   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
411              Leach, P., Luotonen, A., and L. Stewart, "HTTP
412              Authentication: Basic and Digest Access Authentication",
413              RFC 2617, June 1999.
414
415   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
416              Mechanism", RFC 2965, October 2000.
417
418   [RFC3365]  Schiller, J., "Strong Security Requirements for Internet
419              Engineering Task Force Standard Protocols", BCP 61,
420              RFC 3365, August 2002.
421
422   [RFC3631]  Bellovin, S., Schiller, J., and C. Kaufman, "Security
423              Mechanisms for the Internet", RFC 3631, December 2003.
424
425   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
426              Resource Identifier (URI): Generic Syntax", STD 66,
427              RFC 3986, January 2005.
428
429   [RFC4559]  Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
430              Kerberos and NTLM HTTP Authentication in Microsoft
431              Windows", RFC 4559, June 2006.
432
433   [WS-Pagecount]
434              Bray, T., "WS-Pagecount", September 2004, <http://
435              www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>.
436
437
438Appendix A.  Acknowledgements
439
440   Much of the material in this document was written by Rob Sayre, who
441   first promoted the topic.  Many others on the HTTPbis Working Group
442   have contributed to this document in the discussion.
443
444
445
446
447Hoffman & Melnikov       Expires August 25, 2008                [Page 8]
448
449Internet-Draft       Security Requirements for HTTP        February 2008
450
451
452Appendix B.  Document History
453
454   [This entire section is to be removed when published as an RFC.]
455
456B.1.  Changes between draft-sayre-http-security-variance-00 and
457      draft-ietf-httpbis-security-properties-00
458
459   Changed the authors to Paul Hoffman and Alexey Melnikov, with
460   permission of Rob Sayre.
461
462   Made lots of minor editorial changes.
463
464   Removed what was section 2 (Requirements Notation), the reference to
465   RFC 2119, and any use of 2119ish all-caps words.
466
467   In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
468   repertoire" to match the definition of "TEXT" in RFC 2616.
469
470   Added minor text to the Security Considerations section.
471
472   Added URLs to the two non-RFC references.
473
474B.2.  Changes between -00 and -01
475
476   Fixed some editorial nits reported by Iain Calder.
477
478   Added the suggestions about splitting for browsers and automation,
479   and about adding NTLM, to be beginning of 2.
480
481   In 2.1, added "that involves a human using a web browser" in the
482   first sentence.
483
484   In 2.1, changed "session key" to "session identifier".
485
486   In 2.2.2, changed
487
488
489   Digest includes many modes of operation, but only the simplest modes
490   enjoy any degree of interoperability.  For example, most
491   implementations do not implement the mode that provides full message
492   integrity.  Additionally, implementation experience has shown that
493   the message integrity mode is impractical because it requires servers
494   to analyze the full request before determining whether the client
495   knows the shared secret.
496
497   to
498
499
500
501
502
503Hoffman & Melnikov       Expires August 25, 2008                [Page 9]
504
505Internet-Draft       Security Requirements for HTTP        February 2008
506
507
508   Digest includes many modes of operation, but only the simplest
509   modes enjoy any degree of interoperability.  For example, most
510   implementations do not implement the mode that provides full message
511   integrity.  Perhaps one reason is that implementation experience has
512   shown that in some cases, especially those involving large requests
513   or responses such as streams, the message integrity mode is
514   impractical because it requires servers to analyze the full request
515   before determining whether the client knows the shared secret or
516   whether message-body integrity has been violated and hence whether
517   the request can be processed.
518
519   In 2.4, asked for a definition of "Web Services".
520
521   In A, added the WG.
522
523
524Authors' Addresses
525
526   Paul Hoffman
527   VPN Consortium
528
529   Email: paul.hoffman@vpnc.org
530
531
532   Alexey Melnikov
533   Isode Ltd.
534
535   Email: alexey.melnikov@isode.com
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559Hoffman & Melnikov       Expires August 25, 2008               [Page 10]
560
561Internet-Draft       Security Requirements for HTTP        February 2008
562
563
564Full Copyright Statement
565
566   Copyright (C) The IETF Trust (2008).
567
568   This document is subject to the rights, licenses and restrictions
569   contained in BCP 78, and except as set forth therein, the authors
570   retain all their rights.
571
572   This document and the information contained herein are provided on an
573   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
574   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
575   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
576   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
577   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
578   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
579
580
581Intellectual Property
582
583   The IETF takes no position regarding the validity or scope of any
584   Intellectual Property Rights or other rights that might be claimed to
585   pertain to the implementation or use of the technology described in
586   this document or the extent to which any license under such rights
587   might or might not be available; nor does it represent that it has
588   made any independent effort to identify any such rights.  Information
589   on the procedures with respect to rights in RFC documents can be
590   found in BCP 78 and BCP 79.
591
592   Copies of IPR disclosures made to the IETF Secretariat and any
593   assurances of licenses to be made available, or the result of an
594   attempt made to obtain a general license or permission for the use of
595   such proprietary rights by implementers or users of this
596   specification can be obtained from the IETF on-line IPR repository at
597   http://www.ietf.org/ipr.
598
599   The IETF invites any interested party to bring to its attention any
600   copyrights, patents or patent applications, or other proprietary
601   rights that may cover technology that may be required to implement
602   this standard.  Please address the information to the IETF at
603   ietf-ipr@ietf.org.
604
605
606Acknowledgment
607
608   Funding for the RFC Editor function is provided by the IETF
609   Administrative Support Activity (IASA).
610
611
612
613
614
615Hoffman & Melnikov       Expires August 25, 2008               [Page 11]
616
Note: See TracBrowser for help on using the repository browser.