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

[Simo Sorce]

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.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"?
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: P-Box-option-1.pdf
Type: application/pdf
Size: 55944 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20160419/fd99eecd/attachment.pdf>