I am assuming you are talking about these in context of TLS, particularly TLS ciphers. There seems to be some confusion around the what each component does. It is all easier to understand if you see the whole picture so here it is.
During a TLS handshake the following things happen: authentication, key exchange. The details about these depend on the so called cipher suite. Here is a sample.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
This basically says the following.
- The server will serve a certificate, which contains an RSA public key. This will be used for authentication.
- The key exchange will be done using ECDHE.
- The symmetric cipher used after the key exchange will be AES-GCM with a 128 bit key.
- The PRF (pseudo-random function) to use during the exchange is SHA256 (it may also indicate the MAC w/ older TLS versions).
Look closely and you will see how all these are represented in the cipher suite.
Now let's see what these might mean: ECDHE-RSA, Static DH, RSA
ECDHE-RSA = server randomly generate a DH-key pair because the
certificate has no sufficient information to send over to client for
master secret generation. The DH public key is sent in "server key
exchange" packet. The secret will never be sent in the wire. The "RSA"
in the cipher suite refers to the random DH public key signature, but
not the certificate signature
You are on the right track here, and now, with the knowledge about the whole picture, it is easier to understand this. During a "classic" key exchange, the public key in the certificate (and its private pair) is used to agree on a symmetric key. This, however, creates problems if the server's key is ever compromised. If private key corresponding to the public key in the certificate is ever stolen, previously recorded traffic can be decrypted at ease.
This is something we generally want to avoid. Enter Forward Secrecy. The protocol introduces the possibility to have a separate key exchange which does not depend on the RSA key pair that much. The algorithm usually used for this is called Diffie-Hellman.
For DH to work you need the so called DH-parameters, which are basically a prime modulus and a generator. These parameters are public. These are precomputed during the server setup time and shared with each client during the key exchange. Clients in cooperation with the server then use these parameters to agree on a key without actually sending it over the wire, just like you said. Here is a great video about this from the Khan Academy. The DH-key pair's private key is essentially the private number in the video. While the public key is what is sent on the wire.
To sum it up, ECDHE is Ephemeral Elliptic Curve Diffie-Hellman, which is DH over elliptic curves. The ephemeral part refers to the fact that each connection uses a different, randomly generated DH-key pair.
Static DH = server has a fix DH public key in the certificate, it will
be used by the client for share secret generation. The secret will
never be sent in the wire. Since information is enough, server key
exchange message is not needed
Static DH refers to the server choosing the same DH key-pair for every client connection (private number in the video). Or, like you suggested, it can be embedded in the certificate. This allows passive monitoring of TLS connections. This essentially disables forward secrecy.
RSA = Client will use server's public key to encrypt the PMS and send
over to server, server will decrypt the PMS and generate the same PMS.
The secret is sent in the wire
Exactly so.
Now, arriving at your question.
"RSA public key" in the certificate, for TLS-RSA, is used by the
client to encrypt the PMS. It can be seen at "client key exchange"
packet. Then What is its function in the case of TLS-ECDHE-RSA?
Now, this is easy to answer. When there is an explicit key exchange algorithm, the key in the certificate (RSA public key in this case) is only used for authentication. Making sure you connect to the host you intend to by validating the certificate chain and verifying that the server holds the private key for the given certificate's public one. It will also sign the DH-public key it sends to the client with its RSA private key, which the client verifies during the handshake.