tls-crypto: Generate MSK for TLS 1.3
authorTobias Brunner <tobias@strongswan.org>
Tue, 1 Sep 2020 16:51:32 +0000 (18:51 +0200)
committerTobias Brunner <tobias@strongswan.org>
Fri, 12 Feb 2021 13:35:23 +0000 (14:35 +0100)
commit121ac4b9e37e9bc3721bb66a6e9e56a80235f988
treea62aed7e97708d7b3dcf1f6b7c76858541f281e3
parentd2fe921cf5f5fd7940495891afe108d26c1c1ca7
tls-crypto: Generate MSK for TLS 1.3

We generate material for both MSK and EMSK even though we only need the
former.  Because HKDF-Expand-Label(), on which the export functionality
is based, encodes the requested key length, we have to allocate the same
number of bytes as e.g. FreeRADIUS does (i.e. if we only request 64
bytes, those won't be the same as the first 64 bytes after requesting
128 bytes).

Unfortunately, key derivation for TLS-based methods is currently not
standardized for TLS 1.3.  There is a draft [1], which defines a scheme
that's different from previous versions (instead of individual label
strings it uses a single one and passes the EAP type/code as context
value to TLS-Export()).  The current code is compatible to FreeRADIUS
3.0.x, which doesn't implement it according to that draft yet (there are
unreleased changes for EAP-TLS, not for the other methods, but these only
switch the label, no context value is passed).  In a separate draft
for EAP-TLS [2] there is an altogether different scheme defined in the
latest version (label combined with EAP method, no context and separate
derivation for MSK and EMSK).

So this is a mess and we will have to change this later with the inevitable
compatibility issues (we should definitely disable TLS 1.3 by default).

[1] https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types
[2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13
src/libtls/tls_crypto.c