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

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

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