RFC 8471

The Token Binding Protocol Version 1.0

📅 published October 2018, from ietf

The Token Binding Protocol Version 1.0 🎀

  • Authors: A. Popov, Ed.; M. Nystroem (Microsoft Corp.); D. Balfanz (Google Inc.); J. Hodges (Kings Mountain Systems) 💖
  • Series: Request for Comments 8471, ISSN 2070-1721 🧚
  • Category: Standards Track ✨
  • Date: October 2018 📅
  • Obsoletes/Updates: the header doesn't have an Obsoletes or Updates line, so there's nothing listed there 🫶

Abstract

This doc specifies version 1.0 of the Token Binding protocol 🦋 It lets client/server apps create long-lived, uniquely identifiable TLS bindings that span multiple TLS sessions and connections. So apps can cryptographically bind security tokens to the TLS layer, which stops token export and replay attacks cold 🔥 For privacy, the Token Binding identifiers only get shared over TLS, and the user can reset them whenever they want 🌸

Status of This Memo

This is an Internet Standards Track document 💅

This doc is a product of the Internet Engineering Task Force (IETF) 🌈 It reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 For more on Internet Standards, check Section 2 of RFC 7841 ✨

Info about the current status of this doc, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc8471 🔗

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the publication date 📜 Please read these carefully, bestie, because they spell out your rights and restrictions for this doc. Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💜

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Token Binding Protocol Overview . . . . . . . . . . . . . . .   4
   3.  Token Binding Protocol Message  . . . . . . . . . . . . . . .   5
     3.1.  TokenBinding.tokenbinding_type  . . . . . . . . . . . . .   6
     3.2.  TokenBinding.tokenbindingid . . . . . . . . . . . . . . .   7
     3.3.  TokenBinding.signature  . . . . . . . . . . . . . . . . .   7
     3.4.  TokenBinding.extensions . . . . . . . . . . . . . . . . .   9
   4.  Establishing a Token Binding  . . . . . . . . . . . . . . . .   9
     4.1.  Client Processing Rules . . . . . . . . . . . . . . . . .   9
     4.2.  Server Processing Rules . . . . . . . . . . . . . . . . .  10
   5.  Bound Security Token Creation and Validation  . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Token Binding Key Parameters Registry . . . . . . . . . .  11
     6.2.  Token Binding Types Registry  . . . . . . . . . . . . . .  12
     6.3.  Token Binding Extensions Registry . . . . . . . . . . . .  13
     6.4.  Registration of Token Binding TLS Exporter Label  . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
     7.1.  Security Token Replay . . . . . . . . . . . . . . . . . .  14
     7.2.  Downgrade Attacks . . . . . . . . . . . . . . . . . . . .  14
     7.3.  Token Binding Key-Sharing between Applications  . . . . .  14
     7.4.  Triple Handshake Vulnerability in TLS 1.2 and Older TLS
           Versions  . . . . . . . . . . . . . . . . . . . . . . . .  15
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  15
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1. Introduction ✨

Servers often mint all kinds of security tokens (like HTTP cookies and OAuth tokens [RFC6749]) for apps to show when they want protected resources 💅 Generally, anyone holding a bearer security token gets access to certain protected resources, and attackers totally exploit that. They export bearer tokens from a user's app connections or machines, present them to app servers, and impersonate the authenticated user 💀 Token Binding is the fix: it cryptographically binds app security tokens to the underlying TLS layer [RFC5246] and shuts that down 🔒 (Heads up: this doc deals with TLS 1.2, so it refers to RFC 5246, which has been obsoleted by RFC 8446. [TOKENBIND-TLS13] covers Token Binding in TLS 1.3 🧚)

