idnits 2.17.1 draft-ietf-tokbind-protocol-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 12, 2018) is 2207 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-tokbind-https-12 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-10 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Popov, Ed. 3 Internet-Draft M. Nystroem 4 Intended status: Standards Track Microsoft Corp. 5 Expires: October 14, 2018 D. Balfanz 6 A. Langley 7 Google Inc. 8 J. Hodges 9 PayPal 10 April 12, 2018 12 The Token Binding Protocol Version 1.0 13 draft-ietf-tokbind-protocol-17 15 Abstract 17 This document specifies Version 1.0 of the Token Binding protocol. 18 The Token Binding protocol allows client/server applications to 19 create long-lived, uniquely identifiable TLS bindings spanning 20 multiple TLS sessions and connections. Applications are then enabled 21 to cryptographically bind security tokens to the TLS layer, 22 preventing token export and replay attacks. To protect privacy, the 23 Token Binding identifiers are only conveyed over TLS and can be reset 24 by the user at any time. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 14, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Token Binding Protocol Overview . . . . . . . . . . . . . . . 3 63 3. Token Binding Protocol Message . . . . . . . . . . . . . . . 4 64 3.1. TokenBinding.tokenbinding_type . . . . . . . . . . . . . 6 65 3.2. TokenBinding.tokenbindingid . . . . . . . . . . . . . . . 6 66 3.3. TokenBinding.signature . . . . . . . . . . . . . . . . . 7 67 3.4. TokenBinding.extensions . . . . . . . . . . . . . . . . . 8 68 4. Establishing a Token Binding . . . . . . . . . . . . . . . . 8 69 4.1. Client Processing Rules . . . . . . . . . . . . . . . . . 9 70 4.2. Server Processing Rules . . . . . . . . . . . . . . . . . 9 71 5. Bound Security Token Creation and Validation . . . . . . . . 10 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. Token Binding Key Parameters Registry . . . . . . . . . . 11 74 6.2. Token Binding Types Registry . . . . . . . . . . . . . . 12 75 6.3. Token Binding Extensions Registry . . . . . . . . . . . . 13 76 6.4. Registration of Token Binding TLS Exporter Label . . . . 13 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 7.1. Security Token Replay . . . . . . . . . . . . . . . . . . 13 79 7.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 14 80 7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 14 81 7.4. Token Binding Key Sharing Between Applications . . . . . 15 82 7.5. Triple Handshake Vulnerability in TLS 1.2 and Older TLS 83 Versions . . . . . . . . . . . . . . . . . . . . . . . . 15 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 87 9.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 Servers often generate various security tokens (e.g. HTTP cookies, 93 OAuth [RFC6749] tokens) for applications to present when accessing 94 protected resources. In general, any party in possession of bearer 95 security tokens gain access to certain protected resource(s). 97 Attackers take advantage of this by exporting bearer tokens from 98 user's application connections or machines, presenting them to 99 application servers, and impersonating authenticated users. The idea 100 of Token Binding is to prevent such attacks by cryptographically 101 binding application security tokens to the underlying TLS [RFC5246] 102 layer. 104 A Token Binding is established by a user agent generating a private- 105 public key pair (possibly, within a secure hardware module, such as 106 TPM) per target server, providing the public key to the server, and 107 proving possession of the corresponding private key, on every TLS 108 connection to the server. The proof of possession involves signing 109 the exported keying material (EKM) [RFC5705] from the TLS connection 110 with the private key. The corresponding public key is included in 111 the Token Binding identifier structure (described in the Section 3.2 112 "TokenBinding.tokenbindingid"). Token Bindings are long-lived, i.e., 113 they encompass multiple TLS connections and TLS sessions between a 114 given client and server. To protect privacy, Token Binding IDs are 115 never conveyed over insecure connections and can be reset by the user 116 at any time, e.g., when clearing browser cookies. 118 When issuing a security token to a client that supports Token 119 Binding, a server includes the client's Token Binding ID (or its 120 cryptographic hash) in the token. Later on, when a client presents a 121 security token containing a Token Binding ID, the server verifies 122 that the ID in the token matches the ID of the Token Binding 123 established with the client. In the case of a mismatch, the server 124 rejects the token (details are application-specific). 126 In order to successfully export and replay a bound security token, an 127 attacker needs to also be able to use the client's private key, which 128 is hard to do if the key is specially protected, e.g., generated in a 129 secure hardware module. 131 1.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 2. Token Binding Protocol Overview 139 In the course of a TLS handshake, a client and server can use the 140 Token Binding Negotiation TLS Extension 141 [I-D.ietf-tokbind-negotiation] to negotiate the Token Binding 142 protocol version and the parameters (signature algorithm, length) of 143 the Token Binding key. This negotiation does not require additional 144 round-trips. 146 The Token Binding protocol consists of one message sent by the client 147 to the server, proving possession of one or more client-generated 148 asymmetric private keys. This message is not sent if the Token 149 Binding Negotiation has been unsuccessful. The Token Binding message 150 is sent with the application protocol data over TLS. 152 A server receiving the Token Binding message verifies that the key 153 parameters in the message match the Token Binding parameters 154 negotiated (e.g., via [I-D.ietf-tokbind-negotiation]), and then 155 validates the signatures contained in the Token Binding message. If 156 either of these checks fails, the server rejects the binding, along 157 with all associated bound tokens. Otherwise, the Token Binding is 158 successfully established with the ID contained in the Token Binding 159 message. 161 When a server supporting the Token Binding protocol receives a bound 162 token, the server compares the Token Binding ID in the token with the 163 Token Binding ID established with the client. If the bound token 164 came from a TLS connection without a Token Binding, or if the Token 165 Binding IDs do not match, the token is rejected. 167 This document defines the format of the Token Binding protocol 168 message, the process of establishing a Token Binding, the format of 169 the Token Binding ID, and the process of validating a bound token. 170 Token Binding Negotiation TLS Extension 171 [I-D.ietf-tokbind-negotiation] describes the negotiation of the Token 172 Binding protocol and key parameters. Token Binding over HTTP 173 [I-D.ietf-tokbind-https] explains how the Token Binding message is 174 encapsulated within HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] messages. 175 [I-D.ietf-tokbind-https] also describes Token Binding between 176 multiple communicating parties: User Agent, Identity Provider and 177 Relying Party. 179 3. Token Binding Protocol Message 181 The Token Binding message is sent by the client to prove possession 182 of one or more private keys held by the client. This message MUST be 183 sent if the client and server successfully negotiated the use of the 184 Token Binding protocol (e.g., via [I-D.ietf-tokbind-negotiation] or a 185 different mechanism), and MUST NOT be sent otherwise. This message 186 MUST be sent in the client's first application protocol message. 187 This message MAY also be sent in subsequent application protocol 188 messages, proving possession of additional private keys held by the 189 same client, which can be used to facilitate token binding between 190 more than two communicating parties. For example, Token Binding over 191 HTTP [I-D.ietf-tokbind-https] specifies an encapsulation of the Token 192 Binding message in HTTP application protocol messages, as well as 193 scenarios involving more than two communicating parties. 195 The Token Binding message format is defined using TLS Presentation 196 Language (see Section 4 of [RFC5246]): 198 enum { 199 rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255) 200 } TokenBindingKeyParameters; 202 struct { 203 opaque modulus<1..2^16-1>; 204 opaque publicexponent<1..2^8-1>; 205 } RSAPublicKey; 207 struct { 208 opaque point <1..2^8-1>; 209 } TB_ECPoint; 211 struct { 212 TokenBindingKeyParameters key_parameters; 213 uint16 key_length; /* Length (in bytes) of the following 214 TokenBindingID.TokenBindingPublicKey */ 215 select (key_parameters) { 216 case rsa2048_pkcs1.5: 217 case rsa2048_pss: 218 RSAPublicKey rsapubkey; 219 case ecdsap256: 220 TB_ECPoint point; 221 } TokenBindingPublicKey; 222 } TokenBindingID; 224 enum { 225 (255) /* No initial TB_ExtensionType registrations */ 226 } TB_ExtensionType; 228 struct { 229 TB_ExtensionType extension_type; 230 opaque extension_data<0..2^16-1>; 231 } TB_Extension; 233 enum { 234 provided_token_binding(0), referred_token_binding(1), (255) 235 } TokenBindingType; 237 struct { 238 TokenBindingType tokenbinding_type; 239 TokenBindingID tokenbindingid; 240 opaque signature<64..2^16-1>; /* Signature over the concatenation 241 of tokenbinding_type, 242 key_parameters and exported 243 keying material (EKM) */ 244 TB_Extension extensions<0..2^16-1>; 245 } TokenBinding; 247 struct { 248 TokenBinding tokenbindings<132..2^16-1>; 249 } TokenBindingMessage; 251 The Token Binding message consists of a series of TokenBinding 252 structures, each containing the type of the token binding, the 253 TokenBindingID, a signature using the Token Binding key, optionally 254 followed by TB_Extension structures. 256 3.1. TokenBinding.tokenbinding_type 258 This document defines two Token Binding types: 260 o provided_token_binding - used to establish a Token Binding when 261 connecting to a server. 263 o referred_token_binding - used when requesting tokens that are 264 intended to be presented to a different server. 266 Token Binding over HTTP [I-D.ietf-tokbind-https] describes a use case 267 for referred_token_binding where Token Bindings are established 268 between multiple communicating parties: User Agent, Identity Provider 269 and Relying Party. User Agent sends referred_token_binding to the 270 Identity Provider in order to prove possession of the Token Binding 271 key it uses with the Relying Party. The Identity Provider can then 272 bind the token it is supplying (for presentation to the Relying 273 Party) to the Token Binding ID contained in the 274 referred_token_binding. 276 3.2. TokenBinding.tokenbindingid 278 The ID of the Token Binding established as a result of Token Binding 279 message processing contains the identifier of the negotiated key 280 parameters, the length (in bytes) of the Token Binding public key, 281 and the Token Binding public key itself. The Token Binding ID can be 282 obtained from the TokenBinding structure by discarding the Token 283 Binding type, signature and extensions. 285 When rsa2048_pkcs1.5 or rsa2048_pss is used, RSAPublicKey.modulus and 286 RSAPublicKey.publicexponent contain the modulus and exponent of a 287 2048-bit RSA public key represented in big-endian format, with 288 leading zero bytes omitted. 290 When ecdsap256 is used, TB_ECPoint.point contains the X coordinate 291 followed by the Y coordinate of a Curve P-256 key. The X and Y 292 coordinates are unsigned 32-byte integers encoded in big-endian 293 format, preserving any leading zero bytes. Future specifications may 294 define Token Binding keys using other elliptic curves with their 295 corresponding signature and point formats. 297 Token Binding protocol implementations SHOULD make Token Binding IDs 298 available to the application as opaque byte sequences. E.g., server 299 applications will use Token Binding IDs when generating and verifying 300 bound tokens. 302 3.3. TokenBinding.signature 304 When rsa2048_pkcs1.5 is used, TokenBinding.signature contains the 305 signature generated using the RSASSA-PKCS1-v1_5 signature scheme 306 defined in [RFC8017] with SHA256 as the hash function. 308 When rsa2048_pss is used, TokenBinding.signature contains the 309 signature generated using the RSASSA-PSS signature scheme defined in 310 [RFC8017] with SHA256 as the hash function. MGF1 with SHA256 MUST be 311 used as the mask generation function, and the salt length MUST equal 312 32 bytes. 314 When ecdsap256 is used, TokenBinding.signature contains a pair of 315 32-byte integers, R followed by S, generated with ECDSA using Curve 316 P-256 and SHA256 as defined in [ANSI.X9-62.2005] and 317 [FIPS.186-4.2013]. R and S are encoded in big-endian format, 318 preserving any leading zero bytes. 320 The signature is computed over the byte string representing the 321 concatenation of: 323 o TokenBindingType value contained in the 324 TokenBinding.tokenbinding_type field; 326 o TokenBindingKeyParameters value contained in the 327 TokenBindingID.key_parameters field; 329 o Exported keying material (EKM) value obtained from the current TLS 330 connection. 332 Please note that TLS 1.2 and earlier versions support renegotiation, 333 which produces a new TLS master secret for the same connection, with 334 associated session keys and EKM value. TokenBinding.signature MUST 335 be a signature of the EKM value derived from the TLS master secret 336 that produced the session keys encrypting the TLS application_data 337 record(s) containing this TokenBinding. Such use of the current EKM 338 for the TLS connection makes replay of bound tokens within 339 renegotiated TLS sessions detectable, but requires the application to 340 synchronize Token Binding message generation and verification with 341 the TLS handshake state. 343 Specifications defining the use of Token Binding with application 344 protocols, such as Token Binding over HTTP [I-D.ietf-tokbind-https], 345 MAY prohibit the use of TLS renegotiation in combination with Token 346 Binding, obviating the need for such synchronization. Alternatively, 347 such specifications need to define a way to determine which EKM value 348 corresponds to a given TokenBindingMessage, and a mechanism 349 preventing a TokenBindingMessage from being split across TLS 350 renegotiation boundaries (i.e., due to TLS message fragmentation - 351 see Section 6.2.1 of [RFC5246]). Note that application layer 352 messages conveying a TokenBindingMessage may cross renegotiation 353 boundaries in ways that make processing difficult. 355 The EKM is obtained using the Keying Material Exporters for TLS 356 defined in [RFC5705], by supplying the following input values: 358 o Label: The ASCII string "EXPORTER-Token-Binding" with no 359 terminating NUL. 361 o Context value: No application context supplied. 363 o Length: 32 bytes. 365 3.4. TokenBinding.extensions 367 A Token Binding message may optionally contain a series of 368 TB_Extension structures, each consisting of an extension_type and 369 extension_data. The structure and meaning of extension_data depends 370 on the specific extension_type. 372 Initially, no extension types are defined (see Section 6.3 373 "Token Binding Extensions Registry"). One of the possible uses of 374 extensions envisioned at the time of this writing is attestation: 375 cryptographic proof that allows the server to verify that the Token 376 Binding key is hardware-bound. The definitions of such Token Binding 377 protocol extensions are outside the scope of this specification. 379 An implementation MUST ignore any unknown Token Binding types. 381 4. Establishing a Token Binding 382 4.1. Client Processing Rules 384 The client MUST include at least one TokenBinding structure in the 385 Token Binding message. The key parameters used in the 386 provided_token_binding MUST match those negotiated with the server 387 (e.g., via [I-D.ietf-tokbind-negotiation] or a different mechanism). 389 The client SHOULD generate and store Token Binding keys in a secure 390 manner that prevents key export. In order to prevent cooperating 391 servers from linking user identities, the scope of the Token Binding 392 keys MUST NOT be broader than the scope of the tokens, as defined by 393 the application protocol. 395 When the client needs to send a referred_token_binding to the 396 Identity Provider, the client SHALL construct the referred 397 TokenBinding structure in the following manner: 399 o Set TokenBinding.tokenbinding_type to referred_token_binding. 401 o Set TokenBinding.tokenbindingid to the Token Binding ID used with 402 the Relying Party. 404 o Generate TokenBinding.signature, using the EKM value of the TLS 405 connection to the Identity Provider, the Token Binding key 406 established with the Relying Party and the signature algorithm 407 indicated by the associated key parameters. Note that these key 408 parameters may differ from the key parameters negotiated with the 409 Identity Provider. 411 Conveying referred Token Bindings in this fashion allows the Identity 412 Provider to verify that the client controls the Token Binding key 413 used with the Relying Party. 415 4.2. Server Processing Rules 417 The triple handshake vulnerability in TLS 1.2 and older TLS versions 418 affects the security of the Token Binding protocol, as described in 419 Section 7 "Security Considerations". Therefore, the server MUST NOT 420 negotiate the use of the Token Binding protocol with these TLS 421 versions, unless the server also negotiates the Extended Master 422 Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS 423 extensions. 425 If the use of the Token Binding protocol was not negotiated, but the 426 client sends the Token Binding message, the server MUST reject any 427 contained bindings. If the Token Binding type is 428 "provided_token_binding", the server MUST verify that the signature 429 algorithm (including elliptic curve in the case of ECDSA) and key 430 length in the Token Binding message match those negotiated with this 431 client (e.g., via [I-D.ietf-tokbind-negotiation] or a different 432 mechanism). In the case of a mismatch, the server MUST reject the 433 binding. Token Bindings of type "referred_token_binding" may use 434 different key parameters than those negotiated with this client. 436 If the Token Binding message does not contain at least one 437 TokenBinding structure, or if a signature contained in any 438 TokenBinding structure is invalid, the server MUST reject the 439 binding. 441 Servers MUST ignore any unknown extensions. Initially, no extension 442 types are defined (see Section 6.3 443 "Token Binding Extensions Registry"). 445 If all checks defined above have passed successfully, the Token 446 Binding between this client and server is established. The Token 447 Binding ID(s) conveyed in the Token Binding Message can be provided 448 to the server-side application. The application may then use the 449 Token Binding IDs for bound security token creation and validation, 450 see Section 5. 452 If a Token Binding is rejected, any associated bound tokens MUST also 453 be rejected by the server. The effect of this is application- 454 specific, e.g., failing requests, a requirement for the client to re- 455 authenticate and present a different token, or connection 456 termination. 458 5. Bound Security Token Creation and Validation 460 Security tokens can be bound to the TLS layer in a variety of ways: 461 by embedding the Token Binding ID or its cryptographic hash in the 462 token, or by maintaining a database mapping tokens to Token Binding 463 IDs. The specific method of generating bound security tokens is 464 application-defined and beyond the scope of this document. Note that 465 applicable security considerations are outlined in Section 7. 467 Either or both clients and servers MAY create bound security tokens. 468 For example, HTTPS servers employing Token Binding for securing their 469 HTTP cookies will bind these cookies. In the case of a server- 470 initiated challenge-response protocol employing Token Binding and 471 TLS, the client can, for example, incorporate the Token Binding ID 472 within the signed object it returns, thus binding the object. 474 Upon receipt of a security token, the server attempts to retrieve 475 Token Binding ID information from the token and from the TLS 476 connection with the client. Application-provided policy determines 477 whether to honor non-bound (bearer) tokens. If the token is bound 478 and a Token Binding has not been established for the client 479 connection, the server MUST reject the token. If the Token Binding 480 ID for the token does not match the Token Binding ID established for 481 the client connection, the server MUST reject the token. 483 6. IANA Considerations 485 This section establishes three IANA registries on a new registry page 486 entitled "Token Binding Protocol": "Token Binding Key Parameters", 487 "Token Binding Types" and "Token Binding Extensions". It also 488 registers a new TLS exporter label in the TLS Exporter Label 489 Registry. 491 6.1. Token Binding Key Parameters Registry 493 This document establishes a registry for identifiers of Token Binding 494 key parameters entitled "Token Binding Key Parameters" under the 495 "Token Binding Protocol" heading. 497 Entries in this registry require the following fields: 499 o Value: The octet value that identifies a set of Token Binding key 500 parameters (0-255). 502 o Description: The description of the Token Binding key parameters. 504 o Specification: A reference to a specification that defines the 505 Token Binding key parameters. 507 This registry operates under the "Expert Review" policy as defined in 508 [RFC8126]. The designated expert is advised to encourage the 509 inclusion of a reference to a permanent and readily available 510 specification that enables the creation of interoperable 511 implementations using the identified set of Token Binding key 512 parameters. 514 An initial set of registrations for this registry follows: 516 Value: 0 518 Description: rsa2048_pkcs1.5 520 Specification: this document 522 --------------------------------- 524 Value: 1 525 Description: rsa2048_pss 527 Specification: this document 529 --------------------------------- 531 Value: 2 533 Description: ecdsap256 535 Specification: this document 537 6.2. Token Binding Types Registry 539 This document establishes a registry for Token Binding type 540 identifiers entitled "Token Binding Types" under the "Token Binding 541 Protocol" heading. 543 Entries in this registry require the following fields: 545 o Value: The octet value that identifies the Token Binding type 546 (0-255). 548 o Description: The description of the Token Binding type. 550 o Specification: A reference to a specification that defines the 551 Token Binding type. 553 This registry operates under the "Expert Review" policy as defined in 554 [RFC8126]. The designated expert is advised to encourage the 555 inclusion of a reference to a permanent and readily available 556 specification that enables the creation of interoperable 557 implementations using the identified Token Binding type. 559 An initial set of registrations for this registry follows: 561 Value: 0 563 Description: provided_token_binding 565 Specification: this document 567 --------------------------------- 569 Value: 1 571 Description: referred_token_binding 572 Specification: this document 574 6.3. Token Binding Extensions Registry 576 This document establishes a registry for Token Binding extensions 577 entitled "Token Binding Extensions" under the "Token Binding 578 Protocol" heading. 580 Entries in this registry require the following fields: 582 o Value: The octet value that identifies the Token Binding extension 583 (0-255). 585 o Description: The description of the Token Binding extension. 587 o Specification: A reference to a specification that defines the 588 Token Binding extension. 590 This registry operates under the "Expert Review" policy as defined in 591 [RFC8126]. The designated expert is advised to encourage the 592 inclusion of a reference to a permanent and readily available 593 specification that enables the creation of interoperable 594 implementations using the identified Token Binding extension. This 595 document creates no initial registrations in the "Token Binding 596 Extensions" registry. 598 6.4. Registration of Token Binding TLS Exporter Label 600 This document adds the following registration in the TLS Exporter 601 Label Registry: 603 Value: EXPORTER-Token-Binding 605 DTLS-OK: Y 607 Reference: this document 609 7. Security Considerations 611 7.1. Security Token Replay 613 The goal of the Token Binding protocol is to prevent attackers from 614 exporting and replaying security tokens, thereby impersonating 615 legitimate users and gaining access to protected resources. Bound 616 tokens can be replayed by malware present in User Agents, which may 617 be undetectable by a server. However, in order to export bound 618 tokens to other machines and successfully replay them, attackers also 619 need to export corresponding Token Binding private keys. Token 620 Binding private keys are therefore high-value assets and SHOULD be 621 strongly protected, ideally by generating them in a hardware security 622 module that prevents key export. 624 The manner in which a token is bound to the TLS layer is application- 625 defined and beyond the scope of this document. However, the 626 resulting bound token needs to be integrity-protected, so that an 627 attacker cannot remove the binding or substitute a Token Binding ID 628 of their choice without detection. 630 The Token Binding protocol does not prevent cooperating clients from 631 sharing a bound token. A client could intentionally export a bound 632 token with the corresponding Token Binding private key, or perform 633 signatures using this key on behalf of another client. 635 7.2. Downgrade Attacks 637 The Token Binding protocol MUST be negotiated using a mechanism that 638 prevents downgrade. E.g., [I-D.ietf-tokbind-negotiation] uses a TLS 639 extension for Token Binding negotiation. TLS prevents active 640 attackers from modifying the messages of the TLS handshake, therefore 641 it is not possible for the attacker to remove or modify the Token 642 Binding Negotiation TLS Extension. The signature algorithm and key 643 length used in the TokenBinding of type "provided_token_binding" MUST 644 match the negotiated parameters. 646 7.3. Privacy Considerations 648 The Token Binding protocol uses persistent, long-lived Token Binding 649 IDs. To protect privacy, Token Binding IDs are never transmitted in 650 clear text and can be reset by the user at any time, e.g. when 651 clearing browser cookies. Some applications offer a special privacy 652 mode where they don't store or use tokens supplied by the server, 653 e.g., "in private" browsing. When operating in this special privacy 654 mode, applications SHOULD use newly generated Token Binding keys and 655 delete them when exiting this mode, or else SHOULD NOT negotiate 656 Token Binding at all. 658 In order to prevent cooperating servers from linking user identities, 659 the scope of the Token Binding keys MUST NOT be broader than the 660 scope of the tokens, as defined by the application protocol. 662 A server can use tokens and Token Binding IDs to track clients. 663 Client applications that automatically limit the lifetime or scope of 664 tokens to maintain user privacy SHOULD apply the same validity time 665 and scope limits to Token Binding keys. 667 7.4. Token Binding Key Sharing Between Applications 669 Existing systems provide a variety of platform-specific mechanisms 670 for certain applications to share tokens, e.g. to enable single sign- 671 on scenarios. For these scenarios to keep working with bound tokens, 672 the applications that are allowed to share tokens will need to also 673 share Token Binding keys. Care must be taken to restrict the sharing 674 of Token Binding keys to the same group(s) of applications that share 675 the same tokens. 677 7.5. Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions 679 The Token Binding protocol relies on the TLS Exporters [RFC5705] to 680 associate a TLS connection with a Token Binding. The triple 681 handshake attack [TRIPLE-HS] is a known vulnerability in TLS 1.2 and 682 older TLS versions, allowing the attacker to synchronize keying 683 material between TLS connections. The attacker can then successfully 684 replay bound tokens. For this reason, the Token Binding protocol 685 MUST NOT be negotiated with these TLS versions, unless the Extended 686 Master Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS 687 extensions have also been negotiated. 689 8. Acknowledgements 691 This document incorporates comments and suggestions offered by Eric 692 Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Anthony 693 Nadalin, Michael B. Jones, Bill Cox, Nick Harper, Brian Campbell, 694 and others. 696 This document was produced under the chairmanship of John Bradley and 697 Leif Johansson. The area directors included Eric Rescorla, Kathleen 698 Moriarty and Stephen Farrell. 700 9. References 702 9.1. Normative References 704 [ANSI.X9-62.2005] 705 American National Standards Institute, "Public Key 706 Cryptography for the Financial Services Industry, The 707 Elliptic Curve Digital Signature Algorithm (ECDSA)", 708 ANSI X9.62, 2005. 710 [FIPS.186-4.2013] 711 National Institute of Standards and Technology, "Digital 712 Signature Standard (DSS)", FIPS 186-4, 2013. 714 [I-D.ietf-tokbind-https] 715 Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 716 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 717 tokbind-https-12 (work in progress), January 2018. 719 [I-D.ietf-tokbind-negotiation] 720 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 721 "Transport Layer Security (TLS) Extension for Token 722 Binding Protocol Negotiation", draft-ietf-tokbind- 723 negotiation-10 (work in progress), October 2017. 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, 727 DOI 10.17487/RFC2119, March 1997, 728 . 730 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 731 (TLS) Protocol Version 1.2", RFC 5246, 732 DOI 10.17487/RFC5246, August 2008, 733 . 735 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 736 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 737 March 2010, . 739 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 740 "Transport Layer Security (TLS) Renegotiation Indication 741 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 742 . 744 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 745 Protocol (HTTP/1.1): Message Syntax and Routing", 746 RFC 7230, DOI 10.17487/RFC7230, June 2014, 747 . 749 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 750 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 751 DOI 10.17487/RFC7540, May 2015, 752 . 754 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 755 Langley, A., and M. Ray, "Transport Layer Security (TLS) 756 Session Hash and Extended Master Secret Extension", 757 RFC 7627, DOI 10.17487/RFC7627, September 2015, 758 . 760 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 761 Writing an IANA Considerations Section in RFCs", BCP 26, 762 RFC 8126, DOI 10.17487/RFC8126, June 2017, 763 . 765 9.2. Informative References 767 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 768 RFC 6749, DOI 10.17487/RFC6749, October 2012, 769 . 771 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 772 "PKCS #1: RSA Cryptography Specifications Version 2.2", 773 RFC 8017, DOI 10.17487/RFC8017, November 2016, 774 . 776 [TRIPLE-HS] 777 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 778 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 779 Breaking and Fixing Authentication over TLS. IEEE 780 Symposium on Security and Privacy", 2014. 782 Authors' Addresses 784 Andrei Popov (editor) 785 Microsoft Corp. 786 USA 788 Email: andreipo@microsoft.com 790 Magnus Nystroem 791 Microsoft Corp. 792 USA 794 Email: mnystrom@microsoft.com 796 Dirk Balfanz 797 Google Inc. 798 USA 800 Email: balfanz@google.com 801 Adam Langley 802 Google Inc. 803 USA 805 Email: agl@google.com 807 Jeff Hodges 808 PayPal 809 USA 811 Email: Jeff.Hodges@paypal.com