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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
