A typical Kerberos interaction involves three players, the application client, the application server, and the Kerberos server. The client gets tickets from the Kerberos server. Clients need a secret key, sometimes derived from the user's password, sometimes randomly generated for use in a particular session, in order to decode the ticket and make use of it. A client generates an authenticator derived from a ticket that it received from the Kerberos server. The client sends the authenticator to an application server.
Authenticators have protections schemes that prevent replay and tampering.
When an application server receives an authenticator from the client, the application server decodes the authenticator using the server's private key. This proof is obtained without user X ever having sent her password to the server. Only user X knows her password, but the Kerberos database has user X's private key that was generated from user X's password and is virtually equivalent to user X's password as far as security goes. Since the Kerberos server contains all the keys to the kingdom, it's kept in a really secure place. Tickets are stored in memory in the ticket cache.