The authentication ticket is shipped along with client request to the server in its encrypted form. Upon receipt of an encrypted message, the server decrypts the ticket. Inside, it finds the session key, which it can use to decrypt the message, and also authentication information put there by the authentication server verifying that the ticket is actually valid for a session with the particular client. Timestamps are also contained in the ticket to limit the time during which the session key will be considered valid. This is advantageous, since conventional encryption is typically much faster than public key encryption, which is necessary if an authentication server is not used to generate verifiable session keys.
Extensions exist to support hierarchical authentication servers across domain.
Basically what happens is that if an authentication server does not know the secret key of a server for which a ticket has been requested, it communicates via the same algorithm with a higher level authentication server in much the same way that name servers do. Eventually, the collection of authentication servers produce a session key and ticket, which are then used in the session as if they were obtained from a single, global authentication server. Thus, the algorithm scales well and matches to name server domains nicely. For a list of such software, see Kerberos Resources . Of course, all parties to a session must be Kerberos aware, else they cannot interpret the encrypted messages.