EAP-FAST PRF hooks and BoringSSL

[David Benjamin]

On Tue, May 10, 2016 at 1:28 PM, David Benjamin <davidben at google.com> wrote:
> 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.)

I've attached the cleanup and #ifdefs I was thinking for this option.
Note: I've only compile-tested this against Android thus far. It's
mostly to clarify what I mean, and I'm sure I messed up somewhere.

I think the first of these two patches is worthwhile in itself. The
EAP-FAST key derivation is very different compared to how new
protocols are supposed to do it (RFC 5705). The split is also more
conducive to, say, OpenSSL maybe providing an API for extracting
EAP-FAST style keys, either by adding BoringSSL's
SSL_generate_key_block API to OpenSSL or perhaps they add an
EAP-FAST-specific key derivation function. I don't think it makes
sense that hostap needs to reimplement the TLS PRF.

You can also see awkwardness in the merged tls_connection_prf; the
skip_keyblock parameter makes no sense unless server_random_first and
label align with the native TLS key derivation. Whereas when
skip_keyblock and server_random_first is 0, this is just a call to
SSL_export_keying_material in OpenSSL. This suggests they should be
two distinct operations.

The second one I don't have strong opinions on. For my purposes, I
would be happy with it, with making BoringSSL use the OpenSSL 1.1.x
path (I'd add the missing functions), or with using the
BoringSSL-specific functions. I'm happy to put together whichever
version you all prefer.

Thoughts?

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-TLS-Split-tls_connection_prf-into-two-functions.patch
Type: text/x-patch
Size: 15563 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160518/d10c4957/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-OpenSSL-Don-t-implement-tls_connection_get_eap_fast_.patch
Type: text/x-patch
Size: 2265 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160518/d10c4957/attachment-0003.bin>