Subject: [multipathtcp] Application-layer Authentication

From: Alan Ford <[email-masked]>
Date: Tue, 2 Aug 2016 18:28:12 +0100

Hi all,

Picking up from the discussion in Berlin… It was generally felt that more discussion was required around the proposal for application-layer authentication. So, I’m posting this in the hope that folks who think that more discussion is required can raise their concerns and queries.

To recap, we have proposed application-layer authentication in two separate drafts:

https://www.ietf.org/id/draft-paasch-mptcp-application-authentication-00.txt <https://www.ietf.org/id/draft-paasch-mptcp-application-authentication-00.txt> - the proposal for the ‘G’ bit for RFC6824bis
https://www.ietf.org/id/draft-paasch-mptcp-tls-authentication-00.txt <https://www.ietf.org/id/draft-paasch-mptcp-tls-authentication-00.txt> - how to use this with TLS

The first of these defines the ‘G’ bit of the crypto algorithm section bits of the MP_CAPABLE handshake to mean “application-layer”. This means that whatever application is driving this MPTCP connection is responsible for providing keying material to the MPTCP stack in order to authenticate MP_JOIN messages etc. The tokens are entirely arbitrary (rather than being key-derived) and are exchanged in place of the keys in the MP_CAPABLE handshake.

This allows tokens to be meaningful for the sender, so data e.g. back-end server IDs can be carried. This also removes handling of hash collisions. This also permits stronger crypto to be used without any further protocol changes.

The second draft shows how to use this with RFC5705 TLS key exporters, so an application-layer TLS session can provide the secure keys to be used by future sub flows.

Concerns were raised over the limited uses of this, but what we would counter with is that the draft is deliberately vague in its proposals - as long as both ends know what application-layer authentication scheme could be used, _anything_ can be used here - TLS is just an example. Whilst the use of TLS would prevent additional subflows hijacking a connection anyway, that is protection only against the security aspects here, and not the convenience factors of separating tokens from keys.

Regards,
Alan