Re: [Cfrg] aPAKE Analysis / Why System-Level-View

[Jonathan Hoyland <[e-mail]>]

Hi Björn,

I think the aPAKE candidates analysed in the UC model are taking the right
approach. I think it would be valuable for as
to give them composable features such that it is well defined how to bind
them to other protocols, and how to bind other
protocols to them. If we can define a channel binding for the aPAKE and
further allow the aPAKE to commit to ancillary
data then are well on our way to making it a useful primitive.

In terms of integration with other systems like PAM, ActiveDirectory or
even HTTP, I think it is better to go with a
flexible design, rather than directly cater for specific use cases.

Integrating TLS-PAKE with PAM doesn't strike me as likely to be
challenging. Admittedly I have never written a PAM
module before, but it would seem to be simple enough, at least with OPAQUE
with Exported Authenticators (EAs).  The PAM
database would store `EnvU, PubS, PubU, kU, kV`,  make the appropriate
challenge, which would be wrapped in the
appropriate TLS EA frames by the TLS stack, the responding certificate
would have the channel binding checked by the TLS
stack, before passing the certificate to the PAM module to verify the
signature proves knowledge of `PrivU`.

Presumably if the PAM database is being upgraded / goes away then people
won't be able to successfully authenticate,
which is at least fail closed.  If there were a reference PAM module then
'normal' application developers wouldn't need
to implement any code, especially if support were built in to servers
implementing TLS PAKE.

Things like password updates are also simple, in as much as, you just
repeat the registration step, with the application
logic handling who is allowed to do what and when.

Given that EAs are handled at the HTTP layer in the form of certificate
frames, I imagine that TLS-OPAQUE would also be
handled at the HTTP layer, so more complex logic would be done at the
higher layers.

The key thing I would say about separating off the aPAKE into a security
subsystem is that we need to make sure that the
binding to the TLS connection is strong, and in particular that there is no
way to pass the aPAKE protocol between two
different TLS connections.

Consider the current system: A user, `A`, connects to a server `B` and
reuses the same password that she established
with server `C`.  `B` can now take this password and use it to impersonate
`A` to `C`.

Now consider a system where an aPAKE is simply run inside a TLS connection
with no attempt to bind it to the underlying
TLS session: A user, `A`, connects to a server `B` and reuses the same
password that she established with server `C`.
`B`, instead of running the aPAKE honestly opens a new connection to `C`
and simply forwards the messages back and
forth.  The protocol succeeds, because in this scenario we assume that `A`
is not checking consistency between the TLS
connection and the aPAKE protocol.  `C` might now, incorrectly, assume that
the owner of the TLS connection, `B`, has
successfully authenticated himself as `A`. The key established between `A`
and `C` is not used to authenticate any
future data on the connection, and `B` can now perform any action for which
`A` is authorized.

All this to say, a strictly compartmentalized approach to constructing
TLS-PAKE is unlikely to be secure. Specifically,
the inner and outer protocols not only need to be aware of each other, they
need to interact.

If by security subsystem you only meant a way to separate application data
and aPAKE data then defining a new TLS record
type for authentication messages sent over TLS would be fairly trivial.


If we select a PAKE that is easy to compose with other protocols then it
should be versatile enough to handle anything
we need it to.

Second-factor authentication would be a good example of a protocol that
would be bound to a PAKE, and we should design
bindings accordingly, such that we don't need to consider second-factor
directly.

I think OPAQUE-EA has good composition properties, but all of the
candidates have scope.

Regards,

Jonathan

>