Stateless PKINIT?

[Yoann Gini]

Hi

> Le 14 mars 2024 à 21:56, Greg Hudson <ghudson at MIT.EDU> a écrit :
> 
> 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.

Exactly

Informations about the principal (name and everything) could be extracted from the certificate. Principal and certificate contains the same informations.

> 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).

OK, no overlay is a limitation here indeed, it would have been the best option to mix template based response and internal DB. 

> 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.

That's an idea. Branching core product is always a impactful option for the future when it's time to follow main branch evolution, but that could be an option.

Other option I wonder is using the LDAP backend to answer dynamic content (we have an LDAP gateway in our codebase, so we can use it as a backend API between MIT Kerberos and our identity store).

Doing so the main issue would be to know what Kerberos need to write, to handle it. LDAP Gateway for read only is easy, supporting write operation however requires more work to ensure we handle all supported scenarios by the requesters.

I guess here also, it's not possible to use normal DB for R/W and LDAP in RO?

Best regards
Yoann