draft-ietf-httpbis-security-properties-00.txt   draft-ietf-httpbis-security-properties-01.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Informational A. Melnikov Intended status: Informational A. Melnikov
Expires: July 26, 2008 Isode Ltd. Expires: August 25, 2008 Isode Ltd.
January 23, 2008 February 22, 2008
Security Requirements for HTTP Security Requirements for HTTP
draft-ietf-httpbis-security-properties-00.txt draft-ietf-httpbis-security-properties-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 26, 2008. This Internet-Draft will expire on August 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Recent IESG practice dictates that IETF protocols must specify Recent IESG practice dictates that IETF protocols must specify
mandatory-to-implement security mechanisms, so that all conformant mandatory-to-implement security mechanisms, so that all conformant
implementations share a common baseline. This document examines all implementations share a common baseline. This document examines all
widely deployed HTTP security technologies, and analyzes the trade- widely deployed HTTP security technologies, and analyzes the trade-
offs of each. offs of each.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 3 2. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 3
2.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 3 2.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 3
2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 4 2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 4
2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 4 2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 5
2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 5 2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 5
2.2.3. Other Access Authentication Schemes . . . . . . . . . 6 2.2.3. Other Access Authentication Schemes . . . . . . . . . 6
2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 6 2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 6
2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 6
2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 6 2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 7
3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 7 3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 5. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
Appendix B. Document History . . . . . . . . . . . . . . . . . . 8 Appendix B. Document History . . . . . . . . . . . . . . . . . . 9
B.1. Changes between draft-sayre-http-security-variance-00 B.1. Changes between draft-sayre-http-security-variance-00
and draft-ietf-http-security-properties-00 . . . . . . . . 8 and draft-ietf-httpbis-security-properties-00 . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Introduction 1. Introduction
Recent IESG practice dictates that IETF protocols are required to Recent IESG practice dictates that IETF protocols are required to
specify mandatory to implement security mechanisms. "The IETF specify mandatory to implement security mechanisms. "The IETF
Standards Process" [RFC2026] does not require that protocols specify Standards Process" [RFC2026] does not require that protocols specify
mandatory security mechanisms. "Strong Security Requirements for mandatory security mechanisms. "Strong Security Requirements for
IETF Standard Protocols" [RFC3365] requires that all IETF protocols IETF Standard Protocols" [RFC3365] requires that all IETF protocols
provide a mechanism for implementors to provide strong security. RFC provide a mechanism for implementers to provide strong security. RFC
3365 does not define the term "strong security". 3365 does not define the term "strong security".
"Security Mechanisms for the Internet" [RFC3631] is not an IETF "Security Mechanisms for the Internet" [RFC3631] is not an IETF
procedural RFC, but it is perhaps most relevant. Section 2.2 states: procedural RFC, but it is perhaps most relevant. Section 2.2 states:
We have evolved in the IETF the notion of "mandatory to implement" We have evolved in the IETF the notion of "mandatory to implement"
mechanisms. This philosophy evolves from our primary desire to mechanisms. This philosophy evolves from our primary desire to
ensure interoperability between different implementations of a ensure interoperability between different implementations of a
protocol. If a protocol offers many options for how to perform a protocol. If a protocol offers many options for how to perform a
particular task, but fails to provide for at least one that all particular task, but fails to provide for at least one that all
skipping to change at page 3, line 39 skipping to change at page 3, line 39
to Web applications, documents the properties that result from each to Web applications, documents the properties that result from each
method, and will make Best Current Practice recommendations for HTTP method, and will make Best Current Practice recommendations for HTTP
security in a later document version. At the moment, it is mostly a security in a later document version. At the moment, it is mostly a
laundry list of security technologies and tradeoffs. laundry list of security technologies and tradeoffs.
2. Existing HTTP Security Mechanisms 2. Existing HTTP Security Mechanisms
For HTTP, the IETF generally defines "security mechanisms" as some For HTTP, the IETF generally defines "security mechanisms" as some
combination of access authentication and/or a secure transport. combination of access authentication and/or a secure transport.
[[ There is a suggestion that this section be split into "browser-
like" and "automation-like" subsections. ]]
[[ NTLM (shudder) was brought up in the WG a few times in the
discussion of the -00 draft. Should we add a section on it? ]]
2.1. Forms And Cookies 2.1. Forms And Cookies
Almost all HTTP authentication is accomplished through HTML forms, Almost all HTTP authentication that involves a human using a web
with session keys stored in cookies. For cookies, most browser is accomplished through HTML forms, with session identifiers
implementations rely on the "Netscape specification", which is stored in cookies. For cookies, most implementations rely on the
described loosely in section 10 of "HTTP State Management Mechanism" "Netscape specification", which is described loosely in section 10 of
[RFC2109]. The protocol in RFC 2109 is relatively widely "HTTP State Management Mechanism" [RFC2109]. The protocol in RFC
implemented, but most clients don't advertise support for it. RFC 2109 is relatively widely implemented, but most clients don't
2109 was later updated [RFC2965], but the newer version is not widely advertise support for it. RFC 2109 was later updated [RFC2965], but
implemented. the newer version is not widely implemented.
Forms and cookies have number of properties that make them an Forms and cookies have many properties that make them an excellent
excellent solution for some implementors. However, many of those solution for some implementers. However, many of those properties
properties introduce serious security trade-offs. introduce serious security trade-offs.
HTML forms provide a large degree of control over presentation, which HTML forms provide a large degree of control over presentation, which
is an imperative for many websites. However, this increases user is an imperative for many websites. However, this increases user
reliance on the appearance of the interface. Many users do not reliance on the appearance of the interface. Many users do not
understand the construction of URIs [RFC3986], or their presentation understand the construction of URIs [RFC3986], or their presentation
in common clients [[ CITATION NEEDED ]]. As a result, forms are in common clients [PhishingHOWTO]. As a result, forms are extremely
extremely vulnerable to spoofing. vulnerable to spoofing.
HTML forms provide acceptable internationalization if used carefully, HTML forms provide acceptable internationalization if used carefully,
at the cost of being transmitted as normal HTTP content in all cases at the cost of being transmitted as normal HTTP content in all cases
(credentials are not differentiated in the protocol). (credentials are not differentiated in the protocol).
HTML forms provide a facility for sites to indicate that a password HTML forms provide a facility for sites to indicate that a password
should never be pre-populated. [[ More needed here on autocomplete ]] should never be pre-populated. [[ More needed here on autocomplete ]]
The cookies that result from a successful form submission make it The cookies that result from a successful form submission make it
unessecary to validate credentials with each HTTP request; this makes unnecessary to validate credentials with each HTTP request; this
cookies an excellent property for scalability. Cookies are makes cookies an excellent property for scalability. Cookies are
susceptible to a large variety of XSS (cross-site scripting) attacks, susceptible to a large variety of XSS (cross-site scripting) attacks,
and measures to prevent such attacks will never be as stringent as and measures to prevent such attacks will never be as stringent as
necessary for authentication credentials because cookies are used for necessary for authentication credentials because cookies are used for
many purposes. Cookies are also susceptible to a wide variety of many purposes. Cookies are also susceptible to a wide variety of
attacks from malicious intermediaries and observers. The possible attacks from malicious intermediaries and observers. The possible
attacks depend on the contents of the cookie data. There is no attacks depend on the contents of the cookie data. There is no
standard format for most of the data. standard format for most of the data.
HTML forms and cookies provide flexible ways of ending a session from HTML forms and cookies provide flexible ways of ending a session from
the client. the client.
HTML forms require an HTML rendering engine, which many protocols HTML forms require an HTML rendering engine for which many protocols
have no use for. have no use.
2.2. HTTP Access Authentication 2.2. HTTP Access Authentication
HTTP 1.1 provides a simple authentication framework, and "HTTP HTTP 1.1 provides a simple authentication framework, "HTTP
Authentication: Basic and Digest Access Authentication" [RFC2617] Authentication: Basic and Digest Access Authentication" [RFC2617],
defines two optional mechanisms. Both of these mechanisms are which defines two optional mechanisms. Both of these mechanisms are
extremely rarely used in comparison to forms and cookies, but some extremely rarely used in comparison to forms and cookies, but some
degree of support for one or both is available in many degree of support for one or both is available in many
implementations. Neither scheme provides presentation control, implementations. Neither scheme provides presentation control,
logout capabilities, or interoperable internationalization. logout capabilities, or interoperable internationalization.
2.2.1. Basic Authentication 2.2.1. Basic Authentication
Basic Authentication (normally called just "Basic") transmits Basic Authentication (normally called just "Basic") transmits
usernames and passwords in the clear. It is very easy to implement, usernames and passwords in the clear. It is very easy to implement,
but not at all secure unless used over a secure transport. but not at all secure unless used over a secure transport.
skipping to change at page 5, line 36 skipping to change at page 5, line 42
Digest has some properties that are preferable to Basic and Cookies. Digest has some properties that are preferable to Basic and Cookies.
Credentials are not immediately reusable by parties that observe or Credentials are not immediately reusable by parties that observe or
receive them, and session data can be transmitted along side receive them, and session data can be transmitted along side
credentials with each request, allowing servers to validate credentials with each request, allowing servers to validate
credentials only when absolutely necessary. Authentication data credentials only when absolutely necessary. Authentication data
session keys are distinct from other protocol traffic. session keys are distinct from other protocol traffic.
Digest includes many modes of operation, but only the simplest modes Digest includes many modes of operation, but only the simplest modes
enjoy any degree of interoperability. For example, most enjoy any degree of interoperability. For example, most
implementations do not implement the mode that provides full message implementations do not implement the mode that provides full message
integrity. Additionally, implementation experience has shown that integrity. Perhaps one reason is that implementation experience has
the message integrity mode is impractical because it requires servers shown that in some cases, especially those involving large requests
to analyze the full request before determining whether the client or responses such as streams, the message integrity mode is
knows the shared secret. impractical because it requires servers to analyze the full request
before determining whether the client knows the shared secret or
whether message-body integrity has been violated and hence whether
the request can be processed.
Digest is extremely susceptible to offline dictionary attacks, making Digest is extremely susceptible to offline dictionary attacks, making
it practical for attackers to perform a namespace walk consisting of it practical for attackers to perform a namespace walk consisting of
a few million passwords [[ CITATION NEEDED ]]. a few million passwords [[ CITATION NEEDED ]].
Many of the most widely-deployed HTTP/1.1 clients are not compliant Many of the most widely-deployed HTTP/1.1 clients are not compliant
when GET requests include a query string [Apache_Digest]. when GET requests include a query string [Apache_Digest].
Digest either requires that authentication databases be expressly Digest either requires that authentication databases be expressly
designed to accomodate it, or requires access to cleartext passwords. designed to accommodate it, or requires access to cleartext
As a result, many authentication databases that chose to do the passwords. As a result, many authentication databases that chose to
former are incompatible, including the most common method of storing do the former are incompatible, including the most common method of
passwords for use with Forms and Cookies. storing passwords for use with Forms and Cookies.
Many Digest capabilities included to prevent replay attacks expose Many Digest capabilities included to prevent replay attacks expose
the server to Denial of Service attacks. the server to Denial of Service attacks.
Digest is not interoperable when used with credentials that contain Digest is not interoperable when used with credentials that contain
characters outside of the ISO 8859-1 repertoire. characters outside of the ISO 8859-1 repertoire.
2.2.3. Other Access Authentication Schemes 2.2.3. Other Access Authentication Schemes
There are many niche schemes that make use of the HTTP Authentication There are many niche schemes that make use of the HTTP Authentication
skipping to change at page 6, line 44 skipping to change at page 7, line 4
progress, as usual. progress, as usual.
2.4. Web Services 2.4. Web Services
Many security properties mentioned in this document have been recast Many security properties mentioned in this document have been recast
in XML-based protocols, using HTTP as a substitute for TCP. Like the in XML-based protocols, using HTTP as a substitute for TCP. Like the
amalgam of HTTP technologies mentioned above, the XML-based protocols amalgam of HTTP technologies mentioned above, the XML-based protocols
are defined by an ever-changing combination of standard and vendor- are defined by an ever-changing combination of standard and vendor-
produced specifications, some of which may be obsoleted at any time produced specifications, some of which may be obsoleted at any time
[WS-Pagecount] without any documented change control procedures. [WS-Pagecount] without any documented change control procedures.
These protocols usually don't have much in common with the These protocols usually don't have much in common with the
Architecture of the World Wide Web. It's not clear why term "Web" is Architecture of the World Wide Web. It's not clear why the term "Web"
used to group them, but they are obviously out of scope for HTTP- is used to group them, but they are obviously out of scope for HTTP-
based application protocols. based application protocols.
[[ This section could really use a good definition of "Web Services"
to differentiate it from REST. ]]
2.5. Transport Layer Security 2.5. Transport Layer Security
[[ A discussion of HTTP over TLS needs to be added here. ]] [[ A discussion of HTTP over TLS needs to be added here. ]]
[[ Discussion of connection confidentiality should be separate from [[ Discussion of connection confidentiality should be separate from
the discussion of access authentication based on mutual the discussion of access authentication based on mutual
authentication with certificates in TLS. ]] authentication with certificates in TLS. ]]
3. Revisions To HTTP 3. Revisions To HTTP
Is is possible that HTTP will be revised in the future. "HTTP/1.1" Is is possible that HTTP will be revised in the future. "HTTP/1.1"
[RFC2616] and "Use and Interpretation of HTTP Version Numbers" [RFC2616] and "Use and Interpretation of HTTP Version Numbers"
[RFC2145] define conformance requirements in relation to version [RFC2145] define conformance requirements in relation to version
numbers. In HTTP 1.1, all authentication mechanisms are optional, numbers. In HTTP 1.1, all authentication mechanisms are optional,
skipping to change at page 7, line 30 skipping to change at page 7, line 43
This entire document is about security considerations. This entire document is about security considerations.
5. Normative References 5. Normative References
[Apache_Digest] [Apache_Digest]
Apache Software Foundation, "Apache HTTP Server - Apache Software Foundation, "Apache HTTP Server -
mod_auth_digest", <http://httpd.apache.org/docs/1.3/mod/ mod_auth_digest", <http://httpd.apache.org/docs/1.3/mod/
mod_auth_digest.html>. mod_auth_digest.html>.
[PhishingHOWTO]
Gutmann, P., "Phishing Tips and Techniques",
February 2008,
<http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997. Mechanism", RFC 2109, February 1997.
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
and Interpretation of HTTP Version Numbers", RFC 2145, and Interpretation of HTTP Version Numbers", RFC 2145,
May 1997. May 1997.
skipping to change at page 8, line 30 skipping to change at page 8, line 46
Kerberos and NTLM HTTP Authentication in Microsoft Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, June 2006. Windows", RFC 4559, June 2006.
[WS-Pagecount] [WS-Pagecount]
Bray, T., "WS-Pagecount", September 2004, <http:// Bray, T., "WS-Pagecount", September 2004, <http://
www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>. www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Much of the material in this document was written by Rob Sayre, who Much of the material in this document was written by Rob Sayre, who
first promoted the topic. first promoted the topic. Many others on the HTTPbis Working Group
have contributed to this document in the discussion.
Appendix B. Document History Appendix B. Document History
[This entire section is to be removed when published as an RFC.] [This entire section is to be removed when published as an RFC.]
B.1. Changes between draft-sayre-http-security-variance-00 and B.1. Changes between draft-sayre-http-security-variance-00 and
draft-ietf-http-security-properties-00 draft-ietf-httpbis-security-properties-00
Changed the authors to Paul Hoffman and Alexey Melnikov, with Changed the authors to Paul Hoffman and Alexey Melnikov, with
permission of Rob Sayre. permission of Rob Sayre.
Made lots of minor editorial changes. Made lots of minor editorial changes.
Removed what was section 2 (Requirements Notation), the reference to Removed what was section 2 (Requirements Notation), the reference to
RFC 2119, and any use of 2119ish all-caps words. RFC 2119, and any use of 2119ish all-caps words.
In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
repertoire" to match the defintion of "TEXT" in RFC 2616. repertoire" to match the definition of "TEXT" in RFC 2616.
Added minor text to the Security Considerations section. Added minor text to the Security Considerations section.
Added URLs to the two non-RFC references. Added URLs to the two non-RFC references.
B.2. Changes between -00 and -01
Fixed some editorial nits reported by Iain Calder.
Added the suggestions about splitting for browsers and automation,
and about adding NTLM, to be beginning of 2.
In 2.1, added "that involves a human using a web browser" in the
first sentence.
In 2.1, changed "session key" to "session identifier".
In 2.2.2, changed
Digest includes many modes of operation, but only the simplest modes
enjoy any degree of interoperability. For example, most
implementations do not implement the mode that provides full message
integrity. Additionally, implementation experience has shown that
the message integrity mode is impractical because it requires servers
to analyze the full request before determining whether the client
knows the shared secret.
to
Digest includes many modes of operation, but only the simplest
modes enjoy any degree of interoperability. For example, most
implementations do not implement the mode that provides full message
integrity. Perhaps one reason is that implementation experience has
shown that in some cases, especially those involving large requests
or responses such as streams, the message integrity mode is
impractical because it requires servers to analyze the full request
before determining whether the client knows the shared secret or
whether message-body integrity has been violated and hence whether
the request can be processed.
In 2.4, asked for a definition of "Web Services".
In A, added the WG.
Authors' Addresses Authors' Addresses
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
Alexey Melnikov Alexey Melnikov
Isode Ltd. Isode Ltd.
 End of changes. 26 change blocks. 
44 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/