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

[Fraser Tweedale]

On Thu, May 05, 2016 at 07:48:05AM +0200, Jan Cholasta wrote:
> On 4.5.2016 06:04, Fraser Tweedale wrote:
> >On Tue, May 03, 2016 at 05:05:58PM +1000, Fraser Tweedale wrote:
> >>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.
> 
> I would rather add a new ACI than have one super-ACI for everything. That
> way you don't have to invent any complicated naming schemes *and* it will be
> more apparent what the ACI does.
> 
OK, I'll simplify the scheme and create corresponding ACIs.

> BTW I'm a little bit confused as to what Dogtag keys will actually be stored
> in Custodia. My naive understanding is that it would be the CA signing key
> of each CA, but seeing how there's a host name and key usage in the name,
> I'm not so sure. Could you clarify this, or point me to a design where it is
> explained?
> 
Dogtag lightweight CA signing keys are stored in Dogtag's NSSDB
(/etc/pki/pki-tomcat/alias), alongside the "main" CA signing key,
subsystem keys, etc.  Custodia provides access to those keys, but
those are not the keys that this patchset creates.

The keys being dealt with in this patchset are keys for the Custodia
client - running as pkiuser - to authenticate to a Custodia client,
and for encrypting the response.  They serve no other purpose.  It
is explained at [1] (note: the design page still refers to the old
principal name 'dogtag-ipa-custodia').

[1] http://www.freeipa.org/page/V4/Sub-CAs#Authenticating_to_Custodia

> >>>
> >>>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()'.
> 
> Right. *slaps forehead*
> 
> >>
> >>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()'?
> 
> Works for me.
> 
Cool, thanks.