Your description is a bit confused and appears to be wrong. In particular, we see Alice computing here Diffie-Hellman half gKA and then proceed to send... her Diffie-Hellman secret KA to Bob, which is not at all what she should do.
Plain Diffie-Hellman works the following way:
- Alice generates (randomly) her secret KA and computes gKA.
- Bob generates (randomly) his secret KB and computes gKB.
- Alice sends gKA to Bob.
- Bob sends gKB to Alice.
- Alice computes (gKB)KA, using her secret KA and the value sent by Bob.
- Bob computes (gKA)KB, using his secret KB and the value sent by Alice.
By the magic of mathematics, Alice and Bob ends up with the same value, which is the shared secret that they thereafter use for whatever cryptography they need to talk to each other.
For the authenticated variant, the same computations are done; but Alice and Bob also own asymmetric key pairs usable for digital signatures, and they use them: Alice signs whatever she sends to Bob, and Bob verifies that signature (using Alice's public key). Similarly, Bob signs what he sends to Alice, and Alice verifies that signature (using Bob's public key).
Note that a no point whatsoever does Alice send KA (he "DH secret") to Bob in any form. Neither does Bob send KB to Alice. And there is no encryption anywhere. You may encounter many tutorials that purport to explain digital signatures in terms of encryption (usually as "encryption with the private key"). These explanation are remnants of older times (the late 1970s, in fact, in the original Disco era) and are, in fact, plain wrong and very confusing. So don't think in those terms. Signatures are signatures, encryption is encryption.
Authenticated DH is what is done in, for instance, in SSL/TLS with the "DHE" cipher suites. It is also what happens in SSH (version 2).
There are two main reasons for using such an "ephemeral" Diffie-Hellman ("ephemeral" because Alice and Bob generate their DH secrets KA and KB on the fly):
The "permanent" key pairs owned by Alice and Bob may be unfit for anything else than signatures. A source of confusion (again) is that there is not one algorithm called RSA; there are at least two, one for encryption and one for signatures, and they appear to be able to use the same kind of key pairs. However, even if a RSA key pair can be used both for encryption and signatures, there are good reasons not to do so. There are also other signature algorithms (e.g. ECDSA) whose keys cannot be used (at least not easily) for encryption.
Using ephemeral DH secrets provides Forward Secrecy, which is good. Namely, the permanent keys of Alice and Bob must be stored somewhere; so they could, potentially, be stolen afterwards. With simple RSA-based key exchange (no DH, Alice encrypts a random session key with Bob's public key and Bob decrypts it), the ulterior key thief could use it to decrypt a past session. With the DH and the signatures, this issue does not occur; even if Alice's and Bob's signature private keys are revealed afterwards, their past communications cannot be decrypted. The whole concept of forward secrecy revolves around the idea that the "DH secrets", being generated on-the-fly, kept in RAM only, and destroyed immediately after completion of the DH key exchange, are immune to ulterior theft.