TCP Stealth
draft-kirsch-ietf-tcp-stealth-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Julian Kirsch , Christian Grothoff , Jacob Appelbaum , Holger Kenn | ||
| Last updated | 2014-08-14 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kirsch-ietf-tcp-stealth-00
Internet Engineering Task Force J. Kirsch
Internet-Draft C. Grothoff
Intended status: Informational TU Munich
Expires: February 16, 2015 J. Appelbaum
Tor Project Inc.
H. Kenn, Ed.
Microsoft Deutschland GmbH
August 15, 2014
TCP Stealth
draft-kirsch-ietf-tcp-stealth-00
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 implementation 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 February 16, 2015.
Kirsch, et al. Expires February 16, 2015 [Page 1]
Internet-Draft TCP Stealth August 2014
Copyright Notice
Copyright (c) 2014 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. Integraton with Applications . . . . . . . . . . . . . . . . 6
7. Middlebox Considerations . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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.
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
Kirsch, et al. Expires February 16, 2015 [Page 2]
Internet-Draft TCP Stealth August 2014
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 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
authenticate 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, 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.
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.
The abbreviation "ISN" is used for the initial sequence number in the
TCP header.
Kirsch, et al. Expires February 16, 2015 [Page 3]
Internet-Draft TCP Stealth August 2014
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 authenticates 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 authentication.
Using the TCP Timestamp option (see RFC 1323, 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 authentication, 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
+------------------+-----------------------+-----------------------+
| | 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 |
+------------------+-----------------------+-----------------------+
Kirsch, et al. Expires February 16, 2015 [Page 4]
Internet-Draft TCP Stealth August 2014
3.2. 16-bit Access Authorization and 16-bit Payload Protection
For TCP Stealth with payload authentication, 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 February 16, 2015 [Page 5]
Internet-Draft TCP Stealth August 2014
+---------------+------------------------+--------------------------+
| | 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. Integraton 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 authenticated. Similarly, for the
Kirsch, et al. Expires February 16, 2015 [Page 6]
Internet-Draft TCP Stealth August 2014
TCP server it MUST be possible to set the shared secret and the
expected number of authenticated 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. 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.
8. IANA Considerations
None.
9. Security Considerations
Implementations using a predictable shared secret and predictable
values for the TCP timestamp (if present) 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).
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.
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.
10. References
10.1. Normative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
Kirsch, et al. Expires February 16, 2015 [Page 7]
Internet-Draft TCP Stealth August 2014
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 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.
10.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 Munich
Free Secure Network Systems Group
Lehrstuhl fuer Netzarchitekturen und Netzdienste
Boltzmannstrasse 3
Technische Universitaet Muenchen
Garching bei Muenchen, Bayern D-85748
DE
Email: kirschju@sec.in.tum.de
Christian Grothoff
TU Munich
Free Secure Network Systems Group
Lehrstuhl fuer Netzarchitekturen und Netzdienste
Boltzmannstrasse 3
Technische Universitaet Muenchen
Garching bei Muenchen, Bayern D-85748
DE
Email: christian@grothoff.org
Kirsch, et al. Expires February 16, 2015 [Page 8]
Internet-Draft TCP Stealth August 2014
Jacob Appelbaum
Tor Project Inc.
Email: jacob@appelbaum.net
Holger Kenn (editor)
Microsoft Deutschland GmbH
Konrad Zuse Strasse 1
Unterschleissheim D-85716
DE
Email: holger.kenn@ieee.org
Kirsch, et al. Expires February 16, 2015 [Page 9]