A Token Binding gets set up when a User Agent generates a private-public key pair (possibly inside a secure hardware module, like a Trusted Platform Module) for each target server 🦋 The User Agent gives the public key to the server and proves it has the matching private key on every TLS connection to that server. The proof works by signing the Exported Keying Material (EKM) [RFC5705] from the TLS connection with the private key ✨ The public key lives in the Token Binding identifier structure (described in Section 3.2 ("TokenBinding.tokenbindingid")) 🎀 Token Bindings are long-lived, meaning they cover multiple TLS connections and TLS sessions between a given client and server 🌸 For privacy, Token Binding IDs are never sent over insecure connections, and the user can reset them at any time, like when they clear browser cookies 🫶

When the server issues a security token to a client that supports Token Binding, it puts the client's Token Binding ID (or its cryptographic hash) in the token 💖 Later, when a client presents a security token that has a Token Binding ID, the server checks that the ID in the token matches the ID of the Token Binding it set up with that client 👑 If they don't match, the server rejects the token (the details depend on the application) 🙈

To successfully export and replay a bound security token, an attacker also needs the client's private key 😭 That's really hard to pull off when the key is specially protected, like when it's generated in a secure hardware module 🔐

1.1. Requirements Language

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💜

2. Token Binding Protocol Overview 🌈

During a TLS handshake, a client and server can use the Token Binding negotiation TLS extension [RFC8472] to agree on the Token Binding protocol version and the parameters of the Token Binding key (the signature algorithm and length) ⭐ This negotiation doesn't need any extra round trips, which is so iconic 🙌

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. See [RFC8472] ("Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation") for the full scoop 🧁

The Token Binding protocol is one message the client sends to the server, proving it possesses one or more client-generated asymmetric private keys 🎀 That message isn't sent if the Token Binding negotiation didn't work out 💔 The Token Binding message travels with the application protocol data over TLS 🦋

When the server gets the Token Binding message, it checks that the key parameters in the message match the Token Binding parameters that were negotiated (for example, via [RFC8472]). Then it validates the signatures in the message 🔍 If either check fails, the server rejects the binding, along with every bound token tied to it 🚫 Otherwise, the Token Binding is successfully established with the ID that's in the message ✅

When a server that supports the Token Binding protocol gets a bound token, it compares the Token Binding ID in the token with the Token Binding ID established with the client. If the bound token arrives on a TLS connection with no Token Binding, or the Token Binding IDs don't match, the token gets rejected 🙅‍♀️

This document defines the format of the Token Binding protocol message, the process for establishing a Token Binding, the format of the Token Binding ID, and the process for validating a bound token 📝 [RFC8472] describes how the Token Binding protocol and key parameters get negotiated 🤝 [RFC8473] ("Token Binding over HTTP") explains how the Token Binding message is wrapped inside HTTP/1.1 messages [RFC7230] or HTTP/2 messages [RFC7540] 🌸 [RFC8473] also covers Token Binding between multiple communicating parties: the User Agent, the Identity Provider, and the Relying Party 👑

3. Token Binding Protocol Message ✨

okay so this is the main event 💅 The Token Binding message is how the client proves it actually holds one or more private keys 🔑. This message MUST be sent if the client and server successfully negotiated the use of the Token Binding protocol (e.g., via [RFC8472] or a different mechanism) and MUST NOT be sent otherwise. It MUST be sent in the client's first application protocol message 🦋. It MAY also be sent in later application protocol messages to prove possession of extra private keys held by the same client, and that's lowkey iconic because it lets Token Binding work across more than two communicating parties 🌈. For example, [RFC8473] specifies how to wrap the Token Binding message in HTTP application protocol messages, plus scenarios with more than two parties 🧚.

The message format is written in the TLS presentation language (see Section 4 of [RFC5246]) 📜:

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 EKM */
    TB_Extension extensions<0..2^16-1>;
} TokenBinding;

struct {
    TokenBinding tokenbindings<132..2^16-1>;
} TokenBindingMessage;

So basically a Token Binding message is a bunch of TokenBinding structs, and each one has the type, the TokenBindingID, and a signature made with the Token Binding key, optionally followed by TB_Extension structs 💖.

