idnits 2.17.1 draft-ietf-tokbind-tls13-0rtt-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2017) is 2466 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-08 == Outdated reference: A later version (-19) exists of draft-ietf-tokbind-protocol-14 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Token Binding Working Group N. Harper 3 Internet-Draft Google Inc. 4 Intended status: Standards Track June 28, 2017 5 Expires: December 30, 2017 7 Token Binding for 0-RTT TLS 1.3 Connections 8 draft-ietf-tokbind-tls13-0rtt-02 10 Abstract 12 This document describes how Token Binding can be used in the 0-RTT 13 data of a TLS 1.3 connection. This involves a new TLS extension to 14 negotiate and indicate the use of Token Binding in 0-RTT data. A 15 TokenBindingMessage sent in 0-RTT data has different security 16 properties than one sent after the TLS handshake has finished, which 17 this document also describes. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 30, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. TokenBinding Signature Definition . . . . . . . . . . . . . . 3 56 2.1. Selecting Which Exporter Secret to Use . . . . . . . . . 3 57 3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Indicating Use of 0-RTT Token Binding . . . . . . . . . . 4 59 3.2. Token Binding Negotiation TLS Extension . . . . . . . . . 4 60 3.3. Client Processing Rules . . . . . . . . . . . . . . . . . 4 61 3.4. Server Processing Rules . . . . . . . . . . . . . . . . . 5 62 4. Implementation Considerations . . . . . . . . . . . . . . . . 6 63 4.1. Not Implementing Token Binding on 0-RTT Connections . . . 6 64 4.2. Adding Support for Token Binding on 0-RTT Connections . . 7 65 4.3. Implementation Challenges . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6.1. Proof of Possession of Token Binding Key . . . . . . . . 8 69 6.2. Exporter Replayability . . . . . . . . . . . . . . . . . 8 70 6.3. Replay Mitigations . . . . . . . . . . . . . . . . . . . 9 71 6.3.1. Server Mitigations . . . . . . . . . . . . . . . . . 9 72 6.3.2. Client Mitigations . . . . . . . . . . . . . . . . . 10 73 6.4. Early Data Ticket Age Window . . . . . . . . . . . . . . 10 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 75 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 Token Binding ([I-D.ietf-tokbind-protocol]) cryptographically binds 81 security tokens (e.g. HTTP cookies, OAuth tokens) to the TLS layer 82 on which they are presented. It does so by signing an [RFC5705] 83 exporter value from the TLS connection. TLS 1.3 introduces a new 84 mode that allows a client to send application data on its first 85 flight. If this 0-RTT data contains a security token, then a client 86 using Token Binding would want to prove possession of its Token 87 Binding private key so that the server can verify the binding. The 88 [RFC5705]-style exporter provided by TLS 1.3 cannot be run until the 89 handshake has finished. TLS 1.3 also provides an exporter that can 90 be used with 0-RTT data, but it requires that the application 91 explicitly specify that use. This document specifies how to use the 92 early_exporter_secret with Token Binding in TLS 1.3 0-RTT data. 94 Using Token Binding in 0-RTT data involves two main changes to Token 95 Binding. The first is the use of a new TLS extension 96 "early_token_binding" to indicate whether a TLS session ticket can be 97 used with Token Binding in 0-RTT data, and to indicate whether an 98 attempted 0-RTT connection is using Token Binding in 0-RTT data. The 99 second change is one that applies only if Token Binding in 0-RTT data 100 is in use, which changes the definition of the TokenBinding.signature 101 field to use TLS 1.3's early_exporter_secret. 103 If a client does not send any 0-RTT data, or if the server rejects 104 the client's 0-RTT data, then the client MUST use the 1-RTT exporter, 105 as defined in [I-D.ietf-tokbind-protocol]. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. TokenBinding Signature Definition 115 In [I-D.ietf-tokbind-protocol], the signature field of the 116 TokenBinding struct is defined to be the signature of a 117 concatentation that includes the EKM value. Depending on the 118 circumstances, the exporter value in section 7.3.3 of 119 [I-D.ietf-tls-tls13] is computed using either exporter_secret or 120 early_exporter_secret as the Secret. 122 When early_exporter_secret is used as the Secret, the client MUST 123 indicate this use so the server knows which secret to use in 124 signature verification. This indication is done through a new Token 125 Binding extension, "early_exporter" (with extension type TBD). This 126 extension always has 0-length data, so the full Extension struct is 127 the bytes {0xTBD, 0x00, 0x00}. The early_exporter extension MUST be 128 present in every TokenBinding struct where the exporter that is 129 signed uses the early_exporter_secret, and it MUST NOT be present in 130 any other TokenBinding structs. 132 2.1. Selecting Which Exporter Secret to Use 134 A client which is not sending any 0-RTT data on a connection MUST use 135 the exporter defined in [I-D.ietf-tls-tls13] (using exporter_secret 136 as the Secret) for all TokenBindingMessages on that connection so 137 that it is compatible with [I-D.ietf-tokbind-protocol]. 139 When a client sends a TokenBindingMessage in 0-RTT data, it must use 140 the early_exporter_secret. If the server accepts the 0-RTT data, the 141 client must continue to use the early_exporter_secret for the rest of 142 the connection. If the server rejects 0-RTT data, the client must 143 use the exporter_secret. 145 3. Negotiation 147 3.1. Indicating Use of 0-RTT Token Binding 149 The TLS extension "early_token_binding" (extension type TBD) is used 150 in the TLS ClientHello and EncryptedExtensions to indicate use of 151 0-RTT Token Binding on the current connection. It is also used in a 152 NewSessionTicket message to indicate that 0-RTT Token Binding may be 153 used on a connection resumed with that ticket. In all cases, the 154 "extension_data" field of this extension is empty, so the entire 155 encoding of this extension is 0xTBD 0xTBD 0x00 0x00. 157 3.2. Token Binding Negotiation TLS Extension 159 In TLS 1.3, the "token_binding" extension is sent by a server in 160 EncryptedExtensions, whereas in previous versions of TLS this 161 extension was sent in the ServerHello message. On a 1-RTT connection 162 (whether it be a new connection or resumption), no application data 163 is sent in either direction before the "token_binding" TLS extension 164 in the EncryptedExtensions, and the choice of Token Binding version 165 and key parameter is up to the server based on what the client sent 166 and what the server's preferences are, following the same processing 167 rules as in [I-D.ietf-tokbind-negotiation]. 169 3.3. Client Processing Rules 171 A client that supports Token Binding in 0-RTT data and receives a 172 NewSessionTicket containing the "early_token_binding" extension must 173 store with the ticket the Token Binding version and key parameter of 174 the connection in which the ticket was issued. 176 A client that wishes to send a Token Binding message in 0-RTT data 177 may only do so if the TLS connection in which the 0-RTT data is being 178 sent is being resumed from a ticket which included the 179 "early_token_binding" extension. Assuming the ticket included this 180 extension, the client sends a ClientHello containing the 181 "token_binding" extension, "early_data" extension, and 182 "early_token_binding" extensions. The client must include in its 183 "psk_key_exchange_modes" extension psk_dhe_ke. 185 The contents of the "token_binding" extension SHOULD be the same as 186 they would be on a connection without "early_token_binding" to allow 187 for the client and server to negotiate new Token Binding parameters 188 if the early data is rejected. The Token Binding message sent in the 189 0-RTT data MUST be sent assuming that the same Token Binding version 190 and key parameter from the connection where the ticket was received 191 will also be negotiated on this connection. If the server includes 192 the "early_data" extension in EncryptedExtensions in response to a 193 ClientHello with "early_token_binding", but the server does not 194 include "early_token_binding" in EncryptedExtensions, or if the 195 server's "token_binding" extension does not match the values of the 196 connection where the ticket was received, then the client MUST 197 terminate the TLS connection with an illegal_parameter alert. 199 It is valid for a client to send a ClientHello that contains both the 200 "early_data" and "token_binding" extensions, but without the 201 "early_token_binding" extension. This combination means that the 202 client is attempting to resume a connection and is sending early 203 data, but the client is not using Token Binding on this resumed 204 connection (if the server accepts the early data). The presence of 205 the "token_binding" extension is so the client can negotiate the use 206 of Token Binding for this connection if the server rejects early 207 data. 209 3.4. Server Processing Rules 211 When a server issues a NewSessionTicket on a connection where Token 212 Binding was negotiated, and the NewSessionTicket includes an 213 "early_data" extension indicating that the ticket may be used to send 214 0-RTT data, the server may also include the "early_token_binding" 215 extension in the NewSessionTicket to indicate that this ticket can be 216 used for a future connection with Token Binding in 0-RTT data. If 217 the server includes the "early_token_binding" extension in the 218 NewSessionTicket, the server MUST store with the ticket the Token 219 Binding version and key parameter used for the connection in which 220 the ticket was issued. The "early_token_binding" extension can 221 appear in a NewSessionTicket message only if the "early_data" 222 extension also appears in that message. 224 If a server receives a ClientHello with the "early_token_binding" 225 extension and supports Token Binding in 0-RTT data, it MUST perform 226 the following checks: 228 o If either the "early_data" or "token_binding" extensions are 229 missing from the ClientHello, terminate the TLS connection with an 230 illegal_parameter alert. 232 o If the ticket used for resumption is missing either of the 233 "early_data" or "early_token_binding" extensions, reject the early 234 data. 236 o Process the "token_binding" extension as if it were received on a 237 1-RTT connection and compute the Token Binding version and key 238 parameter to use. If either of these values do not match the 239 values that were negotiated on the connection where the ticket 240 used for resumption was sent, reject the early data. 242 o Perform any other checks to decide whether to accept early data. 243 If the server chooses to accept early data, include in 244 EncryptedExtensions the "early_data" extension, 245 "early_token_binding" extension, and "token_binding" extension 246 with the same version and key parameter from the previous 247 connection. 249 If a server accepts early data on a connection where 250 "early_token_binding" was offered, it MUST use PSK with (EC)DHE key 251 establishment. 253 The "early_token_binding" extension must be present in 254 EncryptedExtensions exactly when both "early_data" and 255 "token_binding" are present. A server that receives a ClientHello 256 with "early_token_binding" cannot reject Token Binding and also 257 accept early data at the same time. Said server may reject early 258 data but still negotiate Token Binding. 260 A server might receive a ClientHello that includes both the 261 "early_data" and "token_binding" extensions, but no 262 "early_token_binding" extension. In this case, the server has three 263 options: 265 1. Accept early data and continue the connection with no Token 266 Binding, 268 2. Reject early data and negotiate the use of Token Binding for this 269 connection, or 271 3. Reject early data and do not negotiate Token Binding for this 272 connection. 274 The behavior for the "token_binding" extension in 0-RTT is similar to 275 that of ALPN and SNI: the client predicts the result of the 276 negotiation, and if the actual negotiation differs, the server 277 rejects the early data. 279 4. Implementation Considerations 281 4.1. Not Implementing Token Binding on 0-RTT Connections 283 This spec has been designed so that both clients and servers can 284 support Token Binding on some connections and 0-RTT data on other 285 connections without needing to support Token Binding on 0-RTT 286 connections. 288 A client that wishes to support both without supporting Token Binding 289 on 0-RTT connections can function by completely ignoring the 290 "early_token_binding" TLS extension. When resuming a connection with 291 early data, the client can still advertise support for Token Binding, 292 providing the server the opportunity to accept early data (without 293 Token Binding) or to reject early data and negotiate Token Binding. 294 By always including the "token_binding" extension in its ClientHello, 295 the client can prioritize Token Binding over 0-RTT. 297 A server can support both Token Binding and 0-RTT data without 298 supporting Token Binding on 0-RTT connections by never minting 299 NewSessionTickets containing the "early_token_binding" extension. 300 Such a server that never mints NewSessionTickets with 301 "early_token_binding" can ignore that extension in a ClientHello as 302 it would only appear if the client is not spec compliant. On 303 connections where a server negotiates Token Binding, the server 304 SHOULD NOT include the "early_data" extension in a NewSessionTicket. 306 4.2. Adding Support for Token Binding on 0-RTT Connections 308 A server that supports early data but not Token Binding may wish to 309 add support for Token Binding (and Token Binding on 0-RTT 310 connections) at a later time. For a client to learn that a server 311 supports Token Binding, the server must reject early data to send the 312 "token_binding" extension. 314 4.3. Implementation Challenges 316 The client has to be able to modify the message it sends in 0-RTT 317 data if the 0-RTT data gets rejected and needs to be retransmitted in 318 1-RTT data. Even if the Token Binding integration with 0-RTT were 319 modified so that Token Binding never caused a 0-RTT reject that 320 required rewriting a request, the client still has to handle the 321 server rejecting the 0-RTT data for other reasons. 323 HTTP2 allows for requests to different domains to share the same TLS 324 connection if the SAN of the cert covers those domains. If 325 one.example.com supports 0-RTT and Token Binding, but two.example.com 326 only supports Token Binding as defined in 327 [I-D.ietf-tokbind-protocol], those servers cannot share a cert and 328 use HTTP2. 330 5. IANA Considerations 332 This document defines a new TLS extension "early_token_binding" with 333 code point TBD which needs to be added to IANA's TLS "ExtensionType 334 Values" registry. 336 This document defines a new Token Binding extension "early_exporter", 337 which needs to be added to the IANA "Token Binding Extensions" 338 registry. 340 6. Security Considerations 342 Token Binding messages that use the 0-RTT exporter have weaker 343 security properties than with the [RFC5705] exporter. If either 344 party of a connection using Token Binding does not wish to use 0-RTT 345 token bindings, they can do so: a client can choose to never send 346 0-RTT data on a connection where it uses token binding, and a server 347 can choose to reject any 0-RTT data sent on a connection that 348 negotiated token binding. 350 0-RTT data in TLS 1.3 has weaker security properties than other kinds 351 of TLS data. Specifically, TLS 1.3 does not guarantee non- 352 replayability of data between connections. Token Binding has similar 353 replayability issues when in 0-RTT data, but preventing replay of 354 Token Binding and preventing replay of 0-RTT data are two separate 355 problems. Token Binding is not designed to prevent replay of 0-RTT 356 data, although solutions for preventing the replay of Token Binding 357 might also be applicable to 0-RTT data. 359 6.1. Proof of Possession of Token Binding Key 361 When a Token Binding signature is generated using the exporter with 362 early_exporter_secret, the value being signed is under the client's 363 control. An attacker with temporary access to the Token Binding 364 private key can generate Token Binding signatures for as many future 365 connections as it has NewSessionTickets for. An attacker can 366 construct these to be usable at any time in the future up until the 367 NewSessionTicket's expiration. Section 4.6.1 of [I-D.ietf-tls-tls13] 368 requires that a NewSessionTicket be valid for a maximum of 7 days. 370 Unlike in [I-D.ietf-tokbind-protocol], where the proof of possession 371 of the Token Binding key proves that the client had possession at the 372 time the TLS handshake finished, 0-RTT Token Binding only proves that 373 the client had possession of the Token Binding key at some point 374 after receiving the NewSessionTicket used for that connection. 376 6.2. Exporter Replayability 378 The exporter specified in [I-D.ietf-tokbind-protocol] is chosen so 379 that a client and server have the same exporter value only if they 380 are on the same TLS connection. This prevents an attacker who can 381 read the plaintext of a TokenBindingMessage sent on that connection 382 from replaying that message on another connection (without also 383 having the token binding private key). The 0-RTT exporter only 384 covers the ClientHello and the PSK of the connection, so it does not 385 provide this guarantee. 387 An attacker with possession of the PSK secret and a transcript of the 388 ClientHello and early data sent by a client under that PSK can 389 extract the TokenBindingMessage, create a new connection to the 390 server (using the same ClientHello and PSK), and send different 391 application data with the same TokenBindingMessage. Note that the 392 ClientHello contains public values for the (EC)DHE key agreement that 393 is used as part of deriving the traffic keys for the TLS connection, 394 so if the attacker does not also have the corresponding private 395 values, they will not be able to read the server's response or send a 396 valid Finished message in the handshake for this TLS connection. 397 Nevertheless, by that point the server has already processed the 398 attacker's message with the replayed TokenBindingMessage. 400 This sort of replayability of a TokenBindingMessage is different than 401 the replayability caveat of 0-RTT application data in TLS 1.3. A 402 network observer can replay 0-RTT data from TLS 1.3 without knowing 403 any secrets of the client or server, but the application data that is 404 replayed is untouched. This replay is done by a more powerful 405 attacker who is able to view the plaintext and then spoof a 406 connection with the same parameters so that the replayed 407 TokenBindingMessage still validates when sent with different 408 application data. 410 6.3. Replay Mitigations 412 This section presents multiple ways that a client or server can 413 mitigate the replay of a TokenBinding while still using Token Binding 414 with 0-RTT data. Note that even with replay mitigations, 0-RTT Token 415 Binding is vulnerable to other attacks. 417 6.3.1. Server Mitigations 419 If a server uses a session cache instead of stateless tickets, it can 420 enforce that a PSK generated for resumption can only be used once. 421 If an attacker tries to replay 0-RTT data (with a 422 TokenBindingMessage), the server will reject it because the PSK was 423 already used. 425 Preventing all replay of 0-RTT data is not necessary to prevent 426 replay of a TokenBinding. A server could implement a mechanism to 427 prevent a particular TokenBinding from being presented on more than 428 one connection. In cases where a server's TLS termination and 429 application layer processing happen in different locations, this 430 option might be easier to implement, especially when not all requests 431 have bound tokens. This processing can also take advantage of the 432 structure of the bound token, e.g. a token that identifies which user 433 is making a request could shard its store of which TokenBindings have 434 been seen based on the user ID. 436 A server can prevent some, but not all, 0-RTT data replay with a 437 tight time window for the ticket age that it will accept. See 438 Section 6.4 for more details. 440 6.3.2. Client Mitigations 442 A client cannot prevent a sufficiently motivated attacker from 443 replaying a TokenBinding, but it can make it so difficult to replay 444 the TokenBinding that it is easier for the attacker to steal the 445 Token Binding key directly. If the client secures the resumption 446 secret with the same level of protection as the Token Binding key, 447 then the client has made it not worth the effort of the attacker to 448 attempt to replay a TokenBinding. Ideally the resumption secret (and 449 Token Binding key) are protected strongly and virtually non- 450 exportable. 452 6.4. Early Data Ticket Age Window 454 When an attacker with control of the PSK secret replays a 455 TokenBindingMessage, it has to use the same ClientHello that the 456 client used. The ClientHello includes an "obfuscated_ticket_age" in 457 its EarlyDataIndication extension, which the server can use to narrow 458 the window in which that ClientHello will be accepted. Even if a PSK 459 is valid for a week, the server will only accept that particular 460 ClientHello for a smaller time window based on the ticket age. A 461 server should make their acceptance window for this value as small as 462 practical to limit an attacker's ability to replay a ClientHello and 463 send new application data with the stolen TokenBindingMessage. 465 7. Acknowledgements 467 The author would like to thank David Benjamin, Steven Valdez, Bill 468 Cox, and Andrei Popov for their feedback and suggestions. 470 8. Normative References 472 [I-D.ietf-tls-tls13] 473 Rescorla, E., "The Transport Layer Security (TLS) Protocol 474 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 475 April 2017. 477 [I-D.ietf-tokbind-negotiation] 478 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 479 "Transport Layer Security (TLS) Extension for Token 480 Binding Protocol Negotiation", draft-ietf-tokbind- 481 negotiation-08 (work in progress), April 2017. 483 [I-D.ietf-tokbind-protocol] 484 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 485 Hodges, "The Token Binding Protocol Version 1.0", draft- 486 ietf-tokbind-protocol-14 (work in progress), April 2017. 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, 490 DOI 10.17487/RFC2119, March 1997, 491 . 493 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 494 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 495 March 2010, . 497 Author's Address 499 Nick Harper 500 Google Inc. 502 Email: nharper@google.com