heimdal
heimdal copied to clipboard
heimdal
Client should support SPAKE preauthentication
SPAKE preauthentication, currently in draft at the IETF, solves one of the more serious design flaws in Kerberos: in the default configuration, a passive attacker who monitors the PA-ENC-TIMESTAMP AS exchange with a human client may be able to brute-force the user's password offline. Further, once the password is obtained, the attacker can extract the session key from the AS-REP and therefore compromise the entire chain of trust, including IOV-wrapped messages.
During SPAKE, or Password-Authenticated Key Exchange,
- Each party verifies that the other knows the password (providing mutual authentication);
- Neither party discloses the password to the other (preventing MITM attacks);
- The parties jointly establish an ephemeral secret key that can be used for further communication;
- Each party contributes entropy to that key (preventing replay attacks);
- The strength of the ephemeral key is independent of the strength of the original password (discouraging brute-force attacks, and preventing offline recovery of the original password).
Describe alternatives you've considered The usual solution to this problem is PKINIT, but PKINIT requires creation, maintenance, and deployment of certificates, which is complex and burdensome to administer, particularly for clients not administered centrally. Anonymous PKINIT is easier for administrators but establishing FAST tunnels is non-trivial for end-users to configure and perhaps unsupported(?) on non-PC devices like iPhones.
SPAKE solves this problem without requiring the deployment of any additional infrastructure or extra administration: in the words of MIT, "it just has to be turned on".
Additional context SPAKE is currently in draft with the IETF, and has been evolving for some years. MIT Kerberos implemented it in 1.17 of krb5 and provides documentation. (https://web.mit.edu/kerberos/krb5-latest/doc/admin/spake.html). To me it seems rather stable and I don't expect anything more than a few tweaks to the final paper before it is accepted for the standards track.
I have some early work-in-progress code for this feature, but I found considerable refactoring of the current pre-authentication framework is necessary first, including adding support in the client for PA-FX-COOKIE and KDC_ERR_MORE_PREAUTH_DATA_REQUIRED. I wanted to create this issue to see if the project is interested in work on this feature.
MIT Kerberos borrowed the edwards21159 group computation logic from Google's boringssl. For maximum code diversity it would be better to take code from a different project, or perhaps write it ourselves.
A KDC-side implementation would be great, but I leave that as a separate topic.
Support for multiple round-trip pre-authentication mechanisms was added concurrent with #796 but I would hold tight until #805 is merged as it’s further tweaked in that branch.
I'm very disappointed with the SPAKE spec. I wanted an augmented PAKE so we can have the HDB store only a verifier.
I'm very disappointed with the SPAKE spec. I wanted an augmented PAKE so we can have the HDB store only a verifier.
The CFRG one, the kitten one, or both? CFRG has come out with OPAQUE, which we could presumably convert into a preauth mechanism.
The CFRG one, the kitten one, or both? CFRG has come out with OPAQUE, which we could presumably convert into a preauth mechanism.
The KITTEN one. It's symmetric. It's fine as a way to upgrade from PA-ENC-TIMESTAMP, but ideally we could get the KDC to have almost no key equivalents as follows:
- for client credentials use either PKINIT or augmented-PAKE password verifiers (these are secret, yes, but if leaked you have some time to change all the passwords before the verifiers get cracked);
- for service credentials use the virtual service principal namespace feature in Heimdal
master; - for service credentials add an ECDH key agreement scheme where the HDB stores
{service_public, realm_public_kvno, shared_secret}per-{service, kvno}so that in a pinch one could rotate the realm's public key w/o having to rekey the world (instead services would periodically check for new realm keys).
Between PKINIT and virtual service principal namespaces, it's already possible to run a Heimdal KDC with very few secrets in it: the master key, the keys for the krbtgt principals, and the base keys for the virtual service principal namespaces.
The only problem with using PKINIT exclusively for human user client principals is: where to store the private keys? Smartcards are the obvious answer, but it's not trivial to use those. Thus I would like an augmented-PAKE.
The only problem with virtual service principal namespaces is that it impinges on operations a bit: services have to keep fetching/deriving new keys periodically, and for fetching they need a credential that lives longer than the keytab key rotation period (e.g., a PKINIT client certificate). A very good change, but one that forces changes on sites that they need to prepare for.