* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Tcpinc Status Pages

TCP Increased Security (Concluded WG)
Tsv Area: Zaheduzzaman Sarker, Martin Duke | 2014-Jun-30 — 2019-Jun-05 

2019-03-27 charter

TCP Increased Security (tcpinc)


 Current Status: Active

     David L. Black <david.black@dell.com>
     Kyle Rose <krose@krose.org>

 Transport Area Directors:
     Mirja K├╝hlewind <ietf@kuehlewind.net>
     Magnus Westerlund <magnus.westerlund@ericsson.com>

 Transport Area Advisor:
     Mirja K├╝hlewind <ietf@kuehlewind.net>

 Tech Advisor:
     Stephen Farrell <stephen.farrell@cs.tcd.ie>

 Mailing Lists:
     General Discussion: tcpinc@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/tcpinc
     Archive:            https://mailarchive.ietf.org/arch/browse/tcpinc/

Description of Working Group:

  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 unauthenticated 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

  - 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 a result 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.

Goals and Milestones:
  Done     - Adopt first WG document on unauthenticated key exchange mechanism and extensions to current TCP
  Done     - Adpot first WG document on extended API
  Done     - Submit unauthenticated key exchange mechanism and extensions to current TCP to IESG for publication as Experimental
  Jan 2017 - Submit extended API to IESG as Informational

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/tcpinc/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -