[39586] in Kerberos
Re: interested in discussing some Kerberos improvements
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Mar 26 16:12:35 2026
Date: Thu, 26 Mar 2026 15:11:20 -0500
From: Nico Williams <nico@cryptonector.com>
To: Geoffrey Thorpe <geoff@geoffthorpe.net>
Cc: kerberos@mit.edu
Message-ID: <acWS6N8cVWmtHZ4g@ubby>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAH2n15zygW0KP4p5m+5JD40Js_QFbG-t45jGhHtABsZoDXSnCw@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
