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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
