Re: Stateless PKINIT?
"Greg Hudson" <[email protected]> Thu, 14 Mar 2024 16:56:37 -0400
| Newsgroups | gmane.comp.encryption.kerberos.general |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos