idnits 2.17.1 draft-ietf-tokbind-protocol-06.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 (May 20, 2016) is 2897 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 600, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-tokbind-https-03 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-02 ** 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: November 21, 2016 D. Balfanz 6 A. Langley 7 Google Inc. 8 J. Hodges 9 Paypal 10 May 20, 2016 12 The Token Binding Protocol Version 1.0 13 draft-ietf-tokbind-protocol-06 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 [RFC5246] bindings 20 spanning multiple TLS sessions and connections. Applications are 21 then enabled to cryptographically bind security tokens to the TLS 22 layer, preventing token export and replay attacks. To protect 23 privacy, the TLS Token Binding identifiers are only transmitted 24 encrypted and can be reset 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 http://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 21, 2016. 43 Copyright Notice 45 Copyright (c) 2016 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 (http://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 4. Establishing a TLS Token Binding . . . . . . . . . . . . . . 7 65 4.1. Client Processing Rules . . . . . . . . . . . . . . . . . 7 66 4.2. Server Processing Rules . . . . . . . . . . . . . . . . . 7 67 5. TLS Token Binding ID Format . . . . . . . . . . . . . . . . . 8 68 6. Security Token Validation . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7.1. Token Binding Types Registry . . . . . . . . . . . . . . 10 71 7.2. Token Binding Extensions Registry . . . . . . . . . . . . 10 72 7.3. Registration of Token Binding TLS Exporter Label . . . . 11 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 8.1. Security Token Replay . . . . . . . . . . . . . . . . . . 11 75 8.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 11 76 8.3. Privacy Considerations . . . . . . . . . . . . . . . . . 12 77 8.4. Token Binding Key Sharing Between Applications . . . . . 12 78 8.5. Triple Handshake Vulnerability in TLS 1.2 and Older TLS 79 Versions . . . . . . . . . . . . . . . . . . . . . . . . 12 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 10.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 Servers generate various security tokens (e.g. HTTP cookies, OAuth 89 tokens) for applications to access protected resources. Any party in 90 possession of such token gains access to the protected resource. 91 Attackers export bearer tokens from the user's machine, present them 92 to the servers, and impersonate authenticated users. The idea of 93 Token Binding is to prevent such attacks by cryptographically binding 94 security tokens to the TLS layer. 96 A TLS Token Binding is established by the user agent generating a 97 private-public key pair (possibly within a secure hardware module, 98 such as TPM) per target server, and proving possession of the private 99 key on every TLS connection to the target server. The proof of 100 possession involves signing the exported keying material [RFC5705] 101 for the TLS connection with the private key. The corresponding 102 public key is included in the TLS Token Binding identifier structure 103 (described in the "TLS Token Binding ID Format" section of this 104 document). TLS Token Bindings are long-lived, i.e. they encompass 105 multiple TLS connections and TLS sessions between a given client and 106 server. To protect privacy, TLS Token Binding IDs are never 107 transmitted in clear text and can be reset by the user at any time, 108 e.g. when clearing browser cookies. 110 When issuing a security token to a client that supports TLS Token 111 Binding, a server includes the client's TLS Token Binding ID in the 112 token. Later on, when a client presents a security token containing 113 a TLS Token Binding ID, the server makes sure the ID in the token 114 matches the ID of the TLS Token Binding established with the client. 115 In the case of a mismatch, the server discards the token. 117 In order to successfully export and replay a bound security token, 118 the attacker needs to also be able to export the client's private 119 key, which is hard to do in the case of the key generated in a secure 120 hardware module. 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Token Binding Protocol Overview 130 The client and server use the Token Binding Negotiation TLS Extension 131 [I-D.ietf-tokbind-negotiation] to negotiate the Token Binding 132 protocol version and the parameters (signature algorithm, length) of 133 the Token Binding key. This negotiation does not require additional 134 round-trips. 136 The Token Binding protocol consists of one message sent by the client 137 to the server, proving possession of one or more client-generated 138 asymmetric keys. This message is only sent if the client and server 139 agree on the use of the Token Binding protocol and the key 140 parameters. The Token Binding message is sent with the application 141 protocol data in TLS application_data records. 143 A server receiving the Token Binding message verifies that the key 144 parameters in the message match the Token Binding parameters 145 negotiated via [I-D.ietf-tokbind-negotiation], and then validates the 146 signatures contained in the Token Binding message. If either of 147 these checks fails, the server terminates the connection, otherwise 148 the TLS Token Binding is successfully established with the ID 149 contained in the Token Binding message. 151 When a server supporting the Token Binding protocol receives a bound 152 token, the server compares the TLS Token Binding ID in the security 153 token with the TLS Token Binding ID established with the client. If 154 the bound token came from a TLS connection without a Token Binding, 155 or if the IDs don't match, the token is discarded. 157 This document defines the format of the Token Binding protocol 158 message, the process of establishing a TLS Token Binding, the format 159 of the Token Binding ID, and the process of validating a security 160 token. Token Binding Negotiation TLS Extension 161 [I-D.ietf-tokbind-negotiation] describes the negotiation of the Token 162 Binding protocol and key parameters. Token Binding over HTTP 163 [I-D.ietf-tokbind-https] explains how the Token Binding message is 164 encapsulated within HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] messages. 165 [I-D.ietf-tokbind-https] also describes Token Binding between 166 multiple communicating parties: User Agent, Identity Provider and 167 Relying Party. 169 3. Token Binding Protocol Message 171 The Token Binding message is sent by the client to prove possession 172 of one or more private keys held by the client. This message MUST be 173 sent if the client and server successfully negotiated the use of the 174 Token Binding protocol via [I-D.ietf-tokbind-negotiation], and MUST 175 NOT be sent otherwise. This message MUST be sent in the client's 176 first application protocol message. This message MAY also be sent in 177 subsequent application protocol messages, proving possession of 178 additional private keys held by the same client, which can be used to 179 facilitate token binding between more than two communicating parties. 180 For example, Token Binding over HTTP [I-D.ietf-tokbind-https] 181 specifies an encapsulation of the Token Binding message in HTTP 182 application protocol messages, as well as scenarios involving more 183 than two communicating parties. 185 The Token Binding message format is defined using TLS Presentation 186 Language (see Section 4 of [RFC5246]): 188 enum { 189 rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255) 190 } TokenBindingKeyParameters; 192 struct { 193 opaque modulus<1..2^16-1>; 194 opaque publicexponent<1..2^8-1>; 195 } RSAPublicKey; 197 struct { 198 opaque point <1..2^8-1>; 199 } ECPoint; 201 enum { 202 provided_token_binding(0), referred_token_binding(1), (255) 203 } TokenBindingType; 205 struct { 206 TokenBindingKeyParameters key_parameters; 207 select (key_parameters) { 208 case rsa2048_pkcs1.5: 209 case rsa2048_pss: 210 RSAPublicKey rsapubkey; 211 case ecdsap256: 212 ECPoint point; 213 } 214 } TokenBindingID; 216 enum { 217 (255) // No initial ExtensionType registrations 218 } ExtensionType; 220 struct { 221 ExtensionType extension_type; 222 opaque extension_data<0..2^16-1>; 223 } Extension; 225 struct { 226 TokenBindingType tokenbinding_type; 227 TokenBindingID tokenbindingid; 228 opaque signature<0..2^16-1>;// Signature over the exported keying material value 229 Extension extensions<0..2^16-1>; 230 } TokenBinding; 232 struct { 233 TokenBinding tokenbindings<0..2^16-1>; 234 } TokenBindingMessage; 235 The Token Binding message consists of a series of TokenBinding 236 structures, each containing the type of the token binding, the 237 TokenBindingID, a signature over an exported keying material (EKM) 238 value, optionally followed by Extension structures. 240 This document defines two Token Binding types: 242 o provided_token_binding - used to establish a Token Binding when 243 connecting to a server. 245 o referred_token_binding - used when requesting tokens to be 246 presented to a different server. 248 Token Binding over HTTP [I-D.ietf-tokbind-https] describes a use case 249 for referred_token_binding where Token Bindings are established 250 between multiple communicating parties: User Agent, Identity Provider 251 and Relying Party. User Agent sends referred_token_binding to the 252 Identity Provider in order to prove possession of the Token Binding 253 key it uses with the Relying Party. The Identity Provider can then 254 bind the token it is supplying (for presentation to the Relying 255 Party) to the Token Binding ID contained in the 256 referred_token_binding. Such bound token enjoys the protections 257 discussed below in Section 8 "Security Considerations". 259 This document establishes an IANA registry for Token Binding 260 extensions in Section 7.1 "Token Binding Types Registry". An 261 implementation MUST ignore any unknown Token Binding types. 263 When an rsa2048_pkcs1.5 or rsa2048_pss key is used, 264 TokenBinding.signature contains the signature generated using, 265 respectively, the RSASSA-PKCS1-v1_5 or RSASSA-PSS signature scheme 266 defined in [RFC3447]. RSAPublicKey.modulus and 267 RSAPublicKey.publicexponent contain the length-prefixed modulus and 268 exponent of the RSA public key represented in big-endian format. 270 When an ecdsap256 key is used, TokenBinding.signature contains a pair 271 of 32-byte integers, R followed by S, generated using Curve P-256 as 272 defined in [ANSI.X9-62.2005] and [FIPS.186-4.2013]. R and S are 273 encoded in big-endian format, preserving any leading zero bytes. 274 ECPoint.point contains the X coordinate followed by the Y coordinate. 275 The X and Y coordinates are unsigned 32-byte integers encoded in big- 276 endian format, preserving any leading zero bytes. Future 277 specifications may define Token Binding keys using other elliptic 278 curves with their corresponding signature and point formats. 280 The EKM is obtained using the Keying Material Exporters for TLS 281 defined in [RFC5705], by supplying the following input values: 283 o Label: The ASCII string "EXPORTER-Token-Binding" with no 284 terminating NUL. 286 o Context value: NULL (no application context supplied). 288 o Length: 32 bytes. 290 4. Establishing a TLS Token Binding 292 4.1. Client Processing Rules 294 The client MUST include at least one TokenBinding structure in the 295 Token Binding message. The key parameters used in the 296 provided_token_binding MUST match those negotiated with the server 297 via [I-D.ietf-tokbind-negotiation]. 299 The client SHOULD generate and store Token Binding keys in a secure 300 manner that prevents key export. In order to prevent cooperating 301 servers from linking user identities, different keys SHOULD be used 302 by the client for connections to different servers, according to the 303 token scoping rules of the application protocol. 305 When the client needs to send a referred_token_binding to the 306 Identity Provider, the client SHALL construct the referred 307 TokenBinding structure in the following manner: 309 o Set TokenBinding.tokenbinding_type to referred_token_binding. 311 o Set TokenBinding.tokenbindingid to the Token Binding ID used with 312 the Relying Party. 314 o Set TokenBinding.signature to the result of signing the EKM value 315 of the TLS connection to the Identity Provider, using the Token 316 Binding key established with the Relying Party and the signature 317 algorithm indicated by the associated key parameters. Note that 318 these key parameters may differ from the key parameters negotiated 319 with the Identity Provider. 321 Conveying referred Token Bindings in this fashion allows the Identity 322 Provider to verify that the client controls the Token Binding key 323 used with the Relying Party. 325 4.2. Server Processing Rules 327 The triple handshake vulnerability in TLS 1.2 and older TLS versions 328 affects the security of the Token Binding protocol, as described in 329 Section 8 "Security Considerations". Therefore, the server MUST NOT 330 negotiate the use of the Token Binding protocol with these TLS 331 versions, unless the server also negotiates Extended Master Secret 332 [RFC7627] and Renegotiation Indication [RFC5746] TLS extensions. 334 The server MUST terminate the connection if the use of the Token 335 Binding protocol was not negotiated, but the client sends the Token 336 Binding message. If the Token Binding type is 337 "provided_token_binding", the server MUST verify that the signature 338 algorithm (including elliptic curve in the case of ECDSA) and key 339 length in the Token Binding message match those negotiated via 340 [I-D.ietf-tokbind-negotiation]. In the case of a mismatch, the 341 server MUST terminate the connection. Token Bindings of type 342 "referred_token_binding" may use different key parameters than those 343 negotiated with this client. 345 If the Token Binding message does not contain at least one 346 TokenBinding structure, or if a signature contained in any 347 TokenBinding structure is invalid, the server MUST terminate the 348 connection. 350 Servers MUST ignore any unknown extensions. Initially, no extension 351 types are defined (see Section 7.2 352 "Token Binding Extensions Registry"). One of the possible uses of 353 extensions envisioned at the time of this writing is attestation: 354 cryptographic proof that allows the server to verify that the Token 355 Binding key is hardware-bound. The definitions of such Token Binding 356 protocol extensions are outside the scope of this specification. 358 If all checks defined above have passed successfully, the TLS Token 359 Binding between this client and server is established. The Token 360 Binding ID(s) conveyed in the Token Binding Message can be provided 361 to the server-side application. The application may then use the 362 Token Binding IDs for bound security token creation and validation. 364 5. TLS Token Binding ID Format 365 The ID of the TLS Token Binding established as a result of Token 366 Binding message processing is a binary representation of the 367 following structure: 369 struct { 370 TokenBindingKeyParameters key_parameters; 371 select (key_parameters) { 372 case rsa2048_pkcs1.5: 373 case rsa2048_pss: 374 RSAPublicKey rsapubkey; 375 case ecdsap256: 376 ECPoint point; 377 } 378 } TokenBindingID; 380 TokenBindingID contains the key parameters negotiated via 381 [I-D.ietf-tokbind-negotiation]. TLS Token Binding ID can be obtained 382 from the TokenBinding structure described in the "Token Binding 383 Protocol Message" section of this document by discarding the Token 384 Binding type, signature and extensions. TLS Token Binding ID will be 385 available at the application layer and used by the server to generate 386 and verify bound tokens. 388 6. Security Token Validation 390 Security tokens can be bound to the TLS layer either by embedding the 391 Token Binding ID in the token, or by maintaining a database mapping 392 tokens to Token Binding IDs. The specific method of generating bound 393 security tokens is application-defined and beyond the scope of this 394 document. 396 Upon receipt of a security token, the server attempts to retrieve TLS 397 Token Binding ID information from the token and from the TLS 398 connection with the client. Application-provided policy determines 399 whether to honor non-bound (bearer) tokens. If the token is bound 400 and a TLS Token Binding has not been established for the client 401 connection, the server MUST discard the token. If the TLS Token 402 Binding ID for the token does not match the TLS Token Binding ID 403 established for the client connection, the server MUST discard the 404 token. 406 7. IANA Considerations 408 This section establishes two IANA registries: one for Token Binding 409 types, another for Token Binding extensions. It also registers a new 410 TLS exporter label in the TLS Exporter Label Registry. 412 7.1. Token Binding Types Registry 414 This document establishes a registry for Token Binding type 415 identifiers entitled "Token Binding Types" under the "Token Binding 416 Protocol" heading. 418 Entries in this registry require the following fields: 420 o Value: The octet value that identifies the Token Binding type 421 (0-255). 423 o Description: The description of the Token Binding type. 425 o Specification: A reference to a specification that defines the 426 Token Binding type. 428 This registry operates under the "Expert Review" policy as defined in 429 [RFC5226]. The designated expert is advised to encourage the 430 inclusion of a reference to a permanent and readily available 431 specification that enables the creation of interoperable 432 implementations using the identified Token Binding type. 434 An initial set of registrations for this registry follows: 436 Value: 0 438 Description: provided_token_binding 440 Specification: this document 442 Value: 1 444 Description: referred_token_binding 446 Specification: this document 448 7.2. Token Binding Extensions Registry 450 This document establishes a registry for Token Binding extensions 451 entitled "Token Binding Extensions" under the "Token Binding 452 Protocol" heading. 454 Entries in this registry require the following fields: 456 o Value: The octet value that identifies the Token Binding extension 457 (0-255). 459 o Description: The description of the Token Binding extension. 461 o Specification: A reference to a specification that defines the 462 Token Binding extension. 464 This registry operates under the "Expert Review" policy as defined in 465 [RFC5226]. The designated expert is advised to encourage the 466 inclusion of a reference to a permanent and readily available 467 specification that enables the creation of interoperable 468 implementations using the identified Token Binding extension. This 469 document creates no initial registrations in the "Token Binding 470 Extensions" registry. 472 This document uses "Token Binding Key Parameters" registry originally 473 created in [I-D.ietf-tokbind-negotiation]. This document creates no 474 new registrations in this registry. 476 7.3. Registration of Token Binding TLS Exporter Label 478 This document adds a registration for the "EXPORTER-Token-Binding" 479 value in the TLS Exporter Label Registry to correspond to this 480 specification. 482 8. Security Considerations 484 8.1. Security Token Replay 486 The goal of the Token Binding protocol is to prevent attackers from 487 exporting and replaying security tokens, thereby impersonating 488 legitimate users and gaining access to protected resources. Bound 489 tokens can still be replayed by the malware present in the User 490 Agent. In order to export the token to another machine and 491 successfully replay it, the attacker also needs to export the 492 corresponding private key. Token Binding private keys are therefore 493 high-value assets and SHOULD be strongly protected, ideally by 494 generating them in a hardware security module that prevents key 495 export. 497 The manner in which a token is bound to the TLS layer is application- 498 defined and beyond the scope of this document. However, the 499 resulting bound token needs to be integrity-protected, so that an 500 attacker cannot remove the binding or substitute a Token Binding ID 501 of their choice without detection. 503 8.2. Downgrade Attacks 505 The Token Binding protocol is only used when negotiated via 506 [I-D.ietf-tokbind-negotiation] within the TLS handshake. TLS 507 prevents active attackers from modifying the messages of the TLS 508 handshake, therefore it is not possible for the attacker to remove or 509 modify the Token Binding Negotiation TLS Extension used to negotiate 510 the Token Binding protocol and key parameters. The signature 511 algorithm and key length used in the TokenBinding of type 512 "provided_token_binding" MUST match the parameters negotiated via 513 [I-D.ietf-tokbind-negotiation]. 515 8.3. Privacy Considerations 517 The Token Binding protocol uses persistent, long-lived TLS Token 518 Binding IDs. To protect privacy, TLS Token Binding IDs are never 519 transmitted in clear text and can be reset by the user at any time, 520 e.g. when clearing browser cookies. Some applications offer a 521 special privacy mode where they don't store or use tokens supplied by 522 the server, e.g. "in private" browsing. When operating in this 523 special privacy mode, applications SHOULD use newly generated Token 524 Binding keys and delete them when exiting this mode, or else SHOULD 525 NOT negotiate Token Binding at all. 527 In order to prevent cooperating servers from linking user identities, 528 different keys SHOULD be used by the client for connections to 529 different servers, according to the token scoping rules of the 530 application protocol. 532 A server can use tokens and Token Binding IDs to track clients. 533 Client applications that automatically limit the lifetime of tokens 534 to maintain user privacy SHOULD apply the same validity time limits 535 to Token Binding keys. 537 8.4. Token Binding Key Sharing Between Applications 539 Existing systems provide a variety of platform-specific mechanisms 540 for certain applications to share tokens, e.g. to enable single sign- 541 on scenarios. For these scenarios to keep working with bound tokens, 542 the applications that are allowed to share tokens will need to also 543 share Token Binding keys. Care must be taken to restrict the sharing 544 of Token Binding keys to the same group(s) of applications that share 545 the same tokens. 547 8.5. Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions 549 The Token Binding protocol relies on the exported keying material 550 (EKM) to associate a TLS connection with a Token Binding. The triple 551 handshake attack [TRIPLE-HS] is a known vulnerability in TLS 1.2 and 552 older TLS versions, allowing the attacker to synchronize keying 553 material between TLS connections. The attacker can then successfully 554 replay bound tokens. For this reason, the Token Binding protocol 555 MUST NOT be negotiated with these TLS versions, unless the Extended 556 Master Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS 557 extensions have also been negotiated. 559 9. Acknowledgements 561 This document incorporates comments and suggestions offered by Eric 562 Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Bill Cox, 563 Nick Harper, Brian Campbell and others. 565 10. References 567 10.1. Normative References 569 [ANSI.X9-62.2005] 570 American National Standards Institute, "Public Key 571 Cryptography for the Financial Services Industry, The 572 Elliptic Curve Digital Signature Algorithm (ECDSA)", 573 ANSI X9.62, 2005. 575 [FIPS.186-4.2013] 576 National Institute of Standards and Technology, "Digital 577 Signature Standard (DSS)", FIPS 186-4, 2013. 579 [I-D.ietf-tokbind-https] 580 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 581 Hodges, "Token Binding over HTTP", draft-ietf-tokbind- 582 https-03 (work in progress), March 2016. 584 [I-D.ietf-tokbind-negotiation] 585 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 586 "Transport Layer Security (TLS) Extension for Token 587 Binding Protocol Negotiation", draft-ietf-tokbind- 588 negotiation-02 (work in progress), January 2016. 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, 592 DOI 10.17487/RFC2119, March 1997, 593 . 595 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 596 Standards (PKCS) #1: RSA Cryptography Specifications 597 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 598 2003, . 600 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 601 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 602 for Transport Layer Security (TLS)", RFC 4492, 603 DOI 10.17487/RFC4492, May 2006, 604 . 606 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 607 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 608 DOI 10.17487/RFC5226, May 2008, 609 . 611 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 612 (TLS) Protocol Version 1.2", RFC 5246, 613 DOI 10.17487/RFC5246, August 2008, 614 . 616 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 617 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 618 March 2010, . 620 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 621 "Transport Layer Security (TLS) Renegotiation Indication 622 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 623 . 625 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 626 Protocol (HTTP/1.1): Message Syntax and Routing", 627 RFC 7230, DOI 10.17487/RFC7230, June 2014, 628 . 630 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 631 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 632 DOI 10.17487/RFC7540, May 2015, 633 . 635 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 636 Langley, A., and M. Ray, "Transport Layer Security (TLS) 637 Session Hash and Extended Master Secret Extension", 638 RFC 7627, DOI 10.17487/RFC7627, September 2015, 639 . 641 10.2. Informative References 643 [TRIPLE-HS] 644 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 645 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 646 Breaking and Fixing Authentication over TLS. IEEE 647 Symposium on Security and Privacy", 2014. 649 Authors' Addresses 651 Andrei Popov (editor) 652 Microsoft Corp. 653 USA 655 Email: andreipo@microsoft.com 657 Magnus Nystroem 658 Microsoft Corp. 659 USA 661 Email: mnystrom@microsoft.com 663 Dirk Balfanz 664 Google Inc. 665 USA 667 Email: balfanz@google.com 669 Adam Langley 670 Google Inc. 671 USA 673 Email: agl@google.com 675 Jeff Hodges 676 Paypal 677 USA 679 Email: Jeff.Hodges@paypal.com