The title of the protocol and explanation of the steps required The secure third party R generates key $k_1$ to communicate with A and $k_2$ to communicate with B.

A requests a key with which to communicate with B.

R generates k un and encrypts:
$E_{k_1}(k) = s1;\ \  E_{k_2}(k) = s_2; \ \ E_{k_2}(p_A) = s_A$
R sends to A $\ s_1$ and $[s_2, s_A]$.

A deciphers his key:
$E^{−1}_{k_1}(s_1) = k$

and sends to B $[s_2,s_A]$

B deciphers:
$E^{−1}_{k_2}(s_2) \ \ $(the key is received);
$E^{−1}_{k_2}(s_A) = p_A$. (B knows that he is communicating with A).


First, I would like to know the title of the protocol. Secondly, why the third party cannot send the block $[s_2, s_A]$ to B right away, why A is the one that sends it?
This protocol is known as Kerberos, at least, as originally implemented (I believe the protocol has been extended significantly since).
Within Kerberos, the tuple $[s_2, s_A]$ is protected by $k_2$ (which both R and B know); hence no one else can modify it.
This tuple essentially tells B &quot;A wants to talk to you, and use key $k$ to do so&quot;.  A third party could forward this tuple directly to B, but it doesn't give him an advantage; after all, A really does want to talk to B.  This third party could prevent A from receiving his message from R (and so A doesn't learn $k$), however the third party doesn't learn $k$ either, so B gets a key that will never be used.
It may be that, in the original protocol, the tuple R sends to A was encrypted by $k_1$; this would obviously prevent this attack - it's been a while, and so I forget the details.  Even if it doesn't, this attack doesn't doesn't achieve anything, other than preventing A from talking to B, and an adversary that can arbitrarily modify or delete messages can trivially do that.