Ticket History #8625: Caching Forwarded TGTs

# Wed Dec 06 13:10:10 2017 Todd Lubin <tlubin@janestreet.com> - Ticket created

From:	Todd Lubin <tlubin@janestreet.com>
Date:	Wed, 6 Dec 2017 09:30:22 -0500
Subject:	Caching Forwarded TGTs
To:	krb5-bugs@mit.edu

Download (untitled) / with headers
text/plain 462B

Download (untitled) / with headers
text/html 1.1KiB

When requesting a forwarded TGT, a client always talks to the KDC. [krb5_fwd_tgt_creds] always calls [krb5_get_cred_via_tkt].

When ssh is using GSSAPIDelegateCredentials=yes, this generates KDC traffic on every new ssh connection.

You could imagine caching forwarded TGTs to avoid this. If addresses are used, you could cache a forwarded TGT for each destination host.

Is there a particular reason that this is not done? If no, I can submit a patch for this.

# Wed Dec 06 14:49:06 2017 ghudson@mit.edu (Greg Hudson) - Correspondence added

Download (untitled) / with headers
text/plain 355B

I don't know if there was originally a reason not to cache forwarded
TGTs. One possible reason is that if you forward the same TGT to
multiple parties, they will be able to decrypt each others' TGS replies
and any AP sessions created using the resulting tickets. If you
forward a different TGT to each party, they cannot read each others'
sessions.

# Wed Dec 06 17:17:52 2017 Todd Lubin <tlubin@janestreet.com> - Comments added

From:	Todd Lubin <tlubin@janestreet.com>
Date:	Wed, 6 Dec 2017 17:16:18 -0500
Subject:	Re: [krbdev.mit.edu #8625] Caching Forwarded TGTs
To:	rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:

Download (untitled) / with headers
text/plain 760B

Download (untitled) / with headers
text/html 1.1KiB

That is a good point regarding forwarding the same TGT to different parties. As you suggested, this doesn't seem like a concern if addresses are used in tickets and there is care taken to forward TGTs that have matched addresses. What are your thoughts on doing this only if addresses are used in tickets?

On Wed, Dec 6, 2017 at 2:49 PM, Greg Hudson via RT <rt-comment@krbdev.mit.edu> wrote:

Show quoted text

I don't know if there was originally a reason not to cache forwarded
TGTs. One possible reason is that if you forward the same TGT to
multiple parties, they will be able to decrypt each others' TGS replies
and any AP sessions created using the resulting tickets. If you
forward a different TGT to each party, they cannot read each others'
sessions.

# Wed Dec 06 17:17:52 2017 Todd Lubin <tlubin@janestreet.com> - Correspondence added

From:	Todd Lubin <tlubin@janestreet.com>
Date:	Wed, 6 Dec 2017 17:16:18 -0500
Subject:	Re: [krbdev.mit.edu #8625] Caching Forwarded TGTs
To:	rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:

Download (untitled) / with headers
text/plain 760B

Download (untitled) / with headers
text/html 1.1KiB

That is a good point regarding forwarding the same TGT to different parties. As you suggested, this doesn't seem like a concern if addresses are used in tickets and there is care taken to forward TGTs that have matched addresses. What are your thoughts on doing this only if addresses are used in tickets?

On Wed, Dec 6, 2017 at 2:49 PM, Greg Hudson via RT <rt-comment@krbdev.mit.edu> wrote:

Show quoted text

I don't know if there was originally a reason not to cache forwarded
TGTs. One possible reason is that if you forward the same TGT to
multiple parties, they will be able to decrypt each others' TGS replies
and any AP sessions created using the resulting tickets. If you
forward a different TGT to each party, they cannot read each others'
sessions.

# Thu Dec 07 11:24:40 2017 ghudson@mit.edu (Greg Hudson) - Correspondence added

Download (untitled) / with headers
text/plain 1.1KiB

[tlubin@janestreet.com - Wed Dec 6 17:17:52 2017]:

Show quoted text

> 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.

# Thu Dec 07 11:45:02 2017 Todd Lubin <tlubin@janestreet.com> - Correspondence added

From:	Todd Lubin <tlubin@janestreet.com>
Date:	Thu, 7 Dec 2017 11:44:39 -0500
Subject:	Re: [krbdev.mit.edu #8625] Caching Forwarded TGTs
To:	rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:

Download (untitled) / with headers
text/plain 1.8KiB

Download (untitled) / with headers
text/html 3.1KiB

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

Show quoted text

[tlubin@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).

​

Show quoted text

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.

Show quoted text

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.

# Thu Dec 07 12:45:50 2017 Todd Lubin <tlubin@janestreet.com> - Comments added

From:	Todd Lubin <tlubin@janestreet.com>
Date:	Thu, 7 Dec 2017 11:44:39 -0500
Subject:	Re: [krbdev.mit.edu #8625] Caching Forwarded TGTs
To:	rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:

Download (untitled) / with headers
text/plain 1.8KiB

Download (untitled) / with headers
text/html 3.1KiB

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

Show quoted text

[tlubin@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).

​

Show quoted text

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.

Show quoted text

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.