Skip to main content

TCP Increased Security
charter-ietf-tcpinc-00-00

The information below is for an older proposed charter
Document Proposed charter TCP Increased Security WG (tcpinc) Snapshot
Title TCP Increased Security
Last updated 2014-05-21
State Start Chartering/Rechartering (Internal Steering Group/IAB Review)
WG State Proposed
IESG Responsible AD Mirja Kühlewind
Charter edit AD Martin Stiemerling
Send notices to marcelo@it.uc3m.es

charter-ietf-tcpinc-00-00

The TCPINC WG will develop the TCP extensions to provide unauthenticated
encryption and integrity protection of TCP streams. The WG will define an
unauthenticated key exchange mechanism. In addition, the WG will define the
TCP extensions to utilize unauthenticated keys, resulting in encryption and
integrity protection without authentication. This is better than plain-text
because it thwarts passive eavesdropping, but is weaker than using
authenticated keys, because it is vulnerable to man-in-the-middle attacks
during the initial unathenticated key exchange. This work is part of the IETF
effort to harness the Internet architecture given the latest events of
pervasive monitoring (see BCP 188).

The goal of this WG is to provide an additional security tool that complements
existing protocols at other layers in the stack. The WG will be looking for the
designs that find the right tradeoff spot between conflicting requirements: to
provide reasonable security for the majority of connections. Because we are
dealing with unprotected connections, we are more focussed on improving from
baseline of no security than achieving the high standard of security that is
already available to users of TLS. Providing unauthenticated
encryption and integrity protection at the TCP layer will provide a set of
features that cannot be achieved with existing tools, namely, encryption and
integrity protection without modifications to the upper ayers (no API changes),
encryption and integrity protection with forward secrecy with a per-connection
granularity, simple NAT and firewall traversal capabilities, key rollover without
significant impact to the TCP connection, lower overhead compared to solutions
relying in stacking multiple protocols to achieve different features, no manual
configuration required. A more detailed description of the motivations for
TCP-based solutions can be found in draft-bellovin-tcpsec-01 and in RFC5925.

The working group is looking to produce experimental documents specifying the
required TCP extensions and any additional documents needed.

The high-level requirements for the protocol for providing TCP unauthenticated
encryption and integrity protection are:

  • It should work over the vast majority of paths that unmodified TCP works over,
    in particular it must be compatible with NATs (at the very minimum with the NATs
    that comply with BEHAVE requirements as documented in RFC4787, RFC5382 and RFC5508);

  • The protocol must be usable by unmodified applications. This effort is
    complementary to other security protocols developed in the IETF (such as TLS) as
    it protects those applications and protocols that are difficult to change or may
    even not be changed in a backward compatible way. It also provides some protection
    in scenarios where people are unwilling to do any change just for the sake of
    security (e.g., like configure encryption in an application).

  • The protocol must provide cryptographic algorithm agility.

  • Must gracefully fall-back to TCP if the remote peer does not support the
    proposed extensions

  • When encryption is enabled, it must at least provide protection against
    passive eavesdropping by default,

  • Should attempt to use the least amount of TCP option space, especially in SYN
    segments.

  • Must not require any authentication or configuration from
    applications or users. However, hooks for external authentication must be
    made available. The WG will not work on new authentication mechanisms.

  • The protocol must have acceptable performance, including acceptable latency and
    processing overheads. For example, the protocol may try to re-use existing
    cryptographic material for future communication between the same endpoints to avoid
    expensive public key operations on connection set up.

When encryption is enabled, then the protocol:

  • must always provide forward secrecy.

  • must always provide integrity protection of the payload data (it is open for
    discussion for the WG if the TCP header should or not be protected)

  • must always provide payload encryption.

  • must not provide extra linkability. When encryption is enabled the TCP traffic should
    not give a third party observer any extra way to associate those packets with the
    specific peers beyond information that would have been present in a cleartext session.

  • must allow the initiator of the connection to avoid fingerprinting: some initiators
    may want to avoid appearing as the same endpoint when connecting to a remote peer on
    subsequent occasions. This should either be the default or some mechanism should be
    available for initiators to drop or ignore shared state to avoid being fingerprintable
    any more than would be present for a cleartext session.

Security features at the TCP-level can benefit other TCP extensions. For
example, both Multipath TCP and TCP Fast Open require proof that some connections are
related. Session resumption and Message Authentication Codes (MACs) can provide
this evidence. The working group should identify synergies and design the
security protocol in such a way that other TCP efforts can benefit from it. Of
course, TCP extensions that break must be identified too, and kept to a minimum.

The working group will produce the following documents:

  • A framework for unauthenticated encryption and integrity protection of TCP connections.
    This document will describe basic design considerations, including the motivation and the
    applicability of the proposed mechanism, the interaction with other security mechanisms in
    different layers of the stack, the interaction with external authentication mechanisms, the
    expected protection, privacy considerations and residual threats.

  • Definition of the unauthenticated key exchange mechanism and the extensions to current TCP
    to utilize unauthenticated key to provide encryption and integrity protection. This covers
    all the protocol changes required. This will be an experimental document.

  • An extended API describing how applications can obtain further benefits of the
    proposed extensions. In particular, the hooks for supporting external authentication
    will be defined in this document. This will be an informational document.