[Cfrg] Augmented PAKE review for use with TLS

[Jonathan Hoyland <[e-mail]>]

Hi All,

At Stanislav's request I have reviewed the four augmented PAKEs suitability
for use with TLS, see below.
I hope you find it useful.
Apologies in advance for any mistakes.

Regards,

Jonathan
-------------------------------------

*Review of the four candidate augemented PAKEs for their suitability for
use with TLS.*

   1. BSPAKE
   2. OPAQUE
   3. VTBPEKE
   4. AuCPace

------------------------------
<http://127.0.0.1:9016/page/1#1.-bspake> 1. BSPAKE

BSPAKE is a very short, rather underspecified, entry, making fair review
somewhat challenging. As pointed out on the mailing list, BSPAKE can be
viewed as a member of the OPAQUE family, so I will wrap it into my review
of OPAQUE, and instantiations thereof.
<http://127.0.0.1:9016/page/1#2.-opaque> 2. OPAQUE

OPAQUE is a very comprehensive entry, with an attendant suggestion for how
it is to be combined with TLS. OPAQUE is defined as a compiler that
transforms an OPRF and an AKE into a SaPAKE. Thus it has numerous
instantiations. Because OPAQUE is a 3 flow protocol initiated by the
client, there is an obvious / naïve way of implementing OPAQUE with TLS,
simply aligning the messages with the TLS messages in appropriate
extensions. This has been specified in two ways in draft-sullivan-tls-opaque
<https://tools.ietf.org/html/draft-sullivan-tls-opaque-00>.
Either of the specified methods seems likely to have good security
properties, however because one injects key material into the TLS key
schedule, and the other removes the PKI-based certificates, the security
properties are not trivially derivable.

draft-sullivan-tls-opaque also specifies a third mechanism that has clearer
security properties, using Exported Authenticators (EAs) to perform the
authentication / OPRF protocol. At the cost of an extra round trip, the
EA-based OPAQUE uses a standard TLS handshake, and then binds the OPRF on
top. Because of the design of EAs the security properties of the TLS
handshake and the OPRF protocol can be composed.

The EA-based setup is probably the most practical solution, having clear
security properties, and matching the current authentication flow used by
many web applications. Further, it does not leak the user id, which all
other candidates and the two naïve OPAQUE candidates do, which would
constitute a *new* security risk, and is arguably a breach of TLS’
“Protection of endpoint identities” guarantee.
<http://127.0.0.1:9016/page/1#3.-vtbpeke> 3. VTBPEKE

VTBPEKE, in its vanilla form, does not appear to be resistant to
pre-computation attacks, as the salt is sent to the client in the clear.
However if paired with TLS the salt would be placed in an encrypted
extension. This makes it resistant to passive, though not active,
attackers. VTBPEKE does have a clear path to binding it to the TLS
connection. In the second flow the server sends ε, a value chosen at random
from {0,1}^k. This value could be replaced with a TLS exporter key labelled
with a fixed string. Doing so would bind the authentication flow to a
specific handshake, and allow for clear reasoning about the properties of
TLS + VTBPEKE.

VTBPEKE doesn’t come with a IETF style draft, and the notation in the paper
is confusing at times, but the only obvious major obstacle to pairing it
with TLS is the leaking of the user id to even a passive adversary. It is
possible that one could use EAs in the same was as suggested by OPAQUE, but
some thought would have to be given to working out the details. There are
no suggested mitigations against user enumeration, but having the server
construct Y using a random g if the user is unknown would seem to be
effective.
<http://127.0.0.1:9016/page/1#4.-aucpace> 4. AuCPace

AuCPace is also a very comprehensive entry, and has an attendant suggestion
for TLS integration. The updated strong AuCPace entry blinds the salt,
which makes the entry secure against precomputation attacks.

AuCPace’s decision to allow the client to select the salt seems hard to
justify, because a lazy client may simply always use the same salt. Because
the server identity is not included in the computation of w one can imagine
clients that simply store a single w as their password, and effectively use
the same password with all sites. This might be an especially tempting
shortcut on low power devices.

In Appendix D the authors suggest a method for TLS integration.
Specifically, they suggest performing a pre-TLS handshake to establish a
PRS, and then using a TLS + CPace design to authenticate the pre-handshake.
This is an interesting suggestion, but may see practical difficulties with
routing and session binding. It is also unclear how easy it would be to
bind the TLS + CPace handshake back into the overall AuCPace flow.
Specifically, it’s not clear to me that the weaker authentication
guarantees offered by the PSK interface allow for secure composition of the
two substeps. The TLS PSK handshake doesn’t use any asymmetric primitives,
which means that authentication properties from prior handshakes might not
compose, leaving the path open for a channel synchronization attack.
Certainly it’s something that would require further evaluation.

It is also not immediately obvious if you can efficiently use EAs in a
similar manner to OPAQUE, because of the ordering requirement of the CPace
substep and the AuCPace augmentation layer. The naïve method would add two
round trips, and is almost certainly not the best solution.
<http://127.0.0.1:9016/page/1#overall-recommendation> Overall recommendation

All the candidates have things to recommend them, but overall I think
OPAQUE with EAs is the best option, because it hides the user identity,
something that is important with TLS. BSPAKE’s explicit inclusion of the
client and server identities in the key derivation appeals to me, and might
be something worth adding to OPAQUE, although I’d have to think carefully
about whether it actually contributes anything. If user id hiding is not
required then a variant of VTBPEKE with salt blinding would be a reasonable
candidate, because the binding to the TLS handshake doesn’t change the
guarantees of the underlying handshake like OPAQUE, or a require a pre-TLS
flow like AuCPace. OPAQUE is also a reasonable candidate in the user
revealing scenairo, although some effort would need to be expended to check
whether it invalidated the current security proofs of TLS.