idnits 2.17.1 draft-ietf-tokbind-protocol-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([RFC5246]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 14, 2015) is 3119 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-tokbind-https-01 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-00 ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Popov, Ed. 3 Internet-Draft M. Nystroem 4 Intended status: Standards Track Microsoft Corp. 5 Expires: March 17, 2016 D. Balfanz 6 A. Langley 7 Google Inc. 8 September 14, 2015 10 The Token Binding Protocol Version 1.0 11 draft-ietf-tokbind-protocol-02 13 Abstract 15 This document specifies Version 1.0 of the Token Binding protocol. 16 The Token Binding protocol allows client/server applications to 17 create long-lived, uniquely identifiable TLS [RFC5246] bindings 18 spanning multiple TLS sessions and connections. Applications are 19 then enabled to cryptographically bind security tokens to the TLS 20 layer, preventing token export and replay attacks. To protect 21 privacy, the TLS Token Binding identifiers are only transmitted 22 encrypted and can be reset by the user at any time. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 17, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Token Binding Protocol Overview . . . . . . . . . . . . . . . 3 61 3. Token Binding Protocol Message . . . . . . . . . . . . . . . 4 62 4. Establishing a TLS Token Binding . . . . . . . . . . . . . . 6 63 5. TLS Token Binding ID Format . . . . . . . . . . . . . . . . . 7 64 6. Security Token Validation . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8.1. Security Token Replay . . . . . . . . . . . . . . . . . . 9 68 8.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 9 69 8.3. Privacy Considerations . . . . . . . . . . . . . . . . . 10 70 8.4. Token Binding Key Sharing Between Applications . . . . . 10 71 8.5. Triple Handshake Vulnerability in TLS . . . . . . . . . . 10 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 10.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 Web services generate various security tokens (e.g. HTTP cookies, 81 OAuth tokens) for web applications to access protected resources. 82 Any party in possession of such token gains access to the protected 83 resource. Attackers export bearer tokens from the user's machine, 84 present them to web services, and impersonate authenticated users. 85 The idea of Token Binding is to prevent such attacks by 86 cryptographically binding security tokens to the TLS layer. 88 A TLS Token Binding is established by the user agent generating a 89 private-public key pair (possibly within a secure hardware module, 90 such as TPM) per target server, and proving possession of the private 91 key on every TLS connection to the target server. The proof of 92 possession involves signing the exported keying material [RFC5705] 93 for the TLS connection with the private key. Such TLS Token Binding 94 is identified by the corresponding public key. TLS Token Bindings 95 are long-lived, i.e. they encompass multiple TLS connections and TLS 96 sessions between a given client and server. To protect privacy, TLS 97 Token Binding identifiers are never transmitted in clear text and can 98 be reset by the user at any time, e.g. when clearing browser cookies. 100 When issuing a security token to a client that supports TLS Token 101 Binding, a server includes the client's TLS Token Binding ID in the 102 token. Later on, when a client presents a security token containing 103 a TLS Token Binding ID, the server makes sure the ID in the token 104 matches the ID of the TLS Token Binding established with the client. 105 In the case of a mismatch, the server discards the token. 107 In order to successfully export and replay a bound security token, 108 the attacker needs to also be able to export the client's private 109 key, which is hard to do in the case of the key generated in a secure 110 hardware module. 112 1.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 2. Token Binding Protocol Overview 120 The client and server use the Token Binding Negotiation TLS Extension 121 [I-D.ietf-tokbind-negotiation] to negotiate the Token Binding 122 protocol version and the parameters (signature algorithm, length) of 123 the Token Binding key. This negotiation does not require additional 124 round-trips. 126 The Token Binding protocol consists of one message sent by the client 127 to the server, proving possession of one or more client-generated 128 asymmetric keys. This message is only sent if the client and server 129 agree on the use of the Token Binding protocol and the key 130 parameters. The Token Binding message is sent with the application 131 protocol data in TLS application_data records. 133 A server receiving the Token Binding message verifies that the key 134 parameters in the message match the Token Binding parameters 135 negotiated via [I-D.ietf-tokbind-negotiation], and then validates the 136 signatures contained in the Token Binding message. If either of 137 these checks fails, the server terminates the connection, otherwise 138 the TLS Token Binding is successfully established with the ID 139 contained in the Token Binding message. 141 When a server supporting the Token Binding protocol receives a bound 142 token, the server compares the TLS Token Binding ID in the security 143 token with the TLS Token Binding ID established with the client. If 144 the bound token came from a TLS connection without a Token Binding, 145 or if the IDs don't match, the token is discarded. 147 This document defines the format of the Token Binding protocol 148 message, the process of establishing a TLS Token Binding, the format 149 of the Token Binding ID, and the process of validating a security 150 token. Token Binding Negotiation TLS Extension 151 [I-D.ietf-tokbind-negotiation] describes the negotiation of the Token 152 Binding protocol and key parameters. Token Binding over HTTP 153 [I-D.ietf-tokbind-https] explains how the Token Binding message is 154 encapsulated within HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] messages. 155 [I-D.ietf-tokbind-https] also describes Token Binding between 156 multiple communicating parties: User Agent, Identity Provider and 157 Relying Party. 159 3. Token Binding Protocol Message 161 The Token Binding message is sent by the client and proves possession 162 of one or more private keys held by the client. This message MUST be 163 sent if the client and server successfully negotiated the use of the 164 Token Binding protocol via [I-D.ietf-tokbind-negotiation], and MUST 165 NOT be sent otherwise. This message MUST be sent in the client's 166 first application protocol message. This message MAY also be sent in 167 subsequent application protocol messages, proving possession of other 168 keys by the same client, to facilitate token binding between more 169 than two communicating parties. Token Binding over HTTP 170 [I-D.ietf-tokbind-https] specifies the encapsulation of the Token 171 Binding message in the application protocol messages, and the 172 scenarios involving more than two communicating parties. The Token 173 Binding message format is defined using TLS specification language, 174 and reuses existing TLS structures and IANA registrations where 175 possible: 177 enum { 178 rsa2048_pkcs1.5_sha256(0), rsa2048_pss_sha256(1), ecdsap256_sha256(2), (255) 179 } TokenBindingKeyParameters; 181 struct { 182 opaque modulus<1..2^16-1>; 183 opaque publicexponent<1..2^8-1>; 184 } RSAPublicKey; 186 enum { 187 secp256r1 (23), (0xFFFF) 188 } NamedCurve; 190 struct { 191 opaque point <1..2^8-1>; 192 } ECPoint; 194 struct { 195 NamedCurve namedcurve; 196 ECPoint point; // Uncompressed format 197 } ECDSAParams; 199 enum { 200 provided_token_binding(0), referred_token_binding(1), (255) 201 } TokenBindingType; 203 struct { 204 TokenBindingType tokenbinding_type; 205 TokenBindingKeyParameters key_parameters; 206 select (key_parameters) { 207 case rsa2048_pkcs1.5_sha256: 208 case rsa2048_pss_sha256: 209 RSAPublicKey rsapubkey; 210 case ecdsap256_sha256: 211 ECDSAParams ecdsaparams; 212 } 213 } TokenBindingID; 215 enum { 216 (255) // No initial ExtensionType registrations 217 } ExtensionType; 219 struct { 220 ExtensionType extension_type; 221 opaque extension_data<0..2^16-1>; 222 } Extension; 224 struct { 225 TokenBindingID tokenbindingid; 226 opaque signature<0..2^16-1>;// Signature over the exported keying material value 227 Extension extensions<0..2^16-1>; 228 } TokenBinding; 230 struct { 231 TokenBinding tokenbindings<0..2^16-1>; 232 } TokenBindingMessage; 234 The Token Binding message consists of a series of TokenBinding 235 structures containing the TokenBindingID, a signature over the 236 exported keying material (EKM) value, optionally followed by 237 Extension structures. 239 The EKM is obtained using the Keying Material Exporters for TLS 240 defined in [RFC5705], by supplying the following input values: 242 o Label: The ASCII string "EXPORTER-Token-Binding" with no 243 terminating NUL. 245 o Context value: NULL (no application context supplied). 247 o Length: 32 bytes. 249 An implementation MUST ignore any unknown extensions. Initially, no 250 extension types are defined. One of the possible uses of extensions 251 envisioned at the time of this writing is attestation: cryptographic 252 proof that allows the server to verify that the Token Binding key is 253 hardware-bound. The definitions of such Token Binding protocol 254 extensions are outside the scope of this specification. 256 At least one TokenBinding MUST be included in the Token Binding 257 message. The signature algorithm and key length used in the 258 TokenBinding MUST match the parameters negotiated via 259 [I-D.ietf-tokbind-negotiation]. The client SHOULD generate and store 260 Token Binding keys in a secure manner that prevents key export. In 261 order to prevent cooperating servers from linking user identities, 262 different keys SHOULD be used by the client for connections to 263 different servers, according to the token scoping rules of the 264 application protocol. 266 4. Establishing a TLS Token Binding 268 The triple handshake vulnerability in the TLS protocol affects the 269 security of the Token Binding protocol, as described in the "Security 270 Considerations" section below. Therefore, the server MUST NOT 271 negotiate the use of the Token Binding protocol unless the server 272 also negotiates Extended Master Secret TLS extension 273 [I-D.ietf-tls-session-hash]. 275 The server MUST terminate the connection if the use of the Token 276 Binding protocol was not negotiated, but the client sends the Token 277 Binding message. If the Token Binding type is 278 "provided_token_binding", the server MUST verify that the signature 279 algorithm (including elliptic curve in the case of ECDSA) and key 280 length in the Token Binding message match those negotiated via 281 [I-D.ietf-tokbind-negotiation]. In the case of a mismatch, the 282 server MUST terminate the connection. As described in 283 [I-D.ietf-tokbind-https], Token Bindings of type 284 "referred_token_binding" may have different key parameters than those 285 negotiated via [I-D.ietf-tokbind-negotiation]. 287 If the Token Binding message does not contain at least one 288 TokenBinding structure, or the signature contained in a TokenBinding 289 structure is invalid, the server MUST terminate the connection. 290 Otherwise, the TLS Token Binding is successfully established and its 291 ID can be provided to the application for security token validation. 293 5. TLS Token Binding ID Format 295 The ID of the TLS Token Binding established as a result of Token 296 Binding message processing is a binary representation of the 297 following structure: 299 struct { 300 TokenBindingType tokenbinding_type; 301 TokenBindingKeyParameters key_parameters; 302 select (key_parameters) { 303 case rsa2048_pkcs1.5_sha256: 304 case rsa2048_pss_sha256: 305 RSAPublicKey rsapubkey; 306 case ecdsap256_sha256: 307 ECDSAParams ecdsaparams; 308 } 309 } TokenBindingID; 311 TokenBindingID includes the type of the token binding and the key 312 parameters negotiated via [I-D.ietf-tokbind-negotiation]. This 313 document defines two token binding types: provided_token_binding used 314 to establish a Token Binding when connecting to a server, and 315 referred_token_binding used when requesting tokens to be presented to 316 a different server. Token Binding over HTTP [I-D.ietf-tokbind-https] 317 describes Token Binding between multiple communicating parties: User 318 Agent, Identity Provider and Relying Party. TLS Token Binding ID can 319 be obtained from the TokenBinding structure described in the "Token 320 Binding Protocol Message" section of this document by discarding the 321 signature and extensions. TLS Token Binding ID will be available at 322 the application layer and used by the server to generate and verify 323 bound tokens. 325 6. Security Token Validation 327 Security tokens can be bound to the TLS layer either by embedding the 328 Token Binding ID in the token, or by maintaining a database mapping 329 tokens to Token Binding IDs. The specific method of generating bound 330 security tokens is application-defined and beyond the scope of this 331 document. 333 Upon receipt of a security token, the server attempts to retrieve TLS 334 Token Binding ID information from the token and from the TLS 335 connection with the client. Application-provided policy determines 336 whether to honor non-bound (bearer) tokens. If the token is bound 337 and a TLS Token Binding has not been established for the client 338 connection, the server MUST discard the token. If the TLS Token 339 Binding ID for the token does not match the TLS Token Binding ID 340 established for the client connection, the server MUST discard the 341 token. 343 7. IANA Considerations 345 This document establishes a registry for Token Binding type 346 identifiers entitled "Token Binding Types" under the "Token Binding 347 Protocol" heading. 349 Entries in this registry require the following fields: 351 o Value: The octet value that identifies the Token Binding type 352 (0-255). 354 o Description: The description of the Token Binding type. 356 o Specification: A reference to a specification that defines the 357 Token Binding type. 359 This registry operates under the "Expert Review" policy as defined in 360 [RFC5226]. The designated expert is advised to encourage the 361 inclusion of a reference to a permanent and readily available 362 specification that enables the creation of interoperable 363 implementations using the identified Token Binding type. 365 An initial set of registrations for this registry follows: 367 Value: 0 369 Description: provided_token_binding 371 Specification: this document 373 Value: 1 375 Description: referred_token_binding 377 Specification: this document 379 This document establishes a registry for Token Binding extensions 380 entitled "Token Binding Extensions" under the "Token Binding 381 Protocol" heading. 383 Entries in this registry require the following fields: 385 o Value: The octet value that identifies the Token Binding extension 386 (0-255). 388 o Description: The description of the Token Binding extension. 390 o Specification: A reference to a specification that defines the 391 Token Binding extension. 393 This registry operates under the "Expert Review" policy as defined in 394 [RFC5226]. The designated expert is advised to encourage the 395 inclusion of a reference to a permanent and readily available 396 specification that enables the creation of interoperable 397 implementations using the identified Token Binding extension. This 398 document creates no initial registrations in the "Token Binding 399 Extensions" registry. 401 This document uses "Token Binding Key Parameters" registry originally 402 created in [I-D.ietf-tokbind-negotiation] and "TLS NamedCurve" 403 registry originally created in [RFC4492]. This document creates no 404 new registrations in these registries. 406 8. Security Considerations 408 8.1. Security Token Replay 410 The goal of the Token Binding protocol is to prevent attackers from 411 exporting and replaying security tokens, thereby impersonating 412 legitimate users and gaining access to protected resources. Bound 413 tokens can still be replayed by the malware present in the User 414 Agent. In order to export the token to another machine and 415 successfully replay it, the attacker also needs to export the 416 corresponding private key. Token Binding private keys are therefore 417 high-value assets and SHOULD be strongly protected, ideally by 418 generating them in a hardware security module that prevents key 419 export. 421 8.2. Downgrade Attacks 423 The Token Binding protocol is only used when negotiated via 424 [I-D.ietf-tokbind-negotiation] within the TLS handshake. TLS 425 prevents active attackers from modifying the messages of the TLS 426 handshake, therefore it is not possible for the attacker to remove or 427 modify the Token Binding Negotiation TLS Extension used to negotiate 428 the Token Binding protocol and key parameters. The signature 429 algorithm and key length used in the TokenBinding of type 430 "provided_token_binding" MUST match the parameters negotiated via 431 [I-D.ietf-tokbind-negotiation]. 433 8.3. Privacy Considerations 435 The Token Binding protocol uses persistent, long-lived TLS Token 436 Binding IDs. To protect privacy, TLS Token Binding IDs are never 437 transmitted in clear text and can be reset by the user at any time, 438 e.g. when clearing browser cookies. Some applications offer special 439 privacy modes where they don't store or use tokens supplied by the 440 server, e.g. "in private" browsing. Connections made in these 441 special privacy modes SHOULD NOT negotiate Token Binding. In order 442 to prevent cooperating servers from linking user identities, 443 different keys SHOULD be used by the client for connections to 444 different servers, according to the token scoping rules of the 445 application protocol. 447 8.4. Token Binding Key Sharing Between Applications 449 Existing systems provide a variety of platform-specific mechanisms 450 for certain applications to share tokens, e.g. to enable single sign- 451 on scenarios. For these scenarios to keep working with bound tokens, 452 the applications that are allowed to share tokens will need to also 453 share Token Binding keys. Care must be taken to restrict the sharing 454 of Token Binding keys to the same group(s) of applications that share 455 the same tokens. 457 8.5. Triple Handshake Vulnerability in TLS 459 The Token Binding protocol relies on the exported keying material 460 (EKM) to associate a TLS connection with a Token Binding. The triple 461 handshake attack [TRIPLE-HS] is a known TLS protocol vulnerability 462 allowing the attacker to synchronize keying material between TLS 463 connections. The attacker can then successfully replay bound tokens. 464 For this reason, the Token Binding protocol MUST NOT be negotiated 465 unless the Extended Master Secret TLS extension 466 [I-D.ietf-tls-session-hash] has also been negotiated. 468 9. Acknowledgements 470 This document incorporates comments and suggestions offered by Eric 471 Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Bill Cox, 472 Nick Harper and others. 474 10. References 476 10.1. Normative References 478 [I-D.ietf-tokbind-https] 479 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 480 "Token Binding over HTTP", draft-ietf-tokbind-https-01 481 (work in progress), June 2015. 483 [I-D.ietf-tokbind-negotiation] 484 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 485 "Transport Layer Security (TLS) Extension for Token 486 Binding Protocol Negotiation", draft-ietf-tokbind- 487 negotiation-00 (work in progress), September 2015. 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, 491 DOI 10.17487/RFC2119, March 1997, 492 . 494 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 495 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 496 for Transport Layer Security (TLS)", RFC 4492, 497 DOI 10.17487/RFC4492, May 2006, 498 . 500 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 501 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 502 DOI 10.17487/RFC5226, May 2008, 503 . 505 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 506 (TLS) Protocol Version 1.2", RFC 5246, 507 DOI 10.17487/RFC5246, August 2008, 508 . 510 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 511 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 512 March 2010, . 514 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 515 Protocol (HTTP/1.1): Message Syntax and Routing", 516 RFC 7230, DOI 10.17487/RFC7230, June 2014, 517 . 519 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 520 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 521 DOI 10.17487/RFC7540, May 2015, 522 . 524 10.2. Informative References 526 [I-D.ietf-tls-session-hash] 527 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 528 A., and M. Ray, "Transport Layer Security (TLS) Session 529 Hash and Extended Master Secret Extension", draft-ietf- 530 tls-session-hash-06 (work in progress), July 2015. 532 [TRIPLE-HS] 533 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 534 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 535 Breaking and Fixing Authentication over TLS. IEEE 536 Symposium on Security and Privacy", 2014. 538 Authors' Addresses 540 Andrei Popov (editor) 541 Microsoft Corp. 542 USA 544 Email: andreipo@microsoft.com 546 Magnus Nystroem 547 Microsoft Corp. 548 USA 550 Email: mnystrom@microsoft.com 552 Dirk Balfanz 553 Google Inc. 554 USA 556 Email: balfanz@google.com 558 Adam Langley 559 Google Inc. 560 USA 562 Email: agl@google.com