# What does this Authentication protocol achieve and what information is shared?

I'm having trouble with the following question from my class:

"What is the purpose of the protocol, and how does it achieve this purpose and what shared information does A and B end up after running an instance of this protocol?

1. $\sf A \to B: \quad A, N_A$
2. $\sf B \to S: \quad B, \{A, N_A, T_B\} K_{BS}, N_B$
3. $\sf S \to A: \quad \{B, N_A, K_{AB}, T_B\} K_{AS}, \{A, K_{AB}, T_B\} K_{BS}, N_B$
4. $\sf A \to B: \quad \{A, K_{AB}, T_B\} K_{BS}, \{N_B\} K_{AB}$"

If anyone can help at all, I would greatly appreciate someone going through this question with me. It's not homework, it's not coursework. It's off a previous sheet of in class exercises that my teacher wouldn't go through with me.

I understand basic primitives, but I don't feel confident in my ability to look at an entire protocol and analyze its security properties.

See also How to attack this authentication protocol from "Cryptography: An introduction" for a more specific question about the same cryptographic protocol.

-
In step 3, how does S know Kab? –  John Deters Nov 9 '13 at 2:04

From my understanding, this protocol makes use of a trusted third party in order from A and B to exchange a symmetric key, $K_{AB}$. For the protocol to work, it is assumed that both A and B must share a master key, $K_{AS}$ and $K_{BS}$ respectively with the trusted S and A wants to communicate with B but they has no shared secret. Since there is no MAC/signature appended so it is implicit that the underlying encryption scheme also provides integrity checks. And a plaintext attack resistant encryption scheme should be used since the encrypt plaintext in step 4 is known. Thus,

A sends a random nonce, $N_A$ to B in step 1.

B sends its own nonce, $N_B$ and encrypt A's nonce before sending them to S in step 2.

Next, trusted server S will generate a symmetric key, $K_{AB}$ (which I guess should be a session key) and encrypts $K_{AB}$ separately with the keys shared with A and B in step 3. A can then decrypt $\{B, N_A, K_{AB}, T_B\}K_{AS}$ using the master key shared with S and verify that the nonce $N_A$ and timestamp is correct (for freshness) and B's ID is correct (to prevent MiTM attacks). Now A has knowledge of the assigned session key $K_{AB}$ and he computes an Authenticator (as called in Kerberos) which is actually the encryption of $N_B$. This allows user B to verify that user A does indeed have knowledge of the session key $K_{AB}$.

If everything is correct then A will forward the second part $\{A, K_{AB}, T_B\}K_{BS}$ to user B and also send the Authenticator in step 4. Similarly, user B will be able to decrypt $\{A, K_{AB}, T_B\}K_{BS}$ with the master key shared with S. B checks if A's ID and the timestamp is valid and retrieves the session key $K_{AB}$. Next, B uses $K_{AB}$ to decrypt the Authenticator to authenticate user A.

Currently, only unilateral authentication is provided. But an extra step $B \to A : \{N_B +1\}K_{AB}$ may be added for mutual authentication.

The well establish Kerberos protocol uses a similar albeit more complicated concept to issue tickets for authenticated users.

-