Suppose I want to send a command to a print server on a netwerk that has been se

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

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse S
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.