From Newsgroup: comp.protocols.kerberos

Hi there

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.

In a former life, I worked with some folks involved in the heimdal project
and I have built up a project on top of some interesting heimdal
developments. However heimdal does not seem to be getting much love anymore
and I would like to migrate all this to MIT kerberos, if possible. The
project is "HCP", which stands for Host Cryptographic Provisioning. https://github.com/geoffthorpe/newhcp

The project's initial goal/feature is to use TPMs (including orchestration
of software TPM instances, where appropriate) to provide an
enrollment-based attestation framework. A second goal/feature is to provide container-based tooling to automate the bring-up and networking of a sample "fleet" of hosts, including the attestation services and some sample hosts/workloads whose credentials are bootstrapped and maintained over time using the attestation framework.

Then there's the third goal/feature - a workflow demonstrating
Kerberos-based services and clients, where all orchestration is PKI-based (distributed via the attestation framework). I.e. where there's no need to maintain user and service principals on the KDCs, that's the point. This
also assumes that both the PKI and kerberos layers rotate keys/versions
over time. The currently-implemented workflow demonstrates ssh and nfsv4 running on top of the kerberos layer.
More here on the kerberos specifics; https://github.com/geoffthorpe/newhcp/blob/main/doc/stateless-kdc.md

Among the things that I'm currently depending on in heimdal that might be different or missing in the MIT codebase are;
* "namespace principals" - these are essentially wildcard principals
registered with the KDC that support a derivation mechanism for determining
the service keys for any given principal within the namespace scope and for
any given time (the kvno is determined from the time). I.e. no need to
register service principals with the KDC, just a small set of namespace principals that encompass the FQDNs of all expected service principals.
* "synthetic principals" - this is the capability of the KDC to issue TGTs
for arbitrary principals, as extracted from the x509v3 certificate used in pkinit.
* 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).
* a "kadmin ext_keytab" enhancement that supports namespace principals.
I.e. at any given time, it will export a keytab with the kvnos that
are currently relevant (including any kvnos that might still be in
circulation and valid, as well as any kvnos that are going to become valid within a configurable window of time).

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?

Feedback welcome, thanks,
Geoff
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

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
--
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

I should add that, yes, I think every KDC implementation should adopt innovations from Heimdal -- it's not to flatter us; it's that those are
highly worthwhile, especially the ones you noted.

Nico
--
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

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

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Mon, Mar 30, 2026 at 05:41:23PM -0400, Geoffrey Thorpe wrote:

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. [...]

I would call this read-only KDCs, or mostly-read-only KDCs.

* 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.

FS?

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.

Are you referring to the mode of kinit where it runs a command and keeps
it supplied with fresh tickets? MIT Kerberos' kinit does not have that
mode.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On 3/30/26 5:47 PM, Nico Williams wrote:

On Mon, Mar 30, 2026 at 05:41:23PM -0400, Geoffrey Thorpe wrote:

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. [...]

I would call this read-only KDCs, or mostly-read-only KDCs.

That's the idea. When I wrote "stateless" it was with respect to the
database state, not protocol state. And even then, there's some hand
waving implied.

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.

FS?

file system

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.

Are you referring to the mode of kinit where it runs a command and keeps
it supplied with fresh tickets? MIT Kerberos' kinit does not have that
mode.

Yes that's what I'm referring to. If it's not yet supported by the MIT
kinit, I would certainly recommend that it be added, it's very helpful.

Cheers,
Geoff

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Mon, Mar 30, 2026 at 09:42:12PM -0400, Ken Hornstein via Kerberos wrote:

Are you referring to the mode of kinit where it runs a command and keeps >> it supplied with fresh tickets? MIT Kerberos' kinit does not have that
mode.

Yes that's what I'm referring to. If it's not yet supported by the MIT >kinit, I would certainly recommend that it be added, it's very helpful.

Can't speak for anyone else, but we use "k5start" for this.

IMO it should be a native feature of some tool in MIT Kerberos, but I
admit there are portability issues. Heimdal has a bunch of code to do
this on Unix and Windows, but it completely glosses over issues to do
with setting the process group of the child, handling signals correctly,
etc. So it makes some sense that the work of launching a child process
and monitoring its state should be done by another tool than kinit
itself if doing so simplifies things. Still, IMO the requesite
functionality can be isolated into well-designed utility library
functions, so it might be worth doing for MIT Kerberos.

Nico
--
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On 3/30/26 9:42 PM, Ken Hornstein via Kerberos wrote:

Are you referring to the mode of kinit where it runs a command and keeps >>> it supplied with fresh tickets? MIT Kerberos' kinit does not have that
mode.

Yes that's what I'm referring to. If it's not yet supported by the MIT
kinit, I would certainly recommend that it be added, it's very helpful.

Can't speak for anyone else, but we use "k5start" for this.

Ahh, that looks like the same feature, judging from the man page. Thanks.

As I understand it, k5start will invoke kinit periodically to handle credential refresh, and so if kinit is configured to use pkinit to get
creds, then it would pick up the cert and key from the file system each
time kinit is invoked (rather than them being read only once when
k5start is first run). Is that correct? If so, that's once less feature
to worry about. :-)

