[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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


   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

   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

   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

   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

   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

   o  the TLS layer encrypts the plain text and adds the TLS record

   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

   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

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            |


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


   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

   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

                          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

   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

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

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

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

9.  Acknowledgements

   This work was partially supported by the FP7-Trilogy2 project.

10.  References

10.1.  Normative References

              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, S., "Security problems in the TCP/IP protocol
              suite", SIGCOMM Comput. Commun. Rev. 19, 2 (April 1989),
              32-48 , April 1989,

              Grigorik, I., "High Performance Browser Networking",
              O'Reilly , 2013,

Bonaventure              Expires April 30, 2015                [Page 19]

Internet-Draft                    MPTLS                     October 2014

              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.

              Bonaventure, O., Paasch, C., and G. Detal, "Processing of
              RST segments by Multipath TCP", draft-bonaventure-mptcp-
              rst-00 (work in progress), July 2014.

              Gont, F., "Survey of Security Hardening Methods for
              Transmission Control Protocol (TCP) Implementations",
              draft-ietf-tcpm-tcp-security-03 (work in progress), March

              Paasch, C. and O. Bonaventure, "MultiPath TCP Low
              Overhead", draft-paasch-mptcp-lowoverhead-00 (work in
              progress), October 2012.

              Paasch, C. and O. Bonaventure, "Securing the MultiPath TCP
              handshake with external keys", draft-paasch-mptcp-ssl-00
              (work in progress), October 2012.

              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.

              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

   [RFC6056]  Larsen, M. and F. Gont, "Recommendations for Transport-
              Protocol Port Randomization", BCP 156, RFC 6056, January

   [RFC6528]  Gont, F. and S. Bellovin, "Defending against Sequence
              Number Attacks", RFC 6528, February 2012.

Author's Address

   Olivier Bonaventure

   Email: Olivier.Bonaventure@uclouvain.be

Bonaventure              Expires April 30, 2015                [Page 21]

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/