Re: [Cfrg] My review of the four PAKEs

Björn Haase <bjoern.haase@endress.com> Wed, 26 February 2020 10:21 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 B2B293A1251 for <cfrg@ietfa.amsl.com>; Wed, 26 Feb 2020 02:21:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=OzZojzzz; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=endress.com header.b=dKjIyjan
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 8Ews40zrH1Yl for <cfrg@ietfa.amsl.com>; Wed, 26 Feb 2020 02:21:36 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00070.outbound.protection.outlook.com [40.107.0.70]) (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 206133A124F for <cfrg@irtf.org>; Wed, 26 Feb 2020 02:21:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endress.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+pMHu/+262sWE0aN2+QuL1RdXQhAexTdhIdSBhSFipo=; b=OzZojzzz6YQj82uyH0upl4f8Q53PwcZK4ISYJNVYcXZctaVP03X78Ewy5ZO8baPdtrZ+owton89TmGOq/57LbcrnS7HzunliVKcQi2/lRTBctOQT5ZHbP/7z+Mo1I957mPo0wFJEr0q9RuRr4c+wH3KDPqPoFsezdKb4y+VM1JY=
Received: from VI1PR0502CA0025.eurprd05.prod.outlook.com (2603:10a6:803:1::38) by HE1PR0502MB3097.eurprd05.prod.outlook.com (2603:10a6:3:d4::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18; Wed, 26 Feb 2020 10:21:33 +0000
Received: from AM5EUR03FT027.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::207) by VI1PR0502CA0025.outlook.office365.com (2603:10a6:803:1::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14 via Frontend Transport; Wed, 26 Feb 2020 10:21:33 +0000
Authentication-Results: spf=pass (sender IP is 40.113.82.155) 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 40.113.82.155 as permitted sender) receiver=protection.outlook.com; client-ip=40.113.82.155; helo=iqsuite.endress.com;
Received: from iqsuite.endress.com (40.113.82.155) by AM5EUR03FT027.mail.protection.outlook.com (10.152.16.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2772.15 via Frontend Transport; Wed, 26 Feb 2020 10:21:32 +0000
Received: from mail pickup service by iqsuite.endress.com with Microsoft SMTPSVC; Wed, 26 Feb 2020 11:21:32 +0100
Received: from EUR01-HE1-obe.outbound.protection.outlook.com ([104.47.0.53]) by iqsuite.endress.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Wed, 26 Feb 2020 11:21:31 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HVU4bbkh2a/Ly6nRUf/lmzE299wUJqyuDdJTbvAqvMC6Ynh1LauPxbpPPdNUD1Aj/Ao3140DRYoWe4yHDMKJkPfiEnQw/z1k56A/CAZDFMRP0X51Qp21ldxM5W3YbdbprpclhFTt0R8sVPp+jGBVaEdwf1l2+Fycy+Q/AuKys+6QEzvr4UYph8++XxcIAf9Tw/69ar/cEzhXJZjvDRMvUtystQYKAFHSU8Pp3vDuMVCYo/eas92my0weCOTfRXlQyQWQh8CiotHU9ClUAWIt4rHeno8cO7jyOoZC1twtWlAV0NgovXDDnJpBaz36foUpn4JpdZZL/DfpzwqNxemDJg==
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=QANK9r+r+2hzKwYjTcDWfX8ED9+V2JUqinx1MpI6PKU=; b=B81T+D7nEUFcSp7jYYU6V6r80+9TQT3KNZRBNOjsVu/idM2MjNEzAu/v/KD0RzPjpthl40ZAu9W4tMJo2v/0YgQBEgKb5jrvTAKnu+/ohsSVNLx2v+MElMKpCkQo7UMI8M6Fp/QCOEWoxu5yyk9cUkgNlyEZfqyD/kftB0z9UIKUFHYQLXl4V9hZE4IT5MXRIXbKx+tYCUPaNFR9LbJz+Xh8JZAHvUxsEEtnBh4YuEmOB2xdMOMc/7TeIW4Y0CRCR8TqgmIe/BGQt04gCCRIvaUI8RTlS5IV8Fj3FJeXYsP9uQHp4bvo1mCKzXVneLxw05f+0ebjnD9lnOe8N3FIBg==
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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QANK9r+r+2hzKwYjTcDWfX8ED9+V2JUqinx1MpI6PKU=; b=dKjIyjanNztO5vubEKIZTKWLn0+6XkmsTgA1Mda89iDyI/Art0qZx707o4tmo1NuuyrAfztUW1kdGRSelF/mxkcdz4NU9Uf3XnXycR8NyzD8VIR/hRg/ZmPSyZWm9g3mlsxQ9o2wpNpH0shsTrgMnvJeMhEoYnjBPyTHoU+gc6E=
Received: from AM0PR05MB4786.eurprd05.prod.outlook.com (52.133.57.143) by AM0PR05MB5634.eurprd05.prod.outlook.com (20.178.114.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Wed, 26 Feb 2020 10:21:29 +0000
Received: from AM0PR05MB4786.eurprd05.prod.outlook.com ([fe80::b16c:5fe0:ad0b:81af]) by AM0PR05MB4786.eurprd05.prod.outlook.com ([fe80::b16c:5fe0:ad0b:81af%3]) with mapi id 15.20.2772.012; Wed, 26 Feb 2020 10:21:29 +0000
From: =?Windows-1252?Q?Bj=F6rn_Haase?= <bjoern.haase@endress.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer=40cisco.com@dmarc.ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: My review of the four PAKEs
Thread-Index: AdXsjcoW/Sp2K1k1Q+aJwc9eGATz8Q==
Content-Class:
Date: Wed, 26 Feb 2020 10:21:28 +0000
Message-ID: <AM0PR05MB4786CC5BDB29292A2A86A78C83EA0@AM0PR05MB4786.eurprd05.prod.outlook.com>
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=2020-02-26T10:21:26.4516771Z; 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=d84f6da3-e049-4326-b7ef-eea247531f66; 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: [93.240.145.106]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-Correlation-Id: b0a700d0-27d3-45a6-6e42-08d7baa5a6c8
X-MS-TrafficTypeDiagnostic: AM0PR05MB5634:|HE1PR0502MB3097:
X-Microsoft-Antispam-PRVS: <HE1PR0502MB3097E5861926D7436DCE47AF83EA0@HE1PR0502MB3097.eurprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 0325F6C77B
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(376002)(396003)(346002)(189003)(199004)(66574012)(110136005)(316002)(9686003)(8936002)(55016002)(71200400001)(8676002)(66446008)(81166006)(478600001)(81156014)(966005)(26005)(186003)(5660300002)(86362001)(2906002)(33656002)(66476007)(66556008)(66946007)(52536014)(7696005)(6506007)(76116006)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR05MB5634; H:AM0PR05MB4786.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: endress.com does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: P0gxKZajB5SGftz/P55FFYwikdHjCQiPan4VoWOaimGrLuOa1uDDizMvslcE+UmGe5A9p+araVIkjEicri0x4bUiU7nSqp2kQDiE4KjdNBiHw0JxMXGmupAHBbXtmSCGFqoVlXDQixJ1J3im2BMmpsLN5D2Qmqvnn5G/ugpkGPSbHAT41hu8iFl6zNXmYV6WvwMX6ZjPZ0Mt8ohtxKc/GznnAFNHMUUs1MNsO+PjQeHkcRb6Aic02dfjHhSjE6tMsfB8QsGeRoC/FA+3XC0fZIfbj8YLNFwg2EATU1S525QlUYamicTC1WPViMWtjWI+8NYsMoM6FsbHsEJZXWQzTTpUXzNbNXlejAsqS4NOggnXwCviHxX4aqoPU3SeOIlydAm0y5hfMt05+a8wIFyAveOnKNHqT+iXqOUJ9jPhr2XW5FT3YJNMeoMXPCWgkytcCNdZcZt+Xh4CSYj/HGImThH6K3alGigipzIprPyMj27wWh8xKSgz0vaq6l0ZGJ5z8pvf4S7pcz3JdUZQ3W98lQ==
x-ms-exchange-antispam-messagedata: GDV7Ymig8mSaFN1qG4PkwlEmQMppaKISAQ9lhYg7CYmbeMP0EnBn5TgFFVEGOUMTMFgOBy/UOo1wN091E4BBkdn4r4d2VrYNcsf+nHqfHdH338woAPCvLYBqpYjcYrkZKYNu9RTREqrxIYCOWfPHCA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR05MB5634
X-OriginalArrivalTime: 26 Feb 2020 10:21:31.0474 (UTC) FILETIME=[839A5B20:01D5EC8E]
X-Trailer: 1
X-GBS-PROC: Su519rGUQRzW3/jPgXahqNML6237xD/WUzQciQ67I1I=
X-GRP-TAN: IQNE01@849E68C1C1AB4715A38D14323A2A546F
X-iqsuite-process: processed
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT027.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:40.113.82.155; IPV:; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(396003)(346002)(136003)(199004)(189003)(81156014)(81166006)(8676002)(86362001)(110136005)(316002)(52536014)(8936002)(356004)(70586007)(70206006)(5660300002)(15974865002)(186003)(33656002)(6506007)(55016002)(9686003)(26005)(336012)(66574012)(478600001)(2906002)(966005)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0502MB3097; H:iqsuite.endress.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 8d8a32e2-6fac-4d87-204a-08d7baa5a4f6
X-Forefront-PRVS: 0325F6C77B
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 2eYPrPuja80D3m5AbgQnC+3mptUqoVfgSAV6hbp7x6pS14LZtZbRNEy9EupGOXnG3ml1Jk0tG/r81jRED/RX9nFcwM/jBetgY6n3qtNtEnkXul8x3Wjkss72apKR0vZ93+GeYLDkSBgi2V9R4IBKWRvpdystMO0C1CVKTzaYOLzIRJMpQj7dqIRhsJJlVNx2Lyuyo6a5h+Sx+Jcp+1GGDoa8hX5M4P2KkFvWjgNiF2pbZysnNwcztAVL5487OaPN8VQvqBeDWI5iSNRrHV6p3u35wMCOUmH4YHn/5c0h1bXkiFqqOa5VLrv2BUMAi89gQLXFItW3yCPLH51jhQ3uGbWe1N/t+rW4k6wwB/IPdwGdjLpnh6UC/HiyWX9u2NnTu/YuB98LJTUfqZK3TFVMyeiMDOgHYKTlnH1jnZw9m5jBExRXUsgH+qxUFtetNdJM5MIJ5RoVkda8LgmdOq3PEn7jb5G5cFvDqDt3geql2A4f1JSIO21lc5TCGu3i3cn9Ptk1VG2EP6CX3wyvfDqaGw==
X-OriginatorOrg: endress.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2020 10:21:32.6177 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b0a700d0-27d3-45a6-6e42-08d7baa5a6c8
X-MS-Exchange-CrossTenant-Id: 52daf2a9-3b73-4da4-ac6a-3f81adc92b7e
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=52daf2a9-3b73-4da4-ac6a-3f81adc92b7e; Ip=[40.113.82.155]; Helo=[iqsuite.endress.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0502MB3097
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/NHmpU6QQLY59tnzUTOa4UCEAbUM>
Subject: Re: [Cfrg] My review of the four PAKEs
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: Wed, 26 Feb 2020 10:21:41 -0000

Dear Scott,

thank you for your careful review. I agree with all of your assessments. 

Specifically I agree that for the use-case of a direct integration of an augmented PAKE 
into TLS 1.3, OPAQUE is better. The feature that OPAQUE requires one round-trip less 
than AuCPace might outweight the single practical disadvantage that I see (the *large* 
size of password verifiers) in many scenarios.

Still from a system-level architecture point of view, I believe that there could be 
applications, where too neatly integrating the human-user related mechanisms into 
a transport-layer level component such as TLS might generate headaches.

I still would like to suggest to consider/discuss the following points.

- The augmented PAKE use-case is in my opinion directly linked to human 
  end-user authentication. This is different from the case for balanced 
  PAKE, where I also see the application of machine-machine interfaces.
  
- This means that a TLS subsystem using OPAQUE might have to maintain a
  quite close and possibly intricate link to software components that a)
  maintain the user credential database and b) the applications that
  use the TLS channel.
  For instance, TLS would have to provide interfaces to the application
  on the server side for retrieving the information which user has 
  successfully logged in.
  
- For many applications, I also see the need of a lot of flexibility.
  Sometimes users might not want to enter passwords but use
  Security tokens alone.
  Others would like to use username/passwords, and possibly
  TLS with OPAQUE.
  Other might require supporting two-factor  authentication 
  (TFA, username/password + security hardware).
  Managing all of these 3 settings while maintaining the same software-level
  structure might require not only require TLS cipher suites for OPAQUE but also
  TLS OPAQUE+Security-Token and TLS-Security-Token.
  Possibly for TLS this could result in a complexity that is no
  longer practical.
  
- I also see some unsolved issues for applications that need to migrate an 
  existing user-credential database to OPAQUE.

My personal assessment is that too closely integrating human user-interface
related complexity into a component such as TLS might generate trouble ?.

Here I see advantages for a more modular approach, as I had also tried to 
sketch in:

https://github.com/BjoernMHaase/fe25519/blob/master/Concept_For_Modularized_PAKE_integration_into_TLS_20190726.pdf

Basically the idea is to try to keep the intricate complexity of human 
user-related API interfaces away from the transport-layer components such 
as TLS. Instead TLS would be focusing on the transport-layer aspects and
the intricate human-user interfaces would be integrated into software modules
external to TLS, e.g. in the style of PAM on Linux.

Of course there is the risk of integrating insecure options (e.g. the EAP approach
might be overly flexible). On the other hand if we are too restrictive/monolithic,
we might not be serving important use-cases.

In my opinion the considerations regarding internal software APIs and
the respective scope/responsibilities of software components such as 
TLS / QUIC / PAM would benefit from discussions with people also from 
outside the typical CFRG team.

I believe that at the end of the discussion involving the system architects
for components such as PAM, there might be applications that are actually 
better served by the a more modular approach such as AuCPace.?

I have already tried to enter a discussion with the PAM people, but did not yet
receive any feedback. Maybe some other people on the CFRG list have such
contacts or suggestions regarding this topic.

Maybe somebody else on this list might have an idea on how to get into
discussion with people that have the "system-level" and "os architecture level" 
hat on.

Yours,

Björn.


Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 


Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Liquid Analysis

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.
 



Von: Cfrg <cfrg-bounces@irtf.org> Im Auftrag von Scott Fluhrer (sfluhrer)
Gesendet: Dienstag, 25. Februar 2020 21:46
An: cfrg@irtf.org
Betreff: [Cfrg] My review of the four PAKEs

Summary of my vote: Balanced PAKE: CPace; Augmented PAKE: OPAQUE ...