[Cryptography] [cryptography] WG Review: TCP Increased Security (tcpinc)

[Natanael]

On Mon, Jun 9, 2014 at 7:35 PM, ianG <iang at iang.org> wrote:

> -------- Original Message --------
> Subject: [Tcpcrypt] WG Review: TCP Increased Security (tcpinc)
> Date: Thu, 05 Jun 2014 14:31:12 -0700
> From: The IESG <iesg-secretary at ietf.org>
> To: IETF-Announce <ietf-announce at ietf.org>
> CC: tcpinc WG <tcpcrypt at ietf.org>
>
> A new IETF working group has been proposed in the Transport Area. The
> IESG has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2014-06-15.
>
> TCP Increased Security (tcpinc)
> ------------------------------------------------
> Current Status: Proposed WG

[...]

> Charter:
>
> 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.

[...]

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

[...]

> - 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 the case for a cleartext
>   session.

[...]

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

I've thought of something similar to this when tcpcrypt was new and I
was reading up about Monkeysphere (OpenPGP based Web of Trust
authentication, right now hooked into SSH). I finally wrote up my
thoughts about it in a blog post, and I've just edited it to add some
more thoughts relevant to this. This is very high-level, but could
maybe still be useful;

http://roamingaroundatrandom.wordpress.com/2014/06/06/basic-blueprint-for-a-link-encryption-protocol-with-modular-authentication/

The short summary: what you need to authenticate a link encryption is
a session ID that can be derived from some session specific data, such
as the key generated in the key exchange. The session ID must be
globally unique and unpredictable to any third party. Authentication
would be done by comparing the session ID.

My blog post describes the basic idea of an authentication manager
that supports arbitary authentication modules, where each application
choses which modules to use and for which connection. The
authentication manager would use a specific API to interact with the
link layer encryption, allowing you to create "wrappers" for various
types of link encryption protocols as long as they are capable of
providing sufficient security. It is the authentication modules that
deals with exactly how to compare the session ID, verify the identity
of the other party and the conditions for when to consider the
connection authenticated.