[38146] in Kerberos
Re: set_string/pkinit_cert_match
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Dec 28 14:56:18 2017
To: "Pallissard, Matthew" <kerberos@pallissard.net>, kerberos@mit.edu
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <ddc50af9-c670-0e7b-2ef1-1a7fd48f009f@mit.edu>
Date: Thu, 28 Dec 2017 14:56:00 -0500
MIME-Version: 1.0
In-Reply-To: <20171228190533.bhplkathphu2ynjg@laptop.ihme.uw.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On 12/28/2017 02:05 PM, Pallissard, Matthew wrote:
> I'm having issues when trying to use set_string with pkinit_cert_match. PKINIT does work when the SAN matches the user's principal explicitly. It does not work when I try to map it to a user where the principal does not match the SAN.
The intended use case for pkinit_cert_match is client certificates which
weren't issued for use with PKINIT at all, and therefore have no
id-pkinit-san values. If there is an id-pkinit-san value, the KDC
requires it to match the requested client principal. Currently, the
only way to allow this is to disable the pkinit_san module:
[plugins]
certauth = {
disable = pkinit_san
}
You would then have to specify a pkinit_cert_match string for every
principal, as SAN matching would be turned off entirely.
If enough people have the use case where they want certificates with
mismatched id-pkinit-san values to be accepted based on matching
strings, we could provide a more convenient configuration hook for it.
I had (perhaps naively) assumed that if people were going to the trouble
of issuing client certs with id-pkinit-san values, they could include
values for all of the desired client principal names.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
