I ... was wondering if it was necessary to sign the ciphertext
No, there is no need to sign the ciphertext. The secret key is already derived by the key agreement protocol, and that is secure because you verified the parameters (which, I presume, includes the ephemeral public key of each party).
At this point you just have to verify that each party does indeed have the same shared secret. One way to do this is to verify a GCM encrypted message.
The problems with that are that:
- you need to send a message (which could take some time after you've agreed upon a key) and
- you're now mixing up entity authentication and message authentication.
Part 2 is a major pain in the back for developers and maintainers as they will have to mix concepts. For instance, what will you log if the first message fails? Was it data corruption for the - often much larger - authenticated message or was it a failure to establish the session in the first place?
So you're probably better off sending a MAC specific to entity authentication to the other party as soon as the shared secret is established, preferably using a different derived authentication key. You can use a KDF to e.g. establish an authentication key and message encryption key for that purpose.
The first MAC can be send with the ephemeral public key that is exchanged last; at that point one party already has the other party's public key and can establish the shared secret after all. Unfortunately it may cost you an additional message if the other party needs to be authenticated quickly. Of course there are solutions to that as well, but yeah...
How can I introduce forward secrecy?
If you used ephemeral (EC)DH key pairs for both parties to establish the session keys then you already have obtained forward secrecy. Of course this assumes that you destroy the ephemeral private keys asap after establishing the session keys.
Note that sessions are not immune to attack where the private keys are found e.g. by quantum computers in the future. Forward secrecy is not a panacea (which is why I generally stick with "forward secrecy" rather than "perfect forward secrecy" even though the "perfect" part isn't related to breaking the key agreement algorithm).