[Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication

[Fraser Tweedale]

On Tue, Apr 26, 2016 at 10:02:45AM +0200, Jan Cholasta wrote:
> On 21.4.2016 05:30, Fraser Tweedale wrote:
> >On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote:
> >>Hi all,
> >>
> >>The attached patches configure lightweight CA key replication on IPA
> >>CAs, on upgrade and installation.
> >>
> >>Patches 0051..0052 from my other mail are also needed for the system
> >>to work, but this patchset does not depend on them and can be
> >>reviewed independently.
> >>
> >>There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1
> >>- it just puts the necessary principals/keys/configuration in place.
> >>
> >>Cheers,
> >>Fraser
> >>
> >New patches attached;  0054-2 changes the service name from
> >'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the
> >principal to search server Custodia keys.
> 
Honza, thanks for review.  Comments inline.

> Patch 53:
> 
> I'm not sure about this approach - the cn of custodia keys in LDAP is a
> free-form string, I would not tie it to service names, but rather try to
> keep it short.
> 
> In the key replication section of the design page, you mention "ca/$NAME", I
> think this is a good template for the cn and that we should stick to it.
> 
This scheme (or something like it, *without* '/' as the separator)
is needed to satisfy the ACI that allows host principals to manage
Custodia keys:

    add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")
    (version 3.0; acl "IPA server hosts can create own Custodia secrets";
      allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX"
             and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)

The CN must contain the hostname, and we must also disambiguate on
key type.  The current scheme is:

    {sig,enc}~dogtag/<HOSTNAME>
    e.g.
    enc~dogtag/f23-2.ipa.local

The first separator cannot be '/' because the '*' wildcard in the
ACI is not greedy - the captured text would include the servicename
and fail to match any userdn.

If you do not like '~' feel free to suggest a different symbol :)
The alternative is to add more ACIs.

> 
> Patch 54:
> 
> 1) This belongs to CAInstance.configure_instance():
> 
> +    CA = cainstance.CAInstance(
> +            api.env.realm, certs.NSS_DIR, host_name=api.env.host)
> +    CA.setup_lightweight_ca_key_retrieval()
> 
See comments for (5).

> 
> 2) Any ACI changes should be in a separate patch. (What happened to patch
> 52?)
> 
Patch 52 added an ACI that allowed any authenticated user to see the
keys.  Simo wanted it limited it to the Dogtag principal so I
rescinded patch 52 and added the ACI in the same patch where the
principal was added.

Separate patch is no problem; I will resurrect number 52.

> 
> 3) This is not a platform constant, just a constant:
> 
> +    PKI_GSSAPI_SERVICE_NAME = 'dogtag'
> 
Thanks, will put it in `ipalib.constants'.

> 
> 4) CAInstance.setup_lightweight_ca_key_retrieval() does too much. Please
> split it into a "setup keytab" and "setup custodia" parts.
> 
Will extract methods for next patchset.

> 
> 5) This also belongs to CAInstance.configure_instance():
> 
> +    if setup_ca:
> +        # CA was configured before Kerberos;
> +        # add Custodia client princ and keys now
> +        ca_instance.setup_lightweight_ca_key_retrieval()
> 
> In order for that to work, you need to move the ca.install_step_1() after
> krb.create_instance(), but that should be OK, since KrbInstance does not
> talk to the CA.
> 
`setup_lightweight_ca_key_retrieval' calls `kadmin_addprinc', which
fails if called before `krb.create_instance' due to missing
krb5.conf::

    2016-05-03T06:29:23Z DEBUG args=kadmin.local -q addprinc -randkey dogtag/f23-2.ipa.local at IPA.LOCAL -x ipa-setup-override-restrictions
    2016-05-03T06:29:23Z DEBUG Process finished, return code=1
    2016-05-03T06:29:23Z DEBUG stdout=
    2016-05-03T06:29:23Z DEBUG stderr=kadmin.local: unable to get default realm

Moving `ca.install_step_1()' to after `krb.create_instance()' does
not help, because `CAInstance.configure_instance' is called from
`ca.install_step_0()'.

However, calling `CAInstance.setup_lightweight_ca_key_retrieval()'
*directly* from `ca.install_step_1' would probably work.  Are you
happy with putting it there, instead of `configure_instance()'?

Cheers,
Fraser