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

[Eric Rescorla <[e-mail]>]

On Fri, Oct 6, 2023 at 8:49 AM Hugo Krawczyk <[e-mail]> wrote:

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

FWIW, in my experience these are the two dominant modalities in most
environments. Specifically:

1. You do an initial registration transaction with someone you have never
interacted with before (e.g., to create your Gmail account) and establish a
shared secret at that time. Obviously, this can only be authenticated on
the basis of something like the WebPKI.
2. The account is made separately and you are given some temporary
credential. In this case, it seems that the registration would actually
happen in that transaction, in which case you *wouldn't* need to trust the
PKI the first time you use the credential (at least as I understand OPAQUE).

-Ekr



> 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.
>>
>>
>>
>> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>