On credential cache separation between service ticket and TGT

[Arpit Srivastava]

Ok, consider following usecase which I am employing Negotiate tokens.

- a service ticket obtained by calling gss_init_sec_context for a lifetime
less than that of TGT.
- Now, service ticket expires but TGT is still valid.
- gss_init_sec_context called again and a new service ticket acquired.

Now here, the krb5cc cache would keep on accumulating service tickets of
same name but different validity time stamps.
Isn't that superfluous ?

- Is there any way to renew service tickets the way TGT is renewed (atleast
till the validity of TGT) using GSS/Krb APIs.
- Is there any way to discard expired tickets from credentials because
anyways they are unusable using GSS/Krb APIs.

Arpit



On Tue, Mar 25, 2014 at 9:26 PM, Greg Hudson <ghudson at mit.edu> wrote:

> On 03/25/2014 11:19 AM, Arpit Srivastava wrote:
> > I call gss_init_sec_context with say, /time_req = 20 mins. /Every time
> > the service ticket hence obtained expires, a new service ticket is
> > obtained with 20 mins validity, instead of renewing the one already
> > existing in the cache (so, there are two tickets of same SPN but with
> > different validity time stamps). I observed that if I pass time_req =
> > GSS_C_INDEFINITE, the same ticket is renewed and a new ticket is not
> > created. It would be great if you can provide some insights.
>
> To the best of my knowledge, gss_init_sec_context has no support for
> renewing service tickets, only getting new ones using a TGT.
>
>