idnits 2.17.1 draft-ietf-tokbind-https-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([RFC5246], [TBPROTO]), 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 15, 2015) is 3113 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 497, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'RFC5929' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC7301' is defined on line 521, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'TBPROTO' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Popov 3 Internet-Draft M. Nystroem 4 Intended status: Standards Track Microsoft Corp. 5 Expires: April 17, 2016 D. Balfanz, Ed. 6 A. Langley 7 Google Inc. 8 October 15, 2015 10 Token Binding over HTTP 11 draft-ietf-tokbind-https-02 13 Abstract 15 This document describes a collection of mechanisms that allow HTTP 16 servers to cryptographically bind authentication tokens (such as 17 cookies and OAuth tokens) to a TLS [RFC5246] connection. 19 We describe both _first-party_ as well as _federated_ scenarios. In 20 a first-party scenario, an HTTP server issues a security token (such 21 as a cookie) to a client, and expects the client to send the security 22 token back to the server at a later time in order to authenticate. 23 Binding the token to the TLS connection between client and server 24 protects the security token from theft, and ensures that the security 25 token can only be used by the client that it was issued to. 27 Federated token bindings, on the other hand, allow servers to 28 cryptographically bind security tokens to a TLS [RFC5246] connection 29 that the client has with a _different_ server than the one issuing 30 the token. 32 This Internet-Draft is a companion document to The Token Binding 33 Protocol [TBPROTO] 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 17, 2016. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 2. The Token-Binding Header . . . . . . . . . . . . . . . . . . 3 71 3. Federation Use Cases . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 73 3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3.3. HTTP Redirects . . . . . . . . . . . . . . . . . . . . . 6 75 3.4. Negotiated Key Parameters . . . . . . . . . . . . . . . . 7 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 4.1. Security Token Replay . . . . . . . . . . . . . . . . . . 7 78 4.2. Privacy Considerations . . . . . . . . . . . . . . . . . 7 79 4.3. Triple Handshake Vulnerability in TLS . . . . . . . . . . 7 80 4.4. Sensitivity of the Token-Binding Header . . . . . . . . . 8 81 4.5. Securing Federated Sign-On Protocols . . . . . . . . . . 9 82 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 5.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 5.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 The Token Binding Protocol [TBPROTO] defines a Token Binding ID for a 90 TLS connection between a client and a server. The Token Binding ID 91 of a TLS connection is related to a private key that the client 92 proves possession of to the server, and is long-lived (i.e., 93 subsequent TLS connections between the same client and server have 94 the same Token Binding ID). When issuing a security token (e.g. an 95 HTTP cookie or an OAuth token) to a client, the server can include 96 the Token Binding ID in the token, thus cryptographically binding the 97 token to TLS connections between that particular client and server, 98 and inoculating the token against theft by attackers. 100 While the Token Binding Protocol [TBPROTO] defines a message format 101 for establishing a Token Binding ID, it doesn't specify how this 102 message is embedded in higher-level protocols. The purpose of this 103 specification is to define how TokenBindingMessages are embedded in 104 HTTP (both versions 1.1 [RFC2616] and 2 [I-D.ietf-httpbis-http2]). 105 Note that TokenBindingMessages are only defined if the underlying 106 transport uses TLS. This means that Token Binding over HTTP is only 107 defined when the HTTP protocol is layered on top of TLS (commonly 108 referred to as HTTPS). 110 HTTP clients establish a Token Binding ID with a server by including 111 a special HTTP header in HTTP requests. The HTTP header value is a 112 TokenBindingMessage. 114 TokenBindingMessages allow clients to establish multiple Token 115 Binding IDs with the server, by including multiple TokenBinding 116 structures in the TokenBindingMessage. By default, a client will 117 establish a _provided_ Token Binding ID with the server, indicating a 118 Token Binding ID that the client will persistently use with the 119 server. Under certain conditions, the client can also include a 120 _referred_ Token Binding ID in the TokenBindingMessage, indicating a 121 Token Binding ID that the client is using with a _different_ server 122 than the one that the TokenBindingMessage is sent to. This is useful 123 in federation scenarios. 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 2. The Token-Binding Header 133 Once a client and server have negotiated the Token Binding Protocol 134 with HTTP/1.1 or HTTP/2 (see The Token Binding Protocol [TBPROTO]), 135 clients MUST include the Token-Binding header in their HTTP requests. 136 The ABNF of the Token-Binding header is: 138 Token-Binding = "Token-Binding" ":" [CFWS] EncodedTokenBindingMessage 140 The EncodedTokenBindingMessage is a web-safe Base64-encoding of the 141 TokenBindingMessage as defined in the TokenBindingProtocol [TBPROTO]. 143 The TokenBindingMessage MUST contain a TokenBinding with 144 TokenBindingType provided_token_binding, which MUST be signed with 145 the Token Binding key used by the client for connections between 146 itself and the server that the HTTP request is sent to (clients use 147 different Token Binding keys for different servers). The Token 148 Binding ID established by this TokenBinding is called a _Provided 149 Token Binding ID_ 151 In HTTP/2, the client SHOULD use Header Compression 152 [I-D.ietf-httpbis-header-compression] to avoid the overhead of 153 repeating the same header in subsequent HTTP requests. 155 3. Federation Use Cases 157 3.1. Introduction 159 For privacy reasons, clients use different private keys to establish 160 Provided Token Binding IDs with different servers. As a result, a 161 server cannot bind a security token (such as an OAuth token or an 162 OpenID Connect identity token) to a TLS connection that the client 163 has with a different server. This is, however, a common requirement 164 in federation scenarios: For example, an Identity Provider may wish 165 to issue an identity token to a client and cryptographically bind 166 that token to the TLS connection between the client and a Relying 167 Party. 169 In this section we describe mechanisms to achieve this. The common 170 idea among these mechanisms is that a server (called the _Token 171 Consumer_ in this document) gives the client permission to reveal the 172 Provided Token Binding ID that is used between the client and itself, 173 to another server (called the _Token Provider_ in this document). 174 Also common across the mechanisms is how the Token Binding ID is 175 revealed to the Token Provider: The client uses the Token Binding 176 Protocol [TBPROTO], and includes a TokenBinding structure in the 177 Token-Binding HTTP header defined above. What differs between the 178 various mechanisms is _how_ the Token Consumer grants the permission 179 to reveal the Token Binding ID to the Token Provider. Below we 180 specify one such mechanism, which is suitable for redirect-based 181 interactions between Token Consumers and Token Providers. 183 3.2. Overview 185 In a Federated Sign-On protocol, an Identity Provider issues an 186 identity token to a client, which sends the identity token to a 187 Relying Party to authenticate itself. Examples of this include 188 OpenID Connect (where the identity token is called "ID Token") and 189 SAML (where the identity token is a SAML assertion). 191 To better protect the security of the identity token, the Identity 192 Provider may wish to bind the identity token to the TLS connection 193 between the client and the Relying Party, thus ensuring that only 194 said client can use the identity token: The Relying Party will 195 compare the Token Binding ID in the identity token with the Token 196 Binding ID of the TLS connection between it an the client. 198 This is an example of a federation scenario, which more generally can 199 be described as follows: 201 o A Token Consumer causes the client to issue a token request to the 202 Token Provider. The goal is for the client to obtain a token and 203 then use it with the Token Consumer. 205 o The client delivers the token request to the Token Provider. 207 o The Token Provider issues the token. The token is issued for the 208 specific Token Consumer who requested it (thus preventing 209 malicious Token Consumers from using tokens with other Token 210 Consumers). The token is, however, typically a bearer token, 211 meaning that any client can use it with the Token Consumer, not 212 just the client to which it was issued. 214 o Therefore, in the previous step, the Token Provider may want to 215 include in the token the Token-Binding public key that the client 216 uses when communicating with the Token Consumer, thus _binding_ 217 the token to client's Token-Binding keypair. The client proves 218 possession of the private key when communicating with the Token 219 Consumer through the Token Binding Protocol [TBPROTO], and reveals 220 the corresponding public key of this keypair as part of the Token 221 Binding ID. Comparing the public key from the token with the 222 public key from the Token Binding ID allows the Token Consumer to 223 verify that the token was sent to it by the legitimate client. 225 o To allow the Token Provider to include the Token-Binding public 226 key in the token, the Token Binding ID (between client and Token 227 Consumer) must therefore be communicated to the Token Provider 228 along with the token request. Communicating a Token Binding ID 229 involves proving possession of a private key and is described in 230 the Token Binding Protocol [TBPROTO]. 232 The client will perform this last operation (proving possession of a 233 private key that corresponds to a Token Binding ID between the client 234 and the Token Consumer while delivering the token request to the 235 Token Provider) only if the Token Consumer permits the client to do 236 so. 238 Below, we specify how Token Consumers can grant this permission. 239 during redirect-based federation protocols. 241 3.3. HTTP Redirects 243 When a Token Consumer redirects the client to a Token Provider as a 244 means to deliver the token request, it SHOULD include a Include- 245 Referer-Token-Binding-ID HTTP response header in its HTTP response. 246 The ABNF of the Include-Referer-Token-Binding-ID header is: 248 Include-Referer-Token-Binding-ID = "Include-Referer-Token-Binding-ID" ":" 249 [CFWS] %x74.72.75.65 ; "true", case-sensitive 251 Including this response header signals to the client that it should 252 reveal the Token Binding ID used between the client and the Token 253 Consumer to the Token Provider. In the absence of this response 254 header, the client will not disclose any information about the Token 255 Binding used between the client and the Token Consumer to the Token 256 Provider. 258 This header has only meaning if the HTTP status code is 301, 302, 259 303, 307 or 308, and MUST be ignored by the client for any other 260 status codes. If the client supports the Token Binding Protocol, and 261 has negotiated the Token Binding Protocol with both the Token 262 Consumer and the Token Provider, it already sends the following 263 header to the Token Provider with each HTTP request (see above): 265 Token-Binding: EncodedTokenBindingMessage 267 The TokenBindingMessage SHOULD contain a TokenBinding with 268 TokenBindingType referred_token_binding. If included, this 269 TokenBinding MUST be signed with the Token Binding key used by the 270 client for connections between itself and the Token Consumer (more 271 specifically, the web origin that issued the Include-Referer-Token- 272 Binding-ID response header). The Token Binding ID established by 273 this TokenBinding is called a _Referred Token Binding ID_. 275 As described above, the TokenBindingMessage MUST additionally contain 276 a Provided Token Binding ID, i.e., a TokenBinding structure with 277 TokenBindingType provided_token_binding, which MUST be signed with 278 the Token Binding key used by the client for connections between 279 itself and the Token Privider (more specifically, the web origin that 280 the token request sent to). 282 3.4. Negotiated Key Parameters 284 The Token Binding Protocol [TBPROTO] allows the server and client to 285 negotiate a signature algorithm used in the TokenBindingMessage. It 286 is possible that the Token Binding ID used between the client and the 287 Token Consumer, and the Token Binding ID used between the client and 288 Token Provider, use different signature algorithms. The client MUST 289 use the signature algorithm negotiated with the Token Consumer in the 290 referred_token_binding TokenBinding of the TokenBindingMessage, even 291 if that signature algorithm is different from the one negotiated with 292 the origin that the header is sent to. 294 Token Providers SHOULD support all the SignatureAndHashAlgorithms 295 specified in the Token Binding Protocol [TBPROTO]. If a token 296 provider does not support the SignatureAndHashAlgorithm specified in 297 the referred_token_binding TokenBinding in the TokenBindingMessage, 298 it MUST issue an unbound token. 300 4. Security Considerations 302 4.1. Security Token Replay 304 The goal of the Federated Token Binding mechanisms is to prevent 305 attackers from exporting and replaying tokens used in protocols 306 between the client and Token Consumer, thereby impersonating 307 legitimate users and gaining access to protected resources. Bound 308 tokens can still be replayed by malware present in the client. In 309 order to export the token to another machine and successfully replay 310 it, the attacker also needs to export the corresponding private key. 311 The Token Binding private key is therefore a high-value asset and 312 MUST be strongly protected, ideally by generating it in a hardware 313 security module that prevents key export. 315 4.2. Privacy Considerations 317 The Token Binding protocol uses persistent, long-lived TLS Token 318 Binding IDs. To protect privacy, TLS Token Binding IDs are never 319 transmitted in clear text and can be reset by the user at any time, 320 e.g. when clearing browser cookies. Unique Token Binding IDs MUST be 321 generated for connections to different origins, so they cannot be 322 used by cooperating servers to link user identities. 324 4.3. Triple Handshake Vulnerability in TLS 326 The Token Binding protocol relies on the exported key material (EKM) 327 value [RFC5705] to associate a TLS connection with a TLS Token 328 Binding. The triple handshake attack [TRIPLE-HS] is a known TLS 329 protocol vulnerability allowing the attacker to synchronize keying 330 manterial between TLS connections. The attacker can then 331 successfully replay bound tokens. For this reason, the Token Binding 332 protocol MUST NOT be negotiated unless the Extended Master Secret TLS 333 extension [I-D.ietf-tls-session-hash] has also been negotiated. 335 4.4. Sensitivity of the Token-Binding Header 337 The purpose of the Token Binding protocol is to convince the server 338 that the client that initiated the TLS connection controls a certain 339 key pair. For the server to correctly draw this conclusion after 340 processing the Token-Binding header, certain secrecy and integrity 341 requirements must be met. 343 For example, the client's private Token Binding key must be kept 344 secret by the client. If the private key is not secret, then another 345 actor in the system could create a valid Token Binding header, 346 impersonating the client. This can render the main purpose of the 347 protocol - to bind bearer tokens to certain clients - moot: Consider, 348 for example, an attacker who obtained (perhaps through a network 349 intrusion) an authentication cookie that a client uses with a certain 350 server. Consider further that the server bound that cookie to the 351 client's Token Binding ID precisely to thwart cookie theft. If the 352 attacker were to come into possession of the client's private key, he 353 could then establish a TLS connection with the server and craft a 354 Token-Binding header that matches the binding present in the cookie, 355 thus successfully authenticating as the client, and gaining access to 356 the client's data at the server. The Token Binding protocol, in this 357 case, didn't successfully bind the cookie to the client. 359 Likewise, we need integrity protection of the Token-Binding header: A 360 client shouldn't be tricked into sending a Token-Binding header to a 361 server that contains Token Binding messages about key pairs that the 362 client doesn't control. Consider an attacker A that somehow has 363 knowledge of the exported keying material (EKM) for a TLS connection 364 between a client C and a server S. (While that is somewhat unlikely, 365 it's also not entirely out of the question, since the client might 366 not treat the EKM as a secret - after all, a pre-image-resistant hash 367 function has been applied to the TLS master secret, making it 368 impossible for someone knowing the EKM to recover the TLS master 369 secret. Such considerations might lead some clients to not treat the 370 EKM as a secret.) Such an attacker A could craft a Token-Binding 371 header with A's key pair over C's EKM. If the attacker could now 372 trick C to send such a header to S, it would appear to S as if C 373 controls a certain key pair when in fact it doesn't (the attacker A 374 controls the key pair). 376 If A has a pre-existing relationship with S (perhaps has an account 377 on S), it now appears to the server S as if A is connecting to it, 378 even though it is really C. (If the server S doesn't simply use 379 Token Binding keys to identify clients, but also uses bound 380 authentication cookies, then A would also have to trick C into 381 sending one of A's cookies to S, which it can do through a variety of 382 means - inserting cookies through Javascript APIs, setting cookies 383 through related-domain attacks, etc.) In other words, A tricked C 384 into logging into A's account on S. This could lead to a loss of 385 privacy for C, since A presumably has some other way to also access 386 the account, and can thus indirectly observe A's behavior (for 387 example, if S has a feature that lets account holders see their 388 activity history on S). 390 Therefore, we need to protect the integrity of the Token-Binding 391 header. One origin should not be able to set the Token-Binding 392 header (through a DOM API or otherwise) that the User Agent uses with 393 another origin. 395 4.5. Securing Federated Sign-On Protocols 397 As explained above, in a federated sign-in scenario a client will 398 prove possession of two different key pairs to a Token Provider: One 399 key pair is the "provided" Token Binding key pair (which the client 400 normally uses with the Token Provider), and the other is the 401 "referred" Token Binding key pair (which the client normally uses 402 with the Token Consumer). The Token Provider is expected to issue a 403 token that is bound to the referred Token Binding key. 405 Both proofs (that of the provided Token Binding key and that of the 406 referred Token Binding key) are necessary. To show this, consider 407 the following scenario: 409 o The client has an authentication token with the Token Provider 410 that is bound to the client's Token Binding key. 412 o The client wants to establish a secure (i.e., free of men-in-the- 413 middle) authenticated session with the Token Consumer, but hasn't 414 done so yet (in other words, we're about to run the federated 415 sign-on protocol). 417 o A man-in-the-middle is allowed to intercept the connection between 418 client and Token Consumer or between Client and Token Provider (or 419 both). 421 The goal is to detect the presence of the man-in-the-middle in these 422 scenarios. 424 First, consider a man-in-the-middle between the client and the Token 425 Provider. Recall that we assume that the client possesses a bound 426 authentication token (e.g., cookie) for the Token Provider. The man- 427 in-the-middle can intercept and modify any message sent by the client 428 to the Token Provider, and any message sent by the Token Provider to 429 the client. (This means, among other things, that the man-in-the- 430 middle controls the Javascript running at the client in the origin of 431 the Token Provider.) It is not, however, in possession of the 432 client's Token Binding key. Therefore, it can either choose to 433 replace the Token Binding key in requests from the client to the 434 Token Provider, and create a Token-Binding header that matches the 435 TLS connection between the man-in-the-middle and the Token Provider; 436 or it can choose to leave the Token-Binding header unchanged. If it 437 chooses the latter, the signature in the Token Binding message 438 (created by the original client on the exported keying material (EKM) 439 for the connection between client and man-in-the-middle) will not 440 match the EKM between man-in-the-middle and the Token Provider. If 441 it chooses the former (and creates its own signature, with its own 442 Token Binding key, over the EKM for the connection between man-in- 443 the-middle and Token Provider), then the Token Binding message will 444 match the connection between man-in-the-middle and Token Provider, 445 but the Token Binding key in the message will not match the Token 446 Binding key that the client's authentication token is bound to. 447 Either way, the man-in-the-middle is detected by the Token Provider, 448 but only if the proof of key possession of the provided Token Binding 449 key is required in the protocol (as we do above). 451 Next, consider the presence of a man-in-the-middle between client and 452 Token Consumer. That man-in-the-middle can intercept and modify any 453 message sent by the client to the Token Consumer, and any message 454 sent by the Token Consumer to the client. The Token Consumer is the 455 party that redirects the client to the Token Provider. In this case, 456 the man-in-the-middle controls the redirect URL, and can tamper with 457 any redirect URL issued by the Token Consumer (as well as with any 458 Javascript running in the origin of the Token Consumer). The goal of 459 the man-in-the-middle is to trick the Token Issuer to issue a token 460 bound to _its_ Token Binding key, not to the Token Binding key of the 461 legitimate client. To thwart this goal of the man-in-the-middle, the 462 client's referred Token Binding key must be communicated to the Token 463 Producer in a manner that can not be affected by the man-in-the- 464 middle (who, as we recall, can modify redirect URLs and Javascript at 465 the client). Including the referred Token Binding message in the 466 Token-Binding header (as opposed to, say, including the referred 467 Token Binding key in an application-level message as part of the 468 redirect URL) is one way to assure that the man-in-the-middle between 469 client and Token Consumer cannot affect the communication of the 470 referred Token Binding key to the Token Provider. 472 Therefore, the Token-Binding header in the federated sign-on use case 473 contains both, a proof of possession of the provided Token Binding 474 key, as well as a proof of possession of the referred Token Binding 475 key. 477 5. References 479 5.1. Normative References 481 [I-D.ietf-httpbis-header-compression] 482 Peon, R. and H. Ruellan, "HPACK - Header Compression for 483 HTTP/2", draft-ietf-httpbis-header-compression-12 (work in 484 progress), February 2015. 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 488 RFC2119, March 1997, 489 . 491 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 492 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 493 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ 494 RFC2616, June 1999, 495 . 497 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 498 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 499 for Transport Layer Security (TLS)", RFC 4492, DOI 500 10.17487/RFC4492, May 2006, 501 . 503 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 504 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 505 DOI 10.17487/RFC5226, May 2008, 506 . 508 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 509 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 510 RFC5246, August 2008, 511 . 513 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 514 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 515 March 2010, . 517 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 518 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 519 . 521 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 522 "Transport Layer Security (TLS) Application-Layer Protocol 523 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 524 July 2014, . 526 [TBPROTO] Popov, A., "The Token Binding Protocol Version 1.0", 2014. 528 5.2. Informative References 530 [I-D.ietf-httpbis-http2] 531 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 532 Protocol version 2", draft-ietf-httpbis-http2-17 (work in 533 progress), February 2015. 535 [I-D.ietf-tls-session-hash] 536 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 537 A., and M. Ray, "Transport Layer Security (TLS) Session 538 Hash and Extended Master Secret Extension", draft-ietf- 539 tls-session-hash-06 (work in progress), July 2015. 541 [TRIPLE-HS] 542 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 543 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 544 Breaking and Fixing Authentication over TLS. IEEE 545 Symposium on Security and Privacy", 2014. 547 Authors' Addresses 549 Andrei Popov 550 Microsoft Corp. 551 USA 553 Email: andreipo@microsoft.com 555 Magnus Nystroem 556 Microsoft Corp. 557 USA 559 Email: mnystrom@microsoft.com 561 Dirk Balfanz (editor) 562 Google Inc. 563 USA 565 Email: balfanz@google.com 566 Adam Langley 567 Google Inc. 568 USA 570 Email: agl@google.com