[Freeipa-devel] [RFC] Matching and Mapping Certificates

[Rob Crittenden]

Sumit Bose wrote:
> On Thu, Oct 06, 2016 at 10:33:48AM -0400, Rob Crittenden wrote:
>> Sumit Bose wrote:
>>> Hi,
>>>
>>>
>>
>> Wow, this is really great.
>
> Hi Rob,
>
> thank you for the feedback.
>
>>
>> I think I'd pre-plan to support different configuration per issuer subject,
>> with one named default. It shouldn't be a lot more work and will
>> future-proof things for you, particularly in how the rules are stored in
>> LDAP.
>>
>> I worry a bit about matching without comparing the certificate for the case
>> where you don't examine issuer.
>>
>
> Do I understand it correctly that you are looking for rules which will
> always and only match for certificate from a given issuer? E.g. if all
> matching rules will have the <ISSUER> set like
>
>      <ISSUER>CN=ca,DC=abd,DC=com<EKU>clientAuth
>      <ISSUER>CN=ca,DC=def,DC=com<EKU>msScLogin
>
> certificates from the abc issue must have clientAuth set to be valid for
> authentication and certificates from issuer def must have msScLogin set.
> But you are right, if one rule does not have issuer set like
>
>      <ISSUER>CN=ca,DC=abd,DC=com<EKU>clientAuth
>      <EKU>msScLogin
>
> then a certificate from issuer abc which does not have clientAuth set
> but msScLogin would be accepted as well.
>
> Do you think it would help to make <ISSUER> a required field but allow
> that the lazy admin can just enter a '*' to match any issuer?

Yes, that is basically what I was proposing, and mostly to ensure that 
the data is stored in such away that adding rules per issuer would be 
easy/possible in the future. It probably hits 80/20 by supporting only a 
single set of rules for the 1.0 release.

>> You may want to have an option to require that the presented cert match the
>> one stored in LDAP (off by default). I realize that you specifically mention
>> this can be problematic, but it can also be quite useful. It can be used,
>> for example, to disable a login by removing the certificate from the user's
>> entry. It also ensures that some carefully crafted certificate doesn't allow
>> a bad actor to map to a user account.
>
> This happens when no mapping rule is given. Then SSSD will fall
> back to search/map the user with the whole certificate. And if the
> certificate is removed from the LDAP entry of the user Smartcard
> authentication will fail as soon as the user entry in the cache of SSSD
> is expired.

I wonder if some might want both at the same time. Match using rules and 
then also confirm the certificate matches, if it is available in the 
entry, with a require/optional setting to decide what to do in case the 
cert isn't in LDAP.

rob