idnits 2.17.1 draft-ietf-tcpinc-tcpcrypt-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-tcpinc-tcpeno]), 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 13, 2017) is 2591 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 334 == Outdated reference: A later version (-19) exists of draft-ietf-tcpinc-tcpeno-08 ** Obsolete normative reference: RFC 7539 (Obsoleted by RFC 8439) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bittau 3 Internet-Draft Google 4 Intended status: Experimental D. Giffin 5 Expires: September 14, 2017 Stanford University 6 M. Handley 7 University College London 8 D. Mazieres 9 Stanford University 10 Q. Slack 11 Sourcegraph 12 E. Smith 13 Kestrel Institute 14 March 13, 2017 16 Cryptographic protection of TCP Streams (tcpcrypt) 17 draft-ietf-tcpinc-tcpcrypt-06 19 Abstract 21 This document specifies tcpcrypt, a TCP encryption protocol designed 22 for use in conjunction with the TCP Encryption Negotiation Option 23 (TCP-ENO) [I-D.ietf-tcpinc-tcpeno]. Tcpcrypt coexists with 24 middleboxes by tolerating resegmentation, NATs, and other 25 manipulations of the TCP header. The protocol is self-contained and 26 specifically tailored to TCP implementations, which often reside in 27 kernels or other environments in which large external software 28 dependencies can be undesirable. Because the size of TCP options is 29 limited, the protocol requires one additional one-way message latency 30 to perform key exchange before application data may be transmitted. 31 However, this cost can be avoided between two hosts that have 32 recently established a previous tcpcrypt connection. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 14, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Requirements language . . . . . . . . . . . . . . . . . . . . 3 80 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 3. Encryption protocol . . . . . . . . . . . . . . . . . . . . . 4 82 3.1. Cryptographic algorithms . . . . . . . . . . . . . . . . 4 83 3.2. Protocol negotiation . . . . . . . . . . . . . . . . . . 5 84 3.3. Key exchange . . . . . . . . . . . . . . . . . . . . . . 6 85 3.4. Session ID . . . . . . . . . . . . . . . . . . . . . . . 8 86 3.5. Session caching . . . . . . . . . . . . . . . . . . . . . 8 87 3.6. Data encryption and authentication . . . . . . . . . . . 11 88 3.7. TCP header protection . . . . . . . . . . . . . . . . . . 12 89 3.8. Re-keying . . . . . . . . . . . . . . . . . . . . . . . . 12 90 3.9. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . 13 91 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 4.1. Key exchange messages . . . . . . . . . . . . . . . . . . 14 93 4.2. Application frames . . . . . . . . . . . . . . . . . . . 16 94 4.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . . 17 95 4.2.2. Associated data . . . . . . . . . . . . . . . . . . . 18 96 4.2.3. Frame nonce . . . . . . . . . . . . . . . . . . . . . 18 97 5. Key agreement schemes . . . . . . . . . . . . . . . . . . . . 18 98 6. AEAD algorithms . . . . . . . . . . . . . . . . . . . . . . . 19 99 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 100 8. Security considerations . . . . . . . . . . . . . . . . . . . 20 101 9. Design notes . . . . . . . . . . . . . . . . . . . . . . . . 22 102 9.1. Asymmetric roles . . . . . . . . . . . . . . . . . . . . 22 103 9.2. Verified liveness . . . . . . . . . . . . . . . . . . . . 22 104 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 105 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 108 12.2. Informative References . . . . . . . . . . . . . . . . . 24 109 Appendix A. Protocol constant values . . . . . . . . . . . . . . 24 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 112 1. Requirements language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 2. Introduction 120 This document describes tcpcrypt, an extension to TCP for 121 cryptographic protection of session data. Tcpcrypt was designed to 122 meet the following goals: 124 o Meet the requirements of the TCP Encryption Negotiation Option 125 (TCP-ENO) [I-D.ietf-tcpinc-tcpeno] for protecting connection data. 127 o Be amenable to small, self-contained implementations inside TCP 128 stacks. 130 o Minimize additional latency at connection startup. 132 o As much as possible, prevent connection failure in the presence of 133 NATs and other middleboxes that might normalize traffic or 134 otherwise manipulate TCP segments. 136 o Operate independently of IP addresses, making it possible to 137 authenticate resumed sessions efficiently even when either end 138 changes IP address. 140 3. Encryption protocol 142 This section describes the tcpcrypt protocol at an abstract level. 143 The concrete format of all messages is specified in Section 4. 145 3.1. Cryptographic algorithms 147 Setting up a tcpcrypt connection employs three types of cryptographic 148 algorithms: 150 o A _key agreement scheme_ is used with a short-lived public key to 151 agree upon a shared secret. 153 o An _extract function_ is used to generate a pseudo-random key from 154 some initial keying material, typically the output of the key 155 agreement scheme. The notation Extract(S, IKM) denotes the output 156 of the extract function with salt S and initial keying material 157 IKM. 159 o A _collision-resistant pseudo-random function (CPRF)_ is used to 160 generate multiple cryptographic keys from a pseudo-random key, 161 typically the output of the extract function. We use the notation 162 CPRF(K, CONST, L) to designate the output of L bytes of the 163 pseudo-random function identified by key K on CONST. 165 The Extract and CPRF functions used by default are the Extract and 166 Expand functions of HKDF [RFC5869]. These are defined as follows in 167 terms of the PRF "HMAC-Hash(key, value)" for a negotiated "Hash" 168 function: 170 HKDF-Extract(salt, IKM) -> PRK 171 PRK = HMAC-Hash(salt, IKM) 173 HKDF-Expand(PRK, CONST, L) -> OKM 174 T(0) = empty string (zero length) 175 T(1) = HMAC-Hash(PRK, T(0) | CONST | 0x01) 176 T(2) = HMAC-Hash(PRK, T(1) | CONST | 0x02) 177 T(3) = HMAC-Hash(PRK, T(2) | CONST | 0x03) 178 ... 180 OKM = first L octets of T(1) | T(2) | T(3) | ... 182 Figure 1: The symbol | denotes concatenation, and the counter 183 concatenated to the right of CONST is a single octet. 185 Lastly, once tcpcrypt has been successfully set up and encryption 186 keys have been derived, an algorithm for Authenticated Encryption 187 with Associated Data (AEAD) is used to protect the confidentiality 188 and integrity of all transmitted application data. AEAD algorithms 189 use a single key to encrypt their input data and also to generate a 190 cryptographic tag to accompany the resulting ciphertext; when 191 decryption is performed, the tag allows authentication of the 192 encrypted data and of optional, associated plaintext data. 194 3.2. Protocol negotiation 196 Tcpcrypt depends on TCP-ENO [I-D.ietf-tcpinc-tcpeno] to negotiate 197 whether encryption will be enabled for a connection, and also which 198 key agreement scheme to use. TCP-ENO negotiates the use of a 199 particular TCP encryption protocol or _TEP_ by including protocol 200 identifiers in ENO suboptions. This document associates four TEP 201 identifiers with the tcpcrypt protocol, as listed in Table 1. Each 202 identifier indicates the use of a particular key-agreement scheme. 203 Future standards may associate additional identifiers with tcpcrypt. 205 An active opener that wishes to negotiate the use of tcpcrypt 206 includes an ENO option in its SYN segment. That option includes 207 suboptions with tcpcrypt TEP identifiers indicating the key-agreement 208 schemes it is willing to enable. The active opener MAY additionally 209 include suboptions indicating support for encryption protocols other 210 than tcpcrypt, as well as global suboptions as specified by TCP-ENO. 212 If a passive opener receives an ENO option including tcpcrypt TEPs it 213 supports, it MAY then attach an ENO option to its SYN-ACK segment, 214 including _solely_ the TEP it wishes to enable. 216 To establish distinct roles for the two hosts in each connection, 217 tcpcrypt depends on the role-negotiation mechanism of TCP-ENO. As 218 one result of the negotiation process, TCP-ENO assigns hosts unique 219 roles abstractly called "A" at one end of the connection and "B" at 220 the other. Generally, an active opener plays the "A" role and a 221 passive opener plays the "B" role; but in the case of simultaneous 222 open, an additional mechanism breaks the symmetry and assigns 223 different roles to the two hosts. This document adopts the terms 224 "host A" and "host B" to identify each end of a connection uniquely, 225 following TCP-ENO's designation. 227 ENO suboptions include a flag "v" which indicates the presence of 228 associated, variable-length data. In order to propose fresh key 229 agreement with a particular tcpcrypt TEP, a host sends a one-byte 230 suboption containing the TEP identifier and "v = 0". In order to 231 propose session resumption (described further below) with a 232 particular TEP, a host sends a variable-length suboption containing 233 the TEP identifier, the flag "v = 1", and an identifier for a session 234 previously negotiated with the same host and the same TEP. 236 Once two hosts have exchanged SYN segments, TCP-ENO defines the 237 _negotiated TEP_ to be the last valid TEP identifier in the SYN 238 segment of host B (that is, the passive opener in the absence of 239 simultaneous open) that also occurs in that of host A. If there is 240 no such TEP, hosts MUST disable TCP-ENO and tcpcrypt. 242 If the negotiated TEP was sent by host B with "v = 0", it means that 243 fresh key agreement will be performed as described below in 244 Section 3.3. If it had "v = 1", the key-exchange messages will be 245 omitted in favor of determining keys via session-caching as described 246 in Section 3.5, and protected application data may immediately be 247 sent as detailed in Section 3.6. 249 Note that the negotiated TEP is determined without reference to the 250 "v" bits in ENO suboptions, so if host A offers resumption with a 251 particular TEP and host B replies with a non-resumption suboption 252 with the same TEP, that may become the negotiated TEP and fresh key 253 agreement will be performed. That is, sending a resumption suboption 254 also implies willingness to perform fresh key agreement with the 255 indicated TEP. 257 As required by TCP-ENO, once a host has both sent and received an ACK 258 segment containing a valid ENO option, encryption MUST be enabled and 259 plaintext application data MUST NOT ever be exchanged on the 260 connection. If the negotiated TEP is among those listed in Table 1, 261 a host MUST follow the protocol described in this document. 263 3.3. Key exchange 265 Following successful negotiation of a tcpcrypt TEP, all further 266 signaling is performed in the Data portion of TCP segments. Except 267 when resumption was negotiated (described below in Section 3.5), the 268 two hosts perform key exchange through two messages, "Init1" and 269 "Init2", at the start of the data streams of host A and host B, 270 respectively. These messages may span multiple TCP segments and need 271 not end at a segment boundary. However, the segment containing the 272 last byte of an "Init1" or "Init2" message SHOULD have TCP's PSH bit 273 set. 275 The key exchange protocol, in abstract, proceeds as follows: 277 A -> B: Init1 = { INIT1_MAGIC, sym-cipher-list, N_A, PK_A } 278 B -> A: Init2 = { INIT2_MAGIC, sym-cipher, N_B, PK_B } 280 The concrete format of these messages is specified in Section 4.1. 282 The parameters are defined as follows: 284 o "INIT1_MAGIC", "INIT2_MAGIC": constants defined in Table 3. 286 o "sym-cipher-list": a list of symmetric ciphers (AEAD algorithms) 287 acceptable to host A. These are specified in Table 2. 289 o "sym-cipher": the symmetric cipher selected by host B from the 290 "sym-cipher-list" sent by host A. 292 o "N_A", "N_B": nonces chosen at random by hosts A and B, 293 respectively. 295 o "PK_A", "PK_B": ephemeral public keys for hosts A and B, 296 respectively. These, as well as their corresponding private keys, 297 are short-lived values that SHOULD be refreshed periodically. The 298 private keys SHOULD NOT ever be written to persistent storage. 300 The ephemeral secret ("ES") is the result of the key-agreement 301 algorithm (see Section 5) indicated by the negotiated TEP. The 302 inputs to the algorithm are the local host's ephemeral private key 303 and the remote host's ephemeral public key. For example, host A 304 would compute "ES" using its own private key (not transmitted) and 305 host B's public key, "PK_B". 307 The two sides then compute a pseudo-random key ("PRK"), from which 308 all session keys are derived, as follows: 310 PRK = Extract(N_A, eno-transcript | Init1 | Init2 | ES) 312 Above, "|" denotes concatenation; "eno-transcript" is the protocol- 313 negotiation transcript defined in TCP-ENO; and "Init1" and "Init2" 314 are the transmitted encodings of the messages described in 315 Section 4.1. 317 A series of "session secrets" are then computed from "PRK" as 318 follows: 320 ss[0] = PRK 321 ss[i] = CPRF(ss[i-1], CONST_NEXTK, K_LEN) 323 The value "ss[0]" is used to generate all key material for the 324 current connection. The values "ss[i]" for "i > 0" can be used to 325 avoid public key cryptography when establishing subsequent 326 connections between the same two hosts, as described in Section 3.5. 327 The "CONST_*" values are constants defined in Table 3. The length 328 "K_LEN" depends on the tcpcrypt TEP in use, and is specified in 329 Section 5. 331 Given a session secret "ss", the two sides compute a series of master 332 keys as follows: 334 mk[0] = CPRF(ss, CONST_REKEY, K_LEN) 335 mk[i] = CPRF(mk[i-1], CONST_REKEY, K_LEN) 337 The particular master key in use is advanced as described in 338 Section 3.8. 340 Finally, each master key "mk" is used to generate keys for 341 authenticated encryption for the "A" and "B" roles. Key "k_ab" is 342 used by host A to encrypt and host B to decrypt, while "k_ba" is used 343 by host B to encrypt and host A to decrypt. 345 k_ab = CPRF(mk, CONST_KEY_A, ae_keylen) 346 k_ba = CPRF(mk, CONST_KEY_B, ae_keylen) 348 The value "ae_keylen" depends on the authenticated-encryption 349 algorithm selected, and is given under "Key Length" in Table 2. 351 After host B sends "Init2" or host A receives it, that host may 352 immediately begin transmitting protected application data as 353 described in Section 3.6. 355 If host A receives "Init2" with a "sym-cipher" value that was not 356 present in the "sym-cipher-list" it previously transmitted in 357 "Init1", it MUST abort the connection and raise an error condition 358 distinct from the end-of-file condition. 360 3.4. Session ID 362 TCP-ENO requires each TEP to define a _session ID_ value that 363 uniquely identifies each encrypted connection. 365 As required, a tcpcrypt session ID begins with the negotiated TEP 366 identifier along with the "v" bit as transmitted by host B. The 367 remainder of the ID is derived from the session secret, as follows: 369 session_id[i] = TEP-byte | CPRF(ss[i], CONST_SESSID, K_LEN) 371 Again, the length "K_LEN" depends on the TEP, and is specified in 372 Section 5. 374 3.5. Session caching 376 When two hosts have already negotiated session secret "ss[i-1]", they 377 can establish a new connection without public-key operations using 378 "ss[i]". A host signals willingness to resume with a particular 379 session secret by sending a SYN segment with a resumption suboption: 380 that is, an ENO suboption containing the negotiated TEP identifier 381 from the original session and part of an identifier for the session. 383 The resumption identifier is calculated from a session secret "ss[i]" 384 as follows: 386 resume[i] = CPRF(ss[i], CONST_RESUME, 18) 388 To name a session for resumption, a host sends either the first or 389 second half of the resumption identifier, according to the role it 390 played in the original session with secret "ss[0]". 392 A host that originally played role A and wishes to resume from a 393 cached session sends a suboption with the first half of the 394 resumption identifier: 396 byte 0 1 9 (10 bytes total) 397 +--------+--------+---...---+--------+ 398 | TEP- | resume[i]{0..8} | 399 | byte | | 400 +--------+--------+---...---+--------+ 402 Figure 2: Resumption suboption sent when original role was A. The 403 TEP-byte contains a tcpcrypt TEP identifier and v = 1. 405 Similarly, a host that originally played role B sends a suboption 406 with the second half of the resumption identifier: 408 byte 0 1 9 (10 bytes total) 409 +--------+--------+---...---+--------+ 410 | TEP- | resume[i]{9..17} | 411 | byte | | 412 +--------+--------+---...---+--------+ 414 Figure 3: Resumption suboption sent when original role was B. The 415 TEP-byte contains a tcpcrypt TEP identifier and v = 1. 417 If a passive opener recognizes the identifier-half in a resumption 418 suboption it has received and knows "ss[i]", it SHOULD (with 419 exceptions specified below) agree to resume from the cached session 420 by sending its own resumption suboption, which will contain the other 421 half of the identifier. 423 If it does not agree to resumption with a particular TEP, the passive 424 opener may either request fresh key exchange by responding with a 425 non-resumption suboption using the same TEP, or else respond to any 426 other received suboption. 428 If an active opener receives a resumption suboption for a particular 429 TEP and the received identifier-half does not match the "resume[i]" 430 value whose other half it previously sent in a resumption suboption 431 for the same TEP, it MUST ignore that suboption. In the typical case 432 that this was the only ENO suboption received, this means the host 433 MUST disable TCP-ENO and tcpcrypt: that is, it MUST NOT send any more 434 ENO options and MUST NOT encrypt the connection. 436 When a host concludes that TCP-ENO negotiation has succeeded for some 437 TEP that was received in a resumption suboption, it MUST then enable 438 encryption with that TEP, using the cached session secret, as 439 described in Section 3.6. 441 The session ID (Section 3.4) is constructed in the same way for 442 resumed sessions as it is for fresh ones. In this case the first 443 byte will always have "v = 1". The remainder of the ID is derived 444 from the cached session secret. 446 In the case of simultaneous open where TCP-ENO is able to establish 447 asymmetric roles, two hosts that simultaneously send SYN segments 448 with compatible resumption suboptions may resume the associated 449 session. 451 In a particular SYN segment, a host SHOULD NOT send more than one 452 resumption suboption, and MUST NOT send more than one resumption 453 suboption with the same TEP identifier. But in addition to any 454 resumption suboptions, an active opener MAY include non-resumption 455 suboptions describing other key-agreement schemes it supports (in 456 addition to that indicated by the TEP in the resumption suboption). 458 After using "ss[i]" to compute "mk[0]", implementations SHOULD 459 compute and cache "ss[i+1]" for possible use by a later session, then 460 erase "ss[i]" from memory. Hosts SHOULD retain "ss[i+1]" until it is 461 used or the memory needs to be reclaimed. Hosts SHOULD NOT write a 462 cached "ss[i+1]" value to non-volatile storage. 464 When proposing resumption, the active opener MUST use the lowest 465 value of "i" that has not already been used (successfully or not) to 466 negotiate resumption with the same host and for the same pre-session 467 key "ss[0]". 469 A host MUST NOT resume with a session secret if it has ever 470 successfully negotiated resumption in the past, in either role, with 471 the same secret. In the event that two hosts simultaneously send SYN 472 segments to each other that propose resumption with the same session 473 secret but the two segments are not part of a simultaneous open, both 474 connections will have to revert to fresh key-exchange. To avoid this 475 limitation, implementations MAY choose to implement session caching 476 such that a given pre-session key "ss[0]" is only used for either 477 passive or active opens at the same host, not both. 479 When two hosts have previously negotiated a tcpcrypt session, either 480 host may initiate session resumption regardless of which host was the 481 active opener or played the "A" role in the previous session. 483 However, a given host must either encrypt with "k_ab" for all 484 sessions derived from the same pre-session key "ss[0]", or with 485 "k_ba". Thus, which keys a host uses to send segments is not 486 affected by the role it plays in the current connection: it depends 487 only on whether the host played the "A" or "B" role in the initial 488 session. 490 Implementations that perform session caching MUST provide a means for 491 applications to control session caching, including flushing cached 492 session secrets associated with an ESTABLISHED connection or 493 disabling the use of caching for a particular connection. 495 3.6. Data encryption and authentication 497 Following key exchange (or its omission via session caching), all 498 further communication in a tcpcrypt-enabled connection is carried out 499 within delimited _application frames_ that are encrypted and 500 authenticated using the agreed keys. 502 This protection is provided via algorithms for Authenticated 503 Encryption with Associated Data (AEAD). The particular algorithms 504 that may be used are listed in Table 2. One algorithm is selected 505 during the negotiation described in Section 3.3. 507 The format of an application frame is specified in Section 4.2. A 508 sending host breaks its stream of application data into a series of 509 chunks. Each chunk is placed in the "data" portion of a "plaintext" 510 value, which is then encrypted to yield a frame's "ciphertext" field. 511 Chunks must be small enough that the ciphertext (whose length depends 512 on the AEAD cipher used, and is generally slightly longer than the 513 plaintext) has length less than 2^16 bytes. 515 An "associated data" value (see Section 4.2.2) is constructed for the 516 frame. It contains the frame's "control" field and the length of the 517 ciphertext. 519 A "frame nonce" value (see Section 4.2.3) is also constructed for the 520 frame but not explicitly transmitted. It contains an "offset" field 521 whose integer value is the zero-indexed byte offset of the beginning 522 of the current application frame in the underlying TCP datastream. 523 (That is, the offset in the framing stream, not the plaintext 524 application stream.) Because it is strictly necessary for the 525 security of the AEAD algorithm, an implementation MUST NOT ever 526 transmit distinct frames with the same nonce value under the same 527 encryption key. In particular, a retransmitted TCP segment MUST 528 contain the same payload bytes for the same TCP sequence numbers, and 529 a host MUST NOT transmit more than 2^64 bytes in the underlying TCP 530 datastream (which would cause the "offset" field to wrap) before re- 531 keying. 533 With reference to the "AEAD Interface" described in Section 2 of 534 [RFC5116], tcpcrypt invokes the AEAD algorithm with the secret key 535 "K" set to k_ab or k_ba, according to the host's role as described in 536 Section 3.3. The plaintext value serves as "P", the associated data 537 as "A", and the frame nonce as "N". The output of the encryption 538 operation, "C", is transmitted in the frame's "ciphertext" field. 540 When a frame is received, tcpcrypt reconstructs the associated data 541 and frame nonce values (the former contains only data sent in the 542 clear, and the latter is implicit in the TCP stream), and provides 543 these and the ciphertext value to the the AEAD decryption operation. 544 The output of this operation is either a plaintext value "P" or the 545 special symbol FAIL. In the latter case, the implementation MUST 546 either ignore the frame or abort the connection; but if it aborts, 547 the implementation MUST raise an error condition distinct from the 548 end-of-file condition. 550 3.7. TCP header protection 552 The "ciphertext" field of the application frame contains protected 553 versions of certain TCP header values. 555 When "URGp" is set, the "urgent" value indicates an offset from the 556 current frame's beginning offset; the sum of these offsets gives the 557 index of the last byte of urgent data in the application datastream. 559 When "FINp" is set, it indicates that the sender will send no more 560 application data after this frame. When the TCP FIN flag differs 561 from "FINp", a receiving host MUST either ignore the segment 562 altogether or abort the connection and raise an error condition 563 distinct from the end-of-file condition. 565 3.8. Re-keying 567 Re-keying allows hosts to wipe from memory keys that could decrypt 568 previously transmitted segments. It also allows the use of AEAD 569 ciphers that can securely encrypt only a bounded number of messages 570 under a given key. 572 We refer to the two encryption keys (k_ab, k_ba) as a _key-set_. We 573 refer to the key-set generated by mk[i] as the key-set with 574 _generation number_ "i" within a session. Each host maintains a 575 _local generation number_ that determines which key-set it uses to 576 encrypt outgoing frames, and a _remote generation number_ equal to 577 the highest generation used in frames received from its peer. 578 Initially, these two values are set to zero. 580 A host MAY increment its local generation number beyond the remote 581 generation number it has recorded. We call this action _initiating 582 re-keying_. 584 When a host has incremented its local generation number and uses the 585 new key-set for the first time to encrypt an outgoing frame, it MUST 586 set "rekey = 1" for that frame. It MUST set this field to zero in 587 all other cases. 589 When a host receives a frame with "rekey = 1", it increments its 590 record of the remote generation number. If the remote generation 591 number is now greater than the local generation number, the receiver 592 MUST immediately increment its local generation number to match. 593 Moreover, if the receiver has not yet transmitted a segment with the 594 FIN flag set, it MUST immediately send a frame (with empty 595 application data if necessary) with "rekey = 1". 597 A host SHOULD NOT initiate more than one concurrent re-key operation 598 if it has no data to send; that is, it should not initiate re-keying 599 with an empty application frame more than once while its record of 600 the remote generation number is less than its own. 602 When retransmitting, implementations must always transmit the same 603 bytes for the same TCP sequence numbers. Thus, a frame in a 604 retransmitted segment MUST always be encrypted with the same key as 605 when it was originally transmitted. 607 Implementations SHOULD delete older-generation keys from memory once 608 they have received all frames they will need to decrypt with the old 609 keys and have encrypted all outgoing frames under the old keys. 611 3.9. Keep-alive 613 Instead of using TCP Keep-Alives to verify that the remote endpoint 614 is still responsive, tcpcrypt implementations SHOULD employ the re- 615 keying mechanism for this purpose, as follows. When necessary, a 616 host SHOULD probe the liveness of its peer by initiating re-keying 617 and transmitting a new frame immediately (with empty application data 618 if necessary). 620 As described in Section 3.8, a host receiving a frame encrypted under 621 a generation number greater than its own MUST increment its own 622 generation number and (if it has not already transmitted a segment 623 with FIN set) immediately transmit a new frame (with zero-length 624 application data if necessary). 626 Implementations MAY use TCP Keep-Alives for purposes that do not 627 require endpoint authentication, as discussed in Section 9.2. 629 4. Encodings 631 This section provides byte-level encodings for values transmitted or 632 computed by the protocol. 634 4.1. Key exchange messages 636 The "Init1" message has the following encoding: 638 byte 0 1 2 3 639 +-------+-------+-------+-------+ 640 | INIT1_MAGIC | 641 | | 642 +-------+-------+-------+-------+ 644 4 5 6 7 645 +-------+-------+-------+-------+ 646 | message_len | 647 | = M | 648 +-------+-------+-------+-------+ 650 8 651 +--------+-------+-------+---...---+-------+ 652 |nciphers|sym- |sym- | |sym- | 653 | =K+1 |cipher0|cipher1| |cipherK| 654 +--------+-------+-------+---...---+-------+ 656 K + 10 K + 10 + N_A_LEN 657 | | 658 v v 659 +-------+---...---+-------+-------+---...---+-------+ 660 | N_A | PK_A | 661 | | | 662 +-------+---...---+-------+-------+---...---+-------+ 664 M - 1 665 +-------+---...---+-------+ 666 | ignored | 667 | | 668 +-------+---...---+-------+ 670 The constant "INIT1_MAGIC" is defined in Table 3. The four-byte 671 field "message_len" gives the length of the entire "Init1" message, 672 encoded as a big-endian integer. The "nciphers" field contains an 673 integer value that specifies the number of one-byte symmetric-cipher 674 identifiers that follow. The "sym-cipher" bytes identify 675 cryptographic algorithms in Table 2. The length "N_A_LEN" and the 676 length of "PK_A" are both determined by the negotiated key-agreement 677 scheme, as described in Section 5. 679 When sending "Init1", implementations of this protocol MUST omit the 680 field "ignored"; that is, they must construct the message such that 681 its end, as determined by "message_len", coincides with the end of 682 the field "PK_A". When receiving "Init1", however, implementations 683 MUST permit and ignore any bytes following "PK_A". 685 The "Init2" message has the following encoding: 687 byte 0 1 2 3 688 +-------+-------+-------+-------+ 689 | INIT2_MAGIC | 690 | | 691 +-------+-------+-------+-------+ 693 4 5 6 7 8 694 +-------+-------+-------+-------+-------+ 695 | message_len |sym- | 696 | = M |cipher | 697 +-------+-------+-------+-------+-------+ 699 9 9 + N_B_LEN 700 | | 701 v v 702 +-------+---...---+-------+-------+---...---+-------+ 703 | N_B | PK_B | 704 | | | 705 +-------+---...---+-------+-------+---...---+-------+ 707 M - 1 708 +-------+---...---+-------+ 709 | ignored | 710 | | 711 +-------+---...---+-------+ 713 The constant "INIT2_MAGIC" is defined in Table 3. The four-byte 714 field "message_len" gives the length of the entire "Init2" message, 715 encoded as a big-endian integer. The "sym-cipher" value is a 716 selection from the symmetric-cipher identifiers in the previously- 717 received "Init1" message. The length "N_B_LEN" and the length of 718 "PK_B" are both determined by the negotiated key-agreement scheme, as 719 described in Section 5. 721 When sending "Init2", implementations of this protocol MUST omit the 722 field "ignored"; that is, they must construct the message such that 723 its end, as determined by "message_len", coincides with the end of 724 the "PK_B" field. When receiving "Init2", however, implementations 725 MUST permit and ignore any bytes following "PK_B". 727 4.2. Application frames 729 An _application frame_ comprises a control byte and a length-prefixed 730 ciphertext value: 732 byte 0 1 2 3 clen+2 733 +-------+-------+-------+-------+---...---+-------+ 734 |control| clen | ciphertext | 735 +-------+-------+-------+-------+---...---+-------+ 737 The field "clen" is an integer in big-endian format and gives the 738 length of the "ciphertext" field. 740 The byte "control" has this structure: 742 bit 7 1 0 743 +-------+---...---+-------+-------+ 744 | cres | rekey | 745 +-------+---...---+-------+-------+ 747 The seven-bit field "cres" is reserved; implementations MUST set 748 these bits to zero when sending, and MUST ignore them when receiving. 750 The use of the "rekey" field is described in Section 3.8. 752 4.2.1. Plaintext 754 The "ciphertext" field is the result of applying the negotiated 755 authenticated-encryption algorithm to a "plaintext" value, which has 756 one of these two formats: 758 byte 0 1 plen-1 759 +-------+-------+---...---+-------+ 760 | flags | data | 761 +-------+-------+---...---+-------+ 763 byte 0 1 2 3 plen-1 764 +-------+-------+-------+-------+---...---+-------+ 765 | flags | urgent | data | 766 +-------+-------+-------+-------+---...---+-------+ 768 (Note that "clen" in the previous section will generally be greater 769 than "plen", as the ciphertext produced by the authenticated- 770 encryption scheme must both encrypt the application data and provide 771 a way to verify its integrity.) 773 The "flags" byte has this structure: 775 bit 7 6 5 4 3 2 1 0 776 +----+----+----+----+----+----+----+----+ 777 | fres |URGp|FINp| 778 +----+----+----+----+----+----+----+----+ 780 The six-bit value "fres" is reserved; implementations MUST set these 781 six bits to zero when sending, and MUST ignore them when receiving. 783 When the "URGp" bit is set, it indicates that the "urgent" field is 784 present, and thus that the plaintext value has the second structure 785 variant above; otherwise the first variant is used. 787 The meaning of "urgent" and of the flag bits is described in 788 Section 3.7. 790 4.2.2. Associated data 792 An application frame's "associated data" (which is supplied to the 793 AEAD algorithm when decrypting the ciphertext and verifying the 794 frame's integrity) has this format: 796 byte 0 1 2 797 +-------+-------+-------+ 798 |control| clen | 799 +-------+-------+-------+ 801 It contains the same values as the frame's "control" and "clen" 802 fields. 804 4.2.3. Frame nonce 806 Lastly, a "frame nonce" (provided as input to the AEAD algorithm) has 807 this format: 809 byte 810 +------+------+------+------+ 811 0 | FRAME_NONCE_MAGIC | 812 +------+------+------+------+ 813 4 | | 814 + offset + 815 8 | | 816 +------+------+------+------+ 818 The 4-byte magic constant is defined in Table 3. The 8-byte "offset" 819 field contains an integer in big-endian format. Its value is 820 specified in Section 3.6. 822 5. Key agreement schemes 824 The TEP negotiated via TCP-ENO may indicate the use of one of the 825 key-agreement schemes named in Table 1. For example, 826 "TCPCRYPT_ECDHE_P256" names the tcpcrypt protocol with key-agreement 827 scheme ECDHE-P256. 829 All schemes listed there use HKDF-Expand-SHA256 as the CPRF, and 830 these lengths for nonces and session keys: 832 N_A_LEN: 32 bytes 833 N_B_LEN: 32 bytes 834 K_LEN: 32 bytes 836 Key-agreement schemes ECDHE-P256 and ECDHE-P521 employ the ECSVDP-DH 837 secret value derivation primitive defined in [ieee1363]. The named 838 curves are defined in [nist-dss]. When the public-key values "PK_A" 839 and "PK_B" are transmitted as described in Section 4.1, they are 840 encoded with the "Elliptic Curve Point to Octet String Conversion 841 Primitive" described in Section E.2.3 of [ieee1363], and are prefixed 842 by a two-byte length in big-endian format: 844 byte 0 1 2 L - 1 845 +-------+-------+-------+---...---+-------+ 846 | pubkey_len | pubkey | 847 | = L | | 848 +-------+-------+-------+---...---+-------+ 850 Implementations SHOULD encode these "pubkey" values in "compressed 851 format", and MUST accept values encoded in "compressed", 852 "uncompressed" or "hybrid" formats. 854 Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 use the 855 functions X25519 and X448, respectively, to perform the Diffie-Helman 856 protocol as described in [RFC7748]. When using these ciphers, 857 public-key values "PK_A" and "PK_B" are transmitted directly with no 858 length prefix: 32 bytes for Curve25519, and 56 bytes for Curve448. 860 A tcpcrypt implementation MUST support at least the schemes 861 ECDHE-P256 and ECDHE-P521, although system administrators need not 862 enable them. 864 6. AEAD algorithms 866 Specifiers and key-lengths for AEAD algorithms are given in Table 2. 867 The algorithms "AEAD_AES_128_GCM" and "AEAD_AES_256_GCM" are 868 specified in [RFC5116]. The algorithm "AEAD_CHACHA20_POLY1305" is 869 specified in [RFC7539]. 871 7. IANA considerations 873 Tcpcrypt's TEP identifiers will need to be incorporated in IANA's 874 TCP-ENO encryption protocol identifier registry, as follows: 876 +------+---------------------------+ 877 | glt | Spec name | 878 +------+---------------------------+ 879 | 0x21 | TCPCRYPT_ECDHE_P256 | 880 | 0x22 | TCPCRYPT_ECDHE_P521 | 881 | 0x23 | TCPCRYPT_ECDHE_Curve25519 | 882 | 0x24 | TCPCRYPT_ECDHE_Curve448 | 883 +------+---------------------------+ 885 Table 1: TEP identifiers for use with tcpcrypt 887 A "tcpcrypt AEAD parameter" registry needs to be maintained by IANA 888 as in the following table. The use of encryption is described in 889 Section 3.6. 891 +------------------------+------------+------------+ 892 | AEAD Algorithm | Key Length | sym-cipher | 893 +------------------------+------------+------------+ 894 | AEAD_AES_128_GCM | 16 bytes | 0x01 | 895 | AEAD_AES_256_GCM | 32 bytes | 0x02 | 896 | AEAD_CHACHA20_POLY1305 | 32 bytes | 0x10 | 897 +------------------------+------------+------------+ 899 Table 2: Authenticated-encryption algorithms corresponding to sym- 900 cipher specifiers in Init1 and Init2 messages. 902 8. Security considerations 904 Public-key generation, public-key encryption, and shared-secret 905 generation all require randomness. Other tcpcrypt functions may also 906 require randomness, depending on the algorithms and modes of 907 operation selected. A weak pseudo-random generator at either host 908 will compromise tcpcrypt's security. Many of tcpcrypt's 909 cryptographic functions require random input, and thus any host 910 implementing tcpcrypt MUST have access to a cryptographically-secure 911 source of randomness or pseudo-randomness. 913 Most implementations will rely on system-wide pseudo-random 914 generators seeded from hardware events and a seed carried over from 915 the previous boot. Once a pseudo-random generator has been properly 916 seeded, it can generate effectively arbitrary amounts of pseudo- 917 random data. However, until a pseudo-random generator has been 918 seeded with sufficient entropy, not only will tcpcrypt be insecure, 919 it will reveal information that further weakens the security of the 920 pseudo-random generator, potentially harming other applications. As 921 required by TCP-ENO, implementations MUST NOT send ENO options unless 922 they have access to an adequate source of randomness. 924 The cipher-suites specified in this document all use HMAC-SHA256 to 925 implement the collision-resistant pseudo-random function denoted by 926 "CPRF". A collision-resistant function is one on which, for 927 sufficiently large L, an attacker cannot find two distinct inputs 928 "K_1", "CONST_1" and "K_2", "CONST_2" such that "CPRF(K_1, CONST_1, 929 L) = CPRF(K_2, CONST_2, L)". Collision resistance is important to 930 assure the uniqueness of session IDs, which are generated using the 931 CPRF. 933 All of the security considerations of TCP-ENO apply to tcpcrypt. In 934 particular, tcpcrypt does not protect against active eavesdroppers 935 unless applications authenticate the session ID. If it can be 936 established that the session IDs computed at each end of the 937 connection match, then tcpcrypt guarantees that no man-in-the-middle 938 attacks occurred unless the attacker has broken the underlying 939 cryptographic primitives (e.g., ECDH). A proof of this property for 940 an earlier version of the protocol has been published [tcpcrypt]. 942 To gain middlebox compatibility, tcpcrypt does not protect TCP 943 headers. Hence, the protocol is vulnerable to denial-of-service from 944 off-path attackers just as plain TCP is. Possible attacks include 945 desynchronizing the underlying TCP stream, injecting RST or FIN 946 segments, and forging rekey bits. These attacks will cause a 947 tcpcrypt connection to hang or fail with an error, but not in any 948 circumstance where plain TCP could continue uncorrupted. 949 Implementations MUST give higher-level software a way to distinguish 950 such errors from a clean end-of-stream (indicated by an authenticated 951 "FINp" bit) so that applications can avoid semantic truncation 952 attacks. 954 There is no "key confirmation" step in tcpcrypt. This is not 955 required because tcpcrypt's threat model includes the possibility of 956 a connection to an adversary. If key negotiation is compromised and 957 yields two different keys, all subsequent frames will be ignored due 958 to failed integrity checks, causing the application's connection to 959 hang. This is not a new threat because in plain TCP, an active 960 attacker could have modified sequence and acknowledgement numbers to 961 hang the connection anyway. 963 Tcpcrypt uses short-lived public keys to provide forward secrecy. 964 All currently specified key agreement schemes involve ECDHE-based key 965 agreement, meaning a new key can be efficiently computed for each 966 connection. If implementations reuse these parameters, they SHOULD 967 limit the lifetime of the private parameters, ideally to no more than 968 two minutes. 970 Attackers cannot force passive openers to move forward in their 971 session caching chain without guessing the content of the resumption 972 identifier, which will be difficult without key knowledge. 974 9. Design notes 976 9.1. Asymmetric roles 978 Tcpcrypt transforms a shared pseudo-random key (PRK) into 979 cryptographic session keys for each direction. Doing so requires an 980 asymmetry in the protocol, as the key derivation function must be 981 perturbed differently to generate different keys in each direction. 982 Tcpcrypt includes other asymmetries in the roles of the two hosts, 983 such as the process of negotiating algorithms (e.g., proposing vs. 984 selecting cipher suites). 986 9.2. Verified liveness 988 Many hosts implement TCP Keep-Alives [RFC1122] as an option for 989 applications to ensure that the other end of a TCP connection still 990 exists even when there is no data to be sent. A TCP Keep-Alive 991 segment carries a sequence number one prior to the beginning of the 992 send window, and may carry one byte of "garbage" data. Such a 993 segment causes the remote side to send an acknowledgment. 995 Unfortunately, tcpcrypt cannot cryptographically verify Keep-Alive 996 acknowledgments. Hence, an attacker could prolong the existence of a 997 session at one host after the other end of the connection no longer 998 exists. (Such an attack might prevent a process with sensitive data 999 from exiting, giving an attacker more time to compromise a host and 1000 extract the sensitive data.) 1002 Thus, tcpcrypt specifies a way to stimulate the remote host to send 1003 verifiably fresh and authentic data, described in Section 3.9. 1005 The TCP keep-alive mechanism has also been used for its effects on 1006 intermediate nodes in the network, such as preventing flow state from 1007 expiring at NAT boxes or firewalls. As these purposes do not require 1008 the authentication of endpoints, implementations may safely 1009 accomplish them using either the existing TCP keep-alive mechanism or 1010 tcpcrypt's verified keep-alive mechanism. 1012 10. Acknowledgments 1014 We are grateful for contributions, help, discussions, and feedback 1015 from the TCPINC working group, including Marcelo Bagnulo, David 1016 Black, Bob Briscoe, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Yoav 1017 Nir, Christoph Paasch, Eric Rescorla, and Kyle Rose. 1019 This work was funded by gifts from Intel (to Brad Karp) and from 1020 Google; by NSF award CNS-0716806 (A Clean-Slate Infrastructure for 1021 Information Flow Control); by DARPA CRASH under contract 1022 #N66001-10-2-4088; and by the Stanford Secure Internet of Things 1023 Project. 1025 11. Contributors 1027 Dan Boneh and Michael Hamburg were co-authors of the draft that 1028 became this document. 1030 12. References 1032 12.1. Normative References 1034 [I-D.ietf-tcpinc-tcpeno] 1035 Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. 1036 Smith, "TCP-ENO: Encryption Negotiation Option", draft- 1037 ietf-tcpinc-tcpeno-08 (work in progress), March 2017. 1039 [ieee1363] 1040 "IEEE Standard Specifications for Public-Key Cryptography 1041 (IEEE Std 1363-2000)", 2000. 1043 [nist-dss] 1044 "Digital Signature Standard, FIPS 186-2", 2000. 1046 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1047 Requirement Levels", BCP 14, RFC 2119, 1048 DOI 10.17487/RFC2119, March 1997, 1049 . 1051 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1052 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1053 . 1055 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1056 Key Derivation Function (HKDF)", RFC 5869, 1057 DOI 10.17487/RFC5869, May 2010, 1058 . 1060 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1061 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 1062 . 1064 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1065 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1066 2016, . 1068 12.2. Informative References 1070 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1071 Communication Layers", STD 3, RFC 1122, 1072 DOI 10.17487/RFC1122, October 1989, 1073 . 1075 [tcpcrypt] 1076 Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and D. 1077 Boneh, "The case for ubiquitous transport-level 1078 encryption", USENIX Security , 2010. 1080 Appendix A. Protocol constant values 1082 +------------+-------------------+ 1083 | Value | Name | 1084 +------------+-------------------+ 1085 | 0x01 | CONST_NEXTK | 1086 | 0x02 | CONST_SESSID | 1087 | 0x03 | CONST_REKEY | 1088 | 0x04 | CONST_KEY_A | 1089 | 0x05 | CONST_KEY_B | 1090 | 0x06 | CONST_RESUME | 1091 | 0x15101a0e | INIT1_MAGIC | 1092 | 0x097105e0 | INIT2_MAGIC | 1093 | 0x44415441 | FRAME_NONCE_MAGIC | 1094 +------------+-------------------+ 1096 Table 3: Protocol constants 1098 Authors' Addresses 1100 Andrea Bittau 1101 Google 1102 345 Spear Street 1103 San Francisco, CA 94105 1104 US 1106 Email: bittau@google.com 1108 Daniel B. Giffin 1109 Stanford University 1110 353 Serra Mall, Room 288 1111 Stanford, CA 94305 1112 US 1114 Email: dbg@scs.stanford.edu 1115 Mark Handley 1116 University College London 1117 Gower St. 1118 London WC1E 6BT 1119 UK 1121 Email: M.Handley@cs.ucl.ac.uk 1123 David Mazieres 1124 Stanford University 1125 353 Serra Mall, Room 290 1126 Stanford, CA 94305 1127 US 1129 Email: dm@uun.org 1131 Quinn Slack 1132 Sourcegraph 1133 121 2nd St Ste 200 1134 San Francisco, CA 94105 1135 US 1137 Email: sqs@sourcegraph.com 1139 Eric W. Smith 1140 Kestrel Institute 1141 3260 Hillview Avenue 1142 Palo Alto, CA 94304 1143 US 1145 Email: eric.smith@kestrel.edu