One document matched: draft-thomson-tls-care-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-tls-care-00">
  <front>
    <title abbrev="CARE">
      Client Authentication Request Extension for (D)TLS
    </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>Security</area>
    <workgroup>TLS</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>Client</keyword>
    <keyword>Authentication</keyword>
    <keyword>Certificate</keyword>
    <keyword>Extension</keyword>

    <abstract>
      <t>
        This document describes an extension to Transport Layer Security (TLS) and Datagram TLS
        (DTLS) that allows a client to indicate that it wants to provide a client certificate.
      </t>
    </abstract>
  </front>

  <middle>

    <section anchor="intro" title="Introduction">
      <t>
        In <xref target="RFC5246">Transport Layer Security (TLS)</xref> and <xref
        target="RFC5764">Datagram TLS (DTLS)</xref> the server decides whether or not to request a
        certificate from clients.
      </t>
      <t>
        In TLS versions 1.2 and earlier, the Certificate message from a client is not encrypted and
        is therefore not confidential.  TLS renegotiation is frequently used to provide
        confidentiality for client credentials, since renegotiation handshakes are encrypted with
        the TLS session keys.
      </t>
      <t>
        A client that is aware of a need to authenticate can initial renegotiation, but is unable to
        induce a CertificateRequest from the server.  The decision to request client authentication
        is one that can only be made by a server.
      </t>
      <t>
        This document defines a client authentication request extension that can be used by a client
        to request that the server send a CertificateRequest in its handshake.
      </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 Authentication and TLS Renegotiation">
      <t>
        Renegotiation has the potential to create confusion at higher layers about the security
        properties that apply to the byte stream.  This is especially difficult when there are
        protocol constructs that span the ChangeCipherSpec messages that represent a switch between
        states.
      </t>
      <t>
        For that reason, a client can initiate a new connection when it detects a need to
        authenticate, initiating renegotiation to establish authentication credentials immediately
        after the initial handshake.
      </t>
      <t>
        Since the server only conditionally requests client authentication and it has no context
        with which to decide that authentication is needed, the client needs to provide some
        indication that it might need to be authentication.  The second, renegotiation handshake can
        contain the <xref target="care">client authentication request extension</xref> to provide
        this indication.  As long as no application data is sent on the connection prior to
        completing renegotiation and sending the corresponding ChangeCipherSpec, there is no
        possibility for confusion over the security properties of application content.
      </t>
      <t>
        This behavior could need to be triggered by a higher level protocol.  This document does not
        define how that happens.
      </t>
    </section>

    <section title="Client Authentication Request Extension" anchor="care">
      <t>
        A new extension type (<spanx style="verb">client_authentication_request(TBD)</spanx>) is
        defined.  If a client includes this extension in its ClientHello to indicate that it wishes
        the server to issue a CertificateRequest.
      </t>
      <figure><artwork><![CDATA[
enum {
    client_authentication_request(TBD), (65535)
} ExtensionType;
]]></artwork></figure>
      <t>
        The <spanx style="verb">extension_data</spanx> field of this extension MUST be empty.
      </t>
      <t>
        A server that supports client authentication based on certificates can use the presence of
        this extension to decide to include a CertificateRequest.  The server MAY choose to ignore
        this extension.
      </t>
      <t>
        A server MUST NOT send this extension to a client.
      </t>
   </section>

    <section anchor="security" title="Security Considerations">
      <t>
        This document is entirely about security.
      </t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>
        IANA has allocated a TLS extension code point of (TBD) for this extension.
      </t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>
        Eric Rescorla helped identify the problem and formulate this mechanism.
      </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.5764.xml"?>
    </references>
  </back>
</rfc>