Conceptual difference between kerberos service ticket and token?

Greg Hudson

2017-10-01 14:42:43 UTC

This question would be better suited to ***@mit.edu as it is not
about MIT krb5 development, but I will answer it here.

Post by Rohan Suri
Upon having a TGT, we request a *service ticket* from KDC - providing the
ServicePrincipalName of the target service.
Now at places (esp in context of GSSAPI), it only uses the term token -
when establishing context.
Is this token equivalent to service ticket in all aspects? Is there a
difference?

There is a difference:

* A Kerberos ticket is specific to Kerberos. A GSSAPI context
establishment token could use any GSS mechanism.

* A Kerberos ticket is mostly encrypted in the long-term service key.
(I say "mostly" because there is also a server principal name in plain
text.) It is not a bearer token; to use it you also have to know the
associated ticket session key. The combination of ticket and session
key is called a "credential".

* A GSSAPI context establishment token for the Kerberos mechanism, from
the initiator to the acceptor, contains a ticket and an authenticator.
The authenticator is encrypted in the ticket session key, and contains a
timestamp demonstrating that the holder if the session key wanted to
authenticate at the current time. It also usually contains a
sub-session key, some negotiation flags, possibly delegated credentials,
and possibly channel bindings to ensure that the authenticator can't be
used in a different channel.

* There is also (at least sometimes) a GSSAPI context establishment
token from the acceptor to the initiator, containing the same timestamp
and another sub-sesion key, for mutual authentication.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev