idnits 2.17.1 draft-ietf-tokbind-protocol-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 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 (October 6, 2015) is 3125 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) == Unused Reference: 'RFC4492' is defined on line 481, but no explicit reference was found in the text == 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 (~~), 4 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: April 8, 2016 D. Balfanz 6 A. Langley 7 Google Inc. 8 October 6, 2015 10 The Token Binding Protocol Version 1.0 11 draft-ietf-tokbind-protocol-03 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 April 8, 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 . . . . . . . . . . . . . . . . . . 8 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8.1. Security Token Replay . . . . . . . . . . . . . . . . . . 9 68 8.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 11 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 where possible: 176 enum { 177 rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255) 178 } TokenBindingKeyParameters; 180 struct { 181 opaque modulus<1..2^16-1>; 182 opaque publicexponent<1..2^8-1>; 183 } RSAPublicKey; 185 struct { 186 opaque point <1..2^8-1>; 187 } ECPoint; 189 enum { 190 provided_token_binding(0), referred_token_binding(1), (255) 191 } TokenBindingType; 193 struct { 194 TokenBindingType tokenbinding_type; 195 TokenBindingKeyParameters key_parameters; 196 select (key_parameters) { 197 case rsa2048_pkcs1.5: 198 case rsa2048_pss: 199 RSAPublicKey rsapubkey; 200 case ecdsap256: 201 ECPoint point; 202 } 203 } TokenBindingID; 205 enum { 206 (255) // No initial ExtensionType registrations 207 } ExtensionType; 209 struct { 210 ExtensionType extension_type; 211 opaque extension_data<0..2^16-1>; 212 } Extension; 214 struct { 215 TokenBindingID tokenbindingid; 216 opaque signature<0..2^16-1>;// Signature over the exported keying material value 217 Extension extensions<0..2^16-1>; 218 } TokenBinding; 220 struct { 221 TokenBinding tokenbindings<0..2^16-1>; 222 } TokenBindingMessage; 223 The Token Binding message consists of a series of TokenBinding 224 structures containing the TokenBindingID, a signature over the 225 exported keying material (EKM) value, optionally followed by 226 Extension structures. 228 The EKM is obtained using the Keying Material Exporters for TLS 229 defined in [RFC5705], by supplying the following input values: 231 o Label: The ASCII string "EXPORTER-Token-Binding" with no 232 terminating NUL. 234 o Context value: NULL (no application context supplied). 236 o Length: 32 bytes. 238 An implementation MUST ignore any unknown extensions. Initially, no 239 extension types are defined. One of the possible uses of extensions 240 envisioned at the time of this writing is attestation: cryptographic 241 proof that allows the server to verify that the Token Binding key is 242 hardware-bound. The definitions of such Token Binding protocol 243 extensions are outside the scope of this specification. 245 At least one TokenBinding MUST be included in the Token Binding 246 message. The signature algorithm and key length used in the 247 TokenBinding MUST match the parameters negotiated via 248 [I-D.ietf-tokbind-negotiation]. The client SHOULD generate and store 249 Token Binding keys in a secure manner that prevents key export. In 250 order to prevent cooperating servers from linking user identities, 251 different keys SHOULD be used by the client for connections to 252 different servers, according to the token scoping rules of the 253 application protocol. 255 4. Establishing a TLS Token Binding 257 The triple handshake vulnerability in the TLS protocol affects the 258 security of the Token Binding protocol, as described in the "Security 259 Considerations" section below. Therefore, the server MUST NOT 260 negotiate the use of the Token Binding protocol unless the server 261 also negotiates Extended Master Secret TLS extension 262 [I-D.ietf-tls-session-hash]. 264 The server MUST terminate the connection if the use of the Token 265 Binding protocol was not negotiated, but the client sends the Token 266 Binding message. If the Token Binding type is 267 "provided_token_binding", the server MUST verify that the signature 268 algorithm (including elliptic curve in the case of ECDSA) and key 269 length in the Token Binding message match those negotiated via 270 [I-D.ietf-tokbind-negotiation]. In the case of a mismatch, the 271 server MUST terminate the connection. As described in 272 [I-D.ietf-tokbind-https], Token Bindings of type 273 "referred_token_binding" may have different key parameters than those 274 negotiated via [I-D.ietf-tokbind-negotiation]. 276 If the Token Binding message does not contain at least one 277 TokenBinding structure, or the signature contained in a TokenBinding 278 structure is invalid, the server MUST terminate the connection. 279 Otherwise, the TLS Token Binding is successfully established and its 280 ID can be provided to the application for security token validation. 282 5. TLS Token Binding ID Format 284 The ID of the TLS Token Binding established as a result of Token 285 Binding message processing is a binary representation of the 286 following structure: 288 struct { 289 TokenBindingType tokenbinding_type; 290 TokenBindingKeyParameters key_parameters; 291 select (key_parameters) { 292 case rsa2048_pkcs1.5: 293 case rsa2048_pss: 294 RSAPublicKey rsapubkey; 295 case ecdsap256: 296 ECPoint point; 297 } 298 } TokenBindingID; 300 TokenBindingID includes the type of the token binding and the key 301 parameters negotiated via [I-D.ietf-tokbind-negotiation]. This 302 document defines two token binding types: provided_token_binding used 303 to establish a Token Binding when connecting to a server, and 304 referred_token_binding used when requesting tokens to be presented to 305 a different server. Token Binding over HTTP [I-D.ietf-tokbind-https] 306 describes Token Binding between multiple communicating parties: User 307 Agent, Identity Provider and Relying Party. TLS Token Binding ID can 308 be obtained from the TokenBinding structure described in the "Token 309 Binding Protocol Message" section of this document by discarding the 310 signature and extensions. TLS Token Binding ID will be available at 311 the application layer and used by the server to generate and verify 312 bound tokens. 314 6. Security Token Validation 316 Security tokens can be bound to the TLS layer either by embedding the 317 Token Binding ID in the token, or by maintaining a database mapping 318 tokens to Token Binding IDs. The specific method of generating bound 319 security tokens is application-defined and beyond the scope of this 320 document. 322 Upon receipt of a security token, the server attempts to retrieve TLS 323 Token Binding ID information from the token and from the TLS 324 connection with the client. Application-provided policy determines 325 whether to honor non-bound (bearer) tokens. If the token is bound 326 and a TLS Token Binding has not been established for the client 327 connection, the server MUST discard the token. If the TLS Token 328 Binding ID for the token does not match the TLS Token Binding ID 329 established for the client connection, the server MUST discard the 330 token. 332 7. IANA Considerations 334 This document establishes a registry for Token Binding type 335 identifiers entitled "Token Binding Types" under the "Token Binding 336 Protocol" heading. 338 Entries in this registry require the following fields: 340 o Value: The octet value that identifies the Token Binding type 341 (0-255). 343 o Description: The description of the Token Binding type. 345 o Specification: A reference to a specification that defines the 346 Token Binding type. 348 This registry operates under the "Expert Review" policy as defined in 349 [RFC5226]. The designated expert is advised to encourage the 350 inclusion of a reference to a permanent and readily available 351 specification that enables the creation of interoperable 352 implementations using the identified Token Binding type. 354 An initial set of registrations for this registry follows: 356 Value: 0 358 Description: provided_token_binding 360 Specification: this document 361 Value: 1 363 Description: referred_token_binding 365 Specification: this document 367 This document establishes a registry for Token Binding extensions 368 entitled "Token Binding Extensions" under the "Token Binding 369 Protocol" heading. 371 Entries in this registry require the following fields: 373 o Value: The octet value that identifies the Token Binding extension 374 (0-255). 376 o Description: The description of the Token Binding extension. 378 o Specification: A reference to a specification that defines the 379 Token Binding extension. 381 This registry operates under the "Expert Review" policy as defined in 382 [RFC5226]. The designated expert is advised to encourage the 383 inclusion of a reference to a permanent and readily available 384 specification that enables the creation of interoperable 385 implementations using the identified Token Binding extension. This 386 document creates no initial registrations in the "Token Binding 387 Extensions" registry. 389 This document uses "Token Binding Key Parameters" registry originally 390 created in [I-D.ietf-tokbind-negotiation]. This document creates no 391 new registrations in this registry. 393 8. Security Considerations 395 8.1. Security Token Replay 397 The goal of the Token Binding protocol is to prevent attackers from 398 exporting and replaying security tokens, thereby impersonating 399 legitimate users and gaining access to protected resources. Bound 400 tokens can still be replayed by the malware present in the User 401 Agent. In order to export the token to another machine and 402 successfully replay it, the attacker also needs to export the 403 corresponding private key. Token Binding private keys are therefore 404 high-value assets and SHOULD be strongly protected, ideally by 405 generating them in a hardware security module that prevents key 406 export. 408 8.2. Downgrade Attacks 410 The Token Binding protocol is only used when negotiated via 411 [I-D.ietf-tokbind-negotiation] within the TLS handshake. TLS 412 prevents active attackers from modifying the messages of the TLS 413 handshake, therefore it is not possible for the attacker to remove or 414 modify the Token Binding Negotiation TLS Extension used to negotiate 415 the Token Binding protocol and key parameters. The signature 416 algorithm and key length used in the TokenBinding of type 417 "provided_token_binding" MUST match the parameters negotiated via 418 [I-D.ietf-tokbind-negotiation]. 420 8.3. Privacy Considerations 422 The Token Binding protocol uses persistent, long-lived TLS Token 423 Binding IDs. To protect privacy, TLS Token Binding IDs are never 424 transmitted in clear text and can be reset by the user at any time, 425 e.g. when clearing browser cookies. Some applications offer special 426 privacy modes where they don't store or use tokens supplied by the 427 server, e.g. "in private" browsing. Connections made in these 428 special privacy modes SHOULD NOT negotiate Token Binding. In order 429 to prevent cooperating servers from linking user identities, 430 different keys SHOULD be used by the client for connections to 431 different servers, according to the token scoping rules of the 432 application protocol. 434 8.4. Token Binding Key Sharing Between Applications 436 Existing systems provide a variety of platform-specific mechanisms 437 for certain applications to share tokens, e.g. to enable single sign- 438 on scenarios. For these scenarios to keep working with bound tokens, 439 the applications that are allowed to share tokens will need to also 440 share Token Binding keys. Care must be taken to restrict the sharing 441 of Token Binding keys to the same group(s) of applications that share 442 the same tokens. 444 8.5. Triple Handshake Vulnerability in TLS 446 The Token Binding protocol relies on the exported keying material 447 (EKM) to associate a TLS connection with a Token Binding. The triple 448 handshake attack [TRIPLE-HS] is a known TLS protocol vulnerability 449 allowing the attacker to synchronize keying material between TLS 450 connections. The attacker can then successfully replay bound tokens. 451 For this reason, the Token Binding protocol MUST NOT be negotiated 452 unless the Extended Master Secret TLS extension 453 [I-D.ietf-tls-session-hash] has also been negotiated. 455 9. Acknowledgements 457 This document incorporates comments and suggestions offered by Eric 458 Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Bill Cox, 459 Nick Harper and others. 461 10. References 463 10.1. Normative References 465 [I-D.ietf-tokbind-https] 466 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 467 "Token Binding over HTTP", draft-ietf-tokbind-https-01 468 (work in progress), June 2015. 470 [I-D.ietf-tokbind-negotiation] 471 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 472 "Transport Layer Security (TLS) Extension for Token 473 Binding Protocol Negotiation", draft-ietf-tokbind- 474 negotiation-00 (work in progress), September 2015. 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, 478 DOI 10.17487/RFC2119, March 1997, 479 . 481 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 482 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 483 for Transport Layer Security (TLS)", RFC 4492, 484 DOI 10.17487/RFC4492, May 2006, 485 . 487 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 488 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 489 DOI 10.17487/RFC5226, May 2008, 490 . 492 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 493 (TLS) Protocol Version 1.2", RFC 5246, 494 DOI 10.17487/RFC5246, August 2008, 495 . 497 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 498 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 499 March 2010, . 501 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 502 Protocol (HTTP/1.1): Message Syntax and Routing", 503 RFC 7230, DOI 10.17487/RFC7230, June 2014, 504 . 506 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 507 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 508 DOI 10.17487/RFC7540, May 2015, 509 . 511 10.2. Informative References 513 [I-D.ietf-tls-session-hash] 514 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 515 A., and M. Ray, "Transport Layer Security (TLS) Session 516 Hash and Extended Master Secret Extension", draft-ietf- 517 tls-session-hash-06 (work in progress), July 2015. 519 [TRIPLE-HS] 520 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 521 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 522 Breaking and Fixing Authentication over TLS. IEEE 523 Symposium on Security and Privacy", 2014. 525 Authors' Addresses 527 Andrei Popov (editor) 528 Microsoft Corp. 529 USA 531 Email: andreipo@microsoft.com 533 Magnus Nystroem 534 Microsoft Corp. 535 USA 537 Email: mnystrom@microsoft.com 539 Dirk Balfanz 540 Google Inc. 541 USA 543 Email: balfanz@google.com 544 Adam Langley 545 Google Inc. 546 USA 548 Email: agl@google.com