Subject: [Cfrg] Reviews for augmented PAKEs (BSPAKE, AuCPace, OPAQUE, VTBPEKE)

From: Kevin Lewi <[email-masked]>
Date: Sun, 15 Sep 2019 01:49:12 -0700

I'm providing this review from the perspective of using these
augmented PAKE schemes in place of the existing account login protocol
for Facebook, in which a client sends a plaintext password over a
secure channel to a server. More details here:
https://mailarchive.ietf.org/arch/msg/cfrg/1QQ_FfRsOxvoLGqX0t48WLTMSNU
. The points I cover in this review are more focused on the practical
implications of integrating an aPAKE into account registration/login,
and so I will defer to other experts to analyze the validity of the
security proofs and cryptographic assumptions underlying these
proposals.

---

First, I've outlined some of the high-level concerns which I found to
be common across multiple candidate aPAKEs:

(1) Unspecified / unsafe registration step

In a password-based login protocol, there is a registration step
(where the client registers a username and password pair for account
creation) and an account login step. It is problematic when aPAKEs
assume that the server begins the protocol with some information
derived from the password. We would like to have the guarantee that
the password is also not vulnerable to the same kinds of attacks from
eavesdroppers, server compromise, etc. during the registration step as
well as the login step.

(2) Lack of protection against pre-computation attacks

In the normal password-based login protocol, the account salt is kept
secret by the server, and when employed with a password hashing
function like scrypt/argon. If we are to replace this mechanism with
an augmented PAKE, we do not want to reduce security against
eavesdroppers, server compromise, etc. Indeed, it is already noted as
a requirement for augmented PAKEs to have pre-computation security
anyway.

(3) Client-only password hashing

We want to support a large range of clients, from browsers to low-end
mobile phones. For augmented PAKE protocols which require password
hashing to be done on the client, it seems like we must make a
tradeoff between performance/usability on the client device and the
difficulty of brute-forcing password hashes after a server compromise.
This differs from the normal password-based login protocol, where
password hashing occurs on the server, and hence this tradeoff is not
as significant.

---

And here are the comments I have gathered specifically for each proposal:

BSPAKE: See (1); it seems like the server has to start with parameters
dependent on the password, but it isn't clear how to do this in
registration without sending a password-equivalent to the server.
Also, see (3).
AuCPace: See (2) and (3).
OPAQUE: See (3).
VTBPEKE: See (1); server needs to start with V^H(s, pw), and it is not
clear how to transmit this securely on account creation. Also, see (2)
and (3).

---

From: Björn Haase <[email-masked]>
Date: Sun, 15 Sep 2019 13:08:16 +0200

Dear Kevin,

you obviously have missed the fact that there is also a "Strong AuCPace"
specified in the paper
(Appendix C) which allows for pre-computation attack resistance if
desired for the application setting.

The difference between OPAQUE and BSPEKE is, that AuCPace may also run
in a non-pre-computation attack resistant
mode depending on the application's need. Obviously, you'd be choosing
the pre-computation attack resistant "Strong AuCPace".

There might, on the other hand be other applications that don't want the
"strong option". Imagine for instance that you want to use AuCPace with
the user credential database on some system that today has a password
database using a fixed salt that does not have the required structure
for the OPRF. If you want to get an aPAKE functional with such a
"legacy" data base, you need a system that openly communicates the salt.
On the other hand upon password changes of the users, you might want the
user credential server to be switched to a more secure pre-computation
attack resistant version. AuCPace allows for such a flexibility.

In applications that want pre-computation attack resistance, you are
free to use "Strong AuCPace" that comes with pre-computation attack
resistance.

Actually regarding the aspect (1) that you see for BSPEKE, it seems that
I have missed some point. In my opinion all of BSPEKE, Strong AuCPace
and OPAQUE should be *very* similar regarding the password registration
phase. I agree with you that we should consider this aspect with great
care. Actually unlike the other systems, for AuCPace we have tried to
capture and consider this aspect in the security proof, while this
substep is out of the scope of the security analysis for VTBPEKE and
OPAQUE (to my best knowledge). At the same time, ln my opinion
considerations for AuCPace could in my opinion directly be re-used for
OPAQUE (and possibly BSPEKE, if a security analysis comes out there).

Yours,

Björn.

Am 15.09.2019 um 10:49 schrieb Kevin Lewi:
> .. The points I cover in this review are more focused on the practical
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>