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/[email protected]' 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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
