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 <[email protected]>: > > Hello Mirja, > >> On Jun 17, 2016, at 8:14 AM, Mirja Kühlewind >> <[email protected]> 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 <[email protected]>: >>> >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/multipathtcp >> >> _______________________________________________ >> Tcpinc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tcpinc > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
