Which keys exist in Kerberos, and who holds each of them?
Three long-term secret keys (the client's key derived from the password, the KDC's key known to AS and TGS, and one secret key per service) and two short-lived session keys (TGS session key between client and TGS, service session key between client and service).
| Key | Type | Who knows it | Used for |
|---|---|---|---|
| Client secret key | Long-term, usually derived from the user's password | User/client and the KDC (in its user database) | Encrypting the TGS session key in the AS reply |
| KDC master key | Long-term | Only AS and TGS (shared) | Encrypting the TGT |
| Service secret key | Long-term, one per service | That service and the KDC (service database) | Encrypting the service ticket |
| TGS session key | Short-lived | Client and TGS | Authenticator in the TGS request; the TGS reply |
| Service session key | Short-lived | Client and service | Authenticators between client and service; later traffic |
Everything is symmetric: every party initially shares exactly one long-term secret with the KDC, and the KDC uses those to deliver fresh session keys. Session keys are time-limited and become invalid after a set period.
Tip: In real implementations the "KDC master key" that protects TGTs is the long-term key of a special principal named krbtgt (the TGS's own account; in Active Directory, the krbtgt account). MIT Kerberos uses the term "master key" for something else: the key that encrypts the KDC database on disk.
Go deeper:
RFC 4120, Section 1.6: Environmental assumptions — why principals must keep their long-term keys secret and what a stolen key allows.- MIT Kerberos documentation: keytab — how services store their long-term secret key.