idnits 2.17.1 draft-bittau-tcp-crypt-04.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A host MUST NOT initiate re-keying if it initiated a re-keying less than 60 seconds ago and has not transmitted at least 1 Megabyte (increased its sequence number by 1,048,576) since the last re-keying. A host MUST NOT initiate re-keying if it has outstanding unacknowledged REKEY segments for key numbers that are 127 or more below the current key. A host SHOULD not initiate more than one concurrent re-key operation if it has no data to send. == 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 (February 14, 2014) is 3721 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1288 == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 2193, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 2199, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2437 (Obsoleted by RFC 3447) ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Bittau 3 Internet-Draft D. Boneh 4 Intended status: Standards Track M. Hamburg 5 Expires: August 18, 2014 Stanford University 6 M. Handley 7 University College London 8 D. Mazieres 9 Q. Slack 10 Stanford University 11 February 14, 2014 13 Cryptographic protection of TCP Streams (tcpcrypt) 14 draft-bittau-tcp-crypt-04.txt 16 Abstract 18 This document presents tcpcrypt, a TCP extension for 19 cryptographically protecting TCP segments. Tcpcrypt maintains the 20 confidentiality of data transmitted in TCP segments against a passive 21 eavesdropper. It protects connections against denial-of-service 22 attacks involving desynchronizing of sequence numbers, and when 23 enabled, against forged RST segments. Finally, applications that 24 perform authentication can obtain end-to-end confidentiality and 25 integrity guarantees by tying authentication to tcpcrypt Session ID 26 values. 28 The extension defines two new TCP options, CRYPT and MAC, which are 29 designed to provide compatible interworking with TCPs that do not 30 implement tcpcrypt. The CRYPT option allows hosts to negotiate the 31 use of tcpcrypt and establish shared secret encryption keys. The MAC 32 option carries a message authentication code with which hosts can 33 verify the integrity of transmitted TCP segments. Tcpcrypt is 34 designed to require relatively low overhead, particularly at servers, 35 so as to be useful even in the case of servers accepting many TCP 36 connections per second. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on August 18, 2014. 55 Copyright Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 85 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 3. Idealized protocol . . . . . . . . . . . . . . . . . . . . . . 5 87 3.1. Stages of the protocol . . . . . . . . . . . . . . . . . . 5 88 3.1.1. The setup phase . . . . . . . . . . . . . . . . . . . 6 89 3.1.2. The ENCRYPTING state . . . . . . . . . . . . . . . . . 6 90 3.1.3. The DISABLED state . . . . . . . . . . . . . . . . . . 7 91 3.2. Cryptographic algorithms . . . . . . . . . . . . . . . . . 7 92 3.3. "C" and "S" roles . . . . . . . . . . . . . . . . . . . . 9 93 3.4. Key exchange protocol . . . . . . . . . . . . . . . . . . 9 94 3.5. Data encryption and authentication . . . . . . . . . . . . 11 95 3.6. Authenticated Sequence Mode (ASM) . . . . . . . . . . . . 12 96 3.6.1. ASM-Encrypt . . . . . . . . . . . . . . . . . . . . . 14 97 3.6.2. ASM-Decrypt . . . . . . . . . . . . . . . . . . . . . 15 98 3.6.3. ASM-Update . . . . . . . . . . . . . . . . . . . . . . 15 99 3.7. Re-keying . . . . . . . . . . . . . . . . . . . . . . . . 16 100 3.8. Session caching . . . . . . . . . . . . . . . . . . . . . 16 101 3.8.1. Session caching control . . . . . . . . . . . . . . . 17 102 4. Extensions to TCP . . . . . . . . . . . . . . . . . . . . . . 17 103 4.1. Protocol states . . . . . . . . . . . . . . . . . . . . . 18 104 4.2. Role negotiation . . . . . . . . . . . . . . . . . . . . . 22 105 4.2.1. Simultaneous open . . . . . . . . . . . . . . . . . . 23 106 4.3. The TCP CRYPT option . . . . . . . . . . . . . . . . . . . 24 107 4.3.1. The HELLO suboption . . . . . . . . . . . . . . . . . 27 108 4.3.2. The DECLINE suboption . . . . . . . . . . . . . . . . 28 109 4.3.3. The NEXTK1 and NEXTK2 suboptions . . . . . . . . . . . 28 110 4.3.4. The PKCONF suboption . . . . . . . . . . . . . . . . . 30 111 4.3.5. The UNKNOWN suboption . . . . . . . . . . . . . . . . 31 112 4.3.6. The SYNCOOKIE and ACKCOOKIE suboptions . . . . . . . . 31 113 4.3.7. The SYNC_REQ and SYNC_OK suboptions . . . . . . . . . 32 114 4.3.8. The REKEY and REKEYSTREAM suboptions . . . . . . . . . 34 115 4.3.9. The INIT1 and INIT2 suboptions . . . . . . . . . . . . 36 116 4.3.10. The IV suboption . . . . . . . . . . . . . . . . . . . 38 117 4.4. The TCP MAC option . . . . . . . . . . . . . . . . . . . . 39 118 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 119 5.1. Example 1: Normal handshake . . . . . . . . . . . . . . . 41 120 5.2. Example 2: Normal handshake with SYN cookie . . . . . . . 41 121 5.3. Example 3: tcpcrypt unsupported . . . . . . . . . . . . . 42 122 5.4. Example 4: Reusing established state . . . . . . . . . . . 42 123 5.5. Example 5: Decline of state reuse . . . . . . . . . . . . 42 124 5.6. Example 6: Reversal of client and server roles . . . . . . 42 125 6. API extensions . . . . . . . . . . . . . . . . . . . . . . . . 43 126 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 127 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 128 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 129 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 130 10.1. Normative References . . . . . . . . . . . . . . . . . . . 48 131 10.2. Informative References . . . . . . . . . . . . . . . . . . 49 132 Appendix A. Protocol constant values . . . . . . . . . . . . . . 50 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 135 1. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 2. Introduction 143 This document describes tcpcrypt, an extension to TCP for 144 cryptographic protection of session data. Tcpcrypt was designed to 145 meet the following goals: 147 o Maintain confidentiality of communications against a passive 148 adversary. Ensure that an adversary must actively intercept and 149 modify the traffic to eavesdrop, either by re-encrypting all 150 traffic or by forcing a downgrade to an unencrypted session. 152 o Minimize computational cost, particularly on servers. 154 o Provide interfaces to higher-level software to facilitate end-to- 155 end security, either in the application level protocol or after 156 the fact. (E.g., client and server log session IDs and can 157 compare them after the fact; if there was no tampering or 158 eavesdropping, the IDs will match.) 160 o Be compatible with further extensions that allow authenticated 161 resumption of TCP connections when either end changes IP address. 163 o Facilitate multipath TCP [RFC6824] by identifying a TCP stream 164 with a session ID independent of IP addresses and port numbers. 166 o Provide for incremental deployment and graceful fallback, even in 167 the presence of NATs and other middleboxes that might remove 168 unknown options, and traffic normalizers. 170 3. Idealized protocol 172 This section describes the tcpcrypt protocol at an abstract level, 173 without reference to particular cryptographic algorithms or data 174 encodings. Readers who simply wish to see the key exchange protocol 175 should skip to Section 3.4. 177 3.1. Stages of the protocol 179 A tcpcrypt endpoint goes through multiple stages. It begins in a 180 setup phase and ends up in one of two states, ENCRYPTING or DISABLED, 181 before applications may send or receive data. The ENCRYPTING and 182 DISABLED states are definitive and mutually exclusive; an endpoint 183 that has been in one of the two states MUST NOT ever enter the other, 184 nor ever re-enter the setup phase. 186 3.1.1. The setup phase 188 The setup phase negotiates use of the tcpcrypt extension. During 189 this phase, two hosts agree on a suite of cryptographic algorithms 190 and establish shared secret session keys. 192 The setup phase uses the Data portion of TCP segments to exchange 193 cryptographic keys. Implementations MUST NOT include application 194 data in TCP segments during setup and MUST NOT allow applications to 195 read or write data. System calls MUST behave the same as for TCP 196 connections that have not yet entered the ESTABLISHED state; calls to 197 read and write SHOULD block or return temporary errors, while calls 198 to poll or select SHOULD consider connections not ready. 200 When setup succeeds, tcpcrypt enters the ENCRYPTING state. 201 Importantly, a successful setup also produces an important value 202 called the _Session ID_. The Session ID is tied to the negotiated 203 algorithms and cryptographic keys, and is unique over all time with 204 overwhelming probability. 206 Operating systems MUST make the Session ID available to applications. 207 To prevent man-in-the-middle attacks, applications MAY authenticate 208 the session ID through any protocol that ensures both endpoints of a 209 connection have the same value. Applications MAY alternatively just 210 log Session IDs so as to enable attack detection after the fact 211 through comparison of the values logged at both ends. 213 The setup phase can also fail for various reasons, in which case 214 tcpcrypt enters the DISABLED state. 216 Applications MAY test whether setup succeeded by querying the 217 operating system for the Session ID. Requests for the Session ID 218 MUST return an error when tcpcrypt is not in the ENCRYPTING state. 219 Applications SHOULD authenticate the returned Session ID. 220 Applications relying on tcpcrypt for security SHOULD authenticate the 221 Session ID and SHOULD treat unauthenticated Session IDs the same as 222 connections in the DISABLED state. 224 3.1.2. The ENCRYPTING state 226 When the setup phase succeeds, tcpcrypt enters the ENCRYPTING state. 227 Once in this state, applications may read and write data with the 228 expected semantics of TCP connections. 230 In the ENCRYPTING state, a host MUST encrypt the Data portion of all 231 TCP segments transmitted and MUST include a Message Authentication 232 Code (MAC) in all segments transmitted. A host MUST furthermore 233 ignore any TCP segments received without the RST bit set, unless 234 those segments also contain a valid MAC option. 236 A host SHOULD accept RST segments without valid MACs by default. 237 However, the application SHOULD be allowed to force unMACed RST 238 segments to be dropped by enabling the TCP_CRYPT_RSTCHK option on the 239 connection. 241 Once in the ENCRYPTING state, an endpoint MUST NOT directly or 242 indirectly transition to the DISABLED state under any circumstances. 244 3.1.3. The DISABLED state 246 When setup fails, tcpcrypt enters the DISABLED state. In this case, 247 the host MUST continue just as TCP would without tcpcrypt, unless 248 network conditions would cause a plain TCP connection to fail as 249 well. Entering the DISABLED state prohibits the endpoint from ever 250 entering the ENCRYPTING state. 252 An implementation MUST behave identically to ordinary TCP in the 253 DISABLED state, except that the first segment transmitted after 254 entering the DISABLED state MAY include a TCP CRYPT option with a 255 DECLINE suboption (and optionally other suboptions such as UNKNOWN) 256 to indicate that tcpcrypt is supported but not enabled. 257 Section 4.3.2 describes how this is done. 259 Operating systems MUST allow applications to turn off tcpcrypt by 260 setting the state to DISABLED before opening a connection. An active 261 opener with tcpcrypt disabled MUST behave identically to an 262 implementation of TCP without tcpcrypt. A passive opener with 263 tcpcrypt disabled MUST also behave like normal TCP, except that it 264 MAY optionally respond to SYN segments containing a CRYPT option with 265 SYN-ACK segments containing a DECLINE suboption, so as to indicate 266 that tcpcrypt is supported but not enabled. 268 3.2. Cryptographic algorithms 270 The setup phase employs three types of cryptographic algorithms: 272 o A _public key cipher_ is used with a short-lived public key to 273 exchange (or agree upon) a random, shared secret. 275 o An _extract function_ is used to generate a pseudo-random key from 276 some initial keying material, typically the output of the public 277 key chipher. The notation Extract (S, IKM) denotes the output of 278 the extract function with salt S and initial keying material IKM. 280 o A _collision-resistant pseudo-random function (CPRF)_ is used to 281 generate multiple cryptographic keys from a pseudo-random key, 282 typically the output of the extract function. We use the notation 283 CPRF (K, TAG, L) to designate the output of L bytes of the pseudo- 284 random function identified by key K on TAG. A collision-resistant 285 function is one on which, for sufficiently large L, an attacker 286 cannot find two distinct inputs K_1, TAG_1 and K_2, TAG_2 such 287 that CPRF (K_1, TAG_1, L) = CPRF (K_2, TAG_2, L). Collision 288 resistance is important to assure the uniqueness of Session IDs, 289 which are generated using the CPRF. 291 The Extract and CPRF functions used by default are the Extract and 292 Expand functions of HKDF [RFC5869]. These are defined as follows: 294 HKDF-Extract(salt, IKM) -> PRK 295 PRK = HMAC-Hash(salt, IKM) 297 HKDF-Expand(PRK, TAG, L) -> OKM 298 T(0) = empty string (zero length) 299 T(1) = HMAC-Hash(PRK, T(0) | TAG | 0x01) 300 T(2) = HMAC-Hash(PRK, T(1) | TAG | 0x02) 301 T(3) = HMAC-Hash(PRK, T(2) | TAG | 0x03) 302 ... 304 OKM = first L octets of T(1) | T(2) | T(3) | ... 306 The symbol | denotes concatenation, and the counter concatenated with 307 TAG is a single octet. 309 Because the public key cipher, the extract function, and the expand 310 function all make use of cryptographic hashes in their constructions, 311 the three algorithms are negotiated as a unit employing a single hash 312 function. For example, the OAEP+-RSA [RFC2437] cipher, which uses a 313 SHA-256-based mask-generation function, is coupled with HKDF 314 [RFC5869] using HMAC-SHA256 [RFC2104]. 316 The encrypting phase employs an _authenticated encryption mode_ to 317 encrypt all application data. This mode authenticates both 318 application data and most of the TCP header (excepting header fields 319 commonly modified by middleboxes). 321 Note that public key generation, public key encryption, and shared 322 secret generation all require randomness. Other tcpcrypt functions 323 may also require randomness depending on the algorithms and modes of 324 operation selected. A weak pseudo-random generator at either host 325 will defeat tcpcrypt's security. Thus, any host implementing 326 tcpcrypt MUST have a cryptographically secure source of randomness or 327 pseudo-randomness. 329 3.3. "C" and "S" roles 331 Tcpcrypt transforms a single pseudo-random key (PRK) into 332 cryptographic session keys for each direction. Doing so requires an 333 asymmetry in the protocol, as the key derivation function must be 334 perturbed differently to generate different keys in each direction. 335 Tcpcrypt includes other asymmetries in the roles of the two hosts, 336 such as the process of negotiating algorithms (e.g., proposing vs. 337 selecting cipher suites). 339 We use the terms "C" and "S" to denote the distinct roles of the two 340 hosts in tcpcrypt's setup phase. In the case of key transport, "C" 341 is the host that supplies a public key, while "S" is the host that 342 encrypts a pre-master secret with the key belonging to "C". Which 343 role a host plays can have performance implications, because for some 344 public key algorithms encryption is much faster than decryption. For 345 instance, on a machine at the time of writing, encryption with a 346 2,048-bit RSA-3 key costs 82 microseconds, while decryption costs 347 10 milliseconds. 349 Because servers often need to establish connections at a faster rate 350 than clients, and because servers are often passive openers, by 351 default the passive opener plays the "S" role. However, operating 352 systems MUST provide a mechanism for the passive opener to reverse 353 roles and play the "C" role, as discussed in Section 4.2. 355 3.4. Key exchange protocol 357 Every machine C has a short-lived public encryption key or key 358 agreement parameter, PK_C, which gets refreshed periodically and 359 SHOULD NOT ever be written to persistent storage. 361 When a host C connects to S, the two engage in the following 362 protocol: 364 C -> S: HELLO 365 S -> C: PKCONF, pub-cipher-list 366 C -> S: INIT1, sym-cipher-list, N_C, PK_C 367 S -> C: INIT2, sym-cipher, KX_S 369 The parameters are defined as follows: 371 o pub-cipher-list: a list of public key ciphers and parameters 372 acceptable to S. These are defined in Figure 3. 374 o sym-cipher-list: a list of symmetric cipher suites acceptable to 375 C. These are specified in Table 6. 377 o N_C: Nonce chosen at random by C. 379 o PK_C: C's public key or key agreement parameter. 381 o sym-cipher: the symmetric cipher selected by S. 383 o KX_S: key exchange information produced by S. KX_S will depend on 384 whether key transport is being done (e.g., RSA) or key agreement 385 (e.g., Diffie-Hellman). KX_S is defined in Table 1. 387 +----------------+-----------------+----------------------+ 388 | Cipher | KX_S | PMS | 389 +----------------+-----------------+----------------------+ 390 | OAEP+-RSA exp3 | ENC (PK_C, R_S) | R_S | 391 | ECDHE | N_S, PK_S | key-agreement-output | 392 +----------------+-----------------+----------------------+ 394 ENC (PK_C, R_S) denotes an encryption of R_S with public key PK_C. 395 R_S and N_S are random values chosen by S. Their lengths are defined 396 in Figure 3. PK_S is S's key agreement parameter. PMS is the Pre 397 Master Secret from which keys are ultimately derived. 399 Table 1 401 The two sides then compute a pseudo-random key (PRK) from which all 402 session keys are derived as follows: 404 param := { pub-cipher-list, sym-cipher-list, sym-cipher } 405 PRK := Extract (N_C, { param, PK_C, KX_S, PMS }) 407 A series of "session secrets" and corresponding Session IDs are then 408 computed as follows: 410 ss[0] := PRK 411 ss[i] := CPRF (ss[i-1], CONST_NEXTK, K_LEN) 413 SID[i] := CPRF (ss[i], CONST_SESSID, K_LEN) 415 The value ss[0] is used to generate all key material for the current 416 connection. SID[0] is the session ID for the current connection, and 417 will with overwhelming probability be unique for each individual TCP 418 connection. The most computationally expensive part of the key 419 exchange protocol is the public key cipher. The values of ss[i] for 420 i > 0 can be used to avoid public key cryptography when establishing 421 subsequent connections between the same two hosts, as described in 422 Section 3.8. The TAG values are constants defined in Table 7. The 423 K_LEN values along with nonce sizes are negotiated, and are specified 424 in Figure 3. 426 Given a session secret, ss, the two sides compute a series of master 427 keys as follows: 429 mk[0] := CPRF (ss, CONST_REKEY, K_LEN) 430 mk[i] := CPRF (mk[i-1], CONST_REKEY, K_LEN) 432 Finally, each master key mk is used to generate keys for 433 authenticated encryption for the "S" and "C" roles. Key k_cs is used 434 by "C" to encrypt and "S" to decrypt, while k_sc is used by "S" to 435 encrypt and "C" to decrypt. 437 k_cs := CPRF (mk, CONST_KEY_C, ae_len) 438 k_sc := CPRF (mk, CONST_KEY_S, ae_len) 440 tcpcrypt does not use HKDF directly for key derivation because it 441 requires multiple expand steps with different keys. This is needed 442 for forward secrecy so that ss[n] can be forgotten once a session is 443 established, and mk[n] can be forgotten once a session is rekeyed. 445 There is no key confirmation step in tcpcrypt. This is not required 446 since in tcpcrypt's threat model, a connection to an adversary can be 447 made and so keys need not be verified. If an erroneous key 448 negotiation that yields two different keys occurs, all subsequent 449 packets will be dropped due to an incorrect MAC, causing the TCP 450 connection to hang. This is not a threat because in plain TCP, an 451 active attacker could have modified sequence and ack numbers to hang 452 the connection anyway. 454 3.5. Data encryption and authentication 456 tcpcrypt encrypts and authenticates all application data. It also 457 authenticates some parts of the TCP header. There are several TCP- 458 specific constraints with regards to authenticated encryption that 459 tcpcrypt must meet for performance and compatibility with 460 middleboxes: 462 o The ciphertext for a particular byte position in tcpcrypt's 463 sequence must never change, even if reencryption occurs after 464 coalescing and retransmission. This is because a middlebox may 465 discard a changed payload on retransmission. 467 o Authentication must occur only on fields not modified by 468 middleboxes. In particular, port numbers must not be 469 authenticated, and sequence and ack numbers must be authenticated 470 according to an offset from the initial sequence number, because 471 these can be modulated by a middlebox. 473 o An efficient mechanism is needed for recomputing the 474 authentication tag when only the ack numbers change. For example, 475 on retransmissions, the authenticated encryption authentication 476 tag can be efficiently updated without having to recompute the tag 477 on the entire packet payload. 479 Authenticated encryption modes such as GCM do not meet these 480 criteria. For example, even with identical plaintext, ciphertext 481 values depend on the byte position at which one starts encrypting a 482 segment. Hence two small segments will appear to have different 483 content from their coalesced counterpart; middleboxes might drop such 484 coalesced retransmissions after falsely detecting subterfuge attacks. 485 Furthermore, existing authenticated encryption modes do not allow 486 efficient updating of the authentication tag when only small parts of 487 the data have changed. A new mode is needed to meet all these 488 constraints, and we introduce _Authenticated Sequence Mode_ (ASM) in 489 Section 3.6 as a solution. 491 ASM takes three parameters: a cipher, a MAC and an ACK MAC. At a 492 high-level, the cipher is used to encrypt the TCP payload in counter 493 mode, using a counter derived from TCP's sequence number. The MAC 494 covers the ciphertext and parts of the TCP header. The ACK MAC 495 covers the ACK numbers and is XORed with the previously computed MAC 496 to produce the authenticated encryption authentication tag. This tag 497 can be quickly updated if only the ACK numbers have changed. This 498 approach is principled because ACK messages are conceptually separate 499 from data packets, so MACing them separately is appropriate. In TCP, 500 ACKs are piggybacked to data segments merely as an optimization. 502 XORing two PRF-based MACs together was shown secure by Katz and 503 Lindell [aggregate-macs]. 505 3.6. Authenticated Sequence Mode (ASM) 507 ASM is parameterized by a cipher, MAC and ACK MAC. The operations 508 supported by ASM are: 510 ASM-Encrypt (PRK, Seq, Message, Assoc-Data, Up-Data) -> 511 (Ciphertext, Auth-Tag) 513 ASM-Decrypt (PRK, Seq, Cipher-Text, Assoc-Data, Up-Data, Auth-Tag) -> 514 { (Valid, Message) OR 515 (Invalid, ) 516 } 518 ASM-Update (PRK, Up-Data-Prev, Up-Data-New, Auth-Tag-Prev) -> 519 Auth-Tag 521 The arguments and return values are: 523 o _PRK_ a pseudo-random key. 525 o _Seq_ the byte position in the stream of Message or Cipher-Text. 526 In tcpcrypt, this is an extended version of TCP's sequence number. 528 o _Message_ the Message to encrypt. In tcpcrypt, this is TCP's 529 payload. 531 o _Assoc-Data_ the associated data to be MACed but not encrypted. 532 In tcpcrypt, this contains parts of the TCP header. 534 o _Up-Data_ the updatable data to be MACed but not encrypted, that 535 can also be efficiently updated and reMACed. In tcpcrypt, this 536 will cover an extended version of TCP's ACK numbers. 538 o _Ciphertext_ the encrypted version of Message. 540 o _Auth-Tag_ the authenticated encryption authentication tag. In 541 tcpcrypt, this will be the MAC option. 543 ASM-Decrypt either returns the Valid or Invalid constants, depending 544 on whether the authentication tag can be verified successfully or 545 not. For Valid inputs, the Message is returned as well. 547 The PRK supplied to ASM is expanded into keys used for individual 548 operation as follows: 550 k_enc := CPRF (PRK, CONST_KEY_ENC, cipher-key-len) 551 k_mac := CPRF (PRK, CONST_KEY_MAC, mac-key-len) 552 k_ack := CPRF (PRK, CONST_KEY_ACK, ack-mac-key-len) 554 The next sections describe ASM operations in detail. 556 3.6.1. ASM-Encrypt 558 The interface to encrypt is as follows: 560 ASM-Encrypt (PRK, Seq, Message, Assoc-Data, Up-Data) -> 561 (Ciphertext, Auth-Tag) 563 Keys (denoted by k_*) are derived from PRK as explained in 564 Section 3.6. 566 The following steps occur: 568 1. Message is encrypted to produce Ciphertext using the cipher in 569 counter mode. Seq is the counter and k_enc is the key. When 570 encrypting Seq, its value must always be a multiple of the 571 cipher's block size. In the event that the message does not 572 begin on an even block boundary, Seq must be rounded down, 573 encrypted, and leading bytes of its encryption discarded. 575 2. The MAC is run over the concatenation of Ciphertext and Assoc- 576 Data to produce MAC1, using k_mac as the key. 578 3. The ACK MAC is run over Up-Data to produce MAC2, using k_ack as 579 the key. 581 4. MAC1 and MAC2 are XORed to produce Auth-Tag. 583 Using AES-128 as an example, encryption in counter mode using Seq as 584 the counter happens as follows. 586 o Compute B = Seq - (Seq % 16). 588 o Let B* = 0^{128-|B|} | B be B in network (big-endian) byte order 589 with enough 0 bits pre-pended to make B* exactly 128 bits long. 591 o Let C = ENC-AES (ke, B*). 593 o Discard the first (Seq-B) bytes on C and begin byte-by-byte XORing 594 the remaining portion with the message. 596 If AES-128 is used as the ACK MAC, the Ack number (64-bit extended, 597 offset from ISN) is first padded on the left with enough zeros to 598 produce a 128-bit big-endian value. The number is then encrypted 599 using AES. 601 3.6.2. ASM-Decrypt 603 The interface to decrypt is as follows: 605 ASM-Decrypt (PRK, Seq, Cipher-Text, Assoc-Data, Up-Data, Auth-Tag) -> 606 { (Valid, Message) OR 607 (Invalid, ) 609 Keys (denoted by k_*) are derived from PRK as explained in 610 Section 3.6. 612 The following steps occur: 614 1. The MAC is run over the concatenation of Ciphertext and Assoc- 615 Data to produce MAC1, using k_mac as the key. 617 2. The ACK MAC is run over Up-Data to produce MAC2, using k_ack as 618 the key. 620 3. MAC1 and MAC2 are XORed and compared to Auth-Tag. If different, 621 the process stops and the constant Invalid is returned along with 622 no message. Otherwise the process continues. 624 4. Ciphertext is decrypted to produce Message using the cipher in 625 counter mode. Seq is the counter and k_enc is the key. The 626 Valid constant is returned along with Message. 628 3.6.3. ASM-Update 630 The interface to update the authenticated encryption authentication 631 tag is as follows: 633 ASM-Update (PRK, Up-Data-Prev, Up-Data-New, Auth-Tag-Prev) -> 634 Auth-Tag 636 Keys (denoted by k_*) are derived from PRK as explained in 637 Section 3.6. 639 The following steps occur: 641 1. The ACK MAC is run over Up-Data-Prev using k_ack to produce MAC2- 642 Prev. 644 2. MAC2-Prev is XORed with Auth-Tag-Prev to produce MAC1. 646 3. The ACK MAC is run over Up-Data to produce MAC2, using k_ack as 647 the key. 649 4. MAC1 and MAC2 are XORed to produce Auth-Tag. 651 3.7. Re-keying 653 We refer to the two encryption keys (k_cs, k_sc) as a _key set_. We 654 refer to the key set generated by mk[i] as the key set with 655 _generation number_ i within a session. Initially, the two hosts use 656 the key set with generation number 0. 658 Either host may decide to evolve the encryption key at one or more 659 points within a session, by incrementing the generation number of its 660 transmit keys. When switching keys to generation j, a host must 661 label the segments it transmits with a REKEY option containing j, so 662 that the recipient host knows to check the MAC and decrypt the 663 segment using the new keyset: 665 A -> B: REKEY, MAC<...>, Data<...> 667 Upon receiving a REKEY segment, a recipient using transmit keys 668 from a generation less than j must also update its transmit keys and 669 start including a REKEY option in all of its segments. A host 670 must continue transmitting REKEY options until all segments with 671 other generation numbers have been processed at both ends. 673 Implementations MUST always transmit and retransmit identical 674 ciphertext Data bytes for the same TCP sequence numbers. Thus, a 675 retransmitted segment MUST always use the same keyset as the original 676 segment. Hosts MUST NOT combine segments that were encrypted with 677 different keysets. 679 Implementations SHOULD delete older-generation keys from memory once 680 they have received all segments they will need to decrypt with the 681 old keys and received acknowledgments for all segments they might 682 need to retransmit. 684 3.8. Session caching 686 When two hosts have already negotiated session secret ss[i-1], they 687 can establish a new connection without public key operations using 688 ss[i]. The four-message protocol of Section 3.4 is replaced by: 690 A -> B: NEXTK1, SID[i] 691 B -> A: NEXTK2 693 Which symmetric keys a host uses for transmitted segments is 694 determined by its role in the original session ss[0]. It does not 695 depend on which host is the passive opener in the current session. 696 If A had the "C" role in the first session, then A uses k_cs for 697 sending segments and k_sc for receiving. Otherwise, if A had the "S" 698 role originally, it uses k_sc and k_cs, respectively. B similarly 699 uses the transmit keys that correspond to its role in the original 700 session. 702 After using ss[i] to compute mk[0], implementations SHOULD compute 703 and cache ss[i+1] for possible use by a later session, then erase 704 ss[i] from memory. Hosts SHOULD keep ss[i+1] around for a period of 705 time until it is used or the memory needs to be reclaimed. Hosts 706 SHOULD NOT write a cached ss[i+1] value to non-volatile storage. 708 It is an implementation-specific issue as to how long ss[i+1] should 709 be retained if it is unused. If the passive opener times it out 710 before the active opener does, the only cost is the additional twelve 711 bytes to send NEXTK1 for the next connection. The behavior then 712 falls back to a normal public-key handshake. 714 3.8.1. Session caching control 716 Implementations MUST allow applications to control session caching by 717 setting the following option: 719 TCP_CRYPT_CACHE_FLUSH When set on a TCP endpoint that is in the 720 ENCRYPTING state, this option causes the operating system to flush 721 from memory the cached ss[i+1] (or ss[i+1+n] if other connections 722 have already been established). When set on an endpoint that is 723 in the setup phase, causes any cached ss[i] that would have been 724 used to be flushed from memory. In either case, future 725 connections will have to undertake another round of the public key 726 protocol in Section 3.4. Applications SHOULD set 727 TCP_CRYPT_CACHE_FLUSH whenever authentication of the session ID 728 fails. 730 4. Extensions to TCP 732 The tcpcrypt extension adds two new kinds of option: CRYPT, and MAC. 733 Both are described in this section. During the setup phase, all TCP 734 segments MUST have the CRYPT option. In the ENCRYPTING state, all 735 segments MUST have the MAC option and may include the CRYPT option 736 for various purposes such as re-keying or keep-alive probes. 738 The idealized protocol of the previous section must be embedded in 739 the TCP handshake. Unfortunately, since the maximum TCP header size 740 is 60 bytes and the basic TCP header fields require 20 bytes, there 741 are at most 40 option payload bytes available, which is not enough to 742 hold the INIT1 and INIT2 messages. Tcpcrypt therefore uses the Data 743 portion of TCP segments (after the SYN exchanges) to send the body of 744 these messages. 746 Operating systems MUST keep track of which phase a data segment 747 belongs to, and MUST only deliver data to applications from segments 748 that are processed in the ENCRYPTING or DISABLED states. 750 4.1. Protocol states 752 The setup phase is divided into six states: CLOSED, NEXTK-SENT, 753 HELLO-SENT, C-MODE, LISTEN, and S-MODE. Together with the ENCRYPTING 754 and DISABLED states already discussed, this means a tcpcrypt endpoint 755 can be in one of eight states. 757 In addition to tcpcrypt's state, each endpoint will also be in one of 758 the 11 TCP states described in the TCP protocol specification 759 [RFC0793]. Not all pairs of states are valid. Table 2 shows which 760 TCP states an endpoint can be in for each tcpcrypt state. 762 +-------------+--------------------------+--------------------------+ 763 | Tcpcrypt | TCP states for an active | TCP states for a passive | 764 | state | opener | opener | 765 +-------------+--------------------------+--------------------------+ 766 | CLOSED | CLOSED | CLOSED | 767 | NEXTK-SENT | SYN-SENT | n/a | 768 | HELLO-SENT | SYN-SENT | SYN-RCVD | 769 | C-MODE | ESTABLISHED, FIN-WAIT-1 | ESTABLISHED, FIN-WAIT-1 | 770 | LISTEN | n/a | LISTEN | 771 | S-MODE | (SYN-RCVD), ESTABLISHED | SYN-RCVD | 772 | ENCRYPTING | (SYN-RCVD), ESTABLISHED+ | SYN-RCVD, ESTABLISHED+ | 773 | DISABLED | any | any | 774 +-------------+--------------------------+--------------------------+ 776 Valid tcpcrypt and TCP state combinations. States in parentheses 777 occur only with simultaneous open. ESTABLISHED+ means ESTABLISHED or 778 any later state (FIN-WAIT-1, FIN-WAIT-2, CLOSING, TIME-WAIT, CLOSE- 779 WAIT, or LAST-ACK). 781 Table 2 783 Figure 1 shows how tcpcrypt transitions between states. Each 784 transition is labeled by events that may trigger the transition above 785 the line, and an action the local host is permitted to take in 786 response below the line. "snd" and "rcv" denote sending and receiving 787 segments, respectively. "any" means any possible event. "internal" 788 means any possible event except for receiving a segment (i.e., timers 789 and system calls). "drop" means discarding the last received segment 790 and preventing it from having any effect on TCP's state. "mac" means 791 any valid TCP action, including no action, except that any segments 792 transmitted must be encrypted and contain a valid TCP MAC option. "x" 793 indicates that a host sends no segments when taking a transition. 795 A segment is described as "F/Op". F specifies constraints on the 796 control bits of the TCP header, as follows: 798 +----+------------------------------+ 799 | F | Meaning | 800 +----+------------------------------+ 801 | S | SYN=1, ACK=0, FIN=0, RST=0 | 802 | SA | SYN=1, ACK=1, FIN=0, RST=0 | 803 | A | SYN=0, ACK=1, FIN=0, RST=0 | 804 | S? | SYN=1, ACK=any, FIN=0, RST=0 | 805 | ?A | SYN=any, ACK=1, FIN=0, RST=0 | 806 | R | RST=1 | 807 | * | any | 808 +----+------------------------------+ 810 Op designates message types in the abstract protocol, which also 811 correspond to particular suboptions of the TCP CRYPT option, 812 described in Section 4.3, or "MAC" for a valid TCP MAC option, as 813 described in Section 4.4. A segment with SYN=1 and ACK=0 that 814 contains the NEXTK1 suboption will also explicitly or implicitly 815 contain the HELLO suboption; such a segment matches event constraints 816 on either option--e.g., it matches any of the "rcv S/HELLO", "rcv 817 S?/HELLO", and "rcv S/NEXTK1" events. An empty Op matches any 818 segment with the appropriate control bits. A segment MUST contain 819 the TCP MAC option if and only if Op is "MAC". 821 The "drop" transitions from NEXTK-SENT and HELLO-SENT to HELLO-SENT 822 change TCP slightly by ignoring a segment and preventing a TCP 823 transition from SYN-SENT to SYN-RCVD that would otherwise occur 824 during simultaneous open. Therefore, these transitions SHOULD be 825 disabled by default. They MAY be enabled on one side by an 826 application that wishes to enable tcpcrypt on simultaneous open, as 827 discussed in Section 4.2.1. 829 active OPEN passive OPEN 830 ------------ +----------+ ------------ +----------+ 831 snd S/NEXTK1 | CLOSED | x | LISTEN | 832 +-------------------| |------------->| |---------+ 833 | +----------+ +----------+ | 834 | +---+ |active OPEN | | | 835 | rcv S/HELLO| | |----------- rcv S/HELLO| | rcv S/NEXTK1| 836 | -----------| | |snd S/HELLO ------------| | -------------| 837 V drop| V V snd SA/HELLO| | snd SA/NEXTK2| 838 +----------+ | +----------+ | | | 839 | NEXTK- |___/ \| HELLO- |<------------------+ | | 840 | SENT | | SENT | |rcv S/HELLO | 841 +----------+ +----------+ |------------- | 842 | | | | |rcv S?/HELLO |snd SA/PKCONF | 843 | | |rcv S?/HELLO | |------------- V | 844 | | |------------- | |snd ?A/PKCONF +----------+ | 845 | | |snd ?A/PKCONF | +---------------->| S-MODE | | 846 | | +----------------|------------------>| | | 847 | +----------------+ | +----------+ | 848 | rcv SA/PKCONF| |rcv ?A/PKCONF | | 849 | -------------| |------------- |rcv A/INIT1 | 850 | snd A/INIT1| |snd A/INIT1 |----------- | 851 | V V |snd A/INIT2 | 852 | +----------+ | | 853 |rcv SA/NEXTK2 | C-MODE | +---+ | +---+ | 854 |------------- | | rcv */ | | | | |internal | 855 |snd A/MAC +----------+ -------| | | | |or rcv */MAC | 856 | == or == |rcv A/INIT2 drop| | | | |or rcv R/ | 857 |rcv S/NEXTK1 |----------- | V V V |------------ | 858 |------------ |x +----------+ |mac | 859 |snd SA/NEXTK2 +------------------>|ENCRYPTING|-+ | 860 +------------------------------------->| |<---------------+ 861 +----------+ 863 State diagram for tcpcrypt. Transitions to DISABLED and CLOSED are 864 not shown. 866 Figure 1 868 Any segment that would be discarded by TCP (e.g., for being out of 869 window) MUST also be ignored by tcpcrypt. However, certain segments 870 that might otherwise be accepted by TCP MUST be dropped by tcpcrypt 871 and prevented from affecting TCP's state. 873 Except for these drop actions, tcpcrypt MUST abide by the TCP 874 protocol specification [RFC0793]. Thus, any segment transmitted by a 875 host MUST be permitted by the TCP specification in addition to 876 matching either a transition in Figure 1 or one of the transitions to 877 DISABLED or CLOSED described below. In particular, a host MUST NOT 878 acknowledge an INIT1 segment unless either the acknowledgment 879 contains an INIT2 or the host transitions to DISABLED. 881 Various events cause transitions to DISABLED from states other than 882 ENCRYPTING. In particular: 884 o Operating systems MUST provide a mechanism for applications to 885 transition to DISABLED from the CLOSED and LISTEN states. 887 o A host in the setup phase MUST transition to DISABLED upon 888 receiving any segment without a TCP CRYPT option. 890 o A host in the setup phase MUST transition to DISABLED upon 891 receiving any segment with the FIN or RST control bit set. 893 o A host in the setup phase MUST transition to DISABLED upon sending 894 a segment with the FIN bit set. (As discussed below, however, a 895 host MUST NOT send a FIN segment from the C-MODE state.) 897 Other specific conditions cause a transition to DISABLED and are 898 discussed in the sections that follow. 900 CLOSED is a pseudo-state representing a connection that does not 901 exist. A tcpcrypt connection's lifetime is identical to that of its 902 associated TCP connection. Thus, tcpcrypt transitions to CLOSED 903 exactly when TCP transitions to CLOSED. 905 A host MUST NOT send a FIN segment from the C-MODE state. The reason 906 is that the remote side can be in the ENCRYPTING state and would thus 907 require the segment to contain a valid MAC, yet a host in C-MODE 908 cannot compute the necessary encryption keys before receiving the 909 INIT2 segment. 911 If a CLOSE happens in C-MODE, a host MUST delay sending a FIN segment 912 until receiving an ACK for its INIT1 segment. If the remote host is 913 in ENCRYPTING, the ACK segment will contain INIT2 and the local host 914 can transition to ENCRYPTING before sending the FIN. If the remote 915 host is not in ENCRYPTING, the ACK will not contain INIT2, and thus 916 the local host can transition to DISABLED before sending the FIN. 918 If a CLOSE happens in C-MODE, an implementation MAY delay processing 919 the CLOSE event and entering the TCP FIN-WAIT-1 state until sending 920 the FIN. If it does not, the implementation MUST ensure all relevant 921 timers correspond to the time of transmission of the FIN segment, not 922 the time of entry into the FIN-WAIT-1 state. 924 The only valid tcpcrypt state transition from ENCRYPTING is to 925 CLOSED, which occurs only when TCP transitions to CLOSED. tcpcrypt 926 per-se cannot cause TCP to transition to CLOSED. 928 4.2. Role negotiation 930 A passive opener receiving an S/HELLO segment may choose to play the 931 "S" role (by transitioning to S-MODE) or the "C" role (by 932 transitioning to HELLO-SENT). An active opener may accept the role 933 not chosen by the passive opener, or may instead disable tcpcrypt. 934 During simultaneous open, one endpoint must choose the "C" role while 935 the other chooses the "S" role. Operating systems MUST allow 936 applications to guide these choices on a per-connection basis. 938 Applications SHOULD be able to exert this control by setting a per- 939 connection _CMODE disposition_, which can take on one of the 940 following five values: 942 TCP_CRYPT_CMODE_DEFAULT This disposition SHOULD be the default. A 943 passive opener will only play the "S" role, but an active opener 944 can play either the "C" or the "S" role. Simultaneous open 945 without session caching will cause tcpcrypt to be disabled unless 946 the remote host has set the TCP_CMODE_ALWAYS[_NK] disposition. 948 TCP_CRYPT_CMODE_ALWAYS 950 TCP_CRYPT_CMODE_ALWAYS_NK With this disposition, a host will only 951 play the "C" role. The _NK version additionally prevents the use 952 of session caching if the session was originally established in 953 the "S" role. 955 TCP_CRYPT_CMODE_NEVER 957 TCP_CRYPT_CMODE_NEVER_NK With this disposition, a host will only 958 play the "S" role. The _NK version additionally prevents the use 959 of session caching if the session was originally established in 960 the "C" role. 962 The CMODE disposition prohibits certain state transitions, as 963 summarized in Table 3. If an event occurs for which all valid 964 transitions in Figure 1 are prohibited, a host MUST transition to 965 DISABLED. Operating systems MAY add additional CMODE dispositions, 966 for instance to force or prohibit session caching. 968 +-----------------------------+---------------------------+ 969 | CMODE disposition | Prohibited transitions | 970 +-----------------------------+---------------------------+ 971 | TCP_CRYPT_CMODE_DEFAULT | LISTEN --> HELLO-SENT | 972 | | HELLO-SENT --> HELLO-SENT | 973 | | NEXTK-SENT --> HELLO-SENT | 974 | | | 975 | TCP_CRYPT_CMODE_ALWAYS[_NK] | any --> S-MODE | 976 | | | 977 | TCP_CRYPT_CMODE_NEVER[_NK] | LISTEN --> HELLO-SENT | 978 | | HELLO-SENT --> HELLO-SENT | 979 | | NEXTK-SENT --> HELLO-SENT | 980 | | any --> C-MODE | 981 +-----------------------------+---------------------------+ 983 State transitions prohibited by each CMODE disposition 985 Table 3 987 4.2.1. Simultaneous open 989 During simultaneous open, two ends of a TCP connection are both 990 active openers. If both hosts attempt to use session caching by 991 simultaneously transmitting S/NEXTK1 segments, and if both transmit 992 the same session ID, then both may reply with SA/NEXTK2 segments and 993 immediately enter the ENCRYPTING state. In this case, the host that 994 played "C" when the session was initially negotiated MUST use the 995 symmetric encryption keys for "C" (i.e., encrypt with k_cs, decrypt 996 with k_sc), while the host that initially played "S" uses the "S" 997 keys for the new connection. 999 If both hosts in a simultaneous open do not attempt to use session 1000 caching, or if the two hosts use incompatible Session IDs, then they 1001 MUST engage in public-key-based key negotiation to use tcpcrypt. 1002 Doing so requires one host to play the "C" role and the other to play 1003 the "S" role. With the TCP_CRYPT_CMODE_DEFAULT disposition, these 1004 roles are usually determined by the passive opener choosing the "S" 1005 role. With no passive opener, both active openers will end up in 1006 S-MODE, then transition to DISABLED upon receiving an unexpected 1007 PKCONF. 1009 Simultaneous open can work with key negotiation if exactly one of the 1010 two hosts selects the TCP_CRYPT_CMODE_ALWAYS disposition. This host 1011 will then drop S/HELLO segments and remain in C-MODE while the other 1012 host transitions to S-MODE. Applications SHOULD NOT set 1013 TCP_CRYPT_CMODE_ALWAYS on both sides of a simultaneous open, as this 1014 will result in tcpcrypt being disabled. The reception of two 1015 simultaneous HELLO (or NEXTK) messages will disable tcpcrypt because 1016 it is not explicit as to who is playing the "C" or "S" role. 1018 4.3. The TCP CRYPT option 1020 A CRYPT option has the following format: 1022 Byte 0 1 2 N 1023 +-------+-------+-------...-------+ 1024 | Kind= |Length=| Suboptions | 1025 | OPT1 | N | | 1026 +-------+-------+-------...-------+ 1028 Format of TCP CRYPT option 1030 Kind is always OPT1. Length is the total length of the option, 1031 including the two bytes used for Kind and Length. These first two 1032 bytes are then followed by zero or more suboptions. Suboptions 1033 determine the meaning of the TCP CRYPT option. When a TCP header 1034 contains more than one CRYPT option, a host MUST interpret them the 1035 same as if all the suboptions appeared in a single CRYPT option. 1036 This makes tcpcrypt options future-proof as new suboptions can be 1037 placed in a separate CRYPT option, which can be ignored if not 1038 understood, while other CRYPT options can still be processed. 1040 Each suboption begins with an Opcode byte. The specific format of 1041 the option depends on the two most significant bits of the Opcode. 1043 Suboptions with opcodes from 0x00 to 0x3f contain no data other than 1044 the single opcode byte: 1046 bit 0 1 2 3 4 5 6 7 1047 +-+-+-+-+-+-+-+-+ 1048 | Opcode = | 1049 |0 0 x x x x x x| 1050 +-+-+-+-+-+-+-+-+ 1052 Hosts MUST ignore any opcodes of this format that they do not 1053 recognize. 1055 Suboptions with opcodes from 0x40 to 0x7f contain an opcode, a length 1056 field, and data bytes. 1058 0 1 1059 bit 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------... 1061 | Opcode = | Length = | N-2 bytes 1062 |0 1 x x x x x x| N | of suboption data 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------... 1065 Hosts MUST ignore any opcodes of this format that they do not 1066 recognize. 1068 Suboptions with opcodes from 0x80 to 0xbf contain zero or more bytes 1069 of data whose length depends on the opcode. These suboptions can be 1070 either fixed length or variable length; implementations that 1071 understand these opcodes will known which they are; if the suboption 1072 is fixed length the implementation will know the length; otherwise it 1073 will know where to look for the length field. 1075 bit 0 1 2 3 4 5 6 7 1076 +-+-+-+-+-+-+-+-+-------... 1077 | Opcode = | data 1078 |1 0 x x x x x x| 1079 +-+-+-+-+-+-+-+-+-------... 1081 If a host sees an unknown opcode in this range, it MUST ignore the 1082 suboption and all subsequent suboptions in the same TCP CRYPT option. 1083 However, if more than one CRYPT option appears in the TCP header, the 1084 host MUST continue processing suboptions from the next TCP CRYPT 1085 option. Skipping suboptions in the TCP CRYPT option applies only to 1086 this option range since the length of the suboption cannot be 1087 determined by the receiver. In other cases, where the length is 1088 known, the receiver skips to the next suboption. 1090 Suboptions with opcodes from 0xc0 to 0xff also contain an opcode- 1091 specific length of data. As before, these suboptions can be either 1092 fixed length or variable length. However, suboptions in this range 1093 are classed as mandatory as far as the protocol is concerned. 1094 However, they are not MANDATORY to implement unless otherwise stated, 1095 as discussed below. 1097 bit 0 1 2 3 4 5 6 7 1098 +-+-+-+-+-+-+-+-+-------... 1099 | Opcode = | data 1100 |1 1 x x x x x x| 1101 +-+-+-+-+-+-+-+-+-------... 1103 Should a host encounter an unknown opcode greater than or equal to 1104 0xc0 during the setup phase of the protocol, the host MUST transition 1105 to the DISABLED state. It SHOULD respond with both a DECLINE 1106 suboption and an UNKNOWN suboption specifying the opcode of the 1107 unknown mandatory suboption, after which the host MUST NOT send any 1108 further CRYPT options. 1110 Should a host encounter an unknown opcode greater than or equal to 1111 0xc0 while in the ENCRYPTING state, the host MUST respond with an 1112 UNKNOWN suboption specifying the opcode of the unknown mandatory 1113 suboption, and should ensure the session continues with the same 1114 encryption and authentication state as it had before the segment was 1115 received. This may require ignoring other suboptions within the same 1116 message, or reverting any half-negotiated state. 1118 Table 4 summarizes the opcodes discussed in this document. It is 1119 MANDATORY that all implementations support every opcode in this 1120 table. Each opcode is listed with the length in bytes of the 1121 suboption (including the opcode byte), or * for variable-length 1122 suboptions. The last column specifies in which of the (S)etup phase, 1123 (E)NCRYPTING state, and (D)ISABLED state an opcode may be used. A 1124 host MUST NOT send an option unless it is in one of the stages 1125 indicated by this column. 1127 +-------+--------+---------------------+--------+ 1128 | Value | Length | Name | Stages | 1129 +-------+--------+---------------------+--------+ 1130 | 0x01 | 1 | HELLO | S | 1131 | 0x02 | 1 | HELLO-app-support | S | 1132 | 0x03 | 1 | HELLO-app-mandatory | S | 1133 | 0x04 | 1 | DECLINE | SD | 1134 | 0x05 | 1 | NEXTK2 | S | 1135 | 0x06 | 1 | NEXTK2-app-support | S | 1136 | 0x07 | 1 | INIT1 | S | 1137 | 0x08 | 1 | INIT2 | S | 1138 | 0x41 | * | PKCONF | S | 1139 | 0x42 | * | PKCONF-app-support | S | 1140 | 0x43 | * | UNKNOWN | SED | 1141 | 0x44 | * | SYNCOOKIE | S | 1142 | 0x45 | * | ACKCOOKIE | SED | 1143 | 0x80 | 5 | SYNC_REQ | E | 1144 | 0x81 | 5 | SYNC_OK | E | 1145 | 0x82 | 2 | REKEY | E | 1146 | 0x83 | 6 | REKEYSTREAM | E | 1147 | 0x84 | 10 | NEXTK1 | S | 1148 | 0x85 | * | IV | E | 1149 +-------+--------+---------------------+--------+ 1151 Opcodes for suboptions of the TCP CRYPT option. 1153 Table 4 1155 If a TCP segment (sent by an active opener) has the SYN flag set, the 1156 ACK flag clear, and one or more TCP CRYPT options, there is an 1157 implicit HELLO suboption even if that suboption does not appear in 1158 the segment. In particular, when such a SYN segment contains a 1159 single, empty, two-byte TCP CRYPT option, the passive opener MUST 1160 interpret that option as equivalent to the three-byte TCP option 1161 composed of bytes OPT1, 3, 1 (Kind = OPT1, Length = 3, Suboption = 1162 HELLO). 1164 A host MUST enter the DISABLED state if, during the setup phase, it 1165 receives a segment containing neither a TCP CRYPT nor a TCP MAC 1166 option. This is for robustness against middleboxes that strip 1167 options. A host MUST also enter DISABLED if, during the setup phase, 1168 it receives a DECLINE suboption or any unrecognized suboption with 1169 opcode greater than or equal to 0xc0. The DECLINE option is the 1170 preferred way for a host to refuse tcpcrypt. A host MAY also choose 1171 reply without a TCP CRYPT option to disable tcpcrypt. Once a host 1172 has entered DISABLED, it MUST NOT include the MAC option in any 1173 transmitted segment. The host MAY include a CRYPT option in the next 1174 segment transmitted, but only if the segment also contains the 1175 DECLINE suboption. All subsequently transmitted packets MUST NOT 1176 contain the CRYPT option. 1178 4.3.1. The HELLO suboption 1180 The HELLO dataless suboption MUST only appear in a segment with the 1181 SYN control bit set. It is used by an active opener to indicate 1182 interest in using tcpcrypt for a connection, and by a passive opener 1183 to indicate that the passive opener wishes to play the "C" role. 1185 The initial SYN segment from an active opener wishing to use tcpcrypt 1186 MUST contain a TCP CRYPT option with either an explicit or an 1187 implicit HELLO suboption. 1189 After receiving a SYN segment with the HELLO suboption, a passive 1190 opener MUST respond in one of three ways: 1192 o To continue setting up tcpcrypt and play the "S" role, the passive 1193 opener MUST respond with a PKCONF suboption in the SYN-ACK segment 1194 and transition to S-MODE. 1196 o To continue setting up tcpcrypt and play the "C" role, the passive 1197 opener MUST respond with a HELLO suboption in the SYN-ACK segment 1198 and transition to HELLO-SENT. 1200 o To continue without tcpcrypt, the passive opener MUST respond with 1201 either no CRYPT option or the DECLINE suboption in the SYN-ACK 1202 segment, then transition to the DISABLED state. 1204 An active opener receiving HELLO in a SYN-ACK segment must either 1205 transition to S-MODE and respond with a PKCONF suboption, or 1206 transition to DISABLED. 1208 There are three variants of the HELLO option used for application- 1209 level authentication, each encoded differently as shown in Table 4. 1210 The variants are: a plain HELLO where the application is not 1211 tcpcrypt-aware (but the kernel is), an "application supported" HELLO 1212 where the application is tcpcrypt-aware and is advertising the fact, 1213 and a "application mandatory" HELLO where the application requires 1214 the remote application to support tcpcrypt otherwise the connection 1215 MUST revert to plain TCP. The application supported HELLO can be 1216 used, for example, when implementing HTTP digest authentication - an 1217 application can check whether the peer's application is tcpcrypt 1218 aware and proceed to authenticate tcpcrypt's session ID over HTTP, 1219 otherwise reverting to standard HTTP digest authentication. The 1220 application mandatory HELLO can be used, for example, when 1221 implementing an SSL library that attempts tcpcrypt but reverts to SSL 1222 if the peer's SSL library does not support tcpcrypt. The application 1223 mandatory HELLO avoids double encrypting (SSL-over-tcpcrypt) since 1224 the connection will revert to plain TCP if the remote SSL library is 1225 not tcpcrypt-ware. 1227 4.3.2. The DECLINE suboption 1229 The DECLINE dataless suboption is sent by a host to indicate that the 1230 host will not enable tcpcrypt on a connection. If a host is in the 1231 DISABLED state or transitioning to the DISABLED state, and the host 1232 transmits a segment containing a CRYPT option, then the segment MUST 1233 contain the DECLINE suboption. 1235 A passive opener SHOULD send a DECLINE suboption in response to a 1236 HELLO suboption or NEXTK1 suboption in a received SYN segment if it 1237 supports tcpcrypt but does not wish to engage in encryption for this 1238 particular session. 1240 Implementations MUST NOT send segments containing the DECLINE 1241 suboption from the C-MODE or ENCRYPTING states. 1243 4.3.3. The NEXTK1 and NEXTK2 suboptions 1245 The NEXTK1 suboption MUST only appear in a segment with the SYN 1246 control bit set and the ACK bit clear. It is used by the active 1247 opener to initiate a TCP session without the overhead of public key 1248 cryptography. The new session key is derived from a previously 1249 negotiated session secret, as described in Section 3.8. 1251 The suboption is always 10 bytes in length; the data contains the 1252 first nine bytes of SID[i] and is used to to start the session with 1253 session secret ss[i]. The format of the suboption is: 1255 Byte 0 1 2 3 1256 +-------+-------+-------+-------+ 1257 0 |Opcode | Bytes 0-2 | 1258 | 0x84 | of SID[i] | 1259 +-------+-------+-------+-------+ 1260 4 | Bytes 3-6 | 1261 | of SID[i] | 1262 +-------+-------+-------+-------+ 1263 8 | Bytes 7-8 | 1264 | of SID[i] | 1265 +-------+-------+ 1267 Format of the NEXTK1 suboption 1269 The active opener MUST use the lowest value of i that has not already 1270 appeared in a NEXTK1 segment exchanged with the same host and for the 1271 same pre-session seed. 1273 If the passive opener recognizes SID[i] and knows ss[i], it SHOULD 1274 respond with a segment containing the dataless NEXTK2 suboption. The 1275 NEXTK2 option MUST only appear in a segment with both the SYN and ACK 1276 bits set. 1278 If the passive opener does not recognize SID[i], or SID[i] is not 1279 valid or has already been used, the passive opener SHOULD respond 1280 with a PKCONF or HELLO option and continue key negotiation as usual. 1282 When two hosts have previously negotiated a tcpcrypt session, either 1283 host may use the NEXTK1 option regardless of which host was the 1284 active opener or played the "C" role in the previous session. 1285 However, a given host must either encrypt with k_cs for all sessions 1286 derived from the same pre-session seed, or k_sc. Thus, which keys a 1287 host uses to send segments depends only whether the host played the 1288 "C" or "S" role in the initial session that used ss[0]; it is not 1289 affected by which host was the active opener transmitting the SYN 1290 segment containing a NEXTK1 suboption. 1292 A host MUST reject a NEXTK1 message if it has previously sent or 1293 received one with the same SID[i]. In the event that two hosts 1294 simultaneously send SYN segments to each other with the same SID[i], 1295 but the two segments are not part of a simultaneous open, both 1296 connections will have to revert to public key cryptography. To avoid 1297 this limitation, implementations MAY chose to implement session 1298 caching such that a given pre-session key is only good for either 1299 passive or active opens at the same host, not both. 1301 In the case of simultaneous open, two hosts that simultaneously send 1302 SYN packets with NEXTK1 and the same SID[i] may establish a 1303 connection, as described in Section 4.2.1. 1305 4.3.4. The PKCONF suboption 1307 The PKCONF option has the following format: 1309 Byte 0 1 2 N 1310 +-------+-------+-------...-------+ 1311 |Opcode=|Length=| Algorithm | 1312 | 0x41 | N | Specifiers | 1313 +-------+-------+-------...-------+ 1315 Format of the PKCONF suboption 1317 The suboption data, whose length (N-2) must be divisible by 3, 1318 contains one or more 3-byte algorithm specifiers of the following 1319 form: 1321 0 1 2 1322 bit 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 |0| Algorithm identifier | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 Format of algorithm specifier within PKCONF. Fields starting with 1 1328 are reserved for future use by algorithm identifiers longer than 1329 three bytes. 1331 The algorithm identifier specifies a number of parameters, defined in 1332 Figure 3. 1334 Hosts MUST implement OAEP+-RSA3 and ECDHE-P256 and ECDHE-P512. 1336 Servers demanding utmost performance SHOULD use RSA because the RSA 1337 encrypt operation is must faster than Diffie-Hellman operations, 1338 resulting in a higher connection rate. 1340 Depending on the encoding of the PKCONF suboption (see Table 4), it 1341 can indicate whether "S's" application is tcpcrypt-aware or not. For 1342 the "C" role, the encoding of the HELLO suboption does this. This 1343 mechanism can be used for bootstrapping application-level 1344 authentication without requiring probing in upper layer protocols to 1345 check for support (which may not be possible). The application 1346 controls these encodings via the TCP_CRYPT_SUPPORT socket option. 1348 4.3.5. The UNKNOWN suboption 1350 The UNKNOWN option has the following format: 1352 Byte 0 1 2 N 1353 +-------+-------+-------........-------+ 1354 |Opcode=|Length=| N-2 unknown one-byte | 1355 | 0x42 | N | opcodes received | 1356 +-------+-------+-------........-------+ 1358 Format of the UNKNOWN suboption 1360 This suboption is sent in response to an unknown suboption that has 1361 been received. The contents of the option are a complete list of the 1362 mandatory suboption opcodes from the received packet that were not 1363 understood. Note that this option is only sent once, in the next 1364 packet that the host sends. This means that it is reliable when sent 1365 in a SYN-ACK, but unreliable otherwise. Any mechanism sending new 1366 mandatory attributes must take this into account. If multiple 1367 packets, each containing unknown options, are received before an 1368 UNKNOWN suboption can be sent, the options list MUST contain the 1369 union of the two sets. The order of the opcode list is not 1370 significant. 1372 If a host receives an unknown option, it SHOULD reply with the 1373 UNKNOWN suboption to notify the other side. If the host transitions 1374 to DISABLED as a result of the unknown option, then the host MUST 1375 also include the DECLINE suboption if it sends an UNKNOWN suboption 1376 (or more generally if it includes a CRYPT option in the next packet). 1378 As a special case, if PKCONF (0x41) or INIT1 (0x06) appears in the 1379 unknown opcode list, it does not mean the sender does not understand 1380 the option (since these options are MANDATORY). Instead, it means 1381 the sender does not implement any of the algorithms specified in the 1382 PKCONF or INIT1 message. In either case, the segment must also 1383 contain a DECLINE suboption. 1385 4.3.6. The SYNCOOKIE and ACKCOOKIE suboptions 1387 A passive opener MAY include the SYNCOOKIE suboption in a segment 1388 with both the SYN and ACK flags set. SYNCOOKIE allows a server to be 1389 stateless until the TCP handshake has completed. It has the 1390 following format: 1392 Byte 0 1 2 N 1393 +-------+-------+-------...-------+ 1394 |Opcode=|Length=| N-2 bytes of | 1395 | 0x43 | N | opaque data | 1396 +-------+-------+-------...-------+ 1398 Format of the SYNCOOKIE suboption 1400 The data is opaque as far as the protocol is concerned; it is 1401 entirely up to implementations how to make use of this suboption to 1402 hold state. It is OPTIONAL to send a SYNCOOKIE, but MANDATORY to 1403 understand and respond to them. 1405 The ACKCOOKIE suboption echoes the contents of a SYNCOOKIE; it MUST 1406 be sent in a packet acknowledging receipt of a packet containing a 1407 SYNCOOKIE, and MUST NOT be sent in any other packet. It has the 1408 following format: 1410 Byte 0 1 2 N 1411 +-------+-------+-------...-------+ 1412 |Opcode=|Length=| N-2 bytes of | 1413 | 0x44 | N | SYNCOOKIE data | 1414 +-------+-------+-------...-------+ 1416 Format of the ACKCOOKIE suboption 1418 Servers that rely on suboption data from ACKCOOKIE to reconstruct 1419 session state SHOULD embed a cryptographically strong message 1420 authentication code within the SYNCOOKIE data so as to be able to 1421 reject forged ACKCOOKIE suboptions. 1423 Though an implementation MUST NOT send a SYNCOOKIE in any context 1424 except the SYN-ACK packet returned by a passive opener, 1425 implementations SHOULD accept SYNCOOKIEs in other contexts and reply 1426 with the appropriate ACKCOOKIE if possible. 1428 4.3.7. The SYNC_REQ and SYNC_OK suboptions 1430 Many hosts implement TCP Keep-Alives [RFC1122] as an option for 1431 applications to ensure that the other end of a TCP connection still 1432 exists even when there is no data to be sent. A TCP Keep-Alive 1433 segment carries a sequence number one prior to the beginning of the 1434 send window, and may carry one byte of "garbage" data. Such a 1435 segment causes the remote side to send an acknowledgment. 1437 Unfortunately, Keep-Alive acknowledgments might not contain unique 1438 data. Hence, an old but cryptographically valid acknowledgment could 1439 be replayed by an attacker to prolong the existence of a session at 1440 one host after the other end of the connection no longer exists. 1441 (Such an attack might prevent a process with sensitive data from 1442 exiting, giving an attacker more time to compromise a host and 1443 extract the sensitive data.) 1445 The TCP Timestamps Option (TSopt) [RFC1323] could alternatively have 1446 been used to make Keep-Alives unique. However, because some 1447 middleboxes change the value of TSopt in packets, tcpcrypt does not 1448 protect the contents of the TCP TSopt option. Hence the SYNC_REQ and 1449 SYNC_OK suboptions allow the cryptographically protected TCP CRYPT 1450 option to contain unique data. 1452 The SYNC_REQ suboption is always 5 bytes, and has the following 1453 format: 1455 Byte 0 1 2 3 4 1456 +-------+-------+-------+-------+-------+ 1457 |Opcode=| Clock | 1458 | 0x80 | | 1459 +-------+-------+-------+-------+-------+ 1461 Format of the SYNC_REQ suboption 1463 Clock is a 32-bit non-decreasing value. A host MUST increment Clock 1464 at least once for every interval in which it sends a Keep-Alive. 1465 Implementations that support TSopt MAY chose to use the same value 1466 for Clock that they would put in the TSval field of the TCP TSopt. 1467 However, implementations SHOULD "fuzz" any system clocks used to 1468 avoid disclosing either when a host was last rebooted or at what rate 1469 the hardware clock drifts. 1471 A host that receives a SYNC_REQ suboption MUST reply with a SYNC_OK 1472 suboption, which is always five bytes and has the following format: 1474 Byte 0 1 2 3 4 1475 +-------+-------+-------+-------+-------+ 1476 |Opcode=| Received-Clock | 1477 | 0x81 | | 1478 +-------+-------+-------+-------+-------+ 1480 Format of the SYNC_OK suboption 1482 The value of Received-Clock depends on the values of the Clock fields 1483 in SYNC_REQ messages a host has received. A host must set Received- 1484 Clock to a value at least as high as the most recently received 1485 Clock, but no higher than the highest Clock value received this 1486 session. If a host delays acknowledgment of multiple packets with 1487 SYNC_REQ suboptions, it SHOULD send a single SYNC_OK with Received- 1488 Clock set to the highest Clock in the packets it is acknowledging. 1490 Because middleboxes sometimes "correct" inconsistent retransmissions, 1491 Keep-Alive segments with one byte of garbage data MUST use the same 1492 ciphertext byte as previously transmitted for that sequence number. 1493 Otherwise, a middlebox might change the byte back to its value in the 1494 original transmission, causing the cryptographic MAC to fail. 1496 4.3.8. The REKEY and REKEYSTREAM suboptions 1498 The REKEY and REKEYSTREAM suboptions are used to evolve encryption 1499 keys. Exactly one of the two options is valid with any given 1500 symmetric encryption algorithm and mode. Generally block ciphers 1501 will use REKEY while stream ciphers use REKEYSTREAM. We refer to a 1502 segment containing either option as a REKEY segment. 1504 REKEY allows hosts to wipe from memory keys that could decrypt 1505 previously transmitted segments. It also allows the use of message 1506 authentication codes that are only secure up to a fixed number of 1507 messages. However, implementations MUST work in the presence of 1508 middleboxes that "correct" inconsistent data retransmissions. Hence, 1509 the value of ciphertext bytes must be the same in the original 1510 transmission and all retransmissions of a particular sequence number. 1511 This means a host MUST always use the same encryption key when 1512 transmitting or retransmitting the same range of sequence numbers. 1513 Re-keying only affects data transmitted in the future. Moreover, 1514 segments encrypted with different keysets MUST NOT be combined in 1515 retransmissions. 1517 When switching keys, the REKEY suboption specifies which key set has 1518 been used to encrypt and integrity-protect the current segment. The 1519 suboption is always two bytes, and has the following format: 1521 Byte 0 1 1522 +-------+-------+ 1523 |Opcode=|KeyLSB | 1524 | 0x83 | | 1525 +-------+-------+ 1527 Format of the REKEY suboption 1529 KeyLSB is the generation number of the keys used to encrypt and MAC 1530 the current segment, modulo 256. REKEYSTREAM is the same as REKEY 1531 but includes the TCP Sequence Number offset at which the key change 1532 took effect, for cases in which decryption requires knowing how many 1533 bytes have been encrypted thus far with a key. To interoperate with 1534 middleboxes that rewrite sequence numbers, offsets from the Initial 1535 Sequence Number (ISN) are used instead of TCP sequence numbers 1536 throughout tcpcrypt. The same occurs when dealing with 1537 acknowledgement numbers. 1539 Byte 0 1 2 3 4 5 1540 +-------+-------+-------+-------+-------+-------+ 1541 |Opcode=|KeyLSB | Sequence Number Offset | 1542 | 0x83 | | from ISN | 1543 +-------+-------+-------+-------+-------+-------+ 1545 Format of the REKEYSTREAM suboption 1547 A host MAY use REKEY to increment the session key generation number 1548 beyond the highest generation it knows the other side to be using. 1549 We call this process _initiating_ re-keying. When one host initiates 1550 re-keying, the other host MUST increment its key generation number to 1551 match, as described below (unless the other host has also 1552 simultaneously initiated re-keying). 1554 A host MAY initiate re-keying by including a REKEY suboption in a 1555 _syncable_ segment. A syncable segment is one that either contains 1556 data, or is acknowledgment-only but contains a SYNC_REQ suboption 1557 with a fresh Clock value--i.e., higher than any Clock value it has 1558 previously transmitted. We say a syncable segment is _synced_ when 1559 the transmitter knows the remote side has received it and all 1560 previous sequence numbers. A data segment is synced when the 1561 transmitter receives a cumulative acknowledgment for its sequence 1562 number (a Selective Acknowledgment [RFC2018] is insufficient). An 1563 acknowledgment-only segment is synced when the sender receives an 1564 acknowledgment for its sequence number and a SYNC_OK with a high 1565 enough Clock number. 1567 A host MUST NOT initiate re-keying with an acknowledgment-only 1568 segment that has either no SYNC_REQ suboption or a SYNC_REQ with an 1569 old Clock value, because such a segment is not syncable. A host MUST 1570 NOT initiate re-keying with any KeyLSB other than its current key 1571 number plus one modulo 256. 1573 When a host receives a segment containing a REKEY suboption, it MUST 1574 proceed as follows: 1576 1. The receiver computes RECEIVE-KEY-NUMBER to be the closest 1577 integer to its own transmit key number that also equals KeyLSB 1578 modulo 256. If no number is closest (because KeyLSB is exactly 1579 128 away from the transmit number modulo 256), the receiver MUST 1580 discard the segment. If RECEIVE-KEY-NUMBER is negative, the 1581 receiver MUST also discard the segment. 1583 2. The receiver MUST authenticate and decrypt the segment using the 1584 receive keys with generation number RECEIVE-KEY-NUMBER. The 1585 receiver MUST discard the packet as usual if the MAC is invalid. 1587 3. If RECEIVE-KEY-NUMBER is greater than the receiver's current 1588 transmit key number, the receiver must wait to receive all 1589 sequence numbers prior to the REKEY segment's. Once it receives 1590 segments covering all these missing sequence numbers (if any), it 1591 MUST increase its transmit number to RECEIVE-KEY-NUMBER and 1592 transmit a REKEY suboption. If the receiver has gotten multiple 1593 REKEY segments with different KeyLSB values, it MUST increase its 1594 transmit key number to the highest RECEIVE-KEY-NUMBER of any 1595 segment for which it is not missing prior sequence numbers. 1597 After sending a REKEY (whether initiating re-keying or just 1598 responding), a host MUST continue to send REKEY in all subsequent 1599 segments until at least one of the following holds: 1601 o One of the REKEY segments the host transmitted for its current 1602 transmit key number was syncable, and it has been synced. 1604 o The host receives a cumulative acknowledgment for one of its REKEY 1605 segments with the current transmit key number, and the cumulative 1606 acknowledgment is in a segment encrypted with the new key but not 1607 containing a REKEY suboption. 1609 A host SHOULD erase old keys from memory once the above requirements 1610 are met. 1612 A host MUST NOT initiate re-keying if it initiated a re-keying less 1613 than 60 seconds ago and has not transmitted at least 1 Megabyte 1614 (increased its sequence number by 1,048,576) since the last re- 1615 keying. A host MUST NOT initiate re-keying if it has outstanding 1616 unacknowledged REKEY segments for key numbers that are 127 or more 1617 below the current key. A host SHOULD not initiate more than one 1618 concurrent re-key operation if it has no data to send. 1620 4.3.9. The INIT1 and INIT2 suboptions 1622 The INIT1 dataless suboption indicates that the Data portion of the 1623 TCP segment contains the following data structure: 1625 Byte 0 1 2 3 1626 +-------+-------+-------+-------+ 1627 | # bytes INIT1 | 1628 +-------+-------+-------+-------+ 1629 | INIT1_MAGIC | # auth enc alg| 1630 +-------+-------+-------+-------+ 1631 |# bytes of N_C |# byte of PK_C | 1632 +-------+-------+-------+-------+ 1633 | authenticated encryption | 1634 : algorithms : 1635 +-------+-------+-------+-------+ 1636 | N_C | 1637 : : 1638 +-------+-------+-------+-------+ 1639 | 0 | type of K_C | 1640 +-------+-------+-------+-------+ 1641 | PK_C | 1642 : : 1643 +-------+-------+-------+-------+ 1645 The INIT1_MAGIC is specified in Table 7. The following values for 1646 authenticated sequence mode (ASM) encryption algorithms are defined: 1648 The first entry is mandatory and MUST be supported by all 1649 implementations. The sequence number for ASM mode is TCP's extended 1650 64-bit sequence number offset from the ISN. 1652 The value "type of PK_C" must be one of the public key specifiers 1653 included earlier in the other host's PKCONF message. 1655 The INIT2 dataless suboption indicates that the Data portion of the 1656 TCP segment contains the following data structure: 1658 Byte 0 1 2 3 1659 +-------+-------+-------+-------+ 1660 | # byte INIT2 | 1661 +-------+-------+-------+-------+ 1662 | INIT2_MAGIC |#byte kmaterial| 1663 +-------+-------+-------+-------+ 1664 | symmetric cipher suite | 1665 +-------+-------+-------+-------+ 1666 | key material | 1667 : : 1668 +-------+-------+-------+-------+ 1670 Format of the INIT2 suboption 1672 Figure 2 1674 The INIT2_MAGIC is specified in Table 7. The symmetric cipher suite 1675 is one selected by the host transmitting the INIT2 segment, which 1676 will be playing the "S" role. The key material depends on the public 1677 key cipher selected, as described in Section 3.4. When ECDHE is 1678 used, key material is encoded as follows: 1680 Byte 0 1 N M 1681 +-------+---...---+---...---+ 1682 |# byte | N_S | PK_S | 1683 | N_S | | | 1684 +-------+---...---+---...---+ 1686 Hosts MUST set the TCP PSH control bits on INIT1 and INIT2 segments. 1687 Implementations MUST NOT set the TCP FIN control bit on INIT 1688 segments. 1690 4.3.10. The IV suboption 1692 The IV suboption is used to hold an initialization vector (IV) when 1693 the negotiated encryption mode requires an initialization vector to 1694 be transmitted with packets. It MUST NOT be included in transmitted 1695 packets except in the ENCRYPTING state when the negotiated encryption 1696 mode requires IVs. When the negotiated encryption mode does require 1697 IVs, all segments transmitted in ENCRYPTING mode MUST contain an IV 1698 suboption. 1700 The IV suboption has the following format: 1702 Byte 0 1 N 1703 +-------+-------...-------+ 1704 |Opcode=| Initialization | 1705 | 0x85 | Vector | 1706 +-------+-------...-------+ 1708 Format of the IV suboption 1710 The length N of the IV is determined by the encryption algorithm and 1711 mode negotiated. 1713 As discussed in Section 4.3.8, a host MUST always transmit the same 1714 ciphertext byte in retransmissions of a particular sequence number. 1715 Thus, retransmitted segments must use the same IV each time. 1716 Moreover, previously transmitted segments MUST NOT be combined on 1717 retransmission if their IVs would prevent the ciphertext bytes from 1718 remaining the same as in the original transmission. 1720 4.4. The TCP MAC option 1722 The MAC option is used to authenticate a TCP segment. Once a host 1723 has entered the encrypting phase for a session, the HOST must include 1724 a TCP MAC option in all segments it sends. Furthermore, once in the 1725 encrypting phase, a host MUST ignore any segments it receives that do 1726 not have a valid MAC option, except for segments with the RST bit set 1727 if the application has not requested cryptographic verification of 1728 RST segments. 1730 The length of the MAC option is determined by the symmetric message 1731 authentication code selected. The format of the MAC option is: 1733 Byte 0 1 2 N+1 1734 +-------+-------+------...------+ 1735 | Kind | Len= | N-byte | 1736 | OPT2 | 2+N | MAC | 1737 +-------+-------+------...------+ 1739 Format of TCP MAC option 1741 The MAC is the authentication tag as output from autheticated 1742 encryption. Apart from payload, two headers are included in the 1743 authenticated encryption process: a pseudo-header structure we call 1744 Assoc-Data, and an acknowledgment structure we call Up-Data. The 1745 format of Assoc-Data is as follows: 1747 Byte 0 1 2 3 1748 +-------+-------+-------+-------+ 1749 0 | 0x8000 | length | 1750 +-------+-------+-------+-------+ 1751 4 | off | flags | window | 1752 +-------+-------+---------------+ 1753 8 | 0x0000 | urg | 1754 +-------+-------+-------+-------+ 1755 12 | seqno offset hi | 1756 +-------+-------+-------+-------+ 1757 16 | seqno offset | 1758 +-------+-------+-------+-------+ 1759 20 | options | 1760 : : 1761 +-------+-------+-------+-------+ 1763 Assoc-Data data structure 1765 The fields of Assoc-Data are defined as follows: 1767 length 1768 Total size of the TCP segment from the start of the TCP header to 1769 the end of the IP datagram. 1771 off 1772 Byte 12 of the TCP header (Data Offset) 1774 flags 1775 Byte 13 of the TCP header (Control Bits) 1777 window 1778 Bytes 14-15 of the TCP header (Window) 1780 urg 1781 Bytes 18-19 of the TCP header (Urgent Pointer) 1783 seqno offset hi 1784 Number of times the seqno offset field has wrapped from 0xffffff 1785 -> 0 1787 seqno offset 1788 The low 32 bits of the sequence number offset (the Sequence Number 1789 in the TCP header - ISN) 1791 options 1792 These are bytes 20-off of the TCP header. However, where the 1793 TSOPT (8), Skeeter (16), Bubba (17), MD5 (19), and MAC (OPT2) 1794 options appear, their contents (all but the kind and length bytes) 1795 are replaced with all zeroes. 1797 The format of the Up-Data structure is as follows: 1799 Byte 0 1 2 3 1800 +-------+-------+-------+-------+ 1801 0 | ackno offset hi | 1802 +-------+-------+-------+-------+ 1803 4 | ackno offset | 1804 +-------+-------+-------+-------+ 1806 Up-Data data structure 1808 The fields of Up-Data are defined as follows: 1810 ackno offset hi The number of times ackno offset hi has wrapped from 1811 0xffffff -> 0. 1813 ackno offset The lower 32 bits of the acknowledgement number offset 1814 from the remote end's ISN (TCP's acknowledgement header - ISN 1815 received). 1817 The two structures, Assoc-Data and Up-Data, are used in ASM mode to 1818 calculate the TCP MAC option. 1820 5. Examples 1822 To illustrate these suboptions, consider the following series of ways 1823 in which a TCP connection may be established from host A to host B. 1824 We use notation S for SYN-only packet, SA for SYN-ACK packet, and A 1825 for packets with the ACK bit but not SYN bit. These examples are not 1826 normative. 1828 5.1. Example 1: Normal handshake 1830 (1) A -> B: S CRYPT<> 1831 (2) B -> A: SA CRYPT> 1832 (3) A -> B: A data 1833 (4) B -> A: A data 1834 (5) A -> B: A MAC data<...> 1836 (1) A indicates interest in using tcpcrypt. In (2), the server 1837 indicates willingness to use ECDHE with curves P256 and P512. 1838 Messages (3) and (4) complete the INIT1 and INIT2 key exchange 1839 messages described above, which are embedded in the data portion of 1840 the TCP segment. (5) From this point on, all messages are encrypted 1841 and their integrity protected by a MAC option. 1843 5.2. Example 2: Normal handshake with SYN cookie 1845 (1) A -> B: S CRYPT<> 1846 (2) B -> A: SA CRYPT, SYNCOOKIE> 1847 (3) A -> B: A CRYPT> data 1848 (4) B -> A: A data 1849 (5) B -> A: A MAC data<...> 1851 Same as previous example, except the server sends the client a SYN 1852 cookie value, which the client must echo in (3). Here also the 1853 application level protocol begins by B transmitting data, while in 1854 the previous example, A was the first to transmit application-level 1855 data. 1857 5.3. Example 3: tcpcrypt unsupported 1859 (1) A -> B: S CRYPT<> 1860 (2) B -> A: SA 1861 (3) A -> A: A 1863 (1) A indicates interest in using tcpcrypt. (2) B does not support 1864 tcpcrypt, or a middle box strips out the CRYPT TCP option. (3) the 1865 client completes a normal three-way handshake, and tcpcrypt is not 1866 enabled for the connection. 1868 5.4. Example 4: Reusing established state 1870 (1) A -> B: S CRYPT> 1871 (2) B -> A: SA CRYPT 1872 (3) A -> A: A MAC 1874 (1) A indicates interest in using tcpcrypt with a session key derived 1875 from an existing key, to avoid the use of public key cryptography for 1876 the new session. (2) B supports tcpcrypt, has ID in its session ID 1877 cache, and is willing to proceed with session caching. (3) the client 1878 completes tcpcrypt's handshake within TCP's three-way handshake and 1879 tcpcrypt is enabled for the connection. 1881 5.5. Example 5: Decline of state reuse 1883 (1) A -> B: S CRYPT> 1884 (2) B -> A: SA CRYPT> 1885 (3) A -> B: A data 1886 (4) B -> A: A data 1887 (5) A -> B: A MAC data<...> 1889 A wishes to use a key derived from a previous session key, but B does 1890 not recognize the session ID or has flushed it from its cache. 1891 Therefore, session establishment proceeds as in the first connection, 1892 using public key cryptography to negotiate a new series of session 1893 secrets (ss[i] values). 1895 5.6. Example 6: Reversal of client and server roles 1897 (1) A -> B: S CRYPT<> 1898 (2) B -> A: SA CRYPT 1899 (3) A -> B: A CRYPT> 1900 (4) B -> A: A data 1901 (5) A -> B: A data 1902 (6) B -> A: A MAC data<...> 1904 Here the passive opener, B, wishes to play the role of the decryptor 1905 using RSA. By sending a HELLO suboption, B causes A to switch roles, 1906 so that now A is "S" and B plays the role of "C". 1908 6. API extensions 1910 The getsockopt call should have new options for IPPROTO_TCP: 1912 TCP_CRYPT_SESSID -> returns the session ID and MUST return an 1913 error if tcpcrypt is in not in the ENCRYPTING state (e.g., because 1914 it has transitioned to DISABLED). 1916 TCP_CRYPT_CMODE -> returns 1 if the local host played the "C" role 1917 in session key negotiation, 0 otherwise. 1919 TCP_CRYPT_PUBKEY_LOCAL -> When the local host played the "C" role, 1920 returns the hosts public key, PK_C. When the local host played the 1921 "S" role, returns PK_S if KX_S supports such a value or returns an 1922 error otherwise. Hosts MAY return an error after transmitting the 1923 first application-level payload bytes (so as to reclaim the memory 1924 used to store keys). 1926 TCP_CRYPT_PUBKEY_PEER -> Analogous to TCP_CRYPT_PUBKEY_LOCAL with 1927 the roles reversed. (Returns PK_C when the local host played the 1928 "S" role, and PK_S, if applicable, when the local host played the 1929 "C" role.) 1931 TCP_CRYPT_CONF -> returns the four-byte authenticated encryption 1932 algorithm in use by the connection (as specified in Table 6). In 1933 addition, implementations SHOULD provide the three-byte public key 1934 cipher (Figure 3) initially used to negotiate the session keys, as 1935 well as the public key length for algorithms with variable key 1936 sizes (e.g., OAEP+-RSA3). 1938 TCP_CRYPT_SUPPORT -> returns 1 if the remote application is 1939 tcpcrypt-aware, as indicated by the remote host's use of a HELLO- 1940 app-support, HELLO-app-mandatory, or PKCONF-app-support CRYPT 1941 suboption (see Table 4). 1943 The setsockopt call should have: 1945 TCP_CRYPT_CACHE_FLUSH -> setting this option to non-zero wipes 1946 cached session keys. Useful if application-level authentication 1947 discovers a man in the middle attack, to prevent the next 1948 connection from using NEXTK. 1950 The following options should be readable and writable with getsockopt 1951 and setsockopt: 1953 TCP_CRYPT_ENABLE -> one bit, enables or disables tcpcrypt 1954 extension on an unconnected (listening or new) socket. 1956 TCP_CRYPT_SECURST -> one bit, means ignore unauthenticated RST 1957 packets for this connection when set to 1. 1959 TCP_CRYPT_CMODE_{DEFAULT,NEVER,ALWAYS}[_NK] -> As described in 1960 Section 4.2. 1962 TCP_CRYPT_PKCONF -> set of allowed public key algorithms and CPRFs 1963 this host advertises in CRYPT PKCONF suboptions. 1965 TCP_CRYPT_CCONF -> set of allowed symmetric ciphers and message 1966 authentication codes this host advertises in CRYPT INIT1 segments. 1968 TCP_CRYPT_SCONF -> order of preference of symmetric ciphers. 1970 TCP_CRYPT_SUPPORT -> set to 1 if the application is tcpcrypt- 1971 aware. set to 2 if the application is tcpcrypt-aware and wishes to 1972 enter the DISABLED state if the remote application is not 1973 tcpcrypt-aware. An active opener SHOULD set the default value to 1974 0 for each new connection. A passive opener SHOULD use a default 1975 value to 0 for each port, but SHOULD inherit the value of the 1976 listening socket for accepted connections. The behavior for each 1977 value is as follows: 1979 When set to 0 The host MUST transition to the DISABLED state upon 1980 receiving a HELLO-app-mandatory option. The host MUST NOT send 1981 the HELLO-app-support, HELLO-app-mandatory, NEXTK2-app-support, 1982 or PKCONF-app-support options. 1984 When set to 1 The "C" role host MUST use HELLO-app-support in 1985 place of the HELLO option, while the "S" role host MUST use the 1986 "PKCONF-app-support" in place of the "PKCONF" option. Either 1987 role must use NEXTK2-app-support in place of NEXTK2. 1989 When set to 2 The "C" role host MUST use HELLO-app-mandatory 1990 option in place of the HELLO option, while the "S" role host 1991 MUST use "PKCONF-app-support" in place of the "PKCONF" option. 1992 Either role must use NEXTK2-app-support in place of NEXTK2. 1993 Either host MUST transition to DISABLED upon receipt of a HELLO 1994 or PKCONF option, but MUST proceed as usual in response to 1995 HELLO-app-support, HELLO-app-mandatory, and PKCONF-app-support. 1997 Finally, system administrators must be able to set the following 1998 system-wide parameters: 2000 o Default TCP_CRYPT_ENABLE value 2002 o Default TCP_CRYPT_PKCONF value 2004 o Default TCP_CRYPT_CCONF value 2006 o Default TCP_CRYPT_SCONF value 2008 o Types, key lengths, and regeneration intervals of local host's 2009 short-lived public keys 2011 The session ID can be used for end-to-end security. For instance, 2012 applications might sign the session ID with public keys to 2013 authenticate their ends of a connection. Because session IDs are not 2014 secret, servers can sign them in batches to amortize the cost of the 2015 signature over multiple connections. Alternatively, DSA signatures 2016 are cheaper to compute than to verify, so might be a good way for 2017 servers to authenticate themselves. A voice application could 2018 display the session ID on both parties' screens, and if they confirm 2019 by voice that they have the same ID, then the conversation is secure. 2021 Because the public key may change less often than once a session, it 2022 may alternatively be useful for the local end of a connection to 2023 authenticate itself by signing the local host's public key instead of 2024 the session ID. 2026 7. Acknowledgments 2028 This work was funded by gifts from Intel (to Brad Karp) and from 2029 Google, and by NSF award CNS-0716806 (A Clean-Slate Infrastructure 2030 for Information Flow Control). 2032 8. IANA Considerations 2034 The following numbers need assignment by IANA: 2036 o New TCP option kind number for CRYPT 2038 o New TCP option kind number for MAC 2040 A new registry entitled "tcpcrypt CRYPT suboptions" needs to be 2041 maintained by IANA as per the following table. 2043 +---------------------+-------+ 2044 | Symbol | Value | 2045 +---------------------+-------+ 2046 | HELLO | 0x01 | 2047 | HELLO-app-support | 0x02 | 2048 | HELLO-app-mandatory | 0x03 | 2049 | DECLINE | 0x04 | 2050 | NEXTK2 | 0x05 | 2051 | NEXTK2-app-support | 0x06 | 2052 | INIT1 | 0x07 | 2053 | INIT2 | 0x08 | 2054 | PKCONF | 0x41 | 2055 | PKCONF-app-support | 0x42 | 2056 | UNKNOWN | 0x43 | 2057 | SYNCOOKIE | 0x44 | 2058 | ACKCOOKIE | 0x45 | 2059 | SYNC_REQ | 0x80 | 2060 | SYNC_OK | 0x81 | 2061 | REKEY | 0x82 | 2062 | REKEYSTREAM | 0x83 | 2063 | NEXTK1 | 0x84 | 2064 | IV | 0x85 | 2065 +---------------------+-------+ 2067 TCP CRYPT suboptions. 2069 Table 5 2071 A "tcpcrypt Algorithm Identifiers" registry needs to be maintained by 2072 IANA as per the following table. 2074 +-----------------------------------------------------------+ 2075 | Algorithm Identifier | Value | 2076 +------------------------------------------------+----------+ 2077 | Cipher: OAEP+-RSA with exponent 3 | 0x000100 | 2078 | Extract: HKDF-Extract-SHA256 | | 2079 | CPRF: HKDF-Expand-SHA256 | | 2080 | N_C len: 32 bytes | | 2081 | R_S len: 48 bytes | | 2082 | K_LEN: 32 bytes | | 2083 +------------------------------------------------+----------+ 2084 | Cipher: ECDHE-P256 | 0x000200 | 2085 | Extract: HKDF-Extract-SHA256 | | 2086 | CPRF: HKDF-Expand-SHA256 | | 2087 | N_C len: 32 bytes | | 2088 | N_S len: 32 bytes | | 2089 | K_LEN: 32 bytes | | 2090 +------------------------------------------------+----------+ 2091 | Cipher: ECDHE-P512 | 0x000201 | 2092 | Extract: HKDF-Extract-SHA256 | | 2093 | CPRF: HKDF-Expand-SHA256 | | 2094 | N_C len: 32 bytes | | 2095 | N_S len: 32 bytes | | 2096 | K_LEN: 32 bytes | | 2097 +------------------------------------------------+----------+ 2099 TCP CRYPT algorithm identifiers. 2101 Figure 3 2103 A "tcpcrypt authenticated encryption algorithms" registry needs to be 2104 maintained by IANA as per the following table. 2106 +------------------------------------------------+------------+ 2107 | Authenticated Encryption | value | 2108 +------------------------------------------------+------------+ 2109 | AES-128 ASM mode HMAC-SHA2-128 AES-128 ACK MAC | 0x00000100 | 2110 | AES-128 ASM mode Poly1305-AES AES-128 ACK MAC | 0x00000200 | 2111 | AES-128 ASM mode CMAC-AES-128 AES-128 ACK MAC | 0x00000300 | 2112 +------------------------------------------------+------------+ 2114 TCP CRYPT authenticated encryption algorithms. 2116 Table 6 2118 9. Security Considerations 2120 Tcpcrypt guarantees that no man-in-the-middle attacks occurred if 2121 Session IDs match on both ends of a connection, unless the attacker 2122 has broken the underlying cryptographic primitives (e.g., RSA). A 2123 proof has been published [tcpcrypt]. 2125 If the application performs no authentication, then there are no 2126 guarantees against active attackers. Session IDs can be logged on 2127 both ends and man-in-the-middle attacks can be detected after the 2128 fact by comparing Session IDs offline. 2130 Session IDs are not confidential. 2132 Tcpcrypt can be downgraded to regular TCP during the connection setup 2133 phase by removing any of the CRYPT options. The downgrade, and 2134 absence of protection, can of course be detected by the application 2135 as no Session ID will be returned. 2137 By default tcpcrypt does not protect against RST packet injection. 2138 The connection must be configured with TCP_CRYPT_RSTCHK enabled to 2139 protect against malicious (unMACed) RSTs. 2141 tcpcrypt uses short-lived keys to provide some forward secrecy. If a 2142 key is compromised all connections (new and cached) derived from that 2143 key will be compromised. The life of these keys should be kept to a 2144 minimum for stronger protection. A life of less than two minutes is 2145 recommended. Keys can be generated as frequently as practical, for 2146 example when servers have idle CPU time. For ECDHE-based key 2147 agreement, a new key can be chosen for each connection. 2149 In the 4-way handshake, tcpcrypt does not have a key confirmation 2150 step. Hence, an active attacker can cause a connection to hang, 2151 though this is possible even without tcpcrypt by altering sequence 2152 and ack numbers. 2154 Attackers cannot force passive openers to move forward in their 2155 session caching chain without guessing the content of the NEXTK1 2156 option, which will be hard without key knowledge. 2158 10. References 2160 10.1. Normative References 2162 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2163 RFC 793, September 1981. 2165 [RFC1122] Braden, R., "Requirements for Internet Hosts - 2166 Communication Layers", STD 3, RFC 1122, October 1989. 2168 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 2169 for High Performance", RFC 1323, May 1992. 2171 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 2172 Selective Acknowledgment Options", RFC 2018, October 1996. 2174 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2175 Hashing for Message Authentication", RFC 2104, 2176 February 1997. 2178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2179 Requirement Levels", BCP 14, RFC 2119, March 1997. 2181 [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography 2182 Specifications Version 2.0", RFC 2437, October 1998. 2184 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2185 Key Derivation Function (HKDF)", RFC 5869, May 2010. 2187 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 2188 "TCP Extensions for Multipath Operation with Multiple 2189 Addresses", RFC 6824, January 2013. 2191 10.2. Informative References 2193 [I-D.narten-iana-considerations-rfc2434bis] 2194 Narten, T. and H. Alvestrand, "Guidelines for Writing an 2195 IANA Considerations Section in RFCs", 2196 draft-narten-iana-considerations-rfc2434bis-09 (work in 2197 progress), March 2008. 2199 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 2200 Text on Security Considerations", BCP 72, RFC 3552, 2201 July 2003. 2203 [aggregate-macs] 2204 Katz, J. and A. Lindell, "Aggregate Message Authentication 2205 Codes", Topics in Cryptology - CT-RSA , 2008. 2207 [tcpcrypt] 2208 Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and D. 2209 Boneh, "The case for ubiquitous transport-level 2210 encryption", USENIX Security , 2010. 2212 Appendix A. Protocol constant values 2214 +--------+---------------+ 2215 | Value | Name | 2216 +--------+---------------+ 2217 | 0x01 | CONST_NEXTK | 2218 | 0x02 | CONST_SESSID | 2219 | 0x03 | CONST_REKEY | 2220 | 0x04 | CONST_KEY_C | 2221 | 0x05 | CONST_KEY_S | 2222 | 0x06 | CONST_KEY_ENC | 2223 | 0x07 | CONST_KEY_MAC | 2224 | 0x08 | CONST_KEY_ACK | 2225 | 0x2911 | INIT1_MAGIC | 2226 | 0x8310 | INIT2_MAGIC | 2227 +--------+---------------+ 2229 Protocol constants. 2231 Table 7 2233 Authors' Addresses 2235 Andrea Bittau 2236 Stanford University 2237 Department of Computer Science 2238 353 Serra Mall, Room 288 2239 Stanford, CA 94305 2240 US 2242 Phone: +1 650 723 8777 2243 Email: bittau@cs.stanford.edu 2245 Dan Boneh 2246 Stanford University 2247 Department of Computer Science 2248 353 Serra Mall, Room 475 2249 Stanford, CA 94305 2250 US 2252 Phone: +1 650 725 3897 2253 Email: dabo@cs.stanford.edu 2254 Mike Hamburg 2255 Stanford University 2256 Department of Computer Science 2257 353 Serra Mall, Room 475 2258 Stanford, CA 94305 2259 US 2261 Phone: +1 650 725 3897 2262 Email: mike@shiftleft.org 2264 Mark Handley 2265 University College London 2266 Department of Computer Science 2267 University College London 2268 Gower St. 2269 London WC1E 6BT 2270 UK 2272 Phone: +44 20 7679 7296 2273 Email: M.Handley@cs.ucl.ac.uk 2275 David Mazieres 2276 Stanford University 2277 Department of Computer Science 2278 353 Serra Mall, Room 290 2279 Stanford, CA 94305 2280 US 2282 Phone: +1 415 490 9451 2283 Email: dm@uun.org 2285 Quinn Slack 2286 Stanford University 2287 Department of Computer Science 2288 353 Serra Mall, Room 288 2289 Stanford, CA 94305 2290 US 2292 Phone: +1 650 723 8777 2293 Email: sqs@cs.stanford.edu