On to, 23 maalis 2017, Martin Babinsky wrote:
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
* 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.
Thanks, Martin, for the thorough analysis.

I need to clarify *why* we need working Anonymous PKINIT. There are two
separate needs here:

- Enable clients with no access to a separate key to be usable for 2FA
  accounts. This can be best explained as to support Kerberos auth from
  non-enrolled machines or machines where no SSSD is in use. In such
  cases we cannot use another credentials to create FAST channel and
  pass 2FA creds with kinit.

- Enable IPA framework to perform password-based login for 2FA. With
  privilege separation we don't have access to HTTP/... principal's
  keytab anymore (gssproxy does) and neither GSSAPI nor gssproxy
  support FAST channel wrapping for explicitly specified password+2FA

For DL0 we do not officially support PKINIT, so first case is not
relevant. However, second case is what we need even on DL0 because
otherwise IPA framework does not work, as you have witnessed.

We thought that we could solve this problem by re-using anonymous
principal as 'normal' principal -- by fetching its keytab and
authenticating with the keys from it. But for anonymous principal MIT
Kerberos library does verification of the session key and requires it to
be provided with PKINIT PA DATA when there is no wrapping principal

See RFC 6112 section 4.1: https://tools.ietf.org/html/rfc6112#section-4.1

  The Kerberos client can use the client's long-term keys, the client's
  X.509 certificates [RFC4556], or any other pre-authentication data,
  to authenticate to the KDC and requests an anonymous ticket in an AS
  exchange where the client's identity is known to the KDC.

  If the client in the AS request is anonymous, the anonymous KDC
  option MUST be set in the request.  Otherwise, the KDC MUST return a
  KRB-ERROR message with the code KDC_ERR_BADOPTION.

Corresponding code in MIT Kerberos is this: https://github.com/krb5/krb5/blob/master/src/lib/krb5/krb/get_in_tkt.c#L157

So, using keytab for anonymous principal does not work. We either can
have another principal to perform wrapping or actually fix PKINIT for
DL0 for the purpose of IPA framework.

The latter is easy to achieve. Certmonger maintains two local CAs:
SelfSign and 'local':

# getcert list-cas
CA 'SelfSign':
        is-default: no
        ca-type: INTERNAL:SELF
        next-serial-number: 01
CA 'local':
        is-default: no
        ca-type: EXTERNAL
        helper-location: /usr/libexec/certmonger/local-submit

The first one self-signs whatever request you provide, the second one
signs it with a locally generated CA which is unique to each host. The
latter one doesn't perform any checks and simply signs the request.

Obviously, relying on certmonger's local CA to provide PKINIT to other
IPA clients does not scale. But we already estblished we wouldn't do
that. In IPA framework which runs on the very same host as KDC, we can
have access to the same public key KDC would be using for itself and can
kinit with it as an anchor:

 kinit -X x509_anchor=/path/to/local-ca.crt -n

This approach allows us to avoid any modification to /etc/krb5.conf on
IPA master. An IPA framework would only need to have access to the
public key of local CA. And local CA is something certmonger provides
since its first run.

Yes, we'll need to manage upgrades from DL0 to DL1 for PKINIT. In
practice this will mean we have to:

- replace local CA-issued KDC certificate if we were upgraded to become
  IPA-managed CA

- replace local CA-issued KDC certificate with externally provided KDC
  certificate if we were upgraded and provided with explicit certificates

This is certainly doable and primary benefit is that we wouldn't need to
have any fallbacks anymore. We would always use Anonymous PKINIT within
the IPA framework and be done with it.

/ Alexander Bokovoy

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to