Otway–Rees protocol


The Otway–Rees protocol is a computer network authentication protocol designed for use on insecure networks. It allows individuals communicating over such a network to prove their identity to each other while also preventing eavesdropping or replay attacks and allowing for the detection of modification.
The protocol can be specified as follows in security protocol notation, where Alice is authenticating herself to Bob using a server S :
Note: The above steps do not authenticate B to A.
This is one of the protocols analysed by Burrows, Abadi and Needham in the paper that introduced an early version of Burrows–Abadi–Needham logic.

Attacks on the protocol

There are a variety of attacks on this protocol currently published.

Interception attacks

These attacks leave the intruder with the session key and may exclude one of the parties from the conversation.
Boyd and Mao observe that the original description does not require that S check the plaintext A and B to be the same as the A and B in the two ciphertexts. This allows an intruder masquerading as B to intercept the first message, then send the second message to S constructing the second ciphertext using its own key and naming itself in the plaintext. The protocol ends with A sharing a session key with the intruder rather than B.
Gürgens and Peralta describe another attack which they name an arity attack. In this attack the intruder intercepts the second message and replies to B using the two ciphertexts from message 2 in message 3. In the absence of any check to prevent it, M becomes the session key between A and B and is known to the intruder.
Cole describes both the Gürgens and Peralta arity attack and another attack in his book Hackers Beware. In this the intruder intercepts the first message, removes the plaintext A,B and uses that as message 4 omitting messages 2 and 3. This leaves A communicating with the intruder using M as the session key.

Disruptive attacks

This attack allows the intruder to disrupt the communication but does not allow the intruder to gain access to it.
One problem with this protocol is that a malicious intruder can arrange for A and B to end up with different keys. Here is how: after A and B execute the first three messages, B has received the key. The intruder then intercepts the fourth message. He resends message 2, which results in S generating a new key, subsequently sent to B. The intruder intercepts this message too, but sends to A the part of it that B would have sent to A. So now A has finally received the expected fourth message, but with instead of.