Conceptual difference between kerberos service ticket and token?

[Greg Hudson]

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

On 10/01/2017 08:37 AM, Rohan Suri wrote:
> 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.