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