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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

"Lavanya M Sirreddy" via RT
[[hidden email] - 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 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.

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.
_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Reply | Threaded
Open this post in threaded view
|

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

"Lavanya M Sirreddy" via RT
On Thu, Dec 7, 2017 at 11:24 AM, Greg Hudson via RT <
[hidden email]> wrote:

> [[hidden email] - 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.
>


_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Reply | Threaded
Open this post in threaded view
|

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

"Lavanya M Sirreddy" via RT
In reply to this post by "Lavanya M Sirreddy" via RT
On Thu, Dec 7, 2017 at 11:24 AM, Greg Hudson via RT <
[hidden email]> wrote:

> [[hidden email] - 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.
>


_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs