idnits 2.17.1 draft-ietf-tokbind-tls13-0rtt-01.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 (March 13, 2017) is 2594 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-19 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-07 == Outdated reference: A later version (-19) exists of draft-ietf-tokbind-protocol-13 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 March 13, 2017 5 Expires: September 14, 2017 7 Token Binding for 0-RTT TLS 1.3 Connections 8 draft-ietf-tokbind-tls13-0rtt-01 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 updating how Token 14 Binding negotiation works and adding a mechanism for indicating 15 whether a server prevents replay. A TokenBindingMessage sent in 16 0-RTT data has different security properties than one sent after the 17 TLS handshake has finished, which 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 September 14, 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 . . . . . . . . . . . . . . . . . . 2 55 2. Proposed Design . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. TokenBinding Signature Definition . . . . . . . . . . . . 3 57 2.1.1. Selecting Which Exporter Secret to Use . . . . . . . 3 58 2.2. Negotiating Token Binding . . . . . . . . . . . . . . . . 4 59 2.2.1. Negotiation TLS Extension . . . . . . . . . . . . . . 4 60 2.2.2. Replay Protection Indication Extension . . . . . . . 4 61 3. Implementation Challenges . . . . . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 5.1. Proof of Possession of Token Binding Key . . . . . . . . 6 65 5.2. Attacks on PSK-only Key Exchange and Token Binding . . . 6 66 5.3. Exporter Replayability . . . . . . . . . . . . . . . . . 7 67 5.4. Replay Mitigations . . . . . . . . . . . . . . . . . . . 7 68 5.4.1. Server Mitigations . . . . . . . . . . . . . . . . . 8 69 5.4.2. Client Mitigations . . . . . . . . . . . . . . . . . 8 70 5.5. Early Data Ticket Age Window . . . . . . . . . . . . . . 8 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Token Binding ([I-D.ietf-tokbind-protocol]) cryptographically binds 78 security tokens (e.g. HTTP cookies, OAuth tokens) to the TLS layer 79 on which they are presented. It does so by signing an [RFC5705] 80 exporter value from the TLS connection. TLS 1.3 introduces a new 81 mode that allows a client to send application data on its first 82 flight. If this 0-RTT data contains a security token, then a client 83 using Token Binding would want to prove possession of its Token 84 Binding private key so that the server can verify the binding. The 85 [RFC5705]-style exporter provided by TLS 1.3 cannot be run until the 86 handshake has finished. TLS 1.3 also provides an exporter that can 87 be used with 0-RTT data, but it requires that the application 88 explicitly specify that use. This document specifies how to use the 89 early_exporter_secret with Token Binding in TLS 1.3 0-RTT data. 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Proposed Design 99 A TokenBinding struct as defined in [I-D.ietf-tokbind-protocol] 100 contains a signature of the EKM value from the TLS layer. Under 101 normal circumstances, a TokenBinding on a TLS 1.3 connection would 102 use the exporter_secret to derive the EKM value. When 0-RTT data is 103 assembled to be sent, the exporter_secret is not yet available. This 104 design changes the definition of the TokenBinding.signature field to 105 use the exporter with either early_exporter_secret or 106 exporter_secret. Since no negotiation for the connection can happen 107 before the client sends this TokenBindingMessage in 0-RTT data, this 108 document also describes how a client decides what TokenBindingMessage 109 to send in 0-RTT data and how a server should interpret that message. 111 If a client does not send any 0-RTT data, or if the server rejects 112 the client's 0-RTT data, then the client MUST use the 1-RTT exporter, 113 as defined in [I-D.ietf-tokbind-protocol]. 115 2.1. TokenBinding Signature Definition 117 In [I-D.ietf-tokbind-protocol], the signature field of the 118 TokenBinding struct is defined to be the signature of a 119 concatentation that includes the EKM value. Depending on the 120 circumstances, the exporter value in section 7.3.3 of 121 [I-D.ietf-tls-tls13] is computed using either exporter_secret or 122 early_exporter_secret as the Secret. 124 When early_exporter_secret is used as the Secret, the client MUST 125 indicate this use so the server knows which secret to use in 126 signature verification. This indication is done through a new Token 127 Binding extension, "early_exporter" (with extension type TBD). This 128 extension always has 0-length data, so the full Extension struct is 129 the bytes {0xTBD, 0x00, 0x00}. The early_exporter extension MUST be 130 present in every TokenBinding struct where the exporter that is 131 signed uses the early_exporter_secret, and it MUST NOT be present in 132 any other TokenBinding structs. 134 2.1.1. Selecting Which Exporter Secret to Use 136 A client which is not sending any 0-RTT data on a connection MUST use 137 the exporter defined in [I-D.ietf-tls-tls13] (using exporter_secret 138 as the Secret) for all TokenBindingMessages on that connection so 139 that it is compatible with [I-D.ietf-tokbind-protocol]. 141 When a client sends a TokenBindingMessage in 0-RTT data, it must use 142 the early_exporter_secret. After the client receives an application- 143 layer response from the server, it must use the exporter_secret for 144 all future token bindings on that connection. Requests sent after 145 the client's TLS Finished message, but before the client processes 146 any application-layer response from the server, may use either 147 exporter secret in their token bindings. 149 A server may choose to reject an application message containing a 150 Token Binding that uses the early_exporter_secret. If it chooses to 151 do so, it may send an application message indicating that the client 152 should re-send the request (with a new Token Binding). In HTTP, this 153 could be done with a 307 status code. 155 2.2. Negotiating Token Binding 157 2.2.1. Negotiation TLS Extension 159 The behavior of the Token Binding negotiation TLS extension does not 160 change for a 0-RTT connection: the client and server should process 161 this extension the same way regardless of whether the client also 162 sent the EarlyDataIndication extension. 164 For the sake of choosing a key parameter to use in 0-RTT data, the 165 client MUST use the same key parameter that was used on the 166 connection during which the ticket (now being used for resumption) 167 was established. The server MUST NOT accept early data if the 168 negotiated Token Binding key parameter does not match the parameter 169 from the initial connection. This is the same behavior as ALPN and 170 SNI extensions. 172 If 0-RTT data is being sent with Token Binding using a PSK obtained 173 out-of-band, then the Token Binding key parameter to use with that 174 PSK must also be provisioned to both parties, and only that key 175 parameter must be used with that PSK. 177 2.2.2. Replay Protection Indication Extension 179 The signed exporter value used in a 0-RTT connection is not 180 guaranteed to be unique to the connection, so an attacker may be able 181 to replay the signature without having possession of the private key. 182 To combat this attack, a server may implement some sort of replay 183 prevention, and indicate this to the client. A new TLS extension 184 "token_binding_replay_indication" is defined for the client to query 185 and server to indicate whether it has implemented a mechanism to 186 prevent replay. 188 enum { 189 token_binding_replay_indication(TBD), (65535) 190 } ExtensionType; 191 When sent, this extension always has zero length. If a client wishes 192 to know whether its peer is preventing replay of TokenBinding structs 193 across multiple connections, the client can include this extension in 194 its ClientHello. Upon receiving this extension, the server must echo 195 it back if it is using such a mechanism (like those described in 196 Section 5.4.1) to prevent replay. A client that only wishes to send 197 0-RTT Token Binding if the server implements replay protection can 198 send this extension on first connection establishment, and if the 199 server doesn't send it back (but does support Token Binding) the 200 client can choose to not send 0-RTT messages to that server. 202 A client that wishes to use this extension should send it every time 203 it sends a "token_binding" [I-D.ietf-tokbind-negotiation] extension. 205 3. Implementation Challenges 207 The client has to be able to modify the message it sends in 0-RTT 208 data if the 0-RTT data gets rejected and needs to be retransmitted in 209 1-RTT data. Even if the Token Binding integration with 0-RTT were 210 modified so that Token Binding never caused a 0-RTT reject that 211 required rewriting a request, the client still has to handle the 212 server rejecting the 0-RTT data for other reasons. 214 HTTP2 allows for requests to different domains to share the same TLS 215 connection if the SAN of the cert covers those domains. If 216 one.example.com supports 0-RTT and Token Binding, but two.example.com 217 only supports Token Binding as defined in 218 [I-D.ietf-tokbind-protocol], those servers cannot share a cert and 219 use HTTP2. 221 4. IANA Considerations 223 This document defines a new TLS extension 224 "token_binding_replay_indication", which needs to be added to the 225 IANA "Transport Layer Security (TLS) Extensions" registry. 227 This document defines a new Token Binding extension "early_exporter", 228 which needs to be added to the IANA "Token Binding Extensions" 229 registry. 231 5. Security Considerations 233 Token Binding messages that use the 0-RTT exporter have weaker 234 security properties than with the [RFC5705] exporter. If either 235 party of a connection using Token Binding does not wish to use 0-RTT 236 token bindings, they can do so: a client can choose to never send 237 0-RTT data on a connection where it uses token binding, and a server 238 can choose to reject any 0-RTT data sent on a connection that 239 negotiated token binding. 241 0-RTT data in TLS 1.3 has weaker security properties than other kinds 242 of TLS data. Specifically, TLS 1.3 does not guarantee non- 243 replayability of data between connections. Token Binding has similar 244 replayability issues when in 0-RTT data, but preventing replay of 245 Token Binding and preventing replay of 0-RTT data are two separate 246 problems. Token Binding is not designed to prevent replay of 0-RTT 247 data, although solutions for preventing the replay of Token Binding 248 might also be applicable to 0-RTT data. 250 5.1. Proof of Possession of Token Binding Key 252 When a Token Binding signature is generated using the exporter with 253 early_exporter_secret, the value being signed is under the client's 254 control. An attacker with temporary access to the Token Binding 255 private key can generate Token Binding signatures for as many future 256 connections as it has NewSessionTickets for. An attacker can 257 construct these to be usable at any time in the future up until the 258 NewSessionTicket's expiration. Section 4.6.1 of [I-D.ietf-tls-tls13] 259 requires that a NewSessionTicket be valid for a maximum of 7 days. 261 Unlike in [I-D.ietf-tokbind-protocol], where the proof of possession 262 of the Token Binding key proves that the client had possession at the 263 time the TLS handshake finished, 0-RTT Token Binding only proves that 264 the client had possession of the Token Binding key at some point 265 after receiving the NewSessionTicket used for that connection. 267 5.2. Attacks on PSK-only Key Exchange and Token Binding 269 An attacker who possesses the PSK can eavesdrop on an existing 270 connection that uses that PSK to obtain a TokenBindingMessage that is 271 valid on the connection and then hijack the connection to send 272 whatever attacker-controlled data it wishes. Because the regular 273 exporter closes over the server random, this TokenBindingMessage is 274 valid only for that connection. 276 If the attacker does the same thing with a pure-PSK connection and 277 0-RTT Token Binding, the attacker can replay the original ClientHello 278 and the exporter will stay the same, allowing the attacker to obtain 279 a TokenBindingMessage from one connection and replay it on future 280 connections. The only way for a server to prevent this replay is to 281 prevent the client from ever repeating a client random in the 282 handshake. 284 If a server accepting connections with PSK-only key establishment is 285 concerned about the threat of PSK theft and also implements Token 286 Binding, then that server must either reject all 0-RTT token 287 bindings, or implement some form of preventing reuse of a client 288 random. 290 5.3. Exporter Replayability 292 The exporter specified in [I-D.ietf-tokbind-protocol] is chosen so 293 that a client and server have the same exporter value only if they 294 are on the same TLS connection. This prevents an attacker who can 295 read the plaintext of a TokenBindingMessage sent on that connection 296 from replaying that message on another connection (without also 297 having the token binding private key). The 0-RTT exporter only 298 covers the ClientHello and the PSK of the connection, so it does not 299 provide this guarantee. 301 An attacker with possession of the PSK secret and a transcript of the 302 ClientHello and early data sent by a client under that PSK can 303 extract the TokenBindingMessage, create a new connection to the 304 server (using the same ClientHello and PSK), and send different 305 application data with the same TokenBindingMessage. Note that the 306 ClientHello contains public values for the (EC)DHE key agreement that 307 is used as part of deriving the traffic keys for the TLS connection, 308 so if the attacker does not also have the corresponding private 309 values, they will not be able to read the server's response or send a 310 valid Finished message in the handshake for this TLS connection. 311 Nevertheless, by that point the server has already processed the 312 attacker's message with the replayed TokenBindingMessage. 314 This sort of replayability of a TokenBindingMessage is different than 315 the replayability caveat of 0-RTT application data in TLS 1.3. A 316 network observer can replay 0-RTT data from TLS 1.3 without knowing 317 any secrets of the client or server, but the application data that is 318 replayed is untouched. This replay is done by a more powerful 319 attacker who is able to view the plaintext and then spoof a 320 connection with the same parameters so that the replayed 321 TokenBindingMessage still validates when sent with different 322 application data. 324 5.4. Replay Mitigations 326 This section presents multiple ways that a client or server can 327 prevent the replay of a TokenBinding while still using Token Binding 328 with 0-RTT data. 330 If a client or server implements a measure that prevents all replays, 331 then its peer does not also need to implement such a mitigation. A 332 client that is concerned about replay SHOULD implement a replay 333 mitigation instead of relying solely on a signal from the server 334 through the replay indication extension. Note that even with replay 335 mitigations, 0-RTT Token Binding is vulnerable to other attacks. 337 5.4.1. Server Mitigations 339 If a server uses a session cache instead of stateless tickets, it can 340 enforce that a PSK generated for resumption can only be used once. 341 If an attacker tries to replay 0-RTT data (with a 342 TokenBindingMessage), the server will reject it because the PSK was 343 already used. 345 Preventing all replay of 0-RTT data is not necessary to prevent 346 replay of a TokenBinding. A server could implement a mechanism to 347 prevent a particular TokenBinding from being presented on more than 348 one connection. In cases where a server's TLS termination and 349 application layer processing happen in different locations, this 350 option might be easier to implement, especially when not all requests 351 have bound tokens. This processing can also take advantage of the 352 structure of the bound token, e.g. a token that identifies which user 353 is making a request could shard its store of which TokenBindings have 354 been seen based on the user ID. 356 A server can prevent some, but not all, 0-RTT data replay with a 357 tight time window for the ticket age that it will accept. See 358 Section 5.5 for more details. 360 5.4.2. Client Mitigations 362 A client cannot prevent a sufficiently motivated attacker from 363 replaying a TokenBinding, but it can make it so difficult to replay 364 the TokenBinding that it is easier for the attacker to steal the 365 Token Binding key directly. If the client secures the resumption 366 secret with the same level of protection as the Token Binding key, 367 then the client has made it not worth the effort of the attacker to 368 attempt to replay a TokenBinding. Ideally the resumption secret (and 369 Token Binding key) are protected strongly and virtually non- 370 exportable. 372 5.5. Early Data Ticket Age Window 374 When an attacker with control of the PSK secret replays a 375 TokenBindingMessage, it has to use the same ClientHello that the 376 client used. The ClientHello includes an "obfuscated_ticket_age" in 377 its EarlyDataIndication extension, which the server can use to narrow 378 the window in which that ClientHello will be accepted. Even if a PSK 379 is valid for a week, the server will only accept that particular 380 ClientHello for a smaller time window based on the ticket age. A 381 server should make their acceptance window for this value as small as 382 practical to limit an attacker's ability to replay a ClientHello and 383 send new application data with the stolen TokenBindingMessage. 385 6. Acknowledgements 387 The author would like to thank David Benjamin, Steven Valdez, Bill 388 Cox, and Andrei Popov for their feedback and suggestions. 390 7. Normative References 392 [I-D.ietf-tls-tls13] 393 Rescorla, E., "The Transport Layer Security (TLS) Protocol 394 Version 1.3", draft-ietf-tls-tls13-19 (work in progress), 395 March 2017. 397 [I-D.ietf-tokbind-negotiation] 398 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 399 "Transport Layer Security (TLS) Extension for Token 400 Binding Protocol Negotiation", draft-ietf-tokbind- 401 negotiation-07 (work in progress), February 2017. 403 [I-D.ietf-tokbind-protocol] 404 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 405 Hodges, "The Token Binding Protocol Version 1.0", draft- 406 ietf-tokbind-protocol-13 (work in progress), February 407 2017. 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, 411 DOI 10.17487/RFC2119, March 1997, 412 . 414 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 415 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 416 March 2010, . 418 Author's Address 420 Nick Harper 421 Google Inc. 423 Email: nharper@google.com