Subject: [multipathtcp] Extending draft-paasch-mptcp-ssl-00

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 25 Feb 2014 17:56:03 +0100

Hello,

In RFC6824, the subflows are authenticated by relying on the keys that 
are exchanged in clear during the three way handshake of the initial 
subflow. From a security viewpoint, exchanging short keys in clear is 
not the best option.

In draft-paasch-mptcp-ssl-00, we proposed to allow an application to 
provide its chosen authentication key to Multipath TCP in order to use 
it to authenticate the establishment of subflows. This draft used 
SSL/TLS as a motivation but we did not specify in details how the 
authentication keys would be derived from the SSL/TLS session keys.

I spent some time to look at TLS1.2 to see how this idea of using keys 
from the application for Multipath TCP could be applied to this version 
of TLS.

TLS1.2 exchanges a master secret during the TLS handshake and random 
numbers from the client and the server. This information is then 
combined as follows (RFC5246) :

       key_block = PRF(SecurityParameters.master_secret,
                       "key expansion",
                       SecurityParameters.server_random +
                       SecurityParameters.client_random);

    until enough output has been generated.  Then, the key_block is
    partitioned as follows:

       client_write_MAC_key[SecurityParameters.mac_key_length]
       server_write_MAC_key[SecurityParameters.mac_key_length]
       client_write_key[SecurityParameters.enc_key_length]
       server_write_key[SecurityParameters.enc_key_length]
       client_write_IV[SecurityParameters.fixed_iv_length]
       server_write_IV[SecurityParameters.fixed_iv_length]

The PRF is currently P_SHA256. Some TLS profiles only generate MAC and 
write keys but no write IVs from this PRF.

To use these keys to authenticate the establishment of the Multipath TCP 
subflows, there are several options that probably have different 
security properties :

  a- Use the client_write_MAC_key/server_write_MAC_key as is
  b- Derive a new client_write_MPTCP/server_write_MPTCP keypair by using 
the PRF
  c- Use a hash of some keys (e.g. 
client_write_MAC_key||server_write_MAC_key on the client)

If Multipath TCP is implemented in the kernel and requires the key to 
accept/reject subflows, then leaking a copy of the key to the kernel 
(option a) is not a good option from a security viewpoint. This solution 
might work if the Multipath TCP implementation can do an upcall to TLS 
upon the arrival of a new subflow to compute the HMAC required for the 
authentication, but this would add complexity to the Multipath TCP 
implementations.

Option b (generating a new Multipath TCP specific key) is more secure, 
but for each combinaison of crypto functions in TLS we need to define a 
profile that includes the generation of the Multipath TCP key. It might 
be difficult to deploy such a solution.

Option c seems easier since the same hash can be used for all TLS 
profiles, but I'm wondering what are the security implications of 
leaking a hash of the MAC_keys to the Multipath TCP kernel.

Any idea on this ?

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