Re: [Cfrg] aPAKE Analysis

[Jonathan Hoyland <[e-mail]>]

Hi Björn,

A second round trip is a fairly large performance hit, especially as this
is before the site even begins to load.
If we want to see adoption we have to make sure we don't harm the metrics
website operators care about (for example time to first byte, or document
load).
You write on slide 22 that the user expects the dialogue immediately on the
Hello Retry, but very few users will be familiar with that flow.
They expect to see a fully rendered page with two boxes in which they are
to type their username and password, not an undecorated pop-up.
Because the site has not authenticated itself at this point, the browser
cannot add any site specific rendering (or rather, doing so would require
some complex SXG-style magic, with requires the user to verify the cert
chain at least twice and would immediately leak the site the user is
visiting).

Training users in this system will also make them more vulnerable to
malicious sites that render a blank page and throw a pop-up asking for a
username and password.

The flow for OPAQUE with EAs is much closer to what we see currently.
OPAQUE + EAs performs user authentication _after_ the TLS handshake is
complete, and uses the exporter key interface to bind the authentication to
the underlying channel.

>From a user's perspective,  they go to a website that renders normally, and
then they then login using a username and password box.
If you wanted to, you could switch to OPAQUE + EAs without making the user
aware of the change.
This setup also gives you a major advantage in username leakage, because
impersonating the server requires the attacker to compromise the site's
certificate, which is a reasonably high bar.
Because the site is authenticated to the user before the user sends their
username impersonating a site is much harder.
Further, because of the binding of EAs to the underlying connection you can
also prevent an attacker from MITMing the login.

OPAQUE + EAs:
The system is easy to make memory-hard with protection from rainbow tables.
There are no obvious obstacles for using EAs to perform 2FA based
authentication.
There is also plenty of scope for arranging password changes by binding EAs
to each other, as well as the underlying TLS connection.
There is no change to the TLS state machine.
There is no blow-up in TLS complexity.
The UI elements are kept even further from TLS than under AuCPace.

Regards,

Jonathan

On Sun, 22 Sep 2019 at 20:03, Björn Haase <[e-mail]> wrote:

> Dear Jonathan,
>
> Am 18.09.2019 um 12:09 schrieb Jonathan Hoyland:
> > Björn: The specific issue I have with AuCPace is that the AuCPace
> > substep has to happen before the CPace substep, which means that you
> > need to have a roundtrip before you start TLS.
>
> I understand your concerns but still I am convinced that this is a
> problem that we will be having anyway. In my perception we will have to
> face the situation that the method for authentication to use is up to
> the choice of the server within the most important application settings.
>
> In my perception we will be having at least the settings
> 1.) "Password over certificate-authenticated TLS"
> 2.) "aPAKE authenticated TLS"
> 3.) "aPAKE + 2FA TLS".
>
> Depending on the actual setting of the server, which the HMI client will
> not be knowing beforehand (at least for the case of the https://
> web-server) the client side will not be able to provide all of the
> required information in the first client hello.
>
> As pointed out in my slides
>
>
> https://github.com/BjoernMHaase/fe25519/blob/master/Concept_For_Modularized_PAKE_integration_into_TLS_20190726.pdf
>
> on page 22, I also don't see any performance issue for the HMI interface.
>
> My suggestion on what could best be implemented is the following approach.
>
> The Client tries a conventional Web-PKI-based TLS connection attempt as
> usual with its ClientHello. In this ClientHellow it informs the server
> that it also supports "aPAKE" and "aPAKE with 2FA".
>
> In case of today's webservers, the server replies with a ServerHello as
> normal. In case of a "aPAKE" or "aPAKE with 2FA" requirement by the
> server, the server responds with a "HelloRetry" message in which he
> answers which variant of aPAKE it needs. This first round could also be
> used for establishing an ephemeral session ID on both sides by using the
> random fields.
>
> Then the "aPAKE" or "aPAKE with 2FA"  authentication protocol is started
> and exchanges one ore more message rounds. (For identifying the
> sessions, one could use the session ID as established beforehand.) For
> this purpose, we need an extension to TLS for tunneling these protocol
> messages, which are completely ignored by the TLS layer but transferred
> as opaque payload. In case of "aPAKE with 2FA", the data required for
> the second factor is also transmitted in addition to the messages needed
> by the aPAKE sub-component.
>
> At some spot the external layers will come up with a "PRS" string. In
> the case of the "aPAKE with 2FA", this PRS string will also include data
> from the second factor. Once this value is there, one could resume the
> TLS operation by sending a "ClientHello" with the appropriate SID and
> PRS information.
>
> - We keep the TLS state machine as simple as it is today.
> - We handle the case of balanced and augmented PAKE with the same
> feature set
> - We allow for extensability and flexibility (e.g. 2FA) without blowing
> up the TLS complexity
> - We keep the notoriously complex user-interface components out of TLS
>
> Note that once we have this "tunnel mechanism" that could exchange data
> between both sides for implementing use-cases such as password-changes,
> etc. .
>
> > I think that the pre-TLS phase is going to be difficult to actually
> > implement and deploy, will probably have unacceptable performance,
>
> I don't quite see where you identify a performance problem. Do you
> consider the same application context as I did on slide 22 (as mentioned
> above?)
>
> > and leaks the username, which is a far more serious vulnerability than
> > lack of quantum annoyingness.
>
> Note that the username is leaked in clear text in *all* nominations to
> an adversary impersonating the server! There is nothing I see that we
> can do against it. At least for the case of an industrial plant, in my
> assessment this is the far more critical case and easier to mount than a
> passive adversary which is eavesdropping on the network. In this light,
> I personally don't see a very significant advantage of using PAKE over
> an un-authenticated but encrypted link.
>
> > I think if there was a construction that let you use a balanced PAKE
> > first and then do an augmentation step second, then simply integrating
> > a balanced PAKE into TLS might be an acceptable solution.
> Unfortunately, doing so will make it impossible (IMO) to use memory-hard
> password hashing without rainbow tables :-(.
> > The other option is to run the AuCPace and CPace substeps over a TLS
> > connection, once it has been established, and do some sort of channel
> > binding on top, which adds two roundtrips.
> > I'll specifically address the subsystem question in the other thread.
> >
>