Subject: [multipathtcp] Consensus on HMAC as security solution(?) - Confirming on list the conclusion from the audio meeting.

From: <[email-masked]>
Date: Tue, 14 Dec 2010 19:00:19 +0000

Thanks for the very useful audio meeting, i think we have made good progress. Notes etc will follow; see also slides http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Dec_2010

On the call, we seemed to be finding consensus on the following:-

Tokens proposal (as in the -01 draft)
Stops blind attacks
But is too vulnerable to various threats, for instance if you listen to the token (on the initial SYN) then you can join the connection any time

Hash chains proposal (see mailing list)
Protects against interception of MP_CAPABLE & MP_JOIN
But there remains a racing attack of intercepting and copying a hash from genuine MP_JOIN; not clear that the VERIFY proposal actually solves this
There are a lot of error cases to work through [lost msgs etc, potentially opening security holes]
The processing overhead is quite high.

HMAC proposal  (as in the -02 draft)
Protect against attackers intercepting MP_JOIN
Susceptible to listener on MP_CAPABLE
HMAC is what SCTP does, so should be acceptable to Security review.
Seems the best compromise

Tentative conclusion & consensus:

1.       We go with HMAC

2.       We build into the protocol agility for better security methods, to be defined later (eg using pre-shared key on MP_CAPABLE; eg with IPv6 CGAs)

3.       Security considerations section of draft will need to describe security properties (what attackers are protected or not; requirements eg work with NATs, break-before-make mobility etc)

4.       We think about extending the Charter to define better security methods (or rather, asking for our Charter to be extended)

This is just a very brief summary, hopefully not too inaccurate.

Especially people not on the call:
* please shout if you need more explanation of any of these points
*** in particular please say if you disagree with the conclusion.

I suggest we set a deadline of 31st December for discussion about going with HMAC as our MPTCP security approach. That gives us Jan & Feb to finish working on the details - with the aim of meeting our charter milestone of completing in March (next IETF).

Thanks
Phil/

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 15 Dec 2010 03:37:39 -0800

Hello, I've upload the interim meeting log on:
http://trac.tools.ietf.org/wg/mptcp/trac/attachment/wiki/Interim_Dec_2010/mptcp-interim.2010-1214.txt

Please let me know if there's any mistake.

Thanks,
--
Yoshifumi Nishida
[email-masked]