< draft-ietf-httpbis-security-properties-01.txt   draft-ietf-httpbis-security-properties-02.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: August 25, 2008 Isode Ltd. Expires: January 14, 2009 Isode Ltd.
February 22, 2008 July 13, 2008
Security Requirements for HTTP Security Requirements for HTTP
draft-ietf-httpbis-security-properties-01.txt draft-ietf-httpbis-security-properties-02
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 August 25, 2008. This Internet-Draft will expire on January 14, 2009.
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 . . . . . . . . . . . . . . . . 5
2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 5 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. Authentication Using Certificates in TLS . . . . . . . 6
2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 6 2.2.4. Other Access Authentication Schemes . . . . . . . . . 6
2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 7
2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 7 2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 7
3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 8
5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. Document History . . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9
Appendix B. Document History . . . . . . . . . . . . . . . . . . 10
B.1. Changes between draft-sayre-http-security-variance-00 B.1. Changes between draft-sayre-http-security-variance-00
and draft-ietf-httpbis-security-properties-00 . . . . . . 9 and draft-ietf-httpbis-security-properties-00 . . . . . . 10
B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 9 B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 B.3. Changes between -01 and -02 . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
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 implementers 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".
skipping to change at page 4, line 23 skipping to change at page 4, line 23
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 [PhishingHOWTO]. As a result, forms are extremely in common clients [PhishingHOWTO]. As a result, forms are 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 Many Web browsers have an auto-complete feature that stores a user's
should never be pre-populated. [[ More needed here on autocomplete ]] information and pre-populates fields in forms. This is considered to
be a convenience mechanism, and convenience mechanisms often have
negative security properties. The security concerns with auto-
completion are particularly poignant for web browsers that reside on
computers with multiple users. HTML forms provide a facility for
sites to indicate that a field, such as a password, should never be
pre-populated. However, it is clear that some form creators do not
use this facility when they should.
The cookies that result from a successful form submission make it The cookies that result from a successful form submission make it
unnecessary to validate credentials with each HTTP request; this unnecessary to validate credentials with each HTTP request; this
makes 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
skipping to change at page 5, line 52 skipping to change at page 6, line 13
integrity. Perhaps one reason is that implementation experience has integrity. Perhaps one reason is that implementation experience has
shown that in some cases, especially those involving large requests shown that in some cases, especially those involving large requests
or responses such as streams, the message integrity mode is or responses such as streams, the message integrity mode is
impractical because it requires servers to analyze the full request impractical because it requires servers to analyze the full request
before determining whether the client knows the shared secret or before determining whether the client knows the shared secret or
whether message-body integrity has been violated and hence whether whether message-body integrity has been violated and hence whether
the request can be processed. 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 for most users.
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 accommodate it, or requires access to cleartext designed to accommodate it, or requires access to cleartext
passwords. As a result, many authentication databases that chose to passwords. As a result, many authentication databases that chose to
do the former are incompatible, including the most common method of do the former are incompatible, including the most common method of
storing 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. Authentication Using Certificates in TLS
Running HTTP over TLS provides authentication of the HTTP server to
the client. HTTP over TLS can also provides authentication of the
client to the server using certificates. Although forms are a much
more common way to authenticate users to HTTP servers, TLS client
certificates are widely used in some environments. The public key
infrastructure (PKI) used to validate certificates in TLS can be
rooted in public trust anchors or can be based on local trust
anchors.
2.2.4. 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
framework, but very few are well documented. Some are bound to framework, but very few are well documented. Some are bound to
transport layer connections. transport layer connections.
2.2.3.1. Negotiate (GSS-API) Authentication 2.2.4.1. Negotiate (GSS-API) Authentication
[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP Microsoft has designed an HTTP authentication mechanism that utilizes
Authentication in Microsoft Windows" [RFC4559] goes here. ]] SPNEGO [RFC4178] GSSAPI [RFC4559]. In Microsoft's implementation,
SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan
Manager protocols).
In Kerberos, clients and servers rely on a trusted third-party
authentication service which maintains its own authentication
database. Kerberos is typically used with shared secret key
cryptography, but extensions for use of other authentication
mechnanisms such as PKIX certificates and two-factor tokens are also
common. Kerberos was designed to work under the assumption that
packets traveling along the network can be read, modified, and
inserted at will.
Unlike Digest, Negotiate authentication can take multiple round trips
(client sending authentication data in Authorization, server sending
authentication data in WWW-Authenticate) to complete.
Kerberos authentication is generally more secure than Digest.
However the requirement for having a separate network authentication
service might be a barrier to deployment.
2.3. Centrally-Issued Tickets 2.3. Centrally-Issued Tickets
Many large Internet services rely on authentication schemes that Many large Internet services rely on authentication schemes that
center on clients consulting a single service for a time-limited center on clients consulting a single service for a time-limited
ticket that is validated with undocumented heuristics. Centralized ticket that is validated with undocumented heuristics. Centralized
ticket issuing has the advantage that users may employ one set of ticket issuing has the advantage that users may employ one set of
credentials for many services, and clients don't send credentials to credentials for many services, and clients don't send credentials to
many servers. This approach is often no more than a sophisticated many servers. This approach is often no more than a sophisticated
application of forms and cookies. application of forms and cookies.
skipping to change at page 7, line 4 skipping to change at page 7, line 45
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 the term "Web" Architecture of the World Wide Web. It's not clear why the term "Web"
is 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" [[ This section could really use a good definition of "Web Services"
to differentiate it from REST. ]] 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. ]] In addition to using TLS for client and/or server authentication, it
is also very commonly used to protect the confidentiality and
integrity of the HTTP session. For instance, both HTTP Basic
authentication and Cookies are often protected against snooping by
TLS.
[[ Discussion of connection confidentiality should be separate from It should be noted that, in that case, TLS does not protect against a
the discussion of access authentication based on mutual breach of the credential store at the server or against a keylogger
authentication with certificates in TLS. ]] or phishing interface at the client. TLS does not change the fact
that Basic Authentication passwords are reusable and does not address
that weakness.
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,
and no single transport substrate is specified. Any HTTP revision and no single transport substrate is specified. Any HTTP revision
that adds a mandatory security mechanism or transport substrate will that adds a mandatory security mechanism or transport substrate will
have to increment the HTTP version number appropriately. All widely have to increment the HTTP version number appropriately. All widely
skipping to change at page 8, line 35 skipping to change at page 9, line 33
Engineering Task Force Standard Protocols", BCP 61, Engineering Task Force Standard Protocols", BCP 61,
RFC 3365, August 2002. RFC 3365, August 2002.
[RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security
Mechanisms for the Internet", RFC 3631, December 2003. Mechanisms for the Internet", RFC 3631, December 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
Simple and Protected Generic Security Service Application
Program Interface (GSS-API) Negotiation Mechanism",
RFC 4178, October 2005.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
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
skipping to change at page 10, line 19 skipping to change at page 11, line 19
or responses such as streams, the message integrity mode is or responses such as streams, the message integrity mode is
impractical because it requires servers to analyze the full request impractical because it requires servers to analyze the full request
before determining whether the client knows the shared secret or before determining whether the client knows the shared secret or
whether message-body integrity has been violated and hence whether whether message-body integrity has been violated and hence whether
the request can be processed. the request can be processed.
In 2.4, asked for a definition of "Web Services". In 2.4, asked for a definition of "Web Services".
In A, added the WG. In A, added the WG.
B.3. Changes between -01 and -02
In section 2.1, added more to the paragraph on auto-completion of
HTML forms.
Added the section on TLS for authentication.
Filled in section 2.5.
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. 16 change blocks. 
30 lines changed or deleted 88 lines changed or added

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