Subject: [multipathtcp] MPTCP security solutions

From: "McDonald, Andrew" <[email-masked]>
Date: Thu, 07 Oct 2010 13:11:42 +0100

All,

Having thought about the essential security requirements from the 
threats document, I felt it was time to toss out an initial solution 
proposal - which can be torn to shreds or inspire others to fix it.

Firstly, an observation, the token method currently in the protocol 
draft offers no real security. In particular, once you know one token 
and host address/port, you can use it as an oracle to provide you with 
the other token by sending a SYN(JOIN) to it. The SYN-ACK will tell you 
the other token.

Summarising requirements again:
1/ Provide verification that the peer can receive traffic at a new 
address before adding it
2/ Provide a mechanism to confirm that the parties in a subflow 
handshake are the same as the original connection setup, e.g. require 
use of a key exchanged in the initial handshake in the subflow handshake
3/ Provide replay protection

So, a proposal to stick on the table:

K-A = Key used by A for authenticating subsequent subflow creations
K-B = Key used by B for authenticating subsequent subflow creations
TOK-A = Token used by A to identify its end of the MPTCP session 
(similar to current mechanism)
TOK-B = Token used by B to identify its end of the MPTCP session 
(similar to current mechanism)
H() = A cryptographic hash function, resistant to first preimage attacks 
and suitable for use in an HMAC construction
R-A, R-B = Nonces generated by A and B respectively
IDSN-A, IDSN-B = Initial data sequence numbers

We define:
TOK-A = H(K-A)
TOK-B = H(K-B)

Initial handshake proceeds much like the current system:
SYN     A -> B: Option carries {K-A, IDSN-A}
SYN-ACK B -> A: Option carries {K-B, IDSN-B}
ACK     A -> B: Option carries {K-A, K-B, IDSN-A}

B may generate K-B randomly and store it as state in the half-open 
connection. Alternatively, it may use a function to generate it as a 
stateless cookie. In this case, K-B must be constructed so that the 
necessary state (TCPCB) can be create based on the information in the 
third message.

If host A then wants to add a new subflow:
SYN     A -> B: Option carries {TOK-B, R-A}
SYN-ACK B -> A: Option carries {TOK-A, R-A, R-B}
ACK     A -> B: Payload carries {HMAC(Key=K-A|K-B, Message=R-A|R-B)}
         B -> A: Payload carries {HMAC(Key=K-B|K-A, Message=R-B|R-A)}
Similarly if host B wants to initiate a JOIN.

There is no need for a stateless SYN-ACK mechanism in this case, since 
TOK-B can be validated when the SYN is received. If TOK-B does not 
identify a pre-existing connection that the setup can be dropped/reset. 
Cryptographic work (i.e. the HMAC) does not occur until the end of the 
handshake (and a basic commitment to take part has been established).

The use of K-A and K-B means that a connection cannot be successfully 
established unless the ends took part in (or observed) the initial 
handshake (reqt 2).

The use of R-A, R-B means that the authentication data from the new 
subflow creation cannot be replayed (reqt 3), since new R-A/R-B are 
generated for each subflow creation.

R-A, R-B also effectively strengthen the use of ISNs in avoiding the 
'flooding' type attack (reqt 1). If it wasn't for middleboxes you could 
possibly dispense with R-A/R-B and just use the subflow ISNs (assuming 
good random ISN generation).

The separation of tokens (TOK-A, TOK-B) and keys (K-A, K-B) allows the 
tokens to be used to identification, without concern about making them 
accessible, as described in the observation above about the current 
protocol. The derivation of TOK-A and TOK-B from K-A and K-B avoids the 
need to carry both in the initial handshake.

In order to allow more flexibility in the handshake, we can make use of 
the TCP payload to remove the option-size constraint. My understanding 
is that there is no conflict in using the payload for signalling at the 
beginning of a subflow, since it will be used for data only as soon as 
the handshake is complete.

