7

On the last step of Kerberos, the client sends the target server a ticket and an authenticator. One of the authenticator's parts is a timestamp. The timestamp is said to prevent replay attacks, as the server can verify a message is fresh, and that it has only been sent once (using a cache). This is all clear. What I don't get is the purpose of a replay attack in the first place. Sure, without the timestamp, the attacker can re-transmit legitimate authentication messages. But without having the session key, there's no way to further communicate with the server anyway, is there?

So, assuming replay attacks are possible, and an attacker can fool the server to think it is some legit user. How can the attacker operate within the created session, given it never got a hold of the session key?

  • I'm going to move this to security.se as I think it is more on topic there. Feel free to register an account on security.se and your responses/reputation will appear as normal! –  Dec 27 '11 at 20:24
  • I believe that is the point, a multi layered (system) approach to mitigating issues such as replay attacks. – notmyname Jan 16 '12 at 19:09

2 Answers2

2

You might want to read this PDF, which gives an example of such replay attack. In effect, it's not so much a replay attack as it is a man-in-the-middle attack. That said, part of the reason for having the timestamp and cache is to make it harder for an attacker to perform such a replay attack, and instead they must actually perform a MITM, which is harder. They actively have to block the request to be able to use the authenticator.

As far as the session key, as far as I understand it, and I might be wrong, it's not actually required once you get the token allowing you access to the resource. Again, I'm not sure so better read about it in more detail.

Yoav Aner
  • 5,299
  • 3
  • 24
  • 37
0

I think I understood where you question is coming from. I had the same question today.

You were probably considering using the session key -- shared between the client and the server -- to provide confidentiality and integrity for further communication between the parties. And the replay attack is indeed useless in this respect: without the session key the attacker can not compromise either.

But imagine a use-case, where duping the server into authenticating an attacker by replaying a message containing a ticket (and authenticator) opens up a plaintext communication channel. This is when replay attacks should be prevented!

There is another issue with the replay attacks: they can be used as a mechanism for mounting denial-of-service attacks, essentially forcing the server to decrypt the ticket and the authenticator over and over. It is significant when dealing with public key crypto, but I do not think it matters in this case, because symmetric encryption is not that expensive to cause denial-of-cpu.

portnoy
  • 81
  • 5
  • Can you please detail the second paragraph ? – coding_idiot Sep 23 '17 at 23:41
  • @coding_idiot A KRB_AP_REQ packet can be sniffed off the wire and presented by an adversary within an allowed time window. With no replay attack protection, this request will be validated. Now, everything depends on how your particular kerberized service is designed to work. Imagine a service, that upon validating an AP_REQ opens up a rule in some firewall, opening an access to the IP address belonging to the principal. On the other hand, if the service expects all further communication with the principal to be authenticated or encrypted using the session key, this attack becomes useless. – portnoy Sep 18 '18 at 04:44