# 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.

## migrated from security.stackexchange.comMar 23 '15 at 11:05

This question came from our site for information security professionals.

$ID_a, ID_b, ID_o$ are public information
1. Oscar sends to $KDC$ a legitimate (encrypted) request to communicate with Alice: $RQST(ID_o,ID_a)$
2. Oscar gets $Y_o, Y_a$
3. 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)$.