Session key Exchange, some doubt I have to find a solution to this problem: I have a network composed by 1 server and some client. The server has a couple of keys (public and private) and it shares a secret key with each client. My goal is to exchange a session key between the server and the clients.

I've evaluated some solutions, but I am unsure if my reasoning is correct.

I started thinking about DH, looking for a solution making it secure. And then I realised that maybe the client could randomly generate the session key and then it could send the key to the server in a secure way. In particular, my “secure way” consists in calculating the MAC of the session key using the shared secret key between client and server, and then encrypting $(MAC || session key)$ with the server's public key. In my opinion this “protocol” provides confidentiality, integrity and a sort of authentication using the secret shared key. 

To conclude the protocol the server should send an ACK if the exchange has worked.

To recap:

Client:


generate $k$ // random session key
$t \leftarrow M(k,s)$ // calculate MAC using s(shared secret key)
$c \leftarrow E(es , k||t)$ // Encrypt $k||t$ using server's public key
Send $c$


Server:


$k||t \leftarrow D(ds , c)$ // Decrypt c using server's private key
$t´ \leftarrow M(k,s)$
$(t == t´)$ ? OK : ERR


I'd like to know if my reasoning is correct.
This is basically the difference between e.g. the RSA_ ciphersuites and the DHE_/ECDHE_ ciphersuites in the TLS protocols. Currently the standardization moves towards ECDHE_ because it provides forward secrecy: even if you factor the RSA key you can still not decrypt previous transmissions.

Note that you don't have to MAC the session key before encryption with the RSA public key. You do however need to MAC your ACK with the session key so the client can verify the that you both have calculated the same session keys.

I'm saying keys because you should try and create at least session keys for sending and receiving. In addition you could create keys for session encryption, session authentication and possibly even the initial authentication, depending on the rest of the protocol.



You can forget all the text above if you study TLS, or if you use (D)TLS in favor over your own protocol of course. No need to climb an ice wall, somebody already dug a tunnel.