idnits 2.17.1 draft-ietf-tokbind-protocol-12.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 : ---------------------------------------------------------------------------- ** 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 (February 16, 2017) is 2623 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-07 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-06 ** 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: 6 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: August 20, 2017 D. Balfanz 6 A. Langley 7 Google Inc. 8 J. Hodges 9 Paypal 10 February 16, 2017 12 The Token Binding Protocol Version 1.0 13 draft-ietf-tokbind-protocol-12 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 conveyed over TLS and 24 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 August 20, 2017. 43 Copyright Notice 45 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . 9 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 . . . . . 14 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 . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 Often, servers generate various security tokens (e.g. HTTP cookies, 93 OAuth tokens) for applications to present when accessing protected 94 resources. In general, any party in possession of bearer security 95 tokens gain access to certain protected resource(s). Attackers take 96 advantage of this by exporting bearer tokens from user's application 97 connections or machines, presenting them to application servers, and 98 impersonating authenticated users. The idea of Token Binding is to 99 prevent such attacks by cryptographically binding application 100 security tokens to the underlying TLS layer. 102 A Token Binding is established by a user agent generating a private- 103 public key pair (possibly, within a secure hardware module, such as 104 TPM) per target server, providing the public key to the server, and 105 proving possession of the corresponding private key, on every TLS 106 connection to the server. The proof of possession involves signing 107 the exported keying material (EKM) [RFC5705] from the TLS connection 108 with the private key. The corresponding public key is included in 109 the Token Binding identifier structure (described in the Section 3.2 110 "TokenBinding.tokenbindingid"). Token Bindings are long-lived, i.e., 111 they encompass multiple TLS connections and TLS sessions between a 112 given client and server. To protect privacy, Token Binding IDs are 113 never conveyed over insecure connections and can be reset by the user 114 at any time, e.g., when clearing browser cookies. 116 When issuing a security token to a client that supports Token 117 Binding, a server includes the client's Token Binding ID in the 118 token. Later on, when a client presents a security token containing 119 a Token Binding ID, the server ensures the ID in the token matches 120 the ID of the Token Binding established with the client. In the case 121 of a mismatch, the server rejects the token (details are application- 122 specific). 124 In order to successfully export and replay a bound security token, an 125 attacker needs to also be able to export the client's private key, 126 which is hard to do if the key is specially protected, e.g., 127 generated in a secure hardware module. 129 1.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 2. Token Binding Protocol Overview 137 In the course of a TLS handshake, a client and server use the Token 138 Binding Negotiation TLS Extension [I-D.ietf-tokbind-negotiation] to 139 negotiate the Token Binding protocol version and the parameters 140 (signature algorithm, length) of the Token Binding key. This 141 negotiation does not require additional round-trips. 143 The Token Binding protocol consists of one message sent by the client 144 to the server, proving possession of one or more client-generated 145 asymmetric private keys. This message is not sent if the Token 146 Binding Negotiation has been unsuccessful. The Token Binding message 147 is sent with the application protocol data over TLS. 149 A server receiving the Token Binding message verifies that the key 150 parameters in the message match the Token Binding parameters 151 negotiated via [I-D.ietf-tokbind-negotiation], and then validates the 152 signatures contained in the Token Binding message. If either of 153 these checks fails, the server rejects the binding, along with all 154 associeted bound tokens. Otherwise the Token Binding is successfully 155 established with the ID contained in the Token Binding message. 157 When a server supporting the Token Binding protocol receives a bound 158 token, the server compares the Token Binding ID in the token with the 159 Token Binding ID established with the client. If the bound token 160 came from a TLS connection without a Token Binding, or if the Token 161 Binding IDs do not match, the token is rejected. 163 This document defines the format of the Token Binding protocol 164 message, the process of establishing a Token Binding, the format of 165 the Token Binding ID, and the process of validating a bound token. 166 Token Binding Negotiation TLS Extension 167 [I-D.ietf-tokbind-negotiation] describes the negotiation of the Token 168 Binding protocol and key parameters. Token Binding over HTTP 169 [I-D.ietf-tokbind-https] explains how the Token Binding message is 170 encapsulated within HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] messages. 171 [I-D.ietf-tokbind-https] also describes Token Binding between 172 multiple communicating parties: User Agent, Identity Provider and 173 Relying Party. 175 3. Token Binding Protocol Message 177 The Token Binding message is sent by the client to prove possession 178 of one or more private keys held by the client. This message MUST be 179 sent if the client and server successfully negotiated the use of the 180 Token Binding protocol via [I-D.ietf-tokbind-negotiation], and MUST 181 NOT be sent otherwise. This message MUST be sent in the client's 182 first application protocol message. This message MAY also be sent in 183 subsequent application protocol messages, proving possession of 184 additional private keys held by the same client, which can be used to 185 facilitate token binding between more than two communicating parties. 186 For example, Token Binding over HTTP [I-D.ietf-tokbind-https] 187 specifies an encapsulation of the Token Binding message in HTTP 188 application protocol messages, as well as scenarios involving more 189 than two communicating parties. 191 The Token Binding message format is defined using TLS Presentation 192 Language (see Section 4 of [RFC5246]): 194 enum { 195 rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255) 196 } TokenBindingKeyParameters; 198 struct { 199 opaque modulus<1..2^16-1>; 200 opaque publicexponent<1..2^8-1>; 201 } RSAPublicKey; 203 struct { 204 opaque point <1..2^8-1>; 205 } ECPoint; 207 struct { 208 TokenBindingKeyParameters key_parameters; 209 uint16 key_length; /* Length (in bytes) of the following 210 TokenBindingID.TokenBindingPublicKey */ 211 select (key_parameters) { 212 case rsa2048_pkcs1.5: 213 case rsa2048_pss: 214 RSAPublicKey rsapubkey; 215 case ecdsap256: 216 ECPoint point; 217 } TokenBindingPublicKey; 218 } TokenBindingID; 220 enum { 221 (255) /* No initial ExtensionType registrations */ 222 } ExtensionType; 224 struct { 225 ExtensionType extension_type; 226 opaque extension_data<0..2^16-1>; 227 } Extension; 229 enum { 230 provided_token_binding(0), referred_token_binding(1), (255) 231 } TokenBindingType; 233 struct { 234 TokenBindingType tokenbinding_type; 235 TokenBindingID tokenbindingid; 236 opaque signature<0..2^16-1>; /* Signature over the concatenation 237 of tokenbinding_type, 238 key_parameters and exported 239 keying material (EKM) */ 240 Extension extensions<0..2^16-1>; 241 } TokenBinding; 243 struct { 244 TokenBinding tokenbindings<0..2^16-1>; 245 } TokenBindingMessage; 247 The Token Binding message consists of a series of TokenBinding 248 structures, each containing the type of the token binding, the 249 TokenBindingID, a signature using the Token Binding key, optionally 250 followed by Extension structures. 252 3.1. TokenBinding.tokenbinding_type 254 This document defines two Token Binding types: 256 o provided_token_binding - used to establish a Token Binding when 257 connecting to a server. 259 o referred_token_binding - used when requesting tokens to be 260 presented to a different server. 262 Token Binding over HTTP [I-D.ietf-tokbind-https] describes a use case 263 for referred_token_binding where Token Bindings are established 264 between multiple communicating parties: User Agent, Identity Provider 265 and Relying Party. User Agent sends referred_token_binding to the 266 Identity Provider in order to prove possession of the Token Binding 267 key it uses with the Relying Party. The Identity Provider can then 268 bind the token it is supplying (for presentation to the Relying 269 Party) to the Token Binding ID contained in the 270 referred_token_binding. Such a bound token enjoys the protections 271 discussed below in Section 7 "Security Considerations". 273 3.2. TokenBinding.tokenbindingid 275 The ID of the Token Binding established as a result of Token Binding 276 message processing contains the identifier of the key parameters 277 negotiated via [I-D.ietf-tokbind-negotiation], the length (in bytes) 278 of the Token Binding public key, and the Token Binding public key 279 itself. Token Binding ID can be obtained from the TokenBinding 280 structure by discarding the Token Binding type, signature and 281 extensions. 283 When rsa2048_pkcs1.5 or rsa2048_pss is used, RSAPublicKey.modulus and 284 RSAPublicKey.publicexponent contain the modulus and exponent of a 285 2048-bit RSA public key represented in big-endian format, with 286 leading zero bytes omitted. 288 When ecdsap256 is used, ECPoint.point contains the X coordinate 289 followed by the Y coordinate of a Curve P-256 key. The X and Y 290 coordinates are unsigned 32-byte integers encoded in big-endian 291 format, preserving any leading zero bytes. Future specifications may 292 define Token Binding keys using other elliptic curves with their 293 corresponding signature and point formats. 295 Token Binding protocol implementations SHOULD make Token Binding IDs 296 available to the application as opaque byte sequences. E.g., server 297 applications will use Token Binding IDs when generating and verifying 298 bound tokens. 300 3.3. TokenBinding.signature 302 When rsa2048_pkcs1.5 is used, TokenBinding.signature contains the 303 signature generated using the RSASSA-PKCS1-v1_5 signature scheme 304 defined in [RFC3447] with SHA256 as the hash function. 306 When rsa2048_pss is used, TokenBinding.signature contains the 307 signature generated using the RSASSA-PSS signature scheme defined in 308 [RFC3447] with SHA256 as the hash function. MGF1 with SHA256 MUST be 309 used as the mask generation function, and the salt length MUST equal 310 32 bytes. 312 When ecdsap256 is used, TokenBinding.signature contains a pair of 313 32-byte integers, R followed by S, generated with ECDSA using Curve 314 P-256 and SHA256 as defined in [ANSI.X9-62.2005] and 315 [FIPS.186-4.2013]. R and S are encoded in big-endian format, 316 preserving any leading zero bytes. 318 The signature is computed over the byte string representing the 319 concatenation of: 321 o TokenBindingType value contained in the 322 TokenBinding.tokenbinding_type field; 324 o TokenBindingKeyParameters value contained in the 325 TokenBindingID.key_parameters field; 327 o Exported keying material (EKM) value obtained from the current TLS 328 connection. 330 Please note that TLS 1.2 and earlier versions support renegotiation, 331 which produces a new TLS master secret for the same connection, with 332 associated session keys and EKM value. TokenBinding.signature MUST 333 be a signature of the EKM value derived from the TLS master secret 334 that produced the session keys encrypting the TLS application_data 335 record(s) containing this TokenBinding. Such use of the current EKM 336 for the TLS connection makes replay of bound tokens within 337 renegotiated TLS sessions detectable, but requires the application to 338 synchronize Token Binding message generation and verification with 339 the TLS handshake state. 341 Specifications defining the use of Token Binding with application 342 protocols, such as Token Binding over HTTP [I-D.ietf-tokbind-https], 343 MAY prohibit the use of TLS renegotiation in combination with Token 344 Binding, obviating the need for such synchronization. Alternatively, 345 such specifications need to define a way to determine which EKM value 346 corresponds to a given TokenBindingMessage, and a mechanism 347 preventing a TokenBindingMessage from being split across TLS 348 renegotiation boundaries (i.e., due to TLS message fragmentation - 349 see Section 6.2.1 of [RFC5246]). Note that application layer 350 messages conveying a TokenBindingMessage may cross renegotiation 351 boundaries in ways that make processing difficult. 353 The EKM is obtained using the Keying Material Exporters for TLS 354 defined in [RFC5705], by supplying the following input values: 356 o Label: The ASCII string "EXPORTER-Token-Binding" with no 357 terminating NUL. 359 o Context value: NULL (no application context supplied). 361 o Length: 32 bytes, for the signature schemes defined in this 362 document. Other signature schemes may require a longer exporter 363 output. 365 3.4. TokenBinding.extensions 367 A Token Binding message may optionally contain a series of Extension 368 structures, each consisting of an extension_type and extension_data. 369 The structure and meaning of extension_data depends on the specific 370 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 383 4.1. Client Processing Rules 385 The client MUST include at least one TokenBinding structure in the 386 Token Binding message. The key parameters used in the 387 provided_token_binding MUST match those negotiated with the server 388 via [I-D.ietf-tokbind-negotiation]. 390 The client SHOULD generate and store Token Binding keys in a secure 391 manner that prevents key export. In order to prevent cooperating 392 servers from linking user identities, different keys SHOULD be used 393 by the client for connections to different servers, according to the 394 token scoping rules of the application protocol. 396 When the client needs to send a referred_token_binding to the 397 Identity Provider, the client SHALL construct the referred 398 TokenBinding structure in the following manner: 400 o Set TokenBinding.tokenbinding_type to referred_token_binding. 402 o Set TokenBinding.tokenbindingid to the Token Binding ID used with 403 the Relying Party. 405 o Generate TokenBinding.signature, using the EKM value of the TLS 406 connection to the Identity Provider, the Token Binding key 407 established with the Relying Party and the signature algorithm 408 indicated by the associated key parameters. Note that these key 409 parameters may differ from the key parameters negotiated with the 410 Identity Provider. 412 Conveying referred Token Bindings in this fashion allows the Identity 413 Provider to verify that the client controls the Token Binding key 414 used with the Relying Party. 416 4.2. Server Processing Rules 418 The triple handshake vulnerability in TLS 1.2 and older TLS versions 419 affects the security of the Token Binding protocol, as described in 420 Section 7 "Security Considerations". Therefore, the server MUST NOT 421 negotiate the use of the Token Binding protocol with these TLS 422 versions, unless the server also negotiates the Extended Master 423 Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS 424 extensions. 426 If the use of the Token Binding protocol was not negotiated, but the 427 client sends the Token Binding message, the server MUST reject any 428 contained bindings. If the Token Binding type is 429 "provided_token_binding", the server MUST verify that the signature 430 algorithm (including elliptic curve in the case of ECDSA) and key 431 length in the Token Binding message match those negotiated via 432 [I-D.ietf-tokbind-negotiation]. In the case of a mismatch, the 433 server MUST reject the binding. Token Bindings of type 434 "referred_token_binding" may use different key parameters than those 435 negotiated with this client. 437 If the Token Binding message does not contain at least one 438 TokenBinding structure, or if a signature contained in any 439 TokenBinding structure is invalid, the server MUST reject the 440 binding. 442 Servers MUST ignore any unknown extensions. Initially, no extension 443 types are defined (see Section 6.3 444 "Token Binding Extensions Registry"). 446 If all checks defined above have passed successfully, the Token 447 Binding between this client and server is established. The Token 448 Binding ID(s) conveyed in the Token Binding Message can be provided 449 to the server-side application. The application may then use the 450 Token Binding IDs for bound security token creation and validation, 451 see Section 5. 453 If a Token Binding is rejected, any associated bound tokens MUST also 454 be rejected by the server. The effect of this is application- 455 specific, e.g. failing requests, a requirement for the client to re- 456 authenticate and present a different token, or connection 457 termination. 459 5. Bound Security Token Creation and Validation 461 Security tokens can be bound to the TLS layer either by embedding the 462 Token Binding ID in the token, or by maintaining a database mapping 463 tokens to Token Binding IDs. The specific method of generating bound 464 security tokens is application-defined and beyond the scope of this 465 document. Note that applicable security considerations are outlined 466 in Section 7. 468 Either or both clients and servers MAY create bound security tokens. 469 For example, HTTPS servers employing Token Binding for securing their 470 HTTP cookies will bind the cookies. In the case of a server- 471 initiated challenge-response protocol employing Token Binding and 472 TLS, the client can, for example, incorporate the Token Binding ID 473 within the signed object it returns, thus binding the object. 475 Upon receipt of a security token, the server attempts to retrieve 476 Token Binding ID information from the token and from the TLS 477 connection with the client. Application-provided policy determines 478 whether to honor non-bound (bearer) tokens. If the token is bound 479 and a Token Binding has not been established for the client 480 connection, the server MUST discard the token. If the Token Binding 481 ID for the token does not match the Token Binding ID established for 482 the client connection, the server MUST discard the token. 484 6. IANA Considerations 486 This section establishes three IANA registries: "Token Binding Key 487 Parameters", "Token Binding Types" and "Token Binding Extensions". 488 It also 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 [RFC5226]. 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 Value: 1 524 Description: rsa2048_pss 525 Specification: this document 527 Value: 2 529 Description: ecdsap256 531 Specification: this document 533 6.2. Token Binding Types Registry 535 This document establishes a registry for Token Binding type 536 identifiers entitled "Token Binding Types" under the "Token Binding 537 Protocol" heading. 539 Entries in this registry require the following fields: 541 o Value: The octet value that identifies the Token Binding type 542 (0-255). 544 o Description: The description of the Token Binding type. 546 o Specification: A reference to a specification that defines the 547 Token Binding type. 549 This registry operates under the "Expert Review" policy as defined in 550 [RFC5226]. The designated expert is advised to encourage the 551 inclusion of a reference to a permanent and readily available 552 specification that enables the creation of interoperable 553 implementations using the identified Token Binding type. 555 An initial set of registrations for this registry follows: 557 Value: 0 559 Description: provided_token_binding 561 Specification: this document 563 Value: 1 565 Description: referred_token_binding 567 Specification: this document 569 6.3. Token Binding Extensions Registry 571 This document establishes a registry for Token Binding extensions 572 entitled "Token Binding Extensions" under the "Token Binding 573 Protocol" heading. 575 Entries in this registry require the following fields: 577 o Value: The octet value that identifies the Token Binding extension 578 (0-255). 580 o Description: The description of the Token Binding extension. 582 o Specification: A reference to a specification that defines the 583 Token Binding extension. 585 This registry operates under the "Expert Review" policy as defined in 586 [RFC5226]. The designated expert is advised to encourage the 587 inclusion of a reference to a permanent and readily available 588 specification that enables the creation of interoperable 589 implementations using the identified Token Binding extension. This 590 document creates no initial registrations in the "Token Binding 591 Extensions" registry. 593 6.4. Registration of Token Binding TLS Exporter Label 595 This document adds a registration for the "EXPORTER-Token-Binding" 596 value in the TLS Exporter Label Registry to correspond to this 597 specification. 599 7. Security Considerations 601 7.1. Security Token Replay 603 The goal of the Token Binding protocol is to prevent attackers from 604 exporting and replaying security tokens, thereby impersonating 605 legitimate users and gaining access to protected resources. Bound 606 tokens can be replayed by the malware present in User Agents, which 607 may be undetectable by a server. However, in order to export bound 608 tokens to other machines and successfully replay them, attackers also 609 need to export corresponding Token Binding private keys. Token 610 Binding private keys are therefore high-value assets and SHOULD be 611 strongly protected, ideally by generating them in a hardware security 612 module that prevents key export. 614 The manner in which a token is bound to the TLS layer is application- 615 defined and beyond the scope of this document. However, the 616 resulting bound token needs to be integrity-protected, so that an 617 attacker cannot remove the binding or substitute a Token Binding ID 618 of their choice without detection. 620 7.2. Downgrade Attacks 622 The Token Binding protocol is only used when negotiated via 623 [I-D.ietf-tokbind-negotiation] within the TLS handshake. TLS 624 prevents active attackers from modifying the messages of the TLS 625 handshake, therefore it is not possible for the attacker to remove or 626 modify the Token Binding Negotiation TLS Extension used to negotiate 627 the Token Binding protocol and key parameters. The signature 628 algorithm and key length used in the TokenBinding of type 629 "provided_token_binding" MUST match the parameters negotiated via 630 [I-D.ietf-tokbind-negotiation]. 632 7.3. Privacy Considerations 634 The Token Binding protocol uses persistent, long-lived Token Binding 635 IDs. To protect privacy, Token Binding IDs are never transmitted in 636 clear text and can be reset by the user at any time, e.g. when 637 clearing browser cookies. Some applications offer a special privacy 638 mode where they don't store or use tokens supplied by the server, 639 e.g. "in private" browsing. When operating in this special privacy 640 mode, applications SHOULD use newly generated Token Binding keys and 641 delete them when exiting this mode, or else SHOULD NOT negotiate 642 Token Binding at all. 644 In order to prevent cooperating servers from linking user identities, 645 different keys MUST be used by the client for connections to 646 different servers, according to the token scoping rules of the 647 application protocol. 649 A server can use tokens and Token Binding IDs to track clients. 650 Client applications that automatically limit the lifetime or scope of 651 tokens to maintain user privacy SHOULD apply the same validity time 652 and scope limits to Token Binding keys. 654 7.4. Token Binding Key Sharing Between Applications 656 Existing systems provide a variety of platform-specific mechanisms 657 for certain applications to share tokens, e.g. to enable single sign- 658 on scenarios. For these scenarios to keep working with bound tokens, 659 the applications that are allowed to share tokens will need to also 660 share Token Binding keys. Care must be taken to restrict the sharing 661 of Token Binding keys to the same group(s) of applications that share 662 the same tokens. 664 7.5. Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions 666 The Token Binding protocol relies on the TLS Exporters [RFC5705] to 667 associate a TLS connection with a Token Binding. The triple 668 handshake attack [TRIPLE-HS] is a known vulnerability in TLS 1.2 and 669 older TLS versions, allowing the attacker to synchronize keying 670 material between TLS connections. The attacker can then successfully 671 replay bound tokens. For this reason, the Token Binding protocol 672 MUST NOT be negotiated with these TLS versions, unless the Extended 673 Master Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS 674 extensions have also been negotiated. 676 8. Acknowledgements 678 This document incorporates comments and suggestions offered by Eric 679 Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Anthony 680 Nadalin, Michael B. Jones, Bill Cox, Nick Harper, Brian Campbell, 681 and others. 683 9. References 685 9.1. Normative References 687 [ANSI.X9-62.2005] 688 American National Standards Institute, "Public Key 689 Cryptography for the Financial Services Industry, The 690 Elliptic Curve Digital Signature Algorithm (ECDSA)", 691 ANSI X9.62, 2005. 693 [FIPS.186-4.2013] 694 National Institute of Standards and Technology, "Digital 695 Signature Standard (DSS)", FIPS 186-4, 2013. 697 [I-D.ietf-tokbind-https] 698 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 699 Hodges, "Token Binding over HTTP", draft-ietf-tokbind- 700 https-07 (work in progress), November 2016. 702 [I-D.ietf-tokbind-negotiation] 703 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 704 "Transport Layer Security (TLS) Extension for Token 705 Binding Protocol Negotiation", draft-ietf-tokbind- 706 negotiation-06 (work in progress), November 2016. 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, 710 DOI 10.17487/RFC2119, March 1997, 711 . 713 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 714 Standards (PKCS) #1: RSA Cryptography Specifications 715 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 716 2003, . 718 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 719 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 720 DOI 10.17487/RFC5226, May 2008, 721 . 723 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 724 (TLS) Protocol Version 1.2", RFC 5246, 725 DOI 10.17487/RFC5246, August 2008, 726 . 728 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 729 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 730 March 2010, . 732 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 733 "Transport Layer Security (TLS) Renegotiation Indication 734 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 735 . 737 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 738 Protocol (HTTP/1.1): Message Syntax and Routing", 739 RFC 7230, DOI 10.17487/RFC7230, June 2014, 740 . 742 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 743 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 744 DOI 10.17487/RFC7540, May 2015, 745 . 747 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 748 Langley, A., and M. Ray, "Transport Layer Security (TLS) 749 Session Hash and Extended Master Secret Extension", 750 RFC 7627, DOI 10.17487/RFC7627, September 2015, 751 . 753 9.2. Informative References 755 [TRIPLE-HS] 756 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 757 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 758 Breaking and Fixing Authentication over TLS. IEEE 759 Symposium on Security and Privacy", 2014. 761 Authors' Addresses 763 Andrei Popov (editor) 764 Microsoft Corp. 765 USA 767 Email: andreipo@microsoft.com 769 Magnus Nystroem 770 Microsoft Corp. 771 USA 773 Email: mnystrom@microsoft.com 775 Dirk Balfanz 776 Google Inc. 777 USA 779 Email: balfanz@google.com 781 Adam Langley 782 Google Inc. 783 USA 785 Email: agl@google.com 787 Jeff Hodges 788 Paypal 789 USA 791 Email: Jeff.Hodges@paypal.com