[Cfrg] Additional questions to consider for the PAKE Selection Process
"Björn Haase" <Bjoern.M.Haase@web.de> Tue, 18 June 2019 17:09 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 13DE1120091 for <cfrg@ietfa.amsl.com>; Tue, 18 Jun 2019 10:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.975
X-Spam-Level:
X-Spam-Status: No, score=-1.975 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 L3Ou8KOF_7Gg for <cfrg@ietfa.amsl.com>; Tue, 18 Jun 2019 10:09:39 -0700 (PDT)
Received: from mout.web.de (mout.web.de [212.227.17.12]) (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 11E62120301 for <cfrg@irtf.org>; Tue, 18 Jun 2019 10:09:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1560877773; bh=+NA2SS+wE6iXiwj6g/UzekVIS1Qe7wkfn5VDPgrXGD8=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=CWnzNcnrcK33faM4Te0fs19W0YXFeFGPtR95b8YhCoCj+3MEjbYsVpeSD+0gUoQTd gUcF6TaupFvU6UqXT+kEVhNjj0Mkj1VMbSQwYTabk5ZrCN10N06ES9tL50C7LF1wno JEGCsi9Uu0zeEKdC6knWdeNkEMNboZxTIvwW3n/Q=
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-bap22.server.lan [172.19.172.22]) (via HTTP); Tue, 18 Jun 2019 19:09:33 +0200
MIME-Version: 1.0
Message-ID: <trinity-6ee830b9-216e-4c37-abd3-3b323c6f9018-1560877773355@3c-app-webde-bap22>
From: "\"Björn Haase\"" <Bjoern.M.Haase@web.de>
To: "Hao, Feng" <Feng.Hao@warwick.ac.uk>
Cc: CFRG <cfrg@irtf.org>
Content-Type: text/html; charset="UTF-8"
Date: Tue, 18 Jun 2019 19:09:33 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <249D87DF-0448-4BD1-A3A6-E9E88B0A4E87@live.warwick.ac.uk>
References: <249D87DF-0448-4BD1-A3A6-E9E88B0A4E87@live.warwick.ac.uk>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K1:+f1s3gUsR37ujiSjLUTl5bPkdnFMsPCWFj4RSOoE23pLEPREeEqrLQFSYf1wgP1KcBB9P pxglOjoBxasBbTglDPzwWINLbKpRx/d6TSCeBtJlqx1SenC0UCNZRfyF/wE9jrvo/gGELC/v6wLp uhqAI9WG6LK8NiDRU9Z0dTLU5k/iAc8eQDG4zcogzm7xAIqb9pv+nRbvmuR/xwo67LXonGifxC6x pRA7HOyfRu7JWVr+wcCaP0IUxJv9w0YNbRqmSwbZZETlHvCobhl4sPZztAveTbbVXkKk1j+ztokv HA=
X-UI-Out-Filterresults: notjunk:1;V03:K0:0p3AdlhOX1o=:NlcCQaYam3oFYdwa2zmRJe 9JOPUBH2PmkoJP/UDVvHYDX4pWNOeQmlpyhuvDs7Z8FwzcgV3+TQ173KM5oTpKTBq71XkIEMY eFD/nn/mLOCcQAlK0vmmugUt6X8iXfdqObkEPkdPDzdvcw1Kw+IXaL6Cb97QkhtTEnBICZxfz 5XqV7wcqVFpDtnOYu4q+Q5eYn8Sfe6XcDGjzMRjc2cUXx3efFNKwC9sXeRKwLRQJog6bO+hpq 0u8cFy4j6TF3AIyTqb+iDvJXHSyuvM102JX/ff4xTAaWoBp5oTr0wOGTq+/rjHVZfvWlIFHua ddqJ7EX3Jz4JZG/blcsWe2W5l4zaCiyvOohdd9uK9bT/A25bfroc2o/jYmPgZnENHek8cNfbI 8b1kCk3Bcl/hPFC29a9cpcOJBUnXfZDYzunba8ID7b+I7Y38jimN5JwXn/n8K/U8R34kr6hEV h/vfAbyHlarL5/WJZVdde6l950oM5wyMaH2sfIzLKS20f5uBE3zCvQshdnX1osehj13uea+5d j6tsYd18bQZ/RMSDyybrJ+IvMnwagQ0X0zUE5ZOaWOqIQ2rLiwXp9AEO0yHa/LxOTbgwcMfBl 3IYJtalEOBD8lhYZgdKxgO90SJj9Z5YQ+soOHIEpChTtGTyW7HCqocDw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/wr2Ag4fWBBIr1S3mG3bIi9D1KOQ>
Subject: [Cfrg] 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 17:09:41 -0000
for structuring the PAKE selection process.
list, the topic of PAKE protocols seems to have
led to controversial arguments.
understanding of the target use-cases and application
requirements.
people, including those who have nominated candidate
algorithms and wrote RFC8125.
discussions is, that there seem to be several
use-cases with different and largely contradicting
requirements.
following two main use-cases described below which
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.
####################################################
U1) PAKE as a more-secure replacement for a
PSK on a machine-2-machine interface.
####################################################
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.
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.
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.
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.
####################################################
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.
WEB-certificate allowing for establishing a conventional
TLS link providing MTM protection.
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.
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.
comparably powerful computational capabilities.
There might be more than handheld HMI unit such that
individual configuration of several HMI units is
not desired.
three cameras at one house) which commonly are
configured to the same user passwords.
- 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.
- [Cfrg] Additional questions to consider for the P… Hao, Feng
- [Cfrg] Additional questions to consider for the P… Björn Haase
- [Cfrg] draft-irtf-cfrg-hash-to-curve // More effi… Björn Haase
- [Cfrg] Repost as non-html-mail: draft-irtf-cfrg-h… Björn Haase
- [Cfrg] Re-Post as non-html mail: Additional quest… Björn Haase
- Re: [Cfrg] draft-irtf-cfrg-hash-to-curve // More … Christopher Wood
- Re: [Cfrg] draft-irtf-cfrg-hash-to-curve // More … Adam Langley