The MSK is generated when the keys are derived. For TLS 1.3 that's also
when the handshake is complete. However, for TLS 1.2 it happens when
generating or processing the ClientKeyExchange message, which, on the
client, happens before the final Finished handshake message has been
received from the server. This caused the EAP-TLS client to accept an
EAP-Success message instead of the server's final TLS handshake
messages, unintentionally allowing servers to cut the exchange short by
two EAP messages (in the regular exchange the response to the server's
final handshake messages is an empty EAP-Response, which is then
followed by the server's EAP-Success).
While this is not correct, it does not seem to pose a security issue.
If DH is used as key exchange, the server signs the ServerKeyExchange
message and the client is sure to communicate with a trusted server
before it derives the MSK. If RSA encryption is used as key exchange,
the client sends the premaster secret, on which the MSK is based,
encrypted with the server's public key (as extracted from the trusted
certificate). An attacker won't be able to decrypt this and, therefore,
can't derive the same MSK to generate a valid AUTH payload and the IKE
authentication will fail.
METHOD(tls_t, get_eap_msk, chunk_t,
private_tls_t *this)
{
- return this->crypto->get_eap_msk(this->crypto);
+ if (this->handshake->finished(this->handshake))
+ {
+ return this->crypto->get_eap_msk(this->crypto);
+ }
+ return chunk_empty;
}
METHOD(tls_t, get_auth, auth_cfg_t*,