On Fri, May 29, 2015 at 12:54:13PM +0200, Martin Kosek wrote:
> On 05/29/2015 12:33 PM, Sumit Bose wrote:
> >On Fri, May 29, 2015 at 12:10:24PM +0200, Martin Kosek wrote:
> >>On 05/29/2015 11:26 AM, Sumit Bose wrote:
> >>>On Fri, May 29, 2015 at 10:38:41AM +0200, Martin Kosek wrote:
> >>>>Hello all,
> >>>>
> >>>>I would like to discuss the scope needed for ticket 4905 [1]. This is 
> >>>>mostly
> >>>>question for Sumit as he is working on the SSSD SC support. The main 
> >>>>minimal
> >>>>target is to allow SSSD get a ticket for a user once he authenticates with
> >>>>his SC with certificates tracked in FreeIPA as agreed in [2].
> >>>>
> >>>>Sumit, Simo or others, what changes are required in order to do this? In
> >>>>[1], I so far identified:
> >>>>
> >>>>* Support of Smart Cards in SSSD (​upstream ticket)
> >>>>* API/CLI for configuring the trusted CA certificate in KDC (related - 
> >>>>#616)
> >>>>
> >>>>as the base. What else is needed? Any krb5.conf changes on the
> >>>>server/clients? Or even generating the certs/keys as mentioned in [3]?
> >>>
> >>>currently I would say krb5.conf both on IPA clients and servers already
> >>>have all the needed entries.
> >>
> >>Doesn't FreeIPA KDC need a list of CAs issuing the Smart Cards that it can 
> >>trust?
> >
> >in general yes. If there are certificate which are not created by the
> >IPA CA and have the id-pkinit-san entry we currently would need a
> >pkinit_anchors in krb5.conf pointing to the CA cert.
> This would need to be set on all IPA masters or the clients too? Would it be
> possible to update our KDC driver to tell KDC what is the location of these
> certs or anyhow feed it with the certs when they are available?

After reading the man pages again it looks that pkinit_anchors is only
needed to validate the certificate of the KDC itself. As long as this is
issued by the IPA CA all should be fine. The user certificates are
checked by the pkinit plugin via OpenSSL with the help of the CA certs
that are accessible to OpenSSL. So if the user certificate is signed by
a CA which is currently not known it has to be distributed to all hosts.

But I checked the IPA install code as well and realized that there is
'options.setup_pkinit = False' in ipa-server-install. I will check at
the beginning of next week if this can be removed.

> >But I guess this
> >should go into the documentation because the cert of the other CA might
> >not be available at installation time.
> Right, it wouldn't be. We would need to have an API to add/remove those
> external CA certificates.
> >
> >Since we have to touch the Kerberos pkinit code anyway to support
> >certificates without the id-pkinit-san entry we might add other ways to
> >make the CA cert available, e.g. by storing it at some place in the
> >directory tree.
> Would the id-pkinit-san entry be needed if we implement the client lookup
> within SSSD?


> >
> >>
> >>>>In current code base, we still have the disabled pkinit plugin [4], but I
> >>>>assume this is not what we want.
> >>>
> >>>I think this is only for anonymous pkinit. The general pkinit preauth
> >>>plugin is automatically available as long as the krb5-pkinit package is
> >>>installed. The package contains both client and server side of the
> >>>plugin, so it must be available on IPA clients and servers.
> >>
> >>Ok. This can be added to Requires, that's a simple change.
> >>
> >>>>Thanks for help and advise. Based on what is found out in this thread, we
> >>>>will see what's realistic for FreeIPA 4.2 or FreeIPA 4.2.x.
> >>>
> >>>My understanding is that the current version of the MIT Kerberos pkinit
> >>>plugin needs a id-pkinit-san entry in the Subject Alternatives Names of
> >>>the certificate with the Kerberos principal of the given user.
> >>>
> >>>I think it would be good to add this entry to user certificates IPA
> >>>generates on its own. The pkinit RFC 4556 mentioned that the KDC can do
> >>>the mapping between the certificate and the user principal on its own.
> >>
> >>Can SSSD aid the mapping anyhow? It will know what is the user principal,
> >>based on FreeIPA special mapping.
> >
> >Sure, as soon as the 'Certificate Identity Mapping' is specified I can
> >implement the lookups in SSSD which do not require that the certificate
> >is stored in the directory tree. We have to determine what would be the
> >best way for the KDC/pkinit plugin to access SSSD for this. Currently
> >only InfoPipe/D-BUS supports certificate lookups which might not be the
> >best choice here.
> I see, thanks. In any case what you wrote above does seem as something post 
> 4.2.

yes. My plan would be to add everything what is needed to make SSSD work
with what is already available in MIT Kerberos first and then try to
enhance the pkinit plugin.


> >
> >HTH
> >
> >bye,
> >Sumit
> >
> >>
> >>>But given that afaik there is currently no support for this scheme in
> >>>the MIT pkinit plugin and hence it would require enhancements in the MIT
> >>>code and maybe in the IPA KDB backend as well I think the support for
> >>>certificates without a id-pkinit-san entry is out-of-scope for 4.2.
> >>
> >>I see.
> >>
> >>>Nevertheless client side authentication would still work only the user
> >>>will not have a valid Kerberos TGT after logging in.
> >>>
> >>>HTH
> >>>
> >>>bye,
> >>>Sumit
> >>>
> >>>>
> >>>>[1] https://fedorahosted.org/freeipa/ticket/4905
> >>>>[2] http://www.freeipa.org/page/V4/User_Certificates
> >>>>[3] https://fedorahosted.org/freeipa/ticket/55#comment:3
> >>>>[4] 
> >>>>https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/plugins/pkinit.py
> >>>>
> >>>>--
> >>>>Martin Kosek <mko...@redhat.com>
> >>>>Supervisor, Software Engineering - Identity Management Team
> >>>>Red Hat Inc.
> >>

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to