What is an authenticator in Kerberos, and why does the client send one along with every ticket?

An authenticator is a small message with the user ID and a current timestamp, encrypted with the session key from the ticket; it proves that the presenter actually holds the session key (not just a copied ticket) and that the request is fresh, which stops replays.

A ticket alone is not proof of identity: it is just an encrypted blob that someone could have captured on the network. The authenticator closes that gap:

1. The client builds {user ID, timestamp} and encrypts it with the session key it received alongside the ticket (TGS session key for the TGS, service session key for a service).
2. The receiver decrypts the ticket with its own long-term key, takes the session key out of it, and decrypts the authenticator.
3. It checks that the user ID in the authenticator equals the one in the ticket and that the timestamp is within the allowed clock skew (typically 5 minutes).
4. It remembers recently seen authenticators in a replay cache and rejects duplicates.

Only someone who could read the reply that delivered the session key can build a valid authenticator, and a captured authenticator expires within minutes. This is the improvement over Needham-Schroeder's replayable message 3.

Go deeper:

• RFC 4120, Section 5.5.1: KRB_AP_REQ definition — the authenticator fields (client name, timestamp, optional subkey).
• RFC 4120, Section 3.2.3: Receipt of KRB_AP_REQ — the checks a server makes, including the replay cache.