[39588] in Kerberos
Re: interested in discussing some Kerberos improvements
daemon@ATHENA.MIT.EDU (Geoffrey Thorpe)
Mon Mar 30 17:41:43 2026
Message-ID: <990e6964-c1f6-4fe3-adc9-4c3f9109a74b@geoffthorpe.net>
Date: Mon, 30 Mar 2026 17:41:23 -0400
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
Cc: kerberos@mit.edu
Content-Language: en-US
From: Geoffrey Thorpe <geoff@geoffthorpe.net>
In-Reply-To: <acWS6N8cVWmtHZ4g@ubby>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: kerberos-bounces@mit.edu
Hey Nico, thanks for jumping in.
On 3/26/26 4:11 PM, Nico Williams wrote:
> 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.
Right - I will reformulate my original post and send it to krbdev.
>
>> [...]
>> 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:
<snip>
Yeah I didn't mean stateless in the way you're interpreting it, I get
what you mean. It's only "stateless" in the sense that the typical
orchestration problem of managing a KDC, i.e. registering and
deregistering client and service principals in the KDC database, is
avoidable. There's some hand-waving involved (because you still have to
register the underlying namespace principal(s), any legacy principals
may have to be preserved, etc), but calling it "stateless" kinda gets
the point across more easily than "a mostly write-free KDC solution that
helps resolve traditional kerberos orchestration challenges by using PKI
as the source of truth for principals rather than maintaining all
identity in the KDC's own database".
>> 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!
If they (one of the contributors) wants to chat/collaborate, please put
them in touch!
>> * 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.
Perhaps I didn't express it well. The feature I'm relying on is _not_
that kinit refreshes the x509v3 cred itself, but that it re-reads the
cert and key periodically from the FS rather than reading only once at
startup. I.e. the assumption is that the pkinit cert+key is going to be
refreshed "by other means" (in my case via HCP attestation, in other
cases it'll be whatever PKI tooling keeps creds up to date), so what I'm
relying on is that the kinit instance will consume those updates to the
cred over time (from the FS), without requiring a restart.
The heimdal "kinit -C" does seem to do this.
Cheers,
Geoff
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
