On credential cache separation between service ticket and TGT

[Arpit Srivastava]

Thanks,

I realized that the problem was with renaming the krb5cc file. For testing,
I was renaming the krb5cc file that contained only the service tickets,
however, when I used the one without renaming it - it worked.

I have one more doubt:

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.

Best,
Arpit



On Tue, Mar 25, 2014 at 1:22 AM, Greg Hudson <ghudson at mit.edu> wrote:

> On 03/24/2014 02:23 PM, Arpit Srivastava wrote:
> > I followed the steps you described in your previous mail, however, what
> > I observed is that if TGT is not present in cache file -
> > gss_init_sec_context fails with min_status KRB5_CC_NOTFOUND.
>
> If I create a ccache with only a service ticket using kinit -S, I can
> successfully run ssh or the GSS sample application.  So there is no
> general restriction of this kind.
>
> > klist output:
> >
> > Service principal
> > krbtgt/EXAMPLE.COM at EXAMPLE.COM
> > HTTP/homepage.example.com@
> > HTTP/homepage.example.com at EXAMPLE.COM
> >
> > KerberosApp.trace:
> >
> > [12780] 1395683631.292486: Retrieving user at EXAMPLE.COM -> HTTP\/
> > homepage.example.com/example.com@ from
> > FILE:/etc/local/kerberos/ccache/krb5cc with result: 0/Unknown code 0
> > [12780] 1395683631.294109: Creating authenticator for user at EXAMPLE.COM ->
> > HTTP\/homepage.example.com/example.com@, seqnum 1032037665, subkey
> > aes256-cts/2942, session key aes256-cts/904D
>
> That doesn't look right at all.
> "HTTP\/homepage.example.com/example.com@" is not the same as
> "HTTP/homepage.example.com" and does not appear as the service entry in
> the ccache.  I don't see how this lookup could succeed.  That principal
> name looks like the result of misusing gss_import_name by specifying
> GSS_C_NT_HOSTBASED and the string form of a Kerberos principal instead
> of a host-based name ("service at host").
>
> Since I don't understand why the lookup is succeeding in the successful
> case, I also have no idea why the lookup is failing in the failure case.
>
> > Could it be because session keys not being there in krb5cc file (I think
> > authenticator is generated using session keys) ?
>
> Each entry in the ccache contains a ticket session key; a TGT is not
> special this regard.
>