idnits 2.17.1 draft-nharper-0-rtt-token-binding-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 (November 14, 2016) is 2713 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-18 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-05 == Outdated reference: A later version (-19) exists of draft-ietf-tokbind-protocol-10 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 November 14, 2016 5 Expires: May 18, 2017 7 Token Binding for 0-RTT TLS 1.3 Connections 8 draft-nharper-0-rtt-token-binding-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 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 May 18, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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. Proposed Design . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. TokenBinding Signature Definition . . . . . . . . . . . . 3 57 2.2. Negotiating Token Binding . . . . . . . . . . . . . . . . 4 58 2.2.1. Negotiation TLS Extension . . . . . . . . . . . . . . 4 59 2.2.2. Replay Protection Indication Extension . . . . . . . 4 60 3. Implementation Challenges . . . . . . . . . . . . . . . . . . 5 61 4. Alternatives Considered . . . . . . . . . . . . . . . . . . . 5 62 4.1. Use Both 0-RTT and 1-RTT Exporters on Same Connection . . 5 63 4.2. Don't Remember Key Parameter From Previous Connection . . 6 64 4.3. Token Binding and 0-RTT Data Are Mutually Exclusive . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 6.1. Attacks on PSK-only Key Exchange and Token Binding . . . 7 68 6.2. Exporter Replayability . . . . . . . . . . . . . . . . . 7 69 6.3. Replay Mitigations . . . . . . . . . . . . . . . . . . . 8 70 6.3.1. Server Mitigations . . . . . . . . . . . . . . . . . 8 71 6.3.2. Client Mitigations . . . . . . . . . . . . . . . . . 9 72 6.4. Early Data Ticket Age Window . . . . . . . . . . . . . . 9 73 6.5. Lack of Freshness . . . . . . . . . . . . . . . . . . . . 9 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 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 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2. Proposed Design 102 A TokenBinding struct as defined in [I-D.ietf-tokbind-protocol] 103 contains a signature of the EKM value from the TLS layer. Under 104 normal circumstances, a TokenBinding on a TLS 1.3 connection would 105 use the exporter_secret to derive the EKM value. When 0-RTT data is 106 assembled to be sent, the exporter_secret is not yet available. This 107 design changes the definition of the TokenBinding.signature field to 108 use the exporter with early_exporter_secret for 0-RTT data. Since no 109 negotiation for the connection can happen before the client sends 110 this TokenBindingMessage in 0-RTT data, this document also describes 111 how a client decides what TokenBindingMessage to send in 0-RTT data 112 and how a server should interpret that message. 114 If a client does not send any 0-RTT data, or if the server rejects 115 the client's 0-RTT data, then the client MUST use the 1-RTT exporter, 116 as defined in [I-D.ietf-tokbind-protocol]. 118 2.1. TokenBinding Signature Definition 120 In [I-D.ietf-tokbind-protocol], the signature field of the 121 TokenBinding struct is defined to be the signature of a 122 concatentation that includes the EKM value. Depending on the 123 circumstances, the exporter value in section 7.3.3 of 124 [I-D.ietf-tls-tls13] is computed using either exporter_secret or 125 early_exporter_secret as the Secret. The same Secret is used for the 126 entirety of the connection. 128 The rules for a client choosing which exporter to use are as follows. 129 A client which is not sending any 0-RTT data on a connection MUST use 130 the exporter defined in [I-D.ietf-tls-tls13] (using exporter_secret 131 as the Secret) for all TokenBindingMessages on that connection so 132 that it is compatible with [I-D.ietf-tokbind-protocol]. A client 133 that sends a TokenBindingMessage in 0-RTT data must use the exporter 134 with early_exporter_secret as the Secret (the "0-RTT exporter") since 135 exporter_secret is not defined at that time. A client that sends 136 0-RTT data which is not rejected by the server MUST use the 0-RTT 137 exporter for the rest of the connection. If the server rejects the 138 client's 0-RTT data, then the client MUST use the exporter defined in 139 [I-D.ietf-tls-tls13] (using exporter_secret as the Secret) for the 140 remainder of the connection, as if no 0-RTT data had ever been sent. 142 2.2. Negotiating Token Binding 144 2.2.1. Negotiation TLS Extension 146 The behavior of the Token Binding negotiation TLS extension does not 147 change for a 0-RTT connection: the client and server should process 148 this extension the same way regardless of whether the client also 149 sent the EarlyDataIndication extension. 151 For the sake of choosing a key parameter to use in 0-RTT data, the 152 client MUST use the same key parameter that was used on the 153 connection during which the ticket (now being used for resumption) 154 was established. The server MUST NOT accept early data if the 155 negotiated Token Binding key parameter does not match the parameter 156 from the initial connection. This is the same behavior as ALPN and 157 SNI extensions. 159 If 0-RTT data is being sent with Token Binding using a PSK obtained 160 out-of-band, then the Token Binding key parameter to use with that 161 PSK must also be provisioned to both parties, and only that key 162 parameter must be used with that PSK. 164 2.2.2. Replay Protection Indication Extension 166 The signed exporter value used in a 0-RTT connection is not 167 guaranteed to be unique to the connection, so an attacker may be able 168 to replay the signature without having possession of the private key. 169 To combat this attack, a server may implement some sort of replay 170 prevention, and indicate this to the client. A new TLS extension 171 "token_binding_replay_indication" is defined for the client to query 172 and server to indicate whether it has implemented a mechanism to 173 prevent replay. 175 enum { 176 token_binding_replay_indication(TBD), (65535) 177 } ExtensionType; 179 When sent, this extension always has zero length. If a client wishes 180 to know whether its peer is preventing replay of TokenBinding structs 181 across multiple connections, the client can include this extension in 182 its ClientHello. Upon receiving this extension, the server must echo 183 it back if it is using such a mechanism (like those described in 184 Section 6.3.1) to prevent replay. A client that only wishes to send 185 0-RTT Token Binding if the server implements replay protection can 186 send this extension on first connection establishment, and if the 187 server doesn't send it back (but does support Token Binding) the 188 client can choose to not send 0-RTT messages to that server. 190 A client that wishes to use this extension should send it every time 191 it sends a "token_binding" [I-D.ietf-tokbind-negotiation] extension. 193 3. Implementation Challenges 195 The client has to be able to modify the message it sends in 0-RTT 196 data if the 0-RTT data gets rejected and needs to be retransmitted in 197 1-RTT data. Even if the Token Binding integration with 0-RTT were 198 modified so that Token Binding never caused a 0-RTT reject that 199 required rewriting a request, the client still has to handle the 200 server rejecting the 0-RTT data for other reasons. 202 HTTP2 allows for requests to different domains to share the same TLS 203 connection if the SAN of the cert covers those domains. If 204 one.example.com supports 0-RTT and Token Binding, but two.example.com 205 only supports Token Binding as defined in 206 [I-D.ietf-tokbind-protocol], those servers cannot share a cert and 207 use HTTP2. 209 4. Alternatives Considered 211 4.1. Use Both 0-RTT and 1-RTT Exporters on Same Connection 213 The client could be required to use the 0-RTT EKM when the 214 TokenBindingMessage is sent in 0-RTT data, and the 1-RTT EKM when it 215 is sent in 1-RTT data. This requires that the abstraction of the TLS 216 layer visible to the application where it is handling Token Binding 217 exposes which phase the application data is being sent/received in. 218 An application could very easily have this detail abstracted away; 219 for example, the client might have a function like 220 "write_possibly_early" that will send data in 0-RTT the current 221 connection state permits it, and otherwise send data post-handshake. 222 A pathological client might send the first few bytes of an 223 application message in 0-RTT, but send the rest after the handshake 224 (including the TokenBindingMessage). The server's application layer 225 would have to track which bytes of the request were sent pre- and 226 post-handshake to know how to validate that TokenBindingMessage. 228 This constraint could be relaxed slightly. A ratcheting mechanism 229 could be used where the client uses the 0-RTT EKM while it thinks 230 that it's writing early data (even if it isn't writing early data), 231 and once it knows the handshake is finished, it uses the 1-RTT EKM. 232 Once the server sees a TokenBindingMessage using the 1-RTT EKM, the 233 server would no longer accept the 0-RTT EKM. In practice, this is 234 difficult to implement because multiple HTTP/2 streams can be 235 multiplexed on the same connection, requiring the ratchet to be 236 synchronized across the streams. 238 Relaxing this further where the server will always accept either the 239 0-RTT or 1-RTT EKM (but the client keeps the behavior as above) is 240 another possibility. This is more complicated than always using the 241 0-RTT exporter, and provides no additional security benefits (since 242 the server would have to accept a client only using the 0-RTT 243 exporter). 245 4.2. Don't Remember Key Parameter From Previous Connection 247 The proposed design uses the same Token Binding key parameter from 248 the previous connection, and the TLS extension must negotiate the 249 same key parameter as the previous connection. This mirrors how ALPN 250 is negotiated in TLS 1.3. Instead of remembering this parameter, the 251 client could put the in first entry of their key parameters list the 252 key type being used in 0-RTT, and allow the client and server to 253 potentially negotiate a new type to use once the handshake is 254 complete. This alternate gains a slight amount of key type agility 255 in exchange for implementation difficulty. Other variations of this 256 are also possible, for example requiring the server to reject early 257 data if it doesn't choose the first parameter, or requiring the 258 client to send only one key parameter. 260 4.3. Token Binding and 0-RTT Data Are Mutually Exclusive 262 If a TokenBindingMessage is never allowed in 0-RTT data, then no 263 changes are needed to the exporter or negotiation. A server that 264 wishes to support Token Binding must not create any NewSessionTicket 265 messages with the allow_early_data flag set. A client must not send 266 the token binding negotiation extension and the EarlyDataIndication 267 extension in the same ClientHello. 269 5. IANA Considerations 271 This document defines a new TLS extension 272 "token_binding_replay_indication", which needs to be added to the 273 IANA "Transport Layer Security (TLS) Extensions" registry. 275 6. Security Considerations 277 Token Binding messages that use the 0-RTT exporter have weaker 278 security properties than with the [RFC5705] exporter. If either 279 party of a connection using Token Binding does not wish to use 0-RTT 280 token bindings, they can do so: a client can choose to never send 281 0-RTT data on a connection where it uses token binding, and a server 282 can choose to reject any 0-RTT data sent on a connection that 283 negotiated token binding. 285 0-RTT data in TLS 1.3 has weaker security properties than other kinds 286 of TLS data. Specifically, TLS 1.3 does not guarantee non- 287 replayability of data between connections. Token Binding has similar 288 replayability issues when in 0-RTT data, but preventing replay of 289 Token Binding and preventing replay of 0-RTT data are two separate 290 problems. Token Binding is not designed to prevent replay of 0-RTT 291 data, although solutions for preventing the replay of Token Binding 292 might also be applicable to 0-RTT data. 294 6.1. Attacks on PSK-only Key Exchange and Token Binding 296 An attacker who possesses the PSK can eavesdrop on an existing 297 connection that uses that PSK to obtain a TokenBindingMessage that is 298 valid on the connection and then hijack the connection to send 299 whatever attacker-controlled data it wishes. Because the regular 300 exporter closes over the server random, this TokenBindingMessage is 301 valid only for that connection. 303 If the attacker does the same thing with a pure-PSK connection and 304 0-RTT Token Binding, the attacker can replay the original ClientHello 305 and the exporter will stay the same, allowing the attacker to obtain 306 a TokenBindingMessage from one connection and replay it on future 307 connections. The only way for a server to prevent this replay is to 308 prevent the client from ever repeating a client random in the 309 handshake. 311 If a server accepting connections with PSK-only key establishment is 312 concerned about the threat of PSK theft and also implements Token 313 Binding, then that server must either reject all 0-RTT token 314 bindings, or implement some form of preventing reuse of a client 315 random. 317 6.2. Exporter Replayability 319 The exporter specified in [I-D.ietf-tokbind-protocol] is chosen so 320 that a client and server have the same exporter value only if they 321 are on the same TLS connection. This prevents an attacker who can 322 read the plaintext of a TokenBindingMessage sent on that connection 323 from replaying that message on another connection (without also 324 having the token binding private key). The 0-RTT exporter only 325 covers the ClientHello and the PSK of the connection, so it does not 326 provide this guarantee. 328 An attacker with possession of the PSK secret and a transcript of the 329 ClientHello and early data sent by a client under that PSK can 330 extract the TokenBindingMessage, create a new connection to the 331 server (using the same ClientHello and PSK), and send different 332 application data with the same TokenBindingMessage. Note that the 333 ClientHello contains public values for the (EC)DHE key agreement that 334 is used as part of deriving the traffic keys for the TLS connection, 335 so if the attacker does not also have the corresponding private 336 values, they will not be able to read the server's response or send a 337 valid Finished message in the handshake for this TLS connection. 338 Nevertheless, by that point the server has already processed the 339 attacker's message with the replayed TokenBindingMessage. 341 This sort of replayability of a TokenBindingMessage is different than 342 the replayability caveat of 0-RTT application data in TLS 1.3. A 343 network observer can replay 0-RTT data from TLS 1.3 without knowing 344 any secrets of the client or server, but the application data that is 345 replayed is untouched. This replay is done by a more powerful 346 attacker who is able to view the plaintext and then spoof a 347 connection with the same parameters so that the replayed 348 TokenBindingMessage still validates when sent with different 349 application data. 351 6.3. Replay Mitigations 353 This section presents multiple ways that a client or server can 354 prevent the replay of a TokenBinding while still using Token Binding 355 with 0-RTT data. 357 If a client or server implements a measure that prevents all replays, 358 then its peer does not also need to implement such a mitigation. A 359 client that is concerned about replay SHOULD implement replay a 360 mitigation instead of relying solely on a signal from the server 361 through the replay indication extension. 363 6.3.1. Server Mitigations 365 If a server uses a session cache instead of stateless tickets, it can 366 enforce that a PSK generated for resumption can only be used once. 367 If an attacker tries to replay 0-RTT data (with a 368 TokenBindingMessage), the server will reject it because the PSK was 369 already used. 371 Preventing all replay of 0-RTT data is not necessary to prevent 372 replay of a TokenBinding. A server could implement a mechanism to 373 prevent a particular TokenBinding from being presented on more than 374 one connection. In cases where a server's TLS termination and 375 application layer processing happen in different locations, this 376 option might be easier to implement, especially when not all requests 377 have bound tokens. This processing can also take advantage of the 378 structure of the bound token, e.g. a token that identifies which user 379 is making a request could shard its store of which TokenBindings have 380 been seen based on the user ID. 382 A server can prevent some, but not all, 0-RTT data replay with a 383 tight time window for the ticket age that it will accept. See 384 Section 6.4 for more details. 386 6.3.2. Client Mitigations 388 A client cannot prevent a sufficiently motivated attacker from 389 replaying a TokenBinding, but it can make it so difficult to replay 390 the TokenBinding that it is easier for the attacker to steal the 391 Token Binding key directly. If the client secures the resumption 392 secret with the same level of protection as the Token Binding key, 393 then the client has made it not worth the effort of the attacker to 394 attempt to replay a TokenBinding. Ideally the resumption secret (and 395 Token Binding key) are protected strongly and virtually non- 396 exportable. 398 6.4. Early Data Ticket Age Window 400 When an attacker with control of the PSK secret replays a 401 TokenBindingMessage, it has to use the same ClientHello that the 402 client used. The ClientHello includes an "obfuscated_ticket_age" in 403 its EarlyDataIndication extension, which the server can use to narrow 404 the window in which that ClientHello will be accepted. Even if a PSK 405 is valid for a week, the server will only accept that particular 406 ClientHello for a smaller time window based on the ticket age. A 407 server should make their acceptance window for this value as small as 408 practical to limit an attacker's ability to replay a ClientHello and 409 send new application data with the stolen TokenBindingMessage. 411 6.5. Lack of Freshness 413 The 0-RTT exporter value does not contain anything that the client 414 cannot precompute before connecting to the server. Therefore, an 415 attacker could have a client generate but not send a series of 416 messages to take particular actions, and then selectively send one of 417 those messages at a later date. If this attack includes deleting the 418 resumption secret from the client, then these latent attacker-held 419 messages will be the only ones to use that resumption secret and 420 replay protections do not prevent this attack. 422 7. Acknowledgements 424 The author would like to thank David Benjamin, Steven Valdez, Bill 425 Cox, and Andrei Popov for their feedback and suggestions. 427 8. Normative References 429 [I-D.ietf-tls-tls13] 430 Rescorla, E., "The Transport Layer Security (TLS) Protocol 431 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 432 October 2016. 434 [I-D.ietf-tokbind-negotiation] 435 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 436 "Transport Layer Security (TLS) Extension for Token 437 Binding Protocol Negotiation", draft-ietf-tokbind- 438 negotiation-05 (work in progress), September 2016. 440 [I-D.ietf-tokbind-protocol] 441 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 442 Hodges, "The Token Binding Protocol Version 1.0", draft- 443 ietf-tokbind-protocol-10 (work in progress), September 444 2016. 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, 448 DOI 10.17487/RFC2119, March 1997, 449 . 451 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 452 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 453 March 2010, . 455 Author's Address 457 Nick Harper 458 Google Inc. 460 Email: nharper@google.com