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 :