[Freeipa-devel] DNs of Custodia keys

[Jan Cholasta]

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>

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