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 may be exceptions where users are "anonymous"
and no user credentials are required for registration, but even in this
case the user will want to authenticate the server).

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.

For OPAQUE's "login (or online) stage", no external authentication is
needed, not via PKI or anything else.  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. (Contrast this with the current practice of sending
plaintext passwords protected under TLS, a fully PKI-dependent mechanism.)

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

Björn is concerned with limitations imposed by the interactive character of
OPAQUE. In particular, he mentions 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. (Of course, the user needs to trust/validate the source
of that QR code.)

Regardless of this last point, Björn 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 OPAQUE state information, including the
OPRF key, by itself without interaction. Of course, the user will now have
to pass all this information to the server which assumes a secure channel
(at least from user to server but also implicitly an authenticated channel,
maybe a physical one, where the user obtains the server's public key).
Maybe something like this can help in the air-gap setting.
However, this may not be the most secure general way of running
registration, or be a common enough setting to add to the current OPAQUE
document. It can be documented separately if there is interest.

Finally, Björn raises the question of whether the OPAQUE internet draft
(and future RFC) should specify ways of instrumenting password updates.
There seem to 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

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.
>
>
>
>