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