Elementary PKINIT questions (MIT Kerberos/Linux configuration)

[Ken Hornstein]

>First problem: I have a second principal, jason/admin, for use with 
>kadmin. I've generated a certificate that can authenticate. However, now 
>that I have two certificates (one for jason and another for 
>jason/admin), it isn't clear how to configure the client to offer the 
>correct certificate to the kdc. If I specify both certificates on 
>pkinit_identities lines in the client's krb5.conf file, "jason" can log 
>in, but kadmin returns a "Client name mismatch while initializing kadmin 
>interface" error. My assumptions is that the wrong certificate was 
>offered to the KDC (i.e., not the jason/admin certificate). Specifying 
>the directory containing the certificates in pkinit_identities results 
>in finding two certificates where one is expected, with an error message 
>to that effect.

The bottom line is you need to make only one certificate available
to the PKINIT client code.  This is kind of a corner case; you don't
normally have a single Unix user with two valid certificates.  But
there are some options.

You can specify the certificate exactly on the 'kinit' command line
with the "-X X509_user_identity" option (this has the same format
as the pkinit_identities option in krb5.conf).  Now this option isn't
supported for kadmin, but you can do:

% kinit -X X509_user_identity=FILE:/tmp/foo.pem -S kadmin/admin jason/admin

or

% kinit -X X509_user_identity=FILE:/tmp/foo.pem -S kadmin/admin.host jason/admin

Depending on the principal you are using for kadmind, and then you can use
the "-c credential_cache" option to kadmin to use an existing credential
cache.

>Do I need to specify a PKINIT certificate matching rule, or is there 
>some other configuration that is required?

I do not think a matching rule would help; it sounds like you have two
distinct certificates but I cannot think of a generic match rule that
would match one certificate but not another based on the requested
principal.

>Second problem: securing the client's private key. The Linux client has 
>a TPM 2.0 module, but I haven't found any documentation on how to 
>configure it for use with Kerberos, if indeed this is supported. 
>References would be welcome.

The incredibly short answer here is that the only generic mechanism
supported for hardware storage of private keys is a PKCS#11 module.  A
quick Google suggests that there are PKCS#11 modules which can interface
with a TPM module.  However, I have to caution you that when using a
PKCS#11 module with Kerberos the hardware backed by the PKCS#11 module
has to contain the certificate _and_ keys.  There's not a way to say,
"The cert is on this file and the private key is available in this
module".  (I COULD be wrong about this, but a quick glance at the source
code suggests that I am correct).  A very quick Google only shows the
PKCS#11 module that interfaces with TPM storing private keys; it MAY
support storing a certificate as well, but it may not.  You're going to
be kind of on the fringe here is what I'm trying to say.

>The machine has a smartcard reader, so my other options would be to 
>purchase some compatible smartcards (after finding out what those are), 
>or a security key. In the latter case, I would probably choose a FIDO 2 
>key with smartcard support.

I would also caution you that the same issue applies as above; you need
to make sure your smartcard (a) has a PKCS#11 module available (on Linux
this probably means OpenSC) and (b) it supports storing certificates on
the smartcard.

I have had success using a YubiKey 5 in PIV mode which also supports
a bunch of other things like FIDO 2; I have no connection with Yubico
other than as a user.  Yubico provides a PKCS#11 module but in PIV mode
you should be able to use any PKCS#11 module that supports PIV (this is
very common).  One advantage to a YubiKey is it is just USB and does not
require a dedicated smartcard reader.  Note that this is a lot of moving
parts and probably will require a fair amount of fiddling.

--Ken