Re: [Cfrg] Proposed PAKE Selection Process // Integration in TLS ?

[Natanael <[e-mail]>]

On Wed, Jun 19, 2019 at 11:22 AM "Björn Haase" <[e-mail]>
wrote:

> [...]
> > Eric Crocket wrote:
> >1. We would like to see the standardization of both a standalone scheme
> and its integration into TLS, similar to SRP (RFCs 2945 and 5054) or OPAQUE
>
> I fully agree with you and also would also like to see PAKE integrated as
> a component in TLS. The important aspect to consider, when doing this, IMO
> will be that we are then integrating components into the TLS stack which
> today mostly are assigned to the "application layer" (which often should be
> expected not to consider security adequately).
>
> E.g. after a successful TLS-managed login the application on the server
> will need to know which user is just logged-in, e.g. in order to find out
> which authorization rights to attribute to the current session.This means
> that the interface to the TLS system would become somewhat more powerful
> and complex, by providing interfaces regarding user accounts.
>
> Also for some use-cases, the application will have the need to request a
> re-authentication of a HMI user: Consider, e.g. the use-case of a "Do you
> really want to trigger the self-destruction functionality? Please re-enter
> the password" mask.
>
> I.e. for the use-case that you did sketch (similar to my use-case U2)  I'd
> see the need for interfaces between the TLS system and the "application
> layer" for
>
> - Querying which user is logged in and optionally mange authorization
> rights
> - Arranging for a re-authentication upon application request, possibly
> with another account (similar to a "su" shell command on unix systems).
> - Optionally: Managing user accounts (e.g. Password changes, changes of
> authorizations).
>
> The key question that makes above components mandatory (IMO) is: Does the
> application layer need to consider user accounts with different
> authorization levels?
>
> In the settings that I have in mind (my use case U2) the answer is:
> Definitely "yes, we need to deal with the complexity of user authorization
> levels."
> How is the situation in your AWS use-cases?
>
> IMO the aspect of a possibly more complex TLS interface will generate a
> lot of discussions, but this is definitely manageable. We have been doing
> this specifically in our proprietary TLS-like security stack for our
> industrial HMI service app (E+H SmarBlue). The advantage of integrating the
> account management in our security/networking stack is that this way, we
> were able to clearly modularize the software into a security-submodule and
> an application-module.
> [...]
>

First of all, regarding UX:
If a PAKE were integrated, I would like to see integration in browsers
between WebAuthn (U2F) and the PAKE such that activating the 2FA prompt
also could trigger a secure password prompt from the "user agent" i.e. the
browser (potentially this doesn't need direct integration, if the site
itself can trigger PAKE when it detects successful 2FA authorization).

Consider for example something like Google's 2FA activated login flow:
first enter username, click next. The browser now prompts for verification
with your 2FA hardware token, and you press a button on this device (or
equivalent). After 2FA verification, the web page then shows the web form
for the password entry. But in the integrated PAKE version, the last step
(of pressing the 2FA hardware button) instead opens a PAKE password prompt
via the browser, instead of via a web form. This substantially improves
phishing resistance and related security properties.

Also, in this PAKE prompt, the website should be able to show its site name
/ domain and your entered / remembered username, as a context for what
password to enter.

Any potential integration with other software like password managers is
entirely an implementation issue, for client software like browsers to deal
with on their own.

---

Second, regarding API:s and authorizations in the client-server model,
etc...
(Disclaimer, I'm no expert on these issues, so no guarantees that any of
this is accurate or would be an improvement)

All of that with account information and more seems a bit unnecessarily
complex.

Could you not simply treat the PAKE generated session key as a cookie /
token (of which you can have multiple), perhaps with just some basic
metadata attached? So when you log in with PAKE, it could generate a token
with something like a key-value label attached (server specified) to
indicate purpose. This could then allow the application layer to locally
track which accounts and permissions* are associated with the held tokens.

The TLS then layer wouldn't necessarily need to understand what the labels
means (maybe with exceptions, I'm no expert on issues like XSS attacks),
only the application layer needs to understand this. The TLS / PAKE layer
would only be involved in preventing forged / manipulated tokens.

A client which sees that an action requires a new PAKE generated token for
a permission which it lacks can then prompt for a password to be re-entered
through another PAKE prompt. For example, a client would understand that a
login token can't change something like payment data (through application
layer logic).
And some tokens can be single-use (like authorization of sensitive
actions). This simultaneously solves the issue of tracking multiple
permissions for one account as well as multi-account authorization, since
the application layer can associate all of this with the key-value pairs.

* The issue I'm seeing here is when you have a variety of permissions
available, potentially changing over time (without re-running PAKE), and
want to express exactly which are authorized. To keep the TLS layer simple,
my opinion is that this logic should be pushed to the application layer and
thus forcing it to track associated permissions (changes included) for each
singular token (1 PAKE password entry = 1 token + 1 key-value pair).

At most, any deeper integration should stop at letting the server push a
replacement key-value association for active tokens in order to selectively
alter permissions with minimal server side state and without running PAKE
again, assuming the server use some scheme like Macaroons;
http://tech.tmh.io/concept/2016/06/07/macaroons-a-new-flavor-for-authorization.html