Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On 6.1.2017 10:30, Sumit Bose wrote: On Fri, Jan 06, 2017 at 08:50:14AM +0100, Jan Cholasta wrote: On 5.1.2017 10:39, Sumit Bose wrote: On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote: On 18.10.2016 07:34, Jan Cholasta wrote: On 17.10.2016 16:50, Rob Crittenden wrote: Jan Cholasta wrote: Hi, On 13.10.2016 18:52, Sumit Bose wrote: = Issuer specific matching = Although the MIT Kerberos rules allow to select the issuer of a certificate there are use cases where a more specific selection is needed. E.g. if there are some default matching rules for all issuers and some other issuer specific rules where the default rules should not apply. To make this possible with the above scheme the default rules must have an clause which matches all but the issuer with the specific rules. Writing regular-expressions to not match a specific string or a list of strings is at least error-prone if not impossible. To make it easier to define issuer specific rules and default rules at the same time and optional issuer string can be added to the rule to indicate that for the given issuer only those rules should be considered. Given the use-case I think it is acceptable to require that the full issuer must be specified here in LDAP order (see below) and case-sensitive matching is used. This could also be solved by adding priority to rules - if two rules match, the one with higher priority (the issuer specific rule) is preferred over the one with lower priority (the default rule). IMO this is better than an optional issuer string as it offers greater flexibility. The use cases I've seen haven't had to do with priority, though that would be a nice enhancement, but with only allowing certificates issued by a specific CA to be allowed (this is pretty common in web servers). Being able to say "only do the matching on certificates issued by foo" is valuable. Sure, I'm not suggesting that matching by issuer should be removed, only that rule precedence should not be determined by the issuer field setting. Bump. Sumit, what is your opinion on this? I'm fine with an optional(?) priority as well. Since priorities are already used in the pwpolicies this should be already known to the experienced admin. I guess we just have stick with "A lower value indicates a higher priority" to not confuse users. That's why I think that the priority should be optional here and a missing value indicates the lowest priority (default rules). In pwpolicy and sudorule, the priority is required and has to be unique. Maybe we should do this for certificate mapping rules as well? I think there is no requirement that only a single rule should match hence I think the priority here must not be unique. Is there a requirement that it must be possible for multiple rules to match? If not, we could begin with a simpler (for admin) solution with unique priorities and lift the restriction later when/if it becomes necessary. But I don't have a strong opinion on this. Are you thinking of using the CoS scheme here as well would a priority attribute be sufficient because we do not want to reference internal objects in the mapping rules? I'm not sure how CoS would be helpful here, I think a simple interger attribute would be perfectly sufficient. I agree. bye, Sumit bye, Sumit -- Jan Cholasta -- Jan Cholasta -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On Fri, Jan 06, 2017 at 08:50:14AM +0100, Jan Cholasta wrote: > On 5.1.2017 10:39, Sumit Bose wrote: > > On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote: > > > On 18.10.2016 07:34, Jan Cholasta wrote: > > > > On 17.10.2016 16:50, Rob Crittenden wrote: > > > > > Jan Cholasta wrote: > > > > > > Hi, > > > > > > > > > > > > On 13.10.2016 18:52, Sumit Bose wrote: > > > > > > > = Issuer specific matching = > > > > > > > Although the MIT Kerberos rules allow to select the issuer of a > > > > > > > certificate there are use cases where a more specific selection is > > > > > > > needed. E.g. if there are some default matching rules for all > > > > > > > issuers > > > > > > > and some other issuer specific rules where the default rules > > > > > > > should > > > > > > > not apply. To make this possible with the above scheme the default > > > > > > > rules must have an clause which matches all but the > > > > > > > issuer > > > > > > > with the specific rules. Writing regular-expressions to not match > > > > > > > a > > > > > > > specific string or a list of strings is at least error-prone if > > > > > > > not > > > > > > > impossible. > > > > > > > > > > > > > > To make it easier to define issuer specific rules and default > > > > > > > rules at > > > > > > > the same time and optional issuer string can be added to the rule > > > > > > > to > > > > > > > indicate that for the given issuer only those rules should be > > > > > > > considered. Given the use-case I think it is acceptable to require > > > > > > > that the full issuer must be specified here in LDAP order (see > > > > > > > below) > > > > > > > and case-sensitive matching is used. > > > > > > > > > > > > This could also be solved by adding priority to rules - if two rules > > > > > > match, the one with higher priority (the issuer specific rule) is > > > > > > preferred over the one with lower priority (the default rule). IMO > > > > > > this > > > > > > is better than an optional issuer string as it offers greater > > > > > > flexibility. > > > > > > > > > > The use cases I've seen haven't had to do with priority, though that > > > > > would be a nice enhancement, but with only allowing certificates > > > > > issued > > > > > by a specific CA to be allowed (this is pretty common in web servers). > > > > > Being able to say "only do the matching on certificates issued by foo" > > > > > is valuable. > > > > > > > > Sure, I'm not suggesting that matching by issuer should be removed, only > > > > that rule precedence should not be determined by the issuer field > > > > setting. > > > > > > > > > > Bump. Sumit, what is your opinion on this? > > > > I'm fine with an optional(?) priority as well. Since priorities are > > already used in the pwpolicies this should be already known to the > > experienced admin. I guess we just have stick with "A lower value > > indicates a higher priority" to not confuse users. That's why I think > > that the priority should be optional here and a missing value indicates > > the lowest priority (default rules). > > In pwpolicy and sudorule, the priority is required and has to be unique. > Maybe we should do this for certificate mapping rules as well? I think there is no requirement that only a single rule should match hence I think the priority here must not be unique. > > > > > Are you thinking of using the CoS scheme here as well would a priority > > attribute be sufficient because we do not want to reference internal > > objects in the mapping rules? > > I'm not sure how CoS would be helpful here, I think a simple interger > attribute would be perfectly sufficient. I agree. bye, Sumit > > > > > bye, > > Sumit > > > > > > > > -- > > > Jan Cholasta > > > -- > Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On 5.1.2017 10:39, Sumit Bose wrote: On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote: On 18.10.2016 07:34, Jan Cholasta wrote: On 17.10.2016 16:50, Rob Crittenden wrote: Jan Cholasta wrote: Hi, On 13.10.2016 18:52, Sumit Bose wrote: = Issuer specific matching = Although the MIT Kerberos rules allow to select the issuer of a certificate there are use cases where a more specific selection is needed. E.g. if there are some default matching rules for all issuers and some other issuer specific rules where the default rules should not apply. To make this possible with the above scheme the default rules must have an clause which matches all but the issuer with the specific rules. Writing regular-expressions to not match a specific string or a list of strings is at least error-prone if not impossible. To make it easier to define issuer specific rules and default rules at the same time and optional issuer string can be added to the rule to indicate that for the given issuer only those rules should be considered. Given the use-case I think it is acceptable to require that the full issuer must be specified here in LDAP order (see below) and case-sensitive matching is used. This could also be solved by adding priority to rules - if two rules match, the one with higher priority (the issuer specific rule) is preferred over the one with lower priority (the default rule). IMO this is better than an optional issuer string as it offers greater flexibility. The use cases I've seen haven't had to do with priority, though that would be a nice enhancement, but with only allowing certificates issued by a specific CA to be allowed (this is pretty common in web servers). Being able to say "only do the matching on certificates issued by foo" is valuable. Sure, I'm not suggesting that matching by issuer should be removed, only that rule precedence should not be determined by the issuer field setting. Bump. Sumit, what is your opinion on this? I'm fine with an optional(?) priority as well. Since priorities are already used in the pwpolicies this should be already known to the experienced admin. I guess we just have stick with "A lower value indicates a higher priority" to not confuse users. That's why I think that the priority should be optional here and a missing value indicates the lowest priority (default rules). In pwpolicy and sudorule, the priority is required and has to be unique. Maybe we should do this for certificate mapping rules as well? Are you thinking of using the CoS scheme here as well would a priority attribute be sufficient because we do not want to reference internal objects in the mapping rules? I'm not sure how CoS would be helpful here, I think a simple interger attribute would be perfectly sufficient. bye, Sumit -- Jan Cholasta -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote: > On 18.10.2016 07:34, Jan Cholasta wrote: > > On 17.10.2016 16:50, Rob Crittenden wrote: > > > Jan Cholasta wrote: > > > > Hi, > > > > > > > > On 13.10.2016 18:52, Sumit Bose wrote: > > > > > = Issuer specific matching = > > > > > Although the MIT Kerberos rules allow to select the issuer of a > > > > > certificate there are use cases where a more specific selection is > > > > > needed. E.g. if there are some default matching rules for all issuers > > > > > and some other issuer specific rules where the default rules should > > > > > not apply. To make this possible with the above scheme the default > > > > > rules must have an clause which matches all but the issuer > > > > > with the specific rules. Writing regular-expressions to not match a > > > > > specific string or a list of strings is at least error-prone if not > > > > > impossible. > > > > > > > > > > To make it easier to define issuer specific rules and default rules at > > > > > the same time and optional issuer string can be added to the rule to > > > > > indicate that for the given issuer only those rules should be > > > > > considered. Given the use-case I think it is acceptable to require > > > > > that the full issuer must be specified here in LDAP order (see below) > > > > > and case-sensitive matching is used. > > > > > > > > This could also be solved by adding priority to rules - if two rules > > > > match, the one with higher priority (the issuer specific rule) is > > > > preferred over the one with lower priority (the default rule). IMO this > > > > is better than an optional issuer string as it offers greater > > > > flexibility. > > > > > > The use cases I've seen haven't had to do with priority, though that > > > would be a nice enhancement, but with only allowing certificates issued > > > by a specific CA to be allowed (this is pretty common in web servers). > > > Being able to say "only do the matching on certificates issued by foo" > > > is valuable. > > > > Sure, I'm not suggesting that matching by issuer should be removed, only > > that rule precedence should not be determined by the issuer field setting. > > > > Bump. Sumit, what is your opinion on this? I'm fine with an optional(?) priority as well. Since priorities are already used in the pwpolicies this should be already known to the experienced admin. I guess we just have stick with "A lower value indicates a higher priority" to not confuse users. That's why I think that the priority should be optional here and a missing value indicates the lowest priority (default rules). Are you thinking of using the CoS scheme here as well would a priority attribute be sufficient because we do not want to reference internal objects in the mapping rules? bye, Sumit > > -- > Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On 18.10.2016 07:34, Jan Cholasta wrote: On 17.10.2016 16:50, Rob Crittenden wrote: Jan Cholasta wrote: Hi, On 13.10.2016 18:52, Sumit Bose wrote: = Issuer specific matching = Although the MIT Kerberos rules allow to select the issuer of a certificate there are use cases where a more specific selection is needed. E.g. if there are some default matching rules for all issuers and some other issuer specific rules where the default rules should not apply. To make this possible with the above scheme the default rules must have an clause which matches all but the issuer with the specific rules. Writing regular-expressions to not match a specific string or a list of strings is at least error-prone if not impossible. To make it easier to define issuer specific rules and default rules at the same time and optional issuer string can be added to the rule to indicate that for the given issuer only those rules should be considered. Given the use-case I think it is acceptable to require that the full issuer must be specified here in LDAP order (see below) and case-sensitive matching is used. This could also be solved by adding priority to rules - if two rules match, the one with higher priority (the issuer specific rule) is preferred over the one with lower priority (the default rule). IMO this is better than an optional issuer string as it offers greater flexibility. The use cases I've seen haven't had to do with priority, though that would be a nice enhancement, but with only allowing certificates issued by a specific CA to be allowed (this is pretty common in web servers). Being able to say "only do the matching on certificates issued by foo" is valuable. Sure, I'm not suggesting that matching by issuer should be removed, only that rule precedence should not be determined by the issuer field setting. Bump. Sumit, what is your opinion on this? -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On 25.11.2016 15:55, Sumit Bose wrote: On Fri, Nov 25, 2016 at 02:19:10PM +0100, Jan Cholasta wrote: Bump, Sumit, have you seen my comments? I haven't heard back from you. Yes, I've seen it and added a comment about it on the page https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates#Matching-alternativeRFC4523syntax To cut it short I would prefer to use a standard, but I think RFC4523 currently does nit meet out needs. But I would be happy if there are ways to mitigate my concerns. What I actually had in mind was not to use the full RFC 4523 syntax, but rather re-use the concepts used in it - for example, instead of using regular expressions to match subject names, we could use a scheme based on name constraints, where the subject name is matched using base + minimum distance + maximum distance, which could look like this, written down using glob-like syntax: directoryName=CN=a,O=b (base = CN=a,O=b, minimum distance = 0, maximum distance = 0) directoryName=*,O=b (base = O=b, minimum distance = 1, maximum distance = 1) directoryName=*,*,O=b (base = O=b, minimum distance = 2, maximum distance = 2) directoryName=**,*,O=b (base = O=b, minimum distance = 1, maximum distance unspecified) I'm working on updating and changing other sections as well and planned to reply when I'm done with the other sections as well. OK, thanks for the heads up. bye, Sumit On 17.10.2016 09:50, Jan Cholasta wrote: Hi, On 13.10.2016 18:52, Sumit Bose wrote: On Tue, Oct 11, 2016 at 01:37:09PM +0200, Sumit Bose wrote: On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote: Hi, I've started to write a SSSD design page about enhancing the current mapping of certificates to users and how to select/match a suitable certificate if multiple certificates are on a Smartcard. My currently thoughts and idea and be found at https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates and for your convenience below as well. Comments and suggestions are welcome. Please let me know about concerns, alternatives and missing use-cases/user-stories. bye, Sumit Hi, Rob, Fraser, Alexander, thank you for your comments. I think both the issuer specific matching and the OID in the SUBJECT matching are good ideas. I updated the design page accordingly. The changes can be shown with https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff=9_version=6 The updated version can be found below as well. Of course more comments and suggestions are still very welcome. I did another update. A "Compatibility with Active Director" section is added which made me realize that there are use-cases for using the issuer in the mapping as well and the sub-strings in LDAP search filters might be useful as well. The changes can be seen with https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff=10_version=9 Please let me know your comments and suggestions. bye, Sumit = Matching and Mapping Certificates = Related ticket(s): * http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping === Problem statement === Mapping Currently it is required that a certificate used for authentication is either stored in the LDAP user entry or in a matching override. This might not always be applicable and other ways are needed to relate a user with a certificate. Matching Even if SSSD will support multiple certificates on a Smartcard in the context of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict (or relax) the current certificate selection in certain environments. === Use cases === Mapping In some environments it might not be possible or would cause unwanted effort to add certificates to the LDAP entry of the users to allow Smartcard based authentication. Reasons might be: * Certificates/Smartcards are issued externally * LDAP schema extension is not possible or not allowed Matching A user might have multiple certificate on a Smartcard which are suitable for authentication. But on some host in the environment only certificates from a specific CA (while all other CAs are trusted as well) or with some special extension should be valid for login. === Overview of the solution === To match a certificate a language/syntax has to be defined which allows to reference items from the certificate and compare the values with the expected data. To map the certificates to a user the language/syntax should allow to relate certificate items with LDAP attributes so that the value(s) from the certificate item can be used in a LDAP search filter. Note that in some cases it might be possible to map a certificate to a user without having to do an extra LDAP search, for example when the certificate contains the principal name of the user. Does the design allow this? Or is there no extra LDAP search? === Implementation details
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
Bump, Sumit, have you seen my comments? I haven't heard back from you.
On 17.10.2016 09:50, Jan Cholasta wrote:
Hi,
On 13.10.2016 18:52, Sumit Bose wrote:
On Tue, Oct 11, 2016 at 01:37:09PM +0200, Sumit Bose wrote:
On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote:
Hi,
I've started to write a SSSD design page about enhancing the current
mapping of certificates to users and how to select/match a suitable
certificate if multiple certificates are on a Smartcard.
My currently thoughts and idea and be found at
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates
and for your convenience below as well.
Comments and suggestions are welcome. Please let me know about
concerns,
alternatives and missing use-cases/user-stories.
bye,
Sumit
Hi,
Rob, Fraser, Alexander, thank you for your comments. I think both the
issuer specific matching and the OID in the SUBJECT matching are good
ideas. I updated the design page accordingly. The changes can be shown
with
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff=9_version=6
The updated version can be found below as well. Of course more
comments and
suggestions are still very welcome.
I did another update. A "Compatibility with Active Director" section is
added which made me realize that there are use-cases for using the
issuer in the mapping as well and the sub-strings in LDAP search filters
might be useful as well.
The changes can be seen with
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff=10_version=9
Please let me know your comments and suggestions.
bye,
Sumit
= Matching and Mapping Certificates =
Related ticket(s):
*
http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping
=== Problem statement ===
Mapping
Currently it is required that a certificate used for authentication is
either stored in the LDAP user entry or in a matching override. This
might not always be applicable and other ways are needed to relate a
user with a certificate.
Matching
Even if SSSD will support multiple certificates on a Smartcard in the
context of https://fedorahosted.org/sssd/ticket/3050 it might be
necessary to restrict (or relax) the current certificate selection in
certain environments.
=== Use cases ===
Mapping
In some environments it might not be possible or would cause unwanted
effort to add certificates to the LDAP entry of the users to allow
Smartcard based authentication. Reasons might be:
* Certificates/Smartcards are issued externally
* LDAP schema extension is not possible or not allowed
Matching
A user might have multiple certificate on a Smartcard which are
suitable for authentication. But on some host in the environment only
certificates from a specific CA (while all other CAs are trusted as
well) or with some special extension should be valid for login.
=== Overview of the solution ===
To match a certificate a language/syntax has to be defined which
allows to reference items from the certificate and compare the values
with the expected data. To map the certificates to a user the
language/syntax should allow to relate certificate items with LDAP
attributes so that the value(s) from the certificate item can be used
in a LDAP search filter.
Note that in some cases it might be possible to map a certificate to a
user without having to do an extra LDAP search, for example when the
certificate contains the principal name of the user. Does the design
allow this? Or is there no extra LDAP search?
=== Implementation details ===
Matching
The pkinit plugin of MIT Kerberos must find a suitable certificate
from a Smartcard as well and has defined the following syntax (see the
pkinit_cert_match section of the krb5.conf man page or
http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html
for details). The main components are
* regular-expression
* regular-expression
* regular-expression
* extended-key-usage-list
* key-usage-list
and can be grouped together with a prefixed '&&' (and) or '`||`' (or)
operator ('&&' is the default). If multiple rules are given they are
iterated with the order in the config file as long as a rule matches
exactly one certificate.
'''Question: MIT Kerberos use case-sensitive matching and POSIX
Extended Regular Expression syntax, shall we do the same?'''
While and are (imo) already quite flexible I can
see some potential extensions for the other components.
I don't think regular expressions are a particularly good choice for DN
matching. It is difficult to express assertions which are quite natural
for DNs (matching multi-attribute RDNs, matching the same attribute type
by different identifiers, respecting the defined matching rules of
attribute types) and at the same time it is easy to express assertions
which do not make much sense for DNs (matching substrings in attribute
names, matching accross multiple syntactical
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On 17.10.2016 16:50, Rob Crittenden wrote: Jan Cholasta wrote: Hi, On 13.10.2016 18:52, Sumit Bose wrote: = Issuer specific matching = Although the MIT Kerberos rules allow to select the issuer of a certificate there are use cases where a more specific selection is needed. E.g. if there are some default matching rules for all issuers and some other issuer specific rules where the default rules should not apply. To make this possible with the above scheme the default rules must have an clause which matches all but the issuer with the specific rules. Writing regular-expressions to not match a specific string or a list of strings is at least error-prone if not impossible. To make it easier to define issuer specific rules and default rules at the same time and optional issuer string can be added to the rule to indicate that for the given issuer only those rules should be considered. Given the use-case I think it is acceptable to require that the full issuer must be specified here in LDAP order (see below) and case-sensitive matching is used. This could also be solved by adding priority to rules - if two rules match, the one with higher priority (the issuer specific rule) is preferred over the one with lower priority (the default rule). IMO this is better than an optional issuer string as it offers greater flexibility. The use cases I've seen haven't had to do with priority, though that would be a nice enhancement, but with only allowing certificates issued by a specific CA to be allowed (this is pretty common in web servers). Being able to say "only do the matching on certificates issued by foo" is valuable. Sure, I'm not suggesting that matching by issuer should be removed, only that rule precedence should not be determined by the issuer field setting. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On Thu, 2016-10-13 at 18:52 +0200, Sumit Bose wrote: > Compatibility with Active Directory > Active Directory uses a per-user LDAP attribute > [https://msdn.microsoft.com/en-us/library/cc220106.aspx > altSecurityIdentities] to allow arbitrary user-certificate mappings is there > is no suitable user-principal-name entry in the SAN of the certificate. > > Unfortunately it is more or less undocumented how AD use the values of > this attribute. The best overview I found is in > https://blogs.msdn.microsoft.com/spatdsg/2010/06/18/howto-map-a-user-to-a-certificate-via-all-the-methods-available-in-the-altsecurityidentities-attribute/. A few more pointers Sumit: - This describes what is allowed for users: https://msdn.microsoft.com/en-us/library/ms677943%28v=vs.85%29.aspx - This describes a use for devices: https://msdn.microsoft.com/en-us/library/dn408946.aspx - additional description specific for PKINIT: https://msdn.microsoft.com/en-us/library/hh536384.aspx - This is a good detailed overview of the Smart Card logon workflow in windows, it describes Vista but I do not think it changed in fundamental ways in following releases: https://msdn.microsoft.com/en-us/library/bb905527.aspx NOTE: Please look at the small paragraph named "Smart card logon across forests", we definitely want to think about this problem as well from the get-go and not try to retrofit something later on. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
Jan Cholasta wrote: Hi, On 13.10.2016 18:52, Sumit Bose wrote: = Issuer specific matching = Although the MIT Kerberos rules allow to select the issuer of a certificate there are use cases where a more specific selection is needed. E.g. if there are some default matching rules for all issuers and some other issuer specific rules where the default rules should not apply. To make this possible with the above scheme the default rules must have an clause which matches all but the issuer with the specific rules. Writing regular-expressions to not match a specific string or a list of strings is at least error-prone if not impossible. To make it easier to define issuer specific rules and default rules at the same time and optional issuer string can be added to the rule to indicate that for the given issuer only those rules should be considered. Given the use-case I think it is acceptable to require that the full issuer must be specified here in LDAP order (see below) and case-sensitive matching is used. This could also be solved by adding priority to rules - if two rules match, the one with higher priority (the issuer specific rule) is preferred over the one with lower priority (the default rule). IMO this is better than an optional issuer string as it offers greater flexibility. The use cases I've seen haven't had to do with priority, though that would be a nice enhancement, but with only allowing certificates issued by a specific CA to be allowed (this is pretty common in web servers). Being able to say "only do the matching on certificates issued by foo" is valuable. rob -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
Hi,
On 13.10.2016 18:52, Sumit Bose wrote:
On Tue, Oct 11, 2016 at 01:37:09PM +0200, Sumit Bose wrote:
On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote:
Hi,
I've started to write a SSSD design page about enhancing the current
mapping of certificates to users and how to select/match a suitable
certificate if multiple certificates are on a Smartcard.
My currently thoughts and idea and be found at
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates
and for your convenience below as well.
Comments and suggestions are welcome. Please let me know about concerns,
alternatives and missing use-cases/user-stories.
bye,
Sumit
Hi,
Rob, Fraser, Alexander, thank you for your comments. I think both the
issuer specific matching and the OID in the SUBJECT matching are good
ideas. I updated the design page accordingly. The changes can be shown
with
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff=9_version=6
The updated version can be found below as well. Of course more comments and
suggestions are still very welcome.
I did another update. A "Compatibility with Active Director" section is
added which made me realize that there are use-cases for using the
issuer in the mapping as well and the sub-strings in LDAP search filters
might be useful as well.
The changes can be seen with
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff=10_version=9
Please let me know your comments and suggestions.
bye,
Sumit
= Matching and Mapping Certificates =
Related ticket(s):
* http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping
=== Problem statement ===
Mapping
Currently it is required that a certificate used for authentication is either
stored in the LDAP user entry or in a matching override. This might not always
be applicable and other ways are needed to relate a user with a certificate.
Matching
Even if SSSD will support multiple certificates on a Smartcard in the context
of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict
(or relax) the current certificate selection in certain environments.
=== Use cases ===
Mapping
In some environments it might not be possible or would cause unwanted effort to
add certificates to the LDAP entry of the users to allow Smartcard based
authentication. Reasons might be:
* Certificates/Smartcards are issued externally
* LDAP schema extension is not possible or not allowed
Matching
A user might have multiple certificate on a Smartcard which are suitable for
authentication. But on some host in the environment only certificates from a
specific CA (while all other CAs are trusted as well) or with some special
extension should be valid for login.
=== Overview of the solution ===
To match a certificate a language/syntax has to be defined which allows to
reference items from the certificate and compare the values with the expected
data. To map the certificates to a user the language/syntax should allow to
relate certificate items with LDAP attributes so that the value(s) from the
certificate item can be used in a LDAP search filter.
Note that in some cases it might be possible to map a certificate to a
user without having to do an extra LDAP search, for example when the
certificate contains the principal name of the user. Does the design
allow this? Or is there no extra LDAP search?
=== Implementation details ===
Matching
The pkinit plugin of MIT Kerberos must find a suitable certificate from a
Smartcard as well and has defined the following syntax (see the
pkinit_cert_match section of the krb5.conf man page or
http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for
details). The main components are
* regular-expression
* regular-expression
* regular-expression
* extended-key-usage-list
* key-usage-list
and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator
('&&' is the default). If multiple rules are given they are iterated with the order in
the config file as long as a rule matches exactly one certificate.
'''Question: MIT Kerberos use case-sensitive matching and POSIX Extended
Regular Expression syntax, shall we do the same?'''
While and are (imo) already quite flexible I can see some
potential extensions for the other components.
I don't think regular expressions are a particularly good choice for DN
matching. It is difficult to express assertions which are quite natural
for DNs (matching multi-attribute RDNs, matching the same attribute type
by different identifiers, respecting the defined matching rules of
attribute types) and at the same time it is easy to express assertions
which do not make much sense for DNs (matching substrings in attribute
names, matching accross multiple syntactical elements, etc.).
That said, does the design have to be based on the MIT pkinit matching?
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On Tue, Oct 11, 2016 at 01:37:09PM +0200, Sumit Bose wrote:
> On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote:
> > Hi,
> >
> > I've started to write a SSSD design page about enhancing the current
> > mapping of certificates to users and how to select/match a suitable
> > certificate if multiple certificates are on a Smartcard.
> >
> > My currently thoughts and idea and be found at
> > https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates
> > and for your convenience below as well.
> >
> > Comments and suggestions are welcome. Please let me know about concerns,
> > alternatives and missing use-cases/user-stories.
> >
> > bye,
> > Sumit
> >
>
> Hi,
>
> Rob, Fraser, Alexander, thank you for your comments. I think both the
> issuer specific matching and the OID in the SUBJECT matching are good
> ideas. I updated the design page accordingly. The changes can be shown
> with
> https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff=9_version=6
>
> The updated version can be found below as well. Of course more comments and
> suggestions are still very welcome.
>
I did another update. A "Compatibility with Active Director" section is
added which made me realize that there are use-cases for using the
issuer in the mapping as well and the sub-strings in LDAP search filters
might be useful as well.
The changes can be seen with
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff=10_version=9
Please let me know your comments and suggestions.
bye,
Sumit
= Matching and Mapping Certificates =
Related ticket(s):
* http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping
=== Problem statement ===
Mapping
Currently it is required that a certificate used for authentication is either
stored in the LDAP user entry or in a matching override. This might not always
be applicable and other ways are needed to relate a user with a certificate.
Matching
Even if SSSD will support multiple certificates on a Smartcard in the context
of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict
(or relax) the current certificate selection in certain environments.
=== Use cases ===
Mapping
In some environments it might not be possible or would cause unwanted effort to
add certificates to the LDAP entry of the users to allow Smartcard based
authentication. Reasons might be:
* Certificates/Smartcards are issued externally
* LDAP schema extension is not possible or not allowed
Matching
A user might have multiple certificate on a Smartcard which are suitable for
authentication. But on some host in the environment only certificates from a
specific CA (while all other CAs are trusted as well) or with some special
extension should be valid for login.
=== Overview of the solution ===
To match a certificate a language/syntax has to be defined which allows to
reference items from the certificate and compare the values with the expected
data. To map the certificates to a user the language/syntax should allow to
relate certificate items with LDAP attributes so that the value(s) from the
certificate item can be used in a LDAP search filter.
=== Implementation details ===
Matching
The pkinit plugin of MIT Kerberos must find a suitable certificate from a
Smartcard as well and has defined the following syntax (see the
pkinit_cert_match section of the krb5.conf man page or
http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for
details). The main components are
* regular-expression
* regular-expression
* regular-expression
* extended-key-usage-list
* key-usage-list
and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator
('&&' is the default). If multiple rules are given they are iterated with the
order in the config file as long as a rule matches exactly one certificate.
'''Question: MIT Kerberos use case-sensitive matching and POSIX Extended
Regular Expression syntax, shall we do the same?'''
While and are (imo) already quite flexible I can see some
potential extensions for the other components.
and in MIT Kerberos only accept certain string values related to
some allowed values in those field as defined in
https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by
what is supported on server side of the pkinit plugin of MIT Kerberos. Since we
plan to extend pkinit and support local authentication without pkinit as well I
would suggest to allow OID strings for those components as well (the comparison
is done on the OID level nonetheless).
The component in MIT Kerberos only checks the otherName SAN component for
the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the
szOID_NT_PRINCIPAL_NAME OID as mentioned in
https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the
default pkinit user case
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote:
> Hi,
>
> I've started to write a SSSD design page about enhancing the current
> mapping of certificates to users and how to select/match a suitable
> certificate if multiple certificates are on a Smartcard.
>
> My currently thoughts and idea and be found at
> https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates
> and for your convenience below as well.
>
> Comments and suggestions are welcome. Please let me know about concerns,
> alternatives and missing use-cases/user-stories.
>
> bye,
> Sumit
>
Hi,
Rob, Fraser, Alexander, thank you for your comments. I think both the
issuer specific matching and the OID in the SUBJECT matching are good
ideas. I updated the design page accordingly. The changes can be shown
with
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff=9_version=6
The updated version can be found below as well. Of course more comments and
suggestions are still very welcome.
bye,
Sumit
= Matching and Mapping Certificates =
Related ticket(s):
* http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping
=== Problem statement ===
Mapping
Currently it is required that a certificate used for authentication is either
stored in the LDAP user entry or in a matching override. This might not always
be applicable and other ways are needed to relate a user with a certificate.
Matching
Even if SSSD will support multiple certificates on a Smartcard in the context
of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict
(or relax) the current certificate selection in certain environments.
=== Use cases ===
Mapping
In some environments it might not be possible or would cause unwanted effort to
add certificates to the LDAP entry of the users to allow Smartcard based
authentication. Reasons might be:
* Certificates/Smartcards are issued externally
* LDAP schema extension is not possible or not allowed
Matching
A user might have multiple certificate on a Smartcard which are suitable for
authentication. But on some host in the environment only certificates from a
specific CA (while all other CAs are trusted as well) or with some special
extension should be valid for login.
=== Overview of the solution ===
To match a certificate a language/syntax has to be defined which allows to
reference items from the certificate and compare the values with the expected
data. To map the certificates to a user the language/syntax should allow to
relate certificate items with LDAP attributes so that the value(s) from the
certificate item can be used in a LDAP search filter.
=== Implementation details ===
Matching
The pkinit plugin of MIT Kerberos must find a suitable certificate from a
Smartcard as well and has defined the following syntax (see the
pkinit_cert_match section of the krb5.conf man page or
http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for
details). The main components are
* regular-expression
* regular-expression
* regular-expression
* extended-key-usage-list
* key-usage-list
and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator
('&&' is the default). If multiple rules are given they are iterated with the
order in the config file as long as a rule matches exactly one certificate.
'''Question: MIT Kerberos use case-sensitive matching and POSIX Extended
Regular Expression syntax, shall we do the same?'''
While and are (imo) already quite flexible I can see some
potential extensions for the other components.
and in MIT Kerberos only accept certain string values related to
some allowed values in those field as defined in
https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by
what is supported on server side of the pkinit plugin of MIT Kerberos. Since we
plan to extend pkinit and support local authentication without pkinit as well I
would suggest to allow OID strings for those components as well (the comparison
is done on the OID level nonetheless).
The component in MIT Kerberos only checks the otherName SAN component for
the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the
szOID_NT_PRINCIPAL_NAME OID as mentioned in
https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the
default pkinit user case of MIT Kerberos I would suggest to extend this
component by allowing to specific an OID with
= Issuer specific matching =
Although the MIT Kerberos rules allow to select the issuer of a certificate
there are use cases where a more specific selection is needed. E.g. if there
are some default matching rules for all issuers and some other issuer specific
rules where the default rules should not apply. To make this possible with the
above scheme the default rules must have an clause which matches all
but the issuer with
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On Fri, Oct 07, 2016 at 09:35:00AM +0300, Alexander Bokovoy wrote: > On pe, 07 loka 2016, Fraser Tweedale wrote: > > On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote: > > > > > Question, do we need search-and-replace at all (or at this > > > stage)? Most of the interesting values from the SAN should be > > > directly map-able to LDAP attributes. And processing the string > > > representation of might be tricky as discussed below. > > > Nevertheless the following might be possible: > > > > > > * /regexp/replacement/ > > > * /regexp/replacement/ > > > > > > where "/regexp/replacement/" stands for optional sed-like > > > substitution rules. E.g. a rule like > > > > > >/^CN=\([^,]*\).*$/\1/ > > > > > > would take the subject string > > > 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and > > > generate a LDAP search filter component > > > '(samAccountName=Certuser)' which can be included in a LDAP search > > > filter which includes additional components like e.g. an > > > objectClass. > > > > > A counter-proposal w.r.t. DN mapping: > > > > > > > > Where OID is either an actual OID or the corresponding string i.e. > > "CN", "O", etc. This would extract the "most specific" (leftmost in > > the LDAP sense, rightmost in the X.500 sense) attribute value of the > > specified type from the Subject DN. > > > > IMO this would cover most DN mapping use cases whilst avoiding regex > > or confusion about RDN order. Therefore your original example of: > > > >/^CN=\([^,]*\).*$/\1/ > > > > can be accomplished with: > > > > > > > > In the spirit of "make the simple things simple, and the hard things > > possible" it is probably necessary to retain the regex variant to > > handle more complex DN mapping use cases, e.g. where there are > > multiple occurrences of a single attribute type, a particular fixed > > RDN must be matched, etc. > > > > w.r.t. SAN mapping, I concur that search/replace is probably not > > needed. > How all these syntax extensions are going to handle multi-valued RDN? > In the variant I proposed, it is handled fine because it selects the "most specific" occurrence of that attribute type. An attribute type cannot appear twice in the same RDN so this is unambiguous. For the regex variant, because `RDN ::= SET OF AVA' we would have to ensure that the stringified DN uses a deterministic order for attribute types (probably lexicographic order on corresponding LDAP attribute name) within a multi-valued RDN and clearly document this. It will be up to admins to define the correct regex based on naming of the certificates they use. Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On pe, 07 loka 2016, Fraser Tweedale wrote: On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote: Question, do we need search-and-replace at all (or at this stage)? Most of the interesting values from the SAN should be directly map-able to LDAP attributes. And processing the string representation of might be tricky as discussed below. Nevertheless the following might be possible: * /regexp/replacement/ * /regexp/replacement/ where "/regexp/replacement/" stands for optional sed-like substitution rules. E.g. a rule like /^CN=\([^,]*\).*$/\1/ would take the subject string 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and generate a LDAP search filter component '(samAccountName=Certuser)' which can be included in a LDAP search filter which includes additional components like e.g. an objectClass. A counter-proposal w.r.t. DN mapping: Where OID is either an actual OID or the corresponding string i.e. "CN", "O", etc. This would extract the "most specific" (leftmost in the LDAP sense, rightmost in the X.500 sense) attribute value of the specified type from the Subject DN. IMO this would cover most DN mapping use cases whilst avoiding regex or confusion about RDN order. Therefore your original example of: /^CN=\([^,]*\).*$/\1/ can be accomplished with: In the spirit of "make the simple things simple, and the hard things possible" it is probably necessary to retain the regex variant to handle more complex DN mapping use cases, e.g. where there are multiple occurrences of a single attribute type, a particular fixed RDN must be matched, etc. w.r.t. SAN mapping, I concur that search/replace is probably not needed. How all these syntax extensions are going to handle multi-valued RDN? -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote: > Question, do we need search-and-replace at all (or at this > stage)? Most of the interesting values from the SAN should be > directly map-able to LDAP attributes. And processing the string > representation of might be tricky as discussed below. > Nevertheless the following might be possible: > > * /regexp/replacement/ > * /regexp/replacement/ > > where "/regexp/replacement/" stands for optional sed-like > substitution rules. E.g. a rule like > >/^CN=\([^,]*\).*$/\1/ > > would take the subject string > 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and > generate a LDAP search filter component > '(samAccountName=Certuser)' which can be included in a LDAP search > filter which includes additional components like e.g. an > objectClass. > A counter-proposal w.r.t. DN mapping: Where OID is either an actual OID or the corresponding string i.e. "CN", "O", etc. This would extract the "most specific" (leftmost in the LDAP sense, rightmost in the X.500 sense) attribute value of the specified type from the Subject DN. IMO this would cover most DN mapping use cases whilst avoiding regex or confusion about RDN order. Therefore your original example of: /^CN=\([^,]*\).*$/\1/ can be accomplished with: In the spirit of "make the simple things simple, and the hard things possible" it is probably necessary to retain the regex variant to handle more complex DN mapping use cases, e.g. where there are multiple occurrences of a single attribute type, a particular fixed RDN must be matched, etc. w.r.t. SAN mapping, I concur that search/replace is probably not needed. Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
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 set like CN=ca,DC=abd,DC=comclientAuth CN=ca,DC=def,DC=commsScLogin 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 CN=ca,DC=abd,DC=comclientAuth 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 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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
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 set like CN=ca,DC=abd,DC=comclientAuth CN=ca,DC=def,DC=commsScLogin 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 CN=ca,DC=abd,DC=comclientAuth 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 a required field but allow that the lazy admin can just enter a '*' to match any issuer? > 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. bye, Sumit > > rob -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
Sumit Bose wrote:
Hi,
I've started to write a SSSD design page about enhancing the current
mapping of certificates to users and how to select/match a suitable
certificate if multiple certificates are on a Smartcard.
My currently thoughts and idea and be found at
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates
and for your convenience below as well.
Comments and suggestions are welcome. Please let me know about concerns,
alternatives and missing use-cases/user-stories.
bye,
Sumit
= Matching and Mapping Certificates =
Related ticket(s):
*
http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping
=== Problem statement ===
Mapping
Currently it is required that a certificate used for authentication is either
stored in the LDAP user entry or in a matching override. This might not always
be applicable and other ways are needed to relate a user with a certificate.
Matching
Even if SSSD will support multiple certificates on a Smartcard in the context
of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict
(or relax) the current certificate selection in certain environments.
=== Use cases ===
Mapping
In some environments it might not be possible or would cause unwanted effort to
add certificates to the LDAP entry of the users to allow Smartcard based
authentication. Reasons might be:
* Certificates/Smartcards are issued externally
* LDAP schema extension is not possible or not allowed
Matching
A user might have multiple certificate on a Smartcard which are suitable for
authentication. But on some host in the environment only certificates from a
specific CA (while all other CAs are trusted as well) or with some special
extension should be valid for login.
=== Overview of the solution ===
To match a certificate a language/syntax has to be defined which allows to
reference items from the certificate and compare the values with the expected
data. To map the certificates to a user the language/syntax should allow to
relate certificate items with LDAP attributes so that the value(s) from the
certificate item can be used in a LDAP search filter.
=== Implementation details ===
Matching
The pkinit plugin of MIT Kerberos must find a suitable certificate from a
Smartcard as well and has defined the following syntax (see the
pkinit_cert_match section of the krb5.conf man page or
http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for
details). The main components are
* regular-expression
* regular-expression
* regular-expression
* extended-key-usage-list
* key-usage-list
and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator
('&&' is the default). If multiple rules are given they are iterated with the order in
the config file as long as a rule matches exactly one certificate.
'''Question: MIT Kerberos use case-sensitive matching and POSIX Extended
Regular Expression syntax, shall we do the same?'''
While and are (imo) already quite flexible I can see some
potential extensions for the other components.
and in MIT Kerberos only accept certain string values related to
some allowed values in those field as defined in https://www.ietf.org/rfc/rfc3280.txt . The
selection is basically determined by what is supported on server side of the pkinit plugin
of MIT Kerberos. Since we plan to extend pkinit and support local authentication without
pkinit as well I would suggest to allow OID strings for those components as well (the
comparison is done on the OID level nonetheless).
The component in MIT Kerberos only checks the otherName SAN component for the
id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the
szOID_NT_PRINCIPAL_NAME OID as mentioned in https://support.microsoft.com/en-us/kb/287547.
While this is sufficient for the default pkinit user case of MIT Kerberos I would suggest
to extend this component by allowing to specific an OID with
Mapping
Since different certificates, e.g. issued by different CAs, might have
different mapping rule, a matching rule must be added if there are more than 1
mapping rule. A single mapping rule without a matching rule might be used as
default/catch-all rule in this case.
If multiple rules matches the derived LDAP filter components can be grouped with the
or-operator "|".
A mapping rule can use a similar syntax like the matching rule where the LDAP
attribute can be added with a ':', e.g.
*
*
Currently I see no usage for , and in mapping rules because they
do not contain any user-specific data. If at some point we will have personal CAs we might consider to
add based mappings.
'''Question, do we need search-and-replace at all (or at this stage)? Most of the
interesting values from the SAN should be directly map-able to LDAP attributes. And
processing the string representation of might be tricky as discussed
below.
[Freeipa-devel] [RFC] Matching and Mapping Certificates
Hi,
I've started to write a SSSD design page about enhancing the current
mapping of certificates to users and how to select/match a suitable
certificate if multiple certificates are on a Smartcard.
My currently thoughts and idea and be found at
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates
and for your convenience below as well.
Comments and suggestions are welcome. Please let me know about concerns,
alternatives and missing use-cases/user-stories.
bye,
Sumit
= Matching and Mapping Certificates =
Related ticket(s):
* http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping
=== Problem statement ===
Mapping
Currently it is required that a certificate used for authentication is either
stored in the LDAP user entry or in a matching override. This might not always
be applicable and other ways are needed to relate a user with a certificate.
Matching
Even if SSSD will support multiple certificates on a Smartcard in the context
of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict
(or relax) the current certificate selection in certain environments.
=== Use cases ===
Mapping
In some environments it might not be possible or would cause unwanted effort to
add certificates to the LDAP entry of the users to allow Smartcard based
authentication. Reasons might be:
* Certificates/Smartcards are issued externally
* LDAP schema extension is not possible or not allowed
Matching
A user might have multiple certificate on a Smartcard which are suitable for
authentication. But on some host in the environment only certificates from a
specific CA (while all other CAs are trusted as well) or with some special
extension should be valid for login.
=== Overview of the solution ===
To match a certificate a language/syntax has to be defined which allows to
reference items from the certificate and compare the values with the expected
data. To map the certificates to a user the language/syntax should allow to
relate certificate items with LDAP attributes so that the value(s) from the
certificate item can be used in a LDAP search filter.
=== Implementation details ===
Matching
The pkinit plugin of MIT Kerberos must find a suitable certificate from a
Smartcard as well and has defined the following syntax (see the
pkinit_cert_match section of the krb5.conf man page or
http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for
details). The main components are
* regular-expression
* regular-expression
* regular-expression
* extended-key-usage-list
* key-usage-list
and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator
('&&' is the default). If multiple rules are given they are iterated with the
order in the config file as long as a rule matches exactly one certificate.
'''Question: MIT Kerberos use case-sensitive matching and POSIX Extended
Regular Expression syntax, shall we do the same?'''
While and are (imo) already quite flexible I can see some
potential extensions for the other components.
and in MIT Kerberos only accept certain string values related to
some allowed values in those field as defined in
https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by
what is supported on server side of the pkinit plugin of MIT Kerberos. Since we
plan to extend pkinit and support local authentication without pkinit as well I
would suggest to allow OID strings for those components as well (the comparison
is done on the OID level nonetheless).
The component in MIT Kerberos only checks the otherName SAN component for
the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the
szOID_NT_PRINCIPAL_NAME OID as mentioned in
https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the
default pkinit user case of MIT Kerberos I would suggest to extend this
component by allowing to specific an OID with
Mapping
Since different certificates, e.g. issued by different CAs, might have
different mapping rule, a matching rule must be added if there are more than 1
mapping rule. A single mapping rule without a matching rule might be used as
default/catch-all rule in this case.
If multiple rules matches the derived LDAP filter components can be grouped
with the or-operator "|".
A mapping rule can use a similar syntax like the matching rule where the LDAP
attribute can be added with a ':', e.g.
*
*
Currently I see no usage for , and in mapping rules because
they do not contain any user-specific data. If at some point we will have
personal CAs we might consider to add based mappings.
'''Question, do we need search-and-replace at all (or at this stage)? Most of
the interesting values from the SAN should be directly map-able to LDAP
attributes. And processing the string representation of might be
tricky as discussed below. Nevertheless the following
