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

[Jan Cholasta]

On 7.4.2016 16:17, Petr Spacek wrote:
> 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.

IMO it shouldn't be *that* specific, considering we want to switch 
Dogtag from SSL to GSSAPI authentication to DS, which will probably use 
the same principal name. I think "ipa-pki/..." or "dogtag/..." should be 
fine.

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

-- 
Jan Cholasta