idnits 2.17.1 draft-ietf-tokbind-protocol-18.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 9, 2018) is 2178 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-14 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-12 ** 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 10, 2018 D. Balfanz 6 A. Langley 7 Google Inc. 8 J. Hodges 9 PayPal 10 May 9, 2018 12 The Token Binding Protocol Version 1.0 13 draft-ietf-tokbind-protocol-18 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 10, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Token Binding Protocol Overview . . . . . . . . . . . . . . . 3 63 3. Token Binding Protocol Message . . . . . . . . . . . . . . . 4 64 3.1. TokenBinding.tokenbinding_type . . . . . . . . . . . . . 6 65 3.2. TokenBinding.tokenbindingid . . . . . . . . . . . . . . . 6 66 3.3. TokenBinding.signature . . . . . . . . . . . . . . . . . 7 67 3.4. TokenBinding.extensions . . . . . . . . . . . . . . . . . 8 68 4. Establishing a Token Binding . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 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 172 came from 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 3.2. TokenBinding.tokenbindingid 285 The ID of the Token Binding established as a result of Token Binding 286 message processing contains the identifier of the negotiated key 287 parameters, the length (in bytes) of the Token Binding public key, 288 and the Token Binding public key itself. The Token Binding ID can be 289 obtained from the TokenBinding structure by discarding the Token 290 Binding type, signature and extensions. 292 When rsa2048_pkcs1.5 or rsa2048_pss is used, RSAPublicKey.modulus and 293 RSAPublicKey.publicexponent contain the modulus and exponent of a 294 2048-bit RSA public key represented in big-endian format, with 295 leading zero bytes omitted. 297 When ecdsap256 is used, TB_ECPoint.point contains the X coordinate 298 followed by the Y coordinate of a Curve P-256 key. The X and Y 299 coordinates are unsigned 32-byte integers encoded in big-endian 300 format, preserving any leading zero bytes. Future specifications may 301 define Token Binding keys using other elliptic curves with their 302 corresponding signature and point formats. 304 Token Binding protocol implementations SHOULD make Token Binding IDs 305 available to the application as opaque byte sequences, so that 306 applications do not rely on a particular Token Binding ID structure. 307 E.g., server applications will use Token Binding IDs when generating 308 and verifying bound tokens. 310 3.3. TokenBinding.signature 312 When rsa2048_pkcs1.5 is used, TokenBinding.signature contains the 313 signature generated using the RSASSA-PKCS1-v1_5 signature scheme 314 defined in [RFC8017] with SHA256 as the hash function. 316 When rsa2048_pss is used, TokenBinding.signature contains the 317 signature generated using the RSASSA-PSS signature scheme defined in 318 [RFC8017] with SHA256 as the hash function. MGF1 with SHA256 MUST be 319 used as the mask generation function, and the salt length MUST equal 320 32 bytes. 322 When ecdsap256 is used, TokenBinding.signature contains a pair of 323 32-byte integers, R followed by S, generated with ECDSA using Curve 324 P-256 and SHA256 as defined in [ANSI.X9-62.2005] and 325 [FIPS.186-4.2013]. R and S are encoded in big-endian format, 326 preserving any leading zero bytes. 328 The signature is computed over the byte string representing the 329 concatenation of: 331 o TokenBindingType value contained in the 332 TokenBinding.tokenbinding_type field; 334 o TokenBindingKeyParameters value contained in the 335 TokenBindingID.key_parameters field; 337 o Exported keying material (EKM) value obtained from the current TLS 338 connection. 340 Please note that TLS 1.2 and earlier versions support renegotiation, 341 which produces a new TLS master secret for the same connection, with 342 associated session keys and EKM value. TokenBinding.signature MUST 343 be a signature of the EKM value derived from the TLS master secret 344 that produced the session keys encrypting the TLS application_data 345 record(s) containing this TokenBinding. Such use of the current EKM 346 for the TLS connection makes replay of bound tokens within 347 renegotiated TLS sessions detectable, but requires the application to 348 synchronize Token Binding message generation and verification with 349 the TLS handshake state. 351 Specifications defining the use of Token Binding with application 352 protocols, such as Token Binding over HTTP [I-D.ietf-tokbind-https], 353 MAY prohibit the use of TLS renegotiation in combination with Token 354 Binding, obviating the need for such synchronization. Alternatively, 355 such specifications need to define a way to determine which EKM value 356 corresponds to a given TokenBindingMessage, and a mechanism 357 preventing a TokenBindingMessage from being split across TLS 358 renegotiation boundaries (i.e., due to TLS message fragmentation - 359 see Section 6.2.1 of [RFC5246]). Note that application layer 360 messages conveying a TokenBindingMessage may cross renegotiation 361 boundaries in ways that make processing difficult. 363 The EKM is obtained using the Keying Material Exporters for TLS 364 defined in [RFC5705], by supplying the following input values: 366 o Label: The ASCII string "EXPORTER-Token-Binding" with no 367 terminating NUL. 369 o Context value: No application context supplied. 371 o Length: 32 bytes. 373 3.4. TokenBinding.extensions 375 A Token Binding message may optionally contain a series of 376 TB_Extension structures, each consisting of an extension_type and 377 extension_data. The structure and meaning of extension_data depends 378 on the specific extension_type. 380 Initially, no extension types are defined (see Section 6.3 381 "Token Binding Extensions Registry"). One of the possible uses of 382 extensions envisioned at the time of this writing is attestation: 383 cryptographic proof that allows the server to verify that the Token 384 Binding key is hardware-bound. The definitions of such Token Binding 385 protocol extensions are outside the scope of this specification. 387 An implementation MUST ignore any unknown Token Binding types. 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 the 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. If the Token Binding type is 437 "provided_token_binding", the server MUST verify that the signature 438 algorithm (including elliptic curve in the case of ECDSA) and key 439 length in the Token Binding message match those negotiated with this 440 client (e.g., via [I-D.ietf-tokbind-negotiation] or a different 441 mechanism). In the case of a mismatch, the server MUST reject the 442 binding. Token Bindings of type "referred_token_binding" may use 443 different key parameters than those negotiated with this client. 445 If the Token Binding message does not contain at least one 446 TokenBinding structure, or if a signature contained in any 447 TokenBinding structure is invalid, the server MUST reject the 448 binding. 450 Servers MUST ignore any unknown extensions. Initially, no extension 451 types are defined (see Section 6.3 452 "Token Binding Extensions Registry"). 454 If all checks defined above have passed successfully, the Token 455 Binding between this client and server is established. The Token 456 Binding ID(s) conveyed in the Token Binding Message can be provided 457 to the server-side application. The application may then use the 458 Token Binding IDs for bound security token creation and validation, 459 see Section 5. 461 If a Token Binding is rejected, any associated bound tokens MUST also 462 be rejected by the server. The effect of this is application- 463 specific, e.g., failing requests, a requirement for the client to re- 464 authenticate and present a different token, or connection 465 termination. 467 5. Bound Security Token Creation and Validation 469 Security tokens can be bound to the TLS layer in a variety of ways: 470 by embedding the Token Binding ID or its cryptographic hash in the 471 token, or by maintaining a database mapping tokens to Token Binding 472 IDs. The specific method of generating bound security tokens is 473 application-defined and beyond the scope of this document. Note that 474 applicable security considerations are outlined in Section 7. 476 Either or both clients and servers MAY create bound security tokens. 477 For example, HTTPS servers employing Token Binding for securing their 478 HTTP cookies will bind these cookies. In the case of a server- 479 initiated challenge-response protocol employing Token Binding and 480 TLS, the client can, for example, incorporate the Token Binding ID 481 within the signed object it returns, thus binding the object. 483 Upon receipt of a security token, the server attempts to retrieve 484 Token Binding ID information from the token and from the TLS 485 connection with the client. Application-provided policy determines 486 whether to honor non-bound (bearer) tokens. If the token is bound 487 and a Token Binding has not been established for the client 488 connection, the server MUST reject the token. If the Token Binding 489 ID for the token does not match the Token Binding ID established for 490 the client connection, the server MUST reject the token. 492 6. IANA Considerations 494 This section establishes three IANA registries on a new registry page 495 entitled "Token Binding Protocol": "Token Binding Key Parameters", 496 "Token Binding Types" and "Token Binding Extensions". It also 497 registers a new TLS exporter label in the TLS Exporter Label 498 Registry. 500 6.1. Token Binding Key Parameters Registry 502 This document establishes a registry for identifiers of Token Binding 503 key parameters entitled "Token Binding Key Parameters" under the 504 "Token Binding Protocol" heading. 506 Entries in this registry require the following fields: 508 o Value: The octet value that identifies a set of Token Binding key 509 parameters (0-255). 511 o Description: The description of the Token Binding key parameters. 513 o Specification: A reference to a specification that defines the 514 Token Binding key parameters. 516 This registry operates under the "Expert Review" policy as defined in 517 [RFC8126]. The designated expert will require the inclusion of a 518 reference to a permanent and readily available specification that 519 enables the creation of interoperable implementations using the 520 identified set of Token Binding key parameters. 522 An initial set of registrations for this registry follows: 524 Value: 0 526 Description: rsa2048_pkcs1.5 527 Specification: this document 529 --------------------------------- 531 Value: 1 533 Description: rsa2048_pss 535 Specification: this document 537 --------------------------------- 539 Value: 2 541 Description: ecdsap256 543 Specification: this document 545 6.2. Token Binding Types Registry 547 This document establishes a registry for Token Binding type 548 identifiers entitled "Token Binding Types" under the "Token Binding 549 Protocol" heading. 551 Entries in this registry require the following fields: 553 o Value: The octet value that identifies the Token Binding type 554 (0-255). 556 o Description: The description of the Token Binding type. 558 o Specification: A reference to a specification that defines the 559 Token Binding type. 561 This registry operates under the "Expert Review" policy as defined in 562 [RFC8126]. The designated expert will require the inclusion of a 563 reference to a permanent and readily available specification that 564 enables the creation of interoperable implementations using the 565 identified Token Binding type. 567 An initial set of registrations for this registry follows: 569 Value: 0 571 Description: provided_token_binding 573 Specification: this document 574 --------------------------------- 576 Value: 1 578 Description: referred_token_binding 580 Specification: this document 582 6.3. Token Binding Extensions Registry 584 This document establishes a registry for Token Binding extensions 585 entitled "Token Binding Extensions" under the "Token Binding 586 Protocol" heading. 588 Entries in this registry require the following fields: 590 o Value: The octet value that identifies the Token Binding extension 591 (0-255). 593 o Description: The description of the Token Binding extension. 595 o Specification: A reference to a specification that defines the 596 Token Binding extension. 598 This registry operates under the "Expert Review" policy as defined in 599 [RFC8126]. The designated expert will require the inclusion of a 600 reference to a permanent and readily available specification that 601 enables the creation of interoperable implementations using the 602 identified Token Binding extension. This document creates no initial 603 registrations in the "Token Binding Extensions" registry. 605 6.4. Registration of Token Binding TLS Exporter Label 607 This document adds the following registration in the TLS Exporter 608 Label Registry: 610 Value: EXPORTER-Token-Binding 612 DTLS-OK: Y 614 Reference: this document 616 7. Security Considerations 617 7.1. Security Token Replay 619 The goal of the Token Binding protocol is to prevent attackers from 620 exporting and replaying security tokens, thereby impersonating 621 legitimate users and gaining access to protected resources. Bound 622 tokens can be replayed by malware present in User Agents, which may 623 be undetectable by a server. However, in order to export bound 624 tokens to other machines and successfully replay them, attackers also 625 need to export corresponding Token Binding private keys. Token 626 Binding private keys are therefore high-value assets and SHOULD be 627 strongly protected, ideally by generating them in a hardware security 628 module that prevents key export. 630 The manner in which a token is bound to the TLS layer is application- 631 defined and beyond the scope of this document. However, the 632 resulting bound token needs to be integrity-protected, so that an 633 attacker cannot remove the binding or substitute a Token Binding ID 634 of their choice without detection. 636 The Token Binding protocol does not prevent cooperating clients from 637 sharing a bound token. A client could intentionally export a bound 638 token with the corresponding Token Binding private key, or perform 639 signatures using this key on behalf of another client. 641 7.2. Downgrade Attacks 643 The Token Binding protocol MUST be negotiated using a mechanism that 644 prevents downgrade. E.g., [I-D.ietf-tokbind-negotiation] uses a TLS 645 extension for Token Binding negotiation. TLS prevents active 646 attackers from modifying the messages of the TLS handshake, therefore 647 it is not possible for the attacker to remove or modify the Token 648 Binding Negotiation TLS Extension. The signature algorithm and key 649 length used in the TokenBinding of type "provided_token_binding" MUST 650 match the negotiated parameters. 652 7.3. Privacy Considerations 654 The Token Binding protocol uses persistent, long-lived Token Binding 655 IDs. To protect privacy, Token Binding IDs are never transmitted in 656 clear text and can be reset by the user at any time, e.g. when 657 clearing browser cookies. Some applications offer a special privacy 658 mode where they don't store or use tokens supplied by the server, 659 e.g., "in private" browsing. When operating in this special privacy 660 mode, applications SHOULD use newly generated Token Binding keys and 661 delete them when exiting this mode, or else SHOULD NOT negotiate 662 Token Binding at all. 664 In order to prevent cooperating servers from linking user identities, 665 the scope of the Token Binding keys MUST NOT be broader than the 666 scope of the tokens, as defined by the application protocol. 668 A server can use tokens and Token Binding IDs to track clients. 669 Client applications that automatically limit the lifetime or scope of 670 tokens to maintain user privacy SHOULD apply the same validity time 671 and scope limits to Token Binding keys. 673 7.4. Token Binding Key Sharing Between Applications 675 Existing systems provide a variety of platform-specific mechanisms 676 for certain applications to share tokens, e.g. to enable single sign- 677 on scenarios. For these scenarios to keep working with bound tokens, 678 the applications that are allowed to share tokens will need to also 679 share Token Binding keys. Care must be taken to restrict the sharing 680 of Token Binding keys to the same group(s) of applications that share 681 the same tokens. 683 7.5. Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions 685 The Token Binding protocol relies on the TLS Exporters [RFC5705] to 686 associate a TLS connection with a Token Binding. The triple 687 handshake attack [TRIPLE-HS] is a known vulnerability in TLS 1.2 and 688 older TLS versions, allowing the attacker to synchronize keying 689 material between TLS connections. The attacker can then successfully 690 replay bound tokens. For this reason, the Token Binding protocol 691 MUST NOT be negotiated with these TLS versions, unless the Extended 692 Master Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS 693 extensions have also been negotiated. 695 8. Acknowledgements 697 This document incorporates comments and suggestions offered by Eric 698 Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Anthony 699 Nadalin, Michael B. Jones, Bill Cox, Nick Harper, Brian Campbell, 700 and others. 702 This document was produced under the chairmanship of John Bradley and 703 Leif Johansson. The area directors included Eric Rescorla, Kathleen 704 Moriarty and Stephen Farrell. 706 9. References 707 9.1. Normative References 709 [ANSI.X9-62.2005] 710 American National Standards Institute, "Public Key 711 Cryptography for the Financial Services Industry, The 712 Elliptic Curve Digital Signature Algorithm (ECDSA)", 713 ANSI X9.62, 2005. 715 [FIPS.186-4.2013] 716 National Institute of Standards and Technology, "Digital 717 Signature Standard (DSS)", FIPS 186-4, 2013. 719 [I-D.ietf-tokbind-https] 720 Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 721 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 722 tokbind-https-14 (work in progress), May 2018. 724 [I-D.ietf-tokbind-negotiation] 725 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 726 "Transport Layer Security (TLS) Extension for Token 727 Binding Protocol Negotiation", draft-ietf-tokbind- 728 negotiation-12 (work in progress), May 2018. 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, 732 DOI 10.17487/RFC2119, March 1997, 733 . 735 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 736 (TLS) Protocol Version 1.2", RFC 5246, 737 DOI 10.17487/RFC5246, August 2008, 738 . 740 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 741 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 742 March 2010, . 744 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 745 "Transport Layer Security (TLS) Renegotiation Indication 746 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 747 . 749 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 750 Protocol (HTTP/1.1): Message Syntax and Routing", 751 RFC 7230, DOI 10.17487/RFC7230, June 2014, 752 . 754 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 755 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 756 DOI 10.17487/RFC7540, May 2015, 757 . 759 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 760 Langley, A., and M. Ray, "Transport Layer Security (TLS) 761 Session Hash and Extended Master Secret Extension", 762 RFC 7627, DOI 10.17487/RFC7627, September 2015, 763 . 765 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 766 Writing an IANA Considerations Section in RFCs", BCP 26, 767 RFC 8126, DOI 10.17487/RFC8126, June 2017, 768 . 770 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 771 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 772 May 2017, . 774 9.2. Informative References 776 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 777 RFC 6749, DOI 10.17487/RFC6749, October 2012, 778 . 780 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 781 "PKCS #1: RSA Cryptography Specifications Version 2.2", 782 RFC 8017, DOI 10.17487/RFC8017, November 2016, 783 . 785 [TRIPLE-HS] 786 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 787 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 788 Breaking and Fixing Authentication over TLS. IEEE 789 Symposium on Security and Privacy", 2014. 791 Authors' Addresses 793 Andrei Popov (editor) 794 Microsoft Corp. 795 USA 797 Email: andreipo@microsoft.com 798 Magnus Nystroem 799 Microsoft Corp. 800 USA 802 Email: mnystrom@microsoft.com 804 Dirk Balfanz 805 Google Inc. 806 USA 808 Email: balfanz@google.com 810 Adam Langley 811 Google Inc. 812 USA 814 Email: agl@google.com 816 Jeff Hodges 817 PayPal 818 USA 820 Email: Jeff.Hodges@paypal.com