Stateless PKINIT?

Greg Hudson ghudson at mit.edu
Thu Mar 14 16:56:37 EDT 2024


On 3/14/24 15:27, Ken Hornstein via Kerberos wrote:
>> Is there a way when using PKINIT to not need any internal list of
>> principals but to rely on the validity of the certificate to proxy the
>> certificate identity into the Kerberos ticket?
> 
> I know what all of those words are, but I'm unclear what they mean all
> together.  I think you mean _this_ step:

I believe Yoann is asking for a KDC configuration where the KDB contains 
server principal entries (including a krbtgt entry) but no client 
principal entries.  PKINIT does not require client long-term keys, and 
other client principal fields (except for the name) could be taken from 
a template entry.

MIT krb5 does not currently have this ability with the built-in KDB 
modules.  It could be done with a custom KDB module, but that module 
would also have to provide all of the regular KDB functionality for the 
server principal entries, and the KDB interface isn't designed to be 
stackable (meaning it isn't trivial to implement an overlay).

Alternatively, I think it would be a relatively simple change to the 
core KDC code to support this: do_as_req.c:lookup_client() could look up 
a template at a fixed name (WELLKNOWN/CLIENT-TEMPLATE or something) if 
the regular client lookup fails, and substitute in the requested name.

> It looks like there is some code in the MIT KDC to perform such
> a lookup; the database plugin API contains a function called
> krb5_db_get_s4u_x509_principal(), which takes a client certificate.

This KDB method is there to support S4U2Self requests where the 
requesting server presents an X.509 certificate instead of a cient 
principal name.  It


More information about the Kerberos mailing list