On Tue, Oct 07, 2014 at 09:40:12AM -0400, Simo Sorce wrote: > On Tue, 07 Oct 2014 09:29:33 -0400 > Rob Crittenden <rcrit...@redhat.com> wrote: > > > Simo Sorce wrote: > > > On Tue, 07 Oct 2014 13:47:05 +0200 > > > Martin Kosek <mko...@redhat.com> wrote: > > > > > >> On 10/07/2014 05:31 AM, Fraser Tweedale wrote: > > >>> Hi all, > > >>> > > >>> The Dogtag lightweight sub-CAs design has undergone major revision > > >>> and expansion ahead of beginning the implementation (I plan to > > >>> begin later this week). This feature will provide an API for > > >>> admins to create sub-CAs for separate security domains and > > >>> augment the existing API so that certificates requests can be > > >>> directed to a particular sub-CA. > > >>> > > >>> This feature will be used in FreeIPA for issuing user or service > > >>> certificates for particular purposes (that will be rejected when > > >>> use for other purposes). > > >>> > > >>> Please review the document and provide feedback. > > >>> > > >>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs > > >>> > > >>> Feedback/suggestions for the REST API (that FreeIPA will use) and > > >>> ACI considerations (e.g. is it appropriate to use the existing > > >>> "agent" credential or should a separate credential or more > > >>> fine-grained ACIs be used) are particularly encouraged. > > >>> > > >>> Cheers, > > >>> > > >>> Fraser > > >> > > >> Thanks for sharing the design! Couple initial comments: > > >> > > >>> Creating sub-CAs > > >>> > > >>> Creation of sub-CAs at any time after the initial spawning of an > > >>> CA instance is a requirement. Preferably, restart would not be > > >>> needed, however, if needed, it must be able to be performed > > >>> without manual intervention. > > >> > > >> I am all for having the operation in effect without requiring > > >> restart, especially given the change is in replicated tree. What > > >> do you mean by "restart without manual operation"? That Dogtag > > >> would restart itself when it detects that subCA would be added? > > >> > > >>> Key generation and storage > > >> > > >> Are we referring to > > >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP > > >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema > > >> ? Contact people: Jan Cholasta, Petr Spacek > > >> > > >> > > >>> ACI considerations > > >> > > >> Agent credential is used by FreeIPA web interface, all > > >> authorization is then done on python framework level. We can add > > >> more agents and then switch the used certificate, but I wonder how > > >> to use it in authorization decisions. Apache service will need to > > >> to have access to all these agents anyway. > > > > > > We really need to move to a separate service for agent access, the > > > framework is supposed to not have any more power than the user that > > > connects to it. By giving the framework direct access to > > > credentials we fundamentally change the proposition and erode the > > > security properties of the separation. > > > > > > We have discussed before a proxy process that pass in commands as > > > they come from the framework but assumes agent identity only after > > > checking how the framework authenticated to it (via GSSAPI). > > > > > >> First we need to think how fine grained authorization we want to > > >> do. > > > > > > We need to associate a user to an agent credential via a group, so > > > that we can assign the rights via roles. > > > > > >> I think we will want to be able to for example say that user Foo > > >> can generate certificates in specified subCA. I am not sure it is > > >> a good way to go, it would also make such private key distribution > > >> on IPA replicas + renewal a challenge. > > > > > > I do not think we need to start with very fine grained permissions > > > initially. > > > > > >> Right now, we only have "Virtual Operations" concept to authorize > > >> different operations with Dogtag CA, but it does not distinguish > > >> between different CAs. We could add a new Virtual Operation for > > >> every subCA, but it looks clumsy. But the ACI-based mechanism and > > >> our permission system would still be the easiest way to go, IMHO, > > >> compared to utilizing PKI agents. > > > > > > We need to have a different agent certificate per role, and then in > > > the proxy process associate the right agent certificate based on > > > what the framework asks and internal checking that the user is > > > indeed allowed to do so. > > > > > > The framework will select the 'role' to use based on the operation > > > to be performed. > > > > I totally agree in principle but this will add significant complexity > > to replication and renewal. > > We already have this issue with DNSSEC, so I think we can solve it the > same way (storing keys in LDAP encrypted with a master key). > > > Each agent cert will need to be tracked by certmonger and renewed > > automatically. The basic framework for that is in place and IIRC > > fairly generalized so this should be relatively simple, but we've had > > a few bumps in the road to renewal. > > Alternatively I think we can avoid this by having the proxy process > store the certs in LDAP (encrypted with the current main agent cert) > and renew them by calling out to certmonger if the certs are close to > expiration. We can make it simpler than it is now. > > > What I think will be more challenging is dealing with distribution of > > additional agent certs to other masters. We handle it now via > > ipa-replica-manage. > > See above :) > > > Given that it is a requirement to be able to generate sub-CAs > > post-install there needs to be some mechanism to share this > > certificate amongst the other IPA masters. > > > > On the bright side Fraser has already considered some of this, at > > least for sub-CA key distribution, but there are no no details > > fleshed out yet. > > This is critical in general, so having this privileged process on the > ipa side is necessary. It can handle access to keys for other uses too. > > For example I would like to use the same mechanism to switch to have > only an encrypted krbMaster key in LDAP and use this privileged process > pull it, unencrypt it with the local cert and then store it in a keytab > for the KDC to use). This is clearly a future development but it is > something we really need to move towards instead of adding "simpler" > workarounds in the current code. > > Simo. > >From further investigation, Dogtag CA clones all share a "subsystem certificate" that supports key wrapping; it should be possible (and fairly straightforward) to use this for securely distributing the sub-CA signing keys in LDAP.
Taking inspiration from the DNSSEC design, sub-CA signing keys would be unwrapped and added to the certificate database "just in time", when the replica first has need to use it. I agree that a common framework for distributing secrets among clones/replica is something we want. Fraser > -- > Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
