idnits 2.17.1 draft-kirsch-ietf-tcp-stealth-01.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 17, 2015) is 3359 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1321' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC4987' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'RFC7323' is defined on line 371, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Kirsch 3 Internet-Draft TU Muenchen 4 Intended status: Informational C. Grothoff 5 Expires: July 21, 2015 Inria Rennes Bretagne Atlantique 6 J. Appelbaum 7 Tor Project Inc. 8 H. Kenn, Ed. 9 Microsoft Deutschland GmbH 10 January 17, 2015 12 TCP Stealth 13 draft-kirsch-ietf-tcp-stealth-01 15 Abstract 17 TCP servers are visible on the Internet to unauthorized clients, as 18 the existence of a TCP server is leaked in the TCP handshake before 19 applications have a chance to authenticate the client. 21 We present a small modification to the initial TCP handshake that 22 allows TCP clients to replace the TCP ISN in the TCP SYN packet with 23 an authorization token. Based on this information, TCP servers may 24 then chose to obscure their presence from unauthorized TCP clients. 26 This RFC documents the specific method for calculating the 27 authorization token to ensure interoperability and to minimize 28 interference by middleboxes. Mandating support for this method in 29 operating system TCP/IP implementations will ensure that clients can 30 connect to TCP servers protected by this method. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 21, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology and Conventions Used in This Document . . . . . . 3 68 3. Description of the TCP Stealth Option . . . . . . . . . . . . 4 69 3.1. 32-bit Access Authorization . . . . . . . . . . . . . . . 4 70 3.1.1. Test Vectors . . . . . . . . . . . . . . . . . . . . 4 71 3.2. 16-bit Access Authorization and 16-bit Payload Protection 5 72 3.2.1. Test Vectors . . . . . . . . . . . . . . . . . . . . 5 73 4. Timestamps and TCP SYN Retransmits . . . . . . . . . . . . . 6 74 5. TCP Stealth and TCP SYN Cookies . . . . . . . . . . . . . . . 6 75 6. Integration with Applications . . . . . . . . . . . . . . . . 6 76 7. TCP Stealth and destination network address translation 77 (DNAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 8. Old duplicate segments . . . . . . . . . . . . . . . . . . . 7 79 9. Middlebox Considerations . . . . . . . . . . . . . . . . . . 7 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 7 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 84 12.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 87 1. Introduction 89 As it has been shown in [ZMAP], it is feasible today to perform a 90 port scan on all Internet hosts in less than an hour and specialized 91 search engines perform such port scans regularily. At the same time, 92 security issues in server implementations are exploited by various 93 parties for espionage and commercial gain. Thus, it is increasingly 94 important to minimize the visible footprint of services on Internet 95 hosts, thereby reducing the attack surface. 97 Since the complete integrity of the internet infrastructure cannot be 98 assumed, it follows that adversaries may be able to observe all 99 traffic of an Internet host and perform man-in-the-middle attacks on 100 traffic originating from specific clients. Furthermore, on the 101 server side, an adversary looking for exploitable systems should be 102 expected to have the ability to perform extensive port scans for TCP 103 servers. 105 To help address this problem, we propose to standardize TCP Stealth, 106 a stealthy port-knocking variant where an authenticator is embedded 107 in the TCP SQN number. TCP Stealth enables authorized clients to 108 perform a standard TCP handshake with the server, while obscuring the 109 existence of the server from port scanners. The basic idea is to 110 transmit an authorization token derived from a shared secret instead 111 of a random value for the initial TCP SQN number in the TCP SYN 112 packet. The token demonstrates to the server that the client is 113 authorized and may furthermore protect the integrity of the beginning 114 of the TCP payload to prevent man-in-the-middle attacks. If the 115 token is incorrect, the operating system pretends that the port is 116 closed. Thus, the TCP server is hidden from port scanners and the 117 TCP traffic has no anomalies compared to a normal TCP handshake. 119 The TCP MD5 Signature Option defined in RFC 2385 defines a similar 120 mechanism, except that RFC 2385 does not work in the presence of NATs 121 (RFC 1631) and visibly changes the TCP wire protocol, and can thus be 122 easily detected. 124 While TCP Stealth does not change the TCP wire protocol, the specific 125 method for calculating the authorization token must be consistent 126 across Internet hosts and their TCP/IP implementations to ensure 127 interoperability. By embedding the port knocking logic into the TCP/ 128 IP implementation of an operating system, we minimize the possibility 129 of detecting hidden services via timing attacks, and avoid the 130 pitfalls of applications trying to re-implement TCP in user-space. 131 Implementors MUST make sure that the response to a connection request 132 with wrong ISN value does not differ in any way from the response to 133 a connection request to a closed port. 135 2. Terminology and Conventions Used in This Document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119. 141 We use "TCP Stealth" to refer to the techniques described in this 142 document. 144 The abbreviation "ISN" is used for the initial sequence number in the 145 TCP header. 147 3. Description of the TCP Stealth Option 149 TCP Stealth implementations MUST support two variants for the TCP ISN 150 calculation. The first variant is to only provide access 151 authorization, the second also ensures the integrity of the first 152 octets of the TCP payload. Which method is used depends on the 153 application protocol, as only certain application protocols can 154 benefit from the TCP payload protection. 156 Using the TCP Timestamp option (see RFC 7323, section 3.2) is 157 recommended but optional in combination with TCP Stealth. If the 158 client does not include a timestamp in the request, the following 159 calculations should be done using a timestamp value of zero. 161 Note that if the TCP Timestamp option is enabled then the TCP 162 implementation MUST make sure that potential retransmits of TCP SYN 163 segments carry the same value for the TSVal field as the initial SYN 164 segment that was sent out by TCP Stealth. 166 3.1. 32-bit Access Authorization 168 For TCP Stealth without payload integrity protection, the 32 bit ISN 169 is calculated using a single round of MD5 (the procedure explained in 170 RFC 1321, section 3.4) using the 64-byte shared secret as the 171 argument for the hash function and a 16 byte initialization vector IV 172 computed as follows: 174 First, the 16 byte are set to the destination address, in the case of 175 IPv4 padded with zeros. Then, (if existent) the timestamp value (in 176 network byte order) is XORed at offsets 8 to 11, and finally the 177 destination port (in network byte order) is XORed at offsets 12 to 178 13. 180 The resulting four 32-bit words of the MD5 hash are combined using 181 XOR to calculate the 32-bit ISN in network byte order. 183 3.1.1. Test Vectors 184 +------------------+-----------------------+-----------------------+ 185 | | IPv4 | IPv6 | 186 +------------------+-----------------------+-----------------------+ 187 | Shared secret | "Magic secret string" | "Magic secret string" | 188 | Destination IP | 192.18.42.42 | 2001:db8::2a:2a | 189 | Destination Port | 4242 | 4242 | 190 | Timestamp | 0x11223344 | 0x11223344 | 191 | Resulting ISN | 0xedea1325 | 0x4923a842 | 192 +------------------+-----------------------+-----------------------+ 194 3.2. 16-bit Access Authorization and 16-bit Payload Protection 196 For TCP Stealth with payload integrity protection, the protected 197 portion of the payload is limited to at most the first segment. 198 Additionally, both client and server must know the exact number of 199 bytes to be protected beforehand. The secret is prepended to the 200 protected payload and hashed using full MD5 and the resulting eight 201 16-bit words of the MD5 hash are combined using XOR to a 16-bit 202 integrity hash (IH). 204 Then, the 32 bit ISN is calculated using a single round of MD5 (the 205 procedure explained in RFC 1321, section 3.4) using the 64-byte 206 shared secret as the argument for the hash function and a 16 byte 207 initialization vector IV computed as follows: 209 First, the 16 bytes are set to the destination address, in the case 210 of IPv4 padded with zeros. The IH is XORed at offset 4 to 5. Then, 211 (if existent) the timestamp value (in network byte order) is XORed at 212 offsets 8 to 11, and finally the destination port (in network byte 213 order) is XORed at offsets 12 to 13. 215 The resulting four 32-bit words of the MD5 hash are combined using 216 XOR to calculate at 32-bit authenticator value (AV). The upper 16 217 bit of the AV are concatenated with the 16 bit of the IH to create 218 the final 32-bit ISN in network byte order 220 The TCP server uses the 16 bit IH from the ISN to calculate the AV 221 when receiving the TCP SYN packet. If the AV matches, the handshake 222 is allowed to proceed. Then, when the TCP server receives the first 223 segment, it checks that the included payload is of sufficient length 224 and in combination with the shared secret hashes to the IH. If these 225 checks fail, the connection is closed (using TCP RST). 227 3.2.1. Test Vectors 228 +---------------+------------------------+--------------------------+ 229 | | IPv4 | IPv6 | 230 +---------------+------------------------+--------------------------+ 231 | Payload | "Protected payload | "Protected payload goes | 232 | | goes here." | here." | 233 | Protected | 28 | 28 | 234 | length | | | 235 | Shared secret | "Magic secret string" | "Magic secret string" | 236 | Destination | 192.18.42.42 | 2001:db8::2a:2a | 237 | IP | | | 238 | Destination | 4242 | 4242 | 239 | Port | | | 240 | Timestamp | 0x11223344 | 0x11223344 | 241 | Resulting ISN | 0x2153ff96 | 0x3ae5ff96 | 242 +---------------+------------------------+--------------------------+ 244 4. Timestamps and TCP SYN Retransmits 246 Implementations of TCP Stealth MUST take care to NOT modify the value 247 of the TCP timestamp (if present) when retransmitting the TCP SYN 248 packet. Otherwise, a different TCP timestamp would change the result 249 of the ISN calculation and the receiver would fail to interpret the 250 SYN packet correctly as a retransmission, which would be problematic 251 in cases where high delay or a loss of the SYN ACK caused the 252 retransmission. 254 TCP implementations in general SHOULD strongly consider preserving 255 the original TCP timestamp value for TCP SYN retransmissions to make 256 it impossible to detect the use of TCP Stealth by forcing TCP SYN 257 retransmissions. 259 5. TCP Stealth and TCP SYN Cookies 261 Implementations of TCP Stealth can support the use of TCP SYN Cookies 262 as described in RFC 4987, even in combination with content integrity 263 protection. For this, the TCP server needs to recover the original 264 ISN by subtracting 1 from the SQN of the first acknowledgement from 265 the client. This way, the TCP server does not need to keep any state 266 after receiving just the SYN packet. 268 6. Integration with Applications 270 Given operating system support, nearly every network application can 271 be easily adapted to use TCP Stealth. Operating systems MUST use 272 their existing facilities for setting TCP options to enable TCP 273 clients to specify the shared secret and optionally the first octets 274 of the TCP payload that are to be integrity protected. Similarly, 275 for the TCP server it MUST be possible to set the shared secret and 276 the expected number of protected octets of the TCP payload. 278 Furthermore, support for these options MUST be provided for both IPv4 279 and IPv6 and MAY be provided for other address families. 281 7. TCP Stealth and destination network address translation (DNAT) 283 As TCP Stealth relies on the destination port and address being 284 preserved across the network, TCP Stealth cannot directly be used 285 with hosts behind a DNAT. In case a host behind a DNAT should be 286 protected by TCP Stealth the TCP Stealth implementation should be 287 moved directly into the DNAT implementation. 289 8. Old duplicate segments 291 A client using the pseudo-random ISN generation of TCP Stealth 292 without payload protection must respect TCP TIME-WAIT and use a 293 different source port for a second connection to the same destination 294 until sufficient time has past for old duplicate segments of the 295 previous TCP connection to not be in the network anymore. TCP 296 Stealth has no impact on the TCP PAWS mechanism (RFC 7323), as PAWS 297 makes no assumptions about the ISN. 299 9. Middlebox Considerations 301 To avoid interfering with TCP Stealth, middleboxes SHOULD NOT modify 302 TCP SQN numbers and SHOULD preserve the TCP timestamp option (if 303 present). Recent studies [OSSIFICATION] [Knock] have shown that 304 almost all middleboxes already satisfy these constraints. 306 10. IANA Considerations 308 None. 310 11. Security Considerations 312 Implementations using a predictable shared secret and predictable 313 values for the TCP timestamp (such as 0 if timestamps are not used at 314 all) may be susceptible to attacks based on ISN prediction. Thus, 315 applications MUST be careful to not set the option with an empty or 316 default value for the shared secret (especially in the case where the 317 user did not to specify a shared secret). Similarly, static sequence 318 numbers occur when TCP timestamps are disabled for each combination 319 of secret, destination IP address and destination port. 321 Using predictable ISNs can be used as a vector for denial-of-service 322 attacks on TCP (such as CVE-2005-0356). However, with TCP Stealth, 323 only the authorized client and the providing server share the secret 324 necessary to predict the ISN. Routers that are in a position to 325 observe the ISN from the handshake can always perform a Denial of 326 Service attack on TCP. TCP Stealth does not change this fundamental 327 issue with TCP. 329 Middleboxes MAY modify the TCP SQN number or tamper with the TCP 330 timestamp option. In this case, services protected by the TCP 331 Stealth option would be unavailble to clients accessing the network 332 from behind such a NAT. While such implementations are rare in 333 practice, operators should be aware of the resulting possible 334 limitations in availablilty of TCP Stealth protected services. 336 TCP Stealth MAY protect against malicious attacks in which security 337 flaws of software operating above the TCP protocol are exploited. 338 However TCP Stealth SHOULD be considered as an additional layer of 339 security, not as a replacement of IP or higher level based 340 authentication. 342 TCP Stealth does not protect against passive port scan scenarios in 343 which an attacker can tell a closed from an open port by 344 eavesdropping on the connection made by a legit client to a TCP 345 Stealth protected server. TCP Stealth MAY protect against active 346 man-in-the-middle attacks in which an attacker tries to intercept the 347 TCP connection after the knock if TCP Stealth operates with payload 348 integrity protection and the application layer protocol is designed 349 in a sane way. 351 The protections offered by TCP Stealth are limited by the fact that 352 the TCP SQN number field is only 32 bits. Thus, an adversary may 353 still be able to connect to TCP Stealth protected services with low 354 probability by chance, or high probability using brute-force methods. 355 Thus, TCP Stealth SHOULD only be used as an additional layer of 356 security. 358 12. References 360 12.1. Normative References 362 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 363 April 1992. 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 369 Mitigations", RFC 4987, August 2007. 371 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 372 Scheffenegger, "TCP Extensions for High Performance", RFC 373 7323, September 2014. 375 12.2. Informative References 377 [Knock] Kirsch, J. and C. Grothoff, "Knock: Practical and Secure 378 Stealthy Servers", August 2014, . 381 [OSSIFICATION] 382 Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 383 Handley, M., and H. Tokuda, "Is It Still Possible to 384 Extend TCP?", 2011, 385 . 387 [ZMAP] Durumeric, Z., Wustrow, E., and J. Halderman, "ZMAP: The 388 Internet Scanner", August 2013, . 390 Authors' Addresses 392 Julian Kirsch 393 TU Muenchen 394 Chair for IT-Security 395 Boltzmannstrasse 3 396 Technische Universitaet Muenchen 397 Garching bei Muenchen, Bayern D-85748 398 DE 400 Email: kirschju@sec.in.tum.de 402 Christian Grothoff 403 Inria Rennes Bretagne Atlantique 404 Equipe Decentralise 405 Inria Rennes Bretagne Atlantique 406 263 Avenue du General Leclerc 407 Campus Universitaire de Beaulieu 408 Rennes Cedex, Bretagne F-35042 409 FR 411 Email: christian@grothoff.org 413 Jacob Appelbaum 414 Tor Project Inc. 416 Email: jacob@appelbaum.net 417 Holger Kenn (editor) 418 Microsoft Deutschland GmbH 419 Konrad Zuse Strasse 1 420 Unterschleissheim D-85716 421 DE 423 Email: holger.kenn@cubeos.org