IETF Logo Mail Archive

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

Christoph Paasch <cpaasch@apple.com> Sun, 19 June 2016 21:55 UTC

Return-Path: <cpaasch@apple.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0BB12D842 for <multipathtcp@ietfa.amsl.com>; Sun, 19 Jun 2016 14:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.728
X-Spam-Level:
X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txdTxXugI1Ah for <multipathtcp@ietfa.amsl.com>; Sun, 19 Jun 2016 14:55:36 -0700 (PDT)
Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A10312D84C for <multipathtcp@ietf.org>; Sun, 19 Jun 2016 14:55:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1466373335; x=2330286935; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OHa/qeDVJLvzQ8anjr9BlzznLV2QHvrTEh92AR5sWFg=; b=V0WN8YL315BpJlejbvX5vcfLeursQxYfuXNsxeHpvbh1OmJ1A3lPyChKaB8OkcAz 6xu1AMxo0cPm4Yeax2aCnvHbe1zDMbdrylEj1w6nQWFjPY+nfSp2lwJG23nRVbgE AHCLOizMm2TSJxqfLHdvGKnnCsO4psli5dIrqPimy9G96z/ttPxh/aS4OIDdQPst mDm6hRl2K+fEQIEGTsqsxb+g6Ch6SueL6QuYocNZMh5DOH6gxKH4J4TyHqFVPyHR pWzOLtxbUlumRHNDSUEhR064xEDQA/MIfiOGproWqfkJNNvqoRrBH8iCMPagfTju wkDvYqt1YUhw68ORLd2woQ==;
Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 69.BF.18746.7D417675; Sun, 19 Jun 2016 14:55:35 -0700 (PDT)
X-AuditID: 11973e15-f79436d00000493a-49-576714d74b96
Received: from nwk-mmpp-sz08.apple.com (nwk-mmpp-sz08.apple.com [17.128.115.25]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 8F.43.12923.7D417675; Sun, 19 Jun 2016 14:55:35 -0700 (PDT)
Received: from [17.149.220.208] (unknown [17.149.220.208]) by nwk-mmpp-sz08.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O9100382GWMJY50@nwk-mmpp-sz08.apple.com>; Sun, 19 Jun 2016 14:55:35 -0700 (PDT)
Sender: cpaasch@apple.com
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Christoph Paasch <cpaasch@apple.com>
In-reply-to: <9158F6E6-F21D-4EB6-828D-C89191554C79@tik.ee.ethz.ch>
Date: Sun, 19 Jun 2016 14:55:34 -0700
Content-transfer-encoding: quoted-printable
Message-id: <A4F5A237-681C-40E5-80EF-0D30A9894E35@apple.com>
References: <4E6D9951-D1EB-4F1F-8666-7189357053C0@gmail.com> <9158F6E6-F21D-4EB6-828D-C89191554C79@tik.ee.ethz.ch>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUi2FAYrHtdJD3c4OJLYYvPq6+zWUw9fJHd gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZJ79tYy44LF5x5ccLpgbGTcJdjJwcEgImEu1XXrBB 2GISF+6tB7K5OIQE9jJKfL/7k7GLkQOs6Mz5Koj4MiaJrTNOskA4vUwSa1/dYQLpFhaQlOi+ c4cZpIFZQF1iypRckDCvgJ7E5KMNbBAl9hKtew+BlbMJaEm8vd3OCmJzCjhJfHx6DMxmEVCV mP/kPguIzSxQIPGn8wYbhK0t8eTdBVaImTYSfx/tBYsLCZRIvFs3gxHEFhFwk/hy6SnUM7IS T04uArtTQmANm8SSkw9YJzCKzEI4bxaS82YhWbGAkXkVo1BuYmaObmaemV5iQUFOql5yfu4m RlCYT7cT3cF4ZpXVIUYBDkYlHt4J59PChVgTy4orcw8xSnOwKInznnsNFBJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cAYEPLMh5chNGaHkTJXf0yG/Wqx5fkM//X/LprMd/Ot5Wmj/UE/WLcX nDF6IKC5r/3bpzN8OybPa3mZ+vlhpZ7FqpIuce8di65U77Of89jq/hVT2wmhq41VXxsUbr/H H92aI7n5HLPs00mPdp2IXzrhbzo3c8KzH74WG8/+E5zqMUXqUNDj5sxsJZbijERDLeai4kQA NLWfM1QCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUi2FAsqXtdJD3cYNEXfovPq6+zWUw9fJHd gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZJ79tYy44LF5x5ccLpgbGTcJdjBwcEgImEmfOV3Ux cgKZYhIX7q1n62Lk4hASWMYksXXGSRYIp5dJYu2rO0wgVcICkhLdd+4wgzQzC6hLTJmSCxLm FdCTmHy0gQ2ixF6ide8hsHI2AS2Jt7fbWUFsTgEniY9Pj4HZLAKqEvOf3GcBsZkFCiT+dN5g g7C1JZ68u8AKMdNG4u+jvWBxIYESiXfrZjCC2CICbhJfLj1lgzhaVuLJyUUsExgFZyFcNAvJ RbOQTF3AyLyKUaAoNSex0lgvsaAgJ1UvOT93EyM4LAuDdzD+WWZ1iFGAg1GJh9fibFq4EGti WXFl7iFGCQ5mJRFeJ2BQC/GmJFZWpRblxxeV5qQWH2JMBvplIrOUaHI+MGbySuINTUwMTIyN zYyNzU3MSRNWEued750YLiSQnliSmp2aWpBaBLOFiYNTqoEx8ydfvvFu3u1mW+e9uSJcJffI RDh7dQXjitWSMxft/7DB9Ksxh02A2KQjv3yDuU11uaVW6EZedPacfzBwU5aa/IfmoAtPfx/b b9ShobVacxGfqccPi6dzq1dPaFcpLX15ZFn37f2n+/7HGkou4bjddutRR7LMgcP/BK9msWlN NPywYYGl+6S5SizFGYmGWsxFxYkAV2QaD48CAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/6Xha02tw8-cMPCuYg7ZiV5CGxkE>
Cc: MultiPath TCP - IETF WG <multipathtcp@ietf.org>, tcpinc <tcpinc@ietf.org>
Subject: Re: [multipathtcp] [tcpinc] MPTCP external auth drafts
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Jun 2016 21:55:37 -0000

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

v2.23.0 | Report a Bug | By Email