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 -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
