[Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia

[Petr Spacek]

On 7.4.2016 15:20, Fraser Tweedale wrote:
> On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote:
>> On 7.4.2016 12:13, Christian Heimes wrote:
>>> On 2016-04-07 11:09, Petr Spacek wrote:
>>>> On 7.4.2016 08:43, Fraser Tweedale wrote:
>>>>> Hi team,
>>>>>
>>>>> I updated the Sub-CAs design page with more detail for the key
>>>>> replication[1].  This part of the design is nearly complete (a large
>>>>> patchset is in review over at pki-devel@) but there are various
>>>>> options about how to authenticate to Custodia.
>>>>>
>>>>> [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication
>>>>>
>>>>> In brief, the options are:
>>>>>
>>>>> 1) authenticate as host principal; install binary setuid
>>>>>    root:pkiuser to read host keytab and custodia keys.
>>>>
>>>> Huh, I really do not like this. Host keytab on IPA master is one of the most
>>>> sensitive keys we have.
>>>>
>>>> Maybe gssproxy can be used somehow, but I think it would be better to use
>>>> separate key.
>>>>
>>>>
>>>>> 2) authenticate as host principal; copy host keytab and custodia
>>>>>    keys to location readable by pkiuser.
>>>>
>>>> No, really, do not copy host keytab anywhere.
>>>>
>>>>
>>>>> 3) create new principal for pkiuser to use, along with custodia keys
>>>>>    and keytab in location readable by pkiuser.
>>>>>
>>>>> I prefer option (1) for reasons outlined in the design page.  The
>>>>> design page goes into quite a bit more detail so please review the
>>>>> section linked above and get back to me with your thoughts.
>>>>
>>>> The only downside of (3) using new keys is:
>>>> ... This approach requires the creation of new principals, and Kerberos
>>>> keytabs and Custodia keys for those principals, as part of the
>>>> installation/upgrade process.
>>>>
>>>> Compared with additional SUID binary this seems as safer and easier way to go.
>>>> FreeIPA installers already create quite a lot of principals and keytabs so
>>>> this is well understood task.
>>>>
>>>> I would do (3).
>>>
>>> +1 for (3)
>>>
>>> A SUID binary feels like a dangerous hack.
>>
>> +1
>>
> OK, (3) it is.  Thanks all for your input.
> 
> Now for next question: what should service principal name be?  I
> think `dogtag/example.com at EXAMPLE.COM' but am open to other
> suggestions, e.g. `pki/...'.

Do you plan to attempt to standardize this name in future? I do not expect that.

Considering private nature of it, it should be as specific as possible to
avoid any potential conflicts with future standards. "dogtag-key-replication"
sounds like a good candidate.

Before you set the name in stone make sure it does not conflict with anything
listed on
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

These names have potential to be used by someone else.

-- 
Petr^2 Spacek