How are PSKs agreed upon by the TLS server and client?

Question

I've read that pre-shared keys (PSKs) are symmetric keys shared in advance among communicating parties but have found no explanation as to how the TLS client and server agree upon the value of the PSK. How is this done?

Answer 1

How is the PSK shared?

A pre-shared key is, by definition, pre-shared. The term for this is that it is distributed out-of-band. In other words, the protocol does not prescribe a mechanism for sharing the key. It could be done using a logically-separate key agreement protocol, or by being generated from a shared secret hardcoded in both devices, or over a wireless NFC connection, or even by being directly typed in through a keyboard by a human. The point is that the PSK is shared exclusively out-of-band.

The definition of out-of-band, according to Wikipedia:

[...] an agreement or understanding between the communicating parties that is not included in any message sent over the channel but which is relevant for the interpretation of such messages.

How is the PSK used?

There are three main suites in TLS-PSK. The first, PSK, uses this shared-secret directly to derive all symmetric key material for the protocol. The latter two, RSA_PSK and DHE_PSK, only use the PSK in place of a standard digital certificate. TLS-PSK is used to refer to any of these three suites:

• PSK directly uses the pre-shared secret to derive the premaster secret, which itself is used to generate all other symmetric keys used by the protocol. If the PSK is stolen, confidentiality and authenticity are completely lost. That is, an attacker can passively decrypt stored sessions.

• RSA_PSK uses the pre-shared secret only for authentication in place of a standard certificate. The actual premaster secret is exchanged using RSA. If an attacker manages to steal the PSK, they will be able to perform a MITM attack, but a passive attacker will be thwarted.

• DHE_PSK is like RSA_PSK, but using Diffie-Hellman (DH) rather than RSA. DH provides forward secrecy. It is stronger than RSA in that the private key is ephemeral and never stored. There is less risk that the private key will be stolen, to allow passive decryption of recorded sessions.

Answer 2

To verify that the server is the correct one and not some man in the middle TLS the server authenticates itself against the server.

Usually this is done with certificates: here the server sends a certificate, proves (by signing some challenge) that it owns the private key for this certificate and the client checks if the certificate is valid for the server. This validation requires the client to have some pre-existing local trust anchor, i.e. either the certificate itself is trusted (pinning) or the CA which (directly or indirectly) issued the CA is trusted.

With DHE-PSK or RSA-PSK as defined in RFC 4279 section 3 and 4 this is similar: the client has some pre-existing local trust anchor, which is not a CA but in this case the expected PSK. The server again proves knowledge of the PSK to the client similar to how it proved ownership of the private key of the certificate before. With PSK key exchange as defined in RFC 4279 section 2 no explicit authentication is done at all but the PSK is used directly to derive the keys for encryption. But without knowledge of the key the data cannot be decrypted which implicitly authenticates the peer.

How the PSK is put on the client before the TLS handshake (and thus before the authentication) is not defined similar to how it is not defined how the local trust store is setup with CA before the authentication. Of course, it has to be done in some secure way, for example when setting up the device at the vendor before it gets shipped to the customer.