PSK identification hint not defined (see RFC 4279 ). In a pre-shared access scheme (PSK), both the client and the server must be able to output the same set of cryptographic keys. Authentication authenticity is what the server provides to tell the client how to retrieve the key.
Since each server can have its own unique way to generate a key, the client must know something about the server in order to know what to do with the PSK identification hint. And each implementation uses a hint differently.
For example, NETCONF uses the tooltip directly when creating the PSK (where + means concatenate):
PSK = SHA-1(SHA-1(psk_identity + "Key Pad for Netconf" + password) + psk_identity_hint)
While the Symbian Secure User Plane Location ( SUPL ) protocol uses it to present the protocol version and provide a list of PSK generators that the client can use.
Note. The PSK identification hint is optional and its value is undefined (format must be UTF8). Applications using the TLS-PSK can leave this or use it for any action (for example, SUPL uses it to indicate the SUPL version of the protocol and provide a list of allowed PSK generators).
Similarly, the TLS-PSK for EMV smart cards uses an identification hint to determine how to calculate the PSK.
When psk-identity-hint is not delivered to the server, the default mode is selected. This mode works with static PSK by default. Otherwise, psk-identity-hint defines a specific profile for xCDOL1 values and PSK calculation.
So, as you can see, if you get a PSK hint from the server, you already need to know what information it provides and what to do with it, or you won’t be able to create the same set of keys that the server has.
Footnote: Nokia was responsible for the PSK-TLS RFC 4279 project, and also sent the patch to OpenSSL, implementing the specification.