Key Confirmation Attack [Key Distribution Center (KDC)] Okay this is how I understood it according to this:


Alice $A$ establishes a connection to $KDC$ and prepares for session key Exchange $k_{ses}$
$A$ encrypts the request with her key $k_A(A, B)$ meaning "need a session key to communicate with Bob $B$"
$KDC$ decrypts the message, genereates $k_A(k_{ses}, k_B(A, k_{ses}))$ and sends it to $A$
$A$ decrypts the messages and got now $k_{ses}$ the session key and the other part $k_B(A, k_{ses})$ she cannot decrypt (only $B$ kan due to $k_B$).
$A$ forwards the $k_B(A, k_{ses})$ message to $B$
$B$ decrypts $kB(A, k_{ses})$ and now knows he is talking to $A$ over the key $k_{ses}$


In my slides there is an attack described - the Key Confirmation Attack - which does look like this:



The thing here is now that I am not sure how this is supposed to work. This could only work if $RQST(ID_A, ID_B)$ (I'm sorry for the diverse notation) was not encrypted. This attack cannot work if the request was encrypted by Alice in the first place. 

So, are there a few things mixed up or what am I missing?

Oscar cannot produce $k_A(A, O)$ – the requesting message to generate a session key for communication $A$ to $O$ – since he does not have the key of Alice.
$ID_a, ID_b, ID_o$ are public information


Oscar sends to $KDC$ a legitimate (encrypted) request to communicate with Alice: $RQST(ID_o,ID_a)$
Oscar gets $Y_o, Y_a$
Oscar sends $Y_a, Y_o$ back to Alice. 


Alice cannot tell if she got $Y_b$ or $Y_o$, that's the problem. So, I would say the order of $ID_o$ and $ID_a$ are mixed up in the slide. It would be clearer if it was $RQST(ID_o, ID_a)$ instead of $RQST(ID_a, ID_o)$.