source: draft-ietf-httpbis-security-properties/01/draft-ietf-httpbis-security-properties-01.txt @ 2246

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

Checked in 01 of security, also modded the Makefile for my setup.

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.txt
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     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 August 25, 2008                [Page 3]
168
169Internet-Draft       Security Requirements for HTTP        February 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   HTML forms provide a facility for sites to indicate that a password
192   should never be pre-populated. [[ More needed here on autocomplete ]]
193
194   The cookies that result from a successful form submission make it
195   unnecessary to validate credentials with each HTTP request; this
196   makes cookies an excellent property for scalability.  Cookies are
197   susceptible to a large variety of XSS (cross-site scripting) attacks,
198   and measures to prevent such attacks will never be as stringent as
199   necessary for authentication credentials because cookies are used for
200   many purposes.  Cookies are also susceptible to a wide variety of
201   attacks from malicious intermediaries and observers.  The possible
202   attacks depend on the contents of the cookie data.  There is no
203   standard format for most of the data.
204
205   HTML forms and cookies provide flexible ways of ending a session from
206   the client.
207
208   HTML forms require an HTML rendering engine for which many protocols
209   have no use.
210
2112.2.  HTTP Access Authentication
212
213   HTTP 1.1 provides a simple authentication framework, "HTTP
214   Authentication: Basic and Digest Access Authentication" [RFC2617],
215   which defines two optional mechanisms.  Both of these mechanisms are
216   extremely rarely used in comparison to forms and cookies, but some
217   degree of support for one or both is available in many
218   implementations.  Neither scheme provides presentation control,
219   logout capabilities, or interoperable internationalization.
220
221
222
223Hoffman & Melnikov       Expires August 25, 2008                [Page 4]
224
225Internet-Draft       Security Requirements for HTTP        February 2008
226
227
2282.2.1.  Basic Authentication
229
230   Basic Authentication (normally called just "Basic") transmits
231   usernames and passwords in the clear.  It is very easy to implement,
232   but not at all secure unless used over a secure transport.
233
234   Basic has very poor scalability properties because credentials must
235   be revalidated with every request, and because secure transports
236   negate many of HTTP's caching mechanisms.  Some implementations use
237   cookies in combination with Basic credentials, but there is no
238   standard method of doing so.
239
240   Since Basic credentials are clear text, they are reusable by any
241   party.  This makes them compatible with any authentication database,
242   at the cost of making the user vulnerable to mismanaged or malicious
243   servers, even over a secure channel.
244
245   Basic is not interoperable when used with credentials that contain
246   characters outside of the ISO 8859-1 repertoire.
247
2482.2.2.  Digest Authentication
249
250   In Digest Authentication, the client transmits the results of hashing
251   user credentials with properties of the request and values from the
252   server challenge.  Digest is susceptible to man-in-the-middle attacks
253   when not used over a secure transport.
254
255   Digest has some properties that are preferable to Basic and Cookies.
256   Credentials are not immediately reusable by parties that observe or
257   receive them, and session data can be transmitted along side
258   credentials with each request, allowing servers to validate
259   credentials only when absolutely necessary.  Authentication data
260   session keys are distinct from other protocol traffic.
261
262   Digest includes many modes of operation, but only the simplest modes
263   enjoy any degree of interoperability.  For example, most
264   implementations do not implement the mode that provides full message
265   integrity.  Perhaps one reason is that implementation experience has
266   shown that in some cases, especially those involving large requests
267   or responses such as streams, the message integrity mode is
268   impractical because it requires servers to analyze the full request
269   before determining whether the client knows the shared secret or
270   whether message-body integrity has been violated and hence whether
271   the request can be processed.
272
273   Digest is extremely susceptible to offline dictionary attacks, making
274   it practical for attackers to perform a namespace walk consisting of
275   a few million passwords [[ CITATION NEEDED ]].
276
277
278
279Hoffman & Melnikov       Expires August 25, 2008                [Page 5]
280
281Internet-Draft       Security Requirements for HTTP        February 2008
282
283
284   Many of the most widely-deployed HTTP/1.1 clients are not compliant
285   when GET requests include a query string [Apache_Digest].
286
287   Digest either requires that authentication databases be expressly
288   designed to accommodate it, or requires access to cleartext
289   passwords.  As a result, many authentication databases that chose to
290   do the former are incompatible, including the most common method of
291   storing passwords for use with Forms and Cookies.
292
293   Many Digest capabilities included to prevent replay attacks expose
294   the server to Denial of Service attacks.
295
296   Digest is not interoperable when used with credentials that contain
297   characters outside of the ISO 8859-1 repertoire.
298
2992.2.3.  Other Access Authentication Schemes
300
301   There are many niche schemes that make use of the HTTP Authentication
302   framework, but very few are well documented.  Some are bound to
303   transport layer connections.
304
3052.2.3.1.  Negotiate (GSS-API) Authentication
306
307   [[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP
308   Authentication in Microsoft Windows" [RFC4559] goes here. ]]
309
3102.3.  Centrally-Issued Tickets
311
312   Many large Internet services rely on authentication schemes that
313   center on clients consulting a single service for a time-limited
314   ticket that is validated with undocumented heuristics.  Centralized
315   ticket issuing has the advantage that users may employ one set of
316   credentials for many services, and clients don't send credentials to
317   many servers.  This approach is often no more than a sophisticated
318   application of forms and cookies.
319
320   All of the schemes in wide use are proprietary and non-standard, and
321   usually are undocumented.  There are many standardization efforts in
322   progress, as usual.
323
3242.4.  Web Services
325
326   Many security properties mentioned in this document have been recast
327   in XML-based protocols, using HTTP as a substitute for TCP.  Like the
328   amalgam of HTTP technologies mentioned above, the XML-based protocols
329   are defined by an ever-changing combination of standard and vendor-
330   produced specifications, some of which may be obsoleted at any time
331   [WS-Pagecount] without any documented change control procedures.
332
333
334
335Hoffman & Melnikov       Expires August 25, 2008                [Page 6]
336
337Internet-Draft       Security Requirements for HTTP        February 2008
338
339
340   These protocols usually don't have much in common with the
341   Architecture of the World Wide Web. It's not clear why the term "Web"
342   is used to group them, but they are obviously out of scope for HTTP-
343   based application protocols.
344
345   [[ This section could really use a good definition of "Web Services"
346   to differentiate it from REST. ]]
347
3482.5.  Transport Layer Security
349
350   [[ A discussion of HTTP over TLS needs to be added here. ]]
351
352   [[ Discussion of connection confidentiality should be separate from
353   the discussion of access authentication based on mutual
354   authentication with certificates in TLS. ]]
355
356
3573.  Revisions To HTTP
358
359   Is is possible that HTTP will be revised in the future.  "HTTP/1.1"
360   [RFC2616] and "Use and Interpretation of HTTP Version Numbers"
361   [RFC2145] define conformance requirements in relation to version
362   numbers.  In HTTP 1.1, all authentication mechanisms are optional,
363   and no single transport substrate is specified.  Any HTTP revision
364   that adds a mandatory security mechanism or transport substrate will
365   have to increment the HTTP version number appropriately.  All widely
366   used schemes are non-standard and/or proprietary.
367
368
3694.  Security Considerations
370
371   This entire document is about security considerations.
372
373
3745.  Normative References
375
376   [Apache_Digest]
377              Apache Software Foundation, "Apache HTTP Server -
378              mod_auth_digest", <http://httpd.apache.org/docs/1.3/mod/
379              mod_auth_digest.html>.
380
381   [PhishingHOWTO]
382              Gutmann, P., "Phishing Tips and Techniques",
383              February 2008,
384              <http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf>.
385
386   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
387              3", BCP 9, RFC 2026, October 1996.
388
389
390
391Hoffman & Melnikov       Expires August 25, 2008                [Page 7]
392
393Internet-Draft       Security Requirements for HTTP        February 2008
394
395
396   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
397              Mechanism", RFC 2109, February 1997.
398
399   [RFC2145]  Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
400              and Interpretation of HTTP Version Numbers", RFC 2145,
401              May 1997.
402
403   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
404              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
405              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
406
407   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
408              Leach, P., Luotonen, A., and L. Stewart, "HTTP
409              Authentication: Basic and Digest Access Authentication",
410              RFC 2617, June 1999.
411
412   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
413              Mechanism", RFC 2965, October 2000.
414
415   [RFC3365]  Schiller, J., "Strong Security Requirements for Internet
416              Engineering Task Force Standard Protocols", BCP 61,
417              RFC 3365, August 2002.
418
419   [RFC3631]  Bellovin, S., Schiller, J., and C. Kaufman, "Security
420              Mechanisms for the Internet", RFC 3631, December 2003.
421
422   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
423              Resource Identifier (URI): Generic Syntax", STD 66,
424              RFC 3986, January 2005.
425
426   [RFC4559]  Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
427              Kerberos and NTLM HTTP Authentication in Microsoft
428              Windows", RFC 4559, June 2006.
429
430   [WS-Pagecount]
431              Bray, T., "WS-Pagecount", September 2004, <http://
432              www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>.
433
434
435Appendix A.  Acknowledgements
436
437   Much of the material in this document was written by Rob Sayre, who
438   first promoted the topic.  Many others on the HTTPbis Working Group
439   have contributed to this document in the discussion.
440
441
442
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   Digest includes many modes of operation, but only the simplest modes
489   enjoy any degree of interoperability.  For example, most
490   implementations do not implement the mode that provides full message
491   integrity.  Additionally, implementation experience has shown that
492   the message integrity mode is impractical because it requires servers
493   to analyze the full request before determining whether the client
494   knows the shared secret.
495
496   to
497
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.