TCP Increased Security
charter-ietf-tcpinc-00-05
Document | Proposed charter | TCP Increased Security WG (tcpinc) Snapshot | |
---|---|---|---|
Title | TCP Increased Security | ||
Last updated | 2014-06-27 | ||
State | IESG Review (Charter for Approval, Selected by Secretariat) | ||
WG | State | Proposed | |
IESG | Responsible AD | Mirja Kühlewind | |
Charter edit AD | Martin Stiemerling | ||
Send notices to | marcelo@it.uc3m.es |
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 evolve 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. This work will
deal with unprotected connections, and therefore will focus more on improvements
from a baseline of no security than on achieving the high standard of security
that is already available to users of authenticated TLS.
Providing unauthenticated encryption and integrity protection at the TCP layer
will provide a set of features that cannot be achieved with existing tools.
Those features include:
- encryption and integrity protection without modifications to the upper layers
(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 will produce documents specifying the required TCP extensions
and 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 able to be changed in a backward compatible way. It also
provides some protection in scenarios where application developers are unwilling
to change their applications (e.g., by configuring encryption) solely for the
sake of improving security. -
The protocol must provide cryptographic algorithm agility.
-
The protocol 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, -
Any required TCP option should use a minimum amount of TCP option space,
especially in SYN segments. -
The protocol 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 should 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 being fingerprinted as aresult of
using the protocol: 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 the
case 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.