idnits 2.17.1 draft-ietf-tokbind-protocol-07.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([RFC5246]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2016) is 2851 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4492' is defined on line 642, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-tokbind-https-03 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-02 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** 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: 8 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: January 8, 2017 D. Balfanz 6 A. Langley 7 Google Inc. 8 J. Hodges 9 Paypal 10 July 7, 2016 12 The Token Binding Protocol Version 1.0 13 draft-ietf-tokbind-protocol-07 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 [RFC5246] bindings 20 spanning multiple TLS sessions and connections. Applications are 21 then enabled to cryptographically bind security tokens to the TLS 22 layer, preventing token export and replay attacks. To protect 23 privacy, the TLS Token Binding identifiers are only transmitted 24 encrypted and can be reset 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 http://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 January 8, 2017. 43 Copyright Notice 45 Copyright (c) 2016 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 (http://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 4. Establishing a TLS Token Binding . . . . . . . . . . . . . . 7 65 4.1. Client Processing Rules . . . . . . . . . . . . . . . . . 7 66 4.2. Server Processing Rules . . . . . . . . . . . . . . . . . 7 67 5. TLS Token Binding ID Format . . . . . . . . . . . . . . . . . 8 68 6. Security Token Validation . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 7.1. Token Binding Key Parameters Registry . . . . . . . . . . 10 71 7.2. Token Binding Types Registry . . . . . . . . . . . . . . 11 72 7.3. Token Binding Extensions Registry . . . . . . . . . . . . 11 73 7.4. Registration of Token Binding TLS Exporter Label . . . . 12 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 8.1. Security Token Replay . . . . . . . . . . . . . . . . . . 12 76 8.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 12 77 8.3. Privacy Considerations . . . . . . . . . . . . . . . . . 13 78 8.4. Token Binding Key Sharing Between Applications . . . . . 13 79 8.5. Triple Handshake Vulnerability in TLS 1.2 and Older TLS 80 Versions . . . . . . . . . . . . . . . . . . . . . . . . 13 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 84 10.2. Informative References . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 Servers generate various security tokens (e.g. HTTP cookies, OAuth 90 tokens) for applications to access protected resources. Any party in 91 possession of such token gains access to the protected resource. 92 Attackers export bearer tokens from the user's machine, present them 93 to the servers, and impersonate authenticated users. The idea of 94 Token Binding is to prevent such attacks by cryptographically binding 95 security tokens to the TLS layer. 97 A TLS Token Binding is established by the user agent generating a 98 private-public key pair (possibly within a secure hardware module, 99 such as TPM) per target server, and proving possession of the private 100 key on every TLS connection to the target server. The proof of 101 possession involves signing the exported keying material [RFC5705] 102 for the TLS connection with the private key. The corresponding 103 public key is included in the TLS Token Binding identifier structure 104 (described in the "TLS Token Binding ID Format" section of this 105 document). TLS Token Bindings are long-lived, i.e. they encompass 106 multiple TLS connections and TLS sessions between a given client and 107 server. To protect privacy, TLS Token Binding IDs are never 108 transmitted in clear text and can be reset by the user at any time, 109 e.g. when clearing browser cookies. 111 When issuing a security token to a client that supports TLS Token 112 Binding, a server includes the client's TLS Token Binding ID in the 113 token. Later on, when a client presents a security token containing 114 a TLS Token Binding ID, the server makes sure the ID in the token 115 matches the ID of the TLS Token Binding established with the client. 116 In the case of a mismatch, the server discards the token. 118 In order to successfully export and replay a bound security token, 119 the attacker needs to also be able to export the client's private 120 key, which is hard to do in the case of the key generated in a secure 121 hardware module. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2. Token Binding Protocol Overview 131 The client and server use the Token Binding Negotiation TLS Extension 132 [I-D.ietf-tokbind-negotiation] to negotiate the Token Binding 133 protocol version and the parameters (signature algorithm, length) of 134 the Token Binding key. This negotiation does not require additional 135 round-trips. 137 The Token Binding protocol consists of one message sent by the client 138 to the server, proving possession of one or more client-generated 139 asymmetric keys. This message is only sent if the client and server 140 agree on the use of the Token Binding protocol and the key 141 parameters. The Token Binding message is sent with the application 142 protocol data in TLS application_data records. 144 A server receiving the Token Binding message verifies that the key 145 parameters in the message match the Token Binding parameters 146 negotiated via [I-D.ietf-tokbind-negotiation], and then validates the 147 signatures contained in the Token Binding message. If either of 148 these checks fails, the server terminates the connection, otherwise 149 the TLS Token Binding is successfully established with the ID 150 contained in the Token Binding message. 152 When a server supporting the Token Binding protocol receives a bound 153 token, the server compares the TLS Token Binding ID in the security 154 token with the TLS Token Binding ID established with the client. If 155 the bound token came from a TLS connection without a Token Binding, 156 or if the IDs don't match, the token is discarded. 158 This document defines the format of the Token Binding protocol 159 message, the process of establishing a TLS Token Binding, the format 160 of the Token Binding ID, and the process of validating a security 161 token. Token Binding Negotiation TLS Extension 162 [I-D.ietf-tokbind-negotiation] describes the negotiation of the Token 163 Binding protocol and key parameters. Token Binding over HTTP 164 [I-D.ietf-tokbind-https] explains how the Token Binding message is 165 encapsulated within HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] messages. 166 [I-D.ietf-tokbind-https] also describes Token Binding between 167 multiple communicating parties: User Agent, Identity Provider and 168 Relying Party. 170 3. Token Binding Protocol Message 172 The Token Binding message is sent by the client to prove possession 173 of one or more private keys held by the client. This message MUST be 174 sent if the client and server successfully negotiated the use of the 175 Token Binding protocol via [I-D.ietf-tokbind-negotiation], and MUST 176 NOT be sent otherwise. This message MUST be sent in the client's 177 first application protocol message. This message MAY also be sent in 178 subsequent application protocol messages, proving possession of 179 additional private keys held by the same client, which can be used to 180 facilitate token binding between more than two communicating parties. 181 For example, Token Binding over HTTP [I-D.ietf-tokbind-https] 182 specifies an encapsulation of the Token Binding message in HTTP 183 application protocol messages, as well as scenarios involving more 184 than two communicating parties. 186 The Token Binding message format is defined using TLS Presentation 187 Language (see Section 4 of [RFC5246]): 189 enum { 190 rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255) 191 } TokenBindingKeyParameters; 193 struct { 194 opaque modulus<1..2^16-1>; 195 opaque publicexponent<1..2^8-1>; 196 } RSAPublicKey; 198 struct { 199 opaque point <1..2^8-1>; 200 } ECPoint; 202 enum { 203 provided_token_binding(0), referred_token_binding(1), (255) 204 } TokenBindingType; 206 struct { 207 TokenBindingKeyParameters key_parameters; 208 select (key_parameters) { 209 case rsa2048_pkcs1.5: 210 case rsa2048_pss: 211 RSAPublicKey rsapubkey; 212 case ecdsap256: 213 ECPoint point; 214 } 215 } TokenBindingID; 217 enum { 218 (255) // No initial ExtensionType registrations 219 } ExtensionType; 221 struct { 222 ExtensionType extension_type; 223 opaque extension_data<0..2^16-1>; 224 } Extension; 226 struct { 227 TokenBindingType tokenbinding_type; 228 TokenBindingID tokenbindingid; 229 opaque signature<0..2^16-1>;// Signature over the exported keying material value 230 Extension extensions<0..2^16-1>; 231 } TokenBinding; 233 struct { 234 TokenBinding tokenbindings<0..2^16-1>; 235 } TokenBindingMessage; 236 The Token Binding message consists of a series of TokenBinding 237 structures, each containing the type of the token binding, the 238 TokenBindingID, a signature over an exported keying material (EKM) 239 value, optionally followed by Extension structures. 241 This document defines two Token Binding types: 243 o provided_token_binding - used to establish a Token Binding when 244 connecting to a server. 246 o referred_token_binding - used when requesting tokens to be 247 presented to a different server. 249 Token Binding over HTTP [I-D.ietf-tokbind-https] describes a use case 250 for referred_token_binding where Token Bindings are established 251 between multiple communicating parties: User Agent, Identity Provider 252 and Relying Party. User Agent sends referred_token_binding to the 253 Identity Provider in order to prove possession of the Token Binding 254 key it uses with the Relying Party. The Identity Provider can then 255 bind the token it is supplying (for presentation to the Relying 256 Party) to the Token Binding ID contained in the 257 referred_token_binding. Such bound token enjoys the protections 258 discussed below in Section 8 "Security Considerations". 260 This document establishes an IANA registry for Token Binding 261 extensions in Section 7.2 "Token Binding Types Registry". An 262 implementation MUST ignore any unknown Token Binding types. 264 When an rsa2048_pkcs1.5 or rsa2048_pss key is used, 265 TokenBinding.signature contains the signature generated using, 266 respectively, the RSASSA-PKCS1-v1_5 or RSASSA-PSS signature scheme 267 defined in [RFC3447]. RSAPublicKey.modulus and 268 RSAPublicKey.publicexponent contain the length-prefixed modulus and 269 exponent of the RSA public key represented in big-endian format. 271 When an ecdsap256 key is used, TokenBinding.signature contains a pair 272 of 32-byte integers, R followed by S, generated using Curve P-256 as 273 defined in [ANSI.X9-62.2005] and [FIPS.186-4.2013]. R and S are 274 encoded in big-endian format, preserving any leading zero bytes. 275 ECPoint.point contains the X coordinate followed by the Y coordinate. 276 The X and Y coordinates are unsigned 32-byte integers encoded in big- 277 endian format, preserving any leading zero bytes. Future 278 specifications may define Token Binding keys using other elliptic 279 curves with their corresponding signature and point formats. 281 The EKM is obtained using the Keying Material Exporters for TLS 282 defined in [RFC5705], by supplying the following input values: 284 o Label: The ASCII string "EXPORTER-Token-Binding" with no 285 terminating NUL. 287 o Context value: NULL (no application context supplied). 289 o Length: 32 bytes. 291 4. Establishing a TLS Token Binding 293 4.1. Client Processing Rules 295 The client MUST include at least one TokenBinding structure in the 296 Token Binding message. The key parameters used in the 297 provided_token_binding MUST match those negotiated with the server 298 via [I-D.ietf-tokbind-negotiation]. 300 The client SHOULD generate and store Token Binding keys in a secure 301 manner that prevents key export. In order to prevent cooperating 302 servers from linking user identities, different keys SHOULD be used 303 by the client for connections to different servers, according to the 304 token scoping rules of the application protocol. 306 When the client needs to send a referred_token_binding to the 307 Identity Provider, the client SHALL construct the referred 308 TokenBinding structure in the following manner: 310 o Set TokenBinding.tokenbinding_type to referred_token_binding. 312 o Set TokenBinding.tokenbindingid to the Token Binding ID used with 313 the Relying Party. 315 o Set TokenBinding.signature to the result of signing the EKM value 316 of the TLS connection to the Identity Provider, using the Token 317 Binding key established with the Relying Party and the signature 318 algorithm indicated by the associated key parameters. Note that 319 these key parameters may differ from the key parameters negotiated 320 with the Identity Provider. 322 Conveying referred Token Bindings in this fashion allows the Identity 323 Provider to verify that the client controls the Token Binding key 324 used with the Relying Party. 326 4.2. Server Processing Rules 328 The triple handshake vulnerability in TLS 1.2 and older TLS versions 329 affects the security of the Token Binding protocol, as described in 330 Section 8 "Security Considerations". Therefore, the server MUST NOT 331 negotiate the use of the Token Binding protocol with these TLS 332 versions, unless the server also negotiates Extended Master Secret 333 [RFC7627] and Renegotiation Indication [RFC5746] TLS extensions. 335 The server MUST terminate the connection if the use of the Token 336 Binding protocol was not negotiated, but the client sends the Token 337 Binding message. If the Token Binding type is 338 "provided_token_binding", the server MUST verify that the signature 339 algorithm (including elliptic curve in the case of ECDSA) and key 340 length in the Token Binding message match those negotiated via 341 [I-D.ietf-tokbind-negotiation]. In the case of a mismatch, the 342 server MUST terminate the connection. Token Bindings of type 343 "referred_token_binding" may use different key parameters than those 344 negotiated with this client. 346 If the Token Binding message does not contain at least one 347 TokenBinding structure, or if a signature contained in any 348 TokenBinding structure is invalid, the server MUST terminate the 349 connection. 351 Servers MUST ignore any unknown extensions. Initially, no extension 352 types are defined (see Section 7.3 353 "Token Binding Extensions Registry"). One of the possible uses of 354 extensions envisioned at the time of this writing is attestation: 355 cryptographic proof that allows the server to verify that the Token 356 Binding key is hardware-bound. The definitions of such Token Binding 357 protocol extensions are outside the scope of this specification. 359 If all checks defined above have passed successfully, the TLS Token 360 Binding between this client and server is established. The Token 361 Binding ID(s) conveyed in the Token Binding Message can be provided 362 to the server-side application. The application may then use the 363 Token Binding IDs for bound security token creation and validation. 365 5. TLS Token Binding ID Format 366 The ID of the TLS Token Binding established as a result of Token 367 Binding message processing is a binary representation of the 368 following structure: 370 struct { 371 TokenBindingKeyParameters key_parameters; 372 select (key_parameters) { 373 case rsa2048_pkcs1.5: 374 case rsa2048_pss: 375 RSAPublicKey rsapubkey; 376 case ecdsap256: 377 ECPoint point; 378 } 379 } TokenBindingID; 381 TokenBindingID contains the key parameters negotiated via 382 [I-D.ietf-tokbind-negotiation]. TLS Token Binding ID can be obtained 383 from the TokenBinding structure described in the "Token Binding 384 Protocol Message" section of this document by discarding the Token 385 Binding type, signature and extensions. Token Binding protocol 386 implementations SHOULD make Token Binding IDs available to the 387 application as opaque byte sequences. E.g. server applications will 388 use Token Binding IDs when generating and verifying bound tokens. 390 6. Security Token Validation 392 Security tokens can be bound to the TLS layer either by embedding the 393 Token Binding ID in the token, or by maintaining a database mapping 394 tokens to Token Binding IDs. The specific method of generating bound 395 security tokens is application-defined and beyond the scope of this 396 document. 398 Upon receipt of a security token, the server attempts to retrieve TLS 399 Token Binding ID information from the token and from the TLS 400 connection with the client. Application-provided policy determines 401 whether to honor non-bound (bearer) tokens. If the token is bound 402 and a TLS Token Binding has not been established for the client 403 connection, the server MUST discard the token. If the TLS Token 404 Binding ID for the token does not match the TLS Token Binding ID 405 established for the client connection, the server MUST discard the 406 token. 408 7. IANA Considerations 410 This section establishes three IANA registries: "Token Binding Key 411 Parameters", "Token Binding Types" and "Token Binding Extensions". 412 It also registers a new TLS exporter label in the TLS Exporter Label 413 Registry. 415 7.1. Token Binding Key Parameters Registry 417 This document establishes a registry for identifiers of Token Binding 418 key parameters entitled "Token Binding Key Parameters" under the 419 "Token Binding Protocol" heading. 421 Entries in this registry require the following fields: 423 o Value: The octet value that identifies a set of Token Binding key 424 parameters (0-255). 426 o Description: The description of the Token Binding key parameters. 428 o Specification: A reference to a specification that defines the 429 Token Binding key parameters. 431 This registry operates under the "Expert Review" policy as defined in 432 [RFC5226]. The designated expert is advised to encourage the 433 inclusion of a reference to a permanent and readily available 434 specification that enables the creation of interoperable 435 implementations using the identified set of Token Binding key 436 parameters. 438 An initial set of registrations for this registry follows: 440 Value: 0 442 Description: rsa2048_pkcs1.5 444 Specification: this document 446 Value: 1 448 Description: rsa2048_pss 450 Specification: this document 452 Value: 2 454 Description: ecdsap256 455 Specification: this document 457 7.2. Token Binding Types Registry 459 This document establishes a registry for Token Binding type 460 identifiers entitled "Token Binding Types" under the "Token Binding 461 Protocol" heading. 463 Entries in this registry require the following fields: 465 o Value: The octet value that identifies the Token Binding type 466 (0-255). 468 o Description: The description of the Token Binding type. 470 o Specification: A reference to a specification that defines the 471 Token Binding type. 473 This registry operates under the "Expert Review" policy as defined in 474 [RFC5226]. The designated expert is advised to encourage the 475 inclusion of a reference to a permanent and readily available 476 specification that enables the creation of interoperable 477 implementations using the identified Token Binding type. 479 An initial set of registrations for this registry follows: 481 Value: 0 483 Description: provided_token_binding 485 Specification: this document 487 Value: 1 489 Description: referred_token_binding 491 Specification: this document 493 7.3. Token Binding Extensions Registry 495 This document establishes a registry for Token Binding extensions 496 entitled "Token Binding Extensions" under the "Token Binding 497 Protocol" heading. 499 Entries in this registry require the following fields: 501 o Value: The octet value that identifies the Token Binding extension 502 (0-255). 504 o Description: The description of the Token Binding extension. 506 o Specification: A reference to a specification that defines the 507 Token Binding extension. 509 This registry operates under the "Expert Review" policy as defined in 510 [RFC5226]. The designated expert is advised to encourage the 511 inclusion of a reference to a permanent and readily available 512 specification that enables the creation of interoperable 513 implementations using the identified Token Binding extension. This 514 document creates no initial registrations in the "Token Binding 515 Extensions" registry. 517 7.4. Registration of Token Binding TLS Exporter Label 519 This document adds a registration for the "EXPORTER-Token-Binding" 520 value in the TLS Exporter Label Registry to correspond to this 521 specification. 523 8. Security Considerations 525 8.1. Security Token Replay 527 The goal of the Token Binding protocol is to prevent attackers from 528 exporting and replaying security tokens, thereby impersonating 529 legitimate users and gaining access to protected resources. Bound 530 tokens can still be replayed by the malware present in the User 531 Agent. In order to export the token to another machine and 532 successfully replay it, the attacker also needs to export the 533 corresponding private key. Token Binding private keys are therefore 534 high-value assets and SHOULD be strongly protected, ideally by 535 generating them in a hardware security module that prevents key 536 export. 538 The manner in which a token is bound to the TLS layer is application- 539 defined and beyond the scope of this document. However, the 540 resulting bound token needs to be integrity-protected, so that an 541 attacker cannot remove the binding or substitute a Token Binding ID 542 of their choice without detection. 544 8.2. Downgrade Attacks 546 The Token Binding protocol is only used when negotiated via 547 [I-D.ietf-tokbind-negotiation] within the TLS handshake. TLS 548 prevents active attackers from modifying the messages of the TLS 549 handshake, therefore it is not possible for the attacker to remove or 550 modify the Token Binding Negotiation TLS Extension used to negotiate 551 the Token Binding protocol and key parameters. The signature 552 algorithm and key length used in the TokenBinding of type 553 "provided_token_binding" MUST match the parameters negotiated via 554 [I-D.ietf-tokbind-negotiation]. 556 8.3. Privacy Considerations 558 The Token Binding protocol uses persistent, long-lived TLS Token 559 Binding IDs. To protect privacy, TLS Token Binding IDs are never 560 transmitted in clear text and can be reset by the user at any time, 561 e.g. when clearing browser cookies. Some applications offer a 562 special privacy mode where they don't store or use tokens supplied by 563 the server, e.g. "in private" browsing. When operating in this 564 special privacy mode, applications SHOULD use newly generated Token 565 Binding keys and delete them when exiting this mode, or else SHOULD 566 NOT negotiate Token Binding at all. 568 In order to prevent cooperating servers from linking user identities, 569 different keys SHOULD be used by the client for connections to 570 different servers, according to the token scoping rules of the 571 application protocol. 573 A server can use tokens and Token Binding IDs to track clients. 574 Client applications that automatically limit the lifetime of tokens 575 to maintain user privacy SHOULD apply the same validity time limits 576 to Token Binding keys. 578 8.4. Token Binding Key Sharing Between Applications 580 Existing systems provide a variety of platform-specific mechanisms 581 for certain applications to share tokens, e.g. to enable single sign- 582 on scenarios. For these scenarios to keep working with bound tokens, 583 the applications that are allowed to share tokens will need to also 584 share Token Binding keys. Care must be taken to restrict the sharing 585 of Token Binding keys to the same group(s) of applications that share 586 the same tokens. 588 8.5. Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions 590 The Token Binding protocol relies on the exported keying material 591 (EKM) to associate a TLS connection with a Token Binding. The triple 592 handshake attack [TRIPLE-HS] is a known vulnerability in TLS 1.2 and 593 older TLS versions, allowing the attacker to synchronize keying 594 material between TLS connections. The attacker can then successfully 595 replay bound tokens. For this reason, the Token Binding protocol 596 MUST NOT be negotiated with these TLS versions, unless the Extended 597 Master Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS 598 extensions have also been negotiated. 600 9. Acknowledgements 602 This document incorporates comments and suggestions offered by Eric 603 Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Anthony 604 Nadalin, Michael Jones, Bill Cox, Nick Harper, Brian Campbell and 605 others. 607 10. References 609 10.1. Normative References 611 [ANSI.X9-62.2005] 612 American National Standards Institute, "Public Key 613 Cryptography for the Financial Services Industry, The 614 Elliptic Curve Digital Signature Algorithm (ECDSA)", 615 ANSI X9.62, 2005. 617 [FIPS.186-4.2013] 618 National Institute of Standards and Technology, "Digital 619 Signature Standard (DSS)", FIPS 186-4, 2013. 621 [I-D.ietf-tokbind-https] 622 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 623 Hodges, "Token Binding over HTTP", draft-ietf-tokbind- 624 https-03 (work in progress), March 2016. 626 [I-D.ietf-tokbind-negotiation] 627 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 628 "Transport Layer Security (TLS) Extension for Token 629 Binding Protocol Negotiation", draft-ietf-tokbind- 630 negotiation-02 (work in progress), January 2016. 632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 633 Requirement Levels", BCP 14, RFC 2119, 634 DOI 10.17487/RFC2119, March 1997, 635 . 637 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 638 Standards (PKCS) #1: RSA Cryptography Specifications 639 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 640 2003, . 642 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 643 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 644 for Transport Layer Security (TLS)", RFC 4492, 645 DOI 10.17487/RFC4492, May 2006, 646 . 648 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 649 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 650 DOI 10.17487/RFC5226, May 2008, 651 . 653 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 654 (TLS) Protocol Version 1.2", RFC 5246, 655 DOI 10.17487/RFC5246, August 2008, 656 . 658 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 659 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 660 March 2010, . 662 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 663 "Transport Layer Security (TLS) Renegotiation Indication 664 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 665 . 667 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 668 Protocol (HTTP/1.1): Message Syntax and Routing", 669 RFC 7230, DOI 10.17487/RFC7230, June 2014, 670 . 672 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 673 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 674 DOI 10.17487/RFC7540, May 2015, 675 . 677 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 678 Langley, A., and M. Ray, "Transport Layer Security (TLS) 679 Session Hash and Extended Master Secret Extension", 680 RFC 7627, DOI 10.17487/RFC7627, September 2015, 681 . 683 10.2. Informative References 685 [TRIPLE-HS] 686 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 687 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 688 Breaking and Fixing Authentication over TLS. IEEE 689 Symposium on Security and Privacy", 2014. 691 Authors' Addresses 692 Andrei Popov (editor) 693 Microsoft Corp. 694 USA 696 Email: andreipo@microsoft.com 698 Magnus Nystroem 699 Microsoft Corp. 700 USA 702 Email: mnystrom@microsoft.com 704 Dirk Balfanz 705 Google Inc. 706 USA 708 Email: balfanz@google.com 710 Adam Langley 711 Google Inc. 712 USA 714 Email: agl@google.com 716 Jeff Hodges 717 Paypal 718 USA 720 Email: Jeff.Hodges@paypal.com