Automatic FAST via Anonymous PKINIT

Nathaniel McCallum npmccallum at
Fri May 30 13:12:53 EDT 2014

On Fri, 2014-05-30 at 09:16 -0500, Nico Williams wrote:
> Greg's #1 works, just inefficiently.  It's a lot better than nothing
> and a no-brainer.  #2 doesn't help much.  #3 might be more useful than
> you think, but I'd store the FAST armor ticket (it's constrained,
> isn't it?) in the normal ccache, with a link to it from a ccconfig
> entry.  #4 is clearly desirable from a systems pov, though i would
> prefer an IPC protocol so as to be better able to apply least
> privilege principles.  Still, #4 looks very nice, so it gets my +1.

Thinking through this, I don't know that anything other than #1 is
really needed. Caching only provides a benefit when the ratio of
non-Anonymous ASReqs to Anonymous ASReqs is high. In the typical case of
kinit, this ratio is essentially 1:1, providing no benefit.

The only case I can think of where caching provides a significant
benefit is in the case of a login system. In this case, the ratio could
be very high. If the login system is a single, stateful process #2 might
make sense. But I can't think of a single login system that is
architected this way.

So my vote is #1 now and #4 at a later time.


More information about the krbdev mailing list