[Freeipa-devel] DNs of Custodia keys

[Fraser Tweedale]

On Tue, Apr 12, 2016 at 12:55:50PM +0200, Jan Cholasta wrote:
> Hi,
> 
> On 12.4.2016 09:03, Fraser Tweedale wrote:
> >Hi Simo and Honza et al,
> >
> >I have a design challenge pertaining to DNs for Custodia keys.
> >DNs for Custodia keys for host principals currently take the form:
> >
> >     cn={sig,enc}/$HOSTNAME,cn=custodia,cn=ipa,cn=etc,$SUFFIX
> >
> >This prevents the creation of Custodia keys for service principals
> >(pursuant to another recent design decision[1] the service principal
> >'dogtag-ipa-custodia/$HOSTNAME@$REALM' shall be used as a Custodia
> >client for Dogtag lightweight CA key replication).
> 
> This naming scheme is relevant only to IPA server keys, otherwise the cn can
> be anything, as long as it does not conflict with existing keys.
> 
> >
> >[1] https://www.redhat.com/archives/freeipa-devel/2016-April/msg00044.html
> >
> >Searches for custodia keys use a filter on 'ipaKeyUsage' and
> >'memberPrincipal' attributes, so the CN is unimportant except for
> >a) uniqueness, and b) ACIs (see below).
> >
> >Based on this, my first attempt to resolve the conflict was to use
> >the service name and host name instead of the just the hostname:
> >
> >     cn=sig/host/f23-5.ipa.local at IPA.LOCAL,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local
> >
> >However, this fails during replica install:
> >
> >   [2/5]: Generating ipa-custodia keys
> >   {'info': "Insufficient 'add' privilege to add the entry
> >             'cn=sig/host/f23-5.ipa.local,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local'.\n",
> >    'desc': 'Insufficient access'}
> >
> >due to the ACI:
> >
> >     dn: cn=ipa,cn=etc,$SUFFIX
> >     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 wildcard '*' in the target is not greedy and stops at the first
> >slash '/', so the value captured by the ($dn) macro does not match
> >the bind DN.
> 
> Again, this is relevant only to IPA server keys, you should add your own ACI
> for lightweight CAs.
> 
> >
> >
> >Proposed solution
> >-----------------
> >
> >Use a delimiter other than '/' between the key type and service
> >name, e.g.
> >
> >     cn={sig,enc}+$SERVICENAME/$HOSTNAME        (rule)
> >     cn=sig+dogtag-ipa-custodia/f23-3.ipa.local (example)
> >
> >Pros: should work with existing ACIs.
> >
> >Cons: continues with an arguably suboptimal design choice.
> >
> >
> >Alternative solution
> >--------------------
> >
> >Add an 'ipaCustodiaKey' object class, which has 'managedBy'
> >attribute for linking the key to the host that manages it, and
> >'ipaUniqueId'.
> >
> >Create key entries with autogenerated ipaUniqueId as RDN.
> >
> >Add ACIs:
> >
> >     dn: cn=ipa,cn=etc,$SUFFIX
> >     add:aci: (target = "ldap:///*,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 userattr = "managedby#USERDN";)
> >     add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") (targetattr = "ipaPublicKey")
> >         (version 3.0; acl "IPA server hosts can manage own Custodia secrets";
> >         allow(write) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX"
> >         and userattr = "managedby#USERDN";)
> >
> >(Retain existing ACIs for backwards compatiblity.)
> 
> Actually this has been discussed before:
> <https://www.redhat.com/archives/freeipa-devel/2015-November/msg00547.html>
> 
Thanks for the link and feedback.

Something like the following ACI should do the trick, I think?

  add:aci: (target = "ldap:///cn=*/dogtag-ipa-custodia/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")
      (version 3.0; acl "IPA server hosts can manage Custodia secrets for the dogtag-ipa-custodia service on same host";
      allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX"
      and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)

Host Custodia keys would keep the existing CN schema and existing
ACLs will apply only to them.

Cheers,
Fraser

> >
> >
> >Let me know what you think!
> 
> I think that all you have to do is add a new ACI for your purposes, you
> don't need to change anything.
> 
> Honza
> 
> -- 
> Jan Cholasta