[Freeipa-devel] DNs of Custodia keys

[Petr Spacek]

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).
> 
> [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.

The question is if the * behaves as expected. CCing Ludwig ...

Petr^2 Spacek

> 
> 
> 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.)
> 
> 
> Let me know what you think!
> 
> Cheers,
> Fraser
> 


-- 
Petr^2 Spacek