draft-ietf-tokbind-negotiation-14.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5705 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5705.xml">
<!ENTITY RFC7627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7627.xml">
<!ENTITY RFC5746 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5746.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-tokbind-negotiation-14" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Token Binding Negotiation TLS Extension">
      Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
    </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <author fullname="Andrei Popov" initials="A." 
            surname="Popov" role="editor">
      <organization>Microsoft Corp.</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country>USA</country>
        </postal>

        <email>andreipo@microsoft.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Magnus Nyström" initials="M."
            surname="Nyström">
      <organization>Microsoft Corp.</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country>USA</country>
        </postal>

        <email>mnystrom@microsoft.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Dirk Balfanz" initials="D."
            surname="Balfanz">
      <organization>Google Inc.</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country>USA</country>
        </postal>

        <email>balfanz@google.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2018" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>draft</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document specifies a Transport Layer Security (TLS) extension for the negotiation of 
      the Token Binding protocol version and key parameters. Negotiation of Token Binding in TLS 
      1.3 and later versions is beyond the scope of this document.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>In order to use the Token Binding protocol <xref target="I-D.ietf-tokbind-protocol"/>, 
      the client and server need to agree on the Token Binding protocol version and the parameters 
      (signature algorithm, length) of the Token Binding key. This document specifies a new TLS 
      <xref target="RFC5246" /> extension to accomplish this negotiation without introducing 
      additional network round-trips in TLS 1.2 and earlier versions. 
      <xref target="I-D.ietf-tokbind-tls13"/> describes the negotiation of the Token Binding 
      protocol and key parameters in combination with TLS 1.3 and later versions.</t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
        NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
        interpreted as described in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174" /> 
        when, and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>

    <section title="Token Binding Negotiation Client Hello Extension">
      <t>The client uses the "token_binding" TLS extension to indicate the highest supported Token 
      Binding protocol version and key parameters.</t>

        <figure>
        <artwork align="left"><![CDATA[
enum {
    token_binding(24), (65535)
} ExtensionType;
        ]]></artwork>
        </figure>

        <t>The "extension_data" field of this extension contains a "TokenBindingParameters" value.</t>

        <figure>
        <artwork align="left"><![CDATA[
struct {
    uint8 major;
    uint8 minor;
} TB_ProtocolVersion;

enum {
    rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255)
} TokenBindingKeyParameters;

struct {
    TB_ProtocolVersion token_binding_version;
    TokenBindingKeyParameters key_parameters_list<1..2^8-1>
} TokenBindingParameters;
        ]]></artwork>
        </figure>

      <t>"token_binding_version" indicates the version of the Token Binding protocol the client 
      wishes to use during this connection. If the client supports multiple Token Binding protocol 
      versions, it SHOULD indicate the latest supported version (the one with the highest 
      TB_ProtocolVersion.major and TB_ProtocolVersion.minor) in 
      TokenBindingParameters.token_binding_version. E.g. if the client supports versions {1, 0} and 
      {0, 13} of the Token Binding protocol, it SHOULD indicate version {1, 0}. Please note that 
      the server MAY select any lower protocol version, see <xref target="Server"/> 
      "<xref target="Server" format="title"/>" for more details. If the client does not support the 
      Token Binding protocol version selected by the server, then the connection proceeds without 
      Token Binding. <xref target="I-D.ietf-tokbind-protocol"/> describes version {1, 0} of the 
      protocol.</t>

      <t>Please note that the representation of the Token Binding protocol version using two octets 
      ("major" and "minor") is for human convenience only and carries no protocol significance.</t>

      <t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: Prototype implementations of Token 
      Binding drafts can indicate support of a specific draft version, e.g. {0, 1} or {0, 2}.</t>

      <t>"key_parameters_list" contains the list of identifiers of the Token Binding key 
      parameters supported by the client, in descending order of preference. 
      <xref target="I-D.ietf-tokbind-protocol"/> establishes an IANA registry for Token Binding key 
      parameter identifiers.</t>
    </section>

    <section anchor="Server" title="Token Binding Negotiation Server Hello Extension">
      <t>The server uses the "token_binding" TLS extension to indicate support for the Token 
      Binding protocol and to select the protocol version and key parameters.</t>

      <t>The server that supports Token Binding and receives a client hello message containing the 
      "token_binding" extension will include the "token_binding" extension in the server hello if 
      all of the following conditions are satisfied:
      <list style="numbers">
        <t>The server supports the Token Binding protocol version offered by the client or a lower 
        version.</t>
        <t>The server finds acceptable Token Binding key parameters on the client's list.</t>
        <t>The server is also negotiating the Extended Master Secret <xref target="RFC7627" /> and 
        Renegotiation Indication <xref target="RFC5746" /> TLS extensions. This requirement applies 
        when TLS 1.2 or an older TLS version is used (see <xref target="Security"/> 
        "<xref target="Security" format="title"/>" below for more details).</t>
      </list></t>

      <t>The server will ignore any key parameters that it does not recognize. The 
      "extension_data" field of the "token_binding" extension is structured the same as described 
      above for the client "extension_data".</t>

      <t>"token_binding_version" contains the lower of: 
        <list style="symbols">
          <t>the Token Binding protocol version offered by the client in the "token_binding" 
          extension and</t>
          <t>the highest Token Binding protocol version supported by the server.</t>
        </list>
      </t>

      <t>"key_parameters_list" contains exactly one Token Binding key parameters identifier 
      selected by the server from the client's list.</t>
    </section>

    <section anchor="Negotiating" title="Negotiating Token Binding Protocol Version and Key Parameters">
      <t>It is expected that a server will have a list of Token Binding key parameters identifiers 
      that it supports, in preference order. The server MUST only select an identifier that the 
      client offered. The server SHOULD select the most highly preferred key parameters identifier 
      it supports which is also advertised by the client. In the event that the server supports 
      none of the key parameters that the client advertises, then the server MUST NOT include 
      the "token_binding" extension in the server hello.</t>

      <t>The client receiving the "token_binding" extension MUST terminate the handshake with a 
      fatal "unsupported_extension" alert if any of the following conditions are true:
      <list style="numbers">
        <t>The client did not include the "token_binding" extension in the client hello.</t>
        <t>"token_binding_version" is higher than the Token Binding protocol version advertised by 
        the client.</t>
        <t>"key_parameters_list" includes more than one Token Binding key parameters 
        identifier.</t>
        <t>"key_parameters_list" includes an identifier that was not advertised by the client.</t>
        <t>TLS 1.2 or an older TLS version is used, but the Extended Master Secret 
        <xref target="RFC7627" /> and TLS Renegotiation Indication <xref target="RFC5746" /> 
        extensions are not negotiated (see <xref target="Security"/> 
        "<xref target="Security" format="title"/>" below for more details).</t>
      </list></t>

      <t>If the "token_binding" extension is included in the server hello and the client supports 
      the Token Binding protocol version selected by the server, it means that the version and key 
      parameters have been negotiated between the client and the server and SHALL be definitive for 
      the TLS connection. TLS 1.2 and earlier versions support renegotiation, allowing the client 
      and server to renegotiate the Token Binding protocol version and key parameters on the same 
      connection. The client MUST use the negotiated key parameters in the "provided_token_binding" 
      as described in <xref target="I-D.ietf-tokbind-protocol"/>.</t>

      <t>If the client does not support the Token Binding protocol version selected by the server, 
      then the connection proceeds without Token Binding. There is no requirement for the client to 
      support any Token Binding versions other than the one advertised in the client's 
      "token_binding" extension.</t>

      <t>Client and server applications can choose to handle failure to negotiate Token Binding in 
      a variety of ways, e.g.: continue using the connection as usual, shorten the lifetime of 
      tokens issued during this connection, require stronger authentication, terminate the 
      connection, etc.</t>

      <t>The Token Binding protocol version and key parameters are negotiated for each TLS 
      connection, which means that the client and server include their "token_binding" 
      extensions both in the full TLS handshake that establishes a new TLS session and in the 
      subsequent abbreviated TLS handshakes that resume the TLS session.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document updates the TLS "ExtensionType Values" registry. IANA has provided the 
      following temporary registration for the "token_binding" TLS extension:
        <list style="empty">
          <t>Value: 24</t>
          <t>Extension name: token_binding</t>
          <t>Reference: this document</t>
          <t>Recommended: Yes</t>
        </list>
        IANA is requested to make this registration permanent, keeping the value of 24, which has 
        been used by the prototype implementations of the Token Binding protocol.
      </t>

      <t>This document uses "Token Binding Key Parameters" registry originally created in 
      <xref target="I-D.ietf-tokbind-protocol"/>. This document creates no new registrations in 
      this registry.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <section title="Downgrade Attacks">
        <t>The Token Binding protocol version and key parameters are negotiated via the 
        "token_binding" extension  within the TLS handshake. TLS detects handshake message 
        modification by active attackers, therefore it is not possible for an attacker to remove 
        or modify the "token_binding" extension without breaking the TLS handshake. The signature 
        algorithm and key length used in the Token Binding of type "provided_token_binding" MUST 
        match the parameters negotiated via the "token_binding" extension.</t>
      </section>
      <section title="Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions">
        <t>The Token Binding protocol relies on the TLS Exporters <xref target="RFC5705" /> to 
        associate a TLS connection with a Token Binding. The triple handshake attack 
        <xref target="TRIPLE-HS" /> is a known vulnerability in TLS 1.2 and older TLS versions, 
        allowing an attacker to synchronize keying material between TLS connections. The attacker 
        can then successfully replay bound tokens. For this reason, the Token Binding protocol MUST 
        NOT be negotiated with these TLS versions, unless the Extended Master Secret 
        <xref target="RFC7627" /> and Renegotiation Indication <xref target="RFC5746" /> TLS 
        extensions have also been negotiated.</t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This document incorporates comments and suggestions offered by Eric Rescorla, Gabriel 
      Montenegro, Martin Thomson, Vinod Anupam, Anthony Nadalin, Michael B. Jones, Bill Cox, Nick 
      Harper, Brian Campbell, Benjamin Kaduk, Alexey Melnikov and others.</t>
      <t>This document was produced under the chairmanship of John Bradley and Leif Johansson. 
      The area directors included Eric Rescorla, Kathleen Moriarty and Stephen Farrell.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      &RFC2119;
      &RFC8174;
      &RFC5246;
      &RFC5705;
      &RFC7627;
      &RFC5746;
      <?rfc include="reference.I-D.ietf-tokbind-protocol.xml"?>
    </references>

    <references title="Informative References">
      <reference anchor="TRIPLE-HS">
        <front>
          <title>Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over 
          TLS. IEEE Symposium on Security and Privacy</title>
          <author initials="K." surname="Bhargavan">
            <organization>Inria Paris-Rocquencourt</organization>
          </author>
          <author initials="A." surname="Delignat-Lavaud">
            <organization>Inria Paris-Rocquencourt</organization>
          </author>
          <author initials="C." surname="Fournet">
            <organization>Inria Paris-Rocquencourt</organization>
          </author>
          <author initials="A." surname="Pironti">
            <organization>Inria Paris-Rocquencourt</organization>
          </author>
          <author initials="P." surname="Strub">
            <organization>Inria Paris-Rocquencourt</organization>
          </author>
          <date year="2014" />
        </front>
      </reference>
      <?rfc include="reference.I-D.ietf-tokbind-tls13.xml"?>
    </references>

    <!-- Change Log
      v00 2015-05-07  Andrei Popov   Initial version.
      v00 2015-09-09  Andrei Popov   Added TLS-style TB version negotiation, limited key parameters list to 1..2^8-1.
      v01 2015-10-06  Andrei Popov   Removed _SHA256 suffixes from TB key parameters.
      v02 2016-01-08  Andrei Popov   Added requirement for Renegotiation Indication.
      v03 2016-07-07  Andrei Popov   Moved the TB ID registry to TBPROTO.
      v04 2016-08-23  Andrei Popov   Merged PR #58.
      v04 2016-08-26  Andrei Popov   Clarified that renegotiation indication ext. is only needed when renegotiation is enabled.
      v05 2016-09-02  Andrei Popov   Corrected acknowledgements (it's Michael B. Jones).
      v06 2016-11-16  Andrei Popov   Undid the change from 2016-08-26 above. Renegotiation indication is always needed.
      v07 2016-12-23  Andrei Popov   Clarifying the TLS versions affected by the triple handshake attack.
      v08 2017-04-04  Andrei Popov   Incorporating WGLC comments.
      v09 2017-07-20  Andrei Popov   Fixing ID nits.
      v10 2017-10-15  Andrei Popov   Addressing AD review comments.
      v11 2018-04-11  Andrei Popov   Updating IANA considerations: Recommended column has been added to the extensions registry.
                                     Clarifying the version negotiation language as suggested by EKR.
                                     Acknowledging tokbind chairs and ADs.
      v12 2018-04-30  Andrei Popov   Clarifying the version negotiation language as suggested by Paul Kyzivat.
      v13 2018-05-09  Andrei Popov   Incorporating GEN-ART review feedback.
      v14 2018-05-23  Andrei Popov   Incorporating IESG review feedback.
      v14 2018-07-24  Andrei Popov   Adding informative reference to the TBTLS13 document.
                                     Adding language in the Abstract saying TLS 1.3 and later versions are out of scope.
                                     Removing Adam Langley from the co-authors list, according to his request.
    -->
  </back>
</rfc>