idnits 2.17.1 draft-ietf-tokbind-protocol-11.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 4 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 (November 23, 2016) is 2704 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-06 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-05 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** 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: 7 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: May 27, 2017 D. Balfanz 6 A. Langley 7 Google Inc. 8 J. Hodges 9 Paypal 10 November 23, 2016 12 The Token Binding Protocol Version 1.0 13 draft-ietf-tokbind-protocol-11 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 Token Binding identifiers are only transmitted encrypted 24 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 May 27, 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 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 . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . 13 80 7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 14 81 7.4. Token Binding Key Sharing Between Applications . . . . . 14 82 7.5. Triple Handshake Vulnerability in TLS 1.2 and Older TLS 83 Versions . . . . . . . . . . . . . . . . . . . . . . . . 14 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 87 9.2. Informative References . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 Servers generate various security tokens (e.g. HTTP cookies, OAuth 93 tokens) for applications to access protected resources. Any party in 94 possession of such token gains access to the protected resource. 95 Attackers export bearer tokens from the user's machine, present them 96 to the servers, and impersonate authenticated users. The idea of 97 Token Binding is to prevent such attacks by cryptographically binding 98 security tokens to the TLS layer. 100 A Token Binding is established by the user agent generating a 101 private-public key pair (possibly within a secure hardware module, 102 such as TPM) per target server, and proving possession of the private 103 key on every TLS connection to the target server. The proof of 104 possession involves signing the exported keying material [RFC5705] 105 for the TLS connection with the private key. The corresponding 106 public key is included in the Token Binding identifier structure 107 (described in the Section 3.2 "TokenBinding.tokenbindingid"). Token 108 Bindings are long-lived, i.e. they encompass multiple TLS connections 109 and TLS sessions between a given client and server. To protect 110 privacy, Token Binding IDs are never transmitted in clear text and 111 can be reset by the user at any time, e.g. when clearing browser 112 cookies. 114 When issuing a security token to a client that supports Token 115 Binding, a server includes the client's Token Binding ID in the 116 token. Later on, when a client presents a security token containing 117 a Token Binding ID, the server makes sure the ID in the token matches 118 the ID of the Token Binding established with the client. In the case 119 of a mismatch, the server discards the token. 121 In order to successfully export and replay a bound security token, 122 the attacker needs to also be able to export the client's private 123 key, which is hard to do in the case of the key generated in a secure 124 hardware module. 126 1.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2. Token Binding Protocol Overview 134 The client and server use the Token Binding Negotiation TLS Extension 135 [I-D.ietf-tokbind-negotiation] to negotiate the Token Binding 136 protocol version and the parameters (signature algorithm, length) of 137 the Token Binding key. This negotiation does not require additional 138 round-trips. 140 The Token Binding protocol consists of one message sent by the client 141 to the server, proving possession of one or more client-generated 142 asymmetric keys. This message is only sent if the client and server 143 agree on the use of the Token Binding protocol and the key 144 parameters. The Token Binding message is sent with the application 145 protocol data in TLS application_data records. 147 A server receiving the Token Binding message verifies that the key 148 parameters in the message match the Token Binding parameters 149 negotiated via [I-D.ietf-tokbind-negotiation], and then validates the 150 signatures contained in the Token Binding message. If either of 151 these checks fails, the server rejects the binding, along with all 152 associeted bound tokens. Otherwise the Token Binding is successfully 153 established with the ID contained in the Token Binding message. 155 When a server supporting the Token Binding protocol receives a bound 156 token, the server compares the Token Binding ID in the security token 157 with the Token Binding ID established with the client. If the bound 158 token came from a TLS connection without a Token Binding, or if the 159 IDs don't match, the token is discarded. 161 This document defines the format of the Token Binding protocol 162 message, the process of establishing a Token Binding, the format of 163 the Token Binding ID, and the process of validating a security token. 164 Token Binding Negotiation TLS Extension 165 [I-D.ietf-tokbind-negotiation] describes the negotiation of the Token 166 Binding protocol and key parameters. Token Binding over HTTP 167 [I-D.ietf-tokbind-https] explains how the Token Binding message is 168 encapsulated within HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] messages. 169 [I-D.ietf-tokbind-https] also describes Token Binding between 170 multiple communicating parties: User Agent, Identity Provider and 171 Relying Party. 173 3. Token Binding Protocol Message 175 The Token Binding message is sent by the client to prove possession 176 of one or more private keys held by the client. This message MUST be 177 sent if the client and server successfully negotiated the use of the 178 Token Binding protocol via [I-D.ietf-tokbind-negotiation], and MUST 179 NOT be sent otherwise. This message MUST be sent in the client's 180 first application protocol message. This message MAY also be sent in 181 subsequent application protocol messages, proving possession of 182 additional private keys held by the same client, which can be used to 183 facilitate token binding between more than two communicating parties. 184 For example, Token Binding over HTTP [I-D.ietf-tokbind-https] 185 specifies an encapsulation of the Token Binding message in HTTP 186 application protocol messages, as well as scenarios involving more 187 than two communicating parties. 189 The Token Binding message format is defined using TLS Presentation 190 Language (see Section 4 of [RFC5246]): 192 enum { 193 rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255) 194 } TokenBindingKeyParameters; 196 struct { 197 opaque modulus<1..2^16-1>; 198 opaque publicexponent<1..2^8-1>; 199 } RSAPublicKey; 201 struct { 202 opaque point <1..2^8-1>; 203 } ECPoint; 205 struct { 206 TokenBindingKeyParameters key_parameters; 207 uint16 key_length; /* Length (in bytes) of the following 208 TokenBindingID.TokenBindingPublicKey */ 209 select (key_parameters) { 210 case rsa2048_pkcs1.5: 211 case rsa2048_pss: 212 RSAPublicKey rsapubkey; 213 case ecdsap256: 214 ECPoint point; 215 } TokenBindingPublicKey; 216 } TokenBindingID; 218 enum { 219 (255) /* No initial ExtensionType registrations */ 220 } ExtensionType; 222 struct { 223 ExtensionType extension_type; 224 opaque extension_data<0..2^16-1>; 225 } Extension; 227 enum { 228 provided_token_binding(0), referred_token_binding(1), (255) 229 } TokenBindingType; 231 struct { 232 TokenBindingType tokenbinding_type; 233 TokenBindingID tokenbindingid; 234 opaque signature<0..2^16-1>; /* Signature over the concatenation of 235 tokenbinding_type, key_parameters and 236 exported keying material (EKM) */ 237 Extension extensions<0..2^16-1>; 238 } TokenBinding; 239 struct { 240 TokenBinding tokenbindings<0..2^16-1>; 241 } TokenBindingMessage; 243 The Token Binding message consists of a series of TokenBinding 244 structures, each containing the type of the token binding, the 245 TokenBindingID, a signature using the Token Binding key, optionally 246 followed by Extension structures. 248 3.1. TokenBinding.tokenbinding_type 250 This document defines two Token Binding types: 252 o provided_token_binding - used to establish a Token Binding when 253 connecting to a server. 255 o referred_token_binding - used when requesting tokens to be 256 presented to a different server. 258 Token Binding over HTTP [I-D.ietf-tokbind-https] describes a use case 259 for referred_token_binding where Token Bindings are established 260 between multiple communicating parties: User Agent, Identity Provider 261 and Relying Party. User Agent sends referred_token_binding to the 262 Identity Provider in order to prove possession of the Token Binding 263 key it uses with the Relying Party. The Identity Provider can then 264 bind the token it is supplying (for presentation to the Relying 265 Party) to the Token Binding ID contained in the 266 referred_token_binding. Such bound token enjoys the protections 267 discussed below in Section 7 "Security Considerations". 269 3.2. TokenBinding.tokenbindingid 271 The ID of the Token Binding established as a result of Token Binding 272 message processing contains the identifier of the key parameters 273 negotiated via [I-D.ietf-tokbind-negotiation], the length (in bytes) 274 of the Token Binding public key, and the Token Binding public key 275 itself. Token Binding ID can be obtained from the TokenBinding 276 structure by discarding the Token Binding type, signature and 277 extensions. 279 When rsa2048_pkcs1.5 or rsa2048_pss is used, RSAPublicKey.modulus and 280 RSAPublicKey.publicexponent contain the modulus and exponent of the 281 2048-bit RSA public key represented in big-endian format, with 282 leading zero bytes omitted. 284 When ecdsap256 is used, ECPoint.point contains the X coordinate 285 followed by the Y coordinate of the Curve P-256 key. The X and Y 286 coordinates are unsigned 32-byte integers encoded in big-endian 287 format, preserving any leading zero bytes. Future specifications may 288 define Token Binding keys using other elliptic curves with their 289 corresponding signature and point formats. 291 Token Binding protocol implementations SHOULD make Token Binding IDs 292 available to the application as opaque byte sequences. E.g. server 293 applications will use Token Binding IDs when generating and verifying 294 bound tokens. 296 3.3. TokenBinding.signature 298 When rsa2048_pkcs1.5 is used, TokenBinding.signature contains the 299 signature generated using the RSASSA-PKCS1-v1_5 signature scheme 300 defined in [RFC3447] with SHA256 as the hash function. 302 When rsa2048_pss is used, TokenBinding.signature contains the 303 signature generated using the RSASSA-PSS signature scheme defined in 304 [RFC3447] with SHA256 as the hash function. MGF1 with SHA256 MUST be 305 used as the mask generation function, and the salt length MUST equal 306 32 bytes. 308 When ecdsap256 is used, TokenBinding.signature contains a pair of 309 32-byte integers, R followed by S, generated with ECDSA using Curve 310 P-256 and SHA256 as defined in [ANSI.X9-62.2005] and 311 [FIPS.186-4.2013]. R and S are encoded in big-endian format, 312 preserving any leading zero bytes. 314 The signature is computed over the byte string representing the 315 concatenation of: 317 o TokenBindingType value contained in the 318 TokenBinding.tokenbinding_type field; 320 o TokenBindingKeyParameters value contained in the 321 TokenBindingID.key_parameters field; 323 o Exported keying material (EKM) value obtained from the current TLS 324 connection. 326 Please note that TLS 1.2 and earlier versions support renegotiaion, 327 which produces a new TLS master secret for the same connection, with 328 its associated session keys and EKM value. TokenBinding.signature 329 MUST use the EKM value derived from the same TLS master secret that 330 produced the session keys encrypting the application_data record 331 containing this TokenBinding. Such use of the current EKM for the 332 TLS connection prevents the replay of bound tokens within 333 renegotiated TLS sessions, but requires the application to 334 synchronize Token Binding message generation and verification with 335 the TLS handshake state. 337 Specifications defining the use of Token Binding with various 338 application protocols, such as Token Binding over HTTP 339 [I-D.ietf-tokbind-https], may prohibit the use of TLS renegotiation 340 in combination with Token Binding. Alternatively, such 341 specifications need to define a way to determine which EKM value 342 corresponds to a given TokenBindingMessage, and a mechanism 343 preventing a TokenBindingMessage from being split across the 344 renegotiation boundary. 346 The EKM is obtained using the Keying Material Exporters for TLS 347 defined in [RFC5705], by supplying the following input values: 349 o Label: The ASCII string "EXPORTER-Token-Binding" with no 350 terminating NUL. 352 o Context value: NULL (no application context supplied). 354 o Length: 32 bytes, for the signature schemes defined in this 355 document. Other signature schemes may require a longer exporter 356 output. 358 3.4. TokenBinding.extensions 360 A Token Binding message may optionally contain a series of Extension 361 structures, each consisting of an extension_type and extension_data. 362 The structure and meaning of extension_data depends on the specific 363 extension_type. 365 Initially, no extension types are defined (see Section 6.3 366 "Token Binding Extensions Registry"). One of the possible uses of 367 extensions envisioned at the time of this writing is attestation: 368 cryptographic proof that allows the server to verify that the Token 369 Binding key is hardware-bound. The definitions of such Token Binding 370 protocol extensions are outside the scope of this specification. 372 An implementation MUST ignore any unknown Token Binding types. 374 4. Establishing a Token Binding 376 4.1. Client Processing Rules 378 The client MUST include at least one TokenBinding structure in the 379 Token Binding message. The key parameters used in the 380 provided_token_binding MUST match those negotiated with the server 381 via [I-D.ietf-tokbind-negotiation]. 383 The client SHOULD generate and store Token Binding keys in a secure 384 manner that prevents key export. In order to prevent cooperating 385 servers from linking user identities, different keys SHOULD be used 386 by the client for connections to different servers, according to the 387 token scoping rules of the application protocol. 389 When the client needs to send a referred_token_binding to the 390 Identity Provider, the client SHALL construct the referred 391 TokenBinding structure in the following manner: 393 o Set TokenBinding.tokenbinding_type to referred_token_binding. 395 o Set TokenBinding.tokenbindingid to the Token Binding ID used with 396 the Relying Party. 398 o Generate TokenBinding.signature, using the EKM value of the TLS 399 connection to the Identity Provider, the Token Binding key 400 established with the Relying Party and the signature algorithm 401 indicated by the associated key parameters. Note that these key 402 parameters may differ from the key parameters negotiated with the 403 Identity Provider. 405 Conveying referred Token Bindings in this fashion allows the Identity 406 Provider to verify that the client controls the Token Binding key 407 used with the Relying Party. 409 4.2. Server Processing Rules 411 The triple handshake vulnerability in TLS 1.2 and older TLS versions 412 affects the security of the Token Binding protocol, as described in 413 Section 7 "Security Considerations". Therefore, the server MUST NOT 414 negotiate the use of the Token Binding protocol with these TLS 415 versions, unless the server also negotiates the Extended Master 416 Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS 417 extensions. 419 If the use of the Token Binding protocol was not negotiated, but the 420 client sends the Token Binding message, the server MUST reject any 421 contained bindings. If the Token Binding type is 422 "provided_token_binding", the server MUST verify that the signature 423 algorithm (including elliptic curve in the case of ECDSA) and key 424 length in the Token Binding message match those negotiated via 425 [I-D.ietf-tokbind-negotiation]. In the case of a mismatch, the 426 server MUST reject the binding. Token Bindings of type 427 "referred_token_binding" may use different key parameters than those 428 negotiated with this client. 430 If the Token Binding message does not contain at least one 431 TokenBinding structure, or if a signature contained in any 432 TokenBinding structure is invalid, the server MUST reject the 433 binding. 435 Servers MUST ignore any unknown extensions. Initially, no extension 436 types are defined (see Section 6.3 437 "Token Binding Extensions Registry"). 439 If all checks defined above have passed successfully, the Token 440 Binding between this client and server is established. The Token 441 Binding ID(s) conveyed in the Token Binding Message can be provided 442 to the server-side application. The application may then use the 443 Token Binding IDs for bound security token creation and validation, 444 see Section 5. 446 If a Token Binding is rejected, any associated bound tokens MUST also 447 be rejected by the server. The effect of this is application- 448 specific, e.g. failing requests, a requirement for the client to re- 449 authenticate and present a different token, or connection 450 termination. 452 5. Bound Security Token Creation and Validation 454 Security tokens can be bound to the TLS layer either by embedding the 455 Token Binding ID in the token, or by maintaining a database mapping 456 tokens to Token Binding IDs. The specific method of generating bound 457 security tokens is application-defined and beyond the scope of this 458 document. Note that applicable security considerations are outlined 459 in Section 7. 461 Either or both clients and servers MAY create bound security tokens. 462 For example, HTTPS servers employing Token Binding for securing their 463 HTTP cookies will bind the cookies. In the case of a server- 464 initiated challenge-response protocol employing Token Binding and 465 TLS, the client can, for example, incorporate the Token Binding ID 466 within the signed object it returns, thus binding the object. 468 Upon receipt of a security token, the server attempts to retrieve 469 Token Binding ID information from the token and from the TLS 470 connection with the client. Application-provided policy determines 471 whether to honor non-bound (bearer) tokens. If the token is bound 472 and a Token Binding has not been established for the client 473 connection, the server MUST discard the token. If the Token Binding 474 ID for the token does not match the Token Binding ID established for 475 the client connection, the server MUST discard the token. 477 6. IANA Considerations 479 This section establishes three IANA registries: "Token Binding Key 480 Parameters", "Token Binding Types" and "Token Binding Extensions". 481 It also registers a new TLS exporter label in the TLS Exporter Label 482 Registry. 484 6.1. Token Binding Key Parameters Registry 486 This document establishes a registry for identifiers of Token Binding 487 key parameters entitled "Token Binding Key Parameters" under the 488 "Token Binding Protocol" heading. 490 Entries in this registry require the following fields: 492 o Value: The octet value that identifies a set of Token Binding key 493 parameters (0-255). 495 o Description: The description of the Token Binding key parameters. 497 o Specification: A reference to a specification that defines the 498 Token Binding key parameters. 500 This registry operates under the "Expert Review" policy as defined in 501 [RFC5226]. The designated expert is advised to encourage the 502 inclusion of a reference to a permanent and readily available 503 specification that enables the creation of interoperable 504 implementations using the identified set of Token Binding key 505 parameters. 507 An initial set of registrations for this registry follows: 509 Value: 0 511 Description: rsa2048_pkcs1.5 513 Specification: this document 515 Value: 1 517 Description: rsa2048_pss 519 Specification: this document 521 Value: 2 523 Description: ecdsap256 524 Specification: this document 526 6.2. Token Binding Types Registry 528 This document establishes a registry for Token Binding type 529 identifiers entitled "Token Binding Types" under the "Token Binding 530 Protocol" heading. 532 Entries in this registry require the following fields: 534 o Value: The octet value that identifies the Token Binding type 535 (0-255). 537 o Description: The description of the Token Binding type. 539 o Specification: A reference to a specification that defines the 540 Token Binding type. 542 This registry operates under the "Expert Review" policy as defined in 543 [RFC5226]. The designated expert is advised to encourage the 544 inclusion of a reference to a permanent and readily available 545 specification that enables the creation of interoperable 546 implementations using the identified Token Binding type. 548 An initial set of registrations for this registry follows: 550 Value: 0 552 Description: provided_token_binding 554 Specification: this document 556 Value: 1 558 Description: referred_token_binding 560 Specification: this document 562 6.3. Token Binding Extensions Registry 564 This document establishes a registry for Token Binding extensions 565 entitled "Token Binding Extensions" under the "Token Binding 566 Protocol" heading. 568 Entries in this registry require the following fields: 570 o Value: The octet value that identifies the Token Binding extension 571 (0-255). 573 o Description: The description of the Token Binding extension. 575 o Specification: A reference to a specification that defines the 576 Token Binding extension. 578 This registry operates under the "Expert Review" policy as defined in 579 [RFC5226]. The designated expert is advised to encourage the 580 inclusion of a reference to a permanent and readily available 581 specification that enables the creation of interoperable 582 implementations using the identified Token Binding extension. This 583 document creates no initial registrations in the "Token Binding 584 Extensions" registry. 586 6.4. Registration of Token Binding TLS Exporter Label 588 This document adds a registration for the "EXPORTER-Token-Binding" 589 value in the TLS Exporter Label Registry to correspond to this 590 specification. 592 7. Security Considerations 594 7.1. Security Token Replay 596 The goal of the Token Binding protocol is to prevent attackers from 597 exporting and replaying security tokens, thereby impersonating 598 legitimate users and gaining access to protected resources. Bound 599 tokens can still be replayed by the malware present in the User 600 Agent. In order to export the token to another machine and 601 successfully replay it, the attacker also needs to export the 602 corresponding private key. Token Binding private keys are therefore 603 high-value assets and SHOULD be strongly protected, ideally by 604 generating them in a hardware security module that prevents key 605 export. 607 The manner in which a token is bound to the TLS layer is application- 608 defined and beyond the scope of this document. However, the 609 resulting bound token needs to be integrity-protected, so that an 610 attacker cannot remove the binding or substitute a Token Binding ID 611 of their choice without detection. 613 7.2. Downgrade Attacks 615 The Token Binding protocol is only used when negotiated via 616 [I-D.ietf-tokbind-negotiation] within the TLS handshake. TLS 617 prevents active attackers from modifying the messages of the TLS 618 handshake, therefore it is not possible for the attacker to remove or 619 modify the Token Binding Negotiation TLS Extension used to negotiate 620 the Token Binding protocol and key parameters. The signature 621 algorithm and key length used in the TokenBinding of type 622 "provided_token_binding" MUST match the parameters negotiated via 623 [I-D.ietf-tokbind-negotiation]. 625 7.3. Privacy Considerations 627 The Token Binding protocol uses persistent, long-lived Token Binding 628 IDs. To protect privacy, Token Binding IDs are never transmitted in 629 clear text and can be reset by the user at any time, e.g. when 630 clearing browser cookies. Some applications offer a special privacy 631 mode where they don't store or use tokens supplied by the server, 632 e.g. "in private" browsing. When operating in this special privacy 633 mode, applications SHOULD use newly generated Token Binding keys and 634 delete them when exiting this mode, or else SHOULD NOT negotiate 635 Token Binding at all. 637 In order to prevent cooperating servers from linking user identities, 638 different keys MUST be used by the client for connections to 639 different servers, according to the token scoping rules of the 640 application protocol. 642 A server can use tokens and Token Binding IDs to track clients. 643 Client applications that automatically limit the lifetime or scope of 644 tokens to maintain user privacy SHOULD apply the same validity time 645 and scope limits to Token Binding keys. 647 7.4. Token Binding Key Sharing Between Applications 649 Existing systems provide a variety of platform-specific mechanisms 650 for certain applications to share tokens, e.g. to enable single sign- 651 on scenarios. For these scenarios to keep working with bound tokens, 652 the applications that are allowed to share tokens will need to also 653 share Token Binding keys. Care must be taken to restrict the sharing 654 of Token Binding keys to the same group(s) of applications that share 655 the same tokens. 657 7.5. Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions 659 The Token Binding protocol relies on the exported keying material 660 (EKM) to associate a TLS connection with a Token Binding. The triple 661 handshake attack [TRIPLE-HS] is a known vulnerability in TLS 1.2 and 662 older TLS versions, allowing the attacker to synchronize keying 663 material between TLS connections. The attacker can then successfully 664 replay bound tokens. For this reason, the Token Binding protocol 665 MUST NOT be negotiated with these TLS versions, unless the Extended 666 Master Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS 667 extensions have also been negotiated. 669 8. Acknowledgements 671 This document incorporates comments and suggestions offered by Eric 672 Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Anthony 673 Nadalin, Michael B. Jones, Bill Cox, Nick Harper, Brian Campbell, 674 and others. 676 9. References 678 9.1. Normative References 680 [ANSI.X9-62.2005] 681 American National Standards Institute, "Public Key 682 Cryptography for the Financial Services Industry, The 683 Elliptic Curve Digital Signature Algorithm (ECDSA)", 684 ANSI X9.62, 2005. 686 [FIPS.186-4.2013] 687 National Institute of Standards and Technology, "Digital 688 Signature Standard (DSS)", FIPS 186-4, 2013. 690 [I-D.ietf-tokbind-https] 691 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 692 Hodges, "Token Binding over HTTP", draft-ietf-tokbind- 693 https-06 (work in progress), August 2016. 695 [I-D.ietf-tokbind-negotiation] 696 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 697 "Transport Layer Security (TLS) Extension for Token 698 Binding Protocol Negotiation", draft-ietf-tokbind- 699 negotiation-05 (work in progress), September 2016. 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, 703 DOI 10.17487/RFC2119, March 1997, 704 . 706 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 707 Standards (PKCS) #1: RSA Cryptography Specifications 708 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 709 2003, . 711 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 712 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 713 DOI 10.17487/RFC5226, May 2008, 714 . 716 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 717 (TLS) Protocol Version 1.2", RFC 5246, 718 DOI 10.17487/RFC5246, August 2008, 719 . 721 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 722 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 723 March 2010, . 725 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 726 "Transport Layer Security (TLS) Renegotiation Indication 727 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 728 . 730 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 731 Protocol (HTTP/1.1): Message Syntax and Routing", 732 RFC 7230, DOI 10.17487/RFC7230, June 2014, 733 . 735 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 736 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 737 DOI 10.17487/RFC7540, May 2015, 738 . 740 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 741 Langley, A., and M. Ray, "Transport Layer Security (TLS) 742 Session Hash and Extended Master Secret Extension", 743 RFC 7627, DOI 10.17487/RFC7627, September 2015, 744 . 746 9.2. Informative References 748 [TRIPLE-HS] 749 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 750 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 751 Breaking and Fixing Authentication over TLS. IEEE 752 Symposium on Security and Privacy", 2014. 754 Authors' Addresses 756 Andrei Popov (editor) 757 Microsoft Corp. 758 USA 760 Email: andreipo@microsoft.com 761 Magnus Nystroem 762 Microsoft Corp. 763 USA 765 Email: mnystrom@microsoft.com 767 Dirk Balfanz 768 Google Inc. 769 USA 771 Email: balfanz@google.com 773 Adam Langley 774 Google Inc. 775 USA 777 Email: agl@google.com 779 Jeff Hodges 780 Paypal 781 USA 783 Email: Jeff.Hodges@paypal.com