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

Reply via email to