One document matched: draft-thomson-httpbis-catch-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-catch-00">
  <front>
    <title abbrev="CATCH">
      Client Authentication over TLS Connection Header
    </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 header field that can be added to a response to indicate to a
        client that a response will only be provided over a 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 TLS.  Some uses of client authentication rely on <xref target="RFC5246">Transport
        Layer Security (TLS)</xref> 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 type of authentication scheme, "ClientCertificate" 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 kind of authentication scheme (<xref
        target="I-D.ietf-httpbis-p7-auth">auth-scheme</xref>) 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 auth-scheme does not define the use of any parameters other than
        <spanx style="verb">realm</spanx>.  Other 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>
        A client can use this information 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 <xref target="RFC6454">origins</xref>.  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 will [has] create[d] 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:">RFCXXXX (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
        hasn't provided any contribution yet, but he will.
      </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.2617.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.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>