3.1. TokenBinding.tokenbinding_type

This doc defines two Token Binding types 👑:

  • provided_token_binding 💜 - used to establish a Token Binding when connecting to a server.
  • referred_token_binding 🎀 - used when requesting tokens that are meant to be presented to a different server.

[RFC8473] describes a referred_token_binding use case where Token Bindings are set up between multiple communicating parties: the User Agent, the Identity Provider, and the Relying Party 🫶. The User Agent sends referred_token_binding to the Identity Provider to prove it holds the Token Binding key it uses with the Relying Party. The Identity Provider can then bind the token it's handing out (for presentation to the Relying Party) to the Token Binding ID inside that referred_token_binding 🔥.

An implementation MUST ignore any unknown Token Binding types 🙈.

3.2. TokenBinding.tokenbindingid

The ID of a Token Binding (the thing you get once the message is processed) holds the negotiated key parameters identifier, the length in bytes of the Token Binding public key, and the public key itself 🧚. You can get the Token Binding ID from a TokenBinding structure just by throwing away the Token Binding type, the signature, and the extensions ✨.

When rsa2048_pkcs1.5 or rsa2048_pss is used, RSAPublicKey.modulus and RSAPublicKey.publicexponent hold the modulus and exponent of a 2048-bit RSA public key, written in big-endian format with leading zero bytes left out 🌸.

When ecdsap256 is used, TB_ECPoint.point holds the X coordinate followed by the Y coordinate of a Curve P-256 key. Both coordinates are unsigned 32-byte integers in big-endian format, and any leading zero bytes are kept 💅. Future specs can define Token Binding keys with other elliptic curves, along with their own signature and point formats 🦋.

Token Binding implementations SHOULD make Token Binding IDs available to the application as opaque byte sequences 🍓. That way, apps don't depend on any particular Token Binding ID structure. For example, server apps will use Token Binding IDs when they generate and verify bound tokens 🔐.

3.3. TokenBinding.signature

When rsa2048_pkcs1.5 is used, TokenBinding.signature holds the signature made with the RSASSA-PKCS1-v1_5 signature scheme defined in [RFC8017], using SHA256 [FIPS.180-4.2015] as the hash function 🌈.

When rsa2048_pss is used, TokenBinding.signature holds the signature made with the RSA Probabilistic Signature Scheme (RSASSA-PSS) defined in [RFC8017], using SHA256 as the hash function. MGF1 with SHA256 MUST be used as the mask generation function (MGF), and the salt length MUST equal 32 bytes 🙌.

When ecdsap256 is used, TokenBinding.signature holds a pair of 32-byte integers, R followed by S, generated with the Elliptic Curve Digital Signature Algorithm (ECDSA) using Curve P-256 and SHA256, as defined in [FIPS.186-4.2013] and [ANSI.X9-62.2005]. R and S are encoded in big-endian format, and any leading zero bytes are preserved 🎀.

The signature gets computed over the byte string made by concatenating 💜:

  • The TokenBindingType value in the TokenBinding.tokenbinding_type field,
  • The TokenBindingKeyParameters value in the TokenBindingID.key_parameters field, and
  • The EKM value obtained from the current TLS connection.

Heads up 👀: TLS 1.2 and earlier support renegotiation, which makes a brand-new TLS master secret for the same connection, along with new session keys and a new EKM value. TokenBinding.signature MUST be a signature over the EKM value derived from the TLS master secret that produced the session keys encrypting the TLS application_data record(s) containing this TokenBinding. Using the current EKM for the connection like this makes replaying bound tokens inside renegotiated TLS sessions detectable, but it means the app has to sync Token Binding message generation and verification with the TLS handshake state 😭.

