idnits 2.17.1 draft-kirsch-ietf-tcp-stealth-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 : ---------------------------------------------------------------------------- == 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 (August 15, 2014) is 3539 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1321' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'RFC1323' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 319, but no explicit reference was found in the text == Unused Reference: 'RFC4987' is defined on line 322, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) Summary: 1 error (**), 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 C. Grothoff 4 Intended status: Informational TU Munich 5 Expires: February 16, 2015 J. Appelbaum 6 Tor Project Inc. 7 H. Kenn, Ed. 8 Microsoft Deutschland GmbH 9 August 15, 2014 11 TCP Stealth 12 draft-kirsch-ietf-tcp-stealth-00 14 Abstract 16 TCP servers are visible on the Internet to unauthorized clients, as 17 the existence of a TCP server is leaked in the TCP handshake before 18 applications have a chance to authenticate the client. 20 We present a small modification to the initial TCP handshake that 21 allows TCP clients to replace the TCP ISN in the TCP SYN packet with 22 an authorization token. Based on this information, TCP servers may 23 then chose to obscure their presence from unauthorized TCP clients. 25 This RFC documents the specific method for calculating the 26 authorization token to ensure interoperability and to minimize 27 interference by middleboxes. Mandating support for this method in 28 operating system TCP/IP implementation will ensure that clients can 29 connect to TCP servers protected by this method. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 16, 2015. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology and Conventions Used in This Document . . . . . . 3 67 3. Description of the TCP Stealth Option . . . . . . . . . . . . 4 68 3.1. 32-bit Access Authorization . . . . . . . . . . . . . . . 4 69 3.1.1. Test Vectors . . . . . . . . . . . . . . . . . . . . 4 70 3.2. 16-bit Access Authorization and 16-bit Payload Protection 5 71 3.2.1. Test Vectors . . . . . . . . . . . . . . . . . . . . 5 72 4. Timestamps and TCP SYN Retransmits . . . . . . . . . . . . . 6 73 5. TCP Stealth and TCP SYN Cookies . . . . . . . . . . . . . . . 6 74 6. Integraton with Applications . . . . . . . . . . . . . . . . 6 75 7. Middlebox Considerations . . . . . . . . . . . . . . . . . . 7 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 80 10.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 As it has been shown in [ZMAP], it is feasible today to perform a 86 port scan on all Internet hosts in less than an hour and specialized 87 search engines perform such port scans regularily. At the same time, 88 security issues in server implementations are exploited by various 89 parties for espionage and commercial gain. Thus, it is increasingly 90 important to minimize the visible footprint of services on Internet 91 hosts, thereby reducing the attack surface. 93 Since the complete integrity of the internet infrastructure cannot be 94 assumed, it follows that adversaries may be able to observe all 95 traffic of an Internet host and perform man-in-the-middle attacks on 96 traffic originating from specific clients. Furthermore, on the 97 server side, an adversary looking for exploitable systems should be 98 expected to have the ability to perform extensive port scans for TCP 99 servers. 101 To help address this problem, we propose to standardize TCP Stealth, 102 a stealthy port-knocking variant where an authenticator is embedded 103 in the TCP SQN number. TCP Stealth enables authorized clients to 104 perform a standard TCP handshake with the server, while obscuring the 105 existence of the server from port scanners. The basic idea is to 106 transmit an authorization token instead of a random value for the 107 initial TCP SQN number in the TCP SYN packet. The token demonstrates 108 to the server that the client is authorized and may furthermore 109 authenticate the beginning of the TCP payload to prevent man-in-the- 110 middle attacks. If the token is incorrect, the operating system 111 pretends that the port is closed. Thus, TCP server is hidden from 112 port scanners and the TCP traffic has no anomalies compared to a 113 normal TCP handshake. 115 The TCP MD5 Signature Option defined in RFC 2385 defines a similar 116 mechanism, except that RFC 2385 does not work in the presence of NATs 117 (RFC 1631) and visibly changes the TCP wire protocol, and can thus be 118 easily detected. 120 While TCP Stealth does not change the TCP wire protocol, the specific 121 method for calculating the authorization token must be consistent 122 across Internet hosts and their TCP/IP implementations to ensure 123 interoperability. By embedding the port knocking logic into the TCP/ 124 IP implementation of an operating system, we minimize the possibility 125 of detecting hidden services via timing attacks, and avoid the 126 pitfalls of applications trying to re-implement TCP in user-space. 128 2. Terminology and Conventions Used in This Document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119. 134 We use "TCP Stealth" to refer to the techniques described in this 135 document. 137 The abbreviation "ISN" is used for the initial sequence number in the 138 TCP header. 140 3. Description of the TCP Stealth Option 142 TCP Stealth implementations MUST support two variants for the TCP ISN 143 calculation. The first variant is to only provide access 144 authorization, the second also authenticates the first octets of the 145 TCP payload. Which method is used depends on the application 146 protocol, as only certain application protocols can benefit from the 147 TCP payload authentication. 149 Using the TCP Timestamp option (see RFC 1323, section 3.2) is 150 recommended but optional in combination with TCP Stealth. If the 151 client does not include a timestamp in the request, the following 152 calculations should be done using a timestamp value of zero. 154 Note that if the TCP Timestamp option is enabled then the TCP 155 implementation MUST make sure that potential retransmits of TCP SYN 156 segments carry the same value for the TSVal field as the initial SYN 157 segment that was sent out by TCP Stealth. 159 3.1. 32-bit Access Authorization 161 For TCP Stealth without payload authentication, the 32 bit ISN is 162 calculated using a single round of MD5 (the procedure explained in 163 RFC 1321, section 3.4) using the 64-byte shared secret as the 164 argument for the hash function and a 16 byte initialization vector IV 165 computed as follows: 167 First, the 16 byte are set to the destination address, in the case of 168 IPv4 padded with zeros. Then, (if existent) the timestamp value (in 169 network byte order) is XORed at offsets 8 to 11, and finally the 170 destination port (in network byte order) is XORed at offsets 12 to 171 13. 173 The resulting four 32-bit words of the MD5 hash are combined using 174 XOR to calculate the 32-bit ISN in network byte order. 176 3.1.1. Test Vectors 178 +------------------+-----------------------+-----------------------+ 179 | | IPv4 | IPv6 | 180 +------------------+-----------------------+-----------------------+ 181 | Shared secret | "Magic secret string" | "Magic secret string" | 182 | Destination IP | 192.18.42.42 | 2001:db8::2a:2a | 183 | Destination Port | 4242 | 4242 | 184 | Timestamp | 0x11223344 | 0x11223344 | 185 | Resulting ISN | 0xedea1325 | 0x4923a842 | 186 +------------------+-----------------------+-----------------------+ 188 3.2. 16-bit Access Authorization and 16-bit Payload Protection 190 For TCP Stealth with payload authentication, the protected portion of 191 the payload is limited to at most the first segment. Additionally, 192 both client and server must know the exact number of bytes to be 193 protected beforehand. The secret is prepended to the protected 194 payload and hashed using full MD5 and the resulting eight 16-bit 195 words of the MD5 hash are combined using XOR to a 16-bit integrity 196 hash (IH). 198 Then, the 32 bit ISN is calculated using a single round of MD5 (the 199 procedure explained in RFC 1321, section 3.4) using the 64-byte 200 shared secret as the argument for the hash function and a 16 byte 201 initialization vector IV computed as follows: 203 First, the 16 bytes are set to the destination address, in the case 204 of IPv4 padded with zeros. The IH is XORed at offset 4 to 5. Then, 205 (if existent) the timestamp value (in network byte order) is XORed at 206 offsets 8 to 11, and finally the destination port (in network byte 207 order) is XORed at offsets 12 to 13. 209 The resulting four 32-bit words of the MD5 hash are combined using 210 XOR to calculate at 32-bit authenticator value (AV). The upper 16 211 bit of the AV are concatenated with the 16 bit of the IH to create 212 the final 32-bit ISN in network byte order 214 The TCP server uses the 16 bit IH from the ISN to calculate the AV 215 when receiving the TCP SYN packet. If the AV matches, the handshake 216 is allowed to proceed. Then, when the TCP server receives the first 217 segment, it checks that the included payload is of sufficient length 218 and in combination with the shared secret hashes to the IH. If these 219 checks fail, the connection is closed (using TCP RST). 221 3.2.1. Test Vectors 222 +---------------+------------------------+--------------------------+ 223 | | IPv4 | IPv6 | 224 +---------------+------------------------+--------------------------+ 225 | Payload | "Protected payload | "Protected payload goes | 226 | | goes here." | here." | 227 | Protected | 28 | 28 | 228 | length | | | 229 | Shared secret | "Magic secret string" | "Magic secret string" | 230 | Destination | 192.18.42.42 | 2001:db8::2a:2a | 231 | IP | | | 232 | Destination | 4242 | 4242 | 233 | Port | | | 234 | Timestamp | 0x11223344 | 0x11223344 | 235 | Resulting ISN | 0x2153ff96 | 0x3ae5ff96 | 236 +---------------+------------------------+--------------------------+ 238 4. Timestamps and TCP SYN Retransmits 240 Implementations of TCP Stealth MUST take care to NOT modify the value 241 of the TCP timestamp (if present) when retransmitting the TCP SYN 242 packet. Otherwise, a different TCP timestamp would change the result 243 of the ISN calculation and the receiver would fail to interpret the 244 SYN packet correctly as a retransmission, which would be problematic 245 in cases where high delay or a loss of the SYN ACK caused the 246 retransmission. 248 TCP implementations in general SHOULD strongly consider preserving 249 the original TCP timestamp value for TCP SYN retransmissions to make 250 it impossible to detect the use of TCP Stealth by forcing TCP SYN 251 retransmissions. 253 5. TCP Stealth and TCP SYN Cookies 255 Implementations of TCP Stealth can support the use of TCP SYN Cookies 256 as described in RFC 4987, even in combination with content integrity 257 protection. For this, the TCP server needs to recover the original 258 ISN by subtracting 1 from the SQN of the first acknowledgement from 259 the client. This way, the TCP server does not need to keep any state 260 after receiving just the SYN packet. 262 6. Integraton with Applications 264 Given operating system support, nearly every network application can 265 be easily adapted to use TCP Stealth. Operating systems MUST use 266 their existing facilities for setting TCP options to enable TCP 267 clients to specify the shared secret and optionally the first octets 268 of the TCP payload that are to be authenticated. Similarly, for the 269 TCP server it MUST be possible to set the shared secret and the 270 expected number of authenticated octets of the TCP payload. 272 Furthermore, support for these options MUST be provided for both IPv4 273 and IPv6 and MAY be provided for other address families. 275 7. Middlebox Considerations 277 To avoid interfering with TCP Stealth, middleboxes SHOULD NOT modify 278 TCP SQN numbers and SHOULD preserve the TCP timestamp option (if 279 present). Recent studies [OSSIFICATION] [Knock] have shown that 280 almost all middleboxes already satisfy these constraints. 282 8. IANA Considerations 284 None. 286 9. Security Considerations 288 Implementations using a predictable shared secret and predictable 289 values for the TCP timestamp (if present) may be susceptible to 290 attacks based on ISN prediction. Thus, applications MUST be careful 291 to not set the option with an empty or default value for the shared 292 secret (especially in the case where the user did not to specify a 293 shared secret). 295 Middleboxes MAY modify the TCP SQN number or tamper with the TCP 296 timestamp option. In this case, services protected by the TCP 297 Stealth option would be unavailble to clients accessing the network 298 from behind such a NAT. While such implementations are rare in 299 practice, operators should be aware of the resulting possible 300 limitations in availablilty of TCP Stealth protected services. 302 The protections offered by TCP Stealth are limited by the fact that 303 the TCP SQN number field is only 32 bits. Thus, an adversary may 304 still be able to connect to TCP Stealth protected services with low 305 probability by chance, or high probability using brute-force methods. 306 Thus, TCP Stealth SHOULD only be used as an additional layer of 307 security. 309 10. References 311 10.1. Normative References 313 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 314 April 1992. 316 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 317 for High Performance", RFC 1323, May 1992. 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, March 1997. 322 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 323 Mitigations", RFC 4987, August 2007. 325 10.2. Informative References 327 [Knock] Kirsch, J. and C. Grothoff, "Knock: Practical and Secure 328 Stealthy Servers", August 2014, . 331 [OSSIFICATION] 332 Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 333 Handley, M., and H. Tokuda, "Is It Still Possible to 334 Extend TCP?", 2011, 335 . 337 [ZMAP] Durumeric, Z., Wustrow, E., and J. Halderman, "ZMAP: The 338 Internet Scanner", August 2013, . 340 Authors' Addresses 342 Julian Kirsch 343 TU Munich 344 Free Secure Network Systems Group 345 Lehrstuhl fuer Netzarchitekturen und Netzdienste 346 Boltzmannstrasse 3 347 Technische Universitaet Muenchen 348 Garching bei Muenchen, Bayern D-85748 349 DE 351 Email: kirschju@sec.in.tum.de 353 Christian Grothoff 354 TU Munich 355 Free Secure Network Systems Group 356 Lehrstuhl fuer Netzarchitekturen und Netzdienste 357 Boltzmannstrasse 3 358 Technische Universitaet Muenchen 359 Garching bei Muenchen, Bayern D-85748 360 DE 362 Email: christian@grothoff.org 363 Jacob Appelbaum 364 Tor Project Inc. 366 Email: jacob@appelbaum.net 368 Holger Kenn (editor) 369 Microsoft Deutschland GmbH 370 Konrad Zuse Strasse 1 371 Unterschleissheim D-85716 372 DE 374 Email: holger.kenn@ieee.org