[krbdev.mit.edu #8625] Caching Forwarded TGTs

[Todd Lubin via RT]

On Thu, Dec 7, 2017 at 11:24 AM, Greg Hudson via RT <
rt-comment at krbdev.mit.edu> wrote:

> [tlubin at janestreet.com - Wed Dec  6 17:17:52 2017]:
> > What are your thoughts on doing this only if addresses
> > are used in tickets?
>
> I'm not sure that fully resolves the concern; multiple parties with
> different privilege levels might be using the same IP address.
>
​
I suppose then it should be up to the application itself to handle cache
the forwarded tickets (e.g. the browser scenario you listed below).
​

>
> I would also question whether it is worth the code complexity at that
> point, since it's vanishingly uncommon to use addresses in tickets
> these days.
>
> Taking a step back: if the forwarded tickets are used at least once
> on the receiving end, at least one TGS request will be made on the
> receiving host.  So under that condition, caching the forwarded
> tickets on the sending host saves at most 50% of TGS requests in this
> scenario--not nothing, but not as helpful as many scenarios where we
> cache service tickets.
>

​In most cases, your claim is right that the overhead of getting a new
forwarded TGT doesn't have much overhead. However, if service tickets are
cached on the remote system, then it might cut down on all TGS requests.

I am now realizing that patching krb5-libs a little roundabout to achieve
the behavior I'm looking for. It seems like SSH's GSSAPI code would be a
better target, where GSSAPIDelegateCredentials could have some smarter
behavior.



>
> I have heard of scenarios where a browser is configured to forward
> tickets when doing Negotiate auth, and since a browser typically
> makes many HTTP connections when loading a web page, failure to cache
> the forwarded tickets slows down page loads substantially.  But I
> suspect in these scenarios that the browser configuration is in
> error, and the forwarded tickets are never used on the receiving end.
>