source: draft-ietf-httpbis-security-properties/01/draft-ietf-httpbis-security-properties-01.xml @ 415

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">
<!ENTITY rfc2109 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2109.xml">
<!ENTITY rfc2145 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2145.xml">
<!ENTITY rfc2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY rfc2617 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
<!ENTITY rfc2965 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2965.xml">
<!ENTITY rfc3365 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3365.xml">
<!ENTITY rfc3631 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3631.xml">
<!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY rfc4559 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559.xml">
]>

<rfc category="info" ipr="full3978"
  docName="draft-ietf-httpbis-security-properties-01.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'?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<front>
  <title>Security Requirements for HTTP</title>
  <author initials='P.' surname="Hoffman" fullname='Paul Hoffman'>
    <organization>VPN Consortium</organization>
    <address><email>paul.hoffman@vpnc.org</email> </address>
  </author>
  <author initials='A.' surname="Melnikov" fullname='Alexey Melnikov'>
     <organization>Isode Ltd.</organization>
     <address><email>alexey.melnikov@isode.com</email> </address>
  </author>
  <date 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 implementers
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>

<t>[[ There is a suggestion that this section be split into
"browser-like" and "automation-like" subsections. ]]</t>

<t>[[ 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? ]]</t>

<section title="Forms And Cookies">

<t>Almost all HTTP authentication that involves a human
using a web browser is accomplished through HTML forms,
with session identifiers 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 many properties that make them an
excellent solution for some implementers. 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 <xref target="PhishingHOWTO"/>.
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
unnecessary 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 for which many protocols
have no use.</t>

</section>

<section title="HTTP Access Authentication">

<t>HTTP 1.1 provides a simple authentication framework, "HTTP
Authentication: Basic and Digest Access Authentication" <xref
target="RFC2617"/>, which 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.  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.</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 accommodate 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 the term "Web" is
used to group them, but they are obviously out of scope for HTTP-based
application protocols.</t>

<t>[[ This section could really use a good definition of
"Web Services" to differentiate it from REST. ]]</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='http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html'>
<front>
  <title>Apache HTTP Server - mod_auth_digest</title>
  <author surname="Apache Software Foundation">
  <organization />
  </author>
</front>
</reference>

<reference anchor='PhishingHOWTO'
  target='http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf'>
<front>
  <title>Phishing Tips and Techniques</title>
  <author initials="P." surname="Gutmann" fullname="Peter Gutmann">
  <organization /></author>
  <date year='2008' month='February' />
</front>
</reference>

<reference anchor='WS-Pagecount'
  target='http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research'>
<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. Many others on the HTTPbis Working
Group have contributed to this document in the discussion.</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-httpbis-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 definition 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 title='Changes between -00 and -01'>

<t>Fixed some editorial nits reported by Iain Calder.</t>

<t>Added the suggestions about splitting for browsers and
automation, and about adding NTLM, to be beginning of 2.</t>

<t>In 2.1, added "that involves a human
using a web browser" in the first sentence.</t>

<t>In 2.1, changed "session key" to "session identifier".</t>

<t>In 2.2.2, changed
<figure><artwork><![CDATA[
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.
]]></artwork></figure>
to
<figure><artwork><![CDATA[
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.
]]></artwork></figure>
</t>

<t>In 2.4, asked for a definition of "Web Services".</t>

<t>In A, added the WG.</t>

</section>

</section>

</back>

</rfc>