# Why doesn't this dummy mutual authentication protocol provide mutual authentication?

I am a student taking a cryptography course so forgive me if this comes off as a silly question.
This is an assignment question:

$Alice \rightarrow R \rightarrow Bob$
$Alice \leftarrow [R]B \leftarrow Bob$
$Alice \rightarrow [R+1]A \rightarrow Bob$

Why doesn't this protocol provide mutual authentication?

Here's a plausible scenario:

Alice sends $R$. Trudy intercepts it and sends it to Bob impersonating Alice. Bob sends back $R$ signed by him to Trudy. Trudy now impersonates Bob and sends $R$ with Bob's signature to Alice impersonating Bob. Alice sends $[R+1]$ signed by Alice which Trudy can now use to impersonate as Alice to Bob.

If that is a valid attack. Wouldn't this work with every protocol? After all we're merely just relaying message back and forth among the two parties.

• Is [R]B the encryption of R using the key B? – CodesInChaos Dec 3 '13 at 18:44
• That is R signed by Bob. [R]_B – Ajit Dec 3 '13 at 18:47
• You can't simply "authenticate". You need to authenticate something. For example a specific message or connection. Else Eve who receives an incoming connection from Alice might simply open a connection to Bob, ask him for [R]B, send that back to Alice, obtaining [R+1]A and send that to Bob. At that point she has authenticated as Alice to Bob and as Bob to Alice. – CodesInChaos Dec 3 '13 at 18:47
• Another problem is that Bob who received a (R, [R+1]A) pair from Alice, can use that pair to impersonate Alice to any third party. – CodesInChaos Dec 3 '13 at 18:52
• What you sketch cannot reasonably be interpreted as an attack because authentication schemes have very limited scope. But suppose Alice thinks she is authenticating to Trudy, not Bob. Can Trudy make Bob believe Alice authenticated to him? – K.G. Dec 4 '13 at 9:26