Suppose I want to send a command to a print server on a netwerk that has been secured with Kerberos. To do so, I authenticate myself to the KDC and get a TGT, and then another ticket from the TGS for the print server. I then authenticate myself to the print server and I can then send it a print command, signed with the session key. But suppose someone is listening on the network and sniffs the command I sent it, what prevents him from replaying it to the print server and thus being able to print the same file I just printed during the same session (so same session key)? A solution would be to get a new ticket (and thus new session key) from the TGS for every command you send to the print server but I don’t think this is required in the Kerberos protocol?

  • Did you do any research on your own? A Google search with your title returned many high-quality answers.
    – schroeder
    Mar 2, 2015 at 18:16

1 Answer 1


This is stopped by authenticators. Whenever you present a Kerberos ticket, it must be accompanied by an authenticator, which is encrypted using the session key and contains (among other info) a timestamp. The server checks that the timestamp is recent (in Kerberos 4, this means "within 5 minutes;" in 5, it is configurable, but 5 minutes is the default) and that it has never seen that authenticator before. The authenticator just relies on the session key, so can be generated by the client; a new authenticator is created every time you send a ticket.

To answer "what if they're using the same session," the basic Kerberos protocol doesn't handle it. Kerberos, at its core, authenticates the user opening a connection; it does not have to do anything more. Application protocols are responsible for handling protection of further messages if that's important; Kerberos provides two ways to do so, or can supply data from the authentication to whatever system the application protocol uses, but an application protocol need not use Kerberos at all other than for initial authentication. Everything after that depends on the application protocol.

Kerberos has two options for Kerberos-protected communication beyond the initial message (one authenticates, one encrypts and authenticates); an application protocol may use them to protect later communication, but does not have to. Both of these use a timestamp and/or a sequence number to prevent replays; the sequence number protects against dropped messages and message reordering, while the timestamp is forgiving if that's not a concern (but prevents an attacker from just delaying a message, as a delayed message will be rejected), but both prevent replays.

If you are concerned about a malicious user tampering with the data stream to the print server, you can define the print server protocol to use KRB_SAFE or KRB_PRIV (respectively, "authenticate only" or "encrypt and authenticate"); both protect against replays. Or you can use some other system that takes a sub-session key from the authenticator as a pre-shared key and has replay protection; a TLS-PSK protocol with the sub-session key as PSK would probably work (TLS protects against replay attacks). The point is, Kerberos does not inherently protect against that sort of replay, because it says nothing about how to do the rest of the communication; to protect against attacks on the communication post-authentication, you need to either use Kerberos's KRB_SAFE or KRB_PRIV or use something else that protects that communication.

  • Yes, but suppose the client has already authenticated itself (with the ticket and authenticator) to the server. He then wants to send a command to the print server, e.g.: “print file test.txt” and signs this with the session key that both client and server share. The server checks the signature, sees it’s ok and prints the file. If now someone were to sniff this message (the signed version of “print file test.txt”), he could then replay this message during the same session (because the session key hasn’t changed) and have the file printed again.
    – Nimyz
    Mar 2, 2015 at 19:23
  • @cpast "what if they're using the same session," - is it possible to share a TGS session between two different servers? In some microservices contexts where there are applications that use Kerberos and only Kerberos (like Hadoop), and others that don't, all within a firewall, it would be very useful to create service tickets at a gateway, store them in a distributed session and allow other services to use them later when talking to Kerberised Hadoop services. Authenticators prevent it, but shared TGS sessions might be a solution. This is basically benign ticket theft within a firewall. Nov 11, 2016 at 21:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .