Return to Answer

For one-way authentication (where Bob is the server and Alice the client), I would rather do something like this:

Alice —> Open Connection —> Bob
Alice <— $R$ <— Bob
Alice —> $K_{A-B} (R)$ —> Bob

By using a “once-in-a-lifetime” value $R$, and then checking the returned value, $K_{A-B} (R)$, Bob can be sure that both Alice is who she says she is (since she knows the secret key value needed to encrypt $R$) and is "live" (since she has encrypted the nonce, $R$, that Bob just created).

Now…

Your description looks pretty similar but it notes a $Cert_b$ which I interpret to be a certificate. A certificate does not represent a “once-in-a-lifetime” value. In your case, Bob would not be sure if Alice is "live" because the certificate data could have been collected/intercepted at an earlier time… potentially by Eve instead of Alice. As a result, authentication would fail secure verification in your protocol description. In the end, you're facing the possibility of crashing into a replay attack by Eve when doing it your way.

For one-way authentication (where Bob is the server and Alice the client), I would rather do something like this:

Alice → Open Connection → Bob
Alice ← $R$ ← Bob
Alice → $K_{A-B} (R)$ → Bob

By using a “once-in-a-lifetime” value $R$, and then checking the returned value, $K_{A-B} (R)$, Bob can be sure that both Alice is who she says she is (since she knows the secret key value needed to encrypt $R$) and is "live" (since she has encrypted the nonce, $R$, that Bob just created).

Now…

Your description looks pretty similar but it notes a $Cert_b$ which I interpret to be a certificate. A certificate does not represent a “once-in-a-lifetime” value. In your case, Bob would not be sure if Alice is "live" because the certificate data could have been collected/intercepted at an earlier time… potentially by Eve instead of Alice. As a result, authentication would fail secure verification in your protocol description. In the end, you're facing the possibility of crashing into a replay attack by Eve when doing it your way.

For one-way authentication (where Bob is the server and Alice the client), I would rather do something like this:

Alice —> Open Connection —> Bob
Alice <— $R$ <— Bob
Alice —> $K_{A-B} (R)$ —> Bob

By using a “once-in-a-lifetime” value $R$, and then checking the returned value, $K_{A-B} (R)$, Bob can be sure that both Alice is who she says she is (since she knows the secret key value needed to encrypt $R$) and is "live" (since she has encrypted the nonce, $R$, that Bob just created).

Now…

Your description notes a $Cert_b$ which I interpret to be a certificate. A certificate does not represent a “once-in-a-lifetime” value. In your case, Bob would not be sure if Alice is "live" because the certificate data could have been collected at an earlier time… potentially by Eve instead of Alice. As a result, authentication would fail secure verification.

For one-way authentication (where Bob is the server and Alice the client), I would rather do something like this:

Alice —> Open Connection —> Bob
Alice <— $R$ <— Bob
Alice —> $K_{A-B} (R)$ —> Bob

By using a “once-in-a-lifetime” value $R$, and then checking the returned value, $K_{A-B} (R)$, Bob can be sure that both Alice is who she says she is (since she knows the secret key value needed to encrypt $R$) and is "live" (since she has encrypted the nonce, $R$, that Bob just created).

Now…

Your description looks pretty similar but it notes a $Cert_b$ which I interpret to be a certificate. A certificate does not represent a “once-in-a-lifetime” value. In your case, Bob would not be sure if Alice is "live" because the certificate data could have been collected/intercepted at an earlier time… potentially by Eve instead of Alice. As a result, authentication would fail secure verification in your protocol description. In the end, you're facing the possibility of crashing into a replay attack by Eve when doing it your way.

For one-way authentication (where Bob is the server and Alice the client), I would rather do something like this:

Alice —> Open Connection —> Bob
Alice <— $R$ <— Bob
Alice —> $K_{A-B} (R)$ —> Bob

By using the once-in-a-lifetime value $R$, and then checking the returned value, $K_{A-B} (R)$, Bob can be sure that both Alice is who she says she is (since she knows the secret key value needed to encrypt $R$) and is "live" (since she has encrypted the nonce, $R$, that Bob just created).

For one-way authentication (where Bob is the server and Alice the client), I would rather do something like this:

Alice —> Open Connection —> Bob
Alice <— $R$ <— Bob
Alice —> $K_{A-B} (R)$ —> Bob

By using a “once-in-a-lifetime” value $R$, and then checking the returned value, $K_{A-B} (R)$, Bob can be sure that both Alice is who she says she is (since she knows the secret key value needed to encrypt $R$) and is "live" (since she has encrypted the nonce, $R$, that Bob just created).

Now…

Your description notes a $Cert_b$ which I interpret to be a certificate. A certificate does not represent a “once-in-a-lifetime” value. In your case, Bob would not be sure if Alice is "live" because the certificate data could have been collected at an earlier time… potentially by Eve instead of Alice. As a result, authentication would fail secure verification.