idnits 2.17.1 draft-bittau-tcp-crypt-03.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 (September 3, 2012) is 4250 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 1030 ** 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) Summary: 4 errors (**), 0 flaws (~~), 3 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: March 7, 2013 Stanford University 6 M. Handley 7 University College London 8 D. Mazieres 9 Q. Slack 10 Stanford University 11 September 3, 2012 13 Cryptographic protection of TCP Streams (tcpcrypt) 14 draft-bittau-tcp-crypt-03.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 can be used to protect already established TCP 22 connections against denial-of-service attacks involving injection of 23 forged RST segments or desynchronizing of sequence numbers. Finally, 24 applications that perform authentication can obtain end-to-end 25 confidentiality and integrity guarantees by tying authentication to 26 tcpcrypt Session ID 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 March 7, 2013. 55 Copyright Notice 57 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . 4 85 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 3. Idealized protocol . . . . . . . . . . . . . . . . . . . . . . 4 87 3.1. Stages of the protocol . . . . . . . . . . . . . . . . . . 4 88 3.1.1. The setup phase . . . . . . . . . . . . . . . . . . . 5 89 3.1.2. The ENCRYPTING state . . . . . . . . . . . . . . . . . 5 90 3.1.3. The DISABLED state . . . . . . . . . . . . . . . . . . 6 91 3.2. Cryptographic algorithms . . . . . . . . . . . . . . . . . 6 92 3.3. "C" and "S" roles . . . . . . . . . . . . . . . . . . . . 7 93 3.4. Key exchange protocol . . . . . . . . . . . . . . . . . . 8 94 3.5. Re-keying . . . . . . . . . . . . . . . . . . . . . . . . 9 95 3.6. Session caching . . . . . . . . . . . . . . . . . . . . . 10 96 3.6.1. Session caching control . . . . . . . . . . . . . . . 11 97 4. Extensions to TCP . . . . . . . . . . . . . . . . . . . . . . 11 98 4.1. Protocol states . . . . . . . . . . . . . . . . . . . . . 11 99 4.2. Role negotiation . . . . . . . . . . . . . . . . . . . . . 16 100 4.2.1. Simultaneous open . . . . . . . . . . . . . . . . . . 17 101 4.3. The TCP CRYPT option . . . . . . . . . . . . . . . . . . . 18 102 4.3.1. The HELLO suboption . . . . . . . . . . . . . . . . . 21 103 4.3.2. The DECLINE suboption . . . . . . . . . . . . . . . . 22 104 4.3.3. The NEXTK1 and NEXTK2 suboptions . . . . . . . . . . . 22 105 4.3.4. The PKCONF suboption . . . . . . . . . . . . . . . . . 23 106 4.3.5. The UNKNOWN suboption . . . . . . . . . . . . . . . . 25 107 4.3.6. The SYNCOOKIE and ACKCOOKIE suboptions . . . . . . . . 25 108 4.3.7. The SYNC_REQ and SYNC_OK suboptions . . . . . . . . . 26 109 4.3.8. The REKEY and REKEYSTREAM suboptions . . . . . . . . . 28 110 4.3.9. The INIT1 and INIT2 suboptions . . . . . . . . . . . . 30 111 4.3.10. The IV suboption . . . . . . . . . . . . . . . . . . . 32 112 4.4. The TCP MAC option . . . . . . . . . . . . . . . . . . . . 33 113 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 114 5.1. Example 1: Normal handshake . . . . . . . . . . . . . . . 36 115 5.2. Example 2: Normal handshake with SYN cookie . . . . . . . 36 116 5.3. Example 3: tcpcrypt unsupported . . . . . . . . . . . . . 36 117 5.4. Example 4: Reusing established state . . . . . . . . . . . 36 118 5.5. Example 5: Decline of state reuse . . . . . . . . . . . . 37 119 5.6. Exmaple 6: Reversal of client and server roles . . . . . . 37 120 6. API extensions . . . . . . . . . . . . . . . . . . . . . . . . 37 121 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 122 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 123 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 124 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 125 10.1. Normative References . . . . . . . . . . . . . . . . . . . 40 126 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 127 Appendix A. Protocol constant values . . . . . . . . . . . . . . 41 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 130 1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 2. Introduction 138 This document describes tcpcrypt, an extension to TCP for 139 cryptographic protection of session data. Tcpcrypt was designed to 140 meet the following goals: 142 o Maintain confidentiality of communications against a passive 143 adversary. Ensure that an adversary must actively intercept and 144 modify the traffic to eavesdrop, either by re-encrypting all 145 traffic or by forcing a downgrade to an unencrypted session. 147 o Minimize computational cost, particularly on servers. 149 o Provide interfaces to higher-level software to facilitate end-to- 150 end security, either in the application level protocol or after 151 the fact. (E.g., client and server log session IDs and can 152 compare them after the fact; if there was no tampering or 153 eavesdropping, the IDs will match.) 155 o Be compatible with further extensions that allow authenticated 156 resumption of TCP connections when either end changes IP address. 158 o Facilitate multipath TCP by identifying a TCP stream with a 159 session ID independent of IP addresses and port numbers. 161 o Provide for incremental deployment and graceful fallback, even in 162 the presence of NATs and other middleboxes that might remove 163 unknown options, and traffic normalizers. 165 3. Idealized protocol 167 This section describes the tcpcrypt protocol at an abstract level, 168 without reference to particular cryptographic algorithms or data 169 encodings. Readers who simply wish to see the key exchange protocol 170 should skip to Section 3.4. 172 3.1. Stages of the protocol 174 A tcpcrypt endpoint goes through multiple stages. It begins in a 175 setup phase and ends up in one of two states, ENCRYPTING or DISABLED, 176 before applications may send or receive data. The ENCRYPTING and 177 DISABLED states are definitive and mutually exclusive; an endpoint 178 that has been in one of the two states MUST NOT ever enter the other, 179 nor ever re-enter the setup phase. 181 3.1.1. The setup phase 183 The setup phase negotiates use of the tcpcrypt extension. During 184 this phase, two hosts agree on a suite of cryptographic algorithms 185 and establish shared secret session keys. 187 The setup phase uses the Data portion of TCP segments to exchange 188 cryptographic keys. Implementations MUST NOT include application 189 data in TCP segments during setup and MUST NOT allow applications to 190 read or write data. System calls MUST behave the same as for TCP 191 connections that have not yet entered the ESTABLISHED state; calls to 192 read and write SHOULD block or return temporary errors, while calls 193 to poll or select SHOULD consider connections not ready. 195 When setup succeeds, tcpcrypt enters the ENCRYPTING state. 196 Importantly, a successful setup also produces an important value 197 called the _Session ID_. The Session ID is tied to the negotiated 198 algorithms and cryptographic keys, and is unique over all time with 199 overwhelming probability. 201 Operating systems MUST make the Session ID available to applications. 202 To prevent man-in-the-middle attacks, applications MAY authenticate 203 the session ID through any protocol that ensures both endpoints of a 204 connection have the same value. Applications MAY alternatively just 205 log Session IDs so as to enable attack detection after the fact 206 through comparison of the values logged at both ends. 208 The setup phase can also fail for various reasons, in which case 209 tcpcrypt enters the DISABLED state. 211 Applications MAY test whether setup succeeded by querying the 212 operating system for the Session ID. Requests for the Session ID 213 MUST return an error when tcpcrypt is not in the ENCRYPTING state. 214 Applications SHOULD authenticate the returned Session ID. 215 Applications relying on tcpcrypt for security SHOULD authenticate the 216 Session ID and SHOULD treat unauthenticated Session IDs the same as 217 connections in the DISABLED state. 219 3.1.2. The ENCRYPTING state 221 When the setup phase succeeds, tcpcrypt enters the ENCRYPTING state. 222 Once in this state, applications may read and write data with the 223 expected semantics of TCP connections. 225 In the ENCRYPTING state, a host MUST encrypt the Data portion of all 226 TCP segments transmitted and MUST include a Message Authentication 227 Code (MAC) in all segments transmitted. A host MUST furthermore 228 ignore any TCP segments received without the RST bit set, unless 229 those segments also contain a valid MAC. 231 A host MAY ignore RST segments without valid MACs. However, 232 operating systems SHOULD allow applications to control the dropping 233 of unMACed RST segments on a per-connection basis through an option 234 called TCP_CRYPT_RSTCHK option. Operating systems SHOULD furthermore 235 disable TCP_CRYPT_RSTCHK by default. 237 Once in the ENCRYPTING state, an endpoint MUST NOT directly or 238 indirectly transition to the DISABLED state under any circumstances. 240 3.1.3. The DISABLED state 242 When setup fails, tcpcrypt enters the DISABLED state. In this case, 243 the host MUST continue just as TCP would without tcpcrypt, unless 244 network conditions would cause a plain TCP connection to fail as 245 well. Entering the DISABLED state prohibits the endpoint from ever 246 entering the ENCRYPTING state. 248 An implementation MUST behave identically to ordinary TCP in the 249 DISABLED state, except that the first segment transmitted after 250 entering the DISABLED state MAY include a TCP CRYPT option with a 251 DECLINE suboption (and optionally other suboptions such as UNKNOWN) 252 to indicate that tcpcrypt is supported but not enabled. 253 Section 4.3.2 describes how this is done. 255 Operating systems MUST allow applications to turn off tcpcrypt by 256 setting the state to DISABLED before opening a connection. An active 257 opener with tcpcrypt disabled MUST behave identically to an 258 implementation of TCP without tcpcrypt. A passive opener with 259 tcpcrypt disabled MUST also behave like normal TCP, except that it 260 MAY optionally respond to SYN segments containing a CRYPT option with 261 SYN-ACK segments containing a DECLINE suboption, so as to indicate 262 that tcpcrypt is supported but not enabled. 264 3.2. Cryptographic algorithms 266 The setup phase employs two types of cryptographic algorithm: 268 o A _public key cipher_ is used with an ephemeral public key to 269 exchange a random, shared secret. We use the notation 270 ENC (K, VALUE) to denote an encryption of VALUE with public key K. 272 o A _collision-resistant pseudo-random function (CPRF)_ family is 273 used to generate multiple cryptographic keys from a smaller shared 274 secret. We use the notation CPRF (K, MESSAGE) to designate the 275 output of the pseudo-random function identified by key K on 276 MESSAGE. 278 Because public key ciphers and CPRFs often both make use of 279 cryptographic hashes, it generally makes sense to have both 280 algorithms based on the same hash function--for instance to pair the 281 OAEP+-RSA [RFC2437] cipher using a SHA-256-based mask-generation 282 function with the HMAC-SHA256 [RFC2104] CPRF. For this reason, the 283 public key cipher and CPRF are negotiated as a pair. 285 The encrypting phase employs two more types of algorithm: 287 o A _symmetric encryption algorithm_ is applied to all application 288 data. The algorithm specifier includes both an underlying cipher 289 (such as AES), and a mode of operation (such as CTR mode with TCP 290 sequence numbers as the counter). 292 o A Message Authentication Code or _MAC_ is used to protect the data 293 portion and most of the TCP header contents of all TCP segments 294 sent and received in the encrypting phase. The currently 295 specified MACs handle data in a structured way so as to optimize 296 authentication of TCP's Acknowledgment Number field in re- 297 transmissions. 299 Note that public key generation, public key encryption, and shared 300 secret generation all require randomness. Other tcpcrypt functions 301 may also require randomness depending on the algorithms and modes of 302 operation selected. A weak pseudo-random generator at either host 303 will defeat tcpcrypt's security. Thus, any host implementing 304 tcpcrypt MUST have a cryptographically secure source of randomness or 305 pseudo-randomness. 307 3.3. "C" and "S" roles 309 To establish shared session keys, tcpcrypt requires one host to 310 encrypt a secret value with the second host's public key. The second 311 host must subsequently use its private key to decrypt this value. 312 Thus, tcpcrypt's setup phase is asymmetric; the two hosts must play 313 different roles. We use "S" to denote the host that encrypts with 314 the other host's public key, and "C" to denote the host that decrypts 315 using its own private key. 317 Which role a host plays can have performance implications, because 318 for some public key algorithms encryption is much faster than 319 decryption. For instance, on a machine at the time of writing, 320 encryption with a 2,048-bit RSA-3 key costs 82 microseconds, while 321 decryption costs 10 milliseconds. 323 Because servers often need to establish connections at a faster rate 324 than clients, and because servers are often passive openers, by 325 default the passive opener plays the "S" role. However, operating 326 systems MUST provide a mechanism for the passive opener to reverse 327 roles and play the "C" role, as discussed in Section 4.2. 329 3.4. Key exchange protocol 331 Every machine C has a short-lived public encryption key, K_C, which 332 gets refreshed periodically and SHOULD NOT ever be written to 333 persistent storage. 335 When a host C connects to S, the two engage in the following 336 protocol: 338 C -> S: HELLO 339 S -> C: PKCONF, pub-cipher-list 340 C -> S: INIT1, sym-cipher-list, N_C, K_C 341 S -> C: INIT2, sym-cipher, ENC (K_C, N_S) 343 Here the pub-cipher-list is a list of public key ciphers and key 344 lengths acceptable to S. Sym-cipher-list specifies the symmetric 345 cipher suites acceptable to C. N_C is a nonce chosen at random by C, 346 while K_C is C's public encryption key, which MUST match one of the 347 entries in pub-cipher-list. sym-cipher is the symmetric cipher suite 348 chosen by the server from sym-cipher-list. Finally N_S is a "pre- 349 session seed" chosen at random by S. 351 The two sides then compute a series of "session secrets" and 352 corresponding Session IDs as follows: 354 param := { pub-cipher-list, sym-cipher-list, sym-cipher } 356 ss[0] := CPRF (N_S, { K_C, param, N_C }) 357 ss[i] := CPRF (ss[i-1], TAG_NEXTK) 359 SID[i] := CPRF (ss[i], TAG_SESSID) 361 The value ss[0] is used to generate all key material for the current 362 connection. SID[0] is the session ID for the current connection, and 363 will with overwhelming probability be unique for each individual TCP 364 connection. The most computationally expensive part of the key 365 exchange protocol is the public key cipher. The values of ss[i] for 366 i > 0 can be used to avoid public key cryptography when establishing 367 subsequent connections between the same two hosts, as described in 368 Section 3.6. 370 Given a session secret, ss, the two sides compute a series of master 371 keys as follows: 373 mk[0] := CPRF (ss, TAG_REKEY) 374 mk[i] := CPRF (mk[i-1], TAG_REKEY) 376 Finally, each master key mk is used to generate four symmetric 377 encryption keys: 379 kec := CPRF (mk, TAG_KEY_C_ENC || 1) || CPRF (mk, TAG_KEY_C_ENC || 2) 380 kac := CPRF (mk, TAG_KEY_C_MAC || 1) || CPRF (mk, TAG_KEY_C_MAC || 2) 381 kes := CPRF (mk, TAG_KEY_S_ENC || 1) || CPRF (mk, TAG_KEY_S_ENC || 2) 382 kas := CPRF (mk, TAG_KEY_S_MAC || 1) || CPRF (mk, TAG_KEY_S_MAC || 2) 384 The numbers 1 and 2 are each 1-byte byte long. 386 kec is used by the host in the "C" role to encrypt Data in 387 transmitted TCP segments. If the symmetric encryption algorithm 388 requires shorter keys, the key is truncated, keeping the left-most 389 bytes only. Thus, if the symmetric cipher key length is less than or 390 equal to the CPRF output length, a host need not compute 391 CPRF (mk, TAG_KEY_C_ENC || 2). 393 kac is used by the host in the "C" role to compute MACs on 394 transmitted segments, as described in Section 4.4. The key is 395 truncated similarly to kec if the MAC requires a shorter key length. 396 If the symmetric cipher is used in a mode that provides 397 authentication as well as secrecy, kac need not be used. 399 kes and kas are used analogously to kec and kac for segments 400 transmitted by the host in the "S" role. 402 3.5. Re-keying 404 We refer to the four encryption keys (kec, kac, kes, kas) as a _key 405 set_. We refer to the key set generated by mk[i] as the key set with 406 _generation number_ i within a session. Initially, the two hosts use 407 the key set with generation number 0. 409 Either host may decide to evolve the encryption key at one or more 410 points within a session, by incrementing the generation number of its 411 transmit keys. When switching keys to generation j, a host must 412 label the segments it transmits with a REKEY option containing j, so 413 that the recipient host knows to check the MAC and decrypt the 414 segment using the new keyset: 416 A -> B: REKEY, MAC<...>, Data<...> 418 Upon receiving a REKEY segment, a recipient using transmit keys 419 from a generation less than j must also update its transmit keys and 420 start including a REKEY option in all of its segments. A host 421 must continue transmitting REKEY options until all segments with 422 other generation numbers have been processed at both ends. 424 Implementations MUST always transmit and retransmit identical 425 ciphertext Data bytes for the same TCP sequence numbers. Thus, a 426 retransmitted segment MUST always use the same keyset as the original 427 segment. If the encryption algorithm requires an initialization 428 vector, a retransmitted segment MUST additionally use the same 429 initialization vector as the original segment. Hosts MUST NOT 430 combine segments that were encrypted with different keysets or 431 incompatible initialization vectors. 433 Implementations SHOULD delete older-generation keys from memory once 434 they have received all segments they will need to decrypt with the 435 old keys and received acknowledgments for all segments they might 436 need to retransmit. 438 3.6. Session caching 440 When two hosts have already negotiated session secret ss[i-1], they 441 can establish a new connection without public key operations using 442 ss[i]. The four-message protocol of Section 3.4 is replaced by: 444 A -> B: NEXTK1, SID[i] 445 B -> A: NEXTK2 447 Which symmetric keys a host uses for transmitted segments is 448 determined by its role in the original session ss[0]. It does not 449 depend on which host is the passive opener in the current session. 450 If A had the "C" role in the first session, then A uses kec and kac 451 for sending segments. Otherwise, if A had the "S" role originally, 452 it uses kes and kas in the new session. B similarly uses the 453 transmit keys that correspond to its role in the original session. 455 After using ss[i] to compute mk[0], implementations SHOULD compute 456 and cache ss[i+1] for possible use by a later session, then erase 457 ss[i] from memory. Hosts SHOULD keep ss[i+1] around for a period of 458 time until it is used or the memory needs to be reclaimed. Hosts 459 SHOULD NOT write a cached ss[i+1] value to non-volatile storage. 461 It is an implementation-specific issue as to how long ss[i+1] should 462 be retained if it is unused. If the passive opener times it out 463 before the active opener does, the only cost is the additional twelve 464 bytes to send NEXTK1 for the next connection. The behavior then 465 falls back to a normal public-key handshake. 467 3.6.1. Session caching control 469 Implementations MUST allow applications to control session caching by 470 setting the following option: 472 TCP_CRYPT_CACHE_FLUSH When set on a TCP endpoint that is in the 473 ENCRYPTING state, this option causes the operating system to flush 474 from memory the cached ss[i+1] (or ss[i+1+n] if other connections 475 have already been established). When set on an endpoint that is 476 in the setup phase, causes any cached ss[i] that would have been 477 used to be flushed from memory. In either case, future 478 connections will have to undertake another round of the public key 479 protocol in Section 3.4. Applications SHOULD set 480 TCP_CRYPT_CACHE_FLUSH whenever authentication of the session ID 481 fails. 483 4. Extensions to TCP 485 The tcpcrypt extension adds two new kinds of option: CRYPT, and MAC. 486 Both are described in this section. During the setup phase, all TCP 487 segments MUST have the CRYPT option. In the ENCRYPTING state, all 488 segments MUST have the MAC option and may include the CRYPT option 489 for various purposes such as re-keying or keep-alive probes. 491 The idealized protocol of the previous section must be embedded in 492 the TCP handshake. Unfortunately, since the maximum TCP header size 493 is 60 bytes and the basic TCP header fields require 20 bytes, there 494 are at most 40 option payload bytes available, which is not enough to 495 hold the INIT1 and INIT2 messages. Tcpcrypt therefore uses the Data 496 portion of TCP segments to send the body of these messages. 498 Operating systems MUST keep track of which phase a data segment 499 belongs to, and MUST only deliver data to applications from segments 500 that are processed in the ENCRYPTING or DISABLED states. 502 4.1. Protocol states 504 The setup phase is divided into six states: CLOSED, NEXTK-SENT, 505 HELLO-SENT, C-MODE, LISTEN, and S-MODE. Together with the ENCRYPTING 506 and DISABLED states already discussed, this means a tcpcrypt endpoint 507 can be in one of eight states. 509 In addition to tcpcrypt's state, each endpoint will also be in one of 510 the 11 TCP states described in the TCP protocol specification 512 [RFC0793]. Not all pairs of states are valid. Table 1 shows which 513 TCP states an endpoint can be in for each tcpcrypt state. 515 +-------------+--------------------------+--------------------------+ 516 | Tcpcrypt | TCP states for an active | TCP states for a passive | 517 | state | opener | opener | 518 +-------------+--------------------------+--------------------------+ 519 | CLOSED | CLOSED | CLOSED | 520 | NEXTK-SENT | SYN-SENT | n/a | 521 | HELLO-SENT | SYN-SENT | SYN-RCVD | 522 | C-MODE | ESTABLISHED, FIN-WAIT-1 | ESTABLISHED, FIN-WAIT-1 | 523 | LISTEN | n/a | LISTEN | 524 | S-MODE | (SYN-RCVD), ESTABLISHED | SYN-RCVD | 525 | ENCRYPTING | (SYN-RCVD), ESTABLISHED+ | SYN-RCVD, ESTABLISHED+ | 526 | DISABLED | any | any | 527 +-------------+--------------------------+--------------------------+ 529 Valid tcpcrypt and TCP state combinations. States in parentheses 530 occur only with simultaneous open. ESTABLISHED+ means ESTABLISHED or 531 any later state (FIN-WAIT-1, FIN-WAIT-2, CLOSING, TIME-WAIT, CLOSE- 532 WAIT, or LAST-ACK). 534 Table 1 536 Figure 1 shows how tcpcrypt transitions between states. Each 537 transition is labeled by events that may trigger the transition above 538 the line, and an action the local host is permitted to take in 539 response below the line. "snd" and "rcv" denote sending and receiving 540 segments, respectively. "any" means any possible event. "internal" 541 means any possible event except for receiving a segment (i.e., timers 542 and system calls). "drop" means discarding the last received segment 543 and preventing it from having any effect on TCP's state. "mac" means 544 any valid TCP action, including no action, except that any segments 545 transmitted must be encrypted and contain a valid TCP MAC option. "x" 546 indicates that a host sends no segments when taking a transition. 548 A segment is described as "F/Op". F specifies constraints on the 549 control bits of the TCP header, as follows: 551 +----+------------------------------+ 552 | F | Meaning | 553 +----+------------------------------+ 554 | S | SYN=1, ACK=0, FIN=0, RST=0 | 555 | SA | SYN=1, ACK=1, FIN=0, RST=0 | 556 | A | SYN=0, ACK=1, FIN=0, RST=0 | 557 | S? | SYN=1, ACK=any, FIN=0, RST=0 | 558 | ?A | SYN=any, ACK=1, FIN=0, RST=0 | 559 | R | RST=1 | 560 | * | any | 561 +----+------------------------------+ 563 Op designates message types in the abstract protocol, which also 564 correspond to particular suboptions of the TCP CRYPT option, 565 described in Section 4.3, or "MAC" for a valid TCP MAC option, as 566 described in Section 4.4. A segment with SYN=1 and ACK=0 that 567 contains the NEXTK1 suboption will also explicitly or implicitly 568 contain the HELLO suboption; such a segment matches event constraints 569 on either option--e.g., it matches any of the "rcv S/HELLO", "rcv 570 S?/HELLO", and "rcv S/NEXTK1" events. An empty Op matches any 571 segment with the appropriate control bits. A segment MUST contain 572 the TCP MAC option if and only if Op is "MAC". 574 The "drop" transitions from NEXTK-SENT and HELLO-SENT to HELLO-SENT 575 change TCP slightly by ignoring a segment and preventing a TCP 576 transition from SYN-SENT to SYN-RCVD that would otherwise occur 577 during simultaneous open. Therefore, these transitions SHOULD be 578 disabled by default. They MAY be enabled on one side by an 579 application that wishes to enable tcpcrypt on simultaneous open, as 580 discussed in Section 4.2.1. 582 active OPEN passive OPEN 583 ------------ +----------+ ------------ +----------+ 584 snd S/NEXTK1 | CLOSED | x | LISTEN | 585 +-------------------| |------------->| |---------+ 586 | +----------+ +----------+ | 587 | +---+ |active OPEN | | | 588 | rcv S/HELLO| | |----------- rcv S/HELLO| | rcv S/NEXTK1| 589 | -----------| | |snd S/HELLO ------------| | -------------| 590 V drop| V V snd SA/HELLO| | snd SA/NEXTK2| 591 +----------+ | +----------+ | | | 592 | NEXTK- |___/ \| HELLO- |<------------------+ | | 593 | SENT | | SENT | |rcv S/HELLO | 594 +----------+ +----------+ |------------- | 595 | | | | |rcv S?/HELLO |snd SA/PKCONF | 596 | | |rcv S?/HELLO | |------------- V | 597 | | |------------- | |snd ?A/PKCONF +----------+ | 598 | | |snd ?A/PKCONF | +---------------->| S-MODE | | 599 | | +----------------|------------------>| | | 600 | +----------------+ | +----------+ | 601 | rcv SA/PKCONF| |rcv ?A/PKCONF | | 602 | -------------| |------------- |rcv A/INIT1 | 603 | snd A/INIT1| |snd A/INIT1 |----------- | 604 | V V |snd A/INIT2 | 605 | +----------+ | | 606 |rcv SA/NEXTK2 | C-MODE | +---+ | +---+ | 607 |------------- | | rcv */ | | | | |internal | 608 |snd A/MAC +----------+ -------| | | | |or rcv */MAC | 609 | == or == |rcv A/INIT2 drop| | | | |or rcv R/ | 610 |rcv S/NEXTK1 |----------- | V V V |------------ | 611 |------------ |x +----------+ |mac | 612 |snd SA/NEXTK2 +------------------>|ENCRYPTING|-+ | 613 +------------------------------------->| |<---------------+ 614 +----------+ 616 State diagram for tcpcrypt. Transitions to DISABLED and CLOSED are 617 not shown. 619 Figure 1 621 Any segment that would be discarded by TCP (e.g., for being out of 622 window) MUST also be ignored by tcpcrypt. However, certain segments 623 that might otherwise be accepted by TCP MUST be dropped by tcpcrypt 624 and prevented from affecting TCP's state. 626 Except for these drop actions, tcpcrypt MUST abide by the TCP 627 protocol specification [RFC0793]. Thus, any segment transmitted by a 628 host MUST be permitted by the TCP specification in addition to 629 matching either a transition in Figure 1 or one of the transitions to 630 DISABLED or CLOSED described below. In particular, a host MUST NOT 631 acknowledge an INIT1 segment unless either the acknowledgment 632 contains an INIT2 or the host transitions to DISABLED. 634 Various events cause transitions to DISABLED from states other than 635 ENCRYPTING. In particular: 637 o Operating systems MUST provide a mechanism for applications to 638 transition to DISABLED from the CLOSED and LISTEN states. 640 o A host in the setup phase MUST transition to DISABLED upon 641 receiving any segment without a TCP CRYPT option. 643 o A host in the setup phase MUST transition to DISABLED upon 644 receiving any segment with the FIN or RST control bit set. 646 o A host in the setup phase MUST transition to DISABLED upon sending 647 a segment with the FIN bit set. (As discussed below, however, a 648 host MUST NOT send a FIN segment from the C-MODE state.) 650 Other specific conditions cause a transition to DISABLED and are 651 discussed in the sections that follow. 653 CLOSED is a pseudo-state representing a connection that does not 654 exist. A tcpcrypt connection's lifetime is identical to that of its 655 associated TCP connection. Thus, tcpcrypt transitions to CLOSED 656 exactly when TCP transitions to CLOSED. 658 A host MUST NOT send a FIN segment from the C-MODE state. The reason 659 is that the remote side can be in the ENCRYPTING state and would thus 660 require the segment to contain a valid MAC, yet a host in C-MODE 661 cannot compute the necessary encryption keys before receiving the 662 INIT2 segment. 664 If a CLOSE happens in C-MODE, a host MUST delay sending a FIN segment 665 until receiving an ACK for its INIT1 segment. If the remote host is 666 in ENCRYPTING, the ACK segment will contain INIT2 and the local host 667 can transition to ENCRYPTING before sending the FIN. If the remote 668 host is not in ENCRYPTING, the ACK will not contain INIT2, and thus 669 the local host can transition to DISABLED before sending the FIN. 671 If a CLOSE happens in C-MODE, an implementation MAY delay processing 672 the CLOSE event and entering the TCP FIN-WAIT-1 state until sending 673 the FIN. If it does not, the implementation MUST ensure all relevant 674 timers correspond to the time of transmission of the FIN segment, not 675 the time of entry into the FIN-WAIT-1 state. 677 A CLOSE event in the ENCRYPTING state MUST NOT change tcpcrypt's 678 state, only TCP's. The only valid tcpcrypt state transition from 679 ENCRYPTING is to CLOSED, which occurs only when TCP also transitions 680 to CLOSED. 682 4.2. Role negotiation 684 A passive opener receiving an S/HELLO segment may choose to play the 685 "S" role (by transitioning to S-MODE) or the "C" role (by 686 transitioning to HELLO-SENT). An active opener may accept the role 687 not chosen by the passive opener, or may instead disable tcpcrypt. 688 During simultaneous open, one endpoint must choose the "C" role while 689 the other chooses the "S" role. Operating systems MUST allow 690 applications to guide these choices on a per-connection basis. 692 Applications SHOULD be able to exert this control by setting a per- 693 connection _CMODE disposition_, which can take on one of the 694 following five values: 696 TCP_CRYPT_CMODE_DEFAULT This disposition SHOULD be the default. A 697 passive opener will only play the "S" role, but an active opener 698 can play either the "C" or the "S" role. Simultaneous open 699 without session caching will cause tcpcrypt to be disabled unless 700 the remote host has set the TCP_CMODE_ALWAYS[_NK] disposition. 702 TCP_CRYPT_CMODE_ALWAYS 704 TCP_CRYPT_CMODE_ALWAYS_NK With this disposition, a host will only 705 play the "C" role. The _NK version additionally prevents the use 706 of session caching if the session was originally established in 707 the "S" role. 709 TCP_CRYPT_CMODE_NEVER 711 TCP_CRYPT_CMODE_NEVER_NK With this disposition, a host will only 712 play the "S" role. The _NK version additionally prevents the use 713 of session caching if the session was originally established in 714 the "C" role. 716 The CMODE disposition prohibits certain state transitions, as 717 summarized in Table 2. If an event occurs for which all valid 718 transitions in Figure 1 are prohibited, a host MUST transition to 719 DISABLED. Operating systems MAY add additional CMODE dispositions, 720 for instance to force or prohibit session caching. 722 +-----------------------------+---------------------------+ 723 | CMODE disposition | Prohibited transitions | 724 +-----------------------------+---------------------------+ 725 | TCP_CRYPT_CMODE_DEFAULT | LISTEN --> HELLO-SENT | 726 | | HELLO-SENT --> HELLO-SENT | 727 | | NEXTK-SENT --> HELLO-SENT | 728 | | | 729 | TCP_CRYPT_CMODE_ALWAYS[_NK] | any --> S-MODE | 730 | | | 731 | TCP_CRYPT_CMODE_NEVER[_NK] | LISTEN --> HELLO-SENT | 732 | | HELLO-SENT --> HELLO-SENT | 733 | | NEXTK-SENT --> HELLO-SENT | 734 | | any --> C-MODE | 735 +-----------------------------+---------------------------+ 737 State transitions prohibited by each CMODE disposition 739 Table 2 741 4.2.1. Simultaneous open 743 During simultaneous open, two ends of a TCP connection are both 744 active openers. If both hosts attempt to use session caching by 745 simultaneously transmitting S/NEXTK1 segments, and if both transmit 746 the same session ID, then both may reply with SA/NEXTK2 segments and 747 immediately enter the ENCRYPTING state. In this case, the host that 748 played "C" when the session was initially negotiated MUST use the 749 symmetric encryption keys for "C" (i.e., use kec and kac for 750 transmitted segments), while the host that initially played "S" uses 751 the "S" keys for the new connection. 753 If both hosts in a simultaneous open do not attempt to use session 754 caching, or if the two hosts use incompatible Session IDs, then they 755 MUST engage in public-key-based key negotiation to use tcpcrypt. 756 Doing so requires one host to play the "C" role and the other to play 757 the "S" role. With the TCP_CRYPT_CMODE_DEFAULT disposition, these 758 roles are usually determined by the passive opener choosing the "S" 759 role. With no passive opener, both active openers will end up in 760 S-MODE, then transition to DISABLED upon receiving an unexpected 761 PKCONF. 763 Simultaneous open can work with key negotiation if exactly one of the 764 two hosts selects the TCP_CRYPT_CMODE_ALWAYS disposition. This host 765 will then drop S/HELLO segments and remain in C-MODE while the other 766 host transitions to S-MODE. Applications SHOULD NOT set 767 TCP_CRYPT_CMODE_ALWAYS on both sides of a simultaneous open, as this 768 will cause even the underlying TCP connection to fail. 770 4.3. The TCP CRYPT option 772 A CRYPT option has the following format: 774 Byte 0 1 2 N 775 +-------+-------+-------...-------+ 776 | Kind= |Length=| Suboptions | 777 | OPT1 | N | | 778 +-------+-------+-------...-------+ 780 Format of TCP CRYPT option 782 Kind is always OPT1. Length is the total length of the option, 783 including the two bytes used for Kind and Length. These first two 784 bytes are then followed by zero or more suboptions. Suboptions 785 determine the meaning of the TCP CRYPT option. When a TCP header 786 contains more than one CRYPT option, a host MUST interpret them the 787 same as if all the suboptions appeared in a single CRYPT option. 789 Each suboption begins with an Opcode byte. The specific format of 790 the option depends on the two most significant bits of the Opcode. 792 Suboptions with opcodes from 0x00 to 0x3f contain no data other than 793 the single opcode byte: 795 bit 0 1 2 3 4 5 6 7 796 +-+-+-+-+-+-+-+-+ 797 | Opcode = | 798 |0 0 x x x x x x| 799 +-+-+-+-+-+-+-+-+ 801 Hosts MUST ignore any opcodes of this format that they do not 802 recognize. 804 Suboptions with opcodes from 0x40 to 0x7f contain an opcode, a length 805 field, and data bytes. 807 0 1 808 bit 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------... 810 | Opcode = | Length = | N-2 bytes 811 |0 1 x x x x x x| N | of suboption data 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------... 814 Hosts MUST ignore any opcodes of this format that they do not 815 recognize. 817 Suboptions with opcodes from 0x80 to 0xbf contain zero or more bytes 818 of data whose length depends on the opcode. These suboptions can be 819 either fixed length or variable length; implementations that 820 understand these opcodes will known which they are; if the suboption 821 is fixed length the implementation will know the length; otherwise it 822 will know where to look for the length field. 824 bit 0 1 2 3 4 5 6 7 825 +-+-+-+-+-+-+-+-+-------... 826 | Opcode = | data 827 |1 0 x x x x x x| 828 +-+-+-+-+-+-+-+-+-------... 830 If a host sees an unknown opcode in this range, it MUST ignore the 831 suboption and all subsequent suboptions in the same TCP CRYPT option. 832 However, if more than one CRYPT option appears in the TCP header, the 833 host MUST continue processing suboptions from the next TCP CRYPT 834 option. 836 Suboptions with opcodes from 0xc0 to 0xff also contain an opcode- 837 specific length of data. As before, these suboptions can be either 838 fixed length or variable length. However, suboptions in this range 839 are classed as mandatory as far as the protocol is concerned. 840 However, they are not MANDATORY to implement unless otherwise stated, 841 as discussed below. 843 bit 0 1 2 3 4 5 6 7 844 +-+-+-+-+-+-+-+-+-------... 845 | Opcode = | data 846 |1 1 x x x x x x| 847 +-+-+-+-+-+-+-+-+-------... 849 Should a host encounter an unknown opcode greater than or equal to 850 0xc0 during the setup phase of the protocol, the host MUST transition 851 to the DISABLED state. It SHOULD respond with both a DECLINE 852 suboption and an UNKNOWN suboption specifying the opcode of the 853 unknown mandatory suboption, after which the host MUST NOT send any 854 further CRYPT options. 856 Should a host encounter an unknown opcode greater than or equal to 857 0xc0 while in the ENCRYPTING state, the host MUST respond with an 858 UNKNOWN suboption specifying the opcode of the unknown mandatory 859 suboption, and should ensure the session continues with the same 860 encryption and authentication state as it had before the segment was 861 received. This may require ignoring other suboptions within the same 862 message, or reverting any half-negotiated state. 864 Table 3 summarizes the opcodes discussed in this document. It is 865 MANDATORY that all implementations support every opcode in this 866 table. Each opcode is listed with the length in bytes of the 867 suboption (including the opcode byte), or * for variable-length 868 suboptions. The last column specifies in which of the (S)etup phase, 869 (E)NCRYPTING state, and (D)ISABLED state an opcode may be used. A 870 host MUST NOT send an option unless it is in one of the stages 871 indicated by this column. 873 +-------+--------+---------------------+--------+ 874 | Value | Length | Name | Stages | 875 +-------+--------+---------------------+--------+ 876 | 0x01 | 1 | HELLO | S | 877 | 0x02 | 1 | HELLO-app-support | S | 878 | 0x03 | 1 | HELLO-app-mandatory | S | 879 | 0x04 | 1 | DECLINE | SD | 880 | 0x05 | 1 | NEXTK2 | S | 881 | 0x06 | 1 | INIT1 | S | 882 | 0x07 | 1 | INIT2 | S | 883 | 0x41 | * | PKCONF | S | 884 | 0x42 | * | PKCONF-app-support | S | 885 | 0x43 | * | UNKNOWN | SED | 886 | 0x44 | * | SYNCOOKIE | S | 887 | 0x45 | * | ACKCOOKIE | SED | 888 | 0x80 | 5 | SYNC_REQ | E | 889 | 0x81 | 5 | SYNC_OK | E | 890 | 0x82 | 2 | REKEY | E | 891 | 0x83 | 6 | REKEYSTREAM | E | 892 | 0x84 | 10 | NEXTK1 | S | 893 | 0x85 | * | IV | E | 894 +-------+--------+---------------------+--------+ 896 Opcodes for suboptions of the TCP CRYPT option. 898 Table 3 900 If a TCP segment (sent by an active opener) has the SYN flag set, the 901 ACK flag clear, and one or more TCP CRYPT options, there is an 902 implicit HELLO suboption even if that suboption does not appear in 903 the segment. In particular, when such a SYN segment contains a 904 single, empty, two-byte TCP CRYPT option, the passive opener MUST 905 interpret that option as equivalent to the three-byte TCP option 906 composed of bytes OPT1, 3, 1 (Kind = OPT1, Length = 3, Suboption = 907 HELLO). 909 A host MUST enter the DISABLED state if, during the setup phase, it 910 receives a segment containing neither a TCP CRYPT nor a TCP MAC 911 option. A host MUST also enter DISABLED if, during the setup phase, 912 it receives a DECLINE suboption or any unrecognized suboption with 913 opcode greater than or equal to 0xc0. Once a host has entered 914 DISABLED, it MUST NOT include the MAC option in any transmitted 915 segment. The host MAY include a CRYPT option in the next segment 916 transmitted, but only if the segment also contains the DECLINE 917 suboption. All subsequently transmitted packets MUST NOT contain the 918 CRYPT option. 920 4.3.1. The HELLO suboption 922 The HELLO dataless suboption MUST only appear in a segment with the 923 SYN control bit set. It is used by an active opener to indicate 924 interest in using tcpcrypt for a connection, and by a passive opener 925 to indicate that the passive opener wishes to play the "C" role. 927 The initial SYN segment from an active opener wishing to use tcpcrypt 928 MUST contain a TCP CRYPT option with either an explicit or an 929 implicit HELLO suboption. 931 After receiving a SYN segment with the HELLO suboption, a passive 932 opener MUST respond in one of three ways: 934 o To continue setting up tcpcrypt and play the "S" role, the passive 935 opener MUST respond with a PKCONF suboption in the SYN-ACK segment 936 and transition to S-MODE. 938 o To continue setting up tcpcrypt and play the "C" role, the passive 939 opener MUST respond with a HELLO suboption in the SYN-ACK segment 940 and transition to HELLO-SENT. 942 o To continue without tcpcrypt, the passive opener MUST respond with 943 either no CRYPT option or the DECLINE suboption in the SYN-ACK 944 segment, then transition to the DISABLED state. 946 An active opener receiving HELLO in a SYN-ACK segment must either 947 transition to S-MODE and respond with a PKCONF suboption, or 948 transition to DISABLED. 950 There are three variants of the HELLO option used for application- 951 level authentication: a plain HELLO where the application is not 952 tcpcrypt-aware (but the kernel is), an "application supported" HELLO 953 where the application is tcpcrypt-aware and is advertising the fact, 954 and a "application mandatory" HELLO where the application requires 955 the remote application to support tcpcrypt otherwise the connection 956 MUST revert to plain TCP. The application supported HELLO can be 957 used, for example, when implementing HTTP digest authentication - an 958 application can check whether the peer's application is tcpcrypt 959 aware and proceed to authenticate tcpcrypt's session ID over HTTP, 960 otherwise reverting to standard HTTP digest authentication. The 961 application mandatory HELLO can be used, for example, when 962 implementing an SSL library that attempts tcpcrypt but reverts to SSL 963 if the peer's SSL library does not support tcpcrypt. The application 964 mandatory HELLO avoids double encrypting (SSL-over-tcpcrypt) since 965 the connection will revert to plain TCP if the remote SSL library is 966 not tcpcrypt-ware. 968 4.3.2. The DECLINE suboption 970 The DECLINE dataless suboption is sent by a host to indicate that the 971 host will not enable tcpcrypt on a connection. If a host is in the 972 DISABLED state or transitioning to the DISABLED state, and the host 973 transmits a segment containing a CRYPT option, then the segment MUST 974 contain the DECLINE suboption. 976 A passive opener SHOULD send a DECLINE suboption in response to a 977 HELLO suboption or NEXTK1 suboption in a received SYN segment if it 978 supports tcpcrypt but does not wish to engage in encryption for this 979 particular session. 981 Implementations MUST NOT send segments containing the DECLINE 982 suboption from the C-MODE or ENCRYPTING states. 984 4.3.3. The NEXTK1 and NEXTK2 suboptions 986 The NEXTK1 suboption MUST only appear in a segment with the SYN 987 control bit set and the ACK bit clear. It is used by the active 988 opener to initiate a TCP session without the overhead of public key 989 cryptography. The new session key is derived from a previously 990 negotiated session secret, as described in Section 3.6. 992 The suboption is always 10 bytes in length; the data contains the 993 first nine bytes of SID[i] and is used to to start the session with 994 session secret ss[i]. The format of the suboption is: 996 Byte 0 1 2 3 997 +-------+-------+-------+-------+ 998 0 |Opcode | Bytes 0-2 | 999 | 0x84 | of SID[i] | 1000 +-------+-------+-------+-------+ 1001 4 | Bytes 3-6 | 1002 | of SID[i] | 1003 +-------+-------+-------+-------+ 1004 8 | Bytes 7-8 | 1005 | of SID[i] | 1006 +-------+-------+ 1008 Format of the NEXTK1 suboption 1010 The active opener MUST use the lowest value of i that has not already 1011 appeared in a NEXTK1 segment exchanged with the same host and for the 1012 same pre-session seed. 1014 If the passive opener recognizes SID[i] and knows ss[i], it SHOULD 1015 respond with a segment containing the dataless NEXTK2 suboption. The 1016 NEXTK2 option MUST only appear in a segment with both the SYN and ACK 1017 bits set. 1019 If the passive opener does not recognize SID[i], or SID[i] is not 1020 valid or has already been used, the passive opener SHOULD respond 1021 with a PKCONF or HELLO option and continue key negotiation as usual. 1023 When two hosts have previously negotiated a tcpcrypt session, either 1024 host may use the NEXTK1 option regardless of which host was the 1025 active opener or played the "C" role in the previous session. 1026 However, a given host must either use kec/kac for all sessions 1027 derived from the same pre-session seed, or kas/kes for all those 1028 sessions. Thus, which keys a host uses to send segments depends only 1029 whether the host played the "C" or "S" role in the initial session 1030 that used ss[0]; it is not affected by which host was the active 1031 opener transmitting the SYN segment containing a NEXTK1 suboption. 1033 A host MUST reject a NEXTK1 message if it has previously sent or 1034 received one with the same SID[i]. In the event that two hosts 1035 simultaneously send SYN segments to each other with the same SID[i], 1036 but the two segments are not part of a simultaneous open, both 1037 connections will have to revert to public key cryptography. To avoid 1038 this limitation, implementations MAY chose to implement session 1039 caching such that a given pre-session key is only good for either 1040 passive or active opens at the same host, not both. 1042 In the case of simultaneous open, two hosts that simultaneously send 1043 SYN packets with NEXTK1 and the same SID[i] may establish a 1044 connection, as described in Section 4.2.1. 1046 4.3.4. The PKCONF suboption 1048 The PKCONF option has the following format: 1050 Byte 0 1 2 N 1051 +-------+-------+-------...-------+ 1052 |Opcode=|Length=| Algorithm | 1053 | 0x41 | N | Specifiers | 1054 +-------+-------+-------...-------+ 1056 Format of the PKCONF suboption 1058 The suboption data, whose length (N-2) must be divisible by 3, 1059 contains one or more 3-byte algorithm specifiers of the following 1060 form: 1062 0 1 2 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 |0| Algorithm | Min-Key-Len | Max-Key-Len | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 Format of algorithm specifier within PKCONF suboption 1070 The following values of algorithm are defined: 1072 +-------+---------------------------+-------------+ 1073 | Value | Cipher | CPRF | 1074 +-------+---------------------------+-------------+ 1075 | 0x01 | Rabin-Williams | HMAC-SHA256 | 1076 | 0x02 | OAEP+-RSA with exponent 3 | HMAC-SHA256 | 1077 +-------+---------------------------+-------------+ 1079 (Values of algorithm over 127 are reserved for future use by multi- 1080 byte algorithm specifiers for algorithms with fixed key sizes or more 1081 compact min/max key length encodings.) 1083 Hosts SHOULD implement Rabin-Williams, and MUST implement OAEP+-RSA3. 1084 The Min-Key-Len and Max-Key-Len fields specify the minimum and 1085 maximum key sizes acceptable for each particular algorithm. The 1086 interpretation of the values of these fields depends on the 1087 particular algorithm. For the two algorithms listed above, the two 1088 Len values are expressed in terms of 256-bit (32-byte) key blocks, so 1089 that, for example, the following algorithm specifier designates 1090 Rabin-Williams keys with lengths from 1,024 to 8,192 bits. 1092 0 1 2 1093 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 |0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|0 0 1 0 0 0 0 0| 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 Depending on the value of the PKCONF suboption, it can either 1099 indicate that the application is tcpcrypt-aware or not. This can be 1100 used for bootstrapping application-level authentication without 1101 requiring probing in upper layer protocols to check for support 1102 (which may not be possible). 1104 4.3.5. The UNKNOWN suboption 1106 The UNKNOWN option has the following format: 1108 Byte 0 1 2 N 1109 +-------+-------+-------........-------+ 1110 |Opcode=|Length=| N-2 unknown one-byte | 1111 | 0x42 | N | opcodes received | 1112 +-------+-------+-------........-------+ 1114 Format of the UNKNOWN suboption 1116 This suboption is sent in response to an unknown suboption that has 1117 been received. The contents of the option are a complete list of the 1118 mandatory suboption opcodes from the received packet that were not 1119 understood. Note that this option is only sent once, in the next 1120 packet that the host sends. This means that it is reliable when sent 1121 in a SYN-ACK, but unreliable otherwise. Any mechanism sending new 1122 mandatory attributes must take this into account. If multiple 1123 packets, each containing unknown options, are received before an 1124 UNKNOWN suboption can be sent, the options list MUST contain the 1125 union of the two sets. The order of the opcode list is not 1126 significant. 1128 If a host receives an unknown option, it SHOULD reply with the 1129 UNKNOWN suboption to notify the other side. If the host transitions 1130 to DISABLED as a result of the unknown option, then the host MUST 1131 also include the DECLINE suboption if it sends an UNKNOWN suboption 1132 (or more generally if it includes a CRYPT option in the next packet). 1134 As a special case, if PKCONF (0x41) or INIT1 (0x06) appears in the 1135 unknown opcode list, it does not mean the sender does not understand 1136 the option (since these options are MANDATORY). Instead, it means 1137 the sender does not implement any of the algorithms specified in the 1138 PKCONF or INIT1 message. In either case, the segment must also 1139 contain a DECLINE suboption. 1141 4.3.6. The SYNCOOKIE and ACKCOOKIE suboptions 1143 A passive opener MAY include the SYNCOOKIE suboption in a segment 1144 with both the SYN and ACK flags set. SYNCOOKIE allows a server to be 1145 stateless until the TCP handshake has completed. If has the 1146 following format: 1148 Byte 0 1 2 N 1149 +-------+-------+-------...-------+ 1150 |Opcode=|Length=| N-2 bytes of | 1151 | 0x43 | N | opaque data | 1152 +-------+-------+-------...-------+ 1154 Format of the SYNCOOKIE suboption 1156 The data is opaque as far as the protocol is concerned; it is 1157 entirely up to implementations how to make use of this suboption to 1158 hold state. It is OPTIONAL to send a SYNCOOKIE, but MANDATORY to 1159 understand and respond to them. 1161 The ACKCOOKIE suboption echoes the contents of a SYNCOOKIE; it MUST 1162 be sent in a packet acknowledging receipt of a packet containing a 1163 SYNCOOKIE, and MUST NOT be sent in any other packet. If has the 1164 following format: 1166 Byte 0 1 2 N 1167 +-------+-------+-------...-------+ 1168 |Opcode=|Length=| N-2 bytes of | 1169 | 0x44 | N | SYNCOOKIE data | 1170 +-------+-------+-------...-------+ 1172 Format of the ACKCOOKIE suboption 1174 Servers that rely on suboption data from ACKCOOKIE to reconstruct 1175 session state SHOULD embed a cryptographically strong message 1176 authentication code within the SYNCOOKIE data so as to be able to 1177 reject forged ACKCOOKIE suboptions. 1179 Though an implementation MUST NOT send a SYNCOOKIE in any context 1180 except the SYN-ACK packet returned by a passive opener, 1181 implementations SHOULD accept SYNCOOKIEs in other contexts and reply 1182 with the appropriate ACKCOOKIE if possible. 1184 4.3.7. The SYNC_REQ and SYNC_OK suboptions 1186 Many hosts implement TCP Keep-Alives [RFC1122] as an option for 1187 applications to ensure that the other end of a TCP connection still 1188 exists even when there is no data to be sent. A TCP Keep-Alive 1189 segment carries a sequence number one prior to the beginning of the 1190 send window, and may carry one byte of "garbage" data. Such a 1191 segment causes the remote side to send an acknowledgment. 1193 Unfortunately, Keep-Alive acknowledgments might not contain unique 1194 data. Hence, an old but cryptographically valid acknowledgment could 1195 be replayed by an attacker to prolong the existence of a session at 1196 one host after the other end of the connection no longer exists. 1197 (Such an attack might prevent a process with sensitive data from 1198 exiting, giving an attacker more time to compromise a host and 1199 extract the sensitive data.) 1201 The TCP Timestamps Option (TSopt) [RFC1323] could alternatively have 1202 been used to make Keep-Alives unique. However, because some 1203 middleboxes change the value of TSopt in packets, tcpcrypt does not 1204 protect the contents of the TCP TSopt option. Hence the SYNC_REQ and 1205 SYNC_OK suboptions allow the cryptographically protected TCP CRYPT 1206 option to contain unique data. 1208 The SYNC_REQ suboption is always 5 bytes, and has the following 1209 format: 1211 Byte 0 1 2 3 4 1212 +-------+-------+-------+-------+-------+ 1213 |Opcode=| Clock | 1214 | 0x80 | | 1215 +-------+-------+-------+-------+-------+ 1217 Format of the SYNC_REQ suboption 1219 Clock is a 32-bit non-decreasing value. A host MUST increment Clock 1220 at least once for every interval in which it sends a Keep-Alive. 1221 Implementations that support TSopt MAY chose to use the same value 1222 for Clock that they would put in the TSval field of the TCP TSopt. 1223 However, implementations SHOULD "fuzz" any system clocks used to 1224 avoid disclosing either when a host was last rebooted or at what rate 1225 the hardware clock drifts. 1227 A host that receives a SYNC_REQ suboption MUST reply with a SYNC_OK 1228 suboption, which is always five bytes and has the following format: 1230 Byte 0 1 2 3 4 1231 +-------+-------+-------+-------+-------+ 1232 |Opcode=| Received-Clock | 1233 | 0x81 | | 1234 +-------+-------+-------+-------+-------+ 1236 Format of the SYNC_OK suboption 1238 The value of Received-Clock depends on the values of the Clock fields 1239 in SYNC_REQ messages a host has received. A host must set Received- 1240 Clock to a value at least as high as the most recently received 1241 Clock, but no higher than the highest Clock value received this 1242 session. If a host delays acknowledgment of multiple packets with 1243 SYNC_REQ suboptions, it SHOULD send a single SYNC_OK with Received- 1244 Clock set to the highest Clock in the packets it is acknowledging. 1246 Because middleboxes sometimes "correct" inconsistent retransmissions, 1247 Keep-Alive segments with one byte of garbage data MUST use the same 1248 ciphertext byte as previously transmitted for that sequence number. 1249 Otherwise, a middlebox might change the byte back to its value in the 1250 original transmission, causing the cryptographic MAC to fail. 1252 4.3.8. The REKEY and REKEYSTREAM suboptions 1254 The REKEY and REKEYSTREAM suboptions are used to evolve encryption 1255 keys. Exactly one of the two options is valid with any given 1256 symmetric encryption algorithm and mode. Generally block ciphers 1257 will use REKEY while stream ciphers use REKEYSTREAM. We refer to a 1258 segment containing either option as a REKEY segment. 1260 REKEY allows hosts to wipe from memory keys that could decrypt 1261 previously transmitted segments. It also allows the use of message 1262 authentication codes that are only secure up to a fixed number of 1263 messages. However, implementations MUST work in the presence of 1264 middleboxes that "correct" inconsistent data retransmissions. Hence, 1265 the value of ciphertext bytes must be the same in the original 1266 transmission and all retransmissions of a particular sequence number. 1267 This means a host MUST always use the same encryption key when 1268 transmitting or retransmitting the same range of sequence numbers. 1269 Re-keying only affects data transmitted in the future. Moreover, 1270 segments encrypted with different keysets MUST NOT be combined in 1271 retransmissions. 1273 When switching keys, the REKEY suboption specifies which key set has 1274 been used to encrypt and integrity-protect the current segment. The 1275 suboption is always two bytes, and has the following format: 1277 Byte 0 1 1278 +-------+-------+ 1279 |Opcode=|KeyLSB | 1280 | 0x83 | | 1281 +-------+-------+ 1283 Format of the REKEY suboption 1285 KeyLSB is the generation number of the keys used to encrypt and MAC 1286 the current segment, modulo 256. REKEYSTREAM is the same as REKEY 1287 but includes the TCP Sequence Number offset at which the key change 1288 took effect, for cases in which decryption requires knowing how many 1289 bytes have been encrypted thus far with a key. To interoperate with 1290 middleboxes that rewrite sequence numbers, offsets from the Initial 1291 Sequence Number (ISN) are used instead of TCP sequence numbers 1292 throughout tcpcrypt. The same occurs when dealing with 1293 acknowledgement numbers. 1295 Byte 0 1 2 3 4 5 1296 +-------+-------+-------+-------+-------+-------+ 1297 |Opcode=|KeyLSB | Sequence Number Offset | 1298 | 0x83 | | from ISN | 1299 +-------+-------+-------+-------+-------+-------+ 1301 Format of the REKEYSTREAM suboption 1303 A host MAY use REKEY to increment the session key generation number 1304 beyond the highest generation it knows the other side to be using. 1305 We call this process _initiating_ re-keying. When one host initiates 1306 re-keying, the other host MUST increment its key generation number to 1307 match, as described blow (unless the other host has also 1308 simultaneously initiated re-keying). 1310 A host MAY initiate re-keying by including a REKEY suboption in a 1311 _syncable_ segment. A syncable segment is one that either contains 1312 data, or is acknowledgment-only but contains a SYNC_REQ suboption 1313 with a fresh Clock value--i.e., higher than any Clock value it has 1314 previously transmitted. We say a syncable segment is _synced_ when 1315 the transmitter knows the remote side has received it and all 1316 previous sequence numbers. A data segment is synced when the 1317 transmitter receives a cumulative acknowledgment for its sequence 1318 number (a Selective Acknowledgment [RFC2018] is insufficient). An 1319 acknowledgment-only segment is synced when the sender receives an 1320 acknowledgment for its sequence number and a SYNC_OK with a high 1321 enough Clock number. 1323 A host MUST NOT initiate re-keying with an acknowledgment-only 1324 segment that has either no SYNC_REQ suboption or a SYNC_REQ with an 1325 old Clock value, because such a segment is not syncable. A host MUST 1326 NOT initiate re-keying with any KeyLSB other than its current key 1327 number plus one modulo 256. 1329 When a host receives a segment containing a REKEY suboption, it MUST 1330 proceed as follows: 1332 1. The receiver computes RECEIVE-KEY-NUMBER to be the closest 1333 integer to its own transmit key number that also equals KeyLSB 1334 modulo 256. If no number is closest (because KeyLSB is exactly 1335 128 away from the transmit number modulo 256), the receiver MUST 1336 discard the segment. If RECEIVE-KEY-NUMBER is negative, the 1337 receiver MUST also discard the segment. 1339 2. The receiver MUST authenticate and decrypt the segment using the 1340 receive keys with generation number RECEIVE-KEY-NUMBER. The 1341 receiver MUST discard the packet as usual if the MAC is invalid. 1343 3. If RECEIVE-KEY-NUMBER is greater than the receiver's current 1344 transmit key number, the receiver must wait to receive all 1345 sequence numbers prior to the REKEY segment's. Once it receives 1346 segments covering all these missing sequence numbers (if any), it 1347 MUST increase its transmit number to RECEIVE-KEY-NUMBER and 1348 transmit a REKEY suboption. If the receiver has gotten multiple 1349 REKEY segments with different KeyLSB values, it MUST increase its 1350 transmit key number to the highest RECEIVE-KEY-NUMBER of any 1351 segment for which it is not missing prior sequence numbers. 1353 After sending a REKEY (whether initiating re-keying or just 1354 responding), a host MUST continue to send REKEY in all subsequent 1355 segments until at least one of the following holds: 1357 o One of the REKEY segments the host transmitted for its current 1358 transmit key number was syncable, and it has been synced. 1360 o The host receives a cumulative acknowledgment for one of its REKEY 1361 segments with the current transmit key number, and the cumulative 1362 acknowledgment is in a segment encrypted with the new key but not 1363 containing a REKEY suboption. 1365 A host SHOULD erase old keys from memory once the above requirements 1366 are met. 1368 A host MUST NOT initiate re-keying if it initiated a re-keying less 1369 than 60 seconds ago and has not transmitted at least 1 Megabyte 1370 (increased its sequence number by 1,048,576) since the last re- 1371 keying. A host MUST NOT initiate re-keying if it has outstanding 1372 unacknowledged REKEY segments for key numbers that are 127 or more 1373 below the current key. A host SHOULD not initiate more than one 1374 concurrent re-key operation if it has no data to send. 1376 4.3.9. The INIT1 and INIT2 suboptions 1378 The INIT1 dataless suboption indicates that the Data portion of the 1379 TCP segment contains the following data structure: 1381 Byte 0 1 2 3 1382 +-------+-------+-------+-------+ 1383 | 0x0001 | # sym ciphers | 1384 +-------+-------+-------+-------+ 1385 |# bytes of N_C |# bytes of K_C | 1386 +-------+-------+-------+-------+ 1387 | symmetric cipher | 1388 : : 1389 +-------+-------+-------+-------+ 1390 | N_C | 1391 : : 1392 +-------+-------+-------+-------+ 1393 | 0 | type of K_C | 1394 +-------+-------+-------+-------+ 1395 | K_C | 1396 : : 1397 +-------+-------+-------+-------+ 1399 Each symmetric cipher has the following format: 1401 0 1 2 3 1402 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 4 5 6 7 8 9 0 1 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 |0 0 0 0 0 0 0 0| cipher alg |0 0 0 0 0 0 0 0| MAC alg | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 Format of symmetric cipher within INIT1 suboption 1409 Note that the cipher and MAC are specified as a pair, using an 8-bit 1410 identifier to specify each supported algorithm. The special cipher 1411 value of 0 means that a MAC can be used with any cipher, or a cipher 1412 with any MAC. The following cipher values are mandatory and MUST be 1413 supported by all implementations: 1415 +-------+---------------------------------+ 1416 | value | cipher | 1417 +-------+---------------------------------+ 1418 | 0x00 | Any cipher okay with this MAC | 1419 | 0x01 | AES-128 CTR mode w. seqno as IV | 1420 +-------+---------------------------------+ 1422 With AES-128 CTR mode, bytes are encrypted using their extended 64- 1423 bit sequence number offset from the ISN. To encrypt the byte for 1424 sequence number offset N: 1426 o Compute B = N - (N % 16). 1428 o Let B* = 0^{128-|B|} || B be B with enough 0 bits pre-pended to 1429 make B* exactly 128 bits long. 1431 o Let C = ENC-AES (ke[cs], B*). 1433 o XOR the message byte with byte (N-B) of C. 1435 The following MACs are mandatory and MUST be supported by all 1436 implementations. 1438 +-------+-------------------------------+ 1439 | value | MAC | 1440 +-------+-------------------------------+ 1441 | 0x00 | Any MAC okay with this cipher | 1442 | 0x01 | HMAC-SHA2-128 | 1443 +-------+-------------------------------+ 1445 The value "type of K_C" must be one of the public key specifiers 1446 included earlier in the other host's PKCONF message. 1448 The INIT2 dataless suboption indicates that the Data portion of the 1449 TCP segment contains the following data structure: 1451 Byte 0 1 2 3 1452 +-------+-------+-------+-------+ 1453 | 0x0002 |#byt ciphertext| 1454 +-------+-------+-------+-------+ 1455 | symmetric cipher suite | 1456 +-------+-------+-------+-------+ 1457 | ciphertext | 1458 : : 1459 +-------+-------+-------+-------+ 1461 Here the symmetric cipher suite is one selected by the host 1462 transmitting the INIT2 segment, which will be playing the "S" role. 1463 Neither the cipher nor the MAC may have value 0x00 in the INIT2 1464 segment. The ciphertext is an encryption of N_S, as described in 1465 Section 3.4. 1467 Hosts MUST set the TCP PSH control bits on INIT1 and INIT2 segments. 1468 Implementations MUST NOT set the TCP FIN control bit on INIT2 1469 segments. 1471 4.3.10. The IV suboption 1473 The IV suboption is used to hold an initialization vector (IV) when 1474 the negotiated encryption mode requires an initialization vector to 1475 be transmitted with packets. It MUST NOT be included in transmitted 1476 packets except in the ENCRYPTING state when the negotiated encryption 1477 mode requires IVs. When the negotiated encryption mode does require 1478 IVs, all segments transmitted in ENCRYPTING mode MUST contain an IV 1479 suboption. 1481 The IV suboption has the following format: 1483 Byte 0 1 N 1484 +-------+-------...-------+ 1485 |Opcode=| Initialization | 1486 | 0x85 | Vector | 1487 +-------+-------...-------+ 1489 Format of the IV suboption 1491 The length N of the IV is determined by the encryption algorithm and 1492 mode negotiated. 1494 As discussed in Section 4.3.8, a host MUST always transmit the same 1495 ciphertext byte in retransmissions of a particular sequence number. 1496 Thus, retransmitted segments must use the same IV each time. 1497 Moreover, previously transmitted segments MUST NOT be combined on 1498 retransmission if their IVs would prevent the ciphertext bytes from 1499 remaining the same as in the original transmission. 1501 4.4. The TCP MAC option 1503 The MAC option is used to authenticate a TCP segment as described in 1504 the next section. Once a host has entered the encrypting phase for a 1505 session, the HOST must include a TCP MAC option in all segments it 1506 sends. Furthermore, once in the encrypting phase, a host MUST ignore 1507 any segments it receives that do not have a valid MAC option, except 1508 for segments with the RST bit set if the application has not 1509 requested cryptographic verification of RST segments. 1511 The length of the MAC option is determined by the symmetric message 1512 authentication code selected. The format of the MAC option is: 1514 Byte 0 1 2 N+1 1515 +-------+-------+------...------+ 1516 | Kind | Len= | N-byte | 1517 | OPT2 | 2+N | MAC | 1518 +-------+-------+------...------+ 1520 Format of TCP MAC option 1522 The MAC is computed based on two data structures, a pseudo-packet 1523 structure we call M, and an acknowledgment structure we call A. The 1524 format of M is as follows: 1526 Byte 0 1 2 3 1527 +-------+-------+-------+-------+ 1528 0 | 0x8000 | length | 1529 +-------+-------+-------+-------+ 1530 4 | off | flags | window | 1531 +-------+-------+---------------+ 1532 8 | 0x0000 | urg | 1533 +-------+-------+-------+-------+ 1534 12 | seqno offset hi | 1535 +-------+-------+-------+-------+ 1536 16 | seqno offset | 1537 +-------+-------+-------+-------+ 1538 20 | options | 1539 : : 1540 +-------+-------+-------+-------+ 1541 | payload ciphertext | 1542 | must be len-off bytes | 1543 : : 1544 +-------+-------+-------+-------+ 1546 M data structure 1548 The fields of M are defined as follows: 1550 length 1551 Total size of the TCP segment from the start of the TCP header to 1552 the end of the IP datagram. 1554 off 1555 Byte 12 of the TCP header (Data Offset) 1557 flags 1558 Byte 13 of the TCP header (Control Bits) 1560 window 1561 Bytes 14-15 of the TCP header (Window) 1563 urg 1564 Bytes 18-19 of the TCP header (Urgent Pointer) 1566 seqno offset hi 1567 Number of times the seqno offset field has wrapped from 0xffffff 1568 -> 0 1570 seqno offset 1571 The low 32 bits of the sequence number offset (the Sequence Number 1572 in the TCP header - ISN) 1574 options 1575 These are bytes 20-off of the TCP header. However, where the 1576 TSOPT (8), Skeeter (16), Bubba (17), MD5 (19), and MAC (OPT2) 1577 options appear, their contents (all but the kind and length bytes) 1578 are replaced with all zeroes. 1580 payload ciphertext 1581 This is the Data portion of the TCP segment, which contains 1582 encrypted ciphertext. 1584 The format of the A structure is as follows: 1586 Byte 0 1 2 3 1587 +-------+-------+-------+-------+ 1588 0 | ackno offset hi | 1589 +-------+-------+-------+-------+ 1590 4 | ackno offset | 1591 +-------+-------+-------+-------+ 1593 A data structure 1595 The fields of A are defined as follows: 1597 ackno offset hi The number of times ackno offset hi has wrapped from 1598 0xffffff -> 0. 1600 ackno offset The lower 32 bits of the acknowledgement number offset 1601 from the remote end's ISN (TCP's acknowledgement header - ISN 1602 received). 1604 For HMAC-SHA2-128, The N-byte MAC value in the option contains the 1605 exclusive OR of MAC (M) and MAC (A). 1607 5. Examples 1609 To illustrate these suboptions, consider the following series of ways 1610 in which a TCP connection may be established from host A to host B. 1611 We use notation S for SYN-only packet, SA for SYN-ACK packet, and A 1612 for packets with the ACK bit but not SYN bit. These examples are not 1613 normative. 1615 5.1. Example 1: Normal handshake 1617 (1) A -> B: S CRYPT<> 1618 (2) B -> A: SA CRYPT> 1619 (3) A -> B: A data 1620 (4) B -> A: A data 1621 (5) A -> B: A MAC data<...> 1623 (1) A indicates interest in using tcpcrypt. In (2), the server 1624 indicates willingness to accept Rabin-Williams public keys between 1625 1,024 and 4,096 bytes long. Messages (3) and (4) complete the INIT1 1626 and INIT2 key exchange messages described above, which are embedded 1627 in the data portion of the TCP segment. (5) From this point on, all 1628 messages are encrypted, and their integrity protected by a MAC option 1629 (described in the next section). 1631 5.2. Example 2: Normal handshake with SYN cookie 1633 (1) A -> B: S CRYPT<> 1634 (2) B -> A: SA CRYPT, SYNCOOKIE> 1635 (3) A -> B: A CRYPT> data 1636 (4) B -> A: A data 1637 (5) B -> A: A MAC data<...> 1639 Same as previous example, except the server sends the client a SYN 1640 cookie value, which the client must echo in (3). Here also the 1641 application level protocol begins by B transmitting data, while in 1642 the previous example A was the first to transmit application-level 1643 data. 1645 5.3. Example 3: tcpcrypt unsupported 1647 (1) A -> B: S CRYPT<> 1648 (2) B -> A: SA 1649 (3) A -> A: A 1651 (1) A indicates interest in using tcpcrypt. (2) B does not support 1652 tcpcrypt, or a middle box strips out the CRYPT TCP option. (3) the 1653 client completes a normal three-way handshake, and tcpcrypt is not 1654 enabled for the connection. 1656 5.4. Example 4: Reusing established state 1658 (1) A -> B: S CRYPT> 1659 (2) B -> A: SA CRYPT 1660 (3) A -> A: A MAC 1662 (1) A indicates interest in using tcpcrypt with a session key derived 1663 from an existing key, to avoid the use of public key cryptography for 1664 the new session. (2) B supports tcpcrypt, has ID in its session ID 1665 cache and is willing to proceed with session caching. (3) the client 1666 completes tcpcrypt's handshake within TCP's three-way handshake, and 1667 tcpcrypt is enabled for the connection. 1669 5.5. Example 5: Decline of state reuse 1671 (1) A -> B: S CRYPT> 1672 (2) B -> A: SA CRYPT> 1673 (3) A -> B: A data 1674 (4) B -> A: A data 1675 (5) A -> B: A MAC data<...> 1677 A wishes to use a key derived from a previous session key, but B does 1678 not recognize the session ID or has flushed it from its cache. 1679 Therefore session establishment proceeds as in the first connection, 1680 with public key encryption. 1682 5.6. Exmaple 6: Reversal of client and server roles 1684 (1) A -> B: S CRYPT<> 1685 (2) B -> A: SA CRYPT 1686 (3) A -> B: A CRYPT> 1687 (4) B -> A: A data 1688 (5) A -> B: A data 1689 (6) B -> A: A MAC data<...> 1691 Here the server, B, wishes to play the role of the decryptor. By 1692 sending a HELLO suboption, it causes A to switch roles, so that now A 1693 is "S" and B can play the role of "C". 1695 6. API extensions 1697 The getsockopt call should have new options for IPPROTO_TCP: 1699 TCP_CRYPT_SESSID -> should return the session ID or error if no 1700 tcpcrypt. 1702 TCP_CRYPT_PUBKEY -> should return (mine, pubkey), where pubkey is 1703 the public key used to establish the session (K_C), and mine says 1704 whether the key belongs to this host or the remote peer. 1706 TCP_CRYPT_CONF -> returns encryption algorithms used for the 1707 current session. 1709 TCP_CRYPT_SUPPORT -> returns 1 if the remote application is 1710 tcpcrypt-aware. 1712 The setsockopt call should have: 1714 TCP_CRYPT_CACHE_FLUSH -> setting wipes cached session keys. 1715 Useful if application-level authentication discovers a man in the 1716 middle attack, to prevent the next connection from using NEXTK. 1718 The following options should be readable and writable with getsockopt 1719 and setsockopt: 1721 TCP_CRYPT_ENABLE -> one bit, enables or disables tcpcrypt 1722 extension on an unconnected (listening or new) socket. 1724 TCP_CRYPT_SECURST -> one bit, means ignore unauthenticated RST 1725 packets for this connection when set to 1. 1727 TCP_CRYPT_CMODE_{DEFAULT,NEVER,ALWAYS}[_NK] -> As described in 1728 Section 4.2. 1730 TCP_CRYPT_PKCONF -> set of allowed public key algorithms and CPRFs 1731 this host advertises in CRYPT PKCONF suboptions. 1733 TCP_CRYPT_CCONF -> set of allowed symmetric ciphers and message 1734 authentication codes this host advertises in CRYPT INIT1 segments. 1736 TCP_CRYPT_SCONF -> order of preference of symmetric ciphers. 1738 TCP_CRYPT_SUPPORT -> set to 1 if the application is tcpcrypt- 1739 aware. set to 2 if the application requires the remote application 1740 to be tcpcrypt-aware. 1742 Finally, system administrators must be able to set the following 1743 system-wide parameters: 1745 o Default TCP_CRYPT_ENABLE value 1747 o Default TCP_CRYPT_PKCONF value 1749 o Default TCP_CRYPT_CCONF value 1751 o Default TCP_CRYPT_SCONF value 1753 o Types, key lengths, and regeneration intervals of local host's 1754 ephemeral public keys 1756 The session ID can be used for end-to-end security. For instance, 1757 applications might sign the session ID with public keys to 1758 authenticate their ends of a connection. Because session IDs are not 1759 secret, servers can sign them in batches to amortize the cost of the 1760 signature over multiple connections. Alternative, DSA signatures are 1761 cheaper to compute than to verify, so might be a good way for servers 1762 to authenticate themselves. A voice application could display the 1763 session ID on both parties' screens, and if they confirm by voice 1764 that they have the same ID, then the conversation is secure. 1766 Because the public key may change less often than once a session, it 1767 may alternatively be useful for the local end of a connection to 1768 authenticate itself by signing the local host's public key instead of 1769 the session ID. 1771 7. Acknowledgments 1773 This work was funded by gifts from Intel (to Brad Karp) and from 1774 Google, and by NSF award CNS-0716806 (A Clean-Slate Infrastructure 1775 for Information Flow Control). 1777 8. IANA Considerations 1779 When tcpcrypt is extended, the following numbers must be assigned by 1780 IANA: 1782 o New opcodes for CRYPT suboptions 1784 o New identifiers for public key algorithms 1786 o New identifiers for symmetric key algorithms 1788 This memo includes no request to IANA. 1790 All drafts are required to have an IANA considerations section (see 1791 the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] 1792 for a guide). If the draft does not require IANA to do anything, the 1793 section contains an explicit statement that this is the case (as 1794 above). If there are no requirements for IANA, the section will be 1795 removed during conversion into an RFC by the RFC Editor. 1797 9. Security Considerations 1799 All drafts are required to have a security considerations section. 1800 See RFC 3552 [RFC3552] for a guide. 1802 10. References 1804 10.1. Normative References 1806 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1807 RFC 793, September 1981. 1809 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1810 Communication Layers", STD 3, RFC 1122, October 1989. 1812 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 1813 for High Performance", RFC 1323, May 1992. 1815 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 1816 Selective Acknowledgment Options", RFC 2018, October 1996. 1818 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1819 Hashing for Message Authentication", RFC 2104, 1820 February 1997. 1822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1823 Requirement Levels", BCP 14, RFC 2119, March 1997. 1825 [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography 1826 Specifications Version 2.0", RFC 2437, October 1998. 1828 10.2. Informative References 1830 [I-D.narten-iana-considerations-rfc2434bis] 1831 Narten, T. and H. Alvestrand, "Guidelines for Writing an 1832 IANA Considerations Section in RFCs", 1833 draft-narten-iana-considerations-rfc2434bis-09 (work in 1834 progress), March 2008. 1836 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1837 Text on Security Considerations", BCP 72, RFC 3552, 1838 July 2003. 1840 Appendix A. Protocol constant values 1842 +-------+---------------+ 1843 | Value | Name | 1844 +-------+---------------+ 1845 | 0x01 | TAG_NEXTK | 1846 | 0x02 | TAG_SESSID | 1847 | 0x03 | TAG_REKEY | 1848 | 0x04 | TAG_KEY_C_ENC | 1849 | 0x05 | TAG_KEY_C_MAC | 1850 | 0x06 | TAG_KEY_S_ENC | 1851 | 0x07 | TAG_KEY_S_MAC | 1852 +-------+---------------+ 1854 Protocol constants. 1856 Table 4 1858 Authors' Addresses 1860 Andrea Bittau 1861 Stanford University 1862 Department of Computer Science 1863 353 Serra Mall, Room 288 1864 Stanford, CA 94305 1865 US 1867 Phone: +1 650 723 8777 1868 Email: bittau@cs.stanford.edu 1870 Dan Boneh 1871 Stanford University 1872 Department of Computer Science 1873 353 Serra Mall, Room 475 1874 Stanford, CA 94305 1875 US 1877 Phone: +1 650 725 3897 1878 Email: dabo@cs.stanford.edu 1879 Mike Hamburg 1880 Stanford University 1881 Department of Computer Science 1882 353 Serra Mall, Room 475 1883 Stanford, CA 94305 1884 US 1886 Phone: +1 650 725 3897 1887 Email: mike@shiftleft.org 1889 Mark Handley 1890 University College London 1891 Department of Computer Science 1892 University College London 1893 Gower St. 1894 London WC1E 6BT 1895 UK 1897 Phone: +44 20 7679 7296 1898 Email: M.Handley@cs.ucl.ac.uk 1900 David Mazieres 1901 Stanford University 1902 Department of Computer Science 1903 353 Serra Mall, Room 290 1904 Stanford, CA 94305 1905 US 1907 Phone: +1 415 490 9451 1908 Email: dm@uun.org 1910 Quinn Slack 1911 Stanford University 1912 Department of Computer Science 1913 353 Serra Mall, Room 288 1914 Stanford, CA 94305 1915 US 1917 Phone: +1 650 723 8777 1918 Email: sqs@cs.stanford.edu