Automatic FAST via Anonymous PKINIT

[Benjamin Kaduk]

On Thu, 29 May 2014, Greg Hudson wrote:

> 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

I re-read the original proposal, and also think it's a good idea.

The only thing that seems like it might require additional thought is the 
server policy side, where the logic could get a bit complicated depending 
on what preauth schemes are in play.  I don't think there's anything 
non-obvious, just that a KDC serving some clients which only do pkinit, 
some that only do OTP, etc., requires some logic to know what to offer in 
each case.

> 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.

Option 4 looks fairly appealing.  It's possible that option 1 would be 
reasonable, but I don't have a good feel for what the performance impact 
would be of needing to do a public-key operation for every such 
authentication.

-Ben