interested in discussing some Kerberos improvements

[Geoffrey Thorpe]

On 4/2/26 10:06 PM, Russ Allbery wrote:
> Geoffrey Thorpe <geoff at 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