Automatic FAST via Anonymous PKINIT

[Greg Hudson]

On 05/20/2014 02:59 PM, Nathaniel McCallum wrote:
> The client should detect the following state: [...]
> 
> 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.

I think this is a good idea, but we need to consider how to cache the
resulting anonymous armor ticket.  We don't want the same armor ticket
used by multiple uids, but multiple AS requests made by the same uid
will be substantially more efficient if they can reuse the armor ticket
from a previous request.  Options include:

1. Don't cache it; get a new anonymous credential each time we run into
this situation.

2. Cache it in a MEMORY ccache with a fixed name.

3. If the default ccache is collection-enabled, add the ticket to the
collection using the anonymous name.  This might be a bad idea; we don't
necessarily want WELLKNOWN/ANONYMOUS to become one of the identities to
consider authenticating with.

4. Introduce the concept of the default fast ccache with discovery
options paralleling the regular default ccache ($KRB5FASTCCNAME,
[libdefaults]->default_fast_ccache_name, a hardcoded default like
/tmp/krb5fastcc_%{uid} overridable at build time).  This could also be
used by pam_krb5 to provide an armor ticket from the keytab for use by
AS requests, on systems with keytabs.

Option 4 has the biggest footprint, but is my current preference.  If
the default fast ccache doesn't exist or can't be used, we can fall back
to option 2.