The number of keys generated in TLS 1.2?

Question

In section 6.3. Key Calculation in the standard documentation here, I see the following:

The master secret is expanded into a sequence of secure bytes, which
is then split to a client write MAC key, a server write MAC key, a
client write encryption key, and a server write encryption key.

To generate the key material, compute

  key_block = PRF(SecurityParameters.master_secret,
                  "key expansion",
                  SecurityParameters.server_random +
                  SecurityParameters.client_random);

until enough output has been generated. Then, the key_block is
partitioned as follows:

  client_write_MAC_key[SecurityParameters.mac_key_length]
  server_write_MAC_key[SecurityParameters.mac_key_length]
  client_write_key[SecurityParameters.enc_key_length]
  server_write_key[SecurityParameters.enc_key_length]
  client_write_IV[SecurityParameters.fixed_iv_length]
  server_write_IV[SecurityParameters.fixed_iv_length]

Correct me if I am wrong please, does this mean:

$ms$, $kc_{mac}$, $ks_{mac}$, $kc$, $ks$ = $kdf (ms, nonce_s, nonce_c)$ ??

My questions:

1. Does that means the kdf generates "actually" 6 keys, but in fact they are 4 keys?

2. Does that means, the Finished messages are encrypted with the MAC keys and the data are encrypted with another key?

3. Is the client_write key different from the server_write key? shouldn't they generate a share secret? shouldn't the application data encrypted with share symmetric key? why does the standard make two keys?

Answer 1

1) Does that means the kdf generates "actually" 6 keys, but in fact they are 4 keys?

The KDF generates 6 values; of the 6, 4 of them can be considered "keys" (in the sense that they'll be used to key some cryptographical primitive) and 2 are not (an IV is typically not considered a "key", as exposing it does not yield a security weakness).

Also, some TLS transforms do not use all of the 6 values; the protocol handles that by making the length of the values they don't use to be 0 (so the same general structure applies). I mention this because you may run into this situation later on...

3) IS the client_write key different from the server_write key?

Yes, the client_write key is different from the server_write key. The client_write key is used to encrypt the traffic that is sent by the client to the server, while the server_write key is used to encrypt the traffic that is sent by the server to the client.

As for why they use two different keys for the different directions, well, the original SSL protocol had different keys in the two directions because it used RC4 as the encryption transform, which would have serious problems if you used the same key in the two directions. When we get to TLS 1.2, they maintained the same structure, in part because they still support RC4, in part because it also helps some transforms (e.g. GCM, which you could use the same key in both directions if you were careful with nonces, but it's easier not to have to worry about that), in part because using different keys for different purposes is just good practice, and in part because there was no real reason to change.

shouldn't they generate a share secret?

Actually, the shared secret (assuming you're using a DH-based transform) is computed much earlier, as the premaster secret. That's one of the inputs into the KDF, hence all the keys generated by TLS depend on it.

---

To answer your further questions:

Which key is the key used in the Finished MAC ?

The master secret; that's not any of the 6 traffic values (which are used to protect traffic between the two stations), but an intermediate value that is generated from the premaster secret, and in turn is used to generate the 6 traffic keys.

And, yes, it is a value that is shared between the client and the server (absent a man-in-the-middle attack).

But the standards talk about 6 keys, each party has its own key?

Again, only 4 of those values are "keys"; in any case, they are used to protect records that are exchanged between the client and the server; they too are also common between the two sides, with the understandard that the 'client->server' traffic will be protected by 3 of those values, and the 'server->client' traffic will be protected by the other 3. All these keys are symmetric, so for the system to work, both sides need to know their values.

If you really want to learn about TLS 1.2 from the source, you might try looking at rfc5246. This is not a description of TLS 1.2; it is the official definition, and hence cannot be wrong.