[Freeipa-devel] Dogtag lightweight sub-CAs; updated design

[Simo Sorce]

On Tue, 07 Oct 2014 09:29:33 -0400
Rob Crittenden <rcritten at redhat.com> wrote:

> Simo Sorce wrote:
> > On Tue, 07 Oct 2014 13:47:05 +0200
> > Martin Kosek <mkosek at 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.

-- 
Simo Sorce * Red Hat, Inc * New York