Is what i'm trying to do safe? What both parties have:

Server
Master Secret (MS)
Server supported versions (Svers)
Agreed upon version (ver)

Client
Master Secret (MS)
Client supported versions (Cvers)
Agreed upon version (Ver)

What I am planning on doing:

Client sends Cvers to Server.
Server checks what version to use (the highest version the 2 share will be selected)

then computes

Rand = Generate crypto random number
SessionID = SHA256(MS, ver, Rand) "&lt;- though the hash will most likely be dependable on the selected version"
SessionKey = KDF(MS, SessionID)
EncryptionKey = KDF(SessionKey, Rand)
IV/nonce = Generate crypto random number


Server sends message to client: SessionID, Ver, Rand, IV/nonce 
Client checks if the returned version he got from the server is actually a version he has (just to be sure). Then the client computes:

SessionKey = KDF(MS, SessionID)
EncryptionKey = KDF(SessionKey, Rand)


If we were to need an extra key (for HMAC) we would simply send over an other random number.

Then finally the client would create a random message and encrypt this message in the propper way according to the selected version. It would send this random message and the ciphertext to the server, the server will either decrypt it or do the same as the client and compare the results. If the results match it will send an OK message back to the client and the communication can commence.

I have a few questions regarding this:


Obviously, is this secure?
Do i need the session key or can i derive the encryption key directly from the MS? (provided the Rand is different each time)
Is the generation of the SessionID ok this way or should a simple random number suffice?
Should the client create a random message and send this over in plain text or should both the server and the client have a message which is 'hard coded' and always use that (it will be the same every session).


I hope it is ok to ask these kind of questions here.



Disclaimer 
Lets start of by saying, yes i know making an own protocol is bad mkay. I have discussed this (at length) with my supervisors but (they made a 'fair' point) there is no TLS implementation small enough that can fit on our devices (not much remaining code space). So here I am implementing (it hurts saying this) my own small TLS-ish protocol.

Also, the versions do not correspond to TLS, version 1 might be AES-CBC version 2 might be AES-GCM version 3 might met TDES-CBC (etc.)
This is a very difficult question. But first the standard information:


Don't roll your own crypto if anyhow possible. (which isn't the case here)
No protocol should be considered secure until formally proven secure. (TLSv1.2 is)


That being said I can still provide "ad-hoc" security argumentations why it's likely that your handshake is (in)secure.I can't prove protocols secure. For this need you have to consult special companies or cryptographers who have actually published such proofs.


If a protocol downgrade (which is trivial here) doesn't hurt you you should be safe.
Your encryption key currently is $EK=KDF(KDF(MS||SHA_{256}(MS||Ver||Rand))||Rand)$. I think that just deriving this key like $EK=KDF(MS||Rand)$ is equally secure and a bit faster and you can expand it to $(EK||AK)=KDF(MS||Rand)$ with $AK$ being the authentication key.
The generation of the session ID like this is a nice idea to authenticate the random value at the same time (maybe using the suggestion below).
I'm not fully sure what you mean by this question. But the Rand value is essential to be different each time to get different session keys (what your protocol tries to achieve), so hardcoding them would be a very bad idea.


Some other notes:


You mentioned HMAC for authentication. Please use a standard AEAD construction (->GCM,EAX,...) if anyhow possible.
You may want to consider, if sending the SessionID, that you check the SessionID on the client side, as it is an "authentication tag"
You may also want to consider using a different IV/Nonce for each message and exclude it from the handshake as it doesn't seem to provide any purpose. However, after the handshake it's an interesting idea to exchange random messages to check the key exchange worked.
You may further want to consider replacing the SHA-256(MS||Ver||Rand) by $HMAC_{MS}(Ver||Rand)$ and thus "authenticate" the random value and the version to defend against tampering, this means you also need to actually transmit the tag (which you were already doing).
You may want to consider using a TLS-PSK cipher suite, like TLS_PSK_WITH_AES_256_GCM_SHA384, but then you'd loose the session key property of having different keys as all session keys will be equal (somewhat defeating the purpose of your protocol), but you could use the "other_secret" field to insert some random negotiated data (using your above protocol) and be confident that you use "fully" TLSv1.2 and have key-freshness.