Conceptual difference between kerberos service ticket and token?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Conceptual difference between kerberos service ticket and token?

Rohan Suri
Hi krbdev,

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?

The question might be of less value, but I'm a purist and hence need this
understanding

Thank you
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Conceptual difference between kerberos service ticket and token?

Greg Hudson
This question would be better suited to [hidden email] 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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev