Re: [Cfrg] aPAKE Analysis

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

Hi Jonathan,


> The issue with AuCPace is that it's complicated to bind to TLS without
> adding two round trips, but I'm sure the issues aren't insurmountable.
>
The question that is in my opinion not yet really answered is, how far
we aim at supporting the "human-user" login support for TLS. Once you
are dealing with passwords you *have* to answer also questions such as

- How does the application trigger a re-authentication?

- How would the user be changing his passwords?

- How would we be adding users?

In my opinion, there should be some "security subsystem" clearly
separated from the normal "application" that handles the "functional
code". My main job is design of explosion-protected intrinsically safe
electronics. There we make a clear distinction between the "functional
subsystem" and the "intrinsic safety subsystem" which we try to keep as
separate as possible in order to avoid the risk of accidental hazards.

I think such type of a concept would be also very helpful for an
application with security needs.

For handling passwords, I see the need for the "security subsystem" to
arrange for all of the rather complex configuration topics (password
changes, user management, re-authentication, change-privileges, etc.). 
A comprehensive solution (where PAKE is nothing but one important
building block) will need far more than what we would be willing or able
to offer by the TLS component.

For this reason, I am advocating to rather design TLS to be one
important but rather small building block which provides interfaces to
other components which in its entity would provide the "security
subsystem". For this reason, I am rather suggesting to do two things

- Integrate a balanced PAKE such as CPace into TLS

- At the same time provide the necessary interfaces to TLS such that we
could build up an augmented and pre-computation-attack resistant PAKE on
top of CPace. This is essentially, what I am suggesting to do with
AuCPace. The "Au"-Part would end up in components such as Linux's PAM
(server side) and password managers (client side) and the "CPace" part
would become integral part of TLS.

This would also solve the round-trip problem in my opinion. Note that
the fact that AuCPace could also run in a conventional
non-precomputation-attack-resistant mode, would make it possible to use
it with today's form of PAM-style user credential databases. If PAM gets
upgraded one day, one could also offer pre-computation-attack resistance
in a second step.

Yours,

Björn.