Internet Engineering Task Force J. Kirsch
Internet-Draft TU Muenchen
Intended status: Informational C. Grothoff
Expires: July 21, 2015 Inria Rennes Bretagne Atlantique
J. Appelbaum
Tor Project Inc.
H. Kenn, Ed.
Microsoft Deutschland GmbH
January 17, 2015
TCP Stealth
draft-kirsch-ietf-tcp-stealth-01
Abstract
TCP servers are visible on the Internet to unauthorized clients, as
the existence of a TCP server is leaked in the TCP handshake before
applications have a chance to authenticate the client.
We present a small modification to the initial TCP handshake that
allows TCP clients to replace the TCP ISN in the TCP SYN packet with
an authorization token. Based on this information, TCP servers may
then chose to obscure their presence from unauthorized TCP clients.
This RFC documents the specific method for calculating the
authorization token to ensure interoperability and to minimize
interference by middleboxes. Mandating support for this method in
operating system TCP/IP implementations will ensure that clients can
connect to TCP servers protected by this method.
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
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 21, 2015.
Kirsch, et al. Expires July 21, 2015 [Page 1]
Internet-Draft TCP Stealth January 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions Used in This Document . . . . . . 3
3. Description of the TCP Stealth Option . . . . . . . . . . . . 4
3.1. 32-bit Access Authorization . . . . . . . . . . . . . . . 4
3.1.1. Test Vectors . . . . . . . . . . . . . . . . . . . . 4
3.2. 16-bit Access Authorization and 16-bit Payload Protection 5
3.2.1. Test Vectors . . . . . . . . . . . . . . . . . . . . 5
4. Timestamps and TCP SYN Retransmits . . . . . . . . . . . . . 6
5. TCP Stealth and TCP SYN Cookies . . . . . . . . . . . . . . . 6
6. Integration with Applications . . . . . . . . . . . . . . . . 6
7. TCP Stealth and destination network address translation
(DNAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Old duplicate segments . . . . . . . . . . . . . . . . . . . 7
9. Middlebox Considerations . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Security Considerations . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
As it has been shown in [ZMAP], it is feasible today to perform a
port scan on all Internet hosts in less than an hour and specialized
search engines perform such port scans regularily. At the same time,
security issues in server implementations are exploited by various
parties for espionage and commercial gain. Thus, it is increasingly
important to minimize the visible footprint of services on Internet
hosts, thereby reducing the attack surface.
Kirsch, et al. Expires July 21, 2015 [Page 2]
Internet-Draft TCP Stealth January 2015
Since the complete integrity of the internet infrastructure cannot be
assumed, it follows that adversaries may be able to observe all
traffic of an Internet host and perform man-in-the-middle attacks on
traffic originating from specific clients. Furthermore, on the
server side, an adversary looking for exploitable systems should be
expected to have the ability to perform extensive port scans for TCP
servers.
To help address this problem, we propose to standardize TCP Stealth,
a stealthy port-knocking variant where an authenticator is embedded
in the TCP SQN number. TCP Stealth enables authorized clients to
perform a standard TCP handshake with the server, while obscuring the
existence of the server from port scanners. The basic idea is to
transmit an authorization token derived from a shared secret instead
of a random value for the initial TCP SQN number in the TCP SYN
packet. The token demonstrates to the server that the client is
authorized and may furthermore protect the integrity of the beginning
of the TCP payload to prevent man-in-the-middle attacks. If the
token is incorrect, the operating system pretends that the port is
closed. Thus, the TCP server is hidden from port scanners and the
TCP traffic has no anomalies compared to a normal TCP handshake.
The TCP MD5 Signature Option defined in RFC 2385 defines a similar
mechanism, except that RFC 2385 does not work in the presence of NATs
(RFC 1631) and visibly changes the TCP wire protocol, and can thus be
easily detected.
While TCP Stealth does not change the TCP wire protocol, the specific
method for calculating the authorization token must be consistent
across Internet hosts and their TCP/IP implementations to ensure
interoperability. By embedding the port knocking logic into the TCP/
IP implementation of an operating system, we minimize the possibility
of detecting hidden services via timing attacks, and avoid the
pitfalls of applications trying to re-implement TCP in user-space.
Implementors MUST make sure that the response to a connection request
with wrong ISN value does not differ in any way from the response to
a connection request to a closed port.
2. Terminology and Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
We use "TCP Stealth" to refer to the techniques described in this
document.
Kirsch, et al. Expires July 21, 2015 [Page 3]
Internet-Draft TCP Stealth January 2015
The abbreviation "ISN" is used for the initial sequence number in the
TCP header.
3. Description of the TCP Stealth Option
TCP Stealth implementations MUST support two variants for the TCP ISN
calculation. The first variant is to only provide access
authorization, the second also ensures the integrity of the first
octets of the TCP payload. Which method is used depends on the
application protocol, as only certain application protocols can
benefit from the TCP payload protection.
Using the TCP Timestamp option (see RFC 7323, section 3.2) is
recommended but optional in combination with TCP Stealth. If the
client does not include a timestamp in the request, the following
calculations should be done using a timestamp value of zero.
Note that if the TCP Timestamp option is enabled then the TCP
implementation MUST make sure that potential retransmits of TCP SYN
segments carry the same value for the TSVal field as the initial SYN
segment that was sent out by TCP Stealth.
3.1. 32-bit Access Authorization
For TCP Stealth without payload integrity protection, the 32 bit ISN
is calculated using a single round of MD5 (the procedure explained in
RFC 1321, section 3.4) using the 64-byte shared secret as the
argument for the hash function and a 16 byte initialization vector IV
computed as follows:
First, the 16 byte are set to the destination address, in the case of
IPv4 padded with zeros. Then, (if existent) the timestamp value (in
network byte order) is XORed at offsets 8 to 11, and finally the
destination port (in network byte order) is XORed at offsets 12 to
13.
The resulting four 32-bit words of the MD5 hash are combined using
XOR to calculate the 32-bit ISN in network byte order.
3.1.1. Test Vectors
Kirsch, et al. Expires July 21, 2015 [Page 4]
Internet-Draft TCP Stealth January 2015
+------------------+-----------------------+-----------------------+
| | IPv4 | IPv6 |
+------------------+-----------------------+-----------------------+
| Shared secret | "Magic secret string" | "Magic secret string" |
| Destination IP | 192.18.42.42 | 2001:db8::2a:2a |
| Destination Port | 4242 | 4242 |
| Timestamp | 0x11223344 | 0x11223344 |
| Resulting ISN | 0xedea1325 | 0x4923a842 |
+------------------+-----------------------+-----------------------+
3.2. 16-bit Access Authorization and 16-bit Payload Protection
For TCP Stealth with payload integrity protection, the protected
portion of the payload is limited to at most the first segment.
Additionally, both client and server must know the exact number of
bytes to be protected beforehand. The secret is prepended to the
protected payload and hashed using full MD5 and the resulting eight
16-bit words of the MD5 hash are combined using XOR to a 16-bit
integrity hash (IH).
Then, the 32 bit ISN is calculated using a single round of MD5 (the
procedure explained in RFC 1321, section 3.4) using the 64-byte
shared secret as the argument for the hash function and a 16 byte
initialization vector IV computed as follows:
First, the 16 bytes are set to the destination address, in the case
of IPv4 padded with zeros. The IH is XORed at offset 4 to 5. Then,
(if existent) the timestamp value (in network byte order) is XORed at
offsets 8 to 11, and finally the destination port (in network byte
order) is XORed at offsets 12 to 13.
The resulting four 32-bit words of the MD5 hash are combined using
XOR to calculate at 32-bit authenticator value (AV). The upper 16
bit of the AV are concatenated with the 16 bit of the IH to create
the final 32-bit ISN in network byte order
The TCP server uses the 16 bit IH from the ISN to calculate the AV
when receiving the TCP SYN packet. If the AV matches, the handshake
is allowed to proceed. Then, when the TCP server receives the first
segment, it checks that the included payload is of sufficient length
and in combination with the shared secret hashes to the IH. If these
checks fail, the connection is closed (using TCP RST).
3.2.1. Test Vectors
Kirsch, et al. Expires July 21, 2015 [Page 5]
Internet-Draft TCP Stealth January 2015
+---------------+------------------------+--------------------------+
| | IPv4 | IPv6 |
+---------------+------------------------+--------------------------+
| Payload | "Protected payload | "Protected payload goes |
| | goes here." | here." |
| Protected | 28 | 28 |
| length | | |
| Shared secret | "Magic secret string" | "Magic secret string" |
| Destination | 192.18.42.42 | 2001:db8::2a:2a |
| IP | | |
| Destination | 4242 | 4242 |
| Port | | |
| Timestamp | 0x11223344 | 0x11223344 |
| Resulting ISN | 0x2153ff96 | 0x3ae5ff96 |
+---------------+------------------------+--------------------------+
4. Timestamps and TCP SYN Retransmits
Implementations of TCP Stealth MUST take care to NOT modify the value
of the TCP timestamp (if present) when retransmitting the TCP SYN
packet. Otherwise, a different TCP timestamp would change the result
of the ISN calculation and the receiver would fail to interpret the
SYN packet correctly as a retransmission, which would be problematic
in cases where high delay or a loss of the SYN ACK caused the
retransmission.
TCP implementations in general SHOULD strongly consider preserving
the original TCP timestamp value for TCP SYN retransmissions to make
it impossible to detect the use of TCP Stealth by forcing TCP SYN
retransmissions.
5. TCP Stealth and TCP SYN Cookies
Implementations of TCP Stealth can support the use of TCP SYN Cookies
as described in RFC 4987, even in combination with content integrity
protection. For this, the TCP server needs to recover the original
ISN by subtracting 1 from the SQN of the first acknowledgement from
the client. This way, the TCP server does not need to keep any state
after receiving just the SYN packet.
6. Integration with Applications
Given operating system support, nearly every network application can
be easily adapted to use TCP Stealth. Operating systems MUST use
their existing facilities for setting TCP options to enable TCP
clients to specify the shared secret and optionally the first octets
of the TCP payload that are to be integrity protected. Similarly,
Kirsch, et al. Expires July 21, 2015 [Page 6]
Internet-Draft TCP Stealth January 2015
for the TCP server it MUST be possible to set the shared secret and
the expected number of protected octets of the TCP payload.
Furthermore, support for these options MUST be provided for both IPv4
and IPv6 and MAY be provided for other address families.
7. TCP Stealth and destination network address translation (DNAT)
As TCP Stealth relies on the destination port and address being
preserved across the network, TCP Stealth cannot directly be used
with hosts behind a DNAT. In case a host behind a DNAT should be
protected by TCP Stealth the TCP Stealth implementation should be
moved directly into the DNAT implementation.
8. Old duplicate segments
A client using the pseudo-random ISN generation of TCP Stealth
without payload protection must respect TCP TIME-WAIT and use a
different source port for a second connection to the same destination
until sufficient time has past for old duplicate segments of the
previous TCP connection to not be in the network anymore. TCP
Stealth has no impact on the TCP PAWS mechanism (RFC 7323), as PAWS
makes no assumptions about the ISN.
9. Middlebox Considerations
To avoid interfering with TCP Stealth, middleboxes SHOULD NOT modify
TCP SQN numbers and SHOULD preserve the TCP timestamp option (if
present). Recent studies [OSSIFICATION] [Knock] have shown that
almost all middleboxes already satisfy these constraints.
10. IANA Considerations
None.
11. Security Considerations
Implementations using a predictable shared secret and predictable
values for the TCP timestamp (such as 0 if timestamps are not used at
all) may be susceptible to attacks based on ISN prediction. Thus,
applications MUST be careful to not set the option with an empty or
default value for the shared secret (especially in the case where the
user did not to specify a shared secret). Similarly, static sequence
numbers occur when TCP timestamps are disabled for each combination
of secret, destination IP address and destination port.
Using predictable ISNs can be used as a vector for denial-of-service
attacks on TCP (such as CVE-2005-0356). However, with TCP Stealth,
Kirsch, et al. Expires July 21, 2015 [Page 7]
Internet-Draft TCP Stealth January 2015
only the authorized client and the providing server share the secret
necessary to predict the ISN. Routers that are in a position to
observe the ISN from the handshake can always perform a Denial of
Service attack on TCP. TCP Stealth does not change this fundamental
issue with TCP.
Middleboxes MAY modify the TCP SQN number or tamper with the TCP
timestamp option. In this case, services protected by the TCP
Stealth option would be unavailble to clients accessing the network
from behind such a NAT. While such implementations are rare in
practice, operators should be aware of the resulting possible
limitations in availablilty of TCP Stealth protected services.
TCP Stealth MAY protect against malicious attacks in which security
flaws of software operating above the TCP protocol are exploited.
However TCP Stealth SHOULD be considered as an additional layer of
security, not as a replacement of IP or higher level based
authentication.
TCP Stealth does not protect against passive port scan scenarios in
which an attacker can tell a closed from an open port by
eavesdropping on the connection made by a legit client to a TCP
Stealth protected server. TCP Stealth MAY protect against active
man-in-the-middle attacks in which an attacker tries to intercept the
TCP connection after the knock if TCP Stealth operates with payload
integrity protection and the application layer protocol is designed
in a sane way.
The protections offered by TCP Stealth are limited by the fact that
the TCP SQN number field is only 32 bits. Thus, an adversary may
still be able to connect to TCP Stealth protected services with low
probability by chance, or high probability using brute-force methods.
Thus, TCP Stealth SHOULD only be used as an additional layer of
security.
12. References
12.1. Normative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007.
Kirsch, et al. Expires July 21, 2015 [Page 8]
Internet-Draft TCP Stealth January 2015
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, "TCP Extensions for High Performance", RFC
7323, September 2014.
12.2. Informative References
[Knock] Kirsch, J. and C. Grothoff, "Knock: Practical and Secure
Stealthy Servers", August 2014, <https://gnunet.org/
knock>.
[OSSIFICATION]
Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
Handley, M., and H. Tokuda, "Is It Still Possible to
Extend TCP?", 2011,
<http://doi.acm.org/10.1145/2068816.2068834>.
[ZMAP] Durumeric, Z., Wustrow, E., and J. Halderman, "ZMAP: The
Internet Scanner", August 2013, <https://zmap.io/>.
Authors' Addresses
Julian Kirsch
TU Muenchen
Chair for IT-Security
Boltzmannstrasse 3
Technische Universitaet Muenchen
Garching bei Muenchen, Bayern D-85748
DE
Email: kirschju@sec.in.tum.de
Christian Grothoff
Inria Rennes Bretagne Atlantique
Equipe Decentralise
Inria Rennes Bretagne Atlantique
263 Avenue du General Leclerc
Campus Universitaire de Beaulieu
Rennes Cedex, Bretagne F-35042
FR
Email: christian@grothoff.org
Jacob Appelbaum
Tor Project Inc.
Email: jacob@appelbaum.net
Kirsch, et al. Expires July 21, 2015 [Page 9]
Internet-Draft TCP Stealth January 2015
Holger Kenn (editor)
Microsoft Deutschland GmbH
Konrad Zuse Strasse 1
Unterschleissheim D-85716
DE
Email: holger.kenn@cubeos.org
Kirsch, et al. Expires July 21, 2015 [Page 10]