idnits 2.17.1 draft-bittau-tcp-crypt-00.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 == Line 1587 has weird spacing: '...ckno_hi blah ...' == Line 1590 has weird spacing: '... ackno blah ...' == 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 (March 7, 2011) is 4798 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 1027 ** 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 (~~), 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: September 8, 2011 Stanford University 6 M. Handley 7 University College London 8 D. Mazieres 9 Q. Slack 10 Stanford University 11 March 7, 2011 13 Cryptographic protection of TCP Streams (tcpcrypt) 14 draft-bittau-tcp-crypt-00.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 September 8, 2011. 55 Copyright Notice 57 Copyright (c) 2011 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 . . . . . . . . . . . . . . . 35 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 39 125 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 126 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 127 Appendix A. Protocol constant values . . . . . . . . . . . . . . 40 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 if security 215 of the DISABLED state would not be adequate. 217 3.1.2. The ENCRYPTING state 219 When the setup phase succeeds, tcpcrypt enters the ENCRYPTING state. 220 Once in this state, applications may read and write data with the 221 expected semantics of TCP connections. 223 In the ENCRYPTING state, a host MUST encrypt the Data portion of all 224 TCP segments transmitted and MUST include a Message Authentication 225 Code (MAC) in all segments transmitted. A host MUST furthermore 226 ignore any TCP segments received without the RST bit set, unless 227 those segments also contain a valid MAC. 229 A host MAY ignore RST segments without valid MACs. However, 230 operating systems SHOULD allow applications to control the dropping 231 of unMACed RST segments on a per-connection basis through an option 232 called TCP_CRYPT_RSTCHK option. Operating systems SHOULD furthermore 233 disable TCP_CRYPT_RSTCHK by default. 235 Once in the ENCRYPTING state, an endpoint MUST NOT directly or 236 indirectly transition to the DISABLED state under any circumstances. 238 3.1.3. The DISABLED state 240 When setup fails, tcpcrypt enters the DISABLED state. In this case, 241 the host MUST continue just as TCP would without tcpcrypt, unless 242 network conditions would cause a plain TCP connection to fail as 243 well. Entering the DISABLED state prohibits the endpoint from ever 244 entering the ENCRYPTING state. 246 An implementation MUST behave identically to ordinary TCP in the 247 DISABLED state, except that the first segment transmitted after 248 entering the DISABLED state MAY include a TCP CRYPT option with a 249 DECLINE suboption (and optionally other suboptions such as UNKNOWN) 250 to indicate that tcpcrypt is supported but not enabled. 251 Section 4.3.2 describes how this is done. 253 Operating systems MUST allow applications to turn off tcpcrypt by 254 setting the state to DISABLED before opening a connection. An active 255 opener with tcpcrypt disabled MUST behave identically to an 256 implementation of TCP without tcpcrypt. A passive opener with 257 tcpcrypt disabled MUST also behave like normal TCP, except that it 258 MAY optionally respond to SYN segments containing a CRYPT option with 259 SYN-ACK segments containing a DECLINE suboption, so as to indicate 260 that tcpcrypt is supported but not enabled. 262 3.2. Cryptographic algorithms 264 The setup phase employs two types of cryptographic algorithm: 266 o A _public key cipher_ is used with an ephemeral public key to 267 exchange a random, shared secret. We use the notation 268 ENC (K, VALUE) to denote an encryption of VALUE with public key K. 270 o A _collision-resistant pseudo-random function (CPRF)_ family is 271 used to generate multiple cryptographic keys from a smaller shared 272 secret. We use the notation CPRF (K, MESSAGE) to designate the 273 output of the pseudo-random function identified by key K on 274 MESSAGE. 276 Because public key ciphers and CPRFs often both make use of 277 cryptographic hashes, it generally makes sense to have both 278 algorithms based on the same hash function--for instance to pair the 279 OAEP+-RSA [RFC2437] cipher using a SHA-256-based mask-generation 280 function with the HMAC-SHA256 [RFC2104] CPRF. For this reason, the 281 public key cipher and CPRF are negotiated as a pair. 283 The encrypting phase employs two more types of algorithm: 285 o A _symmetric encryption algorithm_ is applied to all application 286 data. The algorithm specifier includes both an underlying cipher 287 (such as AES), and a mode of operation (such as CTR mode with TCP 288 sequence numbers as the counter). 290 o A Message Authentication Code or _MAC_ is used to protect the 291 contents of all TCP segments sent and received in the encrypting 292 phase. The currently specified MACs handle data in a structured 293 way so as to optimize authentication of TCP's Acknowledgment 294 Number field in re-transmissions. 296 Note that public key generation, public key encryption, and shared 297 secret generation all require randomness. Other tcpcrypt functions 298 may also require randomness depending on the algorithms and modes of 299 operation selected. A weak pseudo-random generator at either host 300 will defeat tcpcrypt's security. Thus, any host implementing 301 tcpcrypt MUST have a cryptographically secure source of randomness or 302 pseudo-randomness. 304 3.3. "C" and "S" roles 306 To establish shared session keys, tcpcrypt requires one host to 307 encrypt a secret value with the second host's public key. The second 308 host must subsequently use its private key to decrypt this value. 309 Thus, tcpcrypt's setup phase is asymmetric; the two hosts must play 310 different roles. We use "S" to denote the host that encrypts with 311 the other host's public key, and "C" to denote the host that decrypts 312 using its own private key. 314 Which role a host plays can have performance implications, because 315 for some public key algorithms encryption is much faster than 316 decryption. For instance, on a machine at the time of writing, 317 encryption with a 2,048-bit RSA-3 key costs 82 microseconds, while 318 decryption costs 10 milliseconds. 320 Because servers often need to establish connections at a faster rate 321 than clients, and because servers are often passive openers, by 322 default the passive opener plays the "S" role. However, operating 323 systems MUST provide a mechanism for the passive opener to reverse 324 roles and play the "C" role, as discussed in Section 4.2. 326 3.4. Key exchange protocol 328 Every machine C has a short-lived public encryption key, K_C, which 329 gets refreshed periodically and SHOULD NOT ever be written to 330 persistent storage. 332 When a host C connects to S, the two engage in the following 333 protocol: 335 C -> S: HELLO 336 S -> C: PKCONF, pub-cipher-list 337 C -> S: INIT1, sym-cipher-list, N_C, K_C 338 S -> C: INIT2, sym-cipher, ENC (K_C, N_S) 340 Here the pub-cipher-list is a list of public key ciphers and key 341 lengths acceptable to the server. Sym-cipher-list specifies the 342 symmetric cipher suites acceptable to the client. N_C is a nonce 343 chosen at random by C, while K_C is C's public encryption key, which 344 MUST match one of the entries in pub-cipher-list. sym-cipher is the 345 symmetric cipher suite chosen by the server from sym-cipher-list. 346 Finally N_S is a "pre-session seed" chosen at random by S. 348 The two sides then compute a series of "session secrets" and 349 corresponding Session IDs as follows: 351 param := { pub-cipher-list, sym-cipher-list, sym-cipher } 353 ss[0] := CPRF (N_S, { K_C, param, N_C }) 354 ss[i] := CPRF (ss[i-1], TAG_NEXTK) 356 SID[i] := CPRF (ss[i], TAG_SESSID) 358 The value ss[0] is used to generate all key material for the current 359 connection. SID[0] is the session ID for the current connection, and 360 will with overwhelming probability be unique for each individual TCP 361 connection. The most computationally expensive part of the key 362 exchange protocol is the public key cipher. The values of ss[i] for 363 i > 0 can be used to avoid public key cryptography when establishing 364 subsequent connections between the same two hosts, as described in 365 Section 3.6. 367 Given a session secret, ss, the two sides compute a series of master 368 keys as follows: 370 mk[0] := CPRF (ss, TAG_REKEY) 371 mk[i] := CPRF (mk[i-1], TAG_REKEY) 373 Finally, each master key mk is used to generate four symmetric 374 encryption keys: 376 kec := CPRF (mk, TAG_KEY_C_ENC || 1) || CPRF (mk, TAG_KEY_C_ENC || 2) 377 kac := CPRF (mk, TAG_KEY_C_MAC || 1) || CPRF (mk, TAG_KEY_C_MAC || 2) 378 kes := CPRF (mk, TAG_KEY_S_ENC || 1) || CPRF (mk, TAG_KEY_S_ENC || 2) 379 kas := CPRF (mk, TAG_KEY_S_MAC || 1) || CPRF (mk, TAG_KEY_S_MAC || 2) 381 The numbers 1 and 2 are each 1-byte byte long. 383 kec is used by the host in the "C" role to encrypt Data in 384 transmitted TCP segments. If the symmetric encryption algorithm 385 requires shorter keys, the key is truncated, keeping the left-most 386 bytes only. Thus, if the symmetric cipher key length is less than or 387 equal to the CPRF output length, a host need not compute 388 CPRF (mk, TAG_KEY_C_ENC || 2). 390 kac is used by the host in the "C" role to compute MACs on 391 transmitted segments, as described in Section 4.4. The key is 392 truncated similarly to kec if the MAC requires a shorter key length. 393 If the symmetric cipher is used in a mode that provides 394 authentication as well as secrecy, kac need not be used. 396 kes and kas are used analogously to kec and kac for segments 397 transmitted by the host in the "S" role. 399 3.5. Re-keying 401 We refer to the four encryption keys (kec, kac, kes, kas) as a _key 402 set_. We refer to the key set generated by mk[i] as the key set with 403 _generation number_ i within a session. Initially, the two hosts use 404 the key set with generation number 0. 406 Either host may decide to evolve the encryption key at one or more 407 points within a session, by incrementing the generation number of its 408 transmit keys. When switching keys to generation j, a host must 409 label the segments it transmits with a REKEY option containing j, so 410 that the recipient host knows to check the MAC and decrypt the 411 segment using the new keyset: 413 A -> B: REKEY, MAC<...>, Data<...> 415 Upon receiving a REKEY segment, a recipient using transmit keys 416 from a generation less than j must also update its transmit keys and 417 start including a REKEY option in all of its segments. A host 418 must continue transmitting REKEY options until all segments with 419 other generation numbers have been processed at both ends. 421 Implementations MUST always transmit and retransmit identical 422 ciphertext Data bytes for the same TCP sequence numbers. Thus, a 423 retransmitted segment MUST always use the same keyset as the original 424 segment. If the encryption algorithm requires an initialization 425 vector, a retransmitted segment MUST additionally use the same 426 initialization vector as the original segment. Hosts MUST NOT 427 combine segments that were encrypted with different keysets or 428 incompatible initialization vectors. 430 Implementations SHOULD delete older-generation keys from memory once 431 they have received all segments they will need to decrypt with the 432 old keys and received acknowledgments for all segments they might 433 need to retransmit. 435 3.6. Session caching 437 When two hosts have already negotiated session secret ss[i-1], they 438 can establish a new connection without public key operations using 439 ss[i]. The four-message protocol of Section 3.4 is replaced by: 441 A -> B: NEXTK1, SID[i] 442 B -> A: NEXTK2 444 Which symmetric keys a host uses for transmitted segments is 445 determined by its role in the original session ss[0]. It does not 446 depend on which host is the passive opener in the current session. 447 If A had the "C" role in the first session, then A uses kec and kac 448 for sending segments. Otherwise, if A had the "S" role originally, 449 it uses kes and kas in the new session. B similarly uses the 450 transmit keys that correspond to its role in the original session. 452 After using ss[i] to compute mk[0], implementations SHOULD compute 453 and cache ss[i+1] for possible use by a later session, then erase 454 ss[i] from memory. Hosts SHOULD keep ss[i+1] around for a period of 455 time until it is used or the memory needs to be reclaimed. Hosts 456 SHOULD NOT write a cached ss[i+1] value to non-volatile storage. 458 It is an implementation-specific issue as to how long ss[i+1] should 459 be retained if it is unused. If the passive opener times it out 460 before the active opener does, the only cost is the additional twelve 461 bytes to send NEXTK1 for the next connection. The behavior then 462 falls back to a normal public-key handshake. 464 3.6.1. Session caching control 466 Implementations MUST allow applications to control session caching by 467 setting the following option: 469 TCP_CRYPT_CACHE_FLUSH When set on a TCP endpoint that is in the 470 ENCRYPTING state, this option causes the operating system to flush 471 from memory the cached ss[i+1] (or ss[i+1+n] if other connections 472 have already been established). When set on an endpoint that is 473 in the setup phase, causes any cached ss[i] that would have been 474 used to be flushed from memory. In either case, future 475 connections will have to undertake another round of the public key 476 protocol in Section 3.4. Applications SHOULD set 477 TCP_CRYPT_CACHE_FLUSH whenever authentication of the session ID 478 fails. 480 4. Extensions to TCP 482 The tcpcrypt extension adds two new kinds of option: CRYPT, and MAC. 483 Both are described in this section. During the setup phase, all TCP 484 segments MUST have the CRYPT option. In the ENCRYPTING state, all 485 segments MUST have the MAC option and may include the CRYPT option 486 for various purposes such as re-keying or keep-alive probes. 488 The idealized protocol of the previous section must be embedded in 489 the TCP handshake. Unfortunately, since the maximum TCP header size 490 is 60 bytes and the basic TCP header fields require 20 bytes, there 491 are at most 40 option payload bytes available, which is not enough to 492 hold the INIT1 and INIT2 messages. Tcpcrypt therefore uses the Data 493 portion of TCP segments to send the body of these messages. 495 Operating systems MUST keep track of which phase a data segment 496 belongs to, and MUST only deliver data to applications from segments 497 that are processed in the ENCRYPTING or DISABLED states. 499 4.1. Protocol states 501 The setup phase is divided into six states: CLOSED, NEXTK-SENT, 502 HELLO-SENT, C-MODE, LISTEN, and S-MODE. Together with the ENCRYPTING 503 and DISABLED states already discussed, this means a tcpcrypt endpoint 504 can be in one of eight states. 506 In addition to tcpcrypt's state, each endpoint will also be in one of 507 the 11 TCP states described in the TCP protocol specification 509 [RFC0793]. Not all pairs of states are valid. Table 1 shows which 510 TCP states an endpoint can be in for each tcpcrypt state. 512 +-------------+--------------------------+--------------------------+ 513 | Tcpcrypt | TCP states for an active | TCP states for a passive | 514 | state | opener | opener | 515 +-------------+--------------------------+--------------------------+ 516 | CLOSED | CLOSED | CLOSED | 517 | NEXTK-SENT | SYN-SENT | n/a | 518 | HELLO-SENT | SYN-SENT | SYN-RCVD | 519 | C-MODE | ESTABLISHED, FIN-WAIT-1 | ESTABLISHED, FIN-WAIT-1 | 520 | LISTEN | n/a | LISTEN | 521 | S-MODE | (SYN-RCVD), ESTABLISHED | SYN-RCVD | 522 | ENCRYPTING | (SYN-RCVD), ESTABLISHED+ | SYN-RCVD, ESTABLISHED+ | 523 | DISABLED | any | any | 524 +-------------+--------------------------+--------------------------+ 526 Valid tcpcrypt and TCP state combinations. States in parentheses 527 occur only with simultaneous open. ESTABLISHED+ means ESTABLISHED or 528 any later state (FIN-WAIT-1, FIN-WAIT-2, CLOSING, TIME-WAIT, CLOSE- 529 WAIT, or LAST-ACK). 531 Table 1 533 Figure 1 shows how tcpcrypt transitions between states. Each 534 transition is labeled by events that may trigger the transition above 535 the line, and an action the local host is permitted to take in 536 response below the line. "rcv" and "snd" denote sending and receiving 537 segments, respectively. "any" means any possible event. "internal" 538 means any possible event except for receiving a segment (i.e., timers 539 and system calls). "drop" means discarding the last received segment 540 and preventing it from having any effect on TCP's state. "mac" means 541 any valid TCP action, including no action, except that any segments 542 transmitted must be encrypted and contain a valid TCP MAC option. "x" 543 indicates that a host sends no segments when taking a transition. 545 A segment is described as "F/Op". F specifies constraints on the 546 control bits of the TCP header, as follows: 548 +----+------------------------------+ 549 | F | Meaning | 550 +----+------------------------------+ 551 | S | SYN=1, ACK=0, FIN=0, RST=0 | 552 | SA | SYN=1, ACK=1, FIN=0, RST=0 | 553 | A | SYN=0, ACK=1, FIN=0, RST=0 | 554 | S? | SYN=1, ACK=any, FIN=0, RST=0 | 555 | ?A | SYN=any, ACK=1, FIN=0, RST=0 | 556 | R | RST=1 | 557 | * | any | 558 +----+------------------------------+ 560 Op designates message types in the abstract protocol, which also 561 correspond to particular suboptions of the TCP CRYPT option, 562 described in Section 4.3, or "MAC" for a valid TCP MAC option, as 563 described in Section 4.4. A segment with SYN=1 and ACK=0 that 564 contains the NEXTK1 suboption will also explicitly or implicitly 565 contain the HELLO suboption; such a segment matches event constraints 566 on either option--e.g., it matches any of the "rcv S/HELLO", "rcv 567 S?/HELLO", and "rcv S/NEXTK1" events. An empty Op matches any 568 segment with the appropriate control bits. A segment MUST contain 569 the TCP MAC option if and only if Op is "MAC". 571 The "drop" transitions from NEXTK-SENT and HELLO-SENT to HELLO-SENT 572 change TCP slightly by ignoring a segment and preventing a TCP 573 transition from SYN-SENT to SYN-RCVD that would otherwise occur 574 during simultaneous open. Therefore, these transitions SHOULD be 575 disabled by default. They MAY be enabled on one side by an 576 application that wishes to enable tcpcrypt on simultaneous open, as 577 discussed in Section 4.2.1. 579 active OPEN passive OPEN 580 ------------ +----------+ ------------ +----------+ 581 snd S/NEXTK1 | CLOSED | x | LISTEN | 582 +-------------------| |------------->| |---------+ 583 | +----------+ +----------+ | 584 | +---+ |active OPEN | | | 585 | rcv S/HELLO| | |----------- rcv S/HELLO| | rcv S/NEXTK1| 586 | -----------| | |snd S/HELLO ------------| | -------------| 587 V drop| V V snd SA/HELLO| | snd SA/NEXTK2| 588 +----------+ | +----------+ | | | 589 | NEXTK- |___/ \| HELLO- |<------------------+ | | 590 | SENT | | SENT | |rcv S/HELLO | 591 +----------+ +----------+ |------------- | 592 | | | | |rcv S?/HELLO |snd SA/PKCONF | 593 | | |rcv S?/HELLO | |------------- V | 594 | | |------------- | |snd ?A/PKCONF +----------+ | 595 | | |snd ?A/PKCONF | +---------------->| S-MODE | | 596 | | +----------------|------------------>| | | 597 | +----------------+ | +----------+ | 598 | rcv SA/PKCONF| |rcv ?A/PKCONF | | 599 | -------------| |------------- |rcv A/INIT1 | 600 | snd A/INIT1| |snd A/INIT1 |----------- | 601 | V V |snd A/INIT2 | 602 | +----------+ | | 603 |rcv SA/NEXTK2 | C-MODE | +---+ | +---+ | 604 |------------- | | rcv */ | | | | |internal | 605 |snd A/MAC +----------+ -------| | | | |or rcv */MAC | 606 | == or == |rcv A/INIT2 drop| | | | |or rcv R/ | 607 |rcv S/NEXTK1 |----------- | V V V |------------ | 608 |------------ |x +----------+ |mac | 609 |snd SA/NEXTK2 +------------------>|ENCRYPTING|-+ | 610 +------------------------------------->| |<---------------+ 611 +----------+ 613 State diagram for tcpcrypt. Transitions to DISABLED and CLOSED are 614 not shown. 616 Figure 1 618 Any segment that would be discarded by TCP (e.g., for being out of 619 window) MUST also be ignored by tcpcrypt. However, certain segments 620 that might otherwise be accepted by TCP MUST be dropped by tcpcrypt 621 and prevented from affecting TCP's state. 623 Except for these drop actions, tcpcrypt MUST abide by the TCP 624 protocol specification [RFC0793]. Thus, any segment transmitted by a 625 host MUST be permitted by the TCP specification in addition to 626 matching either a transition in Figure 1 or one of the transitions to 627 DISABLED or CLOSED described below. In particular, a host MUST NOT 628 acknowledge an INIT1 segment unless either the acknowledgment 629 contains an INIT2 or the host transitions to DISABLED. 631 Various events cause transitions to DISABLED from states other than 632 ENCRYPTING. In particular: 634 o Operating systems MUST provide a mechanism for applications to 635 transition to DISABLED from the CLOSED and LISTEN states. 637 o A host in the setup phase MUST transition to DISABLED upon 638 receiving any segment without a TCP CRYPT option. 640 o A host in the setup phase MUST transition to DISABLED upon 641 receiving any segment with the FIN or RST control bit set. 643 o A host in the setup phase MUST transition to DISABLED upon sending 644 a segment with the FIN bit set. (As discussed below, however, a 645 host MUST NOT send a FIN segment from the C-MODE state.) 647 Other specific conditions cause a transition to DISABLED and are 648 discussed in the sections that follow. 650 CLOSED is a pseudo-state representing a connection that does not 651 exist. A tcpcrypt connection's lifetime is identical to that of its 652 associated TCP connection. Thus, tcpcrypt transitions to CLOSED 653 exactly when TCP transitions to CLOSED. 655 A host MUST NOT send a FIN segment from the C-MODE state. The reason 656 is that the remote side can be in the ENCRYPTING state and would thus 657 require the segment to contain a valid MAC, yet a host in C-MODE 658 cannot compute the necessary encryption keys before receiving the 659 INIT2 segment. 661 If a CLOSE happens in C-MODE, a host MUST delay sending a FIN segment 662 until receiving an ACK for its INIT1 segment. If the remote host is 663 in ENCRYPTING, the ACK segment will contain INIT2 and the local host 664 can transition to ENCRYPTING before sending the FIN. If the remote 665 host is not in ENCRYPTING, the ACK will not contain INIT2, and thus 666 the local host can transition to DISABLED before sending the FIN. 668 If a CLOSE happens in C-MODE, an implementation MAY delay processing 669 the CLOSE event and entering the TCP FIN-WAIT-1 state until sending 670 the FIN. If it does not, the implementation MUST ensure all relevant 671 timers correspond to the time of transmission of the FIN segment, not 672 the time of entry into the FIN-WAIT-1 state. 674 A CLOSE event in the ENCRYPTING state MUST NOT change tcpcrypt's 675 state, only TCP's. The only valid tcpcrypt state transition from 676 ENCRYPTING is to CLOSED, which occurs only when TCP also transitions 677 to CLOSED. 679 4.2. Role negotiation 681 A passive opener receiving an S/HELLO segment may choose to play the 682 "S" role (by transitioning to S-MODE) or the "C" role (by 683 transitioning to HELLO-SENT). An active opener may accept the role 684 not chosen by the passive opener, or may instead disable tcpcrypt. 685 During simultaneous open, one endpoint must choose the "C" role while 686 the other chooses the "S" role. Operating systems MUST allow 687 applications to guide these choices on a per-connection basis. 689 Applications SHOULD be able to exert this control by setting a per- 690 connection _CMODE disposition_, which can take on one of the 691 following five values: 693 TCP_CRYPT_CMODE_DEFAULT This disposition SHOULD be the default. A 694 passive opener will only play the "S" role, but an active opener 695 can play either the "C" or the "S" role. Simultaneous open 696 without session caching will cause tcpcrypt to be disabled unless 697 the remote host has set the TCP_CMODE_ALWAYS[_NK] disposition. 699 TCP_CRYPT_CMODE_ALWAYS 701 TCP_CRYPT_CMODE_ALWAYS_NK With this disposition, a host will only 702 play the "C" role. The _NK version additionally prevents the use 703 of session caching if the session was originally established in 704 the "S" role. 706 TCP_CRYPT_CMODE_NEVER 708 TCP_CRYPT_CMODE_NEVER_NK With this disposition, a host will only 709 play the "S" role. The _NK version additionally prevents the use 710 of session caching if the session was originally established in 711 the "C" role. 713 The CMODE disposition prohibits certain state transitions, as 714 summarized in Table 2. If an event occurs for which all valid 715 transitions in Figure 1 are prohibited, a host MUST transition to 716 DISABLED. Operating systems MAY add additional CMODE dispositions, 717 for instance to force or prohibit session caching. 719 +-----------------------------+---------------------------+ 720 | CMODE disposition | Prohibited transitions | 721 +-----------------------------+---------------------------+ 722 | TCP_CRYPT_CMODE_DEFAULT | LISTEN --> HELLO-SENT | 723 | | HELLO-SENT --> HELLO-SENT | 724 | | NEXTK-SENT --> HELLO-SENT | 725 | | | 726 | TCP_CRYPT_CMODE_ALWAYS[_NK] | any --> S-MODE | 727 | | | 728 | TCP_CRYPT_CMODE_NEVER[_NK] | LISTEN --> HELLO-SENT | 729 | | HELLO-SENT --> HELLO-SENT | 730 | | NEXTK-SENT --> HELLO-SENT | 731 | | any --> C-MODE | 732 +-----------------------------+---------------------------+ 734 State transitions prohibited by each CMODE disposition 736 Table 2 738 4.2.1. Simultaneous open 740 During simultaneous open, two ends of a TCP connection are both 741 active openers. If both hosts attempt to use session caching by 742 simultaneously transmitting S/NEXTK1 segments, and if both transmit 743 the same session ID, then both may reply with SA/NEXTK2 segments and 744 immediately enter the ENCRYPTING state. In this case, the host that 745 played "C" when the session was initially negotiated MUST use the 746 symmetric encryption keys for "C" (i.e., use kec and kac for 747 transmitted segments), while the host that initially played "S" uses 748 the "S" keys for the new connection. 750 If both hosts in a simultaneous open do not attempt to use session 751 caching, or if the two hosts use incompatible Session IDs, then they 752 MUST engage in public-key-based key negotiation to use tcpcrypt. 753 Doing so requires one host to play the "C" role and the other to play 754 the "S" role. With the TCP_CRYPT_CMODE_DEFAULT disposition, these 755 roles are usually determined by the passive opener choosing the "S" 756 role. With no passive opener, both active openers will end up in 757 S-MODE, then transition to DISABLED upon receiving an unexpected 758 PKCONF. 760 Simultaneous open can work with key negotiation if exactly one of the 761 two hosts selects the TCP_CRYPT_CMODE_ALWAYS disposition. This host 762 will then drop S/HELLO segments and remain in C-MODE while the other 763 host transitions to S-MODE. Applications SHOULD NOT set 764 TCP_CRYPT_CMODE_ALWAYS on both sides of a simultaneous open, as this 765 will cause even the underlying TCP connection to fail. 767 4.3. The TCP CRYPT option 769 A CRYPT option has the following format: 771 Byte 0 1 2 N 772 +-------+-------+-------...-------+ 773 | Kind= |Length=| Suboptions | 774 | OPT1 | N | | 775 +-------+-------+-------...-------+ 777 Format of TCP CRYPT option 779 Kind is always OPT1. Length is the total length of the option, 780 including the two bytes used for Kind and Length. These first two 781 bytes are then followed by zero or more suboptions. Suboptions 782 determine the meaning of the TCP CRYPT option. When a TCP header 783 contains more than one CRYPT option, a host MUST interpret them the 784 same as if all the suboptions appeared in a single CRYPT option. 786 Each suboption begins with an Opcode byte. The specific format of 787 the option depends on the two most significant bits of the Opcode. 789 Suboptions with opcodes from 0x00 to 0x3f contain no data other than 790 the single opcode byte: 792 bit 0 1 2 3 4 5 6 7 793 +-+-+-+-+-+-+-+-+ 794 | Opcode = | 795 |0 0 x x x x x x| 796 +-+-+-+-+-+-+-+-+ 798 Hosts MUST ignore any opcodes of this format that they do not 799 recognize. 801 Suboptions with opcodes from 0x40 to 0x7f contain an opcode, a length 802 field, and data bytes. 804 0 1 805 bit 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------... 807 | Opcode = | Length = | N-2 bytes 808 |0 1 x x x x x x| N | of suboption data 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------... 811 Hosts MUST ignore any opcodes of this format that they do not 812 recognize. 814 Suboptions with opcodes from 0x80 to 0xbf contain zero or more bytes 815 of data whose length depends on the opcode. These suboptions can be 816 either fixed length or variable length; implementations that 817 understand these opcodes will known which they are; if the suboption 818 is fixed length the implementation will know the length; otherwise it 819 will know where to look for the length field. 821 bit 0 1 2 3 4 5 6 7 822 +-+-+-+-+-+-+-+-+-------... 823 | Opcode = | data 824 |1 0 x x x x x x| 825 +-+-+-+-+-+-+-+-+-------... 827 If a host sees an unknown opcode in this range, it MUST ignore the 828 suboption and all subsequent suboptions in the same TCP CRYPT option. 829 However, if more than one CRYPT option appears in the TCP header, the 830 host MUST continue processing suboptions from the next TCP CRYPT 831 option. 833 Suboptions with opcodes from 0xc0 to 0xff also contain an opcode- 834 specific length of data. As before, these suboptions can be either 835 fixed length or variable length. However, suboptions in this range 836 are classed as mandatory as far as the protocol is concerned. 837 However, they are not MANDATORY to implement unless otherwise stated, 838 as discussed below. 840 bit 0 1 2 3 4 5 6 7 841 +-+-+-+-+-+-+-+-+-------... 842 | Opcode = | data 843 |1 1 x x x x x x| 844 +-+-+-+-+-+-+-+-+-------... 846 Should a host encounter an unknown opcode greater than or equal to 847 0xc0 during the setup phase of the protocol, the host MUST transition 848 to the DISABLED state. It SHOULD respond with both a DECLINE 849 suboption and an UNKNOWN suboption specifying the opcode of the 850 unknown mandatory suboption, after which the host MUST NOT send any 851 further CRYPT options. 853 Should a host encounter an unknown opcode greater than or equal to 854 0xc0 while in the ENCRYPTING state, the host MUST respond with an 855 UNKNOWN suboption specifying the opcode of the unknown mandatory 856 suboption, and should ensure the session continues with the same 857 encryption and authentication state as it had before the segment was 858 received. This may require ignoring other suboptions within the same 859 message, or reverting any half-negotiated state. 861 Table 3 summarizes the opcodes discussed in this document. It is 862 MANDATORY that all implementations support every opcode in this 863 table. Each opcode is listed with the length in bytes of the 864 suboption (including the opcode byte), or * for variable-length 865 suboptions. The last column specifies in which of the (S)etup phase, 866 (E)NCRYPTING state, and (D)ISABLED state an opcode may be used. A 867 host MUST NOT send an option unless it is in one of the stages 868 indicated by this column. 870 +-------+--------+---------------------+--------+ 871 | Value | Length | Name | Stages | 872 +-------+--------+---------------------+--------+ 873 | 0x01 | 1 | HELLO | S | 874 | 0x02 | 1 | HELLO-app-support | S | 875 | 0x03 | 1 | HELLO-app-mandatory | S | 876 | 0x04 | 1 | DECLINE | SD | 877 | 0x05 | 1 | NEXTK2 | S | 878 | 0x06 | 1 | INIT1 | S | 879 | 0x07 | 1 | INIT2 | S | 880 | 0x41 | * | PKCONF | S | 881 | 0x42 | * | PKCONF-app-support | S | 882 | 0x43 | * | UNKNOWN | SED | 883 | 0x44 | * | SYNCOOKIE | S | 884 | 0x45 | * | ACKCOOKIE | SED | 885 | 0x80 | 5 | SYNC_REQ | E | 886 | 0x81 | 5 | SYNC_OK | E | 887 | 0x82 | 2 | REKEY | E | 888 | 0x83 | 6 | REKEYSTREAM | E | 889 | 0x84 | 10 | NEXTK1 | S | 890 | 0x85 | * | IV | E | 891 +-------+--------+---------------------+--------+ 893 Opcodes for suboptions of the TCP CRYPT option. 895 Table 3 897 If a TCP segment (sent by an active opener) has the SYN flag set, the 898 ACK flag clear, and one or more TCP CRYPT options, there is an 899 implicit HELLO suboption even if that suboption does not appear in 900 the segment. In particular, when such a SYN segment contains a 901 single, empty, two-byte TCP CRYPT option, the passive opener MUST 902 interpret that option as equivalent to the three-byte TCP option 903 composed of bytes OPT1, 3, 1 (Kind = OPT1, Length = 3, Suboption = 904 HELLO). 906 A host MUST enter the DISABLED state if, during the setup phase, it 907 receives a segment containing neither a TCP CRYPT nor a TCP MAC 908 option. A host MUST also enter DISABLED if, during the setup phase, 909 it receives a DECLINE suboption or any unrecognized suboption with 910 opcode greater than or equal to 0xc0. Once a host has entered 911 DISABLED, it MUST NOT include the MAC option in any transmitted 912 segment. The host MAY include a CRYPT option in the next segment 913 transmitted, but only if the segment also contains the DECLINE 914 suboption. All subsequently transmitted packets MUST NOT contain the 915 CRYPT option. 917 4.3.1. The HELLO suboption 919 The HELLO dataless suboption MUST only appear in a segment with the 920 SYN control bit set. It is used by an active opener to indicate 921 interest in using tcpcrypt for a connection, and by a passive opener 922 to indicate that the passive opener wishes to play the "C" role. 924 The initial SYN segment from an active opener wishing to use tcpcrypt 925 MUST contain a TCP CRYPT option with either an explicit or an 926 implicit HELLO suboption. 928 After receiving a SYN segment with the HELLO suboption, a passive 929 opener MUST respond in one of three ways: 931 o To continue setting up tcpcrypt and play the "S" role, the passive 932 opener MUST respond with a PKCONF suboption in the SYN-ACK segment 933 and transition to S-MODE. 935 o To continue setting up tcpcrypt and play the "C" role, the passive 936 opener MUST respond with a HELLO suboption in the SYN-ACK segment 937 and transition to HELLO-SENT. 939 o To continue without tcpcrypt, the passive opener MUST respond with 940 either no CRYPT option or the DECLINE suboption in the SYN-ACK 941 segment, then transition to the DISABLED state. 943 An active opener receiving HELLO in a SYN-ACK segment must either 944 transition to S-MODE and respond with a PKCONF suboption, or 945 transition to DISABLED. 947 There are three variants of the HELLO option used for application- 948 level authentication: a plain HELLO where the application is not 949 tcpcrypt-aware (but the kernel is), an "application supported" HELLO 950 where the application is tcpcrypt-aware and is advertising the fact, 951 and a "application mandatory" HELLO where the application requires 952 the remote application to support tcpcrypt otherwise the connection 953 MUST revert to plain TCP. The application supported HELLO can be 954 used, for example, when implementing HTTP digest authentication - an 955 application can check whether the peer's application is tcpcrypt 956 aware and proceed to authenticate tcpcrypt's session ID over HTTP, 957 otherwise reverting to standard HTTP digest authentication. The 958 application mandatory HELLO can be used, for example, when 959 implementing an SSL library that attempts tcpcrypt but reverts to SSL 960 if the peer's SSL library does not support tcpcrypt. The application 961 mandatory HELLO avoids double encrypting (SSL-over-tcpcrypt) since 962 the connection will revert to plain TCP if the remote SSL library is 963 not tcpcrypt-ware. 965 4.3.2. The DECLINE suboption 967 The DECLINE dataless suboption is sent by a host to indicate that the 968 host will not enable tcpcrypt on a connection. If a host is in the 969 DISABLED state or transitioning to the DISABLED state, and the host 970 transmits a segment containing a CRYPT option, then the segment MUST 971 contain the DECLINE suboption. 973 A passive opener SHOULD send a DECLINE suboption in response to a 974 HELLO suboption or NEXTK1 suboption in a received SYN segment if it 975 supports tcpcrypt but does not wish to engage in encryption for this 976 particular session. 978 Implementations MUST NOT send segments containing the DECLINE 979 suboption from the C-MODE or ENCRYPTING states. 981 4.3.3. The NEXTK1 and NEXTK2 suboptions 983 The NEXTK1 suboption MUST only appear in a segment with the SYN 984 control bit set and the ACK bit clear. It is used by the active 985 opener to initiate a TCP session without the overhead of public key 986 cryptography. The new session key is derived from a previously 987 negotiated session secret, as described in Section 3.6. 989 The suboption is always 10 bytes in length; the data contains the 990 first nine bytes of SID[i] and is used to to start the session with 991 session secret ss[i]. The format of the suboption is: 993 Byte 0 1 2 3 994 +-------+-------+-------+-------+ 995 0 |Opcode | Bytes 0-2 | 996 | 0x84 | of SID[i] | 997 +-------+-------+-------+-------+ 998 4 | Bytes 3-6 | 999 | of SID[i] | 1000 +-------+-------+-------+-------+ 1001 8 | Bytes 7-8 | 1002 | of SID[i] | 1003 +-------+-------+ 1005 Format of the NEXTK1 suboption 1007 The active opener MUST use the lowest value of i that has not already 1008 appeared in a NEXTK1 segment exchanged with the same host and for the 1009 same pre-session seed. 1011 If the passive opener recognizes SID[i] and knows ss[i], it SHOULD 1012 respond with a segment containing the dataless NEXTK2 suboption. The 1013 NEXTK2 option MUST only appear in a segment with both the SYN and ACK 1014 bits set. 1016 If the passive opener does not recognize SID[i], or SID[i] is not 1017 valid or has already been used, the passive opener SHOULD respond 1018 with a PKCONF or HELLO option and continue key negotiation as usual. 1020 When two hosts have previously negotiated a tcpcrypt session, either 1021 host may use the NEXTK1 option regardless of which host was the 1022 active opener or played the "C" role in the previous session. 1023 However, a given host must either use kec/kac for all sessions 1024 derived from the same pre-session seed, or kas/kes for all those 1025 sessions. Thus, which keys a host uses to send segments depends only 1026 whether the host played the "C" or "S" role in the initial session 1027 that used ss[0]; it is not affected by which host was the active 1028 opener transmitting the SYN segment containing a NEXTK1 suboption. 1030 A host MUST reject a NEXTK1 message if it has previously sent or 1031 received one with the same SID[i]. In the event that two hosts 1032 simultaneously send SYN segments to each other with the same SID[i], 1033 but the two segments are not part of a simultaneous open, both 1034 connections will have to revert to public key cryptography. To avoid 1035 this limitation, implementations MAY chose to implement session 1036 caching such that a given pre-session key is only good for either 1037 passive or active opens at the same host, not both. 1039 In the case of simultaneous open, two hosts that simultaneously send 1040 SYN packets with NEXTK1 and the same SID[i] may establish a 1041 connection, as described in Section 4.2.1. 1043 4.3.4. The PKCONF suboption 1045 The PKCONF option has the following format: 1047 Byte 0 1 2 N 1048 +-------+-------+-------...-------+ 1049 |Opcode=|Length=| Algorithm | 1050 | 0x41 | N | Specifiers | 1051 +-------+-------+-------...-------+ 1053 Format of the PKCONF suboption 1055 The suboption data, whose length (N-2) must be divisible by 3, 1056 contains one or more 3-byte algorithm specifiers of the following 1057 form: 1059 0 1 2 1060 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 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 |0| Algorithm | Min-Key-Len | Max-Key-Len | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 Format of algorithm specifier within PKCONF suboption 1067 The following values of algorithm are defined: 1069 +-------+---------------------------+-------------+ 1070 | Value | Cipher | CPRF | 1071 +-------+---------------------------+-------------+ 1072 | 0x01 | Rabin-Williams | HMAC-SHA256 | 1073 | 0x02 | OAEP+-RSA with exponent 3 | HMAC-SHA256 | 1074 +-------+---------------------------+-------------+ 1076 (Values of algorithm over 127 are reserved for future use by multi- 1077 byte algorithm specifiers for algorithms with fixed key sizes or more 1078 compact min/max key length encodings.) 1080 Hosts SHOULD implement Rabin-Williams, and MUST implement OAEP+-RSA3. 1081 The Min-Key-Len and Max-Key-Len fields specify the minimum and 1082 maximum key sizes acceptable for each particular algorithm. The 1083 interpretation of the values of these fields depends on the 1084 particular algorithm. For the two algorithms listed above, the two 1085 Len values are expressed in terms of 256-bit (32-byte) key blocks, so 1086 that, for example, the following algorithm specifier designates 1087 Rabin-Williams keys with lengths from 1,024 to 8,192 bits. 1089 0 1 2 1090 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 |0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|0 0 1 0 0 0 0 0| 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 Depending on the value of the PKCONF suboption, it can either 1096 indicate that the application is tcpcrypt-aware or not. This can be 1097 used for bootstrapping application-level authentication without 1098 requiring probing in upper layer protocols to check for support 1099 (which may not be possible). 1101 4.3.5. The UNKNOWN suboption 1103 The UNKNOWN option has the following format: 1105 Byte 0 1 2 N 1106 +-------+-------+-------........-------+ 1107 |Opcode=|Length=| N-2 unknown one-byte | 1108 | 0x42 | N | opcodes received | 1109 +-------+-------+-------........-------+ 1111 Format of the UNKNOWN suboption 1113 This suboption is sent in response to an unknown suboption that has 1114 been received. The contents of the option are a complete list of the 1115 mandatory suboption opcodes from the received packet that were not 1116 understood. Note that this option is only sent once, in the next 1117 packet that the host sends. This means that it is reliable when sent 1118 in a SYN-ACK, but unreliable otherwise. Any mechanism sending new 1119 mandatory attributes must take this into account. If multiple 1120 packets, each containing unknown options, are received before an 1121 UNKNOWN suboption can be sent, the options list MUST contain the 1122 union of the two sets. The order of the opcode list is not 1123 significant. 1125 If a host receives an unknown option, it SHOULD reply with the 1126 UNKNOWN suboption to notify the other side. If the host transitions 1127 to DISABLED as a result of the unknown option, then the host MUST 1128 also include the DECLINE suboption if it sends an UNKNOWN suboption 1129 (or more generally if it includes a CRYPT option in the next packet). 1131 As a special case, if PKCONF (0x41) or INIT1 (0x06) appears in the 1132 unknown opcode list, it does not mean the sender does not understand 1133 the option (since these options are MANDATORY). Instead, it means 1134 the sender does not implement any of the algorithms specified in the 1135 PKCONF or INIT1 message. In either case, the segment must also 1136 contain a DECLINE suboption. 1138 4.3.6. The SYNCOOKIE and ACKCOOKIE suboptions 1140 A passive opener MAY include the SYNCOOKIE suboption in a segment 1141 with both the SYN and ACK flags set. SYNCOOKIE allows a server to be 1142 stateless until the TCP handshake has completed. If has the 1143 following format: 1145 Byte 0 1 2 N 1146 +-------+-------+-------...-------+ 1147 |Opcode=|Length=| N-2 bytes of | 1148 | 0x43 | N | opaque data | 1149 +-------+-------+-------...-------+ 1151 Format of the SYNCOOKIE suboption 1153 The data is opaque as far as the protocol is concerned; it is 1154 entirely up to implementations how to make use of this suboption to 1155 hold state. It is OPTIONAL to send a SYNCOOKIE, but MANDATORY to 1156 understand and respond to them. 1158 The ACKCOOKIE suboption echoes the contents of a SYNCOOKIE; it MUST 1159 be sent in a packet acknowledging receipt of a packet containing a 1160 SYNCOOKIE, and MUST NOT be sent in any other packet. If has the 1161 following format: 1163 Byte 0 1 2 N 1164 +-------+-------+-------...-------+ 1165 |Opcode=|Length=| N-2 bytes of | 1166 | 0x44 | N | SYNCOOKIE data | 1167 +-------+-------+-------...-------+ 1169 Format of the ACKCOOKIE suboption 1171 Servers that rely on suboption data from ACKCOOKIE to reconstruct 1172 session state SHOULD embed a cryptographically strong message 1173 authentication code within the SYNCOOKIE data so as to be able to 1174 reject forged ACKCOOKIE suboptions. 1176 Though an implementation MUST NOT send a SYNCOOKIE in any context 1177 except the SYN-ACK packet returned by a passive opener, 1178 implementations SHOULD accept SYNCOOKIEs in other contexts and reply 1179 with the appropriate ACKCOOKIE if possible. 1181 4.3.7. The SYNC_REQ and SYNC_OK suboptions 1183 Many hosts implement TCP Keep-Alives [RFC1122] as an option for 1184 applications to ensure that the other end of a TCP connection still 1185 exists even when there is no data to be sent. A TCP Keep-Alive 1186 segment carries a sequence number one prior to the beginning of the 1187 send window, and may carry one byte of "garbage" data. Such a 1188 segment causes the remote side to send an acknowledgment. 1190 Unfortunately, Keep-Alive acknowledgments might not contain unique 1191 data. Hence, an old but cryptographically valid acknowledgment could 1192 be replayed by an attacker to prolong the existence of a session at 1193 one host after the other end of the connection no longer exists. 1194 (Such an attack might prevent a process with sensitive data from 1195 exiting, giving an attacker more time to compromise a host and 1196 extract the sensitive data.) 1198 The TCP Timestamps Option (TSopt) [RFC1323] could alternatively have 1199 been used to make Keep-Alives unique. However, because some 1200 middleboxes change the value of TSopt in packets, tcpcrypt does not 1201 protect the contents of the TCP TSopt option. Hence the SYNC_REQ and 1202 SYNC_OK suboptions allow the cryptographically protected TCP CRYPT 1203 option to contain unique data. 1205 The SYNC_REQ suboption is always 5 bytes, and has the following 1206 format: 1208 Byte 0 1 2 3 4 1209 +-------+-------+-------+-------+-------+ 1210 |Opcode=| Clock | 1211 | 0x80 | | 1212 +-------+-------+-------+-------+-------+ 1214 Format of the SYNC_REQ suboption 1216 Clock is a 32-bit non-decreasing value. A host MUST increment Clock 1217 at least once for every interval in which it sends a Keep-Alive. 1218 Implementations that support TSopt MAY chose to use the same value 1219 for Clock that they would put in the TSval field of the TCP TSopt. 1220 However, implementations SHOULD "fuzz" any system clocks used to 1221 avoid disclosing either when a host was last rebooted or at what rate 1222 the hardware clock drifts. 1224 A host that receives a SYNC_REQ suboption MUST reply with a SYNC_OK 1225 suboption, which is always five bytes and has the following format: 1227 Byte 0 1 2 3 4 1228 +-------+-------+-------+-------+-------+ 1229 |Opcode=| Received-Clock | 1230 | 0x81 | | 1231 +-------+-------+-------+-------+-------+ 1233 Format of the SYNC_OK suboption 1235 The value of Received-Clock depends on the values of the Clock fields 1236 in SYNC_REQ messages a host has received. A host must set Received- 1237 Clock to a value at least as high as the most recently received 1238 Clock, but no higher than the highest Clock value received this 1239 session. If a host delays acknowledgment of multiple packets with 1240 SYNC_REQ suboptions, it SHOULD send a single SYNC_OK with Received- 1241 Clock set to the highest Clock in the packets it is acknowledging. 1243 Because middleboxes sometimes "correct" inconsistent retransmissions, 1244 Keep-Alive segments with one byte of garbage data MUST use the same 1245 ciphertext byte as previously transmitted for that sequence number. 1246 Otherwise, a middlebox might change the byte back to its value in the 1247 original transmission, causing the cryptographic MAC to fail. 1249 4.3.8. The REKEY and REKEYSTREAM suboptions 1251 The REKEY and REKEYSTREAM suboptions are used to evolve encryption 1252 keys. Exactly one of the two options is valid with any given 1253 symmetric encryption algorithm and mode. Generally block ciphers 1254 will use REKEY while stream ciphers use REKEYSTREAM. We refer to a 1255 segment containing either option as a REKEY segment. 1257 REKEY allows hosts to wipe from memory keys that could decrypt 1258 previously transmitted segments. It also allows the use of message 1259 authentication codes that are only secure up to a fixed number of 1260 messages. However, implementations MUST work in the presence of 1261 middleboxes that "correct" inconsistent data retransmissions. Hence, 1262 the value of ciphertext bytes must be the same in the original 1263 transmission and all retransmissions of a particular sequence number. 1264 This means a host MUST always use the same encryption key when 1265 transmitting or retransmitting the same range of sequence numbers. 1266 Re-keying only affects data transmitted in the future. Moreover, 1267 segments encrypted with different keysets MUST NOT be combined in 1268 retransmissions. 1270 When switching keys, the REKEY suboption specifies which key set has 1271 been used to encrypt and integrity-protect the current segment. The 1272 suboption is always two bytes, and has the following format: 1274 Byte 0 1 1275 +-------+-------+ 1276 |Opcode=|KeyLSB | 1277 | 0x83 | | 1278 +-------+-------+ 1280 Format of the REKEY suboption 1282 KeyLSB is the generation number of the keys used to encrypt and MAC 1283 the current segment, modulo 256. REKEYSTREAM is the same as REKEY 1284 but includes the TCP Sequence Number at which the key change took 1285 effect, for cases in which decryption requires knowing how many bytes 1286 have been encrypted thus far with a key. 1288 Byte 0 1 2 3 4 5 1289 +-------+-------+-------+-------+-------+-------+ 1290 |Opcode=|KeyLSB | Sequence Number | 1291 | 0x83 | | | 1292 +-------+-------+-------+-------+-------+-------+ 1294 Format of the REKEYSTREAM suboption 1296 A host MAY use REKEY to increment the session key generation number 1297 beyond the highest generation it knows the other side to be using. 1298 We call this process _initiating_ re-keying. When one host initiates 1299 re-keying, the other host MUST increment its key generation number to 1300 match, as described blow (unless the other host has also 1301 simultaneously initiated re-keying). 1303 A host MAY initiate re-keying by including a REKEY suboption in a 1304 _syncable_ segment. A syncable segment is one that either contains 1305 data, or is acknowledgment-only but contains a SYNC_REQ suboption 1306 with a fresh Clock value--i.e., higher than any Clock value it has 1307 previously transmitted. We say a syncable segment is _synced_ when 1308 the transmitter knows the remote side has received it and all 1309 previous sequence numbers. A data segment is synced when the 1310 transmitter receives a cumulative acknowledgment for its sequence 1311 number (a Selective Acknowledgment [RFC2018] is insufficient). An 1312 acknowledgment-only segment is synced when the sender receives an 1313 acknowledgment for its sequence number and a SYNC_OK with a high 1314 enough Clock number. 1316 A host MUST NOT initiate re-keying with an acknowledgment-only 1317 segment that has either no SYNC_REQ suboption or a SYNC_REQ with an 1318 old Clock value, because such a segment is not syncable. A host MUST 1319 NOT initiate re-keying with any KeyLSB other than its current key 1320 number plus one modulo 256. 1322 When a host receives a segment containing a REKEY suboption, it MUST 1323 proceed as follows: 1325 1. The receiver computes RECEIVE-KEY-NUMBER to be the closest 1326 integer to its own transmit key number that also equals KeyLSB 1327 modulo 256. If no number is closest (because KeyLSB is exactly 1328 128 away from the transmit number modulo 256), the receiver MUST 1329 discard the segment. If RECEIVE-KEY-NUMBER is negative, the 1330 receiver MUST also discard the segment. 1332 2. The receiver MUST authenticate and decrypt the segment using the 1333 receive keys with generation number RECEIVE-KEY-NUMBER. The 1334 receiver MUST discard the packet as usual if the MAC is invalid. 1336 3. If RECEIVE-KEY-NUMBER is greater than the receiver's current 1337 transmit key number, the receiver must wait to receive all 1338 sequence numbers prior to the REKEY segment's. Once it receives 1339 segments covering all these missing sequence numbers (if any), it 1340 MUST increase its transmit number to RECEIVE-KEY-NUMBER and 1341 transmit a REKEY suboption. If the receiver has gotten multiple 1342 REKEY segments with different KeyLSB values, it MUST increase its 1343 transmit key number to the highest RECEIVE-KEY-NUMBER of any 1344 segment for which it is not missing prior sequence numbers. 1346 After sending a REKEY (whether initiating re-keying or just 1347 responding), a host MUST continue to send REKEY in all subsequent 1348 segments until at least one of the following holds: 1350 o One of the REKEY segments the host transmitted for its current 1351 transmit key number was syncable, and it has been synced. 1353 o The host receives a cumulative acknowledgment for one of its REKEY 1354 segments with the current transmit key number, and the cumulative 1355 acknowledgment is in a segment encrypted with the new key but not 1356 containing a REKEY suboption. 1358 A host SHOULD erase old keys from memory once the above requirements 1359 are met. 1361 A host MUST NOT initiate re-keying if it initiated a re-keying less 1362 than 60 seconds ago and has not transmitted at least 1 Megabyte 1363 (increased its sequence number by 1,048,576) since the last re- 1364 keying. A host MUST NOT initiate re-keying if it has outstanding 1365 unacknowledged REKEY segments for key numbers that are 127 or more 1366 below the current key. A host SHOULD not initiate more than one 1367 concurrent re-key operation if it has no data to send. 1369 4.3.9. The INIT1 and INIT2 suboptions 1371 The INIT1 dataless suboption indicates that the Data portion of the 1372 TCP segment contains the following data structure: 1374 Byte 0 1 2 3 1375 +-------+-------+-------+-------+ 1376 | 0x0001 | # sym ciphers | 1377 +-------+-------+-------+-------+ 1378 |# bytes of N_C |# bytes of K_C | 1379 +-------+-------+-------+-------+ 1380 | symmetric cipher | 1381 : : 1382 +-------+-------+-------+-------+ 1383 | N_C | 1384 : : 1385 +-------+-------+-------+-------+ 1386 | 0 | type of K_C | 1387 +-------+-------+-------+-------+ 1388 | K_C | 1389 : : 1390 +-------+-------+-------+-------+ 1392 Each symmetric cipher has the following format: 1394 0 1 2 3 1395 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 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 |0 0 0 0 0 0 0 0| cipher alg |0 0 0 0 0 0 0 0| MAC alg | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 Format of symmetric cipher within INIT1 suboption 1402 Note that the cipher and MAC are specified as a pair, using an 8-bit 1403 identifier to specify each supported algorithm. The special cipher 1404 value of 0 means that a MAC can be used with any cipher, or a cipher 1405 with any MAC. The following cipher values are mandatory and MUST be 1406 supported by all implementations: 1408 +-------+---------------------------------+ 1409 | value | cipher | 1410 +-------+---------------------------------+ 1411 | 0x00 | Any cipher okay with this MAC | 1412 | 0x01 | AES-128 CTR mode w. seqno as IV | 1413 +-------+---------------------------------+ 1415 With AES-128 CTR mode, bytes are encrypted using their extended 64- 1416 bit sequence number. To encrypt the byte for sequence number N: 1418 o Compute B = N - (N % 16). 1420 o Let B* = 0^{128-|B|} || B be B with enough 0 bits pre-pended to 1421 make B* exactly 128 bits long. 1423 o Let C = ENC-AES (ke[cs], B*). 1425 o XOR the message byte with byte (N-B) of C. 1427 The following MACs are mandatory and MUST be supported by all 1428 implementations. 1430 +-------+-------------------------------+ 1431 | value | MAC | 1432 +-------+-------------------------------+ 1433 | 0x00 | Any MAC okay with this cipher | 1434 | 0x01 | HMAC-SHA2-128 | 1435 +-------+-------------------------------+ 1437 The value "type of K_C" must be one of the public key specifiers 1438 included earlier in the other host's PKCONF message. 1440 The INIT2 dataless suboption indicates that the Data portion of the 1441 TCP segment contains the following data structure: 1443 Byte 0 1 2 3 1444 +-------+-------+-------+-------+ 1445 | 0x0002 |#byt ciphertext| 1446 +-------+-------+-------+-------+ 1447 | symmetric cipher suite | 1448 +-------+-------+-------+-------+ 1449 | ciphertext | 1450 : : 1451 +-------+-------+-------+-------+ 1453 Here the symmetric cipher suite is one selected by the host 1454 transmitting the INIT2 segment, which will be playing the "S" role. 1455 Neither the cipher nor the MAC may have value 0x00 in the INIT2 1456 segment. The ciphertext is an encryption of N_S, as described in 1457 Section 3.4. 1459 Hosts MUST set the TCP PSH control bits on INIT1 and INIT2 segments. 1460 Implementations MUST NOT set the TCP FIN control bit on INIT2 1461 segments. 1463 4.3.10. The IV suboption 1465 The IV suboption is used to hold an initialization vector (IV) when 1466 the negotiated encryption mode requires an initialization vector to 1467 be transmitted with packets. It MUST NOT be included in transmitted 1468 packets except in the ENCRYPTING state when the negotiated encryption 1469 mode requires IVs. When the negotiated encryption mode does require 1470 IVs, all segments transmitted in ENCRYPTING mode MUST contain an IV 1471 suboption. 1473 The IV suboption has the following format: 1475 Byte 0 1 N 1476 +-------+-------...-------+ 1477 |Opcode=| Initialization | 1478 | 0x85 | Vector | 1479 +-------+-------...-------+ 1481 Format of the IV suboption 1483 The length N of the IV is determined by the encryption algorithm and 1484 mode negotiated. 1486 As discussed in Section 4.3.8, a host MUST always transmit the same 1487 ciphertext byte in retransmissions of a particular sequence number. 1488 Thus, retransmitted segments must use the same IV each time. 1489 Moreover, previously transmitted segments MUST NOT be combined on 1490 retransmission if their IVs would prevent the ciphertext bytes from 1491 remaining the same as in the original transmission. 1493 4.4. The TCP MAC option 1495 The MAC option is used to authenticate a TCP segment as described in 1496 the next section. Once a host has entered the encrypting phase for a 1497 session, the HOST must include a TCP MAC option in all segments it 1498 sends. Furthermore, once in the encrypting phase, a host MUST ignore 1499 any segments it receives that do not have a valid MAC option, except 1500 for segments with the RST bit set if the application has not 1501 requested cryptographic verification of RST segments. 1503 The length of the MAC option is determined by the symmetric message 1504 authentication code selected. The format of the MAC option is: 1506 Byte 0 1 2 N+1 1507 +-------+-------+------...------+ 1508 | Kind | Len= | N-byte | 1509 | OPT2 | 2+N | MAC | 1510 +-------+-------+------...------+ 1512 Format of TCP MAC option 1514 The MAC is computed based on two data structures, a pseudo-packet 1515 structure we call M, and an acknowledgment structure we call A. The 1516 format of M is as follows: 1518 Byte 0 1 2 3 1519 +-------+-------+-------+-------+ 1520 0 | 0x8000 | length | 1521 +-------+-------+-------+-------+ 1522 4 | off | flags | window | 1523 +-------+-------+---------------+ 1524 8 | 0x0000 | urg | 1525 +-------+-------+-------+-------+ 1526 12 | seqno_hi | 1527 +-------+-------+-------+-------+ 1528 16 | seqno | 1529 +-------+-------+-------+-------+ 1530 20 | options | 1531 : : 1532 +-------+-------+-------+-------+ 1533 | payload ciphertext | 1534 | must be len-off bytes | 1535 : : 1536 +-------+-------+-------+-------+ 1538 M data structure 1540 The fields of M are defined as follows: 1542 length 1543 Total size of the TCP segment from the start of the TCP header to 1544 the end of the IP datagram. 1546 off 1547 Byte 12 of the TCP header (Data Offset) 1549 flags 1550 Byte 13 of the TCP header (Control Bits) 1552 window 1553 Bytes 14-15 of the TCP header (Window) 1555 urg 1556 Bytes 18-19 of the TCP header (Urgent Pointer) 1558 seqno_hi 1559 Number of times the seqno field has wrapped from 0xffffff -> 0 1561 seqno 1562 Bytes 4-7 of the TCP header (Sequence Number) 1564 options 1565 These are bytes 20-off of the TCP header. However, where the 1566 TSOPT (8), Skeeter (16), Bubba (17), MD5 (19), and MAC (OPT2) 1567 options appear, their contents (all but the kind and length bytes) 1568 are replaced with all zeroes. 1570 payload ciphertext 1571 This is the Data portion of the TCP segment, which contains 1572 encrypted ciphertext. 1574 The format of the A structure is as follows: 1576 Byte 0 1 2 3 1577 +-------+-------+-------+-------+ 1578 0 | ackno_hi | 1579 +-------+-------+-------+-------+ 1580 4 | ackno | 1581 +-------+-------+-------+-------+ 1583 A data structure 1585 The fields of A are defined as follows: 1587 ackno_hi blah The number of times ackno has wrapped from 0xffffff -> 1588 0. 1590 ackno blah Bytes 8-11 of the TCP header. 1592 For HMAC-SHA2-128, The N-byte MAC value in the option contains the 1593 exclusive OR of MAC (M) and MAC (A). 1595 5. Examples 1597 To illustrate these suboptions, consider the following series of ways 1598 in which a TCP connection may be established from host A to host B. 1599 We use notation S for SYN-only packet, SA for SYN-ACK packet, and A 1600 for packets with the ACK bit but not SYN bit. These examples are not 1601 normative. 1603 5.1. Example 1: Normal handshake 1605 (1) A -> B: S CRYPT<> 1606 (2) B -> A: SA CRYPT> 1607 (3) A -> B: A data 1608 (4) B -> A: A data 1609 (5) A -> B: A MAC data<...> 1610 (1) A indicates interest in using tcpcrypt. In (2), the server 1611 indicates willingness to accept Rabin-Williams public keys between 1612 1,024 and 4,096 bytes long. Messages (3) and (4) complete the INIT1 1613 and INIT2 key exchange messages described above, which are embedded 1614 in the data portion of the TCP segment. (5) From this point on, all 1615 messages are encrypted, and their integrity protected by a MAC option 1616 (described in the next section). 1618 5.2. Example 2: Normal handshake with SYN cookie 1620 (1) A -> B: S CRYPT<> 1621 (2) B -> A: SA CRYPT, SYNCOOKIE> 1622 (3) A -> B: A CRYPT> data 1623 (4) B -> A: A data 1624 (5) B -> A: A MAC data<...> 1626 Same as previous example, except the server sends the client a SYN 1627 cookie value, which the client must echo in (3). Here also the 1628 application level protocol begins by B transmitting data, while in 1629 the previous example A was the first to transmit application-level 1630 data. 1632 5.3. Example 3: tcpcrypt unsupported 1634 (1) A -> B: S CRYPT<> 1635 (2) B -> A: SA 1636 (3) A -> A: A 1638 (1) A indicates interest in using tcpcrypt. (2) B does not support 1639 tcpcrypt, or a middle box strips out the CRYPT TCP option. (3) the 1640 client completes a normal three-way handshake, and tcpcrypt is not 1641 enabled for the connection. 1643 5.4. Example 4: Reusing established state 1645 (1) A -> B: S CRYPT> 1646 (2) B -> A: SA CRYPT 1647 (3) A -> A: A MAC 1649 (1) A indicates interest in using tcpcrypt with a session key derived 1650 from an existing key, to avoid the use of public key cryptography for 1651 the new session. (2) B supports tcpcrypt, but does not does not have 1652 ID in its session ID cache. (3) the client completes a normal three- 1653 way handshake, and tcpcrypt is not enabled for the connection. 1655 5.5. Example 5: Decline of state reuse 1657 (1) A -> B: S CRYPT> 1658 (2) B -> A: SA CRYPT> 1659 (3) A -> B: A data 1660 (4) B -> A: A data 1661 (5) A -> B: A MAC data<...> 1663 A wishes to use a key derived from a previous session key, but B does 1664 not recognize the session ID or has flushed it from its cache. 1665 Therefore session establishment proceeds as in the first connection, 1666 with public key encryption. 1668 5.6. Exmaple 6: Reversal of client and server roles 1670 (1) A -> B: S CRYPT<> 1671 (2) B -> A: SA CRYPT 1672 (3) A -> B: A CRYPT> 1673 (4) B -> A: A data 1674 (5) A -> B: A data 1675 (6) B -> A: A MAC data<...> 1677 Here the server, B, wishes to play the role of the decryptor. By 1678 sending a HELLO suboption, it causes A to switch roles, so that now A 1679 is "S" and B can play the role of "C". 1681 6. API extensions 1683 The getsockopt call should have new options for IPPROTO_TCP: 1685 TCP_CRYPT_SESSID -> should return the session ID or error if no 1686 tcpcrypt. 1688 TCP_CRYPT_PUBKEY -> should return (mine, pubkey), where pubkey is 1689 the public key used to establish the session (K_C), and mine says 1690 whether the key belongs to this host or the remote peer. 1692 TCP_CRYPT_CONF -> returns encryption algorithms used for the 1693 current session. 1695 TCP_CRYPT_SUPPORT -> returns 1 if the remote application is 1696 tcpcrypt-aware. 1698 The setsockopt call should have: 1700 TCP_CRYPT_CACHE_FLUSH -> setting wipes cached session keys. 1701 Useful if application-level authentication discovers a man in the 1702 middle attack, to prevent the next connection from using NEXTK. 1704 The following options should be readable and writable with getsockopt 1705 and setsockopt: 1707 TCP_CRYPT_ENABLE -> one bit, enables or disables tcpcrypt 1708 extension on an unconnected (listening or new) socket. 1710 TCP_CRYPT_SECURST -> one bit, means ignore unauthenticated RST 1711 packets for this connection when set to 1. 1713 TCP_CRYPT_CMODE_{DEFAULT,NEVER,ALWAYS}[_NK] -> As described in 1714 Section 4.2. 1716 TCP_CRYPT_PKCONF -> set of allowed public key algorithms and CPRFs 1717 this host advertises in CRYPT PKCONF suboptions. 1719 TCP_CRYPT_CCONF -> set of allowed symmetric ciphers and message 1720 authentication codes this host advertises in CRYPT INIT1 segments. 1722 TCP_CRYPT_SCONF -> order of preference of symmetric ciphers. 1724 TCP_CRYPT_SUPPORT -> set to 1 if the application is tcpcrypt- 1725 aware. set to 2 if the application requires the remote application 1726 to be tcpcrypt-aware. 1728 Finally, system administrators must be able to set the following 1729 system-wide parameters: 1731 o Default TCP_CRYPT_ENABLE value 1733 o Default TCP_CRYPT_PKCONF value 1735 o Default TCP_CRYPT_CCONF value 1737 o Default TCP_CRYPT_SCONF value 1739 o Types, key lengths, and regeneration intervals of local host's 1740 ephemeral public keys 1742 The session ID can be used for end-to-end security. For instance, 1743 applications might sign the session ID with public keys to 1744 authenticate their ends of a connection. Because session IDs are not 1745 secret, servers can sign them in batches to amortize the cost of the 1746 signature over multiple connections. Alternative, DSA signatures are 1747 cheaper to compute than to verify, so might be a good way for servers 1748 to authenticate themselves. A voice application could display the 1749 session ID on both parties' screens, and if they confirm by voice 1750 that they have the same ID, then the conversation is secure. 1752 Because the public key may change less often than once a session, it 1753 may alternatively be useful for the local end of a connection to 1754 authenticate itself by signing the local host's public key instead of 1755 the session ID. 1757 7. Acknowledgments 1759 This work was funded by gifts from Intel (to Brad Karp) and from 1760 Google, and by NSF award CNS-0716806 (A Clean-Slate Infrastructure 1761 for Information Flow Control). 1763 8. IANA Considerations 1765 When tcpcrypt is extended, the following numbers must be assigned by 1766 IANA: 1768 o New opcodes for CRYPT suboptions 1770 o New identifiers for public key algorithms 1772 o New identifiers for symmetric key algorithms 1774 This memo includes no request to IANA. 1776 All drafts are required to have an IANA considerations section (see 1777 the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] 1778 for a guide). If the draft does not require IANA to do anything, the 1779 section contains an explicit statement that this is the case (as 1780 above). If there are no requirements for IANA, the section will be 1781 removed during conversion into an RFC by the RFC Editor. 1783 9. Security Considerations 1785 All drafts are required to have a security considerations section. 1786 See RFC 3552 [RFC3552] for a guide. 1788 10. References 1790 10.1. Normative References 1792 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1793 RFC 793, September 1981. 1795 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1796 Communication Layers", STD 3, RFC 1122, October 1989. 1798 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 1799 for High Performance", RFC 1323, May 1992. 1801 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 1802 Selective Acknowledgment Options", RFC 2018, October 1996. 1804 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1805 Hashing for Message Authentication", RFC 2104, 1806 February 1997. 1808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1809 Requirement Levels", BCP 14, RFC 2119, March 1997. 1811 [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography 1812 Specifications Version 2.0", RFC 2437, October 1998. 1814 10.2. Informative References 1816 [I-D.narten-iana-considerations-rfc2434bis] 1817 Narten, T. and H. Alvestrand, "Guidelines for Writing an 1818 IANA Considerations Section in RFCs", 1819 draft-narten-iana-considerations-rfc2434bis-09 (work in 1820 progress), March 2008. 1822 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1823 Text on Security Considerations", BCP 72, RFC 3552, 1824 July 2003. 1826 Appendix A. Protocol constant values 1827 +-------+---------------+ 1828 | Value | Name | 1829 +-------+---------------+ 1830 | 0x01 | TAG_NEXTK | 1831 | 0x02 | TAG_SESSID | 1832 | 0x03 | TAG_REKEY | 1833 | 0x04 | TAG_KEY_C_ENC | 1834 | 0x05 | TAG_KEY_C_MAC | 1835 | 0x06 | TAG_KEY_S_ENC | 1836 | 0x07 | TAG_KEY_S_MAC | 1837 +-------+---------------+ 1839 Protocol constants. 1841 Table 4 1843 Authors' Addresses 1845 Andrea Bittau 1846 Stanford University 1847 Department of Computer Science 1848 353 Serra Mall, Room 288 1849 Stanford, CA 94305 1850 US 1852 Phone: +1 650 723 8777 1853 Email: bittau@cs.stanford.edu 1855 Dan Boneh 1856 Stanford University 1857 Department of Computer Science 1858 353 Serra Mall, Room 475 1859 Stanford, CA 94305 1860 US 1862 Phone: +1 650 725 3897 1863 Email: dabo@cs.stanford.edu 1864 Mike Hamburg 1865 Stanford University 1866 Department of Computer Science 1867 353 Serra Mall, Room 475 1868 Stanford, CA 94305 1869 US 1871 Phone: +1 650 725 3897 1872 Email: mike@shiftleft.org 1874 Mark Handley 1875 University College London 1876 Department of Computer Science 1877 University College London 1878 Gower St. 1879 London WC1E 6BT 1880 UK 1882 Phone: +44 20 7679 7296 1883 Email: M.Handley@cs.ucl.ac.uk 1885 David Mazieres 1886 Stanford University 1887 Department of Computer Science 1888 353 Serra Mall, Room 290 1889 Stanford, CA 94305 1890 US 1892 Phone: +1 415 490 9451 1893 Email: dm@uun.org 1895 Quinn Slack 1896 Stanford University 1897 Department of Computer Science 1898 353 Serra Mall, Room 288 1899 Stanford, CA 94305 1900 US 1902 Phone: +1 650 723 8777 1903 Email: sqs@cs.stanford.edu