On 7.10.2014 15:40, 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.


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.



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
? 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

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

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).

Maybe it is worth mentioning some implementation details from DNSSEC support:

- *Every replica has own HSM* with standard PKCS#11 interface.
-- By default we install SoftHSM.
-- In theory it can be replaced with real HSM because the interface should be the same. This allows users to "easily" get FIPS 140 level 4 certified crypto instead of SoftHSM if they are willing to pay for it.

- Every replica has own private-public key pair stored in this HSM.
-- Key pair is generated inside HSM.
-- Private part will never leave local HSM.
-- Public part is stored in LDAP so all replicas can see it.

- *All* crypto operations are done inside HSM, no keys ever leave HSM in plain text.

- LDAP stores wrapped keys in this was:
-- DNS zone keys are wrapped with DNS master key.
-- DNS master key is wrapped with replica key.

Scenario: If replica 1 wants to use "key2" stored in LDAP by replica 2:
- Replica 1 downloads wrapped master key from LDAP.
- Replica 1 uses local HSM to unwrap the master key using own private key -> resulting master key is stored in local HSM and never leaves it. - Replica 1 downloads "key2" and uses master key in local HSM to unwrap "key2" -> resulting "key2" is stored in local HSM and never leaves it.

Naturally this forces applications to use PKCS#11 for all crypto so the raw key never leaves HSM. Luckily DNSSEC software is built around PKCS#11 so it was a natural choice for us.

Personally, I would say that this is the way to go.

Petr^2 Spacek

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

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.

Freeipa-devel mailing list

Reply via email to