]> UCLouvain

matthieu.baerts@uclouvain.be

UCLouvain & WELRI

olivier.bonaventure@uclouvain.be

Transport TCPM mptcp This document proposes an extension to Multipath TCP that allows application layer protocols such as TLS or SSH to provide keys to authenticate the creation of new subflows. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the TCPM Individual mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document addresses an important limitation of Multipath TCP : the exchange of plain text keys during the handshake. From a security viewpoint, Multipath TCP is vulnerable to on-path attacks . Since Multipath TCP relies on keys that are exchanged in clear during the handshake, an on-path attacker can easily collect the authentication keys and later establish a subflow on an existing Multipath TCP connection. If this connection is used to support secure protocols such as TLS or SSH , the attacker will only be able to disrupt the connection. This document proposes a modification to the MP_CAPABLE and MP_JOIN options that enables Multipath TCP hosts to use keys that are derived by upper layer protocols such as TLS or SSH. This idea has already been discussed in the past , and . We provide an overview of this extension in and describe the protocol modifications in .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Protocol overview This document proposes an extension that allows Multipath TCP to use either a pre-configured key or a key derived by an upper layer security protocol to authenticate the advertisement of additional addresses, the establishment of new subflows, and the abrupt closure of a whole connection. This extension is negotiated during the establishment of the Multipath TCP connection by setting the TBD bit in the MP_CAPABLE option. This is illustrated in .

Negotiation of the utilization of external keys [flags (TBD is set)] <- MP_CAPABLE [B's token, flags (TBD is set)] ACK + MP_CAPABLE (+ data) -> [A's token, B's token, flags, (data-level details)] ]]>

If the TBD flag is set and the responder supports the option, it returns an MP_CAPABLE that contains the 32-bit token that it uses to identify this connection. The connection initiator replies with an MP_CAPABLE option containing its 32-bit token and the remote 32-bit token. This modification has two important advantages compared to Multipath TCP version 1 . First, the MP_CAPABLE option is shorter. It contains only two 32-bit tokens instead of two 64-bit keys in the third ACK. Second, the token is not derived from a random key using a hash function. This implies that there is no risk of collision between a new key and a token used for an existing connection. The token must uniquely identify the associated connection and should be selected randomly . After the handshake, host A and host B cannot create additional subflows or exchange additional addresses. These operations can only occur once they have agreed on an external key. Once a host has learned an external key (e.g. through configuration, socket option, or derived from a security protocol), it SHOULD inform the other by sending a hash of this key in a NEW_KEY option a shown in . The key is installed once a host has received a hash of the key from the other host. Security protocols need to change keys regularly for security reasons. Multipath TCP version 1 does not support changing the security keys. This extension uses a key identifier to support key changes. All authenticated options contain the K bit which is the identifier of the key used to authenticate it. The initial external key corresponds to identifier 0.

Confirmation of the utilization of a new external key <- NEW_KEY[K,hash(ExtKey)] ]]>

The key identifier is included in the modified ADD_ADDR, MP_JOIN and FASTCLOSE options described later in this document.

Changes to Multipath TCP This section describes the changes to the Multipath TCP options that are required to support external keys.

Extending the MP_CAPABLE and MP_JOIN options defines the MP_CAPABLE option as shown in .

The MP_CAPABLE option in RFC8684 4) | | | +---------------------------------------------------------------+ | Option Receiver's Key (64 bits) | | (if option Length > 12) | | | +-------------------------------+-------------------------------+ | Data-Level Length (16 bits) | Checksum (16 bits, optional) | +-------------------------------+-------------------------------+ ]]>

This option contains several flags, A-H. Flags A, B, C, and H are specified in . This document changes the TBD Flag. If this Flag is set in a SYN, this indicates the utilization of external keys. An external key is a key which is either known, e.g. by configuration as a shared secret, or derived from a negotiated secure key, e.g. by protocols such as SSH or TLS. This key is used as an authentication key for the establishment of additional subflows. A Multipath TCP implementation maintains two 64-bit keys:

• a local key chosen by the host and exchanged during the handshake
• a remote key learned during the handshake

As specified in , a local 32-bit token and a remote 32-bit token are derived from these keys. The keys and the token are known at the end of the handshake. When the external keys are used, the situation is different. The connection initiator sends an empty MP_CAPABLE option in its SYN segment. A responder that receives a SYN with the MP_CAPABLE option having the TBD bit set responds with an MP_CAPABLE option and the TBD bit set if it supports the external keys. Otherwise, it replies with an MP_CAPABLE option whose TBD bit is reset and follows the procedure defined in . If the responder replies with an MP_CAPABLE option whose TBD Flag is set, the option in the SYN+ACK contains the 32-bit token that it uses to identify this connection. Upon reception of the SYN+ACK, the connection initiator replies with a third ACK that contains an MP_CAPABLE option with the TBD bit set. This option contains the initiator and the responder tokens.

The modified MP_CAPABLE option 4) | +---------------------------------------------------------------+ | Option Receiver's Token (32 bits) | | (if option Length > 8) | +-------------------------------+-------------------------------+ | Data-Level Length (16 bits) | Checksum (16 bits, optional) | +-------------------------------+-------------------------------+ ]]>

