Client authentication in TLS normally uses a client certificate and the method by which the client is authenticated has not substantially changed since SSL 3.0: during the initial handshake, the server asks for client authentication (a
CertificateRequest message), and the client responds by sending his certificate and then a signature computed with his private key over the concatenation of all the previous handshake messages (which includes the two "random values" sent by the client and the server, and also the negotiated cipher suites, the server's certificate...).
There are details, though. A signature algorithm uses a hash function, and the hash value is then used with the private key. Up to TLS 1.1, the client necessarily used the concatenation of MD5 and SHA-1 as "hash function". With TLS 1.2, client and server send to each other the list of hash functions and signature types they support, so that the client may choose an "appropriate" hash function, and also an appropriate certificate in case the client owns several of them.
The pre-1.2 method employs a "special padding" with RSA: in PKCS#1, the hash value is first stored in a structure which identifies the hash function (in practice, a fixed header is attached to the hash value), and that encoded structure is then padded with some bytes (most of them equal to
0xFF) up to the key length. In the signatures used from SSL 3.0 to TLS 1.1, the hash value has length 36 bytes (16 bytes for MD5, 20 bytes for SHA-1), and there is no header: the 36 bytes are directly used in "type 1 padding". With TLS 1.2, only one hash function is used (negotiated between client and server), and the header is back.
Thus, TLS 1.2 aligns itself with the PKCS#1 standard and supports many hash function, which should improve interoperability. Yet, it is conceivable that a specific hardware token for the client private key (e.g. a smart card) could be incompatible with TLS 1.2 (if it supported only the 36-byte-hash-with-no-header mode of older SSL/TLS). In that sense, TLS 1.2 might break compatibility with deployed tokens (this is rather improbable, but still warrants some tests). For software implementations, this should not be an issue.