This solution doesn't currently provided a mechanism for algorithm 
agility or alternative security mechanism selection. This is always 
difficult due to bid-down attacks. However, given the security model 
("sniff the initial handshake and you're in") that probably isn't such 
an issue here. Simplest method may be to include a bitmap in the initial 
options to provide a proposal (e.g. "HMAC-SHA1 or HMAC-SHA256") in the 
SYN and selection in the SYN-ACK.

Best regards,

Andrew

---

From: "Ford, Alan" <[email-masked]>
Date: Fri, 8 Oct 2010 09:42:30 +0100

Hi Andrew, all,

To me, this seems like an excellent security solution for our needs,
meeting our desire to be no worse than regular TCP, protecting against
all threats identified, while having minimal overhead and supporting
SYN-Cookie-like stateless handshake.

> ACK     A -> B: Option carries {K-A, K-B, IDSN-A}

we would also need to include the IDSN-B in the ACK, since B won't have
stored that state.

An alternative approach would be to generate the IDSNs from the keys
using a cryptographic hash function (probably different from the one
used to generate the Tokens).

An open question would be what length of key and Token is appropriate
here. Would 32-bits be secure enough? Using, for example, 32 bits for
K-A and K-B, and using 32-bit truncation of SHA-1 for Tok-A and Tok-B?
Similarly, are 32-bit nonces acceptable? I am mindful of option space
limitations...

Regards,
Alan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]] On
> Behalf Of McDonald, Andrew
> Sent: 07 October 2010 13:12
> To: [email-masked]
> Subject: [multipathtcp] MPTCP security solutions
> 
> All,
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 25 Oct 2010 00:41:52 -0700

Hello Andrew,

Sorry for my slow response.
Maybe I missed some points, but If we setup subflow with the following
way, how much can it be vulnerable?
I just would like to understand the rationale behind HMAC calculation
after SYN exchange.

  SYN     A -> B: Option carries {TOK-B, R-A}
  SYN-ACK B -> A: Option carries {TOK-A, R-A, R-B}
  ACK     A -> B: Option carries {R-B}

Thanks,
--
Yoshifumi Nishida
[email-masked]

