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

  • recent certificate failure for pkinit

    From Matt Zagrabelny@21:1/5 to kerberos on Mon Jul 8 13:54:40 2024
    Greetings Kerberos-users,

    I've been successfully using OTP and pkinit for the past year or so. Within
    the last week, or so, it has started to fail with:

    client:
    $ /usr/bin/kinit -n -c /tmp/.kerberos_cache
    kinit: Preauthentication failed while getting initial credentials

    KDC:
    KDC_RETURN_PADATA: WELLKNOWN/ANONYMOUS@EXAMPLE.COM for krbtgt/ EXAMPLE.COM@EXAMPLE.COM, Failed to verify own certificate (depth 0): unable
    to get local issuer certificate

    I've looked at the KDC and CA certs and their expiration dates are still
    valid.

    Looking at the system, the packages have recently been updated due to
    Debian patching the krb5 packages for a CVE:

    krb5 (1.20.1-2+deb12u2) bookworm-security; urgency=high

    * CVE-2024-37370: an unauthenticated attacker can modify the
    extra count in an RFC 4121 GSS token, causing the token to appear
    truncated.
    * CVE-2024-37371: an attacker can cause invalid memory reads by
    sending an invalid GSS token.

    -- Sam Hartman <hartmans@debian.org> Mon, 01 Jul 2024 11:31:35 -0600

    I've tried to downgrade the packages, but the error persists.

    I have enabled tracing via the KRB5_TRACE=/dev/stdout variable, for both
    the client and KDC. Nothing really stands out.

    Does anyone have any ideas about where to look next?

    Thanks for the help!

    -m

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carson Gaspar@21:1/5 to Matt Zagrabelny via Kerberos on Mon Jul 8 17:52:21 2024
    On 7/8/2024 2:54 PM, Matt Zagrabelny via Kerberos wrote:
    Greetings Kerberos-users,

    I've been successfully using OTP and pkinit for the past year or so. Within the last week, or so, it has started to fail with:

    client:
    $ /usr/bin/kinit -n -c /tmp/.kerberos_cache
    kinit: Preauthentication failed while getting initial credentials

    KDC:
    KDC_RETURN_PADATA:WELLKNOWN/ANONYMOUS@EXAMPLE.COM for krbtgt/ EXAMPLE.COM@EXAMPLE.COM, Failed to verify own certificate (depth 0): unable to get local issuer certificate

    I've run into this error before. MIT's KDC, for some bizarre reason,
    insists that its server cert validate against the same set of CAs used
    to authorize client PKINIT certs. This is insecure and a terrible idea,
    but oh well. So make sure that the KDC server cert validates against the
    set of CAs you've specified in the config file.

    If you want more debugging, AFAIK you'll need to recompile the pkinit
    plugin and set a CPP debug macro to 1 to get more useful info out of it
    (and the debug output goes to stderr as I recall).

    --

    Carson

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ken Hornstein@21:1/5 to All on Mon Jul 8 21:29:32 2024
    KDC:
    KDC_RETURN_PADATA:WELLKNOWN/ANONYMOUS@EXAMPLE.COM for krbtgt/
    EXAMPLE.COM@EXAMPLE.COM, Failed to verify own certificate (depth 0): unable >> to get local issuer certificate

    I've run into this error before. MIT's KDC, for some bizarre reason,
    insists that its server cert validate against the same set of CAs used
    to authorize client PKINIT certs. This is insecure and a terrible idea,
    but oh well. So make sure that the KDC server cert validates against the
    set of CAs you've specified in the config file.

    The full chain is needed on the KDC side so intermediate certificates
    can be sent in the CMS object, and the easiest way to get the full chain
    with OpenSSL is to call X509_verify_cert().

    However, I disagree with your assertion that this is insecure. In my experience certificates used by the KDC and clients are all issued by
    the same PKI, so there's nothing insecure about trusting the same set
    of certificates for both (and in the above example if you are using
    anonymous PKINIT you're not using a client certificate anyway).

    If I was in the situation where client certificates were issued by a
    different PKI than the KDC certificate and I didn't trust the PKI
    that was issuing the KDC certificate I would probably write a certauth
    plugin to reject client certificates signed by the "wrong" PKI.

    --Ken

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