TCP Stealth
draft-kirsch-ietf-tcp-stealth-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2014-08-14
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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]