2010/10/7 McDonald, Andrew <[email-masked]>:
> All,
>
> Having thought about the essential security requirements from the threats
> document, I felt it was time to toss out an initial solution proposal -
> which can be torn to shreds or inspire others to fix it.
>
> Firstly, an observation, the token method currently in the protocol draft
> offers no real security. In particular, once you know one token and host
> address/port, you can use it as an oracle to provide you with the other
> token by sending a SYN(JOIN) to it. The SYN-ACK will tell you the other
> token.
>
> 1/ Provide verification that the peer can receive traffic at a new address
> before adding it
> 2/ Provide a mechanism to confirm that the parties in a subflow handshake
> are the same as the original connection setup, e.g. require use of a key
> exchanged in the initial handshake in the subflow handshake
> TOK-A = Token used by A to identify its end of the MPTCP session (similar to
> current mechanism)
> TOK-B = Token used by B to identify its end of the MPTCP session (similar to
> current mechanism)
> H() = A cryptographic hash function, resistant to first preimage attacks and
> suitable for use in an HMAC construction
> necessary state (TCPCB) can be create based on the information in the third
> message.
>
> There is no need for a stateless SYN-ACK mechanism in this case, since TOK-B
> can be validated when the SYN is received. If TOK-B does not identify a
> pre-existing connection that the setup can be dropped/reset. Cryptographic
> work (i.e. the HMAC) does not occur until the end of the handshake (and a
> basic commitment to take part has been established).
>
> established unless the ends took part in (or observed) the initial handshake
> (reqt 2).
>
> The use of R-A, R-B means that the authentication data from the new subflow
> creation cannot be replayed (reqt 3), since new R-A/R-B are generated for
> each subflow creation.
>
> possibly dispense with R-A/R-B and just use the subflow ISNs (assuming good
> random ISN generation).
>
> protocol. The derivation of TOK-A and TOK-B from K-A and K-B avoids the need
> to carry both in the initial handshake.
>
> In order to allow more flexibility in the handshake, we can make use of the
> TCP payload to remove the option-size constraint. My understanding is that
> there is no conflict in using the payload for signalling at the beginning of
> a subflow, since it will be used for data only as soon as the handshake is
> complete.
>
> This solution doesn't currently provided a mechanism for algorithm agility
> or alternative security mechanism selection. This is always difficult due to
> bid-down attacks. However, given the security model ("sniff the initial
> handshake and you're in") that probably isn't such an issue here. Simplest
> method may be to include a bitmap in the initial options to provide a
> proposal (e.g. "HMAC-SHA1 or HMAC-SHA256") in the SYN and selection in the
> SYN-ACK.
>
>
> Best regards,
>
> Andrew

---

From: "McDonald, Andrew" <[email-masked]>
Date: Tue, 26 Oct 2010 11:49:45 +0100

Hi Yoshifumi,

>    ACK     A ->  B: Option carries {R-B}

The HMAC in the proposal meant that you wouldn't be able to complete the 
subflow setup without knowing the secret(s) established on the initial 
connection SYN exchange. The R-A/R-B usage in the HMAC calculations 
stopped the HMAC from being replayed. In the case above no such secret 
knowledge is required (and there isn't an HMAC result which you want to 
stop from being replayed).

In your case the a subflow setup could be completed having seen a single 
direction of the initial flow setup or a single direction from any 
subsequent flow setup. The proposal would require that you saw both 
directions of the initial flow setup (and seeing subsequent subflow 
setups provide no benefit to an attacker).

regards,

Andrew

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 27 Oct 2010 03:02:29 -0700

Hello Andrew,

Thanks for your response.
OK, In this proposal, the same TOK-A and TOK-B are used for all subflow setups.
The reason why we don't do something like this is option space limitation?

SYN         A ->  B: Option carries {HMAC(Key=K-A|K-B, Message=R-A + ..), R-A}
SYN-ACK B ->  A: Option carries {HMAC(Key=K-B|K-A, Message=R-B + .. ), R-B, R-A}
ACK         A ->  B: Option carries {R-B}

Thanks,
--
Yoshifumi Nishida
[email-masked]

2010/10/26 McDonald, Andrew <[email-masked]>:
> connection SYN exchange. The R-A/R-B usage in the HMAC calculations stopped
> the HMAC from being replayed. In the case above no such secret knowledge is
> required (and there isn't an HMAC result which you want to stop from being
> replayed).
>
> directions of the initial flow setup (and seeing subsequent subflow setups
> provide no benefit to an attacker).
>
> regards,
>
> Andrew
>

---

From: "McDonald, Andrew" <[email-masked]>
Date: Thu, 28 Oct 2010 11:53:08 +0100

Hi Yoshifumi,

> ACK         A ->    B: Option carries {R-B}

The main problem with this as formulated is: how does B know which 
K-A/K-B to use to verify the HMAC?

The SYN option in this case can be replayed without any extra work on 
the part of A. The only other information B gets from A is R-B, but that 
can just be copied from the SYN-ACK. B doesn't get any assurance that A 
actually knows the key - getting A to perform the HMAC over R-B does 
provide this evidence.

The other proposal also tried to delay doing 'work' (i.e. the HMAC) 
until after the TCP handshake had successfully completed.

regards,

Andrew

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 29 Oct 2010 02:43:47 -0700

HI Andrew,

2010/10/28 McDonald, Andrew <[email-masked]>:
> The main problem with this as formulated is: how does B know which K-A/K-B
> to use to verify the HMAC?
>
> The SYN option in this case can be replayed without any extra work on the
> part of A. The only other information B gets from A is R-B, but that can
> just be copied from the SYN-ACK. B doesn't get any assurance that A actually
> knows the key - getting A to perform the HMAC over R-B does provide this
> evidence.
>
> The other proposal also tried to delay doing 'work' (i.e. the HMAC) until
> after the TCP handshake had successfully completed.

I thought including Address ID for HMAC calculation might be a way to
prevent replay attack.
But, I realized some drawbacks that re-using IDs, option space issues,
overhead for hash calculation...
Looks like this is very reasonable.
Thank you so much for your clarification.
--
Yoshifumi Nishida
[email-masked]