source: draft-ietf-httpbis-security-properties/00/draft-ietf-httpbis-security-properties-00.xml @ 176

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

First check-in

File size: 13.9 KB
1<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY rfc2026 SYSTEM ""> <!ENTITY rfc2109 SYSTEM ""> <!ENTITY rfc2145 SYSTEM ""> <!ENTITY rfc2616 SYSTEM ""> <!ENTITY rfc2617 SYSTEM ""> <!ENTITY rfc2965 SYSTEM ""> <!ENTITY rfc3365 SYSTEM ""> <!ENTITY rfc3631 SYSTEM ""> <!ENTITY rfc3986 SYSTEM ""> <!ENTITY rfc4559 SYSTEM ""> ]> <rfc category="info" ipr="full3978" docName="draft-ietf-httpbis-security-properties-00.txt"> <?xml-stylesheet type='text/xsl' href='rfc2629xslt/rfc2629.xslt' ?> <?rfc toc="yes" ?> <?rfc symrefs="yes" ?> <?rfc sortrefs="yes"?> <?rfc strict="yes" ?> <?rfc compact="yes" ?> <?rfc subcompact="no" ?> <?rfc linkmailto='no'?> <front>   <title>Security Requirements for HTTP</title>   <author initials='P.' surname="Hoffman" fullname='Paul Hoffman'>     <organization>VPN Consortium</organization>     <address><email></email> </address>   </author>   <author initials='A.' surname="Melnikov" fullname='Alexey Melnikov'>      <organization>Isode Ltd.</organization>      <address><email></email> </address>   </author>   <date month="January" year="2008"/>   <abstract>     <t>Recent IESG practice dictates that IETF protocols must specify       mandatory-to-implement security mechanisms, so that       all conformant implementations share a common baseline. This       document examines all widely deployed HTTP security       technologies, and analyzes the trade-offs of       each.</t>   </abstract> </front> <middle>   <section title="Introduction"> <t>Recent IESG practice dictates that IETF protocols are required to specify mandatory to implement security mechanisms. "The IETF Standards Process" <xref target="RFC2026"/> does not require that protocols specify mandatory security mechanisms. "Strong Security Requirements for IETF Standard Protocols" <xref target="RFC3365"/> requires that all IETF protocols provide a mechanism for implementors to provide strong security. RFC 3365 does not define the term "strong security".</t> <t>"Security Mechanisms for the Internet" <xref target="RFC3631"/> is not an IETF procedural RFC, but it is perhaps most relevant. Section 2.2 states:</t> <figure><artwork>    We have evolved in the IETF the notion of "mandatory to implement"    mechanisms.  This philosophy evolves from our primary desire to    ensure interoperability between different implementations of 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    must implement, it may be possible that multiple, non-interoperable    implementations may result.  This is the consequence of the    selection of non-overlapping mechanisms being deployed in the    different implementations. </artwork></figure> <t>This document examines the effects of applying security constraints to Web applications, documents the properties that result from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the moment, it is mostly a laundry list of security technologies and tradeoffs.</t> </section> <section title="Existing HTTP Security Mechanisms"> <t>For HTTP, the IETF generally defines "security mechanisms" as some combination of access authentication and/or a secure transport.</t> <section title="Forms And Cookies"> <t>Almost all HTTP authentication is accomplished through HTML forms, with session keys stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described loosely in section 10 of "HTTP State Management Mechanism" <xref target="RFC2109"/>. The protocol in RFC 2109 is relatively widely implemented, but most clients don't advertise support for it. RFC 2109 was later updated <xref target="RFC2965"/>, but the newer version is not widely implemented.</t> <t>Forms and cookies have number of properties that make them an excellent solution for some implementors. However, many of those properties introduce serious security trade-offs.</t> <t>HTML forms provide a large degree of control over presentation, which is an imperative for many websites. However, this increases user reliance on the appearance of the interface. Many users do not understand the construction of URIs <xref target="RFC3986"/>, or their presentation in common clients [[ CITATION NEEDED ]]. As a result, forms are extremely vulnerable to spoofing.</t> <t>HTML forms provide acceptable internationalization if used carefully, at the cost of being transmitted as normal HTTP content in all cases (credentials are not differentiated in the protocol).</t> <t>HTML forms provide a facility for sites to indicate that a password should never be pre-populated. [[ More needed here on autocomplete ]]</t> <t>The cookies that result from a successful form submission make it unessecary to validate credentials with each HTTP request; this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting) attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the data.</t> <t>HTML forms and cookies provide flexible ways of ending a session from the client.</t> <t>HTML forms require an HTML rendering engine, which many protocols have no use for.</t> </section> <section title="HTTP Access Authentication"> <t>HTTP 1.1 provides a simple authentication framework, and "HTTP Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/> defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies, but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control, logout capabilities, or interoperable internationalization.</t> <section title="Basic Authentication"> <t>Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement, but not at all secure unless used over a secure transport.</t> <t>Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials, but there is no standard method of doing so.</t> <t>Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.</t> <t>Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</t> </section> <section title="Digest Authentication"> <t>In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.</t> <t>Digest has some properties that are preferable to Basic and Cookies. Credentials are not immediately reusable by parties that observe or receive them, and session data can be transmitted along side credentials with each request, allowing servers to validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.</t> <t>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.</t> <t>Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk consisting of a few million passwords [[ CITATION NEEDED ]].</t> <t>Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <xref target="Apache_Digest"/>.</t> <t>Digest either requires that authentication databases be expressly designed to accomodate it, or requires access to cleartext passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common method of storing passwords for use with Forms and Cookies.</t> <t>Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</t> <t>Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</t> </section> <section title="Other Access Authentication Schemes"> <t>There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are bound to transport layer connections.</t> <section title="Negotiate (GSS-API) Authentication"> <t>[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows" <xref target="RFC4559"/> goes here.]]</t> </section> </section> </section> <section title="Centrally-Issued Tickets"> <t>Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more than a sophisticated application of forms and cookies.</t> <t>All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization efforts in progress, as usual.</t> </section> <section title='Web Services'> <t>Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination of standard and vendor-produced specifications, some of which may be obsoleted at any time <xref target="WS-Pagecount"/> without any documented change control procedures. 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 used to group them, but they are obviously out of scope for HTTP-based application protocols.</t> </section> <section title="Transport Layer Security"> <t>[[ A discussion of HTTP over TLS needs to be added here. ]]</t> <t>[[ Discussion of connection confidentiality should be separate from the discussion of access authentication based on mutual authentication with certificates in TLS. ]]</t> </section> </section> <section title="Revisions To HTTP"> <t>Is is possible that HTTP will be revised in the future. "HTTP/1.1" <xref target="RFC2616"/> and "Use and Interpretation of HTTP Version Numbers" <xref target="RFC2145"/> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.</t> </section> <section title="Security Considerations"> <t>This entire document is about security considerations.</t> </section> </middle> <back> <references title='Normative References'> &rfc2026; &rfc2109; &rfc2145; &rfc2616; &rfc2617; &rfc2965; &rfc3365; &rfc3631; &rfc3986; &rfc4559; <reference anchor='Apache_Digest'   target=''> <front>   <title>Apache HTTP Server - mod_auth_digest</title>   <author surname="Apache Software Foundation">   <organization />   </author> </front> </reference> <reference anchor='WS-Pagecount'   target=''> <front>   <title>WS-Pagecount</title>   <author initials="T." surname="Bray" fullname="Tim Bray">   <organization />   </author>   <date year='2004' month='September' /> </front> </reference> </references> <section title='Acknowledgements'> <t>Much of the material in this document was written by Rob Sayre, who first promoted the topic.</t> </section> <section title='Document History'> <t>[This entire section is to be removed when published as an RFC.]</t> <section title='Changes between draft-sayre-http-security-variance-00 and   draft-ietf-http-security-properties-00'> <t>Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</t> <t>Made lots of minor editorial changes.</t> <t>Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</t> <t>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.</t> <t>Added minor text to the Security Considerations section.</t> <t>Added URLs to the two non-RFC references.</t> </section> </section> </back> </rfc>
Note: See TracBrowser for help on using the repository browser.