Re: [Crypto-panel] [CFRG] Request for review: OPAQUE

[Hugo Krawczyk <[e-mail]>]

Here I want to refer to Björn's message below as well as Chloe's
previous email regarding whether "PKI-freeness" is a suitable description
for OPAQUE.

I think we can all agree that the user wants to make sure it is
establishing an account with the correct server, and the same holds for the
server with respect to the user.

So, there must be a way to authenticate each party in a registration
operation. This means that we need authenticated channels between user and
server at registration (there are exceptions, e.g. in cases where the
server does not care who the user is, but let's not be distracted by these
exceptional cases).

Is PKI a system by which servers can authenticate to users during
registration? Yes. Does it mean that this is the only way? Certainly not.
An employee may be required to interact in person with a computer at
their employer premises to establish a password. Or a pre-shared key may be
distributed to users for authenticated registration purposes, etc.

OPAQUE does not prescribe how this authentication happens, and certainly
does not make PKI the only means of authentication during registration.

Moving to the "login (or online) stage" in OPAQUE. Here PKI has no role in
OPAQUE's security. OPAQUE bootstraps secure sessions based solely on the
user's password and the user's state at the server. The AKE protocols in
the OPAQUE draft use public key cryptography, with public keys defined for
the user and server. However, there is no reliance on any third party,
including CAs. It is in this sense that one may refer to OPAQUE as PKI-free.

For completeness, let me add that the use of PKI (e.g. TLS)  during a login
session may have a benefit: Hiding user identity (and other account
information) transmitted to the server when initiating a login session. But
it has no bearing on the security of the password authentication or key
exchange security.

Regarding Björn's comments on the fact that OPAQUE requires interaction
during password registration. That's correct, although I don't see why the
need for interaction precludes the use of the word 'offline' when referring
to password registration. But this is a minor linguistic issue (not my area
of expertise anyway) so I don't think it is important to discuss here.

Björn also notes that in some protocols, one could provide the user with a
QR code that when scanned would help register a password. If the point here
is to provide a way for secure authentication during registration, then
this is possible also with OPAQUE: Just give the user a QR code  that when
scanned results in a pre-shared key that the server knows too.

However, Björn seems to be more concerned with the interaction part and
he raises the question of

> IMO it might be worth considering, whether a single-flow registering
operation flow might be added to the OPAQUE draft.

This is indeed possible. If someone (that the user can trust) gives the
user (e.g., as part of a QR code) the public key of the server, then the
user can generate all the needed information, including the OPRF key, by
itself without interaction. Of course, it will now have to pass all this
information to the server which assumes a (at least unidirectional) secure
channel. Maybe something like this can help in the air-gap setting.
However, this may not be the most secure way of running registration, or be
a common enough setting to add to the current OPAQUE document. But if
considered useful, we could document such variant separately.

Finally, Björn raises the question of whether the internet draft (and
future RFC) should specify ways of instrumenting password updates. My
instinct here is that there may be too many settings and situations to
cover. However, there are two main straightforward cases. If it is
something like a periodic change of password where the current password is
not suspected to be compromised, then just establish an OPAQUE session and
run a registration procedure over this (authenticated) session. If the
password is suspected to be compromised then a change of password will
require the external authenticated channels as during initial registration.

Thank you all for all the great inputs to this vetting process.

Hugo




Björn raises the issue that the need for interaction limits some settings
where interaction at registration is not possible. I trust Björn that he
knows of such settings, but this is certa













Does "authenticated channels" mean PKI? No. PKI is the most common setting
for authenticating servers but it is not the only and certainly it is not
how most users will authenticate. Authenticated cha




On Thu, Oct 5, 2023 at 4:10 AM Björn Haase <[e-mail]> wrote:

