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