source: draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.xml @ 1928

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
<!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 rfc4178 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4178.xml">
<!ENTITY rfc4559 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559.xml">
]>

<rfc category="info" ipr="pre5378Trust200902"
  docName="draft-ietf-httpbis-security-properties-latest">

    <?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="J." surname="Hodges" fullname="Jeff Hodges">
            <organization>PayPal</organization>
            <address>
                <email>Jeff.Hodges@PayPal.com</email> 
            </address>
        </author>
        <author initials='B.' surname="Leiba" fullname='Barry Leiba'>
            <organization>Huawei Technologies</organization>
            <address>
                <phone>+1 646 827 0648</phone>
                <email>barryleiba@computer.org</email>
                <uri>http://internetmessagingtechnology.org/</uri>
            </address>
        </author>
        <date year="2010" month="March"/>
        <abstract>
            <t>
                Recent IESG practice dictates that IETF protocols must
                specify mandatory-to-implement (MTI) 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 be
                required to specify mandatory-to-implement (MTI) 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>

            <t>
                [[ 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. 
                ]]
            </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. See: 
                <list>
                    <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html</t>
                    <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html</t>
                </list>
                ]]
            </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? See..
                <list>
                    <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html</t>
                    <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html</t>
                </list>
                ]]
            </t>

            <section title="Forms And Cookies">

                <t>
                    [[ JH: I am not convinced that this subsection 
                    properly belongs in this overall section in that 
                    "HTTP+HTML Form based authentication"
                    &lt;http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication&gt;
                    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 
                    <xref target="RFC2109"/>)). Perhaps this section should be 
                    should be retitled "HTTP Authentication". 
                    </t>
                <t>
                    Note: The httpstate WG was recently chartered to develop a successor to 
                    <xref target="RFC2109"/>. See..
                    <list>
                        <t>http://www.ietf.org/dyn/wg/charter/httpstate-charter.html</t>
                    </list>
                </t>
                <t>
                    ]]
                </t>

                <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>
                    Many Web browsers have an auto-complete feature
                    that stores a user's 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.
                </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 alongside 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 for most
                        users.
                    </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="Authentication Using Certificates in TLS">

                    <t>
                        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.
                    </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>
                            Microsoft has designed an HTTP
                            authentication mechanism that utilizes
                            SPNEGO <xref target="RFC4178"/> GSSAPI
                            <xref target="RFC4559"/>. In Microsoft's
                            implementation, SPNEGO allows selection
                            between Kerberos and NTLM (Microsoft NT
                            Lan Manager protocols).
                        </t>

                        <t>
                            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.
                        </t>

                        <t>
                            Unlike Digest, Negotiate authentication
                            can take multiple round trips (client
                            sending authentication data in
                            Authorization, server sending
                            authentication data in WWW-Authenticate)
                            to complete.
                        </t>

                        <t>
                            Kerberos authentication is generally more
                            secure than Digest. However the
                            requirement for having a separate network
                            authentication service might be a barrier
                            to deployment.
                        </t>

                        <!--
                        Kerberos didn't support Unicode till relatively recently. I am not sure if this
                        is an issue with Microsoft's implementation.
                        -->

                    </section>

                    <section title="OAuth">

                        <t>
                            [[ See..
                            <list>
                                <t>http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt</t>
                                <t>http://www.ietf.org/id/draft-hammer-oauth-10.txt</t>
                            </list>
                            ]]
                        </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. See..
                    <list>
                        <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html</t>
                    </list>
                    ]]
                </t>

            </section>

            <section title="Transport Layer Security">

                <t>
                    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.
                </t>

                <t>
                    It should be noted that, in that case, TLS does
                    not protect against a breach of the credential
                    store at the server or against a keylogger or
                    phishing interface at the client. TLS does not
                    change the fact that Basic Authentication
                    passwords are reusable and does not address that
                    weakness.
                </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="IANA Considerations">
            <t>This document has no actions for IANA.</t>
        </section>

        <section title="Security Considerations">

            <t>This entire document is about security considerations.</t>

        </section>



    </middle>

    <back>

        <references title="Normative References">

&rfc2026;
&rfc2145;
&rfc2616;
&rfc2617;
&rfc2965;
&rfc3365;
&rfc3631;
&rfc3986;
&rfc4178;
&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>
<date year="" month="" />
</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>

        <references title="Informative References">

&rfc2109;


        </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 title="Changes between -01 and -02">

                <t>In section 2.1, added more to the paragraph on auto-completion of
                    HTML forms.</t>

                <t>Added the section on TLS for authentication.</t>

                <t>Filled in section 2.5.</t>

            </section>


            <section title="Changes between -02 and -03">

                <t>
                    Changed IPR licensing from "full3978" to "pre5378Trust200902".
                </t>

            </section>


            <section title="Changes between -03 and -04">

                <t>
                    Changed authors to be
                    Jeff Hodges (JH) and Barry Leiba (BL)
                     with permission of Paul
                    Hoffman, Alexey Melnikov, and Mark Nottingham
                    (httpbis chair).
                </t>

                <t>
                    Added "OVERALL ISSUE" to introduction. 
                </t>

                <t>
                    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.
                </t>

                <t>
                    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. 
                </t>

                <t>
                    Added references to OAuth. Section needs to be filled-in as yet. 
                </t>

                <t>
                    Moved ref to RFC2109 to new "Informative References" section, and
                    added a placeholder "IANA Considerations" section in order
                    to satisfy IDnits checking. 
                </t>


            </section>

            <section title="Changes between -04 and -05">

                <t>
                    Fixed incorrect &lt;date&gt; year from 2009 to 2010. mea culpa.
                </t>

            </section>

        </section>

    </back>

</rfc>


<!-- PLEASE DO NOT DELETE!!! The below is used by XEmacs XML major-mode -->
<!--
Local Variables:
mode: xml
indent-tabs-mode:nil
sgml-omittag:t
sgml-shorttag:t
sgml-namecase-general:t
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:4
sgml-indent-data:t
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
<!-- PLEASE DO NOT DELETE!!! The above is used by XEmacs XML major-mode -->