draft-ietf-tokbind-protocol-10.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 RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC7230 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7230.xml">
<!ENTITY RFC7540 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7540.xml">
<!ENTITY RFC5705 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5705.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC3447 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3447.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-protocol-10" 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>The Token Binding Protocol Version 1.0</title>

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

    <!-- Another author who claims to be an editor -->

    <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>

    <author fullname="Jeff Hodges" initials="J."
            surname="Hodges">
      <organization>Paypal</organization>

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

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

          <city></city>

          <region></region>

          <code></code>

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

        <email>Jeff.Hodges@paypal.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 Version 1.0 of the Token Binding protocol. The Token Binding 
      protocol allows client/server applications to create long-lived, uniquely identifiable TLS 
      <xref target="RFC5246" /> bindings spanning multiple TLS sessions and connections. 
      Applications are then enabled to cryptographically bind security tokens to the TLS layer, 
      preventing token export and replay attacks. To protect privacy, the Token Binding 
      identifiers are only transmitted encrypted and can be reset by the user at any time.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Servers generate various security tokens (e.g. HTTP cookies, OAuth tokens) for 
      applications to access protected resources. Any party in possession of such token 
      gains access to the protected resource. Attackers export bearer tokens from the user’s 
      machine, present them to the servers, and impersonate authenticated users. The idea of 
      Token Binding is to prevent such attacks by cryptographically binding security tokens to 
      the TLS layer.</t>

      <t>A Token Binding is established by the user agent generating a private-public key 
      pair (possibly within a secure hardware module, such as TPM) per target server, and 
      proving possession of the private key on every TLS connection to the target server. The 
      proof of possession involves signing the exported keying material <xref target="RFC5705" /> 
      for the TLS connection with the private key. The corresponding public key is included in the 
      Token Binding identifier structure (described in the <xref target="TBMessage-TBID"/> 
      "<xref target="TBMessage-TBID" format="title"/>"). Token Bindings are long-lived, i.e. they 
      encompass multiple TLS connections and TLS sessions between a given client and server. To 
      protect privacy, Token Binding IDs are never transmitted in clear text and can be reset by 
      the user at any time, e.g. when clearing browser cookies.</t>

      <t>When issuing a security token to a client that supports Token Binding, a server 
      includes the client’s Token Binding ID in the token. Later on, when a client presents 
      a security token containing a Token Binding ID, the server makes sure the ID in the 
      token matches the ID of the Token Binding established with the client. In the case of 
      a mismatch, the server discards the token.</t>

      <t>In order to successfully export and replay a bound security token, the attacker needs 
      to also be able to export the client’s private key, which is hard to do in the case of the 
      key generated in a secure hardware module.</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 Protocol Overview">
      <t>The client and server use the Token Binding Negotiation TLS Extension 
      <xref target="I-D.ietf-tokbind-negotiation"/> to negotiate the Token Binding protocol 
      version and the parameters (signature algorithm, length) of the Token Binding key. This 
      negotiation does not require additional round-trips.</t>

      <t>The Token Binding protocol consists of one message sent by the client to the server, 
      proving possession of one or more client-generated asymmetric keys. This message is 
      only sent if the client and server agree on the use of the Token Binding protocol and the 
      key parameters. The Token Binding message is sent with the application protocol data in TLS 
      application_data records.</t>

      <t>A server receiving the Token Binding message verifies that the key parameters in the 
      message match the Token Binding parameters negotiated via 
      <xref target="I-D.ietf-tokbind-negotiation"/>, and then validates the signatures contained 
      in the Token Binding message. If either of these checks fails, the server terminates the 
      connection, otherwise the Token Binding is successfully established with the ID 
      contained in the Token Binding message.</t>

      <t>When a server supporting the Token Binding protocol receives a bound token, the server 
      compares the Token Binding ID in the security token with the Token Binding ID 
      established with the client. If the bound token came from a TLS connection without a Token 
      Binding, or if the IDs don't match, the token is discarded.</t>

      <t>This document defines the format of the Token Binding protocol message, the process of 
      establishing a Token Binding, the format of the Token Binding ID, and the process of 
      validating a security token. Token Binding Negotiation TLS Extension 
      <xref target="I-D.ietf-tokbind-negotiation"/> describes the negotiation of the Token 
      Binding protocol and key parameters. Token Binding over HTTP 
      <xref target="I-D.ietf-tokbind-https"/> explains how the Token Binding message is 
      encapsulated within HTTP/1.1 <xref target="RFC7230"/> or HTTP/2 <xref target="RFC7540"/> 
      messages. <xref target="I-D.ietf-tokbind-https"/> also describes Token Binding between 
      multiple communicating parties: User Agent, Identity Provider and Relying Party.</t> 
    </section>

    <section title="Token Binding Protocol Message">
      <t>The Token Binding message is sent by the client to prove possession of one or more private 
      keys held by the client. This message MUST be sent if the client and server successfully 
      negotiated the use of the Token Binding protocol via 
      <xref target="I-D.ietf-tokbind-negotiation"/>, and MUST NOT be sent otherwise. This message 
      MUST be sent in the client's first application protocol message. This message MAY also be 
      sent in subsequent application protocol messages, proving possession of additional private 
      keys held by the same client, which can be used to facilitate token binding between more than 
      two communicating parties. For example, Token Binding over HTTP 
      <xref target="I-D.ietf-tokbind-https"/> specifies an encapsulation of the Token Binding 
      message in HTTP application protocol messages, as well as scenarios involving more than two 
      communicating parties.</t>
      
      <figure>
        <preamble>The Token Binding message format is defined using TLS Presentation Language (see 
        Section 4 of <xref target="RFC5246"/>):</preamble>

        <artwork><![CDATA[
  enum {
      rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255)
  } TokenBindingKeyParameters;

  struct {
      opaque modulus<1..2^16-1>;
      opaque publicexponent<1..2^8-1>;
  } RSAPublicKey;

  struct {
      opaque point <1..2^8-1>;
  } ECPoint;

  struct {
      TokenBindingKeyParameters key_parameters;
      uint16 key_length;  /* Length (in bytes) of the following 
                             TokenBindingID.TokenBindingPublicKey */
      select (key_parameters) {
          case rsa2048_pkcs1.5: 
          case rsa2048_pss:
              RSAPublicKey rsapubkey;
          case ecdsap256: 
              ECPoint point;
      } TokenBindingPublicKey;
  } TokenBindingID;

  enum {
      (255)        /* No initial ExtensionType registrations */
  } ExtensionType;

  struct {
      ExtensionType extension_type;
      opaque extension_data<0..2^16-1>;
  } Extension;

  enum {
      provided_token_binding(0), referred_token_binding(1), (255)
  } TokenBindingType;

  struct {
      TokenBindingType tokenbinding_type;
      TokenBindingID tokenbindingid;
      opaque signature<0..2^16-1>;  /* Signature over the concatenation of 
                                       tokenbinding_type, key_parameters and 
                                       exported keying material (EKM) */
      Extension extensions<0..2^16-1>;
  } TokenBinding;

  struct {
      TokenBinding tokenbindings<0..2^16-1>;
  } TokenBindingMessage;
        ]]></artwork>

        <postamble>The Token Binding message consists of a series of TokenBinding structures, each 
        containing the type of the token binding, the TokenBindingID, a signature using the Token 
        Binding key, optionally followed by Extension structures.
        </postamble>
      </figure>

      <section title="TokenBinding.tokenbinding_type">
        <t>This document defines two Token Binding types: 
          <list style="symbols">
            <t>provided_token_binding - used to establish a Token Binding when connecting to a 
            server.</t>
            <t>referred_token_binding - used when requesting tokens to be presented to a different 
            server.</t>
          </list>
        </t>

        <t>Token Binding over HTTP <xref target="I-D.ietf-tokbind-https"/> describes a use case for 
        referred_token_binding where Token Bindings are established between multiple communicating 
        parties: User Agent, Identity Provider and Relying Party. User Agent sends 
        referred_token_binding to the Identity Provider in order to prove possession of the Token 
        Binding key it uses with the Relying Party. The Identity Provider can then bind the token it 
        is supplying (for presentation to the Relying Party) to the Token Binding ID contained in the 
        referred_token_binding. Such bound token enjoys the protections discussed below in 
        <xref target="Security"/> "<xref target="Security" format="title"/>".</t>
      </section>

      <section anchor="TBMessage-TBID" title="TokenBinding.tokenbindingid">
        <t>The ID of the Token Binding established as a result of Token Binding message processing 
        contains the identifier of the key parameters negotiated via 
        <xref target="I-D.ietf-tokbind-negotiation"/>, the length (in bytes) of the Token Binding 
        public key, and the Token Binding public key itself. Token Binding ID can be obtained from 
        the TokenBinding structure by discarding the Token Binding type, signature and extensions.
        </t>

        <t>When rsa2048_pkcs1.5 or rsa2048_pss is used, RSAPublicKey.modulus and 
        RSAPublicKey.publicexponent contain the modulus and exponent of the 2048-bit RSA public key 
        represented in big-endian format, with leading zero bytes omitted.</t>

        <t>When ecdsap256 is used, ECPoint.point contains the X coordinate followed by the Y 
        coordinate of the Curve P-256 key. The X and Y coordinates are unsigned 32-byte integers 
        encoded in big-endian format, preserving any leading zero bytes. Future specifications may 
        define Token Binding keys using other elliptic curves with their corresponding signature 
        and point formats.</t>

        <t>Token Binding protocol implementations SHOULD make Token Binding IDs available to the 
        application as opaque byte sequences. E.g. server applications will use Token Binding IDs 
        when generating and verifying bound tokens.</t>
      </section>

      <section title="TokenBinding.signature">
        <t>When rsa2048_pkcs1.5 is used, TokenBinding.signature contains the signature generated 
        using the RSASSA-PKCS1-v1_5 signature scheme defined in <xref target="RFC3447"/> with 
        SHA256 as the hash function.</t>

        <t>When rsa2048_pss is used, TokenBinding.signature contains the signature generated using 
        the RSASSA-PSS signature scheme defined in <xref target="RFC3447"/> with SHA256 as the hash 
        function. MGF1 with SHA256 MUST be used as the mask generation function, and the salt 
        length MUST equal 32 bytes.</t>

        <t>When ecdsap256 is used, TokenBinding.signature contains a pair of 32-byte integers, R 
        followed by S, generated with ECDSA using Curve P-256 and SHA256 as defined in 
        <xref target="ANSI.X9-62.2005"/> and <xref target="FIPS.186-4.2013"/>. R and S are encoded 
        in big-endian format, preserving any leading zero bytes.</t>

        <t>The signature is computed over the byte string representing the concatenation of:
          <list style="symbols">
            <t>TokenBindingType value contained in the TokenBinding.tokenbinding_type field;</t>
            <t>TokenBindingKeyParameters value contained in the TokenBindingID.key_parameters 
            field;</t>
            <t>Exported keying material (EKM) value obtained from the current TLS connection.</t>
          </list>
        </t>

        <t>The EKM is obtained using the Keying Material Exporters for TLS defined in 
        <xref target="RFC5705" />, by supplying the following input values:
          <list style="symbols">
            <t>Label: The ASCII string "EXPORTER-Token-Binding" with no terminating NUL.</t>
            <t>Context value: NULL (no application context supplied).</t>
            <t>Length: 32 bytes.</t>
          </list>
        </t>
      </section>

      <section title="TokenBinding.extensions">
        <t>A Token Binding message may optionally contain a series of Extension structures, each 
        consisting of an extension_type and extension_data. The structure and meaning of 
        extension_data depends on the specific extension_type.</t>

        <t>Initially, no extension types are defined (see <xref target="IANA-TBExts"/> 
        "<xref target="IANA-TBExts" format="title"/>"). One of the possible uses of extensions 
        envisioned at the time of this writing is attestation: cryptographic proof that allows the 
        server to verify that the Token Binding key is hardware-bound. The definitions of such 
        Token Binding protocol extensions are outside the scope of this specification.</t>

        <t>An implementation MUST ignore any unknown Token Binding types.</t>
      </section>

    </section>
    
    <section title="Establishing a Token Binding">
      <section title="Client Processing Rules">
        <t>The client MUST include at least one TokenBinding structure in the Token Binding message. 
        The key parameters used in the provided_token_binding MUST match those negotiated with the 
        server via <xref target="I-D.ietf-tokbind-negotiation"/>.</t>
        
        <t>The client SHOULD generate and store Token Binding keys in a secure manner that prevents 
        key export. In order to prevent cooperating servers from linking user identities, different 
        keys SHOULD be used by the client for connections to different servers, according to the 
        token scoping rules of the application protocol.</t>

        <t>When the client needs to send a referred_token_binding to the Identity Provider, the 
        client SHALL construct the referred TokenBinding structure in the following manner: 
          <list style="symbols">
            <t>Set TokenBinding.tokenbinding_type to referred_token_binding.</t>
            <t>Set TokenBinding.tokenbindingid to the Token Binding ID used with the Relying 
            Party.</t>
            <t>Generate TokenBinding.signature, using the EKM value of the TLS connection to the 
            Identity Provider, the Token Binding key established with the Relying Party and the 
            signature algorithm indicated by the associated key parameters. Note that these key 
            parameters may differ from the key parameters negotiated with the Identity Provider.
            </t>
          </list>
        Conveying referred Token Bindings in this fashion allows the Identity Provider to verify 
        that the client controls the Token Binding key used with the Relying Party.</t>
      </section>

      <section title="Server Processing Rules">
        <t>The triple handshake vulnerability in TLS 1.2 and older TLS versions affects the 
        security of the Token Binding protocol, as described in <xref target="Security"/> 
        "<xref target="Security" format="title"/>". Therefore, the server MUST NOT negotiate the 
        use of the Token Binding protocol with these TLS versions, unless the server also 
        negotiates the Extended Master Secret <xref target="RFC7627"/> TLS extension. In addition, 
        the server MUST NOT initiate or allow TLS renegotiation, unless the Renegotiation 
        Indication <xref target="RFC5746" /> TLS extension has been negotiated.</t>

        <t>The server MUST terminate the connection if the use of the Token Binding protocol was 
        not negotiated, but the client sends the Token Binding message. If the Token Binding type 
        is "provided_token_binding", the server MUST verify that the signature algorithm (including
        elliptic curve in the case of ECDSA) and key length in the Token Binding message match 
        those negotiated via <xref target="I-D.ietf-tokbind-negotiation"/>. In the case of a 
        mismatch, the server MUST terminate the connection. Token Bindings of type 
        "referred_token_binding" may use different key parameters than those negotiated with this 
        client.</t>
        
        <t>If the Token Binding message does not contain at least one TokenBinding structure, 
        or if a signature contained in any TokenBinding structure is invalid, the server MUST 
        terminate the connection. </t>
        
        <t>Servers MUST ignore any unknown extensions. Initially, no extension types are defined 
        (see <xref target="IANA-TBExts"/> "<xref target="IANA-TBExts" format="title"/>").</t>
        
        <t>If all checks defined above have passed successfully, the Token Binding between this 
        client and server is established. The Token Binding ID(s) conveyed in the Token Binding 
        Message can be provided to the server-side application. The application may then use the 
        Token Binding IDs for bound security token creation and validation, see 
        <xref target="BoundSecurityToken"/>.</t>
      </section>
    </section>

    <section title="Bound Security Token Creation and Validation" anchor="BoundSecurityToken">
      <t>Security tokens can be bound to the TLS layer either by embedding the Token Binding ID 
      in the token, or by maintaining a database mapping tokens to Token Binding IDs. The
      specific method of generating bound security tokens is application-defined and beyond the
      scope of this document. Note that applicable security considerations are outlined in <xref
      target="Security"/>.</t>
      
      <t>Either or both clients and servers MAY create bound security tokens. For example, HTTPS
      servers employing Token Binding for securing their HTTP cookies will bind the cookies. In the
      case of a server-initiated challenge-response protocol employing Token Binding and TLS, the
      client can, for example, incorporate the Token Binding ID within the signed object it 
      returns, thus binding the object.</t>

      <t>Upon receipt of a security token, the server attempts to retrieve Token Binding ID 
      information from the token and from the TLS connection with the client.
      Application-provided policy determines whether to honor non-bound (bearer) tokens. If the
      token is bound and a Token Binding has not been established for the client connection, 
      the server MUST discard the token. If the Token Binding ID for the token does not match 
      the Token Binding ID established for the client connection, the server MUST discard the
      token.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This section establishes three IANA registries: "Token Binding Key Parameters", "Token 
      Binding Types" and "Token Binding Extensions". It also registers a new TLS exporter label in 
      the TLS Exporter Label Registry.</t>

      <section anchor="IANA-TBKeyParams" title="Token Binding Key Parameters Registry">
        <t>This document establishes a registry for identifiers of Token Binding key parameters 
        entitled "Token Binding Key Parameters" under the "Token Binding Protocol" heading.</t>

        <t>Entries in this registry require the following fields:
          <list style="symbols">
            <t>Value: The octet value that identifies a set of Token Binding key parameters 
            (0-255).</t>
            <t>Description: The description of the Token Binding key parameters.</t>
            <t>Specification: A reference to a specification that defines the Token Binding key 
            parameters.</t>
          </list>
        </t>

        <t>This registry operates under the "Expert Review" policy as defined in 
        <xref target="RFC5226"/>. The designated expert is advised to encourage the inclusion of a 
        reference to a permanent and readily available specification that enables the creation of 
        interoperable implementations using the identified set of Token Binding key parameters.</t>

        <t>An initial set of registrations for this registry follows:
          <list style="empty">
            <t>Value: 0</t>
            <t>Description: rsa2048_pkcs1.5</t>
            <t>Specification: this document</t>
          </list>

          <list style="empty">
            <t>Value: 1</t>
            <t>Description: rsa2048_pss</t>
            <t>Specification: this document</t>
          </list>

          <list style="empty">
            <t>Value: 2</t>
            <t>Description: ecdsap256</t>
            <t>Specification: this document</t>
          </list>
        </t>
      </section>

      <section anchor="IANA-TBTypes" title="Token Binding Types Registry">
        <t>This document establishes a registry for Token Binding type identifiers entitled "Token 
        Binding Types" under the "Token Binding Protocol" heading.</t>

        <t>Entries in this registry require the following fields:
          <list style="symbols">
            <t>Value: The octet value that identifies the Token Binding type (0-255).</t>
            <t>Description: The description of the Token Binding type.</t>
            <t>Specification: A reference to a specification that defines the Token Binding 
            type.</t>
          </list>
        </t>

        <t>This registry operates under the "Expert Review" policy as defined in 
        <xref target="RFC5226"/>. The designated expert is advised to encourage the inclusion of a 
        reference to a permanent and readily available specification that enables the creation of 
        interoperable implementations using the identified Token Binding type.</t>

        <t>An initial set of registrations for this registry follows:
          <list style="empty">
            <t>Value: 0</t>
            <t>Description: provided_token_binding</t>
            <t>Specification: this document</t>
          </list>

          <list style="empty">
            <t>Value: 1</t>
            <t>Description: referred_token_binding</t>
            <t>Specification: this document</t>
          </list>
        </t>
      </section>
     
      <section anchor="IANA-TBExts" title="Token Binding Extensions Registry">
        <t>This document establishes a registry for Token Binding extensions entitled "Token 
        Binding Extensions" under the "Token Binding Protocol" heading.</t>

        <t>Entries in this registry require the following fields:
          <list style="symbols">
            <t>Value: The octet value that identifies the Token Binding extension (0-255).</t>
            <t>Description: The description of the Token Binding extension.</t>
            <t>Specification: A reference to a specification that defines the Token Binding 
            extension.</t>
          </list>
        </t>

        <t>This registry operates under the "Expert Review" policy as defined in 
        <xref target="RFC5226"/>. The designated expert is advised to encourage the inclusion of a 
        reference to a permanent and readily available specification that enables the creation of 
        interoperable implementations using the identified Token Binding extension. This document 
        creates no initial registrations in the "Token Binding Extensions" registry.</t>
      </section>

      <section anchor="IANA-TBExpLab" title="Registration of Token Binding TLS Exporter Label">
        <t>This document adds a registration for the "EXPORTER-Token-Binding" value in the TLS
        Exporter Label Registry to correspond to this specification.</t>
      </section>
    </section> <!-- IANA Considerations -->
    
    <section anchor="Security" title="Security Considerations">
      <section anchor="Security-TokenReplay" title="Security Token Replay">
        <t>The goal of the Token Binding protocol is to prevent attackers from exporting and 
        replaying security tokens, thereby impersonating legitimate users and gaining access to 
        protected resources. Bound tokens can still be replayed by the malware present in the 
        User Agent. In order to export the token to another machine and successfully replay it, 
        the attacker also needs to export the corresponding private key. Token Binding private 
        keys are therefore high-value assets and SHOULD be strongly protected, ideally by 
        generating them in a hardware security module that prevents key export.</t>
        <t>The manner in which a token is bound to the TLS layer is application-defined and beyond 
        the scope of this document. However, the resulting bound token needs to be 
        integrity-protected, so that an attacker cannot remove the binding or substitute a Token 
        Binding ID of their choice without detection.</t>
      </section>
      <section title="Downgrade Attacks">
        <t>The Token Binding protocol is only used when negotiated via 
        <xref target="I-D.ietf-tokbind-negotiation"/> 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 Negotiation TLS Extension 
        used to negotiate the Token Binding protocol and key parameters. The signature algorithm 
        and key length used in the TokenBinding of type "provided_token_binding" MUST match the 
        parameters negotiated via <xref target="I-D.ietf-tokbind-negotiation"/>.</t>
      </section>
      
      <section title="Privacy Considerations" anchor="privacy-cons">
        <t>The Token Binding protocol uses persistent, long-lived Token Binding IDs. To protect 
        privacy, Token Binding IDs are never transmitted in clear text and can be reset by the user 
        at any time, e.g. when clearing browser cookies. Some applications offer a special privacy 
        mode where they don't store or use tokens supplied by the server, e.g. "in private" 
        browsing. When operating in this special privacy mode, applications SHOULD use newly 
        generated Token Binding keys and delete them when exiting this mode, or else SHOULD 
        NOT negotiate Token Binding at all.</t>

        <t>In order to prevent cooperating servers from linking user identities, different keys 
        MUST be used by the client for connections to different servers, according to the token 
        scoping rules of the application protocol.</t>

        <t>A server can use tokens and Token Binding IDs to track clients. Client applications that 
        automatically limit the lifetime or scope of tokens to maintain user privacy SHOULD apply 
        the same validity time and scope limits to Token Binding keys.</t>
      </section>

      <section title="Token Binding Key Sharing Between Applications">
        <t>Existing systems provide a variety of platform-specific mechanisms for certain 
        applications to share tokens, e.g. to enable single sign-on scenarios. For these scenarios 
        to keep working with bound tokens, the applications that are allowed to share tokens will 
        need to also share Token Binding keys. Care must be taken to restrict the sharing of Token 
        Binding keys to the same group(s) of applications that share the same tokens.</t>
      </section>
      <section title="Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions">
        <t>The Token Binding protocol relies on the exported keying material (EKM) 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 the 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" /> 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;
      &RFC5246;
      &RFC7230;
      &RFC7540;
      &RFC5705;
      &RFC5226;
      &RFC3447;
      &RFC7627;
      &RFC5746;
      <?rfc include="reference.I-D.ietf-tokbind-negotiation.xml"?>
      <?rfc include="reference.I-D.ietf-tokbind-https.xml"?>
      <reference anchor="ANSI.X9-62.2005">

        <front>

          <title>Public Key Cryptography for the Financial Services Industry, The Elliptic Curve 
          Digital Signature Algorithm (ECDSA)</title>

          <author>

            <organization>American National Standards Institute</organization>

          </author>

          <date year="2005" />

        </front>

        <seriesInfo name="ANSI" value="X9.62" />

      </reference>

      <reference anchor="FIPS.186-4.2013">

        <front>

          <title>Digital Signature Standard (DSS)</title>

          <author>

            <organization>National Institute of Standards and Technology</organization>

          </author>

          <date year="2013" />

        </front>

        <seriesInfo name="FIPS" value="186-4" />

      </reference>

    </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 2014-08-21  Andrei Popov   Initial version.
      v00 2015-03-27  Andrei Popov   Renamed as tokbind WG draft.
      v01 2015-05-26  Andrei Popov   Replaced ALPN-based TB negotiation with TBNEGO.
      v02 2015-09-11  Andrei Popov   Replaced TLS-UNIQUE with RFC5705 exporters, SignatureAndHashAlgorithm with 1-byte key parameters IDs from TBNEGO.
      v03 2015-10-06  Andrei Popov   Removed ECDSAParams because NamedCurve is indicated by key_parameters.
      v04 2016-01-08  Andrei Popov   Moved TB type out of the TB ID, added requirement for Renegotiation Indication, specified public key and signature formats.
      v05 2016-03-24  Andrei Popov   Merged =JeffH's IANA PR and added him as a co-author.
      v06 2016-04-11  Andrei Popov   Per IETF95 feedback, clarified that TB types should be skipped.
      v06 2016-05-19  Andrei Popov   Merged Jeff's PR on referred TB processing.
      v06 2016-05-20  Andrei Popov   Clarified ECDSAP256 parameters per Brian's feedback.
      v07 2016-07-06  Andrei Popov   Noted that TB IDs should be presented to the application as opaque byte sequences.
      v07 2016-07-07  Andrei Popov   Moved the TB ID registry from TBNEGO to TBPROTO.
      v08 2016-07-08  Jeff Hodges    comments in tls preso language are `/*...*/` not `//`
                                     fixed line-length overrun in figure, indent figure,
                                     RFC4492 is not referenced from the text, retitle
                                     Sec Token Validation section to denote actual scope, 
                                     xref to sec cons, and fix #22.
      v08 2016-07-08  Andrei Popov   Harminized terminology to address issues ## 50, 51.
      v09 2016-07-23  Jeff Hodges &  Initialize -09.
                      Mike Jones     Michael Jones -> Michael B. Jones (there's too many of me!) ;-)
      v09 2016-08-23  Andrei Popov   Merged PR #54.
      v09 2016-08-25  Andrei Popov   Clarified PKCS and PSS parameters, changed signature to cover protocol version and TB type to prevent cross-protocol attacks.
      v09 2016-08-26  Andrei Popov   Added Token Binding public key length field in the TokenBindingID struct, addressed editorial comments.
      v10 2016-09-02  Andrei Popov   Clarified the language describing the hash and signature operations, per Brian's comments.
    -->
  </back>
</rfc>