# What does the final term 'se' give us in Noise Protocol IK?

I am trying to learn about the Noise Protocol Framework.

Noise Protocol IK is used in WireGuard. For some client initiator and server responder, I think the idea is to hide the client's identity (public key) from an eavesdropper.

According to Noise Explorer, IK is as follows:

<- s
...
-> e, es, s, ss  # Message A, sent by initiator
<- e, ee, se     # Message B, sent by responder


My question is: What does the final se term in Message B provide us? In other words: if se is trying to bind the responder's ephemeral key with the initiator's static key... why? Isn't this already done?

To elaborate: Isn't any message from the point of ss onwards inherently bound to the initiator's static key, as we update the chaining/encryption key as follows after ss:

mixKey, which calls the HKDF function using, as input, the existing SymmetricState key, and dh(s, rs), the Diffie-Hellman share calculated from the initiator's static key and the responder's static key.

My understanding is that if the goal is to ensure PFS after message A, all that needs to be done is to mix in the responder's ephemeral key, because we've already mixed in the following:

• initializer ephemeral (from es)
• responder static (from es)
• initializer static (from ss)

So why can't we stop after ee? After all, Message B would be total nonsense if ss did not validate?

Perhaps I am wildly misunderstanding the Noise Protocol Framework completely. Any insight would be appreciated.