Secure Communication Focus:
I have to design a secure keep alive communication protocol and was wondering if it was necessary to sign the ciphertext after the session key has been generated as an attacker will not know the key.  

Protocol Overview:  


Both the client and server have a copy of their respective public keys.  
Generate session key using ECDH. Parameters will be signed and sent to both parties.  
Further communication encrypted with AES in GCM mode. IV and Tag are appended to the ciphertext and sent to the other party.


Side Note:
How can I introduce forward secrecy?
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).