Among the requirements for a secure key exchange is the key confirmation. I wonder why is this step required. Even if the other party hasn't computed a correct value for the shared secret, it doesn't matter. It won't be able to decipher the information sent anyway. Why bother and make sure that the other party actually possesses the correct shared secret? It is said that this is a requirement for a secure key exchange. But why?
They certainly could decipher anything you send because you are talking about synchronous encryption, where the same key is used to encrypt and decrypt the traffic. In order for this to work both sides have to agree on a key for exchange. Shared secret verification is not actually a requirement for a secure key exchange from a theoretical standpoint, you could exchange keys securely with anyone really. However, if you do not verify the other side then you could be setting up a VPN with anyone, even those you do not want to, and send all sorts of confidential information. This is why sender verification is an integral part of all secure transfer technologies.
You may be getting confused by mixing up PKI and VPN technology, mistakenly thinking that when verification is taken care of by PKI that only the true recipient can decrypt the traffic. It's not that simple because PKI decryption (asynchronous as opposed to synchronous encryption) is extremely computation intensive, so secure transfers almost always use PKI for sender verification but then set up synchronous encryption for the transfers themselves.
EDIT: poster says the source is a lecture
If both sides do not share the same key neither side would be able to decrypt the other's traffic, so key confirmation is important from an operability perspective if not from a pure security perspective. Also, if you are using a VPN to check for authentication (see IPSEC AH) then you must verify keys, or you can't be sure what is authentic traffic. What the lecturer may mean is that it simply won't work without a key verification, rather than being a security process.
Why bother and make sure that the other party actually possesses the correct shared secret? It is said that this is a requirement for a secure key exchange. But why?
In addition to other reasons, a key confirmation is sometimes required during algorithm validation. For example, NIST's The Key Agreement Schemes Validation System (KASVS) requires them in some instances.
For completeness, here's NIST's definition from Section 4.1, page 7:
A procedure to provide assurance to one party (the key confirmation recipient) that another party (the key confirmation provider) actually possesses the correct secret keying material and/or shared secret.
Even if the other party hasn't computed a correct value for the shared secret, it doesn't matter. It won't be able to decipher the information sent anyway.
This may not necessarily be true. If a bad guy can somehow taint the exchange, he/she may be able to learn some things in the absence of a full-blown break by controlling parameters. In this case, the protocol execution would stop immediately at the key confirmation phase rather than giving the attacker more than one bite of the proverbial apple.
Protocols for Authentication and Key Establishment (pp. 162-63) actually details an attack on key exchange that's thwarted by key conformation, so its not theoretical.
I've never implemented a key confirmation protocol, but I expect them to be a two-way challenge/response protocol that does not use the keying material directly. It probably adds 2 to 4 additional messages to the protocol.
Its two way because both parties should prove knowledge of the key. It does not use the keying material directly to avoid disclosing information about the actual key to an adversary.
On a related note, you never use the shared secret/key material directly. You have to move it from the Diffie-Hellman domain into another domain where values are equally probably (i.e., uniformly distributed). IPSec uses HKDF for this step.