draft-ietf-tokbind-negotiation-05.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 RFC4366 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.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-05" 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>

    <author fullname="Adam Langley" initials="A."
            surname="Langley">
      <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>agl@google.com</email>

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

    <date year="2016" />

    <!-- 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) <xref target="RFC5246" /> 
      extension for the negotiation of Token Binding protocol 
      <xref target="I-D.ietf-tokbind-protocol"/> version and key parameters.</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 
      extension to accomplish this negotiation without introducing additional network 
      round-trips.</t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref target="RFC2119" />.</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;
} ProtocolVersion;

enum {
    (255)
} TokenBindingKeyParameters;

struct {
    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.  This SHOULD be the latest (highest valued) version 
      supported by the client. <xref target="I-D.ietf-tokbind-protocol"/> describes version {1, 0} 
      of the protocol. 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"/> defines an initial set of identifiers for Token 
      Binding key parameters.</t>
    </section>

    <section 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" /> TLS 
        extension. This requirement only applies when TLS 1.2 or an older TLS version is used (see 
        security considerations section below for more details).</t>
        <t>The server is also negotiating the Renegotiation Indication <xref target="RFC5746" /> 
        TLS extension. This requirement only applies if the TLS server is configured to initiate or 
        allow renegotiation.</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 the Token Binding protocol version offered 
      by the client in the "token_binding" extension and the highest version supported by the 
      server.</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 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 
      "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" /> TLS extension is not negotiated (see security considerations 
        section below for more details).</t>
        <t>The client is configured to initiate or allow renegotiation, but the Renegotiation 
        Indication <xref target="RFC5746" /> TLS extension is not negotiated.</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. In this case, 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.</t>

      <t>Please note that 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 originally created in 
      <xref target="RFC4366"/>. 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>
        </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 title="Security Considerations">
      <section title="Downgrade Attacks">
        <t>The Token Binding protocol version and key parameters are negotiated via 
        "token_binding" extension  within the TLS handshake. TLS prevents active attackers from 
        modifying the messages of the TLS handshake, therefore it is not possible for the attacker 
        to remove or modify the "token_binding" extension. The signature algorithm and key length 
        used in the TokenBinding of type "provided_token_binding" MUST match the parameters 
        negotiated via "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 TLS protocol vulnerability allowing the attacker 
        to synchronize exported 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" /> TLS extension has also been negotiated. In addition, TLS 
        renegotiation MUST NOT be initiated or allowed, unless the Renegotiation Indication 
        <xref target="RFC5746" /> TLS extension has 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 and others.</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;
      &RFC4366;
      &RFC5246;
      &RFC5226;
      &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>
    </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).
    -->
  </back>
</rfc>