= Solution
Alice can still authenticate Bob when she accepts a genuine fresh ticket and successfully checks $E_{k_{AB}}(\text{Hello Alice})$. The <session key> inside her ticket is Tim's genuine key, protected by her <public key> together with $\mathit{secret}_A$. Tim gives that same key only to Alice and to the holder of Bob's <private key>. The adversary cannot derive it, and honest Tim does not send the greeting. Alice has not sent that greeting either. Thus the matching greeting is evidence that Bob obtained the key and participated. The different final greetings prevent simply reflecting Alice's own confirmation back at her.
Bob's intended freshness test is that $\mathit{nonce}_B$ was hidden in his request encrypted for Tim, so a matching answer must follow Tim's processing of that request. This establishes that Tim revealed that <cryptographic nonce>; it does not authenticate the adjacent ticket. The substitution attack in <2/b/i/solution> may use an old adversary-known $z$ instead of a fresh one. Bob accepts it even though its freshness is false.
$$
\boxed{\text{Alice's check can authenticate Bob; Bob's accepted key need not be fresh.}}
$$
The defect is the absence of a cryptographic binding between Bob's <cryptographic nonce> and his key ticket. A repair must bind the identities, both <cryptographic nonces> and the <session key> under <message authentication> verifiable as Tim's, for example a <digital signature> by Tim over the response, checked before Bob accepts. Merely moving the nonce inside a public-key-encrypted ticket is insufficient once an attacker knows or predicts it: anyone can create such an <encryption>.
Back to article page
