1. Forum
  2. Usenet
  3. COMP.PROTOCOLS.KERBEROS

  • Re: Stateless PKINIT?

    From Ken Hornstein@21:1/5 to Yoann Gini on Thu Mar 14 15:27:45 2024
    Copy: kerberos@mit.edu

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Hudson@21:1/5 to Ken Hornstein on Thu Mar 14 16:56:37 2024
    To: yoann.gini@gmail.com (Yoann Gini)
    Copy: kerberos@mit.edu

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Hudson@21:1/5 to Yoann Gini on Fri Mar 15 12:17:44 2024
    Copy: kenh@cmf.nrl.navy.mil (Ken Hornstein)
    Copy: kerberos@mit.edu

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)