How is MitM attack prevented when complete session is hijacked?

Question

Lets say there is mutual authentication between a client which connects to a server on an otherwise unsecured TCP channel. Both parties create a random challenge and the other side answers with a keyd-hash, based on a pre-shared symmetric key.

$$C\rightarrow open \,\, connection \rightarrow S$$ $$C\rightarrow challenge_C \rightarrow S$$ $$C\leftarrow challenge_S \leftarrow S$$

$$C\rightarrow H_K(challenge_S) \rightarrow S$$ $$C\leftarrow H_K(challenge_C) \leftarrow S$$

$$C \leftarrow authenticated \rightarrow S$$

However, an adversary "man-in-the-middle" could listen on the network by whatever means. Whenever a client C is going to establish a TCP connection to the server, MitM could at the same moment establish another adversary client session C' and inject all communication he listens between C and S into the session between C' and S, so C' gets authenticated against S.

It seems too simple - so where is my mistake?

Answer 1

It's not really that C or C` gets authenticated such that from then on S can trust data appearing to originate from C or C' in a general sense. If that were true, S would trust any plaintext unauthenticated information that appeared to be sent from C to S. That would clearly be liable to a man-in-the-middle attack, that just waited for the initial challenge-response steps to complete prior to then meddling with the information being communicated.

What's really happening in a secure protocol is that C and S mutually authenticate as part of a process to establish a symmetric session key that they then both use to communicate using authenticated symmetric encryption. This is what proves they are genuinely still talking to one another, and not a man-in-the-middle attacker.

If you don't care about having a per-session symmetric key so that there is forward secrecy, and if both sides maintain a long-term counter (to prevent replay attacks), then if you have a pre-shared symmetric key you could just jump directly to communicating via authenticated encryption (which uses and increments the counter with each message sent) without the need for the challenge-response steps you've outlined in your question.