[Freeipa-devel] PKINIT Handling in mixed/CA-less topologies

[Martin Babinsky]

Hi List,

TL;DR we have to handle FAST channer establishment  when KDC is not issued
PKINIT keypair

I have spent some time studying and fixing bugs/regressions caused by
incomplete consideration of PKINIT and anonymous principal setup regarding to

* replicas standed up against old (3.0.0) masters
* domain level 0 topologies
* CA-less deployments

I want to discuss the impact of these findings on existing functionality and
how to fix them so that 4.5.1 release will be more usable and free of subtle
but serious bugs (more on this later).

>From conversation from Alexander and Simo it follows that anonymous PKINIT
feature is supposed to be used in domain level 1 deployments because only these
guarantee the presence of the features (CA ACLs and custom certificate
profiles) which allow for issuing certificates suitable for PKINIT
authentication. This leads to the following considerations:

* on DL0 enforce no_pkinit on server/replica deployments
* during upgrade of DL0 deployments, do not issue PKINIT certificates
* during upgrade of DL1 deployments issue PKINIT certs
* extend ipa-server-certinstall to install/issue PKINIT certificates after
  DL0/DL1 ugrade (have to be manually).

However, I found out that the only case when anonymous PKINIT actually works is
for fresh DL1 server install and upgrade and install of 4.5.0 replica against
4.5.0 master in DL1. The following use-cases either fail to install or leave
the system with unusable password auth (e.g. WebUI login):

* setting up 4.5 replica against <4.5 master fails during anonymous
  principal setup[1] (ticket states domain level 0, but DL1 is also
  affected)
* setting up server-replica with `no_pkinit` option (CA-full or CA-less)
  leaves the installation without non-working WebUI as anonymous PKINIT does
  not work (ticket incoming)
* If we restrict DL0 installs to force no_pkinit[2] we will be left with
  whole topologies where anonymous PKINIT does not work, so no WebUI auth
  for them

We now have to decide how to properly support or avoid non-PKINIT deployments.
The current code which handles armoring of password auth requests[3] does not
actually work without PKINIT certificates, the fallback mechanism still fails
to obtain armor ccache[4].

I have concluded that for non-PKINIT cases we have
to use the old way to armor TGT request (i.e. establish fast channel by
kinit as service principal), but this means that the framewrok has to use a
service principal whose keytab it can read and use. After privilege separation,
however, we do not have direct access to HTTP keytab so how should we proceed
in this case? We definitely need to discuss this further.

Please state your suggestions and comments, and sorry for the long mail.

[1] https://pagure.io/freeipa/issue/6799 
[2] https://github.com/freeipa/freeipa/pull/640
[3] https://github.com/freeipa/freeipa/blob/master/ipalib/install/kinit.py#L100
[4] https://paste.fedoraproject.org/paste/AcM6ymNxg~pipF~1ZIfbdF5M1UNdIGYhyRLivL9gydE=/

-- 
Martin Babinsky