Re: [IPsec] Beginning the PAKE selection process

[Nicolas Williams <[e-mail]>]

A thought about PAKEs and ZKPPs...

In the SASL space we pursued a DIGEST-MD5-like mechanism.  Yup, SCRAM is
vulnerable to off-line dictionary attacks by passive attackers.  Except
that SCRAM is intended to be used with channel binding to TLS, with
confidentiality protection from the same TLS channel, and with TLS
authenticating the server (with PSK, PKIX server certs, doesn't matter
how).

The only difference between the SCRAM-with-channel-binding-to-TLS
approach and a ZKPP is this: with a ZKPP there's no need to separatly
authenticate the server, which means there's no need to deploy a PKI or
Kerberos, nor pre-share certs or keys.  That's pretty nice.

With the SCRAM-with-cb approach you don't really have to deploy a server
authentication infrastructure nor pre-share server authentication
material if you're willing to take a chance on initial attempts: you can
just optimistically learn server authentication material on success.  On
failure you can warn the user to call a helpdesk to reset their
password.  Yeah, that's not as good as what you get with a ZKPP, but
still pretty good.

In practice most customer who'd use a ZKPP would be happy enough to
deploy a server authentication infrastructure in the form of a PKI or
pre-shared certs.  And, they're very likely to want two-factor user
authentication in the form of a user cert (possibly on a smartcard) and
a password.  In the latter case ZKPPs add little value: at best a
round-trip optimization relative to the SCRAM-with-cb approach.

The SCRAM-with-cb approach in IKEv2 would look as follows: first do an
ephemeral-ephemeral DH key exchange, then authenticate the server with a
CERT, then do a GSS-API context establishment with channel binding to
the DH key exchange.

Just a thought!

Nico
--