Subject: [multipathtcp] Securing the establishment of MPTCP subflows

From: Olivier Bonaventure <[email-masked]>
Date: Sun, 07 Nov 2010 23:08:24 +0100

Hello,

I'm exploring ways to simplify the security mechanism that is
included in the current MPTCP draft. The current draft assumes that when
a subflow is established, each host needs to generate a random number
and compute a HMAC. These HMACs are exchanged in the payload of TCP
segments.

One proposal to simplify this scheme would be as follows :

Initial flow establishment :

A generates KA and computes trunc(hash(KA)) that serves as its token.
Note that KA must be such that its truncated hash differs from all the
tokens currently used by host A. Its state contains nA=trunc(hash(KA))

A -- SYN KA --->  B

B generates a key KB and stores KA and remembers nA=trunc(hash(KA)),
nB=trunc(hash(KB))

A <--- SYN+ACK KB --- B

A stores KB in its state and nB=trunc(hash(KB))

A --- ACK KA, KB --- > B     (this is required for syn cookies)

If A wants to open a subflow, it operates as follows :

nA++

A ---- SYN nA, HMAC(nA,KA|KB), trunc(hash(KB)) --> B

B verifies that nA is within 64 units of the nA value stored by B
(usually B will received nA+1, but if A opens multiple subflows at the
same time, it may receive several SYNs together) and stores the received
nA. B uses token=trunc(hash(KB)) to find the MPTCP connection to which
the subflow is associated. B verifies the value of the HMAC found in the
SYN segment

A <----- SYN+ACK  nA, HMAC(nA,KB|KA) ---- B

A verifies that nA corresponds to the SYN that it sent and the value of
the HMAC

A ---- ACK ---->  B

If B wants to open a subflow, it does the same, i.e.

nB++

A <---- SYN nB, HMAC(nB,KB|KA), trunc(hash(KA)) -- B

A verifies that nB is within 64 units of the nB value of nB that it
stored and stores the received NB. A verifies the value of the HMAC
found in the SYN segment

A ----- SYN+ACK  nB, HMAC(nB,KA|KB) ----> B

Compared to the current draft, the advantages of this approach are twofold :

1- we do not need to exchange random numbers and convert the three way
handshake in a four way handshake as in SCTP

2- we do not need to carry HMAC values in the payload of the first
segments of a subflow

Compared to the current draft, this proposal does not rely on random
numbers. I don't think that random numbers are necessary in the case of
MPTCP as both hosts already maintain state when a subflow is
established. Using different values for nA and nB and different keys for
the HMAC (KA|KB in one direction and KB|KA in the other) implies that
the SYN and SYN+ACK segments cannot be replayed, neither from a previous
connection (KA and KB are random) nor from a previous subflow
establishment that was captured by an attacker (nA/nB are used only once).

This proposal, like any security proposal for MPTCP would need to
support some crypto agility (i.e. the ability to change from one HMAC
algo to another). If encoded by using the same format as the TCP AO
option, the HMAC would need 16-20 bytes in the SYN segment. A truncated
HMAC would consumme less space.

Olivier

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

---

From: "Ford, Alan" <[email-masked]>
Date: Mon, 8 Nov 2010 07:02:01 -0000

Hi Olivier, all,

Thanks for your thoughts on this, this may be another suitable proposal.

A few thoughts from my side:
* The window of 64 sounds way too large, 4 would seem to be sufficient.
* The value of nA and nB should be the _total_ number of _successful_
subflows achieved (+1 on MP_JOIN attempt), since this ensures both hosts
will have the same value, and reduces the chances of replay attacks.

I am nevertheless concerned about:
* Will the truncation of the HMAC to only 32 bits (as it would have to
be to fit in the option) be sufficiently secure?
* Are there ever ways the two endpoints could get out of sync regarding
their valid nA and nB values? The nA and nB values cannot change until a
subflow is established, but does this provide a window of opportunity
for some forms of attacks? Or could an attacker somehow force the hosts
to get out of sync?
* Are there other benefits (aside from strong replay protection) that
the draft proposal gives over this one?

Would be great to hear from other security people on this...

Cheers,
Alan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Olivier Bonaventure
Sent: 07 November 2010 22:08
To: multipathtcp
Subject: [multipathtcp] Securing the establishment of MPTCP subflows

Hello,

A -- SYN KA --->  B

A <--- SYN+ACK KB --- B

nA++

A ---- ACK ---->  B

nB++

Compared to the current draft, the advantages of this approach are
twofold :

establishment that was captured by an attacker (nA/nB are used only
once).

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be
_______________________________________________
multipathtcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Ford, Alan" <[email-masked]>
Date: Tue, 9 Nov 2010 02:02:40 -0000

To follow up on this, it was pointed out in yesterday's MPTCP session
that it is indeed very difficult to determine the number of subflows
successfully opened.

What is a successful open? If you send data, it must be ACKed, but then
how do you know an ACK has been received? Etc... Therefore, you would
have to say something like "greater than a window's worth of data has
been successfully transmitted or received". But this kind of heuristic
gets quite complicated.

There was also some feedback yesterday that the initial token-based
approach (with the DSN as rudimentary injection protection) seemed
sufficient, and the perils of designing a comprehensive security
solution may cause us more problems than we are trying to solve. 

What we really need is an independent security review of both the basic
(tokens) and a straw-man hash-based approach (such as what is in the
draft now), and determine what is most appropriate to our threat model.

Regards,
Alan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ford, Alan
Sent: 08 November 2010 07:02
To: [email-masked]; multipathtcp
Subject: Re: [multipathtcp] Securing the establishment of MPTCP subflows

Hi Olivier, all,

Cheers,
Alan

-----Original Message-----

Hello,

A -- SYN KA --->  B

A <--- SYN+ACK KB --- B

nA++

A ---- ACK ---->  B

nB++

Olivier

---

From: Tim Shepard <[email-masked]>
Date: Mon, 08 Nov 2010 21:17:05 -0500

> been successfully transmitted or received". But this kind of heuristic

No that won't work either.  The fundamental problem, whatever
threshold you use, is there is no way to synchornize both ends so that
they both synchronously agree about whether or not the threshold has
been reached.  No such heuristic can solve this fundamental problem.

So the number of subflows succesfully opened cannot be used as
something that both ends know.   Because neither end can know what the
other end knows.

What we want is something like DH but I don't think we have space in
the options to carry a DH exchange.  (And we would need a mechanism to
update to new crypto algorithms in case the ones we specify are later
shown to be weak.  Etcetera.)

			-Tim Shepard
			 [email-masked]