Subject: [multipathtcp] Thursday 3rd October: MPTCP interim (audio) meeting on security

From: <[email-masked]>
Date: Mon, 9 Sep 2013 17:31:57 +0100

Let's fix the date of the interim meeting for Thursday 3rd October at 3pm GMT (note, the clocks change at different times in different regions of the world, this time is in GMT/UTC)

Will send audio details later

Thanks!
phil

From: Eardley,PL,Philip,TUB8 R
Sent: 06 September 2013 10:59
To: [email-masked]
Subject: MPTCP interim (audio) meeting on security - please update your doodle

I extended the doodle to the first week of October.
Please could you update your entry or fill in

Sorry for the trouble

Thanks
phil

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 04 September 2013 08:31
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [multipathtcp] MPTCP interim (audio) meeting on security, late September

Just to let you know. The Security Ads are kindly finding us a security advisor, but no luck yet. So we may have to delay this slightly.
Also, it would be good if there was some discussion on the mailing list before the call.

phil

From: Eardley,PL,Philip,TUB8 R
Sent: 21 August 2013 08:36
To: Eardley,PL,Philip,TUB8 R; [email-masked]<mailto:[email-masked]>
Subject: RE: [multipathtcp] MPTCP interim (audio) meeting on security, late September

Just a reminder, as I know a lot of people have been on holiday, please fill in the doodle

Thanks
phil

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 06 August 2013 13:49
To: [email-masked]<mailto:[email-masked]>
Subject: [multipathtcp] MPTCP interim (audio) meeting on security, late September

We think it would a good idea to have an interim (audio) meeting, in order to make progress on advancing RFC 6824 on the standards track.

We will discuss the security of the MPTCP protocol. The aim is to reach consensus on what security improvements are needed - and what are not needed - in order to progress MPTCP on the Standards track. We hope to cover both the threat(s) that we will handle and, at a high-level, the solutions that will be defined.

Please fill in the doodle at http://doodle.com/xdf8eaiavvna9bcy#table

For previous MPTCP WG interims, ~3pm GMT has been OK. Please shout if the time is no good for you.

In the meantime, please keep discussing MPTCP's security on the list!

Thanks,
Best wishes
Phil & Yoshifumi

---

From: Edward Lopez <[email-masked]>
Date: Mon, 9 Sep 2013 17:32:38 +0000

