Re: [Cfrg] aPAKE Analysis

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

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