idnits 2.17.1 draft-ietf-tcpm-rfc1948bis-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC1948, but the abstract doesn't seem to directly say this. It does mention RFC1948 though, so this could be OK. -- The draft header indicates that this document updates RFC793, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC793, updated by this document, for RFC5378 checks: 1981-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 23, 2011) is 4744 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions F. Gont 3 (tcpm) UTN/FRH 4 Internet-Draft S. Bellovin 5 Obsoletes: 1948 (if approved) Columbia University 6 Updates: 793 (if approved) April 23, 2011 7 Intended status: Standards Track 8 Expires: October 25, 2011 10 Defending Against Sequence Number Attacks 11 draft-ietf-tcpm-rfc1948bis-00.txt 13 Abstract 15 This document specifies an algorithm for the generation of TCP 16 Initial Sequence Numbers (ISNs), such that the chances of an off-path 17 attacker of guessing the sequence numbers in use by a target 18 connection are reduced. This document is a revision of RFC 1948, and 19 takes the ISN generation algorithm originally proposed in that 20 document to Standards Track. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 25, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Generation of Initial Sequence Numbers . . . . . . . . . . . . 3 58 3. Proposed Initial Sequence Number (ISN) generation algorithm . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 65 Appendix A. Address-based trust relationship exploitation 66 attacks . . . . . . . . . . . . . . . . . . . . . . . 9 67 A.1. Blind TCP connection-spoofing . . . . . . . . . . . . . . 10 68 Appendix B. Changes from RFC 1948 . . . . . . . . . . . . . . . . 11 69 Appendix C. Changes from previous versions of the document 70 (this section should be removed by the RFC Editor 71 before publication of this document as an RFC) . . . 11 72 C.1. Changes from draft-gont-tcpm-rfc1948bis-00 . . . . . . . . 11 73 C.2. Changes from RFC 1948 . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 During the last 25 years, the Internet has experienced a number of 79 off-path attacks against TCP connections. These attacks have ranged 80 from trust relationships exploitation to Denial of Service attacks 81 [CPNI-TCP]. Discusion of some of these attacks dates back to at 82 least 1985, when Morris [Morris1985] described a form of attack based 83 on guessing what sequence numbers TCP [RFC0793] will use for new 84 connections. 86 In 1996, RFC 1948 [RFC1948] proposed an algorithm for the selection 87 of TCP Initial Sequence Numbers (ISNs), such that the chances of an 88 off-path attacker of guessing valid sequence numbers are reduced. 89 With the aforementioned algorithm, such attacks would remain possible 90 if and only if the Bad Guy already had the ability to launch even 91 more devastating attacks. 93 This document is a revision of RFC 1948, and takes the ISN generation 94 algorithm originally proposed in that document to Standards Track. 96 Section 2 provides a brief discussion of the requirements for a good 97 ISN generation algorithm. Section 3 specifies a good ISN 98 randomization algorithm. Finally, Appendix A provides a discussion 99 of the trust-relationship exploitation attacks that originally 100 motivated the publication of RFC 1948 [RFC1948]. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 2. Generation of Initial Sequence Numbers 108 RFC 793 [RFC0793] suggests that the choice of the Initial Sequence 109 Number of a connection is not arbitrary, but aims to reduce the 110 chances of a stale segment from being accepted by a new incarnation 111 of a previous connection. RFC 793 [RFC0793] suggests the use of a 112 global 32-bit ISN generator that is incremented by 1 roughly every 4 113 microseconds. 115 It is interesting to note that, as a matter of fact, protection 116 against stale segments from a previous incarnation of the connection 117 is enforced by preventing the creation of a new incarnation of a 118 previous connection before 2*MSL have passed since a segment 119 corresponding to the old incarnation was last seen. This is 120 accomplished by the TIME-WAIT state, and TCP's "quiet time" concept 121 (see Appendix B of [RFC1323]). 123 Based on the assumption that ISNs are monotonically-increasing across 124 connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an 125 incomming SYN segment to perform "heuristics" that enable the 126 creation of a new incarnation of a connection while the previous 127 incarnation is still in the TIME-WAIT state (see pp. 945 of 128 [Wright1994]). This avoids an interoperability problem that may 129 arise when a systems establishes connections to a specific TCP end- 130 point at a high rate [Silbersack2005]. 132 Unfortunately, the ISN generator described in [RFC0793] makes it 133 trivial for an off-path attacker to predict the ISN that a TCP will 134 use for new connections, thus allowing a variety of attacks against 135 TCP connections [CPNI-TCP]. One of the possible attacks that takes 136 advantage of weak sequence numbers was first described in 137 [Morris1985], and its exploitation was widely publicized about 10 138 years later [Shimomura1995]. [CERT2001] and [USCERT2001] are 139 advisories about the security implications of weak ISN generators. 140 [Zalewski2001] and [Zalewski2002] contain a detailed analysis of ISN 141 generators, and a survey of the algorithms in use by popular TCP 142 implementations. 144 Simple randomization of the TCP Initial Sequence Numbers would 145 mitigate those attacks that require an attacker to guess valid 146 sequence numbers. However, it would also break the 4.4BSD 147 "heuristics" to accept a new incoming connection when there is a 148 previous incarnation of that connection in the TIME-WAIT state 149 [Silbersack2005]. 151 We can prevent sequence number guessing attacks by giving each 152 connection -- that is, each 4-tuple of (localip, localport, remoteip, 153 remoteport) -- a separate sequence number space. Within each space, 154 the initial sequence number is incremented according to [RFC0793]; 155 however, there is no obvious relationship between the numbering in 156 different spaces. 158 The obvious way to do this is to maintain state for dead connections, 159 and the easiest way to do that is to change the TCP state transition 160 diagram so that both ends of all connections go to TIME-WAIT state. 161 That would work, but it's inelegant and consumes storage space. 162 Instead, we propose an improvement to the TCP ISN generation 163 algorithm. 165 3. Proposed Initial Sequence Number (ISN) generation algorithm 167 TCP SHOULD generate its Initial Sequence Numbers with the expression: 169 ISN = M + F(localip, localport, remoteip, remoteport) 171 where M is the 4 microsecond timer, and F is a pseudorandom function 172 (PRF) of the connection-id. It is vital that F not be computable 173 from the outside, or an attacker could still guess at sequence 174 numbers from the initial sequence number used for some other 175 connection. The PRF could be implemented as a cryptographic hash of 176 the concatenation of the connection-id and some secret data; MD5 177 [RFC1321] would be a good choice for the hash function. The secret 178 data can either be a true random number [RFC4086], or it can be the 179 combination of some per-host secret and the boot time of the machine. 180 The boot time is included to ensure that the secret is changed on 181 occasion. 183 Note that the secret cannot easily be changed on a live machine. 184 Doing so would change the initial sequence numbers used for 185 reincarnated connections; to maintain safety, either dead connection 186 state must be kept or a quiet time observed for two maximum segment 187 lifetimes after such a change. 189 It should be noted that while there have been concerns about the 190 security properties of MD5 [RFC6151], the algorithm specified in this 191 document simply aims at reducing the chances of an off-path attacker 192 of guessing the ISN of a new connection, and hence we consider that 193 use of MD5 in the specified algorithm is acceptable. 195 4. Security Considerations 197 Good sequence numbers are not a replacement for cryptographic 198 authentication, such as that provided by IPsec [RFC4301] or TCP-AO 199 [RFC5925]. At best, they're a palliative measure. 201 If random numbers are used as the sole source of the secret, they 202 MUST be chosen in accordance with the recommendations given in 203 [RFC4086]. 205 A security consideration that should be made about the algorithm 206 proposed in this document is that it might allow an attacker to count 207 the number of systems behind a Network Address Translator (NAT) 208 [RFC3022]. Depending on the ISN generators implemented by each of 209 the systems behind the NAT, an attacker might be able to count the 210 number of systems behind a NAT by establishing a number of TCP 211 connections (using the public address of the NAT) and indentifying 212 the number of different sequence number "spaces". 213 [I-D.gont-behave-nat-security] discusses how this and other 214 information leakages at NATs could be mitigated. 216 An eavesdropper who can observe the initial messages for a connection 217 can determine its sequence number state, and may still be able to 218 launch sequence number guessing attacks by impersonating that 219 connection. However, such an eavesdropper can also hijack existing 220 connections [Joncheray1995], so the incremental threat isn't that 221 high. Still, since the offset between a fake connection and a given 222 real connection will be more or less constant for the lifetime of the 223 secret, it is important to ensure that attackers can never capture 224 such packets. Typical attacks that could disclose them include both 225 eavesdropping and the variety of routing attacks discussed in 226 [Bellovin1989]. 228 [CPNI-TCP] contains a discussion of all the currently-known attacks 229 that require an attacker to know or be able to guess the TCP sequence 230 numbers in use by the target connection. 232 5. IANA Considerations 234 This document has no actions for IANA. 236 6. Acknowledgements 238 Matt Blaze and Jim Ellis contributed some crucial ideas to RFC 1948, 239 on which this document is based. Frank Kastenholz contributed 240 constructive comments to that memo. 242 The authors of this document woul like to thank (in chronological 243 order) Alfred Hoenes, Lloyd Wood, Lars Eggert, Joe Touch, William 244 Allen Simpson, and Tim Shepard, for providing valuable comments on 245 earlier versions of this document. 247 Fernando Gont would like to thank the United Kingdom's Centre for the 248 Protection of National Infrastructure (UK CPNI) for their continued 249 support. 251 7. References 253 7.1. Normative References 255 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 256 RFC 793, September 1981. 258 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 259 April 1992. 261 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 262 for High Performance", RFC 1323, May 1992. 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 268 Requirements for Security", BCP 106, RFC 4086, June 2005. 270 7.2. Informative References 272 [Bellovin1989] 273 Morris, R., "Security Problems in the TCP/IP Protocol 274 Suite", Computer Communications Review, vol. 19, no. 2, 275 pp. 32-48, 1989. 277 [CERT2001] 278 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 279 TCP/IP Initial Sequence Numbers", 280 http://www.cert.org/advisories/CA-2001-09.html, 2001. 282 [CPNI-TCP] 283 CPNI, "Security Assessment of the Transmission Control 284 Protocol (TCP)", http://www.cpni.gov.uk/Docs/ 285 tn-03-09-security-assessment-TCP.pdf, 2009. 287 [I-D.gont-behave-nat-security] 288 Gont, F. and P. Srisuresh, "Security implications of 289 Network Address Translators (NATs)", 290 draft-gont-behave-nat-security-03 (work in progress), 291 October 2009. 293 [Joncheray1995] 294 Joncheray, L., "A Simple Active Attack Against TCP", Proc. 295 Fifth Usenix UNIX Security Symposium, 1995. 297 [Morris1985] 298 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP 299 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, 300 NJ, 1985. 302 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 303 Specification", STD 8, RFC 854, May 1983. 305 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 306 STD 13, RFC 1034, November 1987. 308 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 309 RFC 1948, May 1996. 311 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 312 Address Translator (Traditional NAT)", RFC 3022, 313 January 2001. 315 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 316 Kerberos Network Authentication Service (V5)", RFC 4120, 317 July 2005. 319 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 320 Protocol Architecture", RFC 4251, January 2006. 322 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 323 Internet Protocol", RFC 4301, December 2005. 325 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 326 for Authentication", RFC 4954, July 2007. 328 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 329 October 2008. 331 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 332 Authentication Option", RFC 5925, June 2010. 334 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 335 (AXFR)", RFC 5936, June 2010. 337 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 338 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 339 RFC 6151, March 2011. 341 [Shimomura1995] 342 Shimomura, T., "Technical details of the attack described 343 by Markoff in NYT", 344 http://www.gont.com.ar/docs/post-shimomura-usenet.txt, 345 Message posted in USENET's comp.security.misc newsgroup, 346 Message-ID: <3g5gkl$5j1@ariel.sdsc.edu>, 1995. 348 [Silbersack2005] 349 Silbersack, M., "Improving TCP/IP security through 350 randomization without sacrificing interoperability.", 351 EuroBSDCon 2005 Conference . 353 [USCERT2001] 354 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple 355 TCP/IP implementations may use statistically predictable 356 initial sequence numbers", 357 http://www.kb.cert.org/vuls/id/498440, 2001. 359 [Wright1994] 360 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 361 The Implementation", Addison-Wesley, 1994. 363 [Zalewski2001] 364 Zalewski, M., "Strange Attractors and TCP/IP Sequence 365 Number Analysis", 366 http://lcamtuf.coredump.cx/oldtcp/tcpseq.html, 2001. 368 [Zalewski2002] 369 Zalewski, M., "Strange Attractors and TCP/IP Sequence 370 Number Analysis - One Year Later", 371 http://lcamtuf.coredump.cx/newtcp/, 2002. 373 Appendix A. Address-based trust relationship exploitation attacks 375 This section discusses the trust-relationship exploitation attack 376 that originally motivated the publication of RFC 1948 [RFC1948]. It 377 should be noted that while RFC 1948 focused its discussion of 378 address-based trust relationship exploitation attacks on Telnet 379 [RFC0854] and the various UNIX "r" commands, both Telnet and the 380 various "r" commands have since been largely replaced by secure 381 counter-parts (such as SSH [RFC4251]) for the purpose of remote login 382 and remote command execution. Nevertheless, address-based trust 383 relationships are still employed nowadays in some scenarios. For 384 example, some SMTP [RFC5321] deployments still authenticate their 385 users by means of their IP addresses, even when more appropriate 386 authentication mechanisms are available [RFC4954]. Another example 387 is the authentication of DNS secondary servers [RFC1034] by means of 388 their IP addresses for allowing DNS zone transfers [RFC5936], or any 389 other access control mechanism based on IP addresses. 391 In 1985, Morris [Morris1985] described a form of attack based on 392 guessing what sequence numbers TCP [RFC0793] will use for new 393 connections. Briefly, the attacker gags a host trusted by the 394 target, impersonates the IP address of the trusted host when talking 395 to the target, and completes the 3-way handshake based on its guess 396 at the next initial sequence number to be used. An ordinary 397 connection to the target is used to gather sequence number state 398 information. This entire sequence, coupled with address-based 399 authentication, allows the attacker to execute commands on the target 400 host. 402 Clearly, the proper solution for these attacks is cryptographic 403 authentication [RFC4301] [RFC4120] [RFC4251]. 405 The following subsection provides technical details for the trust 406 relationship exploitation attack described by Morris [Morris1985]. 408 A.1. Blind TCP connection-spoofing 410 In order to understand the particular case of sequence number 411 guessing, one must look at the 3-way handshake used in the TCP open 412 sequence [RFC0793]. Suppose client machine A wants to talk to rsh 413 server B. It sends the following message: 415 A->B: SYN, ISNa 417 That is, it sends a packet with the SYN ("synchronize sequence 418 number") bit set and an initial sequence number ISNa. 420 B replies with 422 B->A: SYN, ISNb, ACK(ISNa) 424 In addition to sending its own initial sequence number, it 425 acknowledges A's. Note that the actual numeric value ISNa must 426 appear in the message. 428 A concludes the handshake by sending 430 A->B: ACK(ISNb) 432 RFC 793 [RFC0793] specifies that the 32-bit counter be incremented by 433 1 in the low-order position about every 4 microseconds. Instead, 434 Berkeley-derived kernels traditionally incremented it by a constant 435 every second, and by another constant for each new connection. Thus, 436 if you opened a connection to a machine, you knew to a very high 437 degree of confidence what sequence number it would use for its next 438 connection. And therein lied the vulnerability. 440 The attacker X first opens a real connection to its target B -- say, 441 to the mail port or the TCP echo port. This gives ISNb. It then 442 impersonates A and sends 444 Ax->B: SYN, ISNx 446 where "Ax" denotes a packet sent by X pretending to be A. 448 B's response to X's original SYN (so to speak) 450 B->A: SYN, ISNb', ACK(ISNx) 452 goes to the legitimate A, about which more anon. X never sees that 453 message but can still send 455 Ax->B: ACK(ISNb') 457 using the predicted value for ISNb'. If the guess is right -- and 458 usually it will be, if the sequence numbers are weak -- B's rsh 459 server thinks it has a legitimate connection with A, when in fact X 460 is sending the packets. X can't see the output from this session, 461 but it can execute commands as more or less any user -- and in that 462 case, the game is over and X has won. 464 There is a minor difficulty here. If A sees B's message, it will 465 realize that B is acknowledging something it never sent, and will 466 send a RST packet in response to tear down the connection. However, 467 an attacker could send the TCP segments containing the commands to be 468 executed back-to-back with the segments required to establish the TCP 469 connection, and thus by the time the connection is reset, the 470 attacker has already won. 472 In the past, attackers exploited a common TCP implementation bug 473 to prevent the connection from being reset (see subsection "A 474 Common TCP Bug" in [RFC1948]). However, all TCP implementations 475 that used to implement this bug have been fixed for a long time. 477 Appendix B. Changes from RFC 1948 479 o This document aims at Standards Track (rather than Informaitonal). 481 o Formal requirements ([RFC2119]) are specified. 483 o The discussion of address-based trust relationship attacks has 484 been updated and moved to an Appendix. 486 o The subsection entitled "A Common TCP Bug" (describing a common 487 bug in the BSD TCP implementation) has been removed. 489 Appendix C. Changes from previous versions of the document (this 490 section should be removed by the RFC Editor before 491 publication of this document as an RFC) 493 C.1. Changes from draft-gont-tcpm-rfc1948bis-00 495 o The recommended hash algorithm has been changed back to MD5 496 [RFC1321], with a note that the security implications of MD5 have 497 been carefully considered. 499 o The subsection entitled "An old BSD bug" (describing a common bug 500 in the BSD TCP implementation) has been removed. 502 o Minor editorial changes. 504 C.2. Changes from RFC 1948 506 o New document aims at Standards Track (rather than Informaitonal). 508 o The discussion of address-based trust relationship attacks was 509 updated and moved to an Appendix. 511 o The recommended hash algorithm has been changed to SHA-256, in 512 response to the security concerns for MD5 [RFC1321]. 514 o Formal requirements ([RFC2119]) are specified. 516 Authors' Addresses 518 Fernando Gont 519 Universidad Tecnologica Nacional / Facultad Regional Haedo 520 Evaristo Carriego 2644 521 Haedo, Provincia de Buenos Aires 1706 522 Argentina 524 Phone: +54 11 4650 8472 525 Email: fernando@gont.com.ar 526 URI: http://www.gont.com.ar 528 Steven M. Bellovin 529 Columbia University 530 1214 Amsterdam Avenue 531 MC 0401 532 New York, NY 10027 533 US 535 Phone: +1 212 939 7149 536 Email: bellovin@acm.org