Why is CertificateVerify message necessary? (Why isn't client authentication done through the KeyExchange)

Question

Why is client authentication not done through the KeyExchange like with the server, but through a CertificateVerify message?

When using RSA key exchange the client encrypts the key material with the server's public key so only the real server (which has the private key) can decrypt it. [RFC5246: 7.4.7.1] Why doesn't the client also sign the key material with its private key when using client authentication?

When using Diffie-Hellman key exchange the server signs it's key parameters using its private key to prove it has the private key (and therefore is the real server). [RFC5246: 7.4.7.2] Why doesn't the client sign it's parameters too when using client authentication?

Instead of these (I think more logical) methods, the client sends a CertificateVerify message with a signature over all handshake messages. Why is this method chosen?

This only applies to certificates with signing ability, because with eg. static DH certificates client authentication is performed during the KeyExchange. [RFC5246: 7.4.8]

Answer 1

1. Your idea doesn't work. Being able to signing the key material doesn't prove that the client has the private key corresponding to the certificate.

   Authentication is usually done by a challenge-response protocol in which one party presents a question and the other party provides a valid answer to prove that it knows the rule of transforming questions to answers. The key material (here acts as the question) in the ClientKeyExchange is determined solely by the client while the server doesn't have any control over it. So it's just like making the client answer its own question. Without knowing the "rule" (the private key), the client can still provide a valid answer (signed key material). For example, an attacker can take the certificate and the signed key material from another client and later impersonate that client when communicating with the server. To get the certificate and signed key material from the victim, the attacker can establish his own server and make somebody connect to him.

   Actually, the signed hash in the CertificateVerify message includes information from both the client and the server (i.e. the "question" is determined by both sides). So the client is not answering its own question.

2. Client authentication is optional in an SSL/TLS transaction. Considering clarity and ease of implementation, it's not a good idea to have a message with two forms.

The CertificateVerify message is not strictly necessary. It is OK to merge it into the ClientKeyExchange as long as the materials to sign are carefully chosen. However, it is better to have a separate message since it plays an independent role. By the way, a separate message doesn't necessarily cost an additional TCP segment. It's very common to embed multiple messages in one segment so a separate message won't introduce extra costs.