1. What does "stateless" mean in the context of Kerberos authentication?
The KDC keeps a running record of who is currently authenticated, refreshed on a regular interval The KDC never keeps a running record of who is currently authenticated; each ticket is self-contained proof validated the moment it is presented The KDC does not use encryption when issuing tickets Stateless means tickets never expire once issued 2. How does a Ticket Granting Ticket (TGT) differ from a service ticket in scope?
A TGT grants direct access to any resource on the domain, making service tickets redundant A TGT proves the user already authenticated to the domain and is used to request more specific tickets; a service ticket is scoped to one specific service and requires a valid TGT to obtain A TGT and a service ticket are functionally identical, just two names for the same credential A service ticket is broader in scope than a TGT, since it can be used to request additional TGTs 3. Why doesn't a user's password cross the network during Kerberos authentication?
The KDC caches the password from a previous logon, so it never needs to be sent again The user proves possession of a password-derived key by producing something only that key could generate, rather than transmitting the password itself The password is sent in encrypted form, protected by the KDC's key, instead of in plaintext A TGT substitutes for the password on every new logon, so no password is ever needed at all 4. A colleague says Kerberos maintains a persistent, VPN-like connection between a client and the KDC once a user logs in. What is the flaw in that claim?
There is no flaw; that description is roughly accurate Every ticket request is a discrete, one-shot exchange; nothing stays connected the way a VPN or SSH session does Kerberos does maintain a connection, but only for the duration of the TGT's lifetime, then it drops Kerberos maintains a connection, but only between domain controllers, never between a client and the KDC 5. Why does clock accuracy matter so much for Kerberos, given that passwords never cross the network?
Tickets rely on timestamps rather than session state to prove they are current and to prevent replay, so too much clock drift causes authentication to fail The client's clock is used to derive the encryption key that protects each ticket Clock accuracy only affects logging and auditing, not whether authentication succeeds Domain controllers use clock time to decide which one of them issues the next ticket 6. A junior analyst assumes a fresh TGT gets requested for every single action a user takes throughout the day. What is wrong with that assumption?
Nothing; requesting a new TGT per action is exactly how Kerberos is designed to work A TGT is deliberately reusable for its lifetime so the user isn't re-prompted constantly, which is exactly why a stolen TGT is so valuable TGTs are actually requested once per day at a fixed time, regardless of user activity A new TGT is issued for every service ticket request, one for one 7. In the claim-check mental model, why doesn't the KDC need to recognize a user's face or recall serving them minutes earlier?
Because the ticket itself carries a stamp that cannot be forged without the KDC's key, so a valid ticket presented is proof enough on its own Because the KDC keeps a photo record of every authenticated user for quick recognition Because service tickets never actually need to be checked once issued Because a TGT permanently identifies a device rather than a user 