Specs that define Token Binding for application protocols, like Token Binding over HTTP [RFC8473], MAY prohibit TLS renegotiation together with Token Binding, which makes that syncing unnecessary 🙈. Otherwise, those specs need to define (1) a way to figure out which EKM value goes with a given TokenBindingMessage, and (2) a mechanism that stops a TokenBindingMessage from being split across TLS renegotiation boundaries because of TLS message fragmentation; see Section 6.2.1 of [RFC5246]. Note that application-layer messages carrying a TokenBindingMessage may cross renegotiation boundaries in ways that make processing messy 💀.

The EKM comes from the keying material exporters for TLS defined in [RFC5705], using these inputs ✨:

  • Label: The ASCII string "EXPORTER-Token-Binding" with no terminating NUL.
  • Context value: No application context supplied.
  • Length: 32 bytes.

3.4. TokenBinding.extensions

A Token Binding message MAY optionally contain a series of TB_Extension structures, each made of an extension_type and extension_data 🧩. What extension_data looks like and means depends on the specific extension_type.

No extension types are defined at the start (see Section 6.3 ("Token Binding Extensions Registry")). One possible use of extensions, as of when this was written, is attestation: cryptographic proof that lets the server verify that the Token Binding key is hardware bound 🔒. Definitions for those Token Binding protocol extensions are outside the scope of this spec 🌸.

4. Establishing a Token Binding ✨

4.1. Client Processing Rules

The client MUST include at least one TokenBinding structure in the Token Binding message 🎀. When a provided_token_binding is included, the key parameters used in it MUST match the ones negotiated with the server (e.g., via [RFC8472] or a different mechanism) 💅.

The client MUST generate and store Token Binding keys in a secure way that prevents key export 🔐. To stop 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 🙅‍♀️.

When the client needs to send a referred_token_binding to the Identity Provider, it SHALL build the referred TokenBinding structure like this 🦋:

  • Set TokenBinding.tokenbinding_type to referred_token_binding.
  • Set TokenBinding.tokenbindingid to the Token Binding ID used with the Relying Party.
  • 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 🌈.

Sending referred Token Bindings this way lets the Identity Provider verify that the client controls the Token Binding key used with the Relying Party 👑✨.

4.2. Server Processing Rules ✨

okay so the triple handshake vulnerability in TLS 1.2 and older TLS versions messes with the security of the Token Binding protocol 😭 (see Section 7 ("Security Considerations") for the full tea). So 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 TLS extension [RFC7627] and the renegotiation indication TLS extension [RFC5746]. no shortcuts, bestie 🙅‍♀️

If the Token Binding protocol was never negotiated but the client still sends a Token Binding message anyway, the server MUST reject any bindings inside it. rude 💀

