Automatic FAST via Anonymous PKINIT

[Nathaniel McCallum]

FAST is useful, especially for OTP. But FAST is also difficult to get
setup. In the FreeIPA community, we work around this problem by using
SSSD on the client-side and it establishes FAST automatically. However,
kinit doesn't work. Making this process not only smoother, but with a
similar behavior to what web-user expect is highly desirable. To this
end, I would like to propose a design for a zero-conf client FAST
channel. This breaks down into three distinct tasks: client behavior,
client trust and server policy.

=== CLIENT BEHAVIOR ===

The client should detect the following state:
1. Preauth is required.
2. FAST is offered.
3. No known preauth mechs are offered.

Currently, when this state exists, the client fails to authenticate. I
would like to propose that when this state exists, the client should
instead attempt to perform anonymous PKINIT and use the resulting ticket
to establish the FAST channel to find if new preauth mechs are
available.

=== CLIENT TRUST ===

Using other methods of establishing the FAST channel imply an already
established trust between the client and the server. In the case of
SSSD, for instance, the client has already been added to the FreeIPA
realm. This added level of trust is necessary because, unlike
non-preauth Kerberos, long term secrets are going over the wire. When
using Anonymous PKINIT, this trust takes the form of trusting a
certificate's CA chain. We have discussed four approaches with MIT.

1. Manual Configuration

The user will have to manually create a CA trust chain anchor.

This is the current behavior which does not fulfill our requirements for
requiring zero configuration. Regardless of what other option we pursue,
this method should be retained as a possibility.

2. Leap of Faith

The user would be prompted to trust the certificate.

This is a similar model to SSH. As Greg joked on the call today, this
isn't "web scale." There are obvious difficulties with:
A. how to prompt the user
B. which certificate in the chain to trust
B. how to handle when certificates change

This is particularly problematic because certificates change frequently
compared to ssh server keys and are not automatically generated.

3. Trusting Host Certificate Anchors

The user would accept the same CA trusted by his browser.

Fedora, for instance, now has a unified global certificate anchor
database with admin tools to manage it. This would most likely not be an
upstream MIT patch, but would be carried by distributions.

The problems with the browser CA trust model are well known (let's not
hash them out here). On top of this, forcing each platform to configure
this right will make the feature somewhat useless. This will, in turn,
cause admins not to deploy it.

4. DNSSEC (the preferred option)

The user would trust certificates offered by DNSSEC/DANE.

An implicit mapping already exists between the realm and a DNS name when
looking up SRV records. We could extend this mapping such that signed
TLSA records are used to identify the canonical certificate for the KDC
realm. The client then ensures that the certificate provided by the KDC
matches the certificate provided by DNSSEC.

If connecting directly to a KDC, the server name could be validated from
the certificate. However, forcing this behavior would make proxying the
packets (for instance, over HTTP) impossible to verify. For this reason,
I am advocating not forcing this validation.

=== SERVER POLICY ===

The server needs to take care to ensure that if some preauth mechs are
available over FAST only, that no non-FAST preauth mechs are offered.
For instance, if a user is configured for either OTP or PKINIT, because
PKINIT is offered outside of the FAST channel the client state for
automatic FAST will never be triggered. The end result is that the user
never knows that OTP is an option for authentication.

Hence, some kind of per-user preauth policy needs to be implemented on
the server. This policy should define which preauth mechs are available
for the user and whether they require the FAST channel or not. If any
preauth mech requires the FAST channel, the server should enforce that
all of them do as well.