Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
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! –  user2213 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
add comment

migrated from crypto.stackexchange.com Dec 27 '11 at 20:24

This question came from our site for software developers, mathematicians and others interested in cryptography.

2 Answers

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.

share|improve this answer
    
Link Rot. Link is expired. –  Alastor Moody Mar 18 at 18:08
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.