<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
 <!ENTITY docName "draft-ietf-kitten-tls-channel-bindings-for-tls13-16"> nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
 ]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     ipr="trust200902"
     docName="&docName;"
     docName="draft-ietf-kitten-tls-channel-bindings-for-tls13"
     number="9266"
     obsoletes=""
     updates="5801, 5802, 5929, 7677"
     submissionType="IETF"
     category="std"
     consensus="true"
     xml:lang="en"
     tocInclude="true"
     symRefs="true"
     sortRefs="true"
     version="3">

  <front>
    <title abbrev="">Channel Bindings for TLS 1.3</title>
    <seriesInfo name="Internet-Draft" value="&docName;"/> name="RFC" value="9266"/>
    <author initials="S" surname="Whited" fullname="Sam Whited">
      <organization/>
      <address>
        <postal>
          <street/>
          <city>Atlanta</city>
          <code>GA</code>
          <country>USA</country>
          <region>GA</region>
          <country>United States of America</country>
          <region/>
        </postal>
        <phone/>
        <email>sam@samwhited.com</email>
        <uri>https://blog.samwhited.com/</uri>
      </address>
    </author>
    <date year="2022" month="May" day="04"/>
    <area>Internet</area>
    <workgroup>Transport Layer Security</workgroup> month="July"/>

    <area>sec</area>
    <workgroup>kitten</workgroup>

    <abstract>
      <t>
        This document defines a channel binding type, tls-exporter, that is
        compatible with TLS 1.3 in accordance with RFC 5056, On "On the Use of
        Channel Binding. Bindings to Secure Channels".  Furthermore, it updates the
        default channel binding to the new binding for versions of TLS greater
        than 1.2.  This document updates RFC5801, RFC5802, RFC5929, RFCs 5801, 5802, 5929, and RFC7677. 7677.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        The "tls-unique" channel binding type defined in
        <xref target="RFC5929"/> was found to be vulnerable susceptible to the "triple
        handshake vulnerability" <xref target="TRIPLE-HANDSHAKE"/> without the
        extended master secret extension defined in <xref target="RFC7627"/>.
        While TLS 1.3 uses a complete transcript hash akin to the extended
        master secret procedures, the safety of channel bindings with TLS 1.3
        was not analyzed as part of the core protocol work, and so the
        specification of channel bindings for TLS 1.3 was deferred.
        <xref target="RFC8446"/> section C.5 target="RFC8446" sectionFormat="of" section="C.5"/> notes the lack of channel bindings
        for TLS 1.3; this document defines such channel bindings, bindings and fills that
        gap.
        Furthermore, this document updates <xref target="RFC5929"/> by adding an
        additional unique channel binding type, "tls-exporter", that replaces
        some usage of "tls-unique".
      </t>
      <section anchor="conventions-and-terminology" numbered="true" toc="default">
        <name>Conventions and Terminology</name>
        <t>
          Throughout this document document, the acronym "EKM" is used to refer to
          Exported
          "Exported Keying Material Material" as defined in <xref target="RFC5705"/>.
        </t>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
          "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
          "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
          14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174"
          format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="tls-exporter" numbered="true" toc="default">
      <name>The 'tls-exporter' Channel Binding Type</name>
      <t>
        Channel binding mechanisms are not useful until TLS implementations
        expose the required data.  To facilitate this, "tls-exporter" uses exported keying material (EKM)
        Exported Keying Material (EKM), which is already widely exposed by TLS
        implementations.  The EKM is obtained using the keying material
        exporters for TLS TLS, as defined in <xref target="RFC5705"/> and <xref target="RFC8446"/> section
        7.5
        target="RFC8446" sectionFormat="of" section="7.5"/>, by supplying the
        following inputs:
      </t>
      <dl>
        <dt>Label:</dt>
        <dd>
          The ASCII string "EXPORTER-Channel-Binding" with no terminating NUL.
        </dd>
        <dt>Context value:</dt>
        <dd>
          Zero-length string.
        </dd>
        <dt>Length:</dt>
        <dd>
          32 bytes.
        </dd>
      </dl>
      <t>
        This channel binding mechanism is defined only when the TLS handshake
        results in unique master secrets. This is true of TLS versions prior to
        1.3 when the extended master secret extension of
        <xref target="RFC7627"/> is in use, and it is always true for TLS 1.3
        (see <xref target="RFC8446"/> appendix D). target="RFC8446" sectionFormat="of" section="D"/>).
      </t>
    </section>
    <section anchor="scram" numbered="true" toc="default">
      <name>TLS 1.3 with SCRAM or GSS-API over SASL</name>

      <t>
        SCRAM
        (<xref target="RFC5802"/>, and
        The specifications for Salted Challenge Response Authentication Mechanism (SCRAM) <xref
        target="RFC5802"/> <xref target="RFC7677"/>) target="RFC7677"/> and GSS-API Generic Security
        Service Application Program Interface (GSS-API) over SASL Simple
        Authentication and Security Layer (SASL) <xref target="RFC5801"/>
        define "tls-unique" as the default channel binding to use over TLS.
        As "tls-unique" is not defined for TLS 1.3 (and greater), this
        document updates <xref target="RFC5801"/>, <xref target="RFC5802"/>,
        and <xref target="RFC7677"/> to use "tls-exporter" as the default
        channel binding over TLS 1.3 (and greater).
        Note that this document does not change the default channel
        binding for SCRAM mechanisms over TLS 1.2 <xref target="RFC5246"/>,
        which is still "tls-unique". "tls-unique" (also note that RFC 5246 has been obsoleted
        by RFC 8446).
      </t>
      <t>
        Additionally, this document updates the aforementioned documents to make
        "tls-exporter" the mandatory to implement mandatory-to-implement channel binding if any channel
        bindings are implemented for TLS 1.3.
        Implementations that support channel binding over TLS 1.3
        <bcp14>MUST</bcp14> implement "tls-exporter".
      </t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        The channel binding type defined in this document is constructed so that
        disclosure of the channel binding data does not leak secret information
        about the TLS channel and does not affect the security of the TLS
        channel.
      </t>
      <t>
        The derived data <bcp14>MUST NOT</bcp14> be used for any purpose other
        than channel bindings as described in <xref target="RFC5056"/>.
        In particular, implementations MUST NOT <bcp14>MUST NOT</bcp14> use channel binding as a
        secret key to protect privileged information.
      </t>
      <t>
        The Security Considerations sections of <xref target="RFC5056"/>, <xref
        target="RFC5705"/>, and <xref target="RFC8446"/> apply to this document.
      </t>
      <section anchor="unique-bindings" numbered="true" toc="default">
        <name>Uniqueness of Channel Bindings</name>
        <t>
          The definition of channel bindings in <xref target="RFC5056"/>
          defines the concept of a "unique" channel binding as being one that
          is unique to the channel endpoints and unique over time, that is,
          a value that is unique to a specific instance of the lower layer lower-layer
          security protocol.
          When TLS is the lower layer lower-layer security protocol, as for the channel binding
          type defined in this document, this concept of uniqueness
          corresponds to uniquely identifying the specific TLS connection.
        </t>

        <t>
          However, a stronger form of uniqueness is possible, which would entail
          uniquely identifying not just the lower layer lower-layer protocol but also the
          upper layer
          upper-layer application or authentication protocol that is consuming
          the channel binding.
          The distinction is relevant only when there are multiple instances of
          an authentication protocol, or multiple distinct authentication
          protocols, that run atop the same lower layer lower-layer protocol.
          Such a situation is rare -- rare; most consumers of channel bindings
          establish an instance of the lower layer lower-layer secure protocol, run a single
          application or authentication protocol as the upper layer upper-layer protocol,
          then terminate both upper and lower layer lower-layer protocols.
          In this situation situation, the stronger form of uniqueness is trivially
          achieved, given that the channel binding value is unique in the sense
          of <xref target="RFC5056"/>.
        </t>
        <t>
          The channel binding type defined by this document provides only the
          weaker type of uniqueness, as per <xref target="RFC5056"/>; it does
          not achieve the stronger uniqueness per upper layer the upper-layer protocol
          instance described above.  This stronger form of uniqueness would be
          useful in that it provides protection against cross-protocol attacks
          for the multiple authentication protocols running over the same
          instance of the lower
          layer lower-layer protocol, and it provides protection
          against replay attacks that seek to replay a message from one
          instance of an authentication protocol in a different instance of
          the same authentication protocol, again running over the same
          instance of the lower layer lower-layer protocol.  Both of these properties are
          highly desirable when performing formal analysis of upper layer upper-layer
          protocols; if these properties are not provided, such formal
          analysis is essentially impossible.  In some cases cases, one or both of
          these properties may already be provided by specific upper layer upper-layer
          protocols, but that is dependent on the mechanism(s) in question,
          and formal analysis requires that the property is provided in a
          generic manner, manner across all potential upper
          layer upper-layer protocols that
          exist or might exist in the future.
        </t>
        <t>
          Accordingly, applications that make use of the channel binding type
          defined in this document <bcp14>MUST NOT</bcp14> use the channel
          binding for more than one authentication mechanism instance on a given
          TLS connection.
          Such applications <bcp14>MUST</bcp14> immediately close the TLS
          connection after the conclusion of the upper layer upper-layer protocol.
        </t>
      </section>
      <section anchor="legacy-tls" numbered="true" toc="default">
        <name>Use with Legacy TLS</name>
        <t>
          While it is possible to use this channel binding mechanism with TLS
          versions below 1.3, extra precaution must be taken to ensure that
          the chosen cipher suites always result in unique master secrets.
          For more information information, see <xref target="RFC7627"/> and the Security
          Considerations section of <xref target="RFC5705"/> (TLS 1.3 always
          provides unique master secrets, as discussed in Appendix D of <xref target="RFC8446"/>.)
          target="RFC8446" sectionFormat="of" section="D"/>).
        </t>
        <t>
          When TLS renegotiation is enabled on a connection connection, the "tls-exporter"
          channel binding type is not defined for that connection connection, and
          implementations <bcp14>MUST NOT</bcp14> support it.
        </t>
        <t>
          In general, users wishing to take advantage of channel binding should
          upgrade to TLS 1.3 or later.
        </t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="cb-type-registration" numbered="true" toc="default">
        <name>Registration of Channel Binding Type</name>
        <t>
          This document adds the following registration
          IANA has registered tls-exporter in the "Channel-Binding
          Types" registry:
        </t>
        <dl>
          <dt>Subject:</dt>
          <dd>Registration of channel binding tls-exporter</dd>
          <dt>Channel binding
          <dt>Channel-binding unique prefix:</dt>
          <dd>tls-exporter</dd>
          <dt>Channel binding
          <dt>Channel-binding type:</dt>
          <dd>unique</dd>
          <dt>Channel type:</dt>
          <dd><xref target="RFC8446">TLS</xref></dd>
          <dd>TLS <xref target="RFC8446"/></dd>
          <dt>Published specification:</dt>
          <dd>&docName;</dd>
          <dt>Channel binding
          <dd>RFC 9266</dd>
          <dt>Channel-binding is secret:</dt>
          <dd>no</dd>
          <dt>Description:</dt>
          <dd>The EKM value obtained from the current TLS connection.</dd>
          <dt>Intended usage:</dt>
          <dd>COMMON</dd>
          <dt>
            Person and email address to contact for further information:
          </dt>
          <dd>Sam Whited &lt;sam@samwhited.com&gt;.</dd> &lt;sam@samwhited.com&gt;</dd>
          <dt>Owner/Change controller name and email address:</dt>
          <dd>IESG.</dd>
          <dd>IESG</dd>
          <dt>Expert reviewer name and contact information:</dt>
          <dd>
            IETF KITTEN WG &lt;kitten@ietf.org&gt; or IETF TLS WG (kitten@ietf.org or tls@ietf.org, failing
            that, ietf@ietf.org). &lt;tls@ietf.org&gt;
          </dd>
          <dt>Note:</dt>
          <dd>
            See the published specification for advice on the applicability of
            this channel binding type.
          </dd>
        </dl>
      </section>
      <section anchor="exporter-registration" numbered="true" toc="default">
        <name>Registration of Channel Binding TLS Exporter Label</name>
        <t>
          This document adds
          IANA has added the following registration in the "TLS Exporter
          Labels" registry, which is part of registry under the "Transport Layer Security (TLS)
          Parameters" group: registry:
        </t>
        <dl>
          <dt>Value:</dt>
          <dd>EXPORTER-Channel-Binding</dd>
          <dt>DTLS-OK:</dt>
          <dd>Y</dd>
          <dt>Recommended:</dt>
          <dd>Y</dd>
          <dt>Reference:</dt>
          <dd>This document</dd>
          <dd>RFC 9266</dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5056.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5705.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5801.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5802.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5929.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7677.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8446.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5246.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7627.xml"/>

<reference anchor="TRIPLE-HANDSHAKE" target="https://www.mitls.org/pages/attacks/3SHAKE">
          <front>
            <title>Password Storage</title>
            <title>Triple Handshakes Considered Harmful: Breaking and Fixing Authentication over TLS</title>
            <author initials="K." surname="Bhargavan"/>
            <author initials="A." surname="Delignat-Lavaud"/>
            <author initials="C." surname="Fournet"/>
            <author initials="A." surname="Pironti"/>
            <author initials="P." surname="Strub"/>
            <date year="2014" month="March"/>
          </front>
        </reference>
      </references>
    </references>
  </back>
</rfc>