Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // slides.

Björn Haase <bjoern.haase@endress.com> Tue, 23 July 2019 07:43 UTC

Return-Path: <bjoern.haase@endress.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB8712010D for <cfrg@ietfa.amsl.com>; Tue, 23 Jul 2019 00:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=endress.com header.b=0xXWOsya; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=endress.com header.b=GIjy3YMJ
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 19JOkpYl81IT for <cfrg@ietfa.amsl.com>; Tue, 23 Jul 2019 00:43:06 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20045.outbound.protection.outlook.com [40.107.2.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832351200F1 for <cfrg@irtf.org>; Tue, 23 Jul 2019 00:43:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endress.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SHXnPRcFuset8sdf/hBtjrnr63Pzg/veP49bBLQLNBM=; b=0xXWOsyaA/PIgvBF4kOVmTmU8O1nTDmKBKrO0mdepHbdo74Jpb8RAPM1J6whbGBE9M6rkGL3qJ/vx6T5ivs+wNXQJzNyn+GErmdRxsbmJENXBMX/+ckqZeIt0kasFTL0+zJkwAecpTsfHlVP/NEyan0TbNMDaGBFe1K/gFXYY2Y=
Received: from AM3PR05CA0132.eurprd05.prod.outlook.com (2603:10a6:207:2::34) by AM7PR05MB6821.eurprd05.prod.outlook.com (2603:10a6:20b:13b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Tue, 23 Jul 2019 07:43:03 +0000
Received: from DB5EUR03FT063.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::209) by AM3PR05CA0132.outlook.office365.com (2603:10a6:207:2::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2094.12 via Frontend Transport; Tue, 23 Jul 2019 07:43:02 +0000
Authentication-Results: spf=pass (sender IP is 13.79.242.66) smtp.mailfrom=endress.com; irtf.org; dkim=fail (body hash did not verify) header.d=endress.com;irtf.org; dmarc=pass action=none header.from=endress.com;
Received-SPF: Pass (protection.outlook.com: domain of endress.com designates 13.79.242.66 as permitted sender) receiver=protection.outlook.com; client-ip=13.79.242.66; helo=iqsuite.endress.com;
Received: from iqsuite.endress.com (13.79.242.66) by DB5EUR03FT063.mail.protection.outlook.com (10.152.20.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18 via Frontend Transport; Tue, 23 Jul 2019 07:43:02 +0000
Received: from mail pickup service by iqsuite.endress.com with Microsoft SMTPSVC; Tue, 23 Jul 2019 09:43:00 +0200
Received: from EUR01-HE1-obe.outbound.protection.outlook.com ([104.47.0.54]) by iqsuite.endress.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Tue, 23 Jul 2019 09:42:58 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EbAkUOz6HcK/QsqxEYbzSGXdqKQETkOiYika7FkIg1pMl8ExlE04RObcuvjbuGsZPRe5PP9uOBSFQ5PAso1jIemAqyntg1HteiSoc+svWQgwwaqyUFVgwVkUfy5VEafg+oB8ho3kWcdYc1Bnjj1NyRgTPZbADZ2e/2N3KIKbqI/QUuwY3L4W9lpJG7tmUapyOn6v6uStmyY4UaAWEaJ+BKgzrRZ/jZj7PWbdy9vIrrflCqfnedEv790gsp15IaXw61TiT7tDB3yxsZSFNOoZ6Be+v0dWB59B6MdxVgDX5PTCOuM2B18jr32rjcZnXkODGPaamiNv543o6FtR1YIGbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mca2lpKKe5pfiffWmXttm8e/vaRAsv4KV8aQ0ZxWEMU=; b=bHNG+kgR87lm4JMSSejX095TxXSIIXuZf9hj6bIgWzjHZSNw+qGIdzb4ABAOdWiJuQVqVUVTFT8Tz1TgzwTNdtW6NV+ha4ksm95BjFIl40fd9BEJSkfKCHq+R88g9Lwg3WDozaZNQv+BGovaiUOC8KuxLj+LOvPFJ0F1l0D0zWs2YZxZIrpNIp9GjeD3w85e6dkqMxpSRDCZ/T6iBb1YghsCe1jr+UjZZohCdq4u/5gqeoxqNK3lUBRg6woB1UXI6uCwNrcoN06MgvecxTRW1xwSG1wwJRjyBS4SuySXvTG8A/0OAx+ltMgd5apjzpGi/Kj/Js6d0VZnq8wlOQxKpw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=endress.com;dmarc=pass action=none header.from=endress.com;dkim=pass header.d=endress.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endress.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mca2lpKKe5pfiffWmXttm8e/vaRAsv4KV8aQ0ZxWEMU=; b=GIjy3YMJNOg/v6hoLdX3MngDCs9WIKkGRZlGH8LuwS0cJ9i71RfZBZuJlC4P7OdfbwLXVLNc4BEFHW0M68UJ4lGMsMhtcvB3SvjC+7LUjcH0XG0p2SKUvGipu4xwRReEoHfz92zl/poMc+dg49326VXo9Nfia3u3i0pFTy7KK7A=
Received: from VI1PR0501MB2255.eurprd05.prod.outlook.com (10.169.135.11) by VI1PR0501MB2624.eurprd05.prod.outlook.com (10.172.14.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Tue, 23 Jul 2019 07:42:57 +0000
Received: from VI1PR0501MB2255.eurprd05.prod.outlook.com ([fe80::d802:c0a5:12ac:dc2d]) by VI1PR0501MB2255.eurprd05.prod.outlook.com ([fe80::d802:c0a5:12ac:dc2d%6]) with mapi id 15.20.2094.013; Tue, 23 Jul 2019 07:42:57 +0000
From: =?utf-8?B?QmrDtnJuIEhhYXNl?= <bjoern.haase@endress.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Watson Ladd <watsonbladd@gmail.com>
CC: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>, "hugokraw@gmail.com" <hugokraw@gmail.com>, "steve@tobtu.com" <steve@tobtu.com>, Dan Harkins <dharkins@lounge.org>, "Hao, Feng" <Feng.Hao@warwick.ac.uk>, CFRG <cfrg@irtf.org>
Thread-Topic: How to circumvent the obstacles for PAKE integration into TLS // slides.
Thread-Index: AdU/0zW0G1cDrJm7THCybJ0GtxuGUAAGmVwAAEhbfIAABYhggA==
Content-Class:
Date: Tue, 23 Jul 2019 07:42:57 +0000
Message-ID: <VI1PR0501MB225501B52DC40DC41E6D590683C70@VI1PR0501MB2255.eurprd05.prod.outlook.com>
References: <VI1PR0501MB225515FC68BD4CBF7C6F904E83C50@VI1PR0501MB2255.eurprd05.prod.outlook.com> <CACsn0ck3AhxHeu6=vAf9CMNLJcjkC59jhWDdGD-RP03DNqCfXA@mail.gmail.com> <20190723042811.GL99187@kduck.mit.edu>
In-Reply-To: <20190723042811.GL99187@kduck.mit.edu>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Enabled=True; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_SiteId=52daf2a9-3b73-4da4-ac6a-3f81adc92b7e; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Owner=bjoern.haase@endress.com; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_SetDate=2019-07-23T07:42:51.6164845Z; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Name=Not Protected; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Application=Microsoft Azure Information Protection; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_ActionId=749a7b2e-86c6-4bfe-9ecd-114d8d7d914f; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Extended_MSFT_Method=Automatic
Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=bjoern.haase@endress.com;
x-originating-ip: [193.158.100.19]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-Correlation-Id: 4592cfee-b3a4-4518-7445-08d70f41640e
X-Microsoft-Antispam-Untrusted: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1PR0501MB2624;
X-MS-TrafficTypeDiagnostic: VI1PR0501MB2624:|AM7PR05MB6821:
X-Microsoft-Antispam-PRVS: <AM7PR05MB68216264A2DC32ADC9066E0C83C70@AM7PR05MB6821.eurprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000;
x-forefront-prvs: 0107098B6C
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(396003)(366004)(346002)(39860400002)(199004)(51444003)(189003)(76116006)(413944005)(7736002)(66946007)(11346002)(476003)(25786009)(256004)(26005)(110136005)(54906003)(64756008)(66476007)(66556008)(76176011)(446003)(316002)(66446008)(6506007)(8676002)(486006)(186003)(74316002)(99286004)(478600001)(102836004)(305945005)(52536014)(81166006)(6436002)(55016002)(2906002)(6116002)(2171002)(81156014)(33656002)(9686003)(86362001)(66066001)(66574012)(85182001)(14444005)(14454004)(5660300002)(71190400001)(71200400001)(53936002)(85202003)(68736007)(7696005)(3846002)(8936002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0501MB2624; H:VI1PR0501MB2255.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: endress.com does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info-Original: pdjTNWfcPejvhdPPl3qUaLNwsi/vYPk/NV5u89VdktHjM3ec3h5LpZYxPnmuLGCan/3AjLqvrqvImNmeTUj2ddgSKxohXkp3fIZu8dKs1bOnXlTbpzg3Wj7S1lIjRWnoJXuck/x36r4w6PGfdpkCTIFtEwTa68U7onTVGTBRnDtkLqx8zhW4nmNHa0LcC4+u9ZKRdudDfqDNQARXApLIVYUBqjBI+2bQpsRegAmh1pXnQqGR4BCURIG561tbZXO4o0JD7Btt+eWq+E41MomQ4nFIu/LBZpIJ8rNxuPbDf9A8dp40kqPQRdD8YqLN/h6brEPWFHJwE3YH14zs+Pn0pDypdHwDaVN5fdb9QTx7B/IPMkI0Wg6JixnG5Ck/Wfd1NbjMbFw45pF7NcUYoJ+k2DS+8MUgIvk0a0c5SuNiaa4=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0501MB2624
X-OriginalArrivalTime: 23 Jul 2019 07:42:58.0970 (UTC) FILETIME=[3FA7EFA0:01D5412A]
X-Trailer: 1
X-GBS-PROC: pjdUDgD50Duv7nGNurBPMZHYyi+RTnaGepQRiMqGTmk=
X-GRP-TAN: IQNE02@8969A1F735CC410FB0C80281E287F7DD
X-iqsuite-process: processed
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT063.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:13.79.242.66; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(396003)(39860400002)(346002)(2980300002)(199004)(189003)(26234003)(51444003)(356004)(8676002)(478600001)(3846002)(2171002)(54906003)(413944005)(110136005)(7696005)(9686003)(76130400001)(316002)(5660300002)(4326008)(26826003)(86362001)(55016002)(53936002)(336012)(50466002)(70206006)(14444005)(23676004)(2486003)(305945005)(25786009)(68736007)(106002)(6306002)(6116002)(69596002)(52536014)(66574012)(7736002)(70586007)(14454004)(47776003)(81156014)(33656002)(81166006)(436003)(99286004)(85202003)(76176011)(8936002)(11346002)(476003)(2906002)(126002)(486006)(74316002)(26005)(66066001)(186003)(6506007)(85182001)(15974865002)(102836004)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7PR05MB6821; H:iqsuite.endress.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 829fc683-b47a-41df-d91d-08d70f416154
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(710020)(711020)(4605104)(4709080)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM7PR05MB6821;
X-MS-Exchange-PUrlCount: 2
X-Forefront-PRVS: 0107098B6C
X-Microsoft-Antispam-Message-Info: jHm0lhQbO5BfzbVlxrpendt+tqRtMejpKiF++nhLzp5uMYBAvJlFguT2faEIN+gXa9wMWEDSQN87z10L1cRRnQprQOzfZRxQrCwLFfEon2RCb5twF7711sHY/GDf9vCo8HMGejZ9kRGdFHJ+1Q7/e1xX3JE9DiCbETahVPd0Eenmx16r/uXYRTDQ5LRuZxvEbeGmGuH+B86kWIPZdysoW3duCz5KOVB19BPAxR6zT1N/DLxfKtY69jWgwiX2Mk4TIIhBSTsWZZynTqB4cjRwd1s+y4301jaxEm2Ck3hALBXsB+BttZt1sO4kJ6IuKCVmFKXuL8lAzfQAY9vtMmNnZpWeA7P1fA55gxQLbYUzHl53Z+yCTQQkI3Fb+9xdxwHzLjznfqlrnk3comWNbQP6rWiMmtaDkMeJ9iDtNRheniI=
X-OriginatorOrg: endress.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jul 2019 07:43:02.2124 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4592cfee-b3a4-4518-7445-08d70f41640e
X-MS-Exchange-CrossTenant-Id: 52daf2a9-3b73-4da4-ac6a-3f81adc92b7e
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=52daf2a9-3b73-4da4-ac6a-3f81adc92b7e; Ip=[13.79.242.66]; Helo=[iqsuite.endress.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR05MB6821
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ibkONV9xhlBpAY4gW7vx4W-_5sA>
Subject: Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // slides.
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 07:43:10 -0000

Dear Ben,

>To build on that, a big motivation for wanting auth at the HTTP layer is
>that most generic web servers aren't going to know *at TLS handshake time*
>whether a given client is going to need to authenticate for the HTTP
>requests that will subsequently be conveyed over that connection. 

I fully agree. When saying this, I think that we might better be careful not to mix-up two aspects:

1) The human at the client side mostly wants to be sure that the server side contents are authentic, from the very beginning.
2) The server side requires authentication often only when operations with privileges are requested.

What we have here is something similar to what I'd be calling "re-authentication use-case" for password checks in a connection that is already established.

Moreover I see differences regarding the use-cases A  "End-customer-managed web servers (IoT)" and  B "Conventional Web-Shop use-cases (Web-PKI)". The main additional benefit of PAKE for use-case A is that the server-authentication (1.) above) is provided also without the need of Web-PKI integration of the server.

I think that one might best try to realize the maximum possible re-use for authentication mechanisms in both use-cases A/B. Again this might be a reason for "outsourcing" all of the user-handling related stuff outside of the main TLS body. Also for use case "B" it might be worth to consider pulling out the password handling out from the main html application. Maybe one could use the same mechanisms of a "user authentication" module that we would be using for PAKE? For doing so again some kind of channel-linked tunnel mechanism through TLS might be helpful/necessary.

Yours,

Björn.

P.S.: I have moved this discussion back to the main list. Sorry for starting this discussion with the "not yet publication-ready" slides.


Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
bjoern.haase@endress.com |  www.conducta.endress.com 



Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

 
Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

 

Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.