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
PKCS#1 v1.5 signatures are not defined for use with TLS 1.3 (they can
only appear in certificates, we now send a signature_algorithms_cert
extension to indicate support for them). So for RSA certificates, we
must support RSA-PSS signatures.
There are two sets of schemes, that are differentiated by the type of
RSA key used for the signature, one is for classic RSA keys (rsaEncryption
OID), which can also be used with PKCS#1 when using TLS 1.2, the other
is for RSA-PSS keys (RSASSA-PSS OID), which are not yet commonly
used (and can't be generated by our pki tool). According to the RFC,
PSS must also be supported for TLS 1.2 if the schemes are included in
the signature_algorithms extension (e.g. OpenSSL does not use PKCS#1 v1.5
anymore if PSS is proposed).
This changes how these schemes are stored and enumerated (they are not
treated as combination of hash algo and key type anymore).
Legacy schemes (MD5/SHA-1) are removed.
There is no point proposing legacy (or future) cipher suites depending on
the proposed TLS versions. It was actually possible to negotiate and use
cipher suites only defined for TLS 1.2 with earlier TLS versions.
The code is a minimal handshake with the HelloRetryRequest message
implementation missing.
Can be tested with an OpenSSL server running TLS 1.3. The server must
be at least version 1.1.1 (September 2018).
Co-authored-by: ryru <pascal.knecht@hsr.ch>
Handling the result for enum_from_name() is difficult, as checking for
negative return values requires a cast if the enum type is unsigned. The new
signature clearly differentiates lookup result from lookup value.
Further, this actually allows to convert real -1 enum values, which could not
be distinguished from "not-found" and the -1 return value.
This also fixes several clang warnings where enums are unsigned.
To better separate the code path for different TLS versions and modes of
operation, we introduce a TLS AEAD abstraction. We provide three implementations
using traditional transforms, and get prepared for TLS AEAD modes.
Tobias Brunner