Kerberos replay attack

Question

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?

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.