> Hello to all,
>
>
> >Well, in the landscape of asymmetric PAKEs versus symmetric PAKEs, (I
> think?) any asymmetric PAKE (like OPAQUE) requires the client to validate a
> server certificate in order to be assured
>
> >that it is talking to the right server during registration. This is
> because in asymmetric PAKEs, there is a registration step (where the server
> must obtain and store a record for the "hash" of the
> >client's password) that is not present in symmetric PAKEs. So really, the
> context that would be given here would be a comparison of symmetric PAKEs
> vs. asymmetric PAKEs, not OPAQUE vs.
> >other PAKEs. In Section "10.3. Related Protocols" there are comparisons
> made to other proposed asymmetric PAKEs, and I believe the comparisons to
> symmetric PAKEs were considered
> >out of scope for this document.
> >
> >Perhaps if other (a)PAKE experts (Hugo?) have thoughts on this point and
> would like to elaborate or clarify where I am wrong with the above, that
> would be helpful! :)
>
> I believe that registering the credentials with the server is an issue
> that is also only partially covered by the security proofs. Any registering
> will require a trust-relationship between server and client for verifying
> the authenticity of the individual that aims to be registered.
>
> The difference between different PAKE protocols is the protocol flow. The
> OPAQUE draft mandates a bi-directional data connection for registering
> credentials, while other protocols (e.g. the implementation for AuCPace for
> process-control installations of my employer) only require a single
> registration request message (one flow).
>
>
> From the OPAQUE draft:
>
>        creds                                   parameters
>
>          |                                         |
>
>          v                                         v
>
>        Client                                    Server
>
>        ------------------------------------------------
>
>                    registration request
>
>                 ------------------------->
>
>                    registration response
>
>                 <-------------------------
>
>                          record
>
>                 ------------------------->
>
>       ------------------------------------------------
>
>          |                                         |
>
>          v                                         v
>
>      export_key                                 record
>
>
>
> Registration flow available for other aPAKEs (e.g. used for AuCPace):
>
> creds                                   parameters
>
>          |                                         |
>
>          v                                         v
>
>        Client                                    Server
>
>        ------------------------------------------------
>
>         registration request for initial password asymmetrically signed
> by a known issuer’s public key (e.g. CA) or authenticated using symetric
> MAC using pre-shared symetric secret key
>                 ------------------------->
>
>        ------------------------------------------------
>
>                                      Record
>
>
> With this single-flow procedure, implementations become possible, where
> one-way out-of-band channels are to be used for the initial registration.
> One example for such an out-of-band channel is a sheet of paper with a QR
> code containing an encoding of a registration request. Such a
> uni-directional out-of-band channel is not practical for the three-flow
> registration process as shown for OPAQUE in the draft.
>
> In this sense, I believe that the wording in the OPAQUE draft for the
> “offline” registering process is somewhat misleading as a bi-directional
> message flow is mandated (what requires what we call a bi-directional
> “online” connection in our company’s wording). What I would understand when
> using the word “offline” is a procedure that does not mandate a
> bi-directional message flow.
>
> One use-case for such an “offline” interface might be registering accounts
> in a server located behind an air-gap in a control installation in a
> critical infrastructure installation. There the three-flow registering
> operation for the initial account will mandate bridging the air-gap for the
> purpose of registration.
>
>
> IMO it might be worth considering, whether a single-flow registering
> operation flow might be added to the OPAQUE draft. Anyway IMO the security
> of this registering process has not been properly considered in any
> security analysis of PAKE protocols I am aware of. So this topic should at
> least be worth detailed discussion. I also believe that a one-flow
> registration process might be possible for OPAQUE, however most likely with
> security-properties which differ from the three-flow online (my
> understanding of “online”) registration process called “offline
> registration” in the draft.
>
>
> In any case, every aPAKE needs to establish some form of a
> trust-relationship between server and client for the initial registration
> process.
>
>
> Looking forward:
>
> In my opinion the OPAQUE draft should really be distinguishing the
> distinct use-cases of
>
> 1.) initial account creation and
> 2.) password-change operation which is authenticated with the previous
> password.
>
> For the first aspect, I see real-world use-cases where a single-message
> flow procedure is needed.
>
> For the second aspect, I believe that the draft should probably really
> come up with a detailed guideline how to authenticate a new registering
> procedure in an online-session using a completely PKI-less authentication
> using authentication with OPAQUE itself using a previously registered
> password.
>
> If clear guidelines for the common “change password” use-case are not
> given, I fear that there might be the risk that security issues show up
> based on the way the password-change operation is actually implemented.
>
>
> Yours,
>
> Björn.
>
> Mit freundlichen Grüßen | 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: [phone]
> [e-mail] | www.ehla.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.de.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.
>
>
>