Subject: [multipathtcp] Possible issue with MPTCP

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 03 Oct 2013 14:47:34 +0200

Hello,

While discussing about the security of MPTCP, one of our colleagues, 
Olivier Pereira, found an attack scenario for MPTCP that could lead to a 
DoS attack.

The scenario is the following.

C is the client, S the server and A the attacker.

C has created an MPTCP connection with S and the three handshake has 
been done.

C wants to create a second subflow and sends a SYN+MP_JOIN[Rc] to S. 
This MP_JOIN contains a nonce chosen by C.

C -->--- MP_JOIN[Rc] --

The attacker captures the MP_JOIN[Rc]. This MP_JOIN takes some time to 
reach S.

The attacker creates a SYN that contains a copy of the MP_JOIN and sends 
it back to C.

C --- MP_JOIN[Rc] <---- A

The client replies to this MP_JOIN by sending SYN+ACK containing 
MP_JOIN[HMAC(Key=(Ks,Kc), Msg=(Rx||Rc)]

C ---- MP_JOIN[HMAC(Key=(Ks,Kc), Msg=(Rx||Rc)] -- > --- A

The attacker sends a spoofed SYN_ACK packet from S to C containing the 
previous MP_JOIN

C ---- MP_JOIN[HMAC(Key=(Ks,Kc), Msg=(Rx||Rc)] -------< --- S (spoofed)

This MP_JOIN contains a valid HMAC. C accepts the connection 
establishment and replies with its third ack to S. This ack contains 
MP_JOIN[HMAC(Key=Kc,Ks),Msg=(Rc||Rx)]

C--- MP_JOIN[HMAC(Key=Kc,Ks),Msg=(Rc||Rx)] --> --- S

A captures this packet and replays the packet towards C.

C --- MP_JOIN[HMAC(Key=Kc,Ks),Msg=(Rc||Rx)] --<--- A

This terminates the connection establishment for the subflow between C 
and A. C has now two established subflows, the original one and the one 
with A. If S sends its SYN+ACK at this point, the SYN+ACK will contain a 
different random number and it will likely be rejected by C.

The attacker has hijacked the connection. It needs to be able to spoof 
and capture packets. A possible scenario could be a first subflow 
established over a secure 3G network. Then the smartphone moves to an 
unprotected WiFi network and tries to establish an additional subflow 
over this network...

Of course, when regular TCP is used in a network where attackers can 
spoof and capture packets, there is no guarantee in terms of security.

Olivier and Christoph

---

From: Mark Handley <[email-masked]>
Date: Thu, 03 Oct 2013 06:03:15 -0700

Is the solution to this as simple as "don't accept an MP_JOIN with the
same nonce as an MP_JOIN you've got outstanding?"

Mark

On Thu, Oct 3, 2013, at 05:47 AM, Olivier Bonaventure wrote:
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 03 Oct 2013 16:42:48 +0200

> same nonce as an MP_JOIN you've got outstanding?"

This would fix this particular problem. It arises because there is some 
symmetry in the HMACs that are exchanged. It might be worth thinking a 
bit to see whether there are other situations were similar problems 
could arise.

Olivier
-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be