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

[Jan Cholasta]

On 14.4.2016 08:56, Jan Cholasta wrote:
> 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.

(Forgot to CC Fraser.)

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