One document matched: draft-thomson-httpbis-cant-00.xml

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" ipr="trust200902" docName="draft-thomson-httpbis-cant-00">
  <front>
    <title abbrev="CANT">
      Client Authentication over New TLS Connection
    </title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <postal>
          <street>Suite 300</street>
          <street>650 Castro Street</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94041</code>
          <country>US</country>
        </postal>

        <email>martin.thomson@gmail.com</email>
      </address>
    </author>
<!--
    <author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
      <organization>RTFM, Inc.</organization>

      <address>
        <postal>
          <street>2064 Edgewood Drive</street>
          <city>Palo Alto</city>
          <region>CA</region>
          <code>94303</code>
          <country>USA</country>
        </postal>

        <phone>+1 650 678 2350</phone>
        <email>ekr@rtfm.com</email>
      </address>
    </author>
-->
    <date year="2014"/>
    <area>APPS</area>
    <workgroup>HTTPBIS</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>Client</keyword>
    <keyword>Authentication</keyword>
    <keyword>Certificate</keyword>
    <keyword>TLS</keyword>
    <keyword>Header</keyword>

    <abstract>
      <t>
        This document defines an HTTP authentication scheme that can be added to an error response
        to indicate to a client that a successful response will only be provided over a new TLS
        connection, and only if the client has provided a certificate on that connection.
      </t>
    </abstract>
  </front>

  <middle>

    <section anchor="intro" title="Introduction">
      <t>
        Client authentication in HTTP sometimes relies on certificate-based authentication of
        clients in <xref target="RFC5246">Transport Layer Security (TLS)</xref>.  Some uses of
        client authentication rely on TLS renegotiation, triggering renegotiation in response to a
        request for a particular resource.
      </t>
      <t>
        <xref target="I-D.ietf-httpbis-http2">HTTP/2</xref> forbids the use of renegotiation, except
        for at the very beginning of a connection.  This makes addressing some client authentication
        use cases difficult.
      </t>
      <t>
        This document defines a new authentication scheme, <spanx
        style="verb">ClientCertificate</spanx>, for use in <xref
        target="I-D.ietf-httpbis-p7-auth">HTTP authentication challenges</xref>.  In combination
        with the 401 (Unauthorized) status code, this indicates that the resource requires client
        authentication at the TLS layer in order to access it.
      </t>

      <section title="Conventions and Terminology" anchor="terminology">
       <t>
         At times, this document falls back on shorthands for establishing interoperability
         requirements on implementations: the capitalized words "MUST", "SHOULD" and "MAY".  These
         terms are defined in <xref target="RFC2119"/>.
       </t>
      </section>
    </section>

    <section title="Client Certificate Challenge">
      <t>
        A new authentication scheme (<xref target="I-D.ietf-httpbis-p7-auth"/>) for the <spanx
        style="verb">WWW-Authenticate</spanx> and <spanx style="verb">Proxy-Authenticate</spanx>
        header fields is defined with the name <spanx style="verb">ClientCertificate</spanx>.
      </t>
      <t>
        A challenge with this authentication scheme does not define any parameters except <spanx
        style="verb">realm</spanx>.  The <spanx style="verb">realm</spanx> can be used to select an
        appropriate certificate, or if a certificate is already in use, to indicate the need for a
        different certificate.  Other challenge parameters MAY be used to provide a client with
        information it can use to select an appropriate certificate.  Unknown parameters MUST be
        ignored.
      </t>
      <t>
        This challenge cannot be satisfied by constructing an <xref
        target="I-D.ietf-httpbis-p7-auth">Authorization header field</xref>, it can only be
        satisfied by making the request on a TLS connection where an appropriate certificate has
        been provided by the client.
      </t>
      <t>
        To effectively use this authentication scheme, a new connection is needed for every
        protection space used by a given origin server.  A client can use the <spanx
        style="verb">ClientCertificate</spanx> challenge as a trigger to open a new connection and
        to use client authentication on that connection.  The client can use the mechanism in <xref
        target="I-D.thomson-tls-care"/> to prompt the server to request a client certificate, to
        avoid the problem where the server doesn't know to make this request.
      </t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>
        Clients that support this authentication scheme will create a new connection each time that
        they see a challenge.  This could be exploited in order to generate additional load in terms
        of connections on both server and client.
      </t>
      <t>
        Using new connections for client authentication has additional processing costs to the
        client in proving access to the private keys associated with the client certificate; and to
        the server in proving access to the private keys associated with their certificate twice in
        the case that the client opts for confidentiality protection on the client certificate.
      </t>
      <t>
        <xref target="I-D.ietf-httpbis-http2">HTTP/2</xref> allows clients to use the same
        connection for multiple canonical root URIs.  Certificate-based client authentication as
        defined by this specification is bound to a single origin.  This could create issues whereby
        the security properties of a connection could become confused.  Clients MUST ensure that a
        client-authenticated connection is only used for the origin for which it was created.
      </t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>
        IANA is requested to create an entry in the HTTP Authentication Scheme Registry with the
        following information:
        <list style="hanging:">
          <t hangText="Authentication Scheme Name:">ClientCertificate</t>
          <t hangText="Pointer to specification text:">This document</t>
          <t hangText="Notes">This scheme does not rely on the Authorization header field.</t>
        </list>
      </t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>
        Eric Rescorla helped identify the problem and formulate this mechanism.  Julian Reschke and
        Michael Koeller provided excellent feedback.
      </t>
    </section>

    <!--
        <appendix title="Change Log">
        <t>[[The RFC Editor is requested to remove this section at publication.]]</t>
        <t>Changes since -0-1:
        <list style="symbols">
        <t>Document created.</t>
        </list>
        </t>
        </appendix>
    -->
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6454.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-p7-auth.xml"?>
    </references>
   <references title="Informational References">
     <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-http2.xml"?>
     <reference anchor="I-D.thomson-tls-care">
       <front>
         <title></title>
         <author initials="M." surname="Thomson" fullname="Martin Thomson"/>
         <date month="March" year="2014" />
       </front>
       <seriesInfo name="Internet-Draft" value="draft-thomson-tls-care-00" />
     </reference>
   </references>
  </back>
</rfc>