Subject: [multipathtcp] Security Solutions' Properties

From: "Ford, Alan" <[email-masked]>
Date: Wed, 8 Dec 2010 11:03:38 -0000

Folks,

Inspired by Olivier's mail of 22 Nov, proposing categories of attacker
capabilities, the following list attempts to summarise where we stand
with various security proposals. Security is a trade-off, and we need to
get a feel from the WG of what threats it is realistic to aim to protect
against (where security of communications really matters, TLS will be
used, anyway, negating any MITM or hijacking threats to MPTCP - although
DoS remains a threat). Thoughts?

Tokens 
------
(i.e. a single random token generated by a host is used by the peer to
identify the connection it wants to talk about - the -01 and previous
version of the draft)

-> These protect against blind attack, since an attacker would need to
see a token.

HMAC
----
(i.e. authentication based on a token only seen in the clear in the
MP_CAPABLE handshake; the proposal as in draft -02)

-> These protect against any attacker who intercepts a MP_JOIN. An
attacker would need to see the initial MP_CAPABLE exchange, but could
then use this information at any point during a connection.

Hash Chain
----------
(as per my earlier mail, but without the HMAC)

-> This protects against listeners who intercept any signalling exchange
(MP_CAPABLE, MP_JOIN, etc), by hash chain entries having single-use
validity. Note that since hash chain entries are valid until a newer one
is sent, there is potential for attackers to intercept and hijack a
connection if they are able to stop (or slow down) packets getting to
the destination.

In other words, an attacker who can see the MP_JOIN could
'cut-and-paste' hash chain entries from one flow to another, but needs
to block the real message, or win a race against the real sender.

Hash Chain + HMAC
-----------------
-> This additionally protects against listeners who have intercepted the
MP_JOIN and been able to stop (or slow down) packets getting to the
destination, so long as the attackers have not seen the initial
MP_CAPABLE exchange.

In other words, an attacker would need to be see the initial MP_CAPABLE
(to learn the keys), see the MP_JOIN (to learn a hash chain entry) and
then block the real message or win the race against the real sender.

Regards,
Alan

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 08 Dec 2010 12:18:21 +0100

> then use this information at any point during a connection.

mmm, i understand that an attacker who is capable of replacing the 
original hash chain anchor (i.e. the initial value exchanged during 
connection set up) by its own anchor would then be able to send any JOIN 
at any point in time.
In other words, the difference between the HMAC solution and the hash 
chain solution is that in the HMAC is vulnerable to passive attackers 
listening the initial exchange of the key that will be used by the HMAC 
for the future JOIN, while the hash chain approach is vulnerable only to 
active attackers, right?

BEsides, as Marshal noted, you need to consider the DoS attacks agaisnt 
the hash chain itself, correct?

Regards, marcelo

> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>