If the TBD bit was set in the MP_CAPABLE option of the SYN+ACK, this indicates that there are no security keys associated with the connection. This implies that it is impossible to advertise addresses or join an additional subflow until external keys have been exchanged.

Changing the external key Once the Multipath TCP connection has been established, the applications can decide to use an external key. Once the hosts have agreed on an external key to use to authenticate the MP_JOIN, ADD_ADDR, and MP_FASTCLOSE options on a connection, they inform the other host by sending a NEW_KEY option. This option is shown in .

The NEW_KEY option

This new option contains two pieces of information:

• a one-bit key identifier (K)
• a 64-bit HMAC of the external key

The key identifier identifies the last key exchanged on a connection. The key identifiers start at 0, i.e. the first NEW_KEY option contains the K bit set to zero. The 64-bit HMAC contains the low order 64 bits of a HMAC of the external key computed using the negotiated hash algorithm. The key for this HMAC, in the case of a message transmitted by Host A, is Token-A followed by Token-B; and in the case of Host B, Key-B followed by Key-A. The "message" for the HMAC algorithm in each case is the external key. Once a host has sent a NEW_KEY option, it SHOULD start a timer. If it does not receive an option containing the same hash value, it should retransmit the option. A host must store two external keys:

• the current one
• the next key

A key is considered to be active once a host has received a NEW_KEY option containing a HMAC of this key. If a host receives a NEW_KEY option whose HMAC and key identifier do not match the stored ones, it simply discards the option.

Using the external key While Multipath TCP version 1 uses two different keys announced by the communicating hosts, the external key is a key shared by both hosts. defined several procedures that rely on these two keys to authenticate the establishment of subflows using the MP_JOIN option, the advertisement for new addresses, or the fast termination of a connection. These procedures change with an external key. The first modification is that these options now contain a K bit that indicates the identifier of the external key used to (request to) authenticate the option. The second modification is that instead of computing HMACs over KeyA||KeyB, the HMACs defined in are now computed using the external key whose identifier is K. The new format of the MP_JOIN option is shown in .

The modified MP_JOIN option

The new format of the ADD_ADDR option is shown in .

The modified ADD_ADDR option

The modified format of the MP_FASTCLOSE option is shown in . This option does no longer contain the receivers' key as in . Instead, it contains a truncated HMAC of the external key. The key for this HMAC is, in the case of a message transmitted by Host A, Token-A followed by Token-B; and in the case of Host B, Token-B followed by Token-A. The "message" for the HMAC algorithm is, in each case, the external key. The K bit indicates the corresponding key identifier. A host can still reset an MPTCP connection before the initial external keys got exchanged, while there is only one subflow then. This SHOULD be done by sending a TCP RST.

The modified MP_FASTCLOSE option

Security Considerations The solution proposed in this document aims at preventing the attacks where an on-path attacker observes the keys associated with a Multipath TCP connection. Since these keys are not exposed anymore, attackers cannot use them to add subflows to an existing Multipath TCP connection.

IANA Considerations This document requests the IANA to reserve flag TBD of the MP_CAPABLE option as defined in this document. It proposes to use the E flag. It also proposes to add the K bit to the MP_JOIN, ADD_ADDR, and MP_FASTCLOSE options. Finally, it defines the NEW_KEY option. Subtype 0x9 is suggested for this option.

References Normative References TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Informative References Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK] UCLouvain UCLouvain Multipath TCP currently relies on the exchange of keys in clear during the initial handshake to authenticate the establishment of additional subflows. This document proposes a variant of the Multipath TCP handshake that allows Multipath TCP to reuse keys negotiated by the Application layer protocol above it such as SSL/TLS to authenticate the establishment of additional subflows. Apple, Inc. Pexip Multipath TCP (MPTCP), described in [3], is an extension to TCP to provide the ability to simultaneously use multiple paths between hosts. MPTCP currently specifies a single authentication mechanism, using keys that are initially exchanged in the clear. There are application-layer protocols that may have better information as to the identity of the parties and so is able to better provide keying material that could be used for the authentication of future subflows. This document specifies "application layer authentication" for Multipath TCP, an alternatively negotiated keying mechanism for MPTCP. Apple, Inc. Pexip Multipath TCP (MPTCP), described in [4], is an extension to TCP to provide the ability to simultaneously use multiple paths between peers. draft-paasch-mptcp-application-authentication specifies "application layer authentication" for Multipath TCP, an alternatively negotiated keying mechanism for MPTCP. This allows keying material to be sourced from an application layer protocol in order to secure MP_JOIN handshakes. This document explains how to use the proposed application-layer authentication extension with TLS [6], in order to leverage securely exchanged keys for MPTCP security, whilst simultaneously freeing the MPTCP token to be used as a channel for additional information.

Acknowledgments This work was supported by the Walloon government within the FRFS-WEL-T SEEIP project. The idea of using external keys to secure Multipath TCP was initially proposed in .