Advanced SSL Topics - Implementing SSL/TLS Using Cryptography and PKI - page 449

most applications that use TLS to protect the privacy and authenticity of com-
munications also require that the client authenticate itself through some means
such as a shared password.
If you think about it, this is sort of archaic. All of the problems of synchro-
nizing shared keys apply to shared passwords. Because you have public-key
cryptography and PKI, why not use it?
Imagine, for instance, an online bank that creates its own internal CA and
then uses that CA to sign customer's certifi cate requests at a physical branch
location (after authenticating them physically by verifying a driver's license,
fi ngerprints, and so on). The customer can then install that CA's root certifi cate
and his own signed certifi cate on his computer and use that to prove his identity
in addition to the primitive username/password authentication method cur-
rently used. (You need both methods to guard against the damage of a private
key compromise.)
TLS allows for this. The server can demand a certifi cate and refuse to complete
the handshake unless the client provides one, signed by a suitable certifi cate
authority. RSA Data Security's RSA Key Manager (RKM) product uses this tech-
nique to authenticate requests from applications, but it's not as widespread as it
could be. This is a shame, because it's a very good, secure way to authenticate
users. If a bank started requiring this sort of “mutual authentication,” I would
defi nitely put all of my money in it.
TLS describes two additional handshake messages to support client
authentication.
The Certifi cateRequest handshake message is sent by the server to the client,
notifying the client that it expects the client to authenticate itself with a
certifi cate. The Certifi cate message sent by the client is exactly the same
format as the certifi cate message sent by the server.
the Certifi cateVerify message, the second new handshake message, is sent
by the client to prove that it is, in fact, in possession of the private key
corresponding to the public key in the certifi cate itself.
Supporting the Certifi cateRequest Message
The Certifi cateRequest handshake message is sent by the server after sending its
own certifi cate and, if applicable, server key exchange.
NOTE If the server did not send a certifi cate — for example, if it is performing
an anonymous key exchange — it may not request a certifi cate from the client.
The designers of TLS could have designed the certifi cate request to have been
defi ned as a simple marker request like the hello done and ChangeCipherSpec
messages were. However, to streamline things a bit, the TLS designers allowed