[18787] in Kerberos_V5_Development
Re: Automatic FAST via Anonymous PKINIT
daemon@ATHENA.MIT.EDU (Benjamin Kaduk)
Fri May 30 13:17:05 2014
Date: Fri, 30 May 2014 13:16:51 -0400 (EDT)
From: Benjamin Kaduk <kaduk@mit.edu>
To: Nathaniel McCallum <npmccallum@redhat.com>
In-Reply-To: <5387815B.9040504@mit.edu>
Message-ID: <alpine.GSO.1.10.1405301313060.25244@multics.mit.edu>
MIME-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
