On Tue, 2016-04-19 at 21:57 -0400, Simo Sorce wrote: > On Wed, 2016-04-20 at 11:32 +1000, Fraser Tweedale wrote: > > 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....@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"? > > As a target ? > None, in which case are you going to use the dogtag keytab for the > acceptor though ? > > > For communication from IPA framework to Dogtag, > > we will need a way to force the client to use an alternative service > > name. > > Our pbox design says differently. > We'll just interpose gssproxy and we'll be able to safely share the HTTP > key for all services.
Ah this is not finalized yet, but attached find an initial draft. > > As for the actual service name, I will use "dogtag/..." > > Good to use as a client. > > Simo. > > > 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 > > > > -- Simo Sorce * Red Hat, Inc * New York
P-Box-option-1.pdf
Description: Adobe PDF document
-- 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