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

["Björn Haase" <[e-mail]>]

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.