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

[Fraser Tweedale]

On Tue, Apr 19, 2016 at 07:48:27AM +0200, Jan Cholasta wrote:
> 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.)
> 
What is HTTP client support like for principal names with service
part /= "HTTP"?  For communication from IPA framework to Dogtag,
we will need a way to force the client to use an alternative service
name.

As for the actual service name, I will use "dogtag/..."

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