3 ms·
I'll shamelessly plug this for Kerberos since SPAKE is a variant of PAKE... Kerberos has a draft for adding SPAKE to Kerberos: https://tools.ietf.org/html/draf
by cipherboy 8y ago
I'll shamelessly plug this for Kerberos since SPAKE is a variant of PAKE...
Kerberos has a draft for adding SPAKE to Kerberos:
https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-06 https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-prea...
This was implemented sometime around March in MIT Kerberos:
https://github.com/krb5/krb5/pull/741 https://github.com/krb5/krb5/pull/741
One of the interesting use cases would be to add 2FA support to the Kerberos protocol, but that support is still pending last I checked.
A second draft that is useful for SPAKE would be improved Channel Binding (CBs) support:
https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-flag-01 https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-...
CBs are still WIP upstream:
https://github.com/krb5/krb5/pull/685 https://github.com/krb5/krb5/pull/685
Channel bindings allow Kerberos to piggy back on top of an existing encrypted channel (e.g., TLS). When doing 2FA with SPAKE in a browser, this means that we can take advantage of the security guarantees of the TLS protocol by ensuring the value of the final handshake is the same. This is most helpful for SSO-type scenarios.
If anyone wants to comment on either RFC, I'm sure the Kitten WG would be happy to take feedback:
https://tools.ietf.org/wg/kitten/ https://tools.ietf.org/wg/kitten/
Disclosure: I work closely with several of these folks and worked on the CBs PR.
- lvh 8y agoIs there a particular reason to use a symmetric PAKE in this case? Is it somehow not a long-held password?