draft-ietf-tcpm-rfc1948bis-02.txt | rfc6528.txt | |||
---|---|---|---|---|
TCP Maintenance and Minor Extensions F. Gont | Internet Engineering Task Force (IETF) F. Gont | |||
(tcpm) SI6 Networks / UTN-FRH | Request for Comments: 6528 SI6 Networks / UTN-FRH | |||
Internet-Draft S. Bellovin | Obsoletes: 1948 S. Bellovin | |||
Obsoletes: 1948 (if approved) Columbia University | Updates: 793 Columbia University | |||
Updates: 793 (if approved) December 16, 2011 | Category: Standards Track February 2012 | |||
Intended status: Standards Track | ISSN: 2070-1721 | |||
Expires: June 18, 2012 | ||||
Defending Against Sequence Number Attacks | Defending against Sequence Number Attacks | |||
draft-ietf-tcpm-rfc1948bis-02.txt | ||||
Abstract | Abstract | |||
This document specifies an algorithm for the generation of TCP | This document specifies an algorithm for the generation of TCP | |||
Initial Sequence Numbers (ISNs), such that the chances of an off-path | Initial Sequence Numbers (ISNs), such that the chances of an off-path | |||
attacker guessing the sequence numbers in use by a target connection | attacker guessing the sequence numbers in use by a target connection | |||
are reduced. This document revises (and formally obsoletes) RFC | are reduced. This document revises (and formally obsoletes) RFC | |||
1948, and takes the ISN generation algorithm originally proposed in | 1948, and takes the ISN generation algorithm originally proposed in | |||
that document to Standards Track, formally updating RFC 793. | that document to Standards Track, formally updating RFC 793. | |||
Status of this Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | ||||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | This is an Internet Standards Track document. | |||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 5741. | ||||
This Internet-Draft will expire on June 18, 2012. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
http://www.rfc-editor.org/info/rfc6528. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2012 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Generation of Initial Sequence Numbers . . . . . . . . . . . . 3 | 2. Generation of Initial Sequence Numbers . . . . . . . . . . . . 3 | |||
3. Proposed Initial Sequence Number generation algorithm . . . . 4 | 3. Proposed Initial Sequence Number Generation Algorithm . . . . 4 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 | 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . . 8 | Appendix A. Address-Based Trust-Relationship Exploitation | |||
Appendix A. Address-based trust relationship exploitation | Attacks . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
attacks . . . . . . . . . . . . . . . . . . . . . . . 10 | A.1. Blind TCP Connection-Spoofing . . . . . . . . . . . . . . 10 | |||
A.1. Blind TCP connection-spoofing . . . . . . . . . . . . . . 10 | ||||
Appendix B. Changes from RFC 1948 . . . . . . . . . . . . . . . . 12 | Appendix B. Changes from RFC 1948 . . . . . . . . . . . . . . . . 12 | |||
Appendix C. Changes from previous versions of the document | ||||
(this section should be removed by the RFC Editor | ||||
before publication of this document as an RFC) . . . 12 | ||||
C.1. Changes from draft-ietf-tcpm-rfc1948bis-00 . . . . . . . . 12 | ||||
C.2. Changes from draft-gont-tcpm-rfc1948bis-00 . . . . . . . . 12 | ||||
C.3. Changes from RFC 1948 . . . . . . . . . . . . . . . . . . 13 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
1. Introduction | 1. Introduction | |||
For a long time, the Internet has experienced a number of off-path | For a long time, the Internet has experienced a number of off-path | |||
attacks against TCP connections. These attacks have ranged from | attacks against TCP connections. These attacks have ranged from | |||
trust relationships exploitation to Denial of Service attacks | trust-relationship exploitation to denial-of-service attacks | |||
[CPNI-TCP]. Discussion of some of these attacks dates back to at | [CPNI-TCP]. Discussion of some of these attacks dates back to at | |||
least 1985, when Morris [Morris1985] described a form of attack based | least 1985, when Morris [Morris1985] described a form of attack based | |||
on guessing what sequence numbers TCP [RFC0793] will use for new | on guessing what sequence numbers TCP [RFC0793] will use for new | |||
connections between two known end-points. | connections between two known end-points. | |||
In 1996, RFC 1948 [RFC1948] proposed an algorithm for the selection | In 1996, RFC 1948 [RFC1948] proposed an algorithm for the selection | |||
of TCP Initial Sequence Numbers (ISNs), such that the chances of an | of TCP Initial Sequence Numbers (ISNs), such that the chances of an | |||
off-path attacker guessing valid sequence numbers are reduced. With | off-path attacker guessing valid sequence numbers are reduced. With | |||
the aforementioned algorithm, such attacks would remain possible if | the aforementioned algorithm, such attacks would remain possible if | |||
and only if the attacker already has the ability to perform "man in | and only if the attacker already has the ability to perform "man-in- | |||
the middle" attacks. | the-middle" attacks. | |||
This document revises (and formally obsoletes) RFC 1948, and takes | This document revises (and formally obsoletes) RFC 1948, and takes | |||
the ISN generation algorithm originally proposed in that document to | the ISN generation algorithm originally proposed in that document to | |||
Standards Track. | Standards Track. | |||
Section 2 provides a brief discussion of the requirements for a good | Section 2 provides a brief discussion of the requirements for a good | |||
ISN generation algorithm. Section 3 specifies a good ISN selection | ISN generation algorithm. Section 3 specifies a good ISN selection | |||
algorithm. Finally, Appendix A provides a discussion of the trust- | algorithm. Appendix A provides a discussion of the trust- | |||
relationship exploitation attacks that originally motivated the | relationship exploitation attacks that originally motivated the | |||
publication of RFC 1948 [RFC1948]. | publication of RFC 1948 [RFC1948]. Finally, Appendix B lists the | |||
differences from RFC 1948 to this document. | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
2. Generation of Initial Sequence Numbers | 2. Generation of Initial Sequence Numbers | |||
RFC 793 [RFC0793] suggests that the choice of the ISN of a connection | RFC 793 [RFC0793] suggests that the choice of the ISN of a connection | |||
is not arbitrary, but aims to reduce the chances of a stale segment | is not arbitrary, but aims to reduce the chances of a stale segment | |||
from being accepted by a new incarnation of a previous connection. | from being accepted by a new incarnation of a previous connection. | |||
RFC 793 [RFC0793] suggests the use of a global 32-bit ISN generator | RFC 793 [RFC0793] suggests the use of a global 32-bit ISN generator | |||
that is incremented by 1 roughly every 4 microseconds. | that is incremented by 1 roughly every 4 microseconds. | |||
It is interesting to note that, as a matter of fact, protection | It is interesting to note that, as a matter of fact, protection | |||
against stale segments from a previous incarnation of the connection | against stale segments from a previous incarnation of the connection | |||
is enforced by preventing the creation of a new incarnation of a | is enforced by preventing the creation of a new incarnation of a | |||
previous connection before 2*MSL have passed since a segment | previous connection before 2*MSL have passed since a segment | |||
corresponding to the old incarnation was last seen. This is | corresponding to the old incarnation was last seen (where "MSL" is | |||
accomplished by the TIME-WAIT state, and TCP's "quiet time" concept | the "Maximum Segment Lifetime" [RFC0793]). This is accomplished by | |||
(see Appendix B of [RFC1323]). | the TIME-WAIT state and TCP's "quiet time" concept (see Appendix B of | |||
[RFC1323]). | ||||
Based on the assumption that ISNs are monotonically-increasing across | Based on the assumption that ISNs are monotonically increasing across | |||
connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an | connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an | |||
incoming SYN segment to perform "heuristics" that enable the creation | incoming SYN segment to perform "heuristics" that enable the creation | |||
of a new incarnation of a connection while the previous incarnation | of a new incarnation of a connection while the previous incarnation | |||
is still in the TIME-WAIT state (see pp. 945 of [Wright1994]). This | is still in the TIME-WAIT state (see p. 945 of [Wright1994]). This | |||
avoids an interoperability problem that may arise when a node | avoids an interoperability problem that may arise when a node | |||
establishes connections to a specific TCP end-point at a high rate | establishes connections to a specific TCP end-point at a high rate | |||
[Silbersack2005]. | [Silbersack2005]. | |||
Unfortunately, the ISN generator described in [RFC0793] makes it | Unfortunately, the ISN generator described in [RFC0793] makes it | |||
trivial for an off-path attacker to predict the ISN that a TCP will | trivial for an off-path attacker to predict the ISN that a TCP will | |||
use for new connections, thus allowing a variety of attacks against | use for new connections, thus allowing a variety of attacks against | |||
TCP connections [CPNI-TCP]. One of the possible attacks that takes | TCP connections [CPNI-TCP]. One of the possible attacks that takes | |||
advantage of weak sequence numbers was first described in | advantage of weak sequence numbers was first described in | |||
[Morris1985], and its exploitation was widely publicized about 10 | [Morris1985], and its exploitation was widely publicized about 10 | |||
skipping to change at page 4, line 33 | skipping to change at page 3, line 50 | |||
generators, and a survey of the algorithms in use by popular TCP | generators, and a survey of the algorithms in use by popular TCP | |||
implementations. | implementations. | |||
Simple random selection of the TCP ISNs would mitigate those attacks | Simple random selection of the TCP ISNs would mitigate those attacks | |||
that require an attacker to guess valid sequence numbers. However, | that require an attacker to guess valid sequence numbers. However, | |||
it would also break the 4.4BSD "heuristics" to accept a new incoming | it would also break the 4.4BSD "heuristics" to accept a new incoming | |||
connection when there is a previous incarnation of that connection in | connection when there is a previous incarnation of that connection in | |||
the TIME-WAIT state [Silbersack2005]. | the TIME-WAIT state [Silbersack2005]. | |||
We can prevent sequence number guessing attacks by giving each | We can prevent sequence number guessing attacks by giving each | |||
connection -- that is, each 4-tuple of (localip, localport, remoteip, | connection -- that is, each four-tuple of (localip, localport, | |||
remoteport) -- a separate sequence number space. Within each space, | remoteip, remoteport) -- a separate sequence number space. Within | |||
the ISN is incremented according to [RFC0793]; however, there is no | each space, the ISN is incremented according to [RFC0793]; however, | |||
obvious relationship between the numbering in different spaces. | there is no obvious relationship between the numbering in different | |||
spaces. | ||||
An obvious way to prevent sequence number guessing attacks while not | An obvious way to prevent sequence number guessing attacks while not | |||
breaking the 4.4BSD heuristics would be to maintain state for dead | breaking the 4.4BSD heuristics would be to perform a simple random | |||
connections, and the easiest way to do that would be to change the | selection of TCP ISNs while maintaining state for dead connections | |||
TCP state transition diagram so that both end-points of all | (e.g. changing the TCP state transition diagram so that both end- | |||
connections go to TIME-WAIT state. That would work, but would | points of all connections go to TIME-WAIT state). That would work | |||
consume system memory to store the additional state. Instead, we | but would consume system memory to store the additional state. | |||
propose an improvement to the TCP ISN generation algorithm, that does | Instead, we propose an improvement to the TCP ISN generation | |||
not require TCP to keep state for all recently-terminated | algorithm that does not require TCP to keep state for all recently | |||
connections. | terminated connections. | |||
3. Proposed Initial Sequence Number generation algorithm | 3. Proposed Initial Sequence Number Generation Algorithm | |||
TCP SHOULD generate its Initial Sequence Numbers with the expression: | TCP SHOULD generate its Initial Sequence Numbers with the expression: | |||
ISN = M + F(localip, localport, remoteip, remoteport) | ISN = M + F(localip, localport, remoteip, remoteport, secretkey) | |||
where M is the 4 microsecond timer, and F() is a pseudorandom | where M is the 4 microsecond timer, and F() is a pseudorandom | |||
function (PRF) of the connection-id. F() MUST NOT be computable from | function (PRF) of the connection-id. F() MUST NOT be computable from | |||
the outside, or an attacker could still guess at sequence numbers | the outside, or an attacker could still guess at sequence numbers | |||
from the ISN used for some other connection. The PRF could be | from the ISN used for some other connection. The PRF could be | |||
implemented as a cryptographic hash of the concatenation of the | implemented as a cryptographic hash of the concatenation of the | |||
connection-id and some secret data; MD5 [RFC1321] would be a good | connection-id and some secret data; MD5 [RFC1321] would be a good | |||
choice for the hash function. | choice for the hash function. | |||
The result of F() is no more secure than the secret key. If an | The result of F() is no more secure than the secret key. If an | |||
attacker is aware of which cryptographic hash function is being used | attacker is aware of which cryptographic hash function is being used | |||
by the victim (which we should expect), and the attacker can obtain | by the victim (which we should expect), and the attacker can obtain | |||
enough material (i.e., ISNs selected by the victim), the attacker may | enough material (i.e., ISNs selected by the victim), the attacker may | |||
simply search the entire secret-key space to find matches. To | simply search the entire secret-key space to find matches. To | |||
protect against this, the secret key should be of a reasonable | protect against this, the secret key should be of a reasonable | |||
length. Key lengths of 128 bits should be adequate. The secret key | length. Key lengths of 128 bits should be adequate. The secret key | |||
can either be a true random number [RFC4086], or some per-host | can either be a true random number [RFC4086] or some per-host secret. | |||
secret. A possible mechanism for protecting the secret key would be | A possible mechanism for protecting the secret key would be to change | |||
to change it on occasion. For example, the secret key could be | it on occasion. For example, the secret key could be changed | |||
changed whenever one of the following events occur: | whenever one of the following events occur: | |||
o The system is being bootstrapped (e.g., the secret key could be a | o The system is being bootstrapped (e.g., the secret key could be a | |||
combination of some secret and the boot time of the machine). | combination of some secret and the boot time of the machine). | |||
o Some predefined/random time has expired. | o Some predefined/random time has expired. | |||
o The secret key has been used sufficiently often that it should be | o The secret key has been used sufficiently often that it should be | |||
regarded as insecure now. | regarded as insecure at that point. | |||
Note that changing the secret would change the ISN space used for | Note that changing the secret would change the ISN space used for | |||
reincarnated connections, and thus could lead to the 4.4BSD | reincarnated connections, and thus could cause the 4.4BSD heuristics | |||
heuristics to fail; to maintain safety, either dead connection state | to fail; to maintain safety, either dead connection state could be | |||
could be kept or a quiet time observed for two maximum segment | kept or a quiet time observed for two maximum segment lifetimes | |||
lifetimes before such a change. | before such a change. | |||
It should be noted that while there have been concerns about the | It should be noted that while there have been concerns about the | |||
security properties of MD5 [RFC6151], the algorithm specified in this | security properties of MD5 [RFC6151], the algorithm specified in this | |||
document simply aims at reducing the chances of an off-path attacker | document simply aims at reducing the chances of an off-path attacker | |||
guessing the ISN of a new connection, and thus in our threat model it | guessing the ISN of a new connection, and thus in our threat model it | |||
is not worth the effort for an attacker to try to learn the secret | is not worth the effort for an attacker to try to learn the secret | |||
key. Since MD5 is faster than other "stronger" alternatives, and is | key. Since MD5 is faster than other "stronger" alternatives, and is | |||
used in virtually all existing implementations of this algorithm, we | used in virtually all existing implementations of this algorithm, we | |||
consider that use of MD5 in the specified algorithm is acceptable. | consider that use of MD5 in the specified algorithm is acceptable. | |||
However, implementations should consider the trade-offs involved in | However, implementations should consider the trade-offs involved in | |||
using functions with stronger security properties, and employ them if | using functions with stronger security properties, and employ them if | |||
it is deemed appropriate. | it is deemed appropriate. | |||
4. Security Considerations | 4. Security Considerations | |||
Good sequence numbers are not a replacement for cryptographic | Good sequence numbers are not a replacement for cryptographic | |||
authentication, such as that provided by IPsec [RFC4301] or TCP-AO | authentication, such as that provided by IPsec [RFC4301] or the TCP | |||
[RFC5925]. At best, they are a palliative measure. | Authentication Option (TCP-AO) [RFC5925]. At best, they are a | |||
palliative measure. | ||||
If random numbers are used as the sole source of the secret, they | If random numbers are used as the sole source of the secret, they | |||
MUST be chosen in accordance with the recommendations given in | MUST be chosen in accordance with the recommendations given in | |||
[RFC4086]. | [RFC4086]. | |||
A security consideration that should be made about the algorithm | A security consideration that should be made about the algorithm | |||
proposed in this document is that it might allow an attacker to count | proposed in this document is that it might allow an attacker to count | |||
the number of systems behind a Network Address Translator (NAT) | the number of systems behind a Network Address Translator (NAT) | |||
[RFC3022]. Depending on the ISN generators implemented by each of | [RFC3022]. Depending on the ISN generators implemented by each of | |||
the systems behind the NAT, an attacker might be able to count the | the systems behind the NAT, an attacker might be able to count the | |||
number of systems behind a NAT by establishing a number of TCP | number of systems behind a NAT by establishing a number of TCP | |||
connections (using the public address of the NAT) and identifying the | connections (using the public address of the NAT) and identifying the | |||
number of different sequence number "spaces". | number of different sequence number "spaces". [Gont2009] discusses | |||
[I-D.gont-behave-nat-security] discusses how this and other | how this and other information leakages at NATs could be mitigated. | |||
information leakages at NATs could be mitigated. | ||||
An eavesdropper who can observe the initial messages for a connection | An eavesdropper who can observe the initial messages for a connection | |||
can determine its sequence number state, and may still be able to | can determine its sequence number state, and may still be able to | |||
launch sequence number guessing attacks by impersonating that | launch sequence number guessing attacks by impersonating that | |||
connection. However, such an eavesdropper can also hijack existing | connection. However, such an eavesdropper can also hijack existing | |||
connections [Joncheray1995], so the incremental threat is not that | connections [Joncheray1995], so the incremental threat is not that | |||
high. Still, since the offset between a fake connection and a given | high. Still, since the offset between a fake connection and a given | |||
real connection will be more or less constant for the lifetime of the | real connection will be more or less constant for the lifetime of the | |||
secret, it is important to ensure that attackers can never capture | secret, it is important to ensure that attackers can never capture | |||
such packets. Typical attacks that could disclose them include both | such packets. Typical attacks that could disclose them include both | |||
eavesdropping and the variety of routing attacks discussed in | eavesdropping and the variety of routing attacks discussed in | |||
[Bellovin1989]. | [Bellovin1989]. | |||
Off-path attacks against TCP connections require the attacker to | Off-path attacks against TCP connections require the attacker to | |||
guess or know the four-tuple (localip, localport, remoteip, | guess or know the four-tuple (localip, localport, remoteip, | |||
remoteport) that identifies the target connection. TCP port number | remoteport) that identifies the target connection. TCP port number | |||
randomization [RFC6056] reduces the chances of an attacker of | randomization [RFC6056] reduces the chances of an attacker of | |||
guessing such four-tuple by obfuscating the selection of TCP | guessing such a four-tuple by obfuscating the selection of TCP | |||
ephemeral ports, therefore contributing to the mitigation of such | ephemeral ports, therefore contributing to the mitigation of such | |||
attacks. [RFC6056] provides advice on the selection of TCP ephemeral | attacks. [RFC6056] provides advice on the selection of TCP ephemeral | |||
ports, such that the overall protection of TCP connections against | ports, such that the overall protection of TCP connections against | |||
off-path attacks is improved. | off-path attacks is improved. | |||
[CPNI-TCP] contains a discussion of all the currently-known attacks | [CPNI-TCP] contains a discussion of all the currently known attacks | |||
that require an attacker to know or be able to guess the TCP sequence | that require an attacker to know or be able to guess the TCP sequence | |||
numbers in use by the target connection. | numbers in use by the target connection. | |||
5. IANA Considerations | 5. Acknowledgements | |||
This document has no actions for IANA. | ||||
6. Acknowledgements | ||||
Matt Blaze and Jim Ellis contributed some crucial ideas to RFC 1948, | Matt Blaze and Jim Ellis contributed some crucial ideas to RFC 1948, | |||
on which this document is based. Frank Kastenholz contributed | on which this document is based. Frank Kastenholz contributed | |||
constructive comments to that memo. | constructive comments to that memo. | |||
The authors of this document would like to thank (in chronological | The authors of this document would like to thank (in chronological | |||
order) Alfred Hoenes, Lloyd Wood, Lars Eggert, Joe Touch, William | order) Alfred Hoenes, Lloyd Wood, Lars Eggert, Joe Touch, William | |||
Allen Simpson, Tim Shepard, Wesley Eddy, Anantha Ramaiah, and Ben | Allen Simpson, Tim Shepard, Wesley Eddy, Anantha Ramaiah, and Ben | |||
Campbell, for providing valuable comments on earlier versions of this | Campbell for providing valuable comments on draft versions of this | |||
document. | document. | |||
Fernando Gont would like to thank the United Kingdom's Centre for the | Fernando Gont wishes to thank Jorge Oscar Gont, Nelida Garcia, and | |||
Protection of National Infrastructure (UK CPNI) for their continued | Guillermo Gont for their love and support, and Daniel Bellomo and | |||
support. | Christian O'Flaherty for their support in his Internet engineering | |||
activities. | ||||
7. References | Fernando Gont's attendance to IETF meetings was supported by ISOC's | |||
"Fellowship to the IETF" program. | ||||
7.1. Normative References | 6. References | |||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | 6.1. Normative References | |||
RFC 793, September 1981. | ||||
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | |||
April 1992. | RFC 793, September 1981. | |||
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions | [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", | |||
for High Performance", RFC 1323, May 1992. | RFC 1321, April 1992. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Extensions for High Performance", RFC 1323, | |||
May 1992. | ||||
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirements for Security", BCP 106, RFC 4086, June 2005. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- | [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, | |||
Protocol Port Randomization", BCP 156, RFC 6056, | "Randomness Requirements for Security", BCP 106, | |||
January 2011. | RFC 4086, June 2005. | |||
7.2. Informative References | [RFC6056] Larsen, M. and F. Gont, "Recommendations for | |||
Transport-Protocol Port Randomization", BCP 156, | ||||
RFC 6056, January 2011. | ||||
[Bellovin1989] | 6.2. Informative References | |||
Morris, R., "Security Problems in the TCP/IP Protocol | ||||
Suite", Computer Communications Review, vol. 19, no. 2, | ||||
pp. 32-48, 1989. | ||||
[CERT2001] | [Bellovin1989] Morris, R., "Security Problems in the TCP/IP | |||
CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in | Protocol Suite", Computer Communications Review, | |||
TCP/IP Initial Sequence Numbers", | vol. 19, no. 2, pp. 32-48, 1989. | |||
http://www.cert.org/advisories/CA-2001-09.html, 2001. | ||||
[CPNI-TCP] | [CERT2001] CERT, "CERT Advisory CA-2001-09: Statistical | |||
CPNI, "Security Assessment of the Transmission Control | Weaknesses in TCP/IP Initial Sequence Numbers", | |||
Protocol (TCP)", http://www.cpni.gov.uk/Docs/ | http://www.cert.org/advisories/CA-2001-09.html, | |||
tn-03-09-security-assessment-TCP.pdf, 2009. | 2001. | |||
[I-D.gont-behave-nat-security] | [CPNI-TCP] CPNI, "Security Assessment of the Transmission | |||
Gont, F. and P. Srisuresh, "Security implications of | Control Protocol (TCP)", http://www.gont.com.ar/ | |||
Network Address Translators (NATs)", | papers/tn-03-09-security-assessment-TCP.pdf, 2009. | |||
draft-gont-behave-nat-security-03 (work in progress), | ||||
October 2009. | ||||
[Joncheray1995] | [Gont2009] Gont, F. and P. Srisuresh, "Security implications | |||
Joncheray, L., "A Simple Active Attack Against TCP", Proc. | of Network Address Translators (NATs)", Work | |||
Fifth Usenix UNIX Security Symposium, 1995. | in Progress, October 2009. | |||
[Morris1985] | [Joncheray1995] Joncheray, L., "A Simple Active Attack Against | |||
Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP | TCP", Proc. Fifth Usenix UNIX Security Symposium, | |||
Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, | 1995. | |||
NJ, 1985. | ||||
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol | [Morris1985] Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP | |||
Specification", STD 8, RFC 854, May 1983. | Software", CSTR 117, AT&T Bell Laboratories, Murray | |||
Hill, NJ, 1985. | ||||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol | |||
STD 13, RFC 1034, November 1987. | Specification", STD 8, RFC 854, May 1983. | |||
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", | [RFC1034] Mockapetris, P., "Domain names - concepts and | |||
RFC 1948, May 1996. | facilities", STD 13, RFC 1034, November 1987. | |||
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network | [RFC1948] Bellovin, S., "Defending Against Sequence Number | |||
Address Translator (Traditional NAT)", RFC 3022, | Attacks", RFC 1948, May 1996. | |||
January 2001. | ||||
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The | [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP | |||
Kerberos Network Authentication Service (V5)", RFC 4120, | Network Address Translator (Traditional NAT)", | |||
July 2005. | RFC 3022, January 2001. | |||
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) | [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, | |||
Protocol Architecture", RFC 4251, January 2006. | "The Kerberos Network Authentication Service (V5)", | |||
RFC 4120, July 2005. | ||||
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the | [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) | |||
Internet Protocol", RFC 4301, December 2005. | Protocol Architecture", RFC 4251, January 2006. | |||
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension | [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | |||
for Authentication", RFC 4954, July 2007. | Internet Protocol", RFC 4301, December 2005. | |||
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service | |||
October 2008. | Extension for Authentication", RFC 4954, July 2007. | |||
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", | |||
Authentication Option", RFC 5925, June 2010. | RFC 5321, October 2008. | |||
[RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol | [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | |||
(AXFR)", RFC 5936, June 2010. | Authentication Option", RFC 5925, June 2010. | |||
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations | [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer | |||
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", | Protocol (AXFR)", RFC 5936, June 2010. | |||
RFC 6151, March 2011. | ||||
[Shimomura1995] | [RFC6151] Turner, S. and L. Chen, "Updated Security | |||
Shimomura, T., "Technical details of the attack described | Considerations for the MD5 Message-Digest and the | |||
by Markoff in NYT", | HMAC-MD5 Algorithms", RFC 6151, March 2011. | |||
http://www.gont.com.ar/docs/post-shimomura-usenet.txt, | ||||
Message posted in USENET's comp.security.misc newsgroup, | ||||
Message-ID: <3g5gkl$5j1@ariel.sdsc.edu>, 1995. | ||||
[Silbersack2005] | [Shimomura1995] Shimomura, T., "Technical details of the attack | |||
Silbersack, M., "Improving TCP/IP security through | described by Markoff in NYT", | |||
randomization without sacrificing interoperability.", | http://www.gont.com.ar/docs/post-shimomura- | |||
EuroBSDCon 2005 Conference . | usenet.txt, Message posted in USENET's | |||
comp.security.misc newsgroup, Message-ID: | ||||
<3g5gkl$5j1@ariel.sdsc.edu>, 1995. | ||||
[USCERT2001] | [Silbersack2005] Silbersack, M., "Improving TCP/IP security through | |||
US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple | randomization without sacrificing | |||
TCP/IP implementations may use statistically predictable | interoperability", EuroBSDCon 2005 Conference. | |||
initial sequence numbers", | ||||
http://www.kb.cert.org/vuls/id/498440, 2001. | ||||
[Wright1994] | [USCERT2001] US-CERT, "US-CERT Vulnerability Note VU#498440: | |||
Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: | Multiple TCP/IP implementations may use | |||
The Implementation", Addison-Wesley, 1994. | statistically predictable initial sequence | |||
numbers", http://www.kb.cert.org/vuls/id/498440, | ||||
2001. | ||||
[Zalewski2001] | [Wright1994] Wright, G. and W. Stevens, "TCP/IP Illustrated, | |||
Zalewski, M., "Strange Attractors and TCP/IP Sequence | Volume 2: The Implementation", Addison-Wesley, | |||
Number Analysis", | 1994. | |||
http://lcamtuf.coredump.cx/oldtcp/tcpseq.html, 2001. | ||||
[Zalewski2002] | [Zalewski2001] Zalewski, M., "Strange Attractors and TCP/IP | |||
Zalewski, M., "Strange Attractors and TCP/IP Sequence | Sequence Number Analysis", | |||
Number Analysis - One Year Later", | http://lcamtuf.coredump.cx/oldtcp/tcpseq.html, | |||
http://lcamtuf.coredump.cx/newtcp/, 2002. | 2001. | |||
Appendix A. Address-based trust relationship exploitation attacks | [Zalewski2002] Zalewski, M., "Strange Attractors and TCP/IP | |||
Sequence Number Analysis - One Year Later", | ||||
http://lcamtuf.coredump.cx/newtcp/, 2002. | ||||
Appendix A. Address-Based Trust-Relationship Exploitation Attacks | ||||
This section discusses the trust-relationship exploitation attack | This section discusses the trust-relationship exploitation attack | |||
that originally motivated the publication of RFC 1948 [RFC1948]. It | that originally motivated the publication of RFC 1948 [RFC1948]. It | |||
should be noted that while RFC 1948 focused its discussion of | should be noted that while RFC 1948 focused its discussion of | |||
address-based trust relationship exploitation attacks on Telnet | address-based trust-relationship exploitation attacks on Telnet | |||
[RFC0854] and the various UNIX "r" commands, both Telnet and the | [RFC0854] and the various UNIX "r" commands, both Telnet and the | |||
various "r" commands have since been largely replaced by secure | various "r" commands have since been largely replaced by secure | |||
counter-parts (such as SSH [RFC4251]) for the purpose of remote login | counterparts (such as SSH [RFC4251]) for the purpose of remote login | |||
and remote command execution. Nevertheless, address-based trust | and remote command execution. Nevertheless, address-based trust | |||
relationships are still employed nowadays in some scenarios. For | relationships are still employed nowadays in some scenarios. For | |||
example, some SMTP [RFC5321] deployments still authenticate their | example, some SMTP [RFC5321] deployments still authenticate their | |||
users by means of their IP addresses, even when more appropriate | users by means of their IP addresses, even when more appropriate | |||
authentication mechanisms are available [RFC4954]. Another example | authentication mechanisms are available [RFC4954]. Another example | |||
is the authentication of DNS secondary servers [RFC1034] by means of | is the authentication of DNS secondary servers [RFC1034] by means of | |||
their IP addresses for allowing DNS zone transfers [RFC5936], or any | their IP addresses for allowing DNS zone transfers [RFC5936], or any | |||
other access control mechanism based on IP addresses. | other access control mechanism based on IP addresses. | |||
In 1985, Morris [Morris1985] described a form of attack based on | In 1985, Morris [Morris1985] described a form of attack based on | |||
guessing what sequence numbers TCP [RFC0793] will use for new | guessing what sequence numbers TCP [RFC0793] will use for new | |||
connections. Briefly, the attacker gags a host trusted by the | connections. Briefly, the attacker gags a host trusted by the | |||
target, impersonates the IP address of the trusted host when talking | target, impersonates the IP address of the trusted host when talking | |||
to the target, and completes the 3-way handshake based on its guess | to the target, and completes the three-way handshake based on its | |||
at the next ISN to be used. An ordinary connection to the target is | guess at the next ISN to be used. An ordinary connection to the | |||
used to gather sequence number state information. This entire | target is used to gather sequence number state information. This | |||
sequence, coupled with address-based authentication, allows the | entire sequence, coupled with address-based authentication, allows | |||
attacker to execute commands on the target host. | the attacker to execute commands on the target host. | |||
Clearly, the proper solution for these attacks is cryptographic | Clearly, the proper solution for these attacks is cryptographic | |||
authentication [RFC4301] [RFC4120] [RFC4251]. | authentication [RFC4301] [RFC4120] [RFC4251]. | |||
The following subsection provides technical details for the trust | The following subsection provides technical details for the trust- | |||
relationship exploitation attack described by Morris [Morris1985]. | relationship exploitation attack described by Morris [Morris1985]. | |||
A.1. Blind TCP connection-spoofing | A.1. Blind TCP Connection-Spoofing | |||
In order to understand the particular case of sequence number | In order to understand the particular case of sequence number | |||
guessing, one must look at the 3-way handshake used in the TCP open | guessing, one must look at the three-way handshake used in the TCP | |||
sequence [RFC0793]. Suppose client machine A wants to talk to rsh | open sequence [RFC0793]. Suppose client machine A wants to talk to | |||
server B. It sends the following message: | rsh server B. It sends the following message: | |||
A->B: SYN, ISNa | A->B: SYN, ISNa | |||
That is, it sends a packet with the SYN ("synchronize sequence | That is, it sends a packet with the SYN ("synchronize sequence | |||
number") bit set and an initial sequence number ISNa. | number") bit set and an initial sequence number ISNa. | |||
B replies with | B replies with | |||
B->A: SYN, ISNb, ACK(ISNa) | B->A: SYN, ISNb, ACK(ISNa) | |||
skipping to change at page 12, line 17 | skipping to change at page 12, line 15 | |||
connection, and thus by the time the connection is reset, the | connection, and thus by the time the connection is reset, the | |||
attacker has already won. | attacker has already won. | |||
In the past, attackers exploited a common TCP implementation bug | In the past, attackers exploited a common TCP implementation bug | |||
to prevent the connection from being reset (see subsection "A | to prevent the connection from being reset (see subsection "A | |||
Common TCP Bug" in [RFC1948]). However, all TCP implementations | Common TCP Bug" in [RFC1948]). However, all TCP implementations | |||
that used to implement this bug have been fixed for a long time. | that used to implement this bug have been fixed for a long time. | |||
Appendix B. Changes from RFC 1948 | Appendix B. Changes from RFC 1948 | |||
o This document aims at Standards Track (rather than Informational). | o This document is Standards Track (rather than Informational). | |||
o Formal requirements ([RFC2119]) are specified. | o Formal requirements [RFC2119] are specified. | |||
o The discussion of address-based trust relationship attacks has | o The discussion of address-based trust-relationship attacks has | |||
been updated and moved to an Appendix. | been updated and moved to an appendix. | |||
o The subsection entitled "A Common TCP Bug" (describing a common | o The subsection entitled "A Common TCP Bug" (describing a common | |||
bug in the BSD TCP implementation) has been removed. | bug in the BSD TCP implementation) has been removed. | |||
Appendix C. Changes from previous versions of the document (this | ||||
section should be removed by the RFC Editor before | ||||
publication of this document as an RFC) | ||||
C.1. Changes from draft-ietf-tcpm-rfc1948bis-00 | ||||
o Addresses WGLC feedback (posted on-list) by Wesley Eddy, and some | ||||
comments submitted by Anantha Ramaiah. | ||||
C.2. Changes from draft-gont-tcpm-rfc1948bis-00 | ||||
o The recommended hash algorithm has been changed back to MD5 | ||||
[RFC1321], with a note that the security implications of MD5 have | ||||
been carefully considered. | ||||
o The subsection entitled "An old BSD bug" (describing a common bug | ||||
in the BSD TCP implementation) has been removed. | ||||
o Minor editorial changes. | ||||
C.3. Changes from RFC 1948 | ||||
o New document aims at Standards Track (rather than Informational). | ||||
o The discussion of address-based trust relationship attacks was | ||||
updated and moved to an Appendix. | ||||
o The recommended hash algorithm has been changed to SHA-256, in | ||||
response to the security concerns for MD5 [RFC1321]. | ||||
o Formal requirements ([RFC2119]) are specified. | ||||
Authors' Addresses | Authors' Addresses | |||
Fernando Gont | Fernando Gont | |||
UTN-FRH / SI6 Networks | SI6 Networks / UTN-FRH | |||
Evaristo Carriego 2644 | Evaristo Carriego 2644 | |||
Haedo, Provincia de Buenos Aires 1706 | Haedo, Provincia de Buenos Aires 1706 | |||
Argentina | Argentina | |||
Phone: +54 11 4650 8472 | Phone: +54 11 4650 8472 | |||
Email: fernando@gont.com.ar | EMail: fgont@si6networks.com | |||
URI: http://www.si6networks.com | URI: http://www.si6networks.com | |||
Steven M. Bellovin | Steven M. Bellovin | |||
Columbia University | Columbia University | |||
1214 Amsterdam Avenue | 1214 Amsterdam Avenue | |||
MC 0401 | MC 0401 | |||
New York, NY 10027 | New York, NY 10027 | |||
US | US | |||
Phone: +1 212 939 7149 | Phone: +1 212 939 7149 | |||
Email: bellovin@acm.org | EMail: bellovin@acm.org | |||
End of changes. 78 change blocks. | ||||
234 lines changed or deleted | 187 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |