idnits 2.17.1 draft-ietf-tokbind-protocol-04.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 (January 8, 2016) is 3003 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 519, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-tokbind-https-02 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-01 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** 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: 8 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: July 11, 2016 D. Balfanz 6 A. Langley 7 Google Inc. 8 January 8, 2016 10 The Token Binding Protocol Version 1.0 11 draft-ietf-tokbind-protocol-04 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 July 11, 2016. 41 Copyright Notice 43 Copyright (c) 2016 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 . . . . . . . . . . . . . . 7 63 5. TLS Token Binding ID Format . . . . . . . . . . . . . . . . . 7 64 6. Security Token Validation . . . . . . . . . . . . . . . . . . 8 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 8.1. Security Token Replay . . . . . . . . . . . . . . . . . . 10 68 8.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 10 69 8.3. Privacy Considerations . . . . . . . . . . . . . . . . . 10 70 8.4. Token Binding Key Sharing Between Applications . . . . . 11 71 8.5. Triple Handshake Vulnerability in TLS 1.2 and Older TLS 72 Versions . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 10.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 Servers generate various security tokens (e.g. HTTP cookies, OAuth 82 tokens) for applications to access protected resources. Any party in 83 possession of such token gains access to the protected resource. 84 Attackers export bearer tokens from the user's machine, present them 85 to the servers, and impersonate authenticated users. The idea of 86 Token Binding is to prevent such attacks by cryptographically binding 87 security tokens to the TLS layer. 89 A TLS Token Binding is established by the user agent generating a 90 private-public key pair (possibly within a secure hardware module, 91 such as TPM) per target server, and proving possession of the private 92 key on every TLS connection to the target server. The proof of 93 possession involves signing the exported keying material [RFC5705] 94 for the TLS connection with the private key. The corresponding 95 public key is included in the TLS Token Binding identifier structure 96 (described in the "TLS Token Binding ID Format" section of this 97 document). TLS Token Bindings are long-lived, i.e. they encompass 98 multiple TLS connections and TLS sessions between a given client and 99 server. To protect privacy, TLS Token Binding IDs are never 100 transmitted in clear text and can be reset by the user at any time, 101 e.g. when clearing browser cookies. 103 When issuing a security token to a client that supports TLS Token 104 Binding, a server includes the client's TLS Token Binding ID in the 105 token. Later on, when a client presents a security token containing 106 a TLS Token Binding ID, the server makes sure the ID in the token 107 matches the ID of the TLS Token Binding established with the client. 108 In the case of a mismatch, the server discards the token. 110 In order to successfully export and replay a bound security token, 111 the attacker needs to also be able to export the client's private 112 key, which is hard to do in the case of the key generated in a secure 113 hardware module. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Token Binding Protocol Overview 123 The client and server use the Token Binding Negotiation TLS Extension 124 [I-D.ietf-tokbind-negotiation] to negotiate the Token Binding 125 protocol version and the parameters (signature algorithm, length) of 126 the Token Binding key. This negotiation does not require additional 127 round-trips. 129 The Token Binding protocol consists of one message sent by the client 130 to the server, proving possession of one or more client-generated 131 asymmetric keys. This message is only sent if the client and server 132 agree on the use of the Token Binding protocol and the key 133 parameters. The Token Binding message is sent with the application 134 protocol data in TLS application_data records. 136 A server receiving the Token Binding message verifies that the key 137 parameters in the message match the Token Binding parameters 138 negotiated via [I-D.ietf-tokbind-negotiation], and then validates the 139 signatures contained in the Token Binding message. If either of 140 these checks fails, the server terminates the connection, otherwise 141 the TLS Token Binding is successfully established with the ID 142 contained in the Token Binding message. 144 When a server supporting the Token Binding protocol receives a bound 145 token, the server compares the TLS Token Binding ID in the security 146 token with the TLS Token Binding ID established with the client. If 147 the bound token came from a TLS connection without a Token Binding, 148 or if the IDs don't match, the token is discarded. 150 This document defines the format of the Token Binding protocol 151 message, the process of establishing a TLS Token Binding, the format 152 of the Token Binding ID, and the process of validating a security 153 token. Token Binding Negotiation TLS Extension 154 [I-D.ietf-tokbind-negotiation] describes the negotiation of the Token 155 Binding protocol and key parameters. Token Binding over HTTP 156 [I-D.ietf-tokbind-https] explains how the Token Binding message is 157 encapsulated within HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] messages. 158 [I-D.ietf-tokbind-https] also describes Token Binding between 159 multiple communicating parties: User Agent, Identity Provider and 160 Relying Party. 162 3. Token Binding Protocol Message 164 The Token Binding message is sent by the client and proves possession 165 of one or more private keys held by the client. This message MUST be 166 sent if the client and server successfully negotiated the use of the 167 Token Binding protocol via [I-D.ietf-tokbind-negotiation], and MUST 168 NOT be sent otherwise. This message MUST be sent in the client's 169 first application protocol message. This message MAY also be sent in 170 subsequent application protocol messages, proving possession of other 171 keys by the same client, to facilitate token binding between more 172 than two communicating parties. Token Binding over HTTP 173 [I-D.ietf-tokbind-https] specifies the encapsulation of the Token 174 Binding message in the application protocol messages, and the 175 scenarios involving more than two communicating parties. The Token 176 Binding message format is defined using TLS specification language: 178 enum { 179 rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255) 180 } TokenBindingKeyParameters; 182 struct { 183 opaque modulus<1..2^16-1>; 184 opaque publicexponent<1..2^8-1>; 185 } RSAPublicKey; 187 struct { 188 opaque point <1..2^8-1>; 189 } ECPoint; 191 enum { 192 provided_token_binding(0), referred_token_binding(1), (255) 193 } TokenBindingType; 195 struct { 196 TokenBindingKeyParameters key_parameters; 197 select (key_parameters) { 198 case rsa2048_pkcs1.5: 199 case rsa2048_pss: 200 RSAPublicKey rsapubkey; 201 case ecdsap256: 202 ECPoint point; 203 } 204 } TokenBindingID; 206 enum { 207 (255) // No initial ExtensionType registrations 208 } ExtensionType; 210 struct { 211 ExtensionType extension_type; 212 opaque extension_data<0..2^16-1>; 213 } Extension; 215 struct { 216 TokenBindingType tokenbinding_type; 217 TokenBindingID tokenbindingid; 218 opaque signature<0..2^16-1>;// Signature over the exported keying material value 219 Extension extensions<0..2^16-1>; 220 } TokenBinding; 222 struct { 223 TokenBinding tokenbindings<0..2^16-1>; 224 } TokenBindingMessage; 225 The Token Binding message consists of a series of TokenBinding 226 structures containing the type of the token binding, the 227 TokenBindingID, a signature over the exported keying material (EKM) 228 value, optionally followed by Extension structures. 230 This document defines two token binding types: provided_token_binding 231 used to establish a Token Binding when connecting to a server, and 232 referred_token_binding used when requesting tokens to be presented to 233 a different server. Token Binding over HTTP [I-D.ietf-tokbind-https] 234 describes Token Binding between multiple communicating parties: User 235 Agent, Identity Provider and Relying Party. 237 When an rsa2048_pkcs1.5 or rsa2048_pss key is used, 238 TokenBinding.signature contains the signature generated using, 239 respectively, the RSASSA-PKCS1-v1_5 or RSASSA-PSS signature scheme 240 defined in [RFC3447]. RSAPublicKey.modulus and 241 RSAPublicKey.publicexponent contain the length-prefixed modulus and 242 exponent of the RSA public key represented in big-endian format. 244 When an ecdsap256 key is used, TokenBinding.signature contains a pair 245 of integers, R followed by S, as defined in [ANSI.X9-62.2005]. R and 246 S are encoded in big-endian format. ECPoint.point contains the X 247 coordinate followed by the Y coordinate. The X and Y coordinates are 248 unsigned integers encoded in big-endian format. Future 249 specifications may define Token Binding keys using other elliptic 250 curves with their corresponding signature and point formats. 252 The EKM is obtained using the Keying Material Exporters for TLS 253 defined in [RFC5705], by supplying the following input values: 255 o Label: The ASCII string "EXPORTER-Token-Binding" with no 256 terminating NUL. 258 o Context value: NULL (no application context supplied). 260 o Length: 32 bytes. 262 An implementation MUST ignore any unknown extensions. Initially, no 263 extension types are defined. One of the possible uses of extensions 264 envisioned at the time of this writing is attestation: cryptographic 265 proof that allows the server to verify that the Token Binding key is 266 hardware-bound. The definitions of such Token Binding protocol 267 extensions are outside the scope of this specification. 269 At least one TokenBinding MUST be included in the Token Binding 270 message. The signature algorithm and key length used in the 271 TokenBinding MUST match the parameters negotiated via 272 [I-D.ietf-tokbind-negotiation]. The client SHOULD generate and store 273 Token Binding keys in a secure manner that prevents key export. In 274 order to prevent cooperating servers from linking user identities, 275 different keys SHOULD be used by the client for connections to 276 different servers, according to the token scoping rules of the 277 application protocol. 279 4. Establishing a TLS Token Binding 281 The triple handshake vulnerability in TLS 1.2 and older TLS versions 282 affects the security of the Token Binding protocol, as described in 283 the "Security Considerations" section below. Therefore, the server 284 MUST NOT negotiate the use of the Token Binding protocol with these 285 TLS versions, unless the server also negotiates Extended Master 286 Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS 287 extensions. 289 The server MUST terminate the connection if the use of the Token 290 Binding protocol was not negotiated, but the client sends the Token 291 Binding message. If the Token Binding type is 292 "provided_token_binding", the server MUST verify that the signature 293 algorithm (including elliptic curve in the case of ECDSA) and key 294 length in the Token Binding message match those negotiated via 295 [I-D.ietf-tokbind-negotiation]. In the case of a mismatch, the 296 server MUST terminate the connection. As described in 297 [I-D.ietf-tokbind-https], Token Bindings of type 298 "referred_token_binding" may have different key parameters than those 299 negotiated via [I-D.ietf-tokbind-negotiation]. 301 If the Token Binding message does not contain at least one 302 TokenBinding structure, or the signature contained in a TokenBinding 303 structure is invalid, the server MUST terminate the connection. 304 Otherwise, the TLS Token Binding is successfully established and its 305 ID can be provided to the application for security token validation. 307 5. TLS Token Binding ID Format 308 The ID of the TLS Token Binding established as a result of Token 309 Binding message processing is a binary representation of the 310 following structure: 312 struct { 313 TokenBindingKeyParameters key_parameters; 314 select (key_parameters) { 315 case rsa2048_pkcs1.5: 316 case rsa2048_pss: 317 RSAPublicKey rsapubkey; 318 case ecdsap256: 319 ECPoint point; 320 } 321 } TokenBindingID; 323 TokenBindingID contains the key parameters negotiated via 324 [I-D.ietf-tokbind-negotiation]. TLS Token Binding ID can be obtained 325 from the TokenBinding structure described in the "Token Binding 326 Protocol Message" section of this document by discarding the token 327 binding type, signature and extensions. TLS Token Binding ID will be 328 available at the application layer and used by the server to generate 329 and verify bound tokens. 331 6. Security Token Validation 333 Security tokens can be bound to the TLS layer either by embedding the 334 Token Binding ID in the token, or by maintaining a database mapping 335 tokens to Token Binding IDs. The specific method of generating bound 336 security tokens is application-defined and beyond the scope of this 337 document. 339 Upon receipt of a security token, the server attempts to retrieve TLS 340 Token Binding ID information from the token and from the TLS 341 connection with the client. Application-provided policy determines 342 whether to honor non-bound (bearer) tokens. If the token is bound 343 and a TLS Token Binding has not been established for the client 344 connection, the server MUST discard the token. If the TLS Token 345 Binding ID for the token does not match the TLS Token Binding ID 346 established for the client connection, the server MUST discard the 347 token. 349 7. IANA Considerations 351 This document establishes a registry for Token Binding type 352 identifiers entitled "Token Binding Types" under the "Token Binding 353 Protocol" heading. 355 Entries in this registry require the following fields: 357 o Value: The octet value that identifies the Token Binding type 358 (0-255). 360 o Description: The description of the Token Binding type. 362 o Specification: A reference to a specification that defines the 363 Token Binding type. 365 This registry operates under the "Expert Review" policy as defined in 366 [RFC5226]. The designated expert is advised to encourage the 367 inclusion of a reference to a permanent and readily available 368 specification that enables the creation of interoperable 369 implementations using the identified Token Binding type. 371 An initial set of registrations for this registry follows: 373 Value: 0 375 Description: provided_token_binding 377 Specification: this document 379 Value: 1 381 Description: referred_token_binding 383 Specification: this document 385 This document establishes a registry for Token Binding extensions 386 entitled "Token Binding Extensions" under the "Token Binding 387 Protocol" heading. 389 Entries in this registry require the following fields: 391 o Value: The octet value that identifies the Token Binding extension 392 (0-255). 394 o Description: The description of the Token Binding extension. 396 o Specification: A reference to a specification that defines the 397 Token Binding extension. 399 This registry operates under the "Expert Review" policy as defined in 400 [RFC5226]. The designated expert is advised to encourage the 401 inclusion of a reference to a permanent and readily available 402 specification that enables the creation of interoperable 403 implementations using the identified Token Binding extension. This 404 document creates no initial registrations in the "Token Binding 405 Extensions" registry. 407 This document uses "Token Binding Key Parameters" registry originally 408 created in [I-D.ietf-tokbind-negotiation]. This document creates no 409 new registrations in this registry. 411 8. Security Considerations 413 8.1. Security Token Replay 415 The goal of the Token Binding protocol is to prevent attackers from 416 exporting and replaying security tokens, thereby impersonating 417 legitimate users and gaining access to protected resources. Bound 418 tokens can still be replayed by the malware present in the User 419 Agent. In order to export the token to another machine and 420 successfully replay it, the attacker also needs to export the 421 corresponding private key. Token Binding private keys are therefore 422 high-value assets and SHOULD be strongly protected, ideally by 423 generating them in a hardware security module that prevents key 424 export. 426 8.2. Downgrade Attacks 428 The Token Binding protocol is only used when negotiated via 429 [I-D.ietf-tokbind-negotiation] within the TLS handshake. TLS 430 prevents active attackers from modifying the messages of the TLS 431 handshake, therefore it is not possible for the attacker to remove or 432 modify the Token Binding Negotiation TLS Extension used to negotiate 433 the Token Binding protocol and key parameters. The signature 434 algorithm and key length used in the TokenBinding of type 435 "provided_token_binding" MUST match the parameters negotiated via 436 [I-D.ietf-tokbind-negotiation]. 438 8.3. Privacy Considerations 440 The Token Binding protocol uses persistent, long-lived TLS Token 441 Binding IDs. To protect privacy, TLS Token Binding IDs are never 442 transmitted in clear text and can be reset by the user at any time, 443 e.g. when clearing browser cookies. Some applications offer a 444 special privacy mode where they don't store or use tokens supplied by 445 the server, e.g. "in private" browsing. When operating in this 446 special privacy mode, applications SHOULD use newly generated Token 447 Binding keys and delete them when exiting this mode, or else SHOULD 448 NOT negotiate Token Binding at all. 450 In order to prevent cooperating servers from linking user identities, 451 different keys SHOULD be used by the client for connections to 452 different servers, according to the token scoping rules of the 453 application protocol. 455 A server can use tokens and Token Binding IDs to track clients. 456 Client applications that automatically limit the lifetime of tokens 457 to maintain user privacy SHOULD apply the same validity time limits 458 to Token Binding keys. 460 8.4. Token Binding Key Sharing Between Applications 462 Existing systems provide a variety of platform-specific mechanisms 463 for certain applications to share tokens, e.g. to enable single sign- 464 on scenarios. For these scenarios to keep working with bound tokens, 465 the applications that are allowed to share tokens will need to also 466 share Token Binding keys. Care must be taken to restrict the sharing 467 of Token Binding keys to the same group(s) of applications that share 468 the same tokens. 470 8.5. Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions 472 The Token Binding protocol relies on the exported keying material 473 (EKM) to associate a TLS connection with a Token Binding. The triple 474 handshake attack [TRIPLE-HS] is a known vulnerability in TLS 1.2 and 475 older TLS versions, allowing the attacker to synchronize keying 476 material between TLS connections. The attacker can then successfully 477 replay bound tokens. For this reason, the Token Binding protocol 478 MUST NOT be negotiated with these TLS versions, unless the Extended 479 Master Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS 480 extensions have also been negotiated. 482 9. Acknowledgements 484 This document incorporates comments and suggestions offered by Eric 485 Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Bill Cox, 486 Nick Harper and others. 488 10. References 490 10.1. Normative References 492 [ANSI.X9-62.2005] 493 American National Standards Institute, "Public Key 494 Cryptography for the Financial Services Industry, The 495 Elliptic Curve Digital Signature Algorithm (ECDSA)", 496 ANSI X9.62, 2005. 498 [I-D.ietf-tokbind-https] 499 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 500 "Token Binding over HTTP", draft-ietf-tokbind-https-02 501 (work in progress), October 2015. 503 [I-D.ietf-tokbind-negotiation] 504 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 505 "Transport Layer Security (TLS) Extension for Token 506 Binding Protocol Negotiation", draft-ietf-tokbind- 507 negotiation-01 (work in progress), October 2015. 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, 511 DOI 10.17487/RFC2119, March 1997, 512 . 514 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 515 Standards (PKCS) #1: RSA Cryptography Specifications 516 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 517 2003, . 519 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 520 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 521 for Transport Layer Security (TLS)", RFC 4492, 522 DOI 10.17487/RFC4492, May 2006, 523 . 525 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 526 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 527 DOI 10.17487/RFC5226, May 2008, 528 . 530 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 531 (TLS) Protocol Version 1.2", RFC 5246, 532 DOI 10.17487/RFC5246, August 2008, 533 . 535 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 536 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 537 March 2010, . 539 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 540 "Transport Layer Security (TLS) Renegotiation Indication 541 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 542 . 544 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 545 Protocol (HTTP/1.1): Message Syntax and Routing", 546 RFC 7230, DOI 10.17487/RFC7230, June 2014, 547 . 549 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 550 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 551 DOI 10.17487/RFC7540, May 2015, 552 . 554 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 555 Langley, A., and M. Ray, "Transport Layer Security (TLS) 556 Session Hash and Extended Master Secret Extension", 557 RFC 7627, DOI 10.17487/RFC7627, September 2015, 558 . 560 10.2. Informative References 562 [TRIPLE-HS] 563 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 564 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 565 Breaking and Fixing Authentication over TLS. IEEE 566 Symposium on Security and Privacy", 2014. 568 Authors' Addresses 570 Andrei Popov (editor) 571 Microsoft Corp. 572 USA 574 Email: andreipo@microsoft.com 576 Magnus Nystroem 577 Microsoft Corp. 578 USA 580 Email: mnystrom@microsoft.com 582 Dirk Balfanz 583 Google Inc. 584 USA 586 Email: balfanz@google.com 587 Adam Langley 588 Google Inc. 589 USA 591 Email: agl@google.com