draft-ietf-httpbis-security-properties-03.txt   draft-ietf-httpbis-security-properties-04.txt 
Network Working Group P. Hoffman Network Working Group J. Hodges
Internet-Draft VPN Consortium Internet-Draft PayPal
Intended status: Informational A. Melnikov Intended status: Informational B. Leiba
Expires: September 8, 2009 Isode Ltd. Expires: September 2, 2009 Huawei Technologies
March 7, 2009 March 2009
Security Requirements for HTTP Security Requirements for HTTP
draft-ietf-httpbis-security-properties-03 draft-ietf-httpbis-security-properties-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 September 8, 2009. This Internet-Draft will expire on September 2, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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 (MTI) security mechanisms, so that all
implementations share a common baseline. This document examines all conformant implementations share a common baseline. This document
widely deployed HTTP security technologies, and analyzes the trade- examines all widely deployed HTTP security technologies, and analyzes
offs of each. the trade-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 . . . . . . . . . . . . . . . . . . . . 4
2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 5 2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 5
2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 5 2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 6
2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 5 2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 6
2.2.3. Authentication Using Certificates in TLS . . . . . . . 6 2.2.3. Authentication Using Certificates in TLS . . . . . . . 7
2.2.4. Other Access Authentication Schemes . . . . . . . . . 6 2.2.4. Other Access Authentication Schemes . . . . . . . . . 7
2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 7 2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 8
2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 8 2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 9
3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 8 3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix B. Document History . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Appendix B. Document History . . . . . . . . . . . . . . . . . . 11
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 . . . . . . 10 and draft-ietf-httpbis-security-properties-00 . . . . . . 11
B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 10 B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 11
B.3. Changes between -01 and -02 . . . . . . . . . . . . . . . 11 B.3. Changes between -01 and -02 . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 B.4. Changes between -02 and -03 . . . . . . . . . . . . . . . 12
B.5. Changes between -03 and -04 . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Recent IESG practice dictates that IETF protocols are required to Recent IESG practice dictates that IETF protocols be required to
specify mandatory to implement security mechanisms. "The IETF specify mandatory-to-implement (MTI) 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".
"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"
skipping to change at page 3, line 34 skipping to change at page 3, line 34
implementations may result. This is the consequence of the implementations may result. This is the consequence of the
selection of non-overlapping mechanisms being deployed in the selection of non-overlapping mechanisms being deployed in the
different implementations. different implementations.
This document examines the effects of applying security constraints This document examines the effects of applying security constraints
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.
[[ OVERALL ISSUE: It isn't entirely clear to the present editors what
the purpose of this document is. On one hand it could be a
compendium of peer-entity authentication mechanisms (as it is
presently) and make MTI recommendations thereof, or it could be a
place for various security considerations (either coalesced here from
the other httpbis specs, or reserved for the more gnarly cross-spec
composite ones), or both. This needs to be clarified. ]]
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- [[ There is a suggestion that this section be split into "browser-
like" and "automation-like" subsections. ]] like" and "automation-like" subsections. See:
http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
0180.html
http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
0183.html
]]
[[ NTLM (shudder) was brought up in the WG a few times in the [[ 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? ]] discussion of the -00 draft. Should we add a section on it? See..
http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
0132.html
http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
0135.html
]]
2.1. Forms And Cookies 2.1. Forms And Cookies
[[ JH: I am not convinced that this subsection properly belongs in
this overall section in that "HTTP+HTML Form based authentication"
<http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication>
is not properly a part of HTTP itself. Rather, it is a piece of
applications layered on top of HTTP. Use of cookies for state
management (e.g. session maintanence) can be considered such, however
(although there is no overall specification for HTTP user agents
stipulating that they must implement cookies (nominally [RFC2109])).
Perhaps this section should be should be retitled "HTTP
Authentication".
Note: The httpstate WG was recently chartered to develop a successor
to [RFC2109]. See..
http://www.ietf.org/dyn/wg/charter/httpstate-charter.html
]]
Almost all HTTP authentication that involves a human using a web Almost all HTTP authentication that involves a human using a web
browser is accomplished through HTML forms, with session identifiers browser is accomplished through HTML forms, with session identifiers
stored in cookies. For cookies, most implementations rely on the stored in cookies. For cookies, most implementations rely on the
"Netscape specification", which is described loosely in section 10 of "Netscape specification", which is described loosely in section 10 of
"HTTP State Management Mechanism" [RFC2109]. The protocol in RFC "HTTP State Management Mechanism" [RFC2109]. The protocol in RFC
2109 is relatively widely implemented, but most clients don't 2109 is relatively widely implemented, but most clients don't
advertise support for it. RFC 2109 was later updated [RFC2965], but advertise support for it. RFC 2109 was later updated [RFC2965], but
the newer version is not widely implemented. the newer version is not widely implemented.
Forms and cookies have many properties that make them an excellent Forms and cookies have many properties that make them an excellent
skipping to change at page 5, line 44 skipping to change at page 6, line 34
2.2.2. Digest Authentication 2.2.2. Digest Authentication
In Digest Authentication, the client transmits the results of hashing In Digest Authentication, the client transmits the results of hashing
user credentials with properties of the request and values from the user credentials with properties of the request and values from the
server challenge. Digest is susceptible to man-in-the-middle attacks server challenge. Digest is susceptible to man-in-the-middle attacks
when not used over a secure transport. when not used over a secure transport.
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 alongside
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. 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
skipping to change at page 7, line 23 skipping to change at page 8, line 13
inserted at will. inserted at will.
Unlike Digest, Negotiate authentication can take multiple round trips Unlike Digest, Negotiate authentication can take multiple round trips
(client sending authentication data in Authorization, server sending (client sending authentication data in Authorization, server sending
authentication data in WWW-Authenticate) to complete. authentication data in WWW-Authenticate) to complete.
Kerberos authentication is generally more secure than Digest. Kerberos authentication is generally more secure than Digest.
However the requirement for having a separate network authentication However the requirement for having a separate network authentication
service might be a barrier to deployment. service might be a barrier to deployment.
2.2.4.2. OAuth
[[ See..
http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt
http://www.ietf.org/id/draft-hammer-oauth-10.txt
]]
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 51 skipping to change at page 8, line 51
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. See..
http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
0536.html
]]
2.5. Transport Layer Security 2.5. Transport Layer Security
In addition to using TLS for client and/or server authentication, it In addition to using TLS for client and/or server authentication, it
is also very commonly used to protect the confidentiality and is also very commonly used to protect the confidentiality and
integrity of the HTTP session. For instance, both HTTP Basic integrity of the HTTP session. For instance, both HTTP Basic
authentication and Cookies are often protected against snooping by authentication and Cookies are often protected against snooping by
TLS. TLS.
It should be noted that, in that case, TLS does not protect against a It should be noted that, in that case, TLS does not protect against a
skipping to change at page 8, line 30 skipping to change at page 9, line 35
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
used schemes are non-standard and/or proprietary. used schemes are non-standard and/or proprietary.
4. Security Considerations 4. IANA Considerations
This document has no actions for IANA.
5. Security Considerations
This entire document is about security considerations. This entire document is about security considerations.
5. Normative References 6. References
6.1. 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] [PhishingHOWTO]
Gutmann, P., "Phishing Tips and Techniques", Gutmann, P., "Phishing Tips and Techniques",
February 2008, February 2008,
<http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf>. <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
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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
skipping to change at page 9, line 46 skipping to change at page 11, line 7
RFC 4178, October 2005. 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>.
6.2. Informative References
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997.
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. Many others on the HTTPbis Working Group first promoted the topic. Many others on the HTTPbis Working Group
have contributed to this document in the discussion. 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.]
skipping to change at page 11, line 28 skipping to change at page 12, line 43
B.3. Changes between -01 and -02 B.3. Changes between -01 and -02
In section 2.1, added more to the paragraph on auto-completion of In section 2.1, added more to the paragraph on auto-completion of
HTML forms. HTML forms.
Added the section on TLS for authentication. Added the section on TLS for authentication.
Filled in section 2.5. Filled in section 2.5.
B.4. Changes between -02 and -03
Changed IPR licensing from "full3978" to "pre5378Trust200902".
B.5. Changes between -03 and -04
Changed authors to be Jeff Hodges (JH) and Barry Leiba (BL) with
permission of Paul Hoffman, Alexey Melnikov, and Mark Nottingham
(httpbis chair).
Added "OVERALL ISSUE" to introduction.
Added links to email messages on mailing list(s) where various
suggestions for this document were brought up. I.e. added various
links to those comments herein delimited by "[[...]]" braces.
Noted JH's belief that "HTTP+HTML Form based authentication" aka
"Forms And Cookies" doesn't properly belong in the section where it
presently resides. Added link to httpstate WG.
Added references to OAuth. Section needs to be filled-in as yet.
Moved ref to RFC2109 to new "Informative References" section, and
added a placeholder "IANA Considerations" section in order to satisfy
IDnits checking.
Authors' Addresses Authors' Addresses
Paul Hoffman Jeff Hodges
VPN Consortium PayPal
Email: paul.hoffman@vpnc.org Email: Jeff.Hodges@PayPal.com
Alexey Melnikov Barry Leiba
Isode Ltd. Huawei Technologies
Email: alexey.melnikov@isode.com Phone: +1 646 827 0648
Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
 End of changes. 25 change blocks. 
48 lines changed or deleted 147 lines changed or added

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