[39598] in Kerberos
Re: interested in discussing some Kerberos improvements
daemon@ATHENA.MIT.EDU (Geoffrey Thorpe)
Sat Apr 4 19:19:20 2026
Message-ID: <baa716ab-b215-4be7-812a-1e93bff22bb7@geoffthorpe.net>
Date: Sat, 4 Apr 2026 19:18:03 -0400
MIME-Version: 1.0
To: Russ Allbery <eagle@eyrie.org>
Cc: kenh@cmf.nrl.navy.mil, kerberos@mit.edu
Content-Language: en-US
From: Geoffrey Thorpe <geoff@geoffthorpe.net>
In-Reply-To: <87o6k0n6fm.fsf@hope.eyrie.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: kerberos-bounces@mit.edu
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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
