[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,
just for the sake of curiosity,
have you taken any decision between changing the code to adhere
documentation or changing the documentation?
Regards

I repeat also the previous mail (cause the bug tracker system had problems
days ago):

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 14 November 2017 at 00:31, Fabiano Tarlao <ftarlao at gmail.com> wrote:

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