pkinit plugin logic in pkinit_srv.c
Craig Huckabee
craig.huckabee at spawar.navy.mil
Thu Aug 24 15:09:15 EDT 2017
> On Aug 24, 2017, at 2:47 PM, Greg Hudson <ghudson at mit.edu> wrote:
>
> On 08/24/2017 01:42 PM, Craig Huckabee wrote:
>
>> 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.
>
Unfortunately the SAN present isn’t a id-pkinit-san, these cards are only issued with the NT-Principal type SAN, so that is what I have to work with.
I’ll revert my build and try disabling the plugin to see if that still works. Thanks for the context.
—Craig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1753 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20170824/fc9b15d9/attachment-0001.bin
More information about the krbdev
mailing list