FYI ... THe LISP interim meeting is on the same date in Herndon, VA, US
________________________________
From: [email-masked] [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Monday, September 09, 2013 12:31 PM
To: [email-masked]
Subject: [multipathtcp] Thursday 3rd October: MPTCP interim (audio) meeting on security

Let’s fix the date of the interim meeting for Thursday 3rd October at 3pm GMT (note, the clocks change at different times in different regions of the world, this time is in GMT/UTC)

Thanks!
phil

Sorry for the trouble

Thanks
phil

phil

Thanks
phil

In the meantime, please keep discussing MPTCP’s security on the list!

Thanks,
Best wishes
Phil & Yoshifumi

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: <[email-masked]>
Date: Fri, 27 Sep 2013 11:56:45 +0100

Chatting with a couple of people and thinking about the way forward.

Marcelo has suggested a 2-pronged approach:-

Prong 1: how to improve RFC6824 to solve the ADD_ADDR attack. The aim is to get security equivalent to RFC5061 (SCTP with dynamic addresses). We can also improve RFC6824 to make some of the fallback cases clearer (I remember that came out of the implementation survey). We could hope to do this quite quickly as a relatively small improvement to 6824, since there was some discussion on the list a while back how to solve this.

Prong 2: RFC6824 sends the key in the clear on the MP_CAPABLE exchange - What could we do better?  We've had some possibilities mentioned in the past, but I don't think there's any consensus yet.

Personally I think this seems a good way forward. We could do Prong 1 quickly if it looks like Prong 2 will take some time

Comments on this approach welcome.
Also if anyone would like a timeslot in the interim meeting, please let us know

Reading
http://tools.ietf.org/html/draft-bagnulo-mptcp-attacks-00

thanks

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 09 September 2013 17:32
To: [email-masked]
Subject: [multipathtcp] Thursday 3rd October: MPTCP interim (audio) meeting on security

Thanks!
phil

Sorry for the trouble

Thanks
phil

phil

Thanks
phil

Thanks,
Best wishes
Phil & Yoshifumi

---

From: Anumita Biswas <[email-masked]>
Date: Fri, 27 Sep 2013 10:22:41 -0700

Hi Phil,

Prong 2 or the discussion of how to alter MP_JOINs so as to not be dependent on keys exchanged in the clear is a higher priority (compared to Prong 1) although it can take more time. Perhaps if we could start with the list of ideas on the table, that would be great ? 

ADD_ADDR vulnerability is real, but since it is an optional part of the protocol it is not as important a threat as Prong 2 below. ADD_ADDR is also not as easily implementable in Internet environments as most peer to peer or client side end-points have to use out of band mechanisms to discover their public facing addresses to send out over ADD_ADDR. This limits the utility of ADD_ADDR to public facing servers or middleboxes on the Internet. For this limited set of public facing servers, ability to use ADD_ADDR allows connectivity to them be more robust, yet it is not as important an use case and if these middleboxes do not support ADD_ADDR until the vulnerability is solved, it is acceptable imo.

In data center type environments/ private environments, ADD_ADDR probably does not pose as real a threat and could be suitable in its current shape. 

Thanks,
Anumita

On Sep 27, 2013, at 3:56 AM, [email-masked] wrote:

> Prong 2: RFC6824 sends the key in the clear on the MP_CAPABLE exchange - What could we do better?  We’ve had some possibilities mentioned in the past, but I don’t think there’s any consensus yet.
>  
> To: Eardley,PL,Philip,TUB8 R; [email-masked]
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 27 Sep 2013 21:39:51 +0200

Anumita,
>
> Prong 2 or the discussion of how to alter MP_JOINs so as to not be
> dependent on keys exchanged in the clear is a higher priority (compared
> to Prong 1) although it can take more time. Perhaps if we could start
> with the list of ideas on the table, that would be great ?

The first issue that we need to take into account are the constraints on 
the three way handshake and the utilisation of crypto inside TCP.

The current design heavily depends on the assumption that we cannot 
perform strong crypto inside TCP and the constraint on the maximum 
length of the TCP option field (mainly during the three way handshake). 
Given these two constraints, it seems pretty difficult to provide a 
strong and secure mechanism in the TCP layer. We will always be blocked 
by the limited size of the TCP options. Exchanging public keys or 
certificates is impossible in TCP options.

A first possible approach is to allow MPTCP to reuse keys that are 
derived in a secure manner by the application. This solution could work 
with SSL/TLS and SSH for example. These application-layer protocols can 
derive secure keys after a Diffie-Hellman exchange. MPTCP could provide 
an API to receive such a key and use it to autheticate MP_JOINs.

This solution has been described in
http://tools.ietf.org/html/draft-paasch-mptcp-ssl-00
and there is a prototype implementation.

This draft sketches the solution and shows that it is feasible. However, 
there are two points that would need to be improved :
  - the algorithm to derive the MPTCP session should be proposed by 
security experts
  - MPTCP should use a key identifier and allow the application to 
change the MPTCP key (e.g. as a result of a change of the master keys by 
SSL/TLS)

With this solution, MPTCP cannot create additional subflows at the 
beginning of the MPTCP connection since it must wait until the security 
keys have been computed.

A second direction that has been discussed is the utilisation of hash 
chains. The client and the server could generate a hash chain for each 
MPTCP connection and use it to authenticate subsequent MP_JOINs. The 
hash chains could be included in the SYN and SYN+ACK segments if there 
is enough option space. The main advantage of hash chains is that they 
do not require strong crypto. However, a hash chain will be valid for N 
additional subflows. To create the N+1th subflow, the peers would need 
to exchange securely a new hash chain.

A third direction could be to build upon the tcpcrypt proposal and 
include it inside MPTCP. This requires strong crypto in the transport layer.

My impression is that trying to secure MPTCP without securing the data 
exchanged is a bit overkill and I would try to pursue the first 
direction in more details.

Olivier

---

From: Anumita Biswas <[email-masked]>
Date: Fri, 27 Sep 2013 13:20:30 -0700

On Sep 27, 2013, at 12:39 PM, Olivier Bonaventure <[email-masked]> wrote:

> The first issue that we need to take into account are the constraints on the three way handshake and the utilisation of crypto inside TCP.
> 
> The current design heavily depends on the assumption that we cannot perform strong crypto inside TCP and the constraint on the maximum length of the TCP option field (mainly during the three way handshake). Given these two constraints, it seems pretty difficult to provide a strong and secure mechanism in the TCP layer. We will always be blocked by the limited size of the TCP options. Exchanging public keys or certificates is impossible in TCP options.
> 
> A first possible approach is to allow MPTCP to reuse keys that are derived in a secure manner by the application. This solution could work with SSL/TLS and SSH for example. These application-layer protocols can derive secure keys after a Diffie-Hellman exchange. MPTCP could provide an API to receive such a key and use it to autheticate MP_JOINs.
> 
> This draft sketches the solution and shows that it is feasible. However, there are two points that would need to be improved :
> - the algorithm to derive the MPTCP session should be proposed by security experts
> - MPTCP should use a key identifier and allow the application to change the MPTCP key (e.g. as a result of a change of the master keys by SSL/TLS)
> 
> With this solution, MPTCP cannot create additional subflows at the beginning of the MPTCP connection since it must wait until the security keys have been computed.
> 
> A second direction that has been discussed is the utilisation of hash chains. The client and the server could generate a hash chain for each MPTCP connection and use it to authenticate subsequent MP_JOINs. The hash chains could be included in the SYN and SYN+ACK segments if there is enough option space. The main advantage of hash chains is that they do not require strong crypto. However, a hash chain will be valid for N additional subflows. To create the N+1th subflow, the peers would need to exchange securely a new hash chain.
> 
> A third direction could be to build upon the tcpcrypt proposal and include it inside MPTCP. This requires strong crypto in the transport layer.
> 
> My impression is that trying to secure MPTCP without securing the data exchanged is a bit overkill and I would try to pursue the first direction in more details.
I agree. Using SSL keys to improve the strength of the negotiation in Join is the preferred approach. Yes, security experts should look into the algorithm. I think trading off the delay added to initiating subflow joins until the SSL handshake is complete on the primary subflow is worth it for cases where secure join is more important than faster subflow addition. If the spec continues to support the existing join mechanism, then the faster subflow addition albeit slightly less secure (with TLS) is still there for those cases where this is necessary.  

One other thing is that the 4th ACK from the server on Joins should probably not contain the Data ACK so as to not give away the Data Sequence space to a connection hijacker.

Thanks,
Anumita

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 27 Sep 2013 22:52:39 +0200

Hi,

some comments below...

El 27/09/13 21:39, Olivier Bonaventure escribió:
> The first issue that we need to take into account are the constraints 
> on the three way handshake and the utilisation of crypto inside TCP.
>
> length of the TCP option field (mainly during the three way 
> handshake). Given these two constraints, it seems pretty difficult to 
> provide a strong and secure mechanism in the TCP layer. We will always 
> be blocked by the limited size of the TCP options. Exchanging public 
> keys or certificates is impossible in TCP options.
>
> derived in a secure manner by the application. This solution could 
> work with SSL/TLS and SSH for example. These application-layer 
> protocols can derive secure keys after a Diffie-Hellman exchange. 
> MPTCP could provide an API to receive such a key and use it to 
> autheticate MP_JOINs.
>

I understand that the data that would be carried in the MPTCP session in 
this case would be SSL data, correct?
If this is the case, then the data itself is already encrypted, so i 
guess we should do a residual threat analysis to understand what is what 
an attacker can do to already encrypted ssl traffic.

The other limitiation here of course is that this only applies to SSL 
traffic, which afaict is only a small fract of the internet traffic, so, 
this begs the question what happens with the remaining traffic, right?

> This draft sketches the solution and shows that it is feasible. 
> However, there are two points that would need to be improved :
> change the MPTCP key (e.g. as a result of a change of the master keys 
> by SSL/TLS)
>
> beginning of the MPTCP connection since it must wait until the 
> security keys have been computed.
>
> do not require strong crypto. However, a hash chain will be valid for 
> N additional subflows. To create the N+1th subflow, the peers would 
> need to exchange securely a new hash chain.
>

I actually think the argument is in the other side, if the traffic is 
already encrypted, how much harm can an attacker do?

I mean, i dont oppose to this, i only belibe that solves a small piece 
of the problem.

Regards, marcelo