From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: tcpinc WG <tcpcrypt@ietf.org>
Subject: WG Review: TCP Increased Security (tcpinc)
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
Technical advisors:
Stephen Farrell <stephen.farrell@cs.tcd.ie>
Assigned Area Director:
Martin Stiemerling <mls.ietf@gmail.com>
Mailing list
Address: tcpcrypt@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/tcpcrypt
Archive: http://www.ietf.org/mail-archive/web/tcpcrypt/
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.
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 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.
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.
Milestones:
TBD
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: tcpinc WG <tcpinc@ietf.org>
Subject: WG Action: Formed TCP Increased Security (tcpinc)
A new IETF working group has been formed in the Transport Area. For
additional information please contact the Area Directors or the WG Chair.
TCP Increased Security (tcpinc)
------------------------------------------------
Current Status: Proposed WG
Chairs:
Marcelo Bagnulo <marcelo@it.uc3m.es>
Technical advisors:
Stephen Farrell <stephen.farrell@cs.tcd.ie>
Assigned Area Director:
Martin Stiemerling <mls.ietf@gmail.com>
Mailing list
Address: tcpinc@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/tcpinc
Archive: http://www.ietf.org/mail-archive/web/tcpinc/
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 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
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 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.
Ballot announcement
Ballot Announcement
Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.
Working Group Summary
Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
particularly rough?
Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type, or other Expert Review,
what was its course (briefly)? In the case of a Media Type
Review, on what date was the request posted?
Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are <TO BE ADDED BY THE AD>.'
RFC Editor Note
(Insert RFC Editor Note here or remove section)
IRTF Note
(Insert IRTF Note here or remove section)
IESG Note
(Insert IESG Note here or remove section)
IANA Note
(Insert IANA Note here or remove section)