If the Token Binding type is provided_token_binding, the server MUST verify that the signature algorithm (including an elliptic curve when it's ECDSA) and key length in the Token Binding message match what was negotiated with this client (for example, through [RFC8472] or some other mechanism). if they don't match, the server MUST reject the binding 🚫. referred_token_binding types are the exception: they're allowed to use different key parameters than the ones negotiated with this client 🦋

If the Token Binding message doesn't contain at least one TokenBinding structure, or if a signature in any TokenBinding structure is invalid, the server MUST reject the binding. no vibes, just rejection 💅

Servers MUST ignore any unknown extensions. right now there are no extension types defined at all (see Section 6.3 ("Token Binding Extensions Registry")), so it's a whole lot of nothing for now 🌸

If every check above passes, the Token Binding between this client and server is established ✨🎉. The Token Binding ID(s) carried in the Token Binding message can be handed to the server-side application, and the application can use them for bound security token creation and validation (see Section 5). iconic.

If a Token Binding gets rejected, any bound tokens presented on the current TLS connection MUST also be rejected by the server 🙅‍♀️. what happens next is up to the application, like failing requests, making the client re-authenticate with a different token, or terminating the connection 🔌

5. Bound Security Token Creation and Validation 🔐

okay the big picture here is that security tokens can be bound to the TLS layer in a bunch of different ways, like embedding the Token Binding ID (or its cryptographic hash) right inside the token, or keeping a database that maps tokens to Token Binding IDs 🗂️. the specific method for making bound tokens is totally up to the application and is out of scope for this document. just remember the security considerations in Section 7 still apply, periodt 💖

Either or both clients and servers MAY create bound security tokens 🧚. For example, HTTPS servers that use Token Binding to secure their HTTP cookies will bind those cookies 🍪. In a server-initiated challenge-response protocol that uses Token Binding and TLS, the client can (for example) put the Token Binding ID inside the signed object it sends back, which binds that object 💜

When a server gets a security token, it tries to pull Token Binding ID information out of the token and out of the TLS connection with the client 👀. Whether non-bound (bearer) tokens get honored is decided by application policy 🛡️. If the token is bound and no Token Binding has been established for the client connection, the server MUST reject the token ❌. And if the Token Binding ID for the token doesn't match the Token Binding ID established for the connection, the server MUST reject the token too ❌ no exceptions bestie

6. IANA Considerations 📋

this section sets up a brand new IANA registry called "Token Binding Protocol", with three subregistries inside it: "Token Binding Key Parameters", "Token Binding Types", and "Token Binding Extensions" 🌈. It also registers a new TLS exporter label in the "TLS Exporter Labels" registry 🏷️

6.1. Token Binding Key Parameters Registry

this document sets up a subregistry for Token Binding key parameter identifiers, called "Token Binding Key Parameters", under the "Token Binding Protocol" registry 🔑

every entry in this registry needs these fields:

  • Value: the octet value that identifies a set of Token Binding key parameters (0-255).
  • Description: the description of those Token Binding key parameters.
  • Reference: a reference to a specification that defines the Token Binding key parameters.

this registry runs on the "Specification Required" policy from [RFC8126]. the designated expert will want a reference to a permanent, readily available specification that lets people build interoperable implementations with the identified key parameters 📚✨

here's the starting set of registrations:

Value: 0
Description: rsa2048_pkcs1.5
Specification: This document

Value: 1
Description: rsa2048_pss
Specification: This document

Value: 2
Description: ecdsap256
Specification: This document

6.2. Token Binding Types Registry

this document sets up a subregistry for Token Binding type identifiers, called "Token Binding Types", under the "Token Binding Protocol" registry 🦋

every entry here needs these fields:

  • Value: the octet value that identifies the Token Binding type (0-255).
  • Description: the description of the Token Binding type.
  • Reference: a reference to a specification that defines the Token Binding type.

same deal as before: the "Specification Required" policy from [RFC8126] applies. the designated expert will want a reference to a permanent, readily available specification that enables interoperable implementations of the identified Token Binding type 💅

the starting registrations:

Value: 0
Description: provided_token_binding
Specification: This document

Value: 1
Description: referred_token_binding
Specification: This document

6.3. Token Binding Extensions Registry

this document sets up a subregistry for Token Binding extensions, called "Token Binding Extensions", under the "Token Binding Protocol" registry 🧩

every entry needs these fields:

  • Value: the octet value that identifies the Token Binding extension (0-255).
  • Description: the description of the Token Binding extension.
  • Reference: a reference to a specification that defines the Token Binding extension.

it runs on the "Specification Required" policy from [RFC8126]. the designated expert wants a reference to a permanent, readily available specification that enables interoperable implementations of the identified Token Binding extension. and here's the tea: this document creates no initial registrations in the "Token Binding Extensions" registry 🤷‍♀️

6.4. Registration of Token Binding TLS Exporter Label

this document adds the following registration to the "TLS Exporter Labels" registry 🏷️:

Value: EXPORTER-Token-Binding
DTLS-OK: Y
Recommended: Y
Reference: This document

7. Security Considerations 🛡️😤

bestie, this section is seriously important, so read it like it's a group chat from your mom 🫶

7.1. Security Token Replay

the whole goal of the Token Binding protocol is to stop attackers from exporting and replaying security tokens, which would let them impersonate legit users and get into protected resources 🚨. malware sitting in User Agents can replay bound tokens, and a server might not be able to tell it's happening 👻. BUT, to export bound tokens to other machines and replay them successfully, attackers also need to export the matching Token Binding private keys 🔐. so Token Binding private keys are high-value assets and they SHOULD be strongly protected, ideally by generating them in a hardware security module that stops key export 🏰

how a token gets bound to the TLS layer is up to the application and out of scope here. however, the resulting bound token needs to be integrity-protected, so an attacker can't strip the binding or swap in a Token Binding ID of their choice without getting caught 🚫🕵️‍♀️

also, the Token Binding protocol can't stop cooperating clients from sharing a bound token. a client could deliberately export a bound token along with its Token Binding private key, or use that key to make signatures on behalf of another client 🤝

7.2. Downgrade Attacks

the Token Binding protocol MUST be negotiated using a mechanism that prevents downgrade attacks 🙅‍♀️. for example, [RFC8472] specifies a TLS extension for Token Binding negotiation. TLS catches active attackers messing with handshake messages, so an attacker can't remove or modify the "token_binding" extension without breaking the TLS handshake 💥. the signature algorithm and key length used in a TokenBinding of type provided_token_binding MUST match the negotiated parameters 🔒

7.3. Token Binding Key-Sharing between Applications

platforms already have a bunch of platform-specific ways for certain apps to share tokens, like "single sign-on" scenarios 🔑🔑. for those to keep working with bound tokens, the apps that are allowed to share tokens will also need to share Token Binding keys. be careful here: sharing of Token Binding keys has to stay restricted to the same group(s) of applications that share the same tokens 👯‍♀️

7.4. Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions

the Token Binding protocol relies on TLS exporters [RFC5705] to link a TLS connection to a Token Binding. the triple handshake attack [TRIPLE-HS] is a known vulnerability in TLS 1.2 and older TLS versions that lets an attacker synchronize keying material between TLS connections 😱. then the attacker can successfully replay bound tokens. this is why the Token Binding protocol MUST NOT be negotiated with these TLS versions, unless the extended master secret TLS extension [RFC7627] and the renegotiation indication TLS extension [RFC5746] have also been negotiated 💀

8. Privacy Considerations 🙈

the Token Binding protocol uses persistent, long-lived Token Binding IDs 🪪. to protect privacy, Token Binding IDs are never sent in clear text, and the user can reset them at any time (for example, when clearing browser cookies) 🧹. some apps offer a special privacy mode where they don't store or use tokens from the server, like "in private" browsing 🕶️. in that mode, applications SHOULD use newly generated Token Binding keys and delete them when they leave the mode. otherwise, they SHOULD NOT negotiate Token Binding at all 🫣

to stop cooperating servers from linking user identities, the scope of the Token Binding keys MUST NOT be broader than the scope of the tokens, as the application protocol defines it 🧩

servers can use tokens and Token Binding IDs to track clients 👁️. client apps that automatically limit the lifetime or scope of tokens to protect user privacy SHOULD apply the same validity time and scope limits to their Token Binding keys 🌸

9. References 📚

9.1. Normative References 📚

okay bestie, these are the docs the spec needs you to have read, no skipping 🫶

[ANSI.X9-62.2005]
   American National Standards Institute, "Public Key
   Cryptography for the Financial Services Industry: The
   Elliptic Curve Digital Signature Algorithm (ECDSA)",
   ANSI X9.62, November 2005.

[FIPS.180-4.2015]
   National Institute of Standards and Technology, "Secure
   Hash Standard (SHS)", FIPS 180-4,
   DOI 10.6028/NIST.FIPS.180-4, August 2015,
   <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.

[FIPS.186-4.2013]
   National Institute of Standards and Technology, "Digital
   Signature Standard (DSS)", FIPS 186-4,
   DOI 10.6028/NIST.FIPS.186-4, July 2013,
   <https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.186-4.pdf>.

[RFC2119]
   Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119,
   DOI 10.17487/RFC2119, March 1997,
   <https://www.rfc-editor.org/info/rfc2119>.

[RFC5246]
   Dierks, T. and E. Rescorla, "The Transport Layer Security
   (TLS) Protocol Version 1.2", RFC 5246,
   DOI 10.17487/RFC5246, August 2008,
   <https://www.rfc-editor.org/info/rfc5246>.

[RFC5705]
   Rescorla, E., "Keying Material Exporters for Transport
   Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
   March 2010, <https://www.rfc-editor.org/info/rfc5705>.

[RFC5746]
   Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
   "Transport Layer Security (TLS) Renegotiation Indication
   Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
   <https://www.rfc-editor.org/info/rfc5746>.

[RFC7230]
   Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
   Protocol (HTTP/1.1): Message Syntax and Routing",
   RFC 7230, DOI 10.17487/RFC7230, June 2014,
   <https://www.rfc-editor.org/info/rfc7230>.

[RFC7540]
   Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
   Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
   DOI 10.17487/RFC7540, May 2015,
   <https://www.rfc-editor.org/info/rfc7540>.

[RFC7627]
   Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
   Langley, A., and M. Ray, "Transport Layer Security (TLS)
   Session Hash and Extended Master Secret Extension",
   RFC 7627, DOI 10.17487/RFC7627, September 2015,
   <https://www.rfc-editor.org/info/rfc7627>.

[RFC8126]
   Cotton, M., Leiba, B., and T. Narten, "Guidelines for
   Writing an IANA Considerations Section in RFCs", BCP 26,
   RFC 8126, DOI 10.17487/RFC8126, June 2017,
   <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]
   Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
   2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
   May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8472]
   Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport
   Layer Security (TLS) Extension for Token Binding Protocol
   Negotiation", RFC 8472, DOI 10.17487/RFC8472, October
   2018, <https://www.rfc-editor.org/info/rfc8472>.

