[18788] in Kerberos_V5_Development
Re: Automatic FAST via Anonymous PKINIT
daemon@ATHENA.MIT.EDU (Benjamin Kaduk)
Fri May 30 14:42:51 2014
Date: Fri, 30 May 2014 14:42:39 -0400 (EDT)
From: Benjamin Kaduk <kaduk@mit.edu>
To: Nathaniel McCallum <npmccallum@redhat.com>
In-Reply-To: <1401469973.3521.19.camel@ipa.example.com>
Message-ID: <alpine.GSO.1.10.1405301440540.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 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.
-Ben
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
