EAP-FAST PRF hooks and BoringSSL

[David Benjamin]

Hey folks,

So, you all have this logic to reimplement the TLS PRF and key
derivation in src/crypto/tls_openssl.c in openssl_get_keyblock_size
and openssl_tls_prf. It appears these are used for key derivation in
EAP-TLS, EAP-TTLS, and EAP-FAST. EAP-(T)TLS can just use RFC 5705
exporters by way of SSL_export_keying_material, which you use. But
EAP-FAST is a bit of a nightmare. Among other sins, it hooks into
TLS's internal key derivation, so you all understandably need to do
some invasive wrangling.

We took the EAP-FAST bits out of BoringSSL a long time ago. (The way
it integrated into session resumption was problematic. I know how I'd
redo it if I had to, but there hasn't been a need yet.) But to keep
wpa_supplicant compiling, we have to keep some fields around
(ssl->enc_read_ctx, ssl->read_hash, and
ssl->s3->tmp.new_mac_secret_size) even though we never fill them in.
I'd like to resolve that. I can see a few options, but I don't know
which you'd prefer:

1. I can condition the EAP-FAST-only parts of the key derivation
conditioned on EAP_FAST #defines. With
df5bde83daaf3c820b6ac1f8d383b16a64ebd2db, we're finally no longer
defining those symbols, so this would work. I would probably, to make
this cleaner, split the tls_connection_prf entry-point into two
functions, one for the reasonable RFC 5705 mechanisms and one for
EAP-FAST's crazy thing. (Right now the API supports the RFC 5705
style, but with skip_keyblock set, which is a little odd.)

2. For OpenSSL 1.1.x, you all use SSL_CIPHER_get_cipher_nid and
SSL_CIPHER_get_digest_nid. BoringSSL doesn't have these, but I have no
problems adding them. (I would not have used NIDs for
SSL_CIPHER_get_kx_nid and SSL_CIPHER_get_auth_nid but whatever.) It's
a little odd because the computation is wrong for TLS 1.1+ and we
don't use EVP_CIPHER in our SSL code anymore. But the code will never
run anyway, and if it were to later, I could make it match OpenSSL.

3. For other reasons, we added a pair of functions,
SSL_get_key_block_len and SSL_generate_key_block which are actually
exactly what EAP-FAST wants here. I could make
openssl_get_keyblock_size call SSL_get_key_block_len and even make
openssl_tls_prf use SSL_generate_key_block. (Probably this would come
with a similar tls_connection_prf split as in option #1.) But this
would be BoringSSL-only code to support a feature that doesn't work in
BoringSSL anyway, so this is of questionable use.
https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_get_key_block_len

Do you all have a preference? #2 would be the least invasive option,
but splitting tls_connection_prf in two for #1 might be preferable, at
which point you may as well condition on EAP-FAST. In doing so, we can
probably do away with the fallback from SSL_export_keying_material to
openssl_tls_prf if SSL_export_keying_material fails (looks like that's
a remnant of how the #ifdefs worked out while 1.0.0 was supported) and
not even ship a custom TLS PRF in the no-EAP-FAST config. I'm happy to
do a bit of cleanup for you along the way here.

David