Thanks
Geoff

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Geoffrey Thorpe <geoff@geoffthorpe.net> writes:

As I understand it, k5start will invoke kinit periodically to handle credential refresh, and so if kinit is configured to use pkinit to get
creds, then it would pick up the cert and key from the file system each
time kinit is invoked (rather than them being read only once when
k5start is first run). Is that correct? If so, that's once less feature
to worry about. :-)

k5start itself does not run kinit. It uses the Kerberos library calls
directly. I am dubious that it would work with PKINIT from a file without
some code changes. (Although also I'm not sure I understand the security
model of using a PKINIT cert on disk and not a keytab.)
--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Ken Hornstein via Kerberos <kerberos@mit.edu> writes:

k5start itself does not run kinit. It uses the Kerberos library calls
directly. I am dubious that it would work with PKINIT from a file
without some code changes. (Although also I'm not sure I understand the
security model of using a PKINIT cert on disk and not a keytab.)

While you can specify some PKINIT options to the MIT kinit with the
-X switch, at least in my experience PKINIT authentication is normally configured in your krb5.conf and anything that calls the "normal" krb5_get_init_creds_with_password() function does the right thing.
So I think k5start should work out of the box assuming all of the
other PKINIT stuff was configured properly.

Ah! Then maybe it will work, indeed. Normally, k5start authenticates from
a keytab, but you can get it to call krb5_get_init_creds_password instead.

I can think of situations where you might be issued X.509 certificates
that you would want to use for authentication, rather than a keytab.
That might solve some compliance issues depending on site policy. E.g.,
here in the DoD there is a lot of policy pushback about using "fixed" passwords (even with password expiration) and while almost nobody knows
about Kerberos, if they ever did figure out what a keytab was then there would be a lot of resistance to using that for client authentication.
But if you use DoD-issued client certificates for authentication you are exempt from all that (most of the time they want you to use hardware token-based certificates, but software certificates are allowed for "non-person entities" and a few other cases).

Ah, the sort of security model where the security is equivalent but
someone wrote a policy without understanding the security model (or, to be
more fair, wanted to be sure people who don't know what they're doing
don't do stupid things and not really caring about people who do know what they're doing).
--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Thu, Apr 02, 2026 at 10:20:07PM -0400, Ken Hornstein via Kerberos wrote:

I can think of situations where you might be issued X.509 certificates
that you would want to use for authentication, rather than a keytab.

Like a TPM. Just in time to be obsoleted by the move to PQC.

(Though, still, if you treat the public keys as secrets then it can be
safe should we get a CRQC.)

Nico
--
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On 4/2/26 10:06 PM, Russ Allbery wrote:

Geoffrey Thorpe <geoff@geoffthorpe.net> writes:

As I understand it, k5start will invoke kinit periodically to handle
credential refresh, and so if kinit is configured to use pkinit to get
creds, then it would pick up the cert and key from the file system each
time kinit is invoked (rather than them being read only once when
k5start is first run). Is that correct? If so, that's once less feature
to worry about. :-)

k5start itself does not run kinit. It uses the Kerberos library calls directly. I am dubious that it would work with PKINIT from a file without some code changes. (Although also I'm not sure I understand the security model of using a PKINIT cert on disk and not a keytab.)

Regarding the model, it's a question of how your fleet orchestration
deals with bootstrapping and maintaining credentials. If you already
have orchestration that allows for PKI creds to be distributed to hosts
and updated over time, then it might be attractive to extend that to
deploy PKINIT certs.

In https://github.com/geoffthorpe/newhcp, this allows us to deploy a
Kerberos network where the KDC database doesn't need to have any client
or service principals registered at all. So the orchestration activity
of creating and deleting such identities doesn't require any interaction
with the KDC database. If you present a certificate with a properly
encoded client principal in it, the KDC will give you a TGT for that
client principal (synthetic principals). If you present a cert with a
properly encoded service principal, the KDC will give you a keytab for
that service principal (namespace principals). So the KDC doesn't need
to be a source of truth for identity, it relies on the PKI for that.

Cheers,
Geoff

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Thu, Apr 02, 2026 at 07:06:37PM -0700, Russ Allbery wrote:

[...]. (Although also I'm not sure I understand the security model of using a PKINIT cert on disk and not a keytab.)

IMO it's strictly better. Though you can still have a keytab as an optimization.

As Geoff explained in his reply, the idea is that the KDC can synthesize
a KDB entry for any principal that doesn't exist in the KDB but for
which a client certificate is presented (with a PKINIT SAN, issued by a
CA trusted for that and the realm in question) and issue a ticket.

If you want to revoke such a thing you just create a KDB entry for the
given name and mark it locked.

Nico
--
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Nico Williams <nico@cryptonector.com> writes:

As Geoff explained in his reply, the idea is that the KDC can synthesize
a KDB entry for any principal that doesn't exist in the KDB but for
which a client certificate is presented (with a PKINIT SAN, issued by a
CA trusted for that and the realm in question) and issue a ticket.

Ah, yes, right, of course. I had completely forgotten about that.
--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
--- Synchronet 3.21f-Linux NewsLink 1.2