Automatic FAST via Anonymous PKINIT

[Nathaniel McCallum]

On Fri, 2014-05-30 at 14:42 -0400, Benjamin Kaduk wrote:
> On Fri, 30 May 2014, Nathaniel McCallum wrote:
> 
> > 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.
> 
> I think that getting to a state where FAST is used for all traffic to the 
> KDC (which is not being used to obtain an armor ticket) is a very useful 
> state to be in, and #4 provides a lot of infrastructure that would make 
> that state more achievable, whether the armor is obtained via anonymous 
> PKINIT or otherwise.
> 
> So I don't think we should give up on #4 quite yet.

Even if we use FAST to encrypt all traffic, the temporary anonymous
ticket will only be used for ASReq requests. #4 provides no benefit to
"FAST all the time" apart from ASReqs. The only case where it does make
sense is in a login system. And the login system should (generally) be a
Kerberos service in its own right. This is precisely how SSSD works. No
anonymous ticket is needed because the service has its own ticket which
is managed in the SSSD ticket ccache.

Nathaniel