On credential cache separation between service ticket and TGT

[Greg Hudson]

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.