On Fri, Mar 20, 2026 at 11:12:56PM -0400, Geoffrey Thorpe wrote: > I wasn't sure if this was more suited to the krbdev list, but I decided to > start here first. Please advise if this belongs elsewhere.
krbdev is better, yes. > [...] > https://github.com/geoffthorpe/newhcp/blob/main/doc/stateless-kdc.md FYI KDCs are stateless by definition. What you meant is more like a KDC where there is no need to have a _writeable KDB/HDB_ because: - all host-based service principals are in virtual service principal namespaces (VSPNs) - all user principals are "synthetic" thus none of those ever need to be created or altered. You'll always need some KDB/HDB write capability for: - krbtgt principals (these can have previous/current/next keysets derived from a base secret and a schedule, but they can't be namespaced because the base secret has to be different for each such principal), especially cross-realm ones (Though for a "forest" of realms where all are owned by the same administrative entity one could have krbtgt principals be keyed much like host-based service principals in VSPNs. It's just that usually one has multiple realms because one has multiple distinct administrative domains.) - locked principals for "revocation" -- for "deleting" namespaced host-based service principals and "deleting" synthetic principals You can say reasonably say you won't need the latter, but the former is unavoidable though at least KDB/HDB writes for cross-realm principals are quite rare. I would call this a mostly-write-free KDC model. One of the nice things about this deployment model is that recovery from KDC compromise is straightforward, with time bounds given by how frequently services refetch their keytabs. You and I have talked about this before, and I think this is indeed a bit of a holy grail. Note that such a thing can very easily be made into an appliance, especially if one builds it like a tank with tamper-resistance and tamper-detection features. There could be a market for such a thing. > Among the things that I'm currently depending on in heimdal that might be > different or missing in the MIT codebase are; > * "namespace principals" - [...] > * "synthetic principals" - [...] At the OpenSSL 2025 Conference I was told that one of the major contributors to MIT kerberos also wants these features in MIT Kerberos. In this age of LLMs you can probably contribute these yourself in no time flat! > * a persistent, PKI-based kinit - i.e. where an instance of kinit ("kinit > -C" in heimdal) will automatically renegotiate and update tickets over time > to respect the key-rotiation period, and will reread the x509v3 cred each > time (so that any updates to the local PKI cred also get picked up). I'm not sure what this is referring to. MIT Kerberos supports using PKINIT in kinit. Neither MIT nor Heimdal will automatically refresh user certificates though, but Heimdal does have kx509 and an HTTP-based online CA as well which can do that -- it's just Heimdal's kinit does not do what you're asking for. > * a "kadmin ext_keytab" enhancement that supports namespace principals. Right, that's implied in virtual service principal namespaces. > I first took a brief look at migrating this whole system and workflow over > to MIT kerberos some time ago, and I very quickly hit the skids. I've had > to shelve that for a while but I'm keen to try again. I'm wondering if > anyone with more familiarity with the MIT tools and code might be > interested in collaborating? I'm not, sorry, because I've my hands full and I prefer to work on Heimdal if I'm going to work on Kerberos at all. However, I do have non-Kerberos GSS-API work I'm doing (slowly) in Heimdal that I want to port to MIT Kerberos. Nico -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
