RFC 8472

Title Block 🎀

Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation

• RFC number: RFC 8472 🦋
• Authors: A. Popov, Ed.; M. Nystroem (Microsoft Corp.); D. Balfanz (Google Inc.). The header gives no affiliation for A. Popov, so I'm not guessing one 🙈
• Category: Standards Track
• Stream: Internet Engineering Task Force (IETF)
• ISSN: 2070-1721
• Date: October 2018
• Obsoletes / Updates: The header doesn't list anything this RFC obsoletes or updates. The IANA section does say it updates the "TLS ExtensionType Values" registry, and we'll get to that in Section 5 💅

---

Abstract 🧚

okay so this doc specifies a Transport Layer Security (TLS) extension that lets a client and server agree on the Token Binding protocol version and the key parameters. negotiation of Token Binding in TLS 1.3 and later versions is beyond the scope of this document, so we're not doing that here 🙅‍♀️

Status of This Memo 📝

this is an Internet Standards Track document. ✨

it's a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. if you want more on Internet Standards, check out Section 2 of RFC 7841 🫶

for the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8472 🌸

Copyright Notice ⚖️

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

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please actually read these, because they spell out your rights and restrictions for this document. if you pull Code Components out of this document, they have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🔥

Table of Contents 📖

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
2.  Token Binding Negotiation ClientHello Extension . . . . . . .   2
3.  Token Binding Negotiation ServerHello Extension . . . . . . .   3
4.  Negotiating Token Binding Protocol Version and Key Parameters   4
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
  6.1.  Downgrade Attacks . . . . . . . . . . . . . . . . . . . .   6
  6.2.  Triple Handshake Vulnerability in TLS 1.2 and Older TLS
        Versions  . . . . . . . . . . . . . . . . . . . . . . . .   6
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction ✨

okay so before a client and server can use the Token Binding protocol [RFC8471], they need to agree on the Token Binding protocol version and the parameters of the Token Binding key, meaning the signature algorithm and the length. this doc adds a new TLS [RFC5246] extension to do that negotiation without adding extra network round trips in TLS 1.2 and earlier versions. [TOKENBIND-TLS13] covers Token Binding in TLS 1.3. negotiating the Token Binding protocol and key parameters together with TLS 1.3 and later is beyond this document's scope. (Note: this document deals with TLS 1.2 and therefore refers to RFC 5246 (which has been obsoleted by RFC 8446). [TOKENBIND-TLS13] addresses Token Binding in TLS 1.3). 🦋

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 Negotiation ClientHello Extension 🌈

the client uses the token_binding TLS extension to say what the highest Token Binding protocol version and key parameters it supports are. 💖

enum {
    token_binding(24), (65535)
} ExtensionType;

the extension_data field of this extension holds a TokenBindingParameters value. 🧚

struct {
    uint8 major;
    uint8 minor;
} TB_ProtocolVersion;

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

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

token_binding_version is the version of the Token Binding protocol the client wants to use on this connection. if the client supports several versions, it SHOULD send the latest one it supports, meaning the one with the highest TB_ProtocolVersion.major and TB_ProtocolVersion.minor, in TokenBindingParameters.token_binding_version. for example, if the client supports versions {1, 0} and {0, 13} of the Token Binding protocol, it SHOULD indicate version {1, 0}. heads up that the server MAY pick any lower protocol version. see Section 3 ("Token Binding Negotiation ServerHello Extension") for the details 👀 if the client doesn't support the Token Binding protocol version the server picked, the connection just carries on without Token Binding. [RFC8471] describes version {1, 0} of the protocol. 🌸

quick note: writing the protocol version as two octets ("major" and "minor") is only there so humans can read it. it has no protocol significance at all 🙈

key_parameters_list is the list of Token Binding key parameters identifiers the client supports, in descending order of preference. [RFC8471] sets up an IANA registry for those identifiers. 🍓

3. Token Binding Negotiation ServerHello Extension 💜

the server uses the token_binding TLS extension to say it supports the Token Binding protocol and to pick the protocol version and key parameters. ✨

a server that supports Token Binding and gets a ClientHello with the token_binding extension will include the token_binding extension in its ServerHello only when all of these are true: 🫶

1. the server supports the Token Binding protocol version the client offered, or a lower one.
2. the server finds acceptable Token Binding key parameters in the client's list.
3. the server is also negotiating the extended master secret [RFC7627] and renegotiation indication [RFC5746] TLS extensions. this applies when TLS 1.2 or an older TLS version is used (see Section 6 ("Security Considerations") for more details). 🔐

the server ignores any key parameters it doesn't recognize. the extension_data field of the token_binding extension is structured the same way as the client's extension_data described above. 🧩

token_binding_version holds the lower of:

• the Token Binding protocol version the client offered in the token_binding extension, and
• the highest Token Binding protocol version the server supports. 🦋

key_parameters_list holds exactly one Token Binding key parameters identifier, which the server picked from the client's list. 👑

okay so bestie, this is part 2 and it's where the security section wraps up and we get the reference lists 🎀

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

Okay so the Token Binding protocol relies on the 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 😭 It lets an attacker sync up keying material between TLS connections, and then the attacker can successfully replay bound tokens 💀 So the Token Binding protocol MUST NOT be negotiated with these TLS versions, unless the extended master secret [RFC7627] and renegotiation indication [RFC5746] TLS extensions have also been negotiated 🙈 No exceptions, bestie 🔥

---

7. References 🧚

7.1. Normative References 💜

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

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

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

[RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, "The Token Binding Protocol Version 1.0", RFC 8471, DOI 10.17487/RFC8471, October 2018, <https://www.rfc-editor.org/info/rfc8471>.

7.2. Informative References 🌸

[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 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. Iconic cast, no notes 👑

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 🦋

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