[39596] in Kerberos
Re: interested in discussing some Kerberos improvements
daemon@ATHENA.MIT.EDU (Russ Allbery)
Fri Apr 3 00:38:10 2026
From: Russ Allbery <eagle@eyrie.org>
To: Ken Hornstein via Kerberos <kerberos@mit.edu>
In-Reply-To: <202604030220.6332K860020338@hedwig.cmf.nrl.navy.mil> (Ken
Hornstein via Kerberos's message of "Thu, 02 Apr 2026 22:20:07 -0400")
Date: Thu, 02 Apr 2026 21:37:54 -0700
Message-ID: <87ika8mzfh.fsf@hope.eyrie.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