[RFC8473]
   Popov, A., Nystroem, M., Balfanz, D., Ed., Harper, N., and
   J. Hodges, "Token Binding over HTTP", RFC 8473,
   DOI 10.17487/RFC8473, October 2018,
   <https://www.rfc-editor.org/info/rfc8473>.

9.2. Informative References 🦋

these ones are just extra reading for the curious, no pressure 💅

[RFC6749]
   Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
   RFC 6749, DOI 10.17487/RFC6749, October 2012,
   <https://www.rfc-editor.org/info/rfc6749>.

[RFC8017]
   Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
   "PKCS #1: RSA Cryptography Specifications Version 2.2",
   RFC 8017, DOI 10.17487/RFC8017, November 2016,
   <https://www.rfc-editor.org/info/rfc8017>.

[TOKENBIND-TLS13]
   Harper, N., "Token Binding for Transport Layer Security
   (TLS) Version 1.3 Connections", Work in Progress,
   draft-ietf-tokbind-tls13-01, May 2018.

[TRIPLE-HS]
   Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
   A., and P. Strub, "Triple Handshakes and Cookie Cutters:
   Breaking and Fixing Authentication over TLS",
   IEEE Symposium on Security and Privacy,
   DOI 10.1109/SP.2014.14, May 2014.

Acknowledgements 🫶

this doc is literally built different because of these people 💖

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.

This document was produced under the chairmanship of John Bradley and Leif Johansson. The area directors included Eric Rescorla, Kathleen Moriarty, and Stephen Farrell.

Authors' Addresses 🌸

the squad behind the whole thing, slay 👑

Andrei Popov (editor)
Microsoft Corp.
United States of America

Email: andreipo@microsoft.com


Magnus Nystroem
Microsoft Corp.
United States of America

Email: mnystrom@microsoft.com


Dirk Balfanz
Google Inc.
United States of America

Email: balfanz@google.com


Jeff Hodges
Kings Mountain Systems
United States of America

Email: Jeff.Hodges@KingsMountain.com
📦 where this page comes from