[19642] in Kerberos_V5_Development
Re: pkinit plugin logic in pkinit_srv.c
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Aug 24 15:27:03 2017
To: Craig Huckabee <craig.huckabee@spawar.navy.mil>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <b3dd1954-7cfa-cf44-b9c3-a96dc3625e52@mit.edu>
Date: Thu, 24 Aug 2017 15:26:49 -0400
MIME-Version: 1.0
In-Reply-To: <C87B094A-36F9-4225-BFA2-8C11906C598B@spawar.navy.mil>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="windows-1252"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On 08/24/2017 03:09 PM, Craig Huckabee wrote:
>> 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.
By NT-Principal type SAN, you mean 1.3.6.1.4.1.311.20.2.3 (User
Principal Name)? We can handle those, if you set
"pkinit_allow_upn = true" in kdc.conf in the realm configuration (or in
[kdcdefaults]). The value has to match the request client principal, of
course.
It may be that we presently have the wrong behavior if the cert contains
a UPN SAN and pkinit_allow_upn = false (the default). In that case the
upn module should probably return KRB5_PLUGIN_NO_HANDLE but might now be
returning a mismatch.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
