One document matched: draft-sullivan-tls-exported-authenticator-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.31 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc docName="draft-sullivan-tls-exported-authenticator-00" category="std">

  <front>
    <title abbrev="TLS Exported Authenticator">Exported Authenticators in TLS</title>

    <author initials="N." surname="Sullivan" fullname="Nick Sullivan">
      <organization>Cloudflare Inc.</organization>
      <address>
        <email>nick@cloudflare.com</email>
      </address>
    </author>

    <date year="2016"/>

    <area>Security</area>
    <workgroup>TLS</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document describes a mechanism in Transport Layer Security (TLS) to
provide an exportable proof of ownership of a certificate that can be
transmitted out of band and verified by the other party.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>This document provides a way to authenticate one party of a Transport Layer
Security (TLS) communication to another using a certificate after the session
has been established. This allows both the client and server to prove ownership
of additional identities at any time after the handshake has completed. This
proof of authentication can be exported and transmitted out of band from one
party then validated by the other party.</t>

<t>This mechanism is useful in the following situations:</t>

<t><list style="symbols">
  <t>servers that are authoritative for multiple domains the same connection
but do not have a certificate that is simultaneously authoritative for all
of them</t>
  <t>servers that have resources that require client authentication to access
and need to request client authentication after the connection has started</t>
  <t>clients that want to assert ownership over an identity to a server after
a connection has been established</t>
</list></t>

<t>This document intends to replace much of the functionality of renegotiation
in previous versions of TLS. It has the advantages over renegotiation of not
requiring additional on-the-wire changes during a connection.</t>

</section>
<section anchor="authenticator" title="Authenticator">

<t>Given an established TLS connection, a certificate, and a corresponding private
key, an authenticator message can be constructed by either the client or the
server. This authenticator uses the message structures from section 4.4. of
<xref target="I-D.ietf-tls-tls13"/>, but with a different handshake context and finished key.
These messages are not encrypted.</t>

<t>The Handshake Context is an <xref target="RFC5705"/> (for TLS 1.2 or earlier) or <xref target="I-D.ietf-tls-tls13"/>
exporter value derived using the label “authenticator handshake context” and
length 64 bytes. The Finished MAC Key is an exporter value derived using the label
“server authenticator finished key” or “client authenticator finished key”, depending
on the sender, with length corresponding to the length of the handshake hash.</t>

<t>If the connection is TLS 1.2 or earlier, the master secret MUST have been computed
with the extended master secret <xref target="RFC7627"/> to avoid key synchronization attacks.</t>

<t><list style="hanging">
  <t hangText='Certificate'>
  The certificate to be used for authentication and any
supporting certificates in the chain.</t>
</list></t>

<t>The certificate message contains an opaque string called
certificate_request_context which MUST be unique for a given connection. Its format
should be defined by the application level protocol and MUST be non-zero
length.</t>

<t><list style="hanging">
  <t hangText='CertificateVerify'>
  A signature over the value Hash(Handshake Context + Certificate)</t>
  <t hangText='Finished'>
  A HMAC over the value Hash(Handshake Context + Certificate + CertificateVerify)
using the hash function from the handshake and the Finished MAC Key as a key.</t>
</list></t>

<t>The certificates used in the Certificate message must conform to the requirements
of a Certificate message in the version of TLS that is being negotiated as
described in section 4.2.3. of <xref target="I-D.ietf-tls-tls13"/>.</t>

<t>The exported authenticator message is the sequence:
Certificate, CertificateVerify, Finished</t>

</section>
<section anchor="api-considerations" title="API considerations">

<t>TLS implementations supporting the use of exported authenticators MUST provide
application programming interfaces by which clients and servers may request
and verify exported authenticator messages.</t>

<t>Given an established connection, the application should be able to obtain an
authenticator by providing the following:</t>

<t><list style="symbols">
  <t>certificate_request_context (from 1 to 255 bytes)</t>
  <t>valid certificate chain for the connection and associated extensions (OCSP, SCT, etc.)</t>
  <t>signer (either the private key associated with the certificate, or interface
to perform private key operation)</t>
</list></t>

<t>Given an established connection and an exported authenticator message, the
application should be able to provide the authenticator to the connection.
If the Finished and CertificateVerify messages verify, the TLS library should
return the following:</t>

<t><list style="symbols">
  <t>certificate chain and extensions</t>
  <t>certificate_request_context</t>
</list></t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>TBD</t>

</section>
<section anchor="ack" title="Acknowledgements">

<t>Comments on this proposal were provided by Martin Thomson.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='I-D.ietf-tls-tls13'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='July' day='11' year='2016' />

<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-14' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-14.txt' />
</reference>



<reference  anchor='RFC5705' target='http://www.rfc-editor.org/info/rfc5705'>
<front>
<title>Keying Material Exporters for Transport Layer Security (TLS)</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2010' month='March' />
<abstract><t>A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes.  This document describes a general mechanism for allowing that.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5705'/>
<seriesInfo name='DOI' value='10.17487/RFC5705'/>
</reference>



<reference  anchor='RFC7627' target='http://www.rfc-editor.org/info/rfc7627'>
<front>
<title>Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension</title>
<author initials='K.' surname='Bhargavan' fullname='K. Bhargavan' role='editor'><organization /></author>
<author initials='A.' surname='Delignat-Lavaud' fullname='A. Delignat-Lavaud'><organization /></author>
<author initials='A.' surname='Pironti' fullname='A. Pironti'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='M.' surname='Ray' fullname='M. Ray'><organization /></author>
<date year='2015' month='September' />
<abstract><t>The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate.  Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same.  Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server.  This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.</t></abstract>
</front>
<seriesInfo name='RFC' value='7627'/>
<seriesInfo name='DOI' value='10.17487/RFC7627'/>
</reference>




    </references>




  </back>
</rfc>