IETF Logo Mail Archive

Re: [multipathtcp] MPTCP external auth drafts

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Fri, 17 June 2016 15:14 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 A7C7D12D6B1; Fri, 17 Jun 2016 08:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level:
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 LTS-DWBt64fz; Fri, 17 Jun 2016 08:14:48 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6362A12D0FC; Fri, 17 Jun 2016 08:14:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D661CD9305; Fri, 17 Jun 2016 17:14:46 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xUszh1qyMsvF; Fri, 17 Jun 2016 17:14:46 +0200 (MEST)
Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 89620D9304; Fri, 17 Jun 2016 17:14:46 +0200 (MEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <4E6D9951-D1EB-4F1F-8666-7189357053C0@gmail.com>
Date: Fri, 17 Jun 2016 17:14:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9158F6E6-F21D-4EB6-828D-C89191554C79@tik.ee.ethz.ch>
References: <4E6D9951-D1EB-4F1F-8666-7189357053C0@gmail.com>
To: Alan Ford <alan.ford@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/TvxJLqG33AqCMowcby59U41SYC8>
Cc: multipathtcp <multipathtcp@ietf.org>, tcpinc <tcpinc@ietf.org>
Subject: Re: [multipathtcp] 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: Fri, 17 Jun 2016 15:14:51 -0000

Hi Alan,

adding tcpinc. How does this relate to working tcpinc?

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

v2.23.0 | Report a Bug | By Email