pkinit plugin logic in pkinit_srv.c

Greg Hudson ghudson at mit.edu
Thu Aug 24 14:47:27 EDT 2017


On 08/24/2017 01:42 PM, Craig Huckabee wrote:
> Right - the san module returns it, but the dbmatch module also returns
> it, and the eku check returns KRB5KDC_ERR_INCONSISTENT_KEY_PURPOSE.

The dbmatch module returns KRB5KDC_ERR_CERTIFICATE_MISMATCH (not the
same error code) if there is a "pkinit_cert_match" string attribute and
it does not match.  It passes if there is no such string attribute.

The eku module returns KRB5KDC_ERR_INCONSISTENT_KEY_PURPOSE if the cert
doesn't have the EKU for a PKINIT client cert, unless kdc.conf contains
"pkinit_eku_checking = none", in which case it passes.

> In my use case, I’m working with a DoD CAC so I have a SAN that looks
> like this "1234567890 at mil” - so to work around that I wanted to use the
> dbmatch feature to add the relation between that SAN and my actual
> principal.

We expected some users to want to authorize client certs which weren't
issued for PKINIT at all (so no id-pkinit-san SAN and no
id-pkinit-KPClientAuth EKU).  In this use case, the san module would
return KRB5_PLUGIN_NO_HANDLE, the admin would disable EKU checking so
that the eku modules returns KRB5_PLUGIN_NO_HANDLE, and the dbmatch
module would control authorization.

We didn't expect people to want to authorize client certs with an
id-pkinit-san SAN containing the wrong principal name.  The only way to
make that work in the current code is to use module configuration to
disable the san certauth module, which would mean that you'd have to use
dbmatch for everyone.

> But when the san module fails out with KRB5KDC_ERR_CLIENT_NAME_MISMATCH,
> the rest of the possible plugins are not called so I’ll never reach that
> dbmatch.
> Anything other than KRB5_PLUGIN_NO_HANDLE kicks it out of the loop.  I
> assume the intent is to process all possible plugins until a match is
> found so that check needs to be adjusted or maybe just removed.

It is intentional that certauth modules can authorize, explicitly deny,
or pass.  In this case the san module is explicitly denying the cert
because it found a PKINIT SAN for a different principal than the request
client principal.


More information about the krbdev mailing list