Otway-Rees protocol

The Otway-Rees protocol is a computer network authentication protocol designed for use on insecure networks (eg. the Internet). 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 (M is a session-identifier):

1. $A\; ightarrow\; B:\; M,A,B,\{N\_A,M,A,B\}\_\{K\_\{AS$

2. $B\; ightarrow\; S:\; M,A,B,\{N\_A,M,A,B\}\_\{K\_\{AS,\{M,A,B,N\_B\}\_\{K\_\{BS$

3. $S\; ightarrow\; B:\; M,\{N\_A,K\_\{AB\}\}\_\{K\_\{AS,\{N\_B,K\_\{AB\}\}\_\{K\_\{BS$

4. $B\; ightarrow\; A:\; M,\{N\_A,K\_\{AB\}\}\_\{K\_\{AS$

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 $K\_\{AB\}$. The intruder then intercepts the fourth message. S/he resends message 2, which results in S generating a new key $K\text{'}\_\{AB\}$, 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 $K\text{'}\_\{AB\}$ instead of $K\_\{AB\}$.

Another problem is that although the server tells B that A used a nonce, B doesn't know if this was a replay of an old message.

See also

* Kerberos
* Needham-Schroeder protocol
* Wide Mouth Frog protocol