In TLS (that's the standard name for SSL; TLS 1.2 is like "SSL version 3.3"), client and server ends up with a shared secret (the "master secret", a 48-byte sequence; when using RSA key exchange, the master secret is derived from the "premaster secret" which is the 48-byte string that the client encrypts with the server public key). That shared secret is then "extended" into six values:
- the "client write key";
- the "client write IV";
- the "client write MAC key";
- three similar values for the server.
The "extension" uses the PRF described in section 5; it can be thought of as a hash function with a flexible output length.
TLS main purpose is to keep data confidential; however, it also aims at maintaining data integrity: if someone or something, willingly or not, alters data in transit, then the receiver must be able to reliably detect it. Detecting alterations is important in many protocols; moreover, if an attacker can modify data, he can often handcraft precise alteration which, when sent to the peer in lieu of the correct data, may result in reactions which leak information about the encrypted data. Therefore, we not only want to detect alterations for the own sake of integrity, but also because unconstrained alteration may result in a confidentiality breach.
So we need encryption (for confidentiality) and integrity control (to support confidentiality, and because integrity is also needed by itself). This calls for several algorithms, typically AES for the symmetric encryption part, and HMAC for the integrity control. HMAC is a Message Authentication Code algorithm, which is a kind of "hash function with a key" (HMAC is built over a true hash function, like SHA-256, with a key inserted "the right way"). The HMAC value is computed by the client with its "client write MAC key" and appended to the record data; the server will recompute the HMAC value and see if it matches the one which was sent.
The encryption part requires a key (and an IV for symmetric encryption algorithms which use CBC mode, and this is subject to a few subtleties which depend on the SSL protocol version, so I will not detail these here). The MAC also needs a key. Using the same key for two distinct algorithms is, as a general rule, not recommended at all: there may be unwanted interactions between the two algorithms, an improbable but not impossible event which has not been thoroughly studied. So, to be on the safe side, we generated two keys, one for encryption and one for the MAC. The two keys come from the master secret, but the derivation mechanism is like a hash function, so it supposedly makes it impossible to guess the MAC key even if you know the encryption key, and vice versa.
Since TLS has a key derivation function (the "PRF") which can produce outputs of arbitrary length, it was easy to mandate production of encryption and MAC keys distinct for both directions (the key used by the client to encrypt data -- and that the server uses to decrypt received data -- is distinct from the key used by the server to encrypt data it sends to the client). Using distinct keys avoids problems with attackers who could otherwise get a copy of an encrypted record sent by the client, and feed it back to the client as if it was sent from the server. With distinct keys, the client will reject the attempt, because the HMAC value will not match what the client expects (it will be a HMAC computed with the client write MAC key, not with the server write MAC key).
There are newer symmetric encryption modes which do the encryption and the MAC with the same key in a controlled way, e.g. GCM -- and AES-with-GCM can be used with TLS although you may have a hard time finding compatible implementations (this is rather new).