[Cfrg] Re-Post as non-html mail: Additional questions to consider for the PAKE Selection Process

"Björn Haase" <Bjoern.M.Haase@web.de> Tue, 18 June 2019 20:05 UTC

Return-Path: <Bjoern.M.Haase@web.de>
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 53A0112023C for <cfrg@ietfa.amsl.com>; Tue, 18 Jun 2019 13:05:19 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=web.de
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 UOB3ovVnfLNM for <cfrg@ietfa.amsl.com>; Tue, 18 Jun 2019 13:05:17 -0700 (PDT)
Received: from mout.web.de (mout.web.de [212.227.15.4]) (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 6964112003E for <cfrg@irtf.org>; Tue, 18 Jun 2019 13:05:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1560888313; bh=ZPMx2AdbGwCmn8oyotZbappt8KueeIr0/yhUH428xLE=; h=X-UI-Sender-Class:From:To:Subject:Date:References; b=eY5RpyTXfs1qBIHB7HptyBqEudZr3KtjvBgAElB2OgHeAPwtijr1V7tWDiAFpA1MU Kt2OVC3MWDe5/8vke2TZkJBO4VQFrX+MNZipGQwVQ/5oTDeqg14RSdV0ntU6HW0k0j /7h9EBJYNjs11CREYj6kJJ6vegP2Eo4+pNc47+0E=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [178.2.114.231] ([178.2.114.231]) by web-mail.web.de (3c-app-webde-bs39.server.lan [172.19.170.39]) (via HTTP); Tue, 18 Jun 2019 22:05:13 +0200
MIME-Version: 1.0
Message-ID: <trinity-702d86ad-6eb6-492e-a227-177a7f412cf7-1560888313297@3c-app-webde-bs39>
From: "\"Björn Haase\"" <Bjoern.M.Haase@web.de>
To: CFRG <cfrg@irtf.org>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 18 Jun 2019 22:05:13 +0200
Importance: normal
Sensitivity: Normal
References: <249D87DF-0448-4BD1-A3A6-E9E88B0A4E87@live.warwick.ac.uk> <trinity-6ee830b9-216e-4c37-abd3-3b323c6f9018-1560877773355@3c-app-webde-bap22>
Content-Transfer-Encoding: quoted-printable
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K1:z5iCFgIQyFOvwbpMYxIzBnICIbOtdG83JNyQjtY+BGYiCqotjZIp8FdHo09xe4BPYeHkp b+xUegEMWb7SfrUsaHZ3bLaW6LgHDqhlhKIWr6LeKmq7K5t69RqG095Ka58/ZqY6kyZDVvZJnO86 1IQT8ceijKAdtlWFpwV0S4ht4seG5a7438xRrrArwazomm7w/Q532wo+sUxF6py6r3l5oxxpwJWI W+oXJ8ChxQS7W8lFn2yuIqabeMbUKCfxv4dItXAOkV8rbCOA+3OCG6BMj0RuMK0WBPA9E4c4ccAc PY=
X-UI-Out-Filterresults: notjunk:1;V03:K0:sfUeYaMxIPw=:CPyxow5BI/o191nrEF2fBs 3oRAsQREdN0rsb/Z+i/FxbUCqL4ZqoOjn6BJiRKq0YXiiraSXx4pbsLY7Mah63LZLyHKMQJST 9jACi7tOs0yc9jTmjlJRJiQSLyKUs6WvUOcvvwV2QzR2GgnImR9dOizkDyWGOxxfBCe4/7cNU XB4QdTwhHjY9fiY/GLhLxvh+dzgBWJbpdQ9ll806ns7EO5fPGSEcXVOhe4IOuUbjVUz51uEDS fgyp/Pw0jBMiLajq159npp/fNkEtDdjaWb1UffsF00inTGqu/SsKq49Tsz3q1Gf526A4LHrC4 en0xcUephEAyxrlUc6yzwSs1+lMv9rMgvLvkuCFyqDFeg4UfUzjBDdt36bt8IIKrKlVEgxg8n r2sB5PyoKD2+wUzHlWYfefT+C4SEVFEoKUf3T9xJkYml4090r9SuSJ4JK8v/ce2mgzkrVtUAc rLZs4oEr0uRWZlGXKNL21ib3odQdazaqa9kAmMRrZGj/vgmNkcLKTECwpDgMOR4t2LaplA66J MWWhXVmFTckCu+AwFwZ4PSzSNElS0m70d39Yz2298S4G1zg3DOYmOD2HwTL7gcvlOuboHSEcn 3e7eopq4CB8/EXYJzv16Do644bOWtFtcCAr+eGIIryKrNvvAL0zMEOqQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/SBLjjvjdT6q5ZSkWWHQHOlySevg>
Subject: [Cfrg] Re-Post as non-html mail: Additional questions to consider for the PAKE Selection Process
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, 18 Jun 2019 20:05:19 -0000

Dear CFRG,
 

I would like to come up with the following suggestions
for structuring the PAKE selection process.
When re-reading earlier discussions on the CFRG mailing
list, the topic of PAKE protocols seems to have
led to controversial arguments.
 
One reason might be that we don't have a common
understanding of the target use-cases and application
requirements.
 
I had a number of off-the-list discussions with several
people, including those who have nominated candidate
algorithms and wrote RFC8125.
 
What I have taken with me from these off-the-list
discussions is, that there seem to be several
use-cases with different and largely contradicting
requirements.
In the off-the-list discussions I did identify the
following two main use-cases described below which
I have and numbered U1 and U2.
 
In the discussion process we might come up with some
other use cases, However I expect that likely we will have
also very similar applications in mind, so that we might
be having 3 or 4 different application settings.
 
I would like to suggest that in the process of the
discussion we all contribute to a growing common list of use
cases and applications, such that we could discuss the
respective advantages and drawbacks of nominated
algorithms for the different scenarios.
 
 
As additional question for the PAKE selection process
 
I would thus like to add the question in addition to the list in
RFC 8125:
"A nomination SHOULD specify for which use-cases the protocol is recommended."


####################################################
U1) PAKE as a more-secure replacement for a
    PSK on a machine-2-machine interface.
####################################################
In some applications machine to machine interfaces
need a first initial trusted setup, say for
connecting a device to a WIFI router.
The initial setup might involve typing a "join code"
using a HMI unit with strongly reduced capabilities,
having maybe only three buttons. The key benefit
of the PAKE in this setting is, that a high-entropy
"join key" could be replaced by a lower-entropy
"join password" while improving security.
Similar needs show up for initial security
configuration on a small sensor node in an industrial
plant or for a join operation of a small sensor node
with some cloud server application or wireless sensor
node network.
#### U1: Derived requirements
- No need for individual human user names and accounts.
In U1, PAKE is used for somethint that should actually
be considered a machine-to-machine interface.
Specifically for U1 there is no need for several
accounts with possibly varying authorization rights.
For U1 the PAKE does not need to transfer a user name.
- Tight performance requirements.
The second aspect here is that performance
requirements might be extremely tight.
For instance today the join operation for a wireless
HART(c) industrial sensor node network is based on
symmetric primitives only for performance reasons.
The small microcontrollers had been assessed to be
incapable of running asymmetric crypto.
Note that for similar reasons for implementations on
tiny microcontrollers such as a Arm Cortex-M0 or 80C51,
the Bluetooth-Low-energy Standard in its version
4.0 had dropped any asymmetric crypto which resulted
in severe security issues.
 
####################################################
U2) PAKE for securely accessing a remote HMI
    interface server (e.g. a web server) without
    configured WEB-PKI certificates.
####################################################
More and more devices, such as home-automation
surveillance/security cameras combine the needs
for security/privacy with the customer desire to access
the HMI interface by remote handheld units with
using conventional off-the-shelf tools, such as a
web-browser.
As-shipped, these IoT devices will not come with a vaild
WEB-certificate allowing for establishing a conventional
TLS link providing MTM protection.
Similar use-cases show up in industrial automation
settings where devices such as sensors increasingly
come with IP-protocol or even wireless direct internet
connectivity, where already the initial configuration
login is performed over a vulnerable wireless link.
This type of server device might be physically accessible
for adversaries. (e.g. a surveillance camera at the
house gate) and often might not have ressources for
calculating state-of-the-art password hashes.
The HMI units would be tablets/PC/Smartphones with
comparably powerful computational capabilities.
There might be more than handheld HMI unit such that
individual configuration of several HMI units is
not desired.
Often there might be several server devices (e.g.
three cameras at one house) which commonly are
configured to the same user passwords.
#### U2: Derived requirements
- The login is of conventional "username/password" type
with possibly several users having different
authorizations.
- Because of physical accessability the user-login
credentials should best be protected in secure elements.
At least use strong password hashes should be highly
desirable.
- A convenient method for synchronizing user credentials
between a set of servers is desirable, even if a centralized
management infrastructure might not be available.