[Freeipa-devel] DNs of Custodia keys

[Simo Sorce]

On Tue, 2016-04-12 at 21:26 +1000, Fraser Tweedale wrote:
> 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.

You may also think of adding a subtree specific to subCA keys perhaps.

Simo.