Subject: [multipathtcp] Hash function usage in Multipath TCP

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 25 Feb 2014 22:18:51 +0100

Hello,

Multipath TCP, as defined in RFC6824, currently uses the SHA-1 hash 
function for three purposes :

  - derive the Token from the keys exchanged in clear during the 
three-way-handshake
  - derive the Initial Data Sequence Number from the keys exchanged in 
clear during the three-way-handshake
  - authenticate the establishment of the subflows by using a HMAC 
computed over the keys exchanged in clear and random nonces

Most of the protocols that rely on hash functions include a method to 
negotiate the hash function that is used for a particular invocation of 
the protocol.

In Multipath TCP, it seems a bit difficult to easily add the support for 
another has function in a secure manner.

The current version of RFC6824 contains the following statement 
concerning the flags in the MP_CAPABLE option in the SYN segment

> C through H:  The remaining bits, labeled "C" through "H", are used
>       for crypto algorithm negotiation.  Currently only the rightmost
>       bit, labeled "H", is assigned.  Bit "H" indicates the use of HMAC-
>       SHA1 (as defined in Section 3.2).  An implementation that only
>       supports this method MUST set bit "H" to 1, and bits "C" through
>       "G" to 0.

Setting bit H to 1 is the current default in Multipath TCP. By using 
bits C, D, E, F and G, we could define other hash functions in case 
SHA-1 is broken and considered to be insecure for Multipath TCP.

Later, RFC6824 notes :

>    For crypto negotiation, the responder has the choice.  The initiator
>    creates a proposal setting a bit for each algorithm it supports to 1
>    (in this version of the specification, there is only one proposal, so
>    bit "H" will be always set to 1).  The responder responds with only 1
>    bit set -- this is the chosen algorithm.  The rationale for this
>    behavior is that the responder will typically be a server with
>    potentially many thousands of connections, so it may wish to choose
>    an algorithm with minimal computational complexity, depending on the
>    load.  If a responder does not support (or does not want to support)
>    any of the initiator's proposals, it can respond without an
>    MP_CAPABLE option, thus forcing a fallback to regular TCP.

If we replace SHA-1 with another hash function, we thus need to define a 
new bit to propose this new hash function. According to the above texte, 
the client could propose the new hash and SHA-1 (by setting the H bit) 
or only the new hash.

 From a security viewpoint, doing this negotiation of the has functions 
in clear may lead to downgrading attacks where an attacker resets the 
bit corresponding to the hash that he/she does not want to support. 
Given that the SYN is only "protected" by a standard checksum, this 
attack is simple. However, this does not seem to be very severe since if 
the attacker is able to change the content of the SYN, he/she can 
already read the authentication keys...

Should we already define a new hash functions inside RFC6824bis ?

If yes, then we probably need to structure the Multipath TCP RFCs as for 
TCP-AO, i.e. :

  - a first document defines the protocol with abstract crypto 
functions, basically most of the current RFC6824
  - a second document specifies the crypto algorithms can be used with 
all their requirements parameters

If we go in the direction, are there strong preferences for a second 
hash function for Multipath TCP ?

Olivier

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

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 27 Feb 2014 01:24:20 -0800

Hi Olivier,

On Tue, Feb 25, 2014 at 1:18 PM, Olivier Bonaventure <
[email-masked]> wrote:
> the client could propose the new hash and SHA-1 (by setting the H bit) or
> only the new hash.
>
> From a security viewpoint, doing this negotiation of the has functions in
> clear may lead to downgrading attacks where an attacker resets the bit
> corresponding to the hash that he/she does not want to support. Given that
> the SYN is only "protected" by a standard checksum, this attack is simple.
> However, this does not seem to be very severe since if the attacker is able
> to change the content of the SYN, he/she can already read the
> authentication keys...
>

I don't see strong benefits for protecting downgrading attacks as you
mentioned.
Also, if they don't want to downgrade, I guess they should set only the bit
for the hash they want.

>  - a first document defines the protocol with abstract crypto functions,
> basically most of the current RFC6824
>  - a second document specifies the crypto algorithms can be used with all
> their requirements parameters
>
> If we go in the direction, are there strong preferences for a second hash
> function for Multipath TCP ?
>
> Hmm. I see your point. But, how many hashes we want to specify now?
If we just add one more hash to the current spec, the second doc will be
thin, it might not be a problem, though..

--
Yoshifumi

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 27 Feb 2014 11:04:55 +0100

Yoshifumi,
>
>
>     If we replace SHA-1 with another hash function, we thus need to
>     define a new bit to propose this new hash function. According to the
>     above texte, the client could propose the new hash and SHA-1 (by
>     setting the H bit) or only the new hash.
>
>      >From a security viewpoint, doing this negotiation of the has
>     functions in clear may lead to downgrading attacks where an attacker
>     resets the bit corresponding to the hash that he/she does not want
>     to support. Given that the SYN is only "protected" by a standard
>     checksum, this attack is simple. However, this does not seem to be
>     very severe since if the attacker is able to change the content of
>     the SYN, he/she can already read the authentication keys...
>
>
> Also, if they don't want to downgrade, I guess they should set only the
> bit for the hash they want.

What I meant is the following

client sends SYN with MP_CAPABLE indicating HASH1+HASH2
attacker removes HASH2 from SYN
server replies with HASH1 in SYN+ACK

If client sends SYN with MP_CAPABLE and only HASH2, it should reply with 
RST if it receives HASH1 in SYN+ACK

>     If yes, then we probably need to structure the Multipath TCP RFCs as
>     for TCP-AO, i.e. :
>
>       - a second document specifies the crypto algorithms can be used
>     with all their requirements parameters
>

The second document could even only contain a single hash (SHA-1 today). 
If we need to expand the hash functions without chaning MPTCP, we simply 
need to update this second document.

We might want to reserve some bits (e.g. 3) in the MP_CAPABLE option for 
the selection of the hash functions that are to be defined in the second 
document

Olivier