Re: Stateless PKINIT?
> Le 15 mars 2024 à 17:17, Greg Hudson a écrit : > > On 3/15/24 06:15, Yoann Gini wrote: >> Informations about the principal (name and everything) could be extracted >> from the certificate. Principal and certificate contains the same >> informations. > > To issue a ticket, the KDC doesn't need to know directory-type information > such as real names, but it does need to know Kerberos-specific policy > information like "how long can the ticket expiration time be". That > information could presumably be standardized across clients, which is why I > suggested a template principal. Understood! That's and interesting lead here. >> 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. > > The KDC does not need to write to the KDB, although it will attempt to do > writes to maintain account lockout state (which is irrelevant to the > configuration at hand). Attempts to write can be disabled via the settings > documented here: > > https://web.mit.edu/kerberos/krb5-latest/doc/admin/lockout.html#disable-lockout > > When synthesizing a client principal entry (or creating a template), be sure > to include the KRB5_KDB_REQUIRES_PRE_AUTH and KRB5_KDB_DISALLOW_SVR principal > flags. OK, thanks! Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Stateless PKINIT?
On 3/15/24 06:15, Yoann Gini wrote: Informations about the principal (name and everything) could be extracted from the certificate. Principal and certificate contains the same informations. To issue a ticket, the KDC doesn't need to know directory-type information such as real names, but it does need to know Kerberos-specific policy information like "how long can the ticket expiration time be". That information could presumably be standardized across clients, which is why I suggested a template principal. 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. The KDC does not need to write to the KDB, although it will attempt to do writes to maintain account lockout state (which is irrelevant to the configuration at hand). Attempts to write can be disabled via the settings documented here: https://web.mit.edu/kerberos/krb5-latest/doc/admin/lockout.html#disable-lockout When synthesizing a client principal entry (or creating a template), be sure to include the KRB5_KDB_REQUIRES_PRE_AUTH and KRB5_KDB_DISALLOW_SVR principal flags. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Stateless PKINIT?
Hi > Le 14 mars 2024 à 21:56, Greg Hudson 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 Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Stateless PKINIT?
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
Re: Stateless PKINIT?
>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: >— the KDC need to issue the needed TGT then TGS based on the identity >in the certificate if CRL is OK To get a TGT issued you need to send an AS-REQ, that's going to have a client principal in it, so normally that's already done. However, you are allowed to set the canonicalization flag as part of the AS-REQ message and the KDC can change the client principal. Note: this is where we reach the limits of my experience, so other may correct me on the following points. Also, I'm limiting my speaking to the MIT Kerberos implementation. 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. But neither of the current database implementations (db2 or LDAP) use that plugin API today. Note that third-party code may already exist that uses that API, but I am unfamiliar with it. It looks like if you go that route you have to add that certificate to the client request outside of PKINIT. In either case I do not believe you can actually just stick the SPNEGO API as that PKINIT would require initial ticket acquisition. It feels like a large number of the pieces are there, but I am not sure it's going to be turnkey. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
