[multipathtcp] Application-layer Authentication

Alan Ford <alan.ford@gmail.com> Tue, 02 August 2016 17:28 UTC

Return-Path: <alan.ford@gmail.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 ACC2512D188 for <multipathtcp@ietfa.amsl.com>; Tue, 2 Aug 2016 10:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xC0axvYkMmuP for <multipathtcp@ietfa.amsl.com>; Tue, 2 Aug 2016 10:28:17 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F1212D12E for <multipathtcp@ietf.org>; Tue, 2 Aug 2016 10:28:16 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id f65so417919211wmi.0 for <multipathtcp@ietf.org>; Tue, 02 Aug 2016 10:28:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=JojVpaY64o51qIZDPqF71FhlJiq7HF2eSWwuv5RUQxE=; b=AVbYOKMBoFKuMMmrZU5DkMMI2aSNoxsV4RFQr6WN1BEGLTuzRZYNxE5SSS/Bgutd9K H2qljSTCgFPDCe/ZftFyrDUW8JLmhAuQ+iBsIRBSnrsAO12ZEFvtRtxpFmZF7AQXkRgX ZB//QE3kZE2uhK6/v64WBfwDutB0Dm8Y4FZMaRrQZjEn7HKVn8VTuQAIDRk0lcVYAHQg 72se9LGfvR6YO8HE2M6bTFln5yPrh8lmgYT65ALKqIOesPPgpy5J62I6k2O4mnaJylbo ZNUw198p+IzyCauo1b3R8l9Uu1uPLOC9xwK7STk0yhU6QWqVm2a4cw4LOP8RS2/FiCD5 lQPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=JojVpaY64o51qIZDPqF71FhlJiq7HF2eSWwuv5RUQxE=; b=jVIF+ocRte++quKOcu2VxUSApbSYcPklOO0iGiQIoX/UmtccCtg1fi9BvwXMCnSXeR RFLW5tukxOYJioFdO70Q5peFWLvHCFUrZv9Zrqp/VXS+0Lv2jbvC62Ffti3JLBvZz0SV 8pu6CZy7gaJ91AMny/K9PtFFGkriePMD0xwzHkG0JJw7ds2rLNUo2y3mXx/0NwfI6WvG t+3Upb5W3OtOnHaXsDeiOuYQmlGTDhlRKp+Nom1N++nlC6UsVbpj3e+I8hyoLaLDO5Jc RLqzFerYAfMmsuNCxbmUTYrGmnVeqIImYGry4sI+gIQ8dctUlcfyocJtZK8qwWQcQB1p vfZQ==
X-Gm-Message-State: AEkoouskffnp1D3WElevn9UODdVisYjZ83thlBvBgKtS1U78d/lj0OdeQgT5GgTl/vuXNA==
X-Received: by 10.194.81.137 with SMTP id a9mr57405167wjy.106.1470158894481; Tue, 02 Aug 2016 10:28:14 -0700 (PDT)
Received: from alans-mbp.lan (188.201.125.91.dyn.plus.net. [91.125.201.188]) by smtp.gmail.com with ESMTPSA id r13sm4003123wmf.12.2016.08.02.10.28.13 for <multipathtcp@ietf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Aug 2016 10:28:13 -0700 (PDT)
From: Alan Ford <alan.ford@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_124DC2A0-CAC0-42AC-97C5-12479149F678"
Message-Id: <EB6FDE58-F9A7-48CD-B55C-E3E9270C6017@gmail.com>
Date: Tue, 2 Aug 2016 18:28:12 +0100
To: multipathtcp@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/KeGyCgY9CFMg6pce3Wwvlx4t_eA>
Subject: [multipathtcp] Application-layer Authentication
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: Tue, 02 Aug 2016 17:28:19 -0000

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