draft-ietf-tokbind-protocol-19.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 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 RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8017 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8017.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">
<!ENTITY RFC6749 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749.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-19" 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="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="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 Version 1.0 of the Token Binding protocol. The Token Binding 
      protocol allows client/server applications to create long-lived, uniquely identifiable TLS 
      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 conveyed over TLS and can 
      be reset by the user at any time.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Servers often generate various security tokens (e.g. HTTP cookies, OAuth 
      <xref target="RFC6749" /> tokens) for applications to present when accessing protected 
      resources. In general, any party in possession of bearer security tokens gain access to 
      certain protected resource(s). Attackers take advantage of this by exporting bearer tokens 
      from user’s application connections or machines, presenting them to application servers, and 
      impersonating authenticated users. The idea of Token Binding is to prevent such attacks by 
      cryptographically binding application security tokens to the underlying TLS 
      <xref target="RFC5246" /> layer.</t>

      <t>A Token Binding is established by a user agent generating a private-public key pair 
      (possibly within a secure hardware module, such as a Trusted Platform Module) per target 
      server, providing the public key to the server, and proving possession of the corresponding 
      private key, on every TLS connection to the server. The proof of possession involves signing 
      the exported keying material (EKM) <xref target="RFC5705" /> from 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 conveyed over insecure connections 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 (or its cryptographic hash) in the token. Later on, 
      when a client presents a security token containing a Token Binding ID, the server verifies 
      that the ID in the token matches the ID of the Token Binding established with the client. In 
      the case of a mismatch, the server rejects the token (details are application-specific).</t>

      <t>In order to successfully export and replay a bound security token, an attacker needs to 
      also be able to use the client’s private key, which is hard to do if the key is specially 
      protected, e.g., 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", "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 Protocol Overview">
      <t>In the course of a TLS handshake, a client and server can 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>As described in <xref target="I-D.ietf-tokbind-negotiation"/>, version 1.0 of the Token 
      Binding protocol is represented by TB_ProtocolVersion.major = 1 and TB_ProtocolVersion.minor 
      = 0 in the Token Binding Negotiation TLS Extension.</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 private keys. This message is 
      not sent if the Token Binding Negotiation has been unsuccessful. The Token Binding message is 
      sent with the application protocol data over TLS.</t>

      <t>A server receiving the Token Binding message verifies that the key parameters in the 
      message match the Token Binding parameters negotiated (e.g., 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 rejects the 
      binding, along with all associated bound tokens. 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 token with the Token Binding ID established with the 
      client. If the bound token is received on a TLS connection without a Token Binding, or if the 
      Token Binding IDs do not match, the token is rejected.</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 bound 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 (e.g., via 
      <xref target="I-D.ietf-tokbind-negotiation"/> or a different mechanism), 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>;
  } TB_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: 
              TB_ECPoint point;
      } TokenBindingPublicKey;
  } TokenBindingID;

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

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

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

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

  struct {
      TokenBinding tokenbindings<132..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 TB_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 that are intended 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.</t>

        <t>An implementation MUST ignore any unknown Token Binding types.</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 negotiated key parameters, the length (in bytes) of the 
        Token Binding public key, and the Token Binding public key itself. The 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 a 2048-bit RSA public key 
        represented in big-endian format, with leading zero bytes omitted.</t>

        <t>When ecdsap256 is used, TB_ECPoint.point contains the X coordinate followed by the Y 
        coordinate of a 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, so that applications do not rely on a particular 
        Token Binding ID structure. 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="RFC8017"/> with 
        SHA256 <xref target="FIPS.180-2.2002"/> 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="RFC8017"/> 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>Please note that TLS 1.2 and earlier versions support renegotiation, which produces a 
        new TLS master secret for the same connection, with associated session keys and EKM value. 
        TokenBinding.signature MUST be a signature of the EKM value derived from the TLS master 
        secret that produced the session keys encrypting the TLS application_data record(s) 
        containing this TokenBinding. Such use of the current EKM for the TLS connection makes 
        replay of bound tokens within renegotiated TLS sessions detectable, but requires the 
        application to synchronize Token Binding message generation and verification with the TLS 
        handshake state.</t>

        <t>Specifications defining the use of Token Binding with application protocols, such as 
        Token Binding over HTTP <xref target="I-D.ietf-tokbind-https"/>, MAY prohibit the use of 
        TLS renegotiation in combination with Token Binding, obviating the need for such 
        synchronization. Alternatively, such specifications need to define a way to determine which 
        EKM value corresponds to a given TokenBindingMessage, and a mechanism preventing a 
        TokenBindingMessage from being split across TLS renegotiation boundaries (i.e., due to TLS 
        message fragmentation - see Section 6.2.1 of <xref target="RFC5246"/>). Note that 
        application layer messages conveying a TokenBindingMessage may cross renegotiation 
        boundaries in ways that make processing difficult.</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: 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 TB_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>
      </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. When a provided_token_bindng is included, the key parameters used in a 
        provided_token_binding MUST match those negotiated with the server (e.g., via 
        <xref target="I-D.ietf-tokbind-negotiation"/> or a different mechanism).</t>
        
        <t>The client MUST generate and store Token Binding keys in a secure manner that prevents 
        key export. In order to prevent cooperating servers from linking user identities, the scope 
        of the Token Binding keys MUST NOT be broader than the scope of the tokens, as defined by 
        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"/> and Renegotiation Indication 
        <xref target="RFC5746" /> TLS extensions.</t>

        <t>If the use of the Token Binding protocol was not negotiated, but the client sends the 
        Token Binding message, the server MUST reject any contained bindings.</t>

        <t>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 with this client (e.g., via 
        <xref target="I-D.ietf-tokbind-negotiation"/> or a different mechanism). In the case of a 
        mismatch, the server MUST reject the binding. 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 
        reject the binding. </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>

        <t> If a Token Binding is rejected, any associated bound tokens presented on the current 
        TLS connection MUST also be rejected by the server. The effect of this is 
        application-specific, e.g., failing requests, a requirement for the client to 
        re-authenticate and present a different token, or connection termination.</t>
      </section>
    </section>

    <section title="Bound Security Token Creation and Validation" anchor="BoundSecurityToken">
      <t>Security tokens can be bound to the TLS layer in a variety of ways: by embedding the Token 
      Binding ID or its cryptographic hash 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 these 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 reject 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 reject the 
      token.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This section establishes three IANA registries on a new registry page entitled "Token 
      Binding Protocol": "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 "Specification Required" policy as defined in 
        <xref target="RFC8126"/>. The designated expert will require 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>---------------------------------</t></list>
          <list style="empty">
            <t>Value: 1</t>
            <t>Description: rsa2048_pss</t>
            <t>Specification: this document</t>
          </list>
          <list style="empty"><t>---------------------------------</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 "Specification Required" policy as defined in 
        <xref target="RFC8126"/>. The designated expert will require 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>---------------------------------</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 "Specification Required" policy as defined in 
        <xref target="RFC8126"/>. The designated expert will require 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 the following registration in the TLS Exporter Label Registry:
          <list style="empty">
            <t>Value: EXPORTER-Token-Binding</t>
            <t>DTLS-OK: Y</t>
            <t>Reference: this document</t>
          </list>
        </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 be replayed by malware present in User Agents, 
        which may be undetectable by a server. However, in order to export bound tokens to other 
        machines and successfully replay them, attackers also need to export corresponding Token 
        Binding private keys. 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>

        <t>The Token Binding protocol does not prevent cooperating clients from sharing a bound 
        token. A client could intentionally export a bound token with the corresponding Token 
        Binding private key, or perform signatures using this key on behalf of another client.</t>
      </section>

      <section title="Downgrade Attacks">
        <t>The Token Binding protocol MUST be negotiated using a mechanism that prevents downgrade. 
        E.g., <xref target="I-D.ietf-tokbind-negotiation"/> uses a TLS extension for Token Binding 
        negotiation. 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 TokenBinding 
        of type "provided_token_binding" MUST match the negotiated parameters.</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, the scope of the 
        Token Binding keys MUST NOT be broader than the scope of the tokens, as defined by 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 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 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" /> 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;
      &RFC7230;
      &RFC7540;
      &RFC5705;
      &RFC8126;
      &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>
      <reference anchor="FIPS.180-2.2002">
        <front>
          <title>Secure Hash Standard</title>
          <author>
            <organization>National Institute of Standards and Technology</organization>
          </author>
          <date year="2002" />
        </front>
        <seriesInfo name="FIPS" value="180-2" />
      </reference>
    </references>

    <references title="Informative References">
      &RFC6749;
      &RFC8017;
      <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.
      v11 2016-11-16  Andrei Popov   Renegotiation indication is always needed.
      v11 2016-11-17  Andrei Popov   TB verification failure results in TB and associated bound tokens rejection, not necessarily connection termination.
      v11 2016-11-17  Andrei Popov   Clarified the use of TB with renegotiation and the fact that new signature schemes may require longer exporter output.
      v11 2016-11-22  Andrei Popov   Merged PR #81: renegotiation requirements.
      v12 2016-11-29  Jeff Hodges    Init -12.
      v12 2016-12-06  Jeff Hodges    Polish renegotiation requirements. Fixup figure.
      v12 2016-12-08  Jeff Hodges    Editotial polishing of Abstract, Intro, Overview, Security-TokenReplay.
      v13 2017-02-16  Andrei Popov   Addressing Denis' comment regarding cooperating clients.
      v14 2017-04-04  Andrei Popov   Incorporating WGLC feedback.
      v15 2017-07-20  Andrei Popov   Fixing ID nits.
      v16 2017-10-15  Andrei Popov   Addressing AD comments.
      v17 2018-04-11  Andrei Popov   Adding separators between initial registrations.
                                     Clarifying IANA considerations.
                                     Acknowledging tokbind chairs and ADs.
      v18 2018-05-09  Andrei Popov   Incorporating GEN-ART review feedback.
      v18 2018-05-23  Andrei Popov   Incorporating IESG review feedback.
      v18 2018-07-24  Andrei Popov   Adding normative reference to the SHA256 specification.
                                     Clarifying the language in section 4.1 per EKR's comment.
                                     Removing Adam Langley from the co-authors list, according to his request.
    -->
  </back>
</rfc>