[krbdev.mit.edu #8619] ksu command doesn't use service ticket in cache file but always re-requests to TGS

[Fabiano Tarlao via RT]

Hi,
thank you for looking into this issue.
>From my point of view there are two main reasons to restore the documented
ksu behaviour:
1) to not perform useless requests to TGS/DC, to spare resources;
performing the TGS requests also raises the ksu execution latency..
2) from a security standpoint, to reduce the potential "attack surface";
this point is far more important to us, let me elaborate a bit:

A potential attacker may, in a limited time window, have the opportunity to
stole the cached krb tickets. One TGT permits the attacker to impersonate
the user for all resources/services in the domain; a service ticket (not
forwardable) limits the attacker to impersonate the user only on the
current host/service.

Taking this into account.. in order to use ksu.. we would like to populate
the Krb cachefile only with the end-server service ticket (the cachefile
should not contain a TGT).
At the moment we populate the cachefile in this way thanks to the kinit
command with the -S option.
kinit permits to request an "initial" service ticket (In the future we will
try to implement a way to populate a cache file with a service ticket
acquired thanks to a TGT--stored in a different safe place--).
Security is a key point of our work, the documented ksu behaviour looked
exactly what we need.
Regards
Fabiano


On 13 November 2017 at 23:21, Greg Hudson via RT <rt-comment at krbdev.mit.edu>
wrote:

> Thanks for the bug report, and apologies for not having time to look
> into this last week.
>
> It looks like ksu's behavior changed in release 1.13 as a result of
> this pull request:
>
> https://github.com/krb5/krb5/pull/170
>
> although it may have been partially broken since referrals support
> was introduced in release 1.6.  Pull request 170 was motivated by a
> bug caused by the referrals changes.  At that time, we didn't realize
> that the fix we arrived at (simplifying the ksu code) created a
> mismatch with the documented behavior.
>
> I can see several possible remedies here:
>
> 1. Change the documentation to match the code (talk only about using
> a cached TGT).
>
> 2. Restore the documented behavior, but only make it work if the
> canonicalized local hostname matches the host principal in the ccache
> service ticket and the system keytab.
>
> 3. Restore the documented behavior, and make it work for any host
> principal in the system keytab.
>
> The serverfault post contains a lot of detail about the test case,
> but doesn't explain why the documented behavior is important in this
> use case.  Is there a reason why it's not sufficient for ksu to look
> for a TGT in the ccache and make a TGS request to verify it?
>