Conceptual difference between kerberos service ticket and token?
ghudson at mit.edu
Sun Oct 1 10:42:43 EDT 2017
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
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.
More information about the krbdev