Internet DRAFT - draft-bonaventure-mptcp-tls
draft-bonaventure-mptcp-tls
MPTCP Working Group O. Bonaventure
Internet-Draft UCLouvain
Intended status: Experimental October 27, 2014
Expires: April 30, 2015
MPTLS : Making TLS and Multipath TCP stronger together
draft-bonaventure-mptcp-tls-00
Abstract
Multipath TCP and the Transport Layer Security (TLS) include several
techniques that improve the reliability and the security of data
transfers. In this document we propose Multipath TLS (MPTLS), a
tighter coupling between TLS and Multipath TCP that provides improved
security and reliability in the presence of adversaries. MPTLS would
the resilience of existing TLS applications to attacks. It could
also serve as a basis for the TCP extension that is being discussed
within the TCPINC working group to provide unauthenticated encryption
and integrity protection of TCP streams.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Bonaventure Expires April 30, 2015 [Page 1]
Internet-Draft MPTLS October 2014
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Attacks considered . . . . . . . . . . . . . . . . . . . . . 3
3. High-level architecture . . . . . . . . . . . . . . . . . . . 6
4. Required modifications to Multipath TCP . . . . . . . . . . . 8
4.1. The three-way handshake . . . . . . . . . . . . . . . . . 8
4.2. Provision of a message-mode service . . . . . . . . . . . 9
4.3. HMAC authentication . . . . . . . . . . . . . . . . . . . 10
5. Required modifications to TLS . . . . . . . . . . . . . . . . 14
5.1. Modifying the TLS record . . . . . . . . . . . . . . . . 15
5.2. Key derivation . . . . . . . . . . . . . . . . . . . . . 16
6. Interactions with middleboxes . . . . . . . . . . . . . . . . 17
7. Security considerations . . . . . . . . . . . . . . . . . . . 17
7.1. RST injection . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Data injection . . . . . . . . . . . . . . . . . . . . . 18
7.3. Fake TCP acknowledgements . . . . . . . . . . . . . . . . 18
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
Transport Layer Security (TLS) [RFC5246] is an application layer
protocol that allows to encrypt and authenticate the data exchanged
between applications running on different hosts. Various documents
have analysed the security of the TLS protocol from different
viewpoints [I-D.sheffer-uta-tls-attacks]. Over the years, various
extensions to TLS have been developed and deployed. Besides attacks
on the cryptographic algorithms or their implementations, TLS is also
vulnerable to some forms of attacks that affect the underlying TCP
protocol [RFC0793].
TCP, by default, does not include any cryptographic technique to
authenticate/encrypt data. Three types of solutions have been
proposed to improve the security of TCP. A first approach is to tune
the TCP stack to prevent some packet injection attacks. Examples of
this approach may be found in [RFC5927] or [RFC5961]. Another
approach is to add authentication to the TCP protocol. The TCP MD5
option defined in [RFC2385] was the first example of such an
Bonaventure Expires April 30, 2015 [Page 2]
Internet-Draft MPTLS October 2014
approach. The TCP-AO option defined in [RFC5925] and [RFC5926] is a
more recent example. These two solutions were designed to protect
long-lived TCP connections such as BGP sessions from packet injection
attacks. They assume that a secret is shared among the communicating
hosts. A third approach is to extend TCP to include the
cryptographic techniques directly inside the TCP stack
[I-D.bittau-tcp-crypt].
On the other hand, Multipath TCP [RFC6824] is a recent extension to
TCP that allows to use several interfaces (or paths) to transmit the
packets that belong to a single connection. It achieves this by
managing several TCP connections (called subflows) for each Multipath
TCP session. With Multipath TCP, the number of subflows associated
to a given session may change dynamically. This is typically the
case for mobile hosts that change of IP address, but this ability of
Multipath TCP to adapt to changes in the underlying TCP subflows can
also be used to improve the reaction to various packet injection
attacks. Thanks to its ability to manage subflows, Multipath TCP can
cope with various types of attacks and errors that affect the TCP
stack and cannot easily be recovered at the application layer without
implementing a session layer protocol.
In this document, we propose a high level design for Multipath TLS
(MPTLS). Multipath TLS integrates Multipath TCP and TLS together to
provide enhanced security for the applications. This integration can
be beneficial for security sensitive applications that already rely
on TLS. It could also address the requirements of the TCP extension
being developed within the TCPINC working group.
This document is organised as follows. Section Section 2 describes
the attacks that can affect TCP or TLS. Section Section 3 provides a
high-level overview of the proposed architecture. Section Section 4
describes the required changes to the Multipath TCP protocol while
section Section 5 explains the proposed modifications to the TLS
protocol. Section Section 6 discusses the interactions with
middleboxes and section Section 7 the security considerations.
2. Attacks considered
Any security protocol must be designed with the set of attacks that
need to be prevented in mind. For this work, we consider three
different types of attackers :
o a completely off-path attacker that cannot capture any of the
packets exchanged by the communicating hosts but is able to inject
spoofed packets. We call this attacker the off-path attacker.
Bonaventure Expires April 30, 2015 [Page 3]
Internet-Draft MPTLS October 2014
o an attacker that sits on (at least one of ) the paths used to
exchange packets between the communicating hosts at the beginning
of the connection but later moves away from this path. We assume
that this attacker is able to capture the packets exchanged and
send spoofed packets but cannot modify the packets sent by the
communicating hosts. We call this attack the partially on-path
attacker.
o an attacker that is always on the path between the communicating
hosts. This attacker is able to capture the packets exchanged by
the communicating hosts and modify them. We call this attacker
the on-path attacker. This attacker could also be a middlebox
that sits on one of the paths used by the communicating hosts.
The off-path attacker is the simplest type of attacker in our
taxonomy. This attacker can inject spoofed packets inside existing
TCP connections. To inject a packet so that it is accepted inside an
existing TCP connection, the attacker needs to guess the IP addresses
of the communicating hosts, the port numbers (one is usually well-
known) and sequence numbers and acknowledgements that fit inside the
receive window. Several techniques have been defined
[RFC6528],[RFC6056], [RFC5961], [Bellovin] to cope with such attacks
and some have been implemented [I-D.ietf-tcpm-tcp-security]. The
off-path attacker can try to inject either packets containing data or
control packets (i.e. packets carrying the RST or the FIN flags).
For both control and data packet injection attacks, a successful
attack results in the termination of the affected TCP connection.
Multipath TCP is by design less vulnerable than regular TCP to such
attacks since it uses 64 bits data sequence numbers. It should be
noted that the utilisation of TLS on a TCP connection does not
increase its reaction against this form of attack. If the underlying
TCP connection is reset due to an off-path attack, the TLS session is
reset as well. The standard solution to cope with these off-path
attacks is to authenticate the packets that are exchanged at either
the TCP or the IP layer. The TCP-MD5 option, defined in [RFC2385],
allows to authenticate the packets exchanged by the communicating
hosts. This prevents the packet injection attacks discussed above
since the receiving host can verify the validity of all received
packets and easily reject those sent by the attacker. The recently
proposed TCP-AO option [RFC5925] generalises this technique by
allowing different types of hash functions and supporting key
rollover techniques. Unfortunately, both TCP-MD5 and TCP-AO suffer
from an important drawback. They assume that the communicating hosts
have a shared secret. This shared secret is required because both
techniques aim at authenticating all packets including the initial
packets of the three-way handshake. While TCP-MD5 and TCP-AO can be
used to secure the long-lived TCP connections used by BGP sessions
Bonaventure Expires April 30, 2015 [Page 4]
Internet-Draft MPTLS October 2014
between Internet routers, they cannot be easily used to secure
regular Internet traffic. Furthermore, combining TCP-AO with
Multipath TCP would consume a large fraction of the TCP option space
in the packets and would prevent the use of other important TCP
extensions such as TCP-SACK. For these reasons, TCP-AP [RFC5925] is
not a suitable solution.
The second type of attacker that we consider is the on-path attacker.
This is the most powerful attacker. TCP by itself is not protected
against such attackers that can modify the packets exchanged on a TCP
connection. Some of the deployed middleboxes operate like on-path
attackers since they modify the contents of TCP packets. Typical
examples are the NAT devices that change IP addresses and port
numbers. Application Level Gateway running on NATs sometimes also
need to modify the packet payloads or TCP normalisers that re-segment
TCP packets [Normaliser] are other examples. Furthermore, studies
have also shown that some middleboxes may generate packets to
terminate TCP connections for various reasons [RFC3360]. We need to
distinguish two types of attacks from these on-path attackers of
middleboxes :
o attacks that modify the packet payload without terminating the
connection
o attacks where the middlebox terminates the affected TCP connection
The first type of attack is transparent for TCP. TCP does not detect
the attack since the checksum has been modified by the attacker and
delivers the modified payload. Multipath TCP, thanks to its DSS
checksum, can detect a payload modification performed by a middlebox
that understand TCP but not Multipath TCP. In this case, it falls
back to regular TCP to preserve the connectivity between the
communicating hosts. It should be noted that it would be possible to
design a middlebox that modifies the payload of Multipath TCP packets
in a way that cannot be detected by Multipath TCP (e.g. if the
middlebox updates the DSS checksum after having modified the
payload). If the middlebox decides to close the connection by using
regular TCP RST or FIN flags, then Multipath TCP can react by
reestablishing a new subflow (possibly via another path) to preserve
the connection despite of the attack. The ability to manage several
subflows is an important technique that allows Multipath TCP to react
to attacks. While this reaction is effective against currently
deployed TCP middleboxes, it is possible to design Multipath TCP
aware middleboxes that inject specific Multipath TCP packets (e.g. by
using the FAST_CLOSE option whose security relies on the keys
exchanged during the initial handshake) to actively terminate
Multipath TCP connections.
Bonaventure Expires April 30, 2015 [Page 5]
Internet-Draft MPTLS October 2014
On the other hand, TLS uses cryptographic techniques that enable the
secure of keys that allow to authenticate and encrypt the records
exchanged over the (Multipath) TCP connection. With appropriate
cryptographic techniques and a PKI that prevents MITM attacks, it is
possible to negotiate keys through an on-path attacker without
enabling this attacker to derive the security keys. These security
keys can then be used to authenticate and encrypt the records that
are exchanged. Unfortunately, while the current TLS specification
and implementations verify the authenticity of the received records
from the derived secret keys, they react to an authentication failure
by releasing the underlying TCP connection and alerting the
application. This implies that an on-path attack will result in a
denial of service attack for TLS applications.
3. High-level architecture
At a high level, MPTLS integrated TLS and Multipath TCP together as
shown in the figure below. The application interacts with the TLS
implementation through the existing API without any change. This
ensures the backward compatibility with existing applications.
normal TLS interface
+--------------+
| Modified TLS |
| ^ |
+---|----|-----+
| | message interface
+--\/----------+
|Modified MPTCP|
| |
+--------------+
Figure 1: Simplified architecture
We modify the TLS sublayer and keep in this layer the following
functions that are already part TLS :
o secure handshake and key negotiation
o transmission and reception of the TLS records
o encryption/decryption of the TLS records
The TLS techniques that allow to authenticate TLS records are moved
to the modified Multipath TCP sublayer. For this, we leverage the
recently proposed encrypt-then-mac technique [RFC7366]. This is
motivated by two reasons. First, Multipath TCP already verifies the
Bonaventure Expires April 30, 2015 [Page 6]
Internet-Draft MPTLS October 2014
received data by using its optional DSS checksum. We replace this
checksum with a cryptographic MAC authentication that has strong
security properties. Second, if Multipath TCP receives a TLS record
with an invalid MAC it can simply discard the data and wait for its
retransmission or perhaps terminate the affected TCP subflow and
create a new one to retransmit the data. This is much better from a
security viewpoint than the current approach used by TLS that
terminates the TLS session as soon as a record with an invalid MAC
has been received.
To enable Multipath TCP to correctly compute the MAC of each TLS
record, we modify the interface between TLS and Multipath TCP. While
regular TCP provides a bytestream service to TLS, our modified
Multipath TCP provides a message mode service. With this service,
Multipath TCP transports a sequence of TLS records. All these
records are delivered in sequence (possibly after some
retransmissions by the underlying layer) to the TLS sublayer at the
receiver.
As explained earlier, TLS negotiates the keys that are used to
encrypt and authenticate the TLS records. Multipath TCP also needs
keys to authenticate the establishment of subflows. Instead of
exchanging the Multipath TCP keys in clear as defined in [RFC6824],
we leverage the technique proposed in [RFC5705] that allows to derive
additional keys from the MasterSecret negotiated during the secure
TLS key exchange. The required keys are then passed to Multipath TCP
as proposed in [I-D.paasch-mptcp-ssl] to secure the establishment of
new subflows and also authenticate the transported TLS records. A
drawback of this approach is that the keys required to authenticate
the establishment of subflows are only available at the end of the
TLS key exchange. Thus, this key exchange can only be performed over
the initial subflows.
We modify the service model of Multipath TCP when integrating it with
TLS. Instead of providing a bytestream service, Multipath TCP
provides an (authenticated) message-mode service. Each TLS record is
sent as a single message by Multipath TCP. More precisely, the
following workflow is used :
o the application generates a block of up to 2^14 bytes of plain
text
o the TLS layer encrypts the plain text and adds the TLS record
header
o the TLS layer passes the TLS record to Multipath TCP as a message
Bonaventure Expires April 30, 2015 [Page 7]
Internet-Draft MPTLS October 2014
o Multipath TCP maps the entire TLS record via one DSS option onto a
single subflow, computes the MAC and adds the DSN option
o the corresponding packets are reliably transported through the
network and delivered to the Multipath TCP layer at the
destination
o Once all packets have been correctly received at the destination,
the MAC is verified. If the verification succeeds, the TLS record
(without the authenticated MAC) is passed to the TLS layer that
extracts the record header and decrypts the ciphertext to retrieve
the plaintext and pass it to the application.
Additional details about the required modifications to TLS and
Multipath TCP are discussed in sections Section 5 and Section 4.
4. Required modifications to Multipath TCP
Several modifications are required inside Multipath TCP to integrate
it with TLS as proposed in the previous sections.
The high level solution described above requires some modifications
to Multipath TCP to support the integration of TLS with Multipath TCP
:
o Multipath TCP must be modified to support a message-mode service
(limited to messages of up to 2^16 bytes) instead of the default
bytestream service
o Multipath TCP must be able to utilize the keys generated by TLS to
authenticate the messages through a MAC algorithm and the
establishment of new subflows
o optionally an improved API to enable a better exchange of
information between TLS and Multipath TCP
4.1. The three-way handshake
[RFC6824] uses the three way handshake to negotiate the utilisation
of Multipath TCP through the utilisation of the MP_CAPABLE option and
also to exchange the keys that are used to both identify the
Multipath TCP connection and authenticate the additional subflows.
Since in MPTLS the keys will be provided by TLS, there is no need to
exchange keys during the three way handshake. However, the three-way
handshake is also used to exchange the tokens that identify the
Multipath TCP connection on each host and the initial data sequence
numbers in both directions. To identify the Multipath TCP
Bonaventure Expires April 30, 2015 [Page 8]
Internet-Draft MPTLS October 2014
connection, we place the Sender's token in the MP_CAPABLE option of
the SYN and SYN+ACK segments.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+
| Kind | Length |Subtype|Version|A|B|C|D|E|F|G|H|
+---------------+---------------+-------+-------+---------------+
| Sender's Token (32 bits) |
+---------------------------------------------------------------+
Figure 2: MP_CAPABLE option
This variant of the MP_CAPABLE option is shorter than the MP_CAPABLE
option defined in [RFC6824]. The two could be distinguished by
relying on the length of the MP_CAPABLE option or based on the
version number or one of the bits of the MP_CAPABLE option.
The IDSN of each host should be generated by using the hash function
associated with this version of Multipath TCP as
IDSN=Hash(LocalToken||RemoteToken) where Local Token is the locally
generated token and RemoteToken the token that has been generated by
the remote host. An alternative could be to add a 32 bits random
number in the MP_CAPABLE option and generate the IDSN as proposed in
[I-D.paasch-mptcp-lowoverhead]. However, this solution uses 32 more
bits of options in the SYN segment.
4.2. Provision of a message-mode service
The second important modification to Multipath TCP is to replace its
bytestream service by a message-mode service that is targeted to the
needs of the modified TLS sublayer. To distribute the data over
different subflows, Multipath TCP relies on the Data Sequence Signal
option [RFC6824] whose format is shown below :
Bonaventure Expires April 30, 2015 [Page 9]
Internet-Draft MPTLS October 2014
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+----------------------+
| Kind | Length |Subtype| (reserved) |F|m|M|a|A|
+---------------+---------------+-------+----------------------+
| Data ACK (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
| DSN: Data sequence number (4/8 octets, depending on flags) |
+--------------------------------------------------------------+
| SSN : Subflow Sequence Number (4 octets) |
+-------------------------------+------------------------------+
| Data-Level Length (2 octets) | Checksum (2 octets) |
+-------------------------------+------------------------------+
Figure 3: Data Sequence Signal option
This option allows to map Length bytes from the bytestream of the
Multipath TCP connection starting at data sequence number 'DSN' to
the subflow sequence number 'SSN'. Since the length field is encoded
as a two bytes long unsigned integer, it can be used to map up to
2^16 bytes. This is larger than the maximum size of the TLS
plaintext encoded inside a record (2^14 bytes) [RFC5246]. Even with
expansion, a TLS ciphertext will never become larger than 2^16 bytes.
We cover each TLS record with a single mapping. This implies that a
single TLS record can only be mapped onto one subflow. If the TLS
session is interactive, then short TLS records will be used anyway.
If the TLS session transports a large amount of data, sending entire
records over each subflow should not impact the performance. We note
that some deployments of TLS already dynamically adapt the length of
the TLS records to the activity of the session [Grigorik].
We modify the semantics of the DSS option as follows. First, the
Data-level length becomes the size of the TLS record that is
transported. Given the constraints imposed by [RFC5246], this record
will always be shorter than 2^16 bytes. Second, the DSS checksum is
disabled and replaced by a MAC.
4.3. HMAC authentication
TLS supports a range of authentication techniques that can be
negotiated during the TLS handshake. In this first version of the
document, we assume that TLS has negotiated a keyed HMAC to
authenticate the TLS record. Subsequent versions of this document
will analyse other record authentication methods such as [RFC5116].
There are several possible design options to transport the computed
HMAC.
Bonaventure Expires April 30, 2015 [Page 10]
Internet-Draft MPTLS October 2014
At a high level, our objective is to transport the computed HMAC
together with the mapped data. As explained in the previous
subsection, this data will be transported on the same TCP subflow
given that the TLS record is covered by one DSS mapping. These three
blocks of information can be transported either as
+------------+--------------+-------------------------+
| DSS | HMAC | TLS record |
+------------+--------------+-------------------------+
or
+------------+-------------------------+--------------+
| DSS | TLS record | HMAC |
+------------+-------------------------+--------------+
Sending the HMAC before the TLS record could simplify the processing
at the receiver, but would force the sender to compute the entire
HMAC before transmitting the TLS record. On the other hand, by
sending the HMAC after the TLS record, we could enable hardware
accelerators to both encrypt the TLS record and compute the HMAC on
the fly while transmitting the data.
At this stage, it is too early to opt for one encoding over the
other, even if supporting both would create a too complex protocol.
The second design question is how to encode the HMAC. Again, several
options are possible.
A first approach would be to rely on the TCP-AO option [RFC5925] and
modify it so that it can authenticate all the data covered by the DSS
mapping. However, using another (long) TCP option would consume
space in the limited TCP option space. Furthermore, TCP-AO was
designed with the assumption that each TCP-AO option covers a single
TCP segment. Thus, there might be middleboxes that rely on this
assumption to accept/reject packets. Modifying the TCP-AO option
would likely result in difficulties with some middelboxes.
A second approach is to place the length of the HMAC inside the DSS
option, e.g. as a single byte that follows the Data-Level length
field. This allows to support various HMAC lengths, including
truncated HMAC [RFC6066].
A third approach is to encode the HMAC as a variable length option
using the same format as the TCP options, but transport this
Bonaventure Expires April 30, 2015 [Page 11]
Internet-Draft MPTLS October 2014
information inside the DSS payload, before or after the TLS record
that contains the real data. The variable-length TCP options are
encoded in [RFC0793] as :
<Kind><Length><Option>
Where Kind and Length are encoded as a single byte. This limits the
length of each option at 255 bytes, which is large enough to carry a
HMAC. Option Kind=0 defined in [RFC0793] is a special option that
does not contain a length information and is used to indicate the end
of the option list. The HMAC option would always be transmitted
before the TLS record and the null option would terminate the list of
options.
The simplest solution appears to be the second approach and sending
the HMAC before the TLS record. Since the TLS keys can change during
the lifetime of a TLS sessions, MPTLS needs to indicate which key has
been used to compute an HMAC. This problem can be solved by
associating a key identifier to the keys that are passed by TLS to
Multipath TCP and place this key identifier inside the DSS option.
The figure below provides the structure of the DSS option used by
MPTLS.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+----------------------+
| Kind | Length |Subtype| (reserved) |F|m|M|a|A|
+---------------+---------------+-------+----------------------+
| Data ACK (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
| DSN: Data sequence number (4/8 octets, depending on flags) |
+--------------------------------------------------------------+
| SSN : Subflow Sequence Number (4 octets) |
+-------------------------------+------------------------------+
| Data-Level Length (2 octets) | MAC Length | Key Id. |
+-------------------------------+------------------------------+
Figure 4: MPTLS Data Sequence Signal option
The semantics of the last two fields of this modified DSS option is
the following.
o 'MAC Length' is an 8 bits unsigned integer that specifies the
length of the HMAC that follows the DSS option, i.e. the HMAC
starts at subflow sequence number 'SSN' and ends at
'SSN+MACLength-1'. A length of 0 indicates that no HMAC has been
computed for the TLS record.
Bonaventure Expires April 30, 2015 [Page 12]
Internet-Draft MPTLS October 2014
o 'Key Identifier' is an 8 bits unsigned integer that indicates the
key that was used to compute the attached HMAC. When a TLS
session starts, the key identifier is set to zero. It is
incremented by one after each renegotiation of the keys. Using
key identifiers allows an MPTLS implementation to verify the
validate of TLS records that have been generated by using
different keys.
The last point to be discussed about the HMAC and the modified DSS
option is the data that is covered by the HMAC. MPTLS uses the HMAC
to authenticate both the TLS record, i.e. the payload mapped by the
DSS, and the DSS option itself. This implies that any modification
to one of the fields of the DSS option or to the data part would be
detected by the HMAC. It should be noted that in contrast with TCP-
AO, MPTLS does not protect the TCP header fields. This choice is
motivated by the fact that various middleboxes modify IP and TCP
fields, notably the IP addresses, the TCP port numbers, the sequence
and acknowledgement numbers. Including these fields in the MPTLS
HMAC would prevent any communication through such middleboxes.
The HMAC should also be used to authenticate the following Multipath
TCP options that may be exchanged during a Multipath TCP connection :
o ADD_ADDR2 : This option must be authenticated with a HMAC
[I-D.ietf-mptcp-rfc6824bis]. If replay attacks inside a single
connection are concern, then the option needs to be updated to
include a valid data-level sequence number and a valid data level
ack
o REMOVE_ADDR : This option must be authenticated with a HMAC. The
above comment applies if replay attacks are a concern.
o MP_PRIO : This option must be authenticated with a HMAC. The
above comment applies if replay attacks are a concern.
o MP_FASTCLOSE : This option must be authenticated with a HMAC. The
current version defined in [RFC6824] includes the key negotiated
during the three-way exchange. Placing the MAC key generated by
TLS in this option would not be appropriate. A possible solution
would be to place the Initial Data Sequence number inside the
FAST_CLOSE option and authenticate this number via the HMAC.
o MP_FAIL : This option is used to perform a fallback to regular TCP
when middlebox interference has been observed. When MPTCP is used
together with TLS, this mechanism should never be triggered and a
host should silently ignore any MP_FAIL option that it receives.
Bonaventure Expires April 30, 2015 [Page 13]
Internet-Draft MPTLS October 2014
The processing of data on a receiving host is slightly modified
compared to regular TCP. In Multipath TCP version 1, as defined in
[RFC6824], two levels of acknowledgements are used. With MPTLS, data
remains acknowledged at the subflow level as soon as it has been
received. Selective acknowledgements [RFC2018] can be negotiated to
provide additional information about out-of-sequence data at the
subflow level.
With MPTLS, data can only be acknowledged at the Data-Sequence level
(i.e. through the Data ack field of the DSS option) once it has been
received in sequence and the HMAC that authenticates the received TLS
record has been validated. If the HMAC authentication fails for one
received TLS record, then the corresponding subflow should be
terminated with a reason code [I-D.bonaventure-mptcp-rst] that
indicates an authentication failure. The TLS record will then be
retransmitted over another available subflow or a new subflow will be
established to transmit this record. This mode of operation allows
Multipath TCP to cope with various types of packet injection attacks
without breaking the connection and affecting the TLS layer or the
application.
5. Required modifications to TLS
Multipath TCP can be completely transparent to the application since
it provides the same socket interface as regular TCP. On the other
hand, TLS is a record oriented protocol. Data is encoded in records
that are reliably exchanged over the underlying TCP connection. TLS
defines two types of records :
o the control records that are used to exchange control information
such as the secure handshake messages that negotiate the
cryptographic parameters and keys
o the data records that transport encrypted and authenticated data
These two types of records have a variable length and are encoded by
using a TLV format specified in [RFC5246]. The TLS protocol defines
several types of data records depending on the type of encryption
scheme that is used. Current TLS implementations apply a MAC-then-
Encrypt approach to transmit data [RFC5246]. This implies that each
data record, is first authenticated, e.g. by using a negotiated HMAC
algorithm, then the authenticated record is encrypted. Several
cryptographers have argued about several security problems with this
approach there are ongoing discussions to use Encrypt-then-MAC for
the data record [RFC7366]. This technique has better security
properties and we build upon it to integrate TLS and Multipath TCP
together.
Bonaventure Expires April 30, 2015 [Page 14]
Internet-Draft MPTLS October 2014
At a high level, an MPTLS connection starts like a regular Multipath
TCP connection. The Multipath TCP connection starts with a three-way
handshake using the MP_CAPABLE option to negotiate the utilisation of
Multipath TCP and exchange the tokens as explained in section
Section 4.
Once the three-way handshake has finished, the bytestream is
established and TLS can start its key negotiation. All the crypto
mechanisms defined in [RFC5246] can be used to negotiate the crypto
parameters and keys. In contrast with TCP-AO, this crypto
negotiation is performed over an unprotected bytestream as when TLS
is used over single-path TCP. In particular, no HMAC is included in
the DSS option defined in the previous section.
TLS uses the client_write_MAC_key and server_write_MAC_key to
authenticate the data records. We build upon the encrypt-then-mac
principle [RFC7366] and place the encryption/decryption function in
the TLS layer and the authentication function inside Multipath TCP.
As in AEAD algorithms [RFC5116], we assume that two different keys
are used for the encryption and the authentication. The encryption
keys are generated and stored in the TLS layer. The authentication
keys are generated in the TLS layer by using the PRF described in
[RFC5246] or through the procedure defined in [RFC5705].
This part of the document describes in more details the modifications
to TLS that are required to better integrate with Multipath TCP. The
key issues that need to be discussed here are :
o the new format for the TLS records
o the derivation of the keys that are used by TLS and Multipath TCP
o the interactions between TLS and Multipath TCP
5.1. Modifying the TLS record
[RFC7366] defines a TLS record as being composed of :
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
GenericBlockCipher fragment;
opaque MAC;
} TLSCiphertext;
Although the length field of this record is encoded as a 16 bits
integer, TLS limits the record size to 2^14 bytes at most. Since
Bonaventure Expires April 30, 2015 [Page 15]
Internet-Draft MPTLS October 2014
MPTLS performs the authentication outside of the TLS record, we need
to remove the opaque MAC from the structure of the TLS record. With
regular TCP, this record format enables the receiver to retrieve the
record boundaries and extract it from the bytestream. In MPTLS, this
feature is not required since it provides a message mode service that
delivers entire TLS records. For this reason, we also remove the
length information from the TLS record. Note that this implies that
it will be impossible for MPTLS to fallback to regular TCP if
middlebox interference is detected. The modified TLS record becomes
:
struct {
ContentType type;
ProtocolVersion version;
GenericBlockCipher fragment;
} MPTCP_TLSCiphertext;
5.2. Key derivation
MPTLS needs to derive more keys than when it is used over regular
TCP. Once the TLS handshake has succeeded, the crypto parameters and
keys are known by the two communicating hosts. In TLS, [RFC5246],
six keys are derived from the Master key :
o client_write_MAC_key[SecurityParameters.mac_key_length]
o server_write_MAC_key[SecurityParameters.mac_key_length]
o client_write_key[SecurityParameters.enc_key_length]
o server_write_key[SecurityParameters.enc_key_length]
o client_write_IV[SecurityParameters.fixed_iv_length]
o server_write_IV[SecurityParameters.fixed_iv_length]
The last two keys are only used with some specific crypto algorithms.
We leverage [RFC5705] to derive two additional keys :
o client_write_MPTCP_key[SecurityParameters.mac_key_length]
o server_write_MPTCP_key[SecurityParameters.mac_key_length]
The *write_MAC_key and *_write_MPTCP_key keys are derived by TLS and
immediately passed to the Multipath TCP sublayer by using a similar
technique as [I-D.paasch-mptcp-ssl]. The *write_MAC_key keys are
used to authenticate the TLS records while the *_write_MPTCP_key keys
are used to authenticate the establishment of subflows.
Bonaventure Expires April 30, 2015 [Page 16]
Internet-Draft MPTLS October 2014
It should be noted that the key derivation technique used by TLS
requires a distinction between the active opener (i.e. the client)
and the passive opener (i.e. the server). For most MPTLS connections
it is easy to determine the role of each communicating host.
However, in the case of a simultaneous establishment of the Multipath
TCP connection, we need a tiebreak to determine which host acts as
the client and which host acts as the server. We propose to use the
Tokens and the random number exchanged in the MP_CAPABLE option. By
convention, the client will be the host that proposed the smallest
[token] in the MP_CAPABLE option and the server the other one. In
the unlikely case that both hosts propose the same token, then we
rely on the IP addresses of the two hosts. These addresses are
unique and the client is the host that has the numerically smallest
address. It should be noted that this solution does not work if
there is a NAT on the path between the two communicating hosts that
changes (one of) the IP addresses. However, it is unlikely that a
simultaneous establishment of a TCP connection will be possible
through a NAT anyway. Adding complexity to handle this unlikely
scenario (same token pair and NAT) does not seem to be necessary.
6. Interactions with middleboxes
In this document, we assume that there are no middleboxes that
modify, split or reassemble packets and/or options. A subsequent
version of this document will discuss how such middleboxes could be
handled.
7. Security considerations
Various TCP attacks have been documented in the literature. In this
section, we discuss some of these attacks and analyze how they affect
our proposed TLS above Multipath TCP. A more detailed version of
this section will be provided in the next version of this document.
7.1. RST injection
A first attack is the injection of a RST segment in an existing TCP
connection. Such RST segments can be injected by middleboxes as
described [RFC3360]. There have also been documented attacks against
very long-lived TCP connections (typically BGP sessions) where an
attacker sends spoofed RST segments. Several techniques have been
proposed to mitigate this attack [RFC4953].
If an off-path attacker sends a spoofed RST segment, it could
terminate the corresponding TCP connection. For regular TCP, this
attack would cause a denial of service. However, since our solution
builds upon Multipath TCP, this attack is less severe. If an
attacker is able to inject a RST segment on an established subflow,
Bonaventure Expires April 30, 2015 [Page 17]
Internet-Draft MPTLS October 2014
this subflow will be terminated. This will not cause the termination
of the Multipath TCP connection and thus will not affect the
application. Multipath TCP can be configured to reestablish the
subflow when a RST segment is received without a FAST_CLOSE.
An on-path attacker such as a middlebox as discussed in [RFC3360] can
send a spoofed RST segment that would pass the mitigations described
in [RFC4953]. However, such an attacker cannot know the keys that
are used to authenticate the subflows and the TLS records. Thus, the
only attack that such attacker could carry is inserting RST or FIN
segments in one of the subflows. MPTLS will react to such attacks by
reestablishing a new subflow.
7.2. Data injection
An attacker can also inject TCP segments containing an invalid TLS
record in one of the TCP subflows. Given that the TLS record is
protected by an HMAC computed with keys that are negotiated during
the secure TLS handshake, the attacker, cannot inject a valid TLS
record in the connection even if the attacker can predict the
sequence numbers, acknowledgements, Data Sequence Number and Data
acknowledgements that are verified by Multipath TCP. When a receiver
detects an invalid HMAC, it discards the associated TLS record and
terminates the associated TCP subflow. This will slowdown the data
transfer but would not affect the reliability of the data transfer.
7.3. Fake TCP acknowledgements
An attacker can inject fake TCP acknowledgements at the subflow level
but not that the DSS level given that the DSS-level acknowledgements
are protected by the HMAC. Such an attack could force the
retransmission of already transmitted data at the subflow level.
8. Conclusion
In this document, we have proposed the main design principles of
MPTLS : a tighter integration between Multipath TCP and Transport
Layer Security (TLS). By leveraging the best characteristics of each
protocol, MPTLS provides better security and reliability than by
considering Multipath TCP and TLS as isolated protocols.
MPTLS would be useful for two different types of applications.
First, it would be beneficial for all the existing applications that
rely on TLS, even if they are used on single-homed devices. Second,
MPTLS could serve as a basis for the TCP extension that is being
discussed within the TCPINC working group to provide unauthenticated
encryption and integrity protection of TCP streams. These two use
Bonaventure Expires April 30, 2015 [Page 18]
Internet-Draft MPTLS October 2014
cases will be discussed in more details in the next versions of this
draft.
9. Acknowledgements
This work was partially supported by the FP7-Trilogy2 project.
10. References
10.1. Normative References
[I-D.ietf-mptcp-rfc6824bis]
Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", draft-ietf-mptcp-rfc6824bis-02 (work in
progress), January 2014.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013.
[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", RFC 7366, September 2014.
10.2. Informative References
[Bellovin]
Bellovin, S., "Security problems in the TCP/IP protocol
suite", SIGCOMM Comput. Commun. Rev. 19, 2 (April 1989),
32-48 , April 1989,
<http://doi.acm.org/10.1145/378444.378449>.
[Grigorik]
Grigorik, I., "High Performance Browser Networking",
O'Reilly , 2013,
<http://chimera.labs.oreilly.com/books/1230000000545>.
Bonaventure Expires April 30, 2015 [Page 19]
Internet-Draft MPTLS October 2014
[I-D.bittau-tcp-crypt]
Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres,
D., and Q. Slack, "Cryptographic protection of TCP Streams
(tcpcrypt)", draft-bittau-tcp-crypt-04 (work in progress),
February 2014.
[I-D.bonaventure-mptcp-rst]
Bonaventure, O., Paasch, C., and G. Detal, "Processing of
RST segments by Multipath TCP", draft-bonaventure-mptcp-
rst-00 (work in progress), July 2014.
[I-D.ietf-tcpm-tcp-security]
Gont, F., "Survey of Security Hardening Methods for
Transmission Control Protocol (TCP) Implementations",
draft-ietf-tcpm-tcp-security-03 (work in progress), March
2012.
[I-D.paasch-mptcp-lowoverhead]
Paasch, C. and O. Bonaventure, "MultiPath TCP Low
Overhead", draft-paasch-mptcp-lowoverhead-00 (work in
progress), October 2012.
[I-D.paasch-mptcp-ssl]
Paasch, C. and O. Bonaventure, "Securing the MultiPath TCP
handshake with external keys", draft-paasch-mptcp-ssl-00
(work in progress), October 2012.
[I-D.sheffer-uta-tls-attacks]
Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Current Attacks on TLS and DTLS", draft-sheffer-uta-tls-
attacks-00 (work in progress), February 2014.
[Normaliser]
Kreibich, C., Handley, M., and V. Paxson, "Network
intrusion detection Evasion, traffic normalization, and
end-to-end protocol semantics", Proc. USENIX Security
Symposium , 2001.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
Bonaventure Expires April 30, 2015 [Page 20]
Internet-Draft MPTLS October 2014
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful",
BCP 60, RFC 3360, August 2002.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC
4953, July 2007.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
for the TCP Authentication Option (TCP-AO)", RFC 5926,
June 2010.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961, August
2010.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, January
2011.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, February 2012.
Author's Address
Olivier Bonaventure
UCLouvain
Email: Olivier.Bonaventure@uclouvain.be
Bonaventure Expires April 30, 2015 [Page 21]
