Re: [multipathtcp] [tcpinc] MPTCP external auth drafts

Hi Christoph,

please note that tcpinc also discusses to use the tcpinc option to negotiate application layer TLS. Maybe it would make sense to use tcpinc directly instead of defining yet another negotiation mechanism?

Mirja

> Am 19.06.2016 um 23:55 schrieb Christoph Paasch <cpaasch@apple.com>:
> 
> Hello Mirja,
> 
>> On Jun 17, 2016, at 8:14 AM, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
>> adding tcpinc. How does this relate to working tcpinc?
> 
> in a tcpinc-deployment, MPTCP could use a derivate of tcpinc's key to authenticate new subflows.
> 
> A draft similar to http://www.ietf.org/id/draft-paasch-mptcp-tls-authentication-00.txt would need to describe how the MPTCP-key is derived from the tcpinc-secret.
> 
> 
> Christoph
> 
> 
>> 
>> Mirja
>> 
>> 
>>> Am 28.05.2016 um 10:32 schrieb Alan Ford <alan.ford@gmail.com>:
>>> 
>>> Hi all,
>>> 
>>> Following on from the discussion at the previous two IETFs, we have submitted two drafts proposing a way forward for resolving the loadbalancers issue (or in other words, separating tokens and keys), and in turn have a proposal for using TLS keying material with MPTCP.
>>> 
>>> This proposal comes in the form of two drafts, to separate protocol changes (which we would be proposing for adoption into rfc6824bis), and TLS-specific extensions (which we would suggest are kept separate).
>>> 
>>> The protocol changes (http://www.ietf.org/id/draft-paasch-mptcp-application-authentication-00.txt) propose an additional handshake mechanism to be negotiated in the MP_CAPABLE flags - the "G" bit, allocated to "application-layer". This means that MPTCP queries the application layer for Token and Key materials. This is negotiated by being offered by the initiator, and chosen by the answerer.
>>> 
>>> Only tokens are sent on the wire, and these can be used to contain any information that could assist a far end to demultiplex connections (e.g. including routing data which would help front-end proxies).
>>> 
>>> Minor changes that fall out of this also mean the IDSN, in that scenario, would be generated from the Token not the Key.
>>> 
>>> Keying information may not be available at the SYN/ACK exchange, but will be provided by the application when available. Only once that has occurred can subflow setup continue.
>>> 
>>> The TLS draft (http://www.ietf.org/id/draft-paasch-mptcp-tls-authentication-00.txt) shows how we can interface this proposal with TLS, using RFC5705 key export from TLS. This requires no changes to the protocol, but would register a new RFC5705 exporter with IANA. Exported keys from a TLS session would be passed to the MPTCP layer and used in the HMAC authentication algorithm.
>>> 
>>> We would like to present and discuss these points in the upcoming interim, to see if there is consensus to add the necessary protocol changes to rfc6824bis.
>>> 
>>> Best regards,
>>> Alan & Christoph
>>> _______________________________________________
>>> multipathtcp mailing list
>>> multipathtcp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>> 
>> _______________________________________________
>> Tcpinc mailing list
>> Tcpinc@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpinc
> 
> _______________________________________________
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc