-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for (EAP-TLS) RFC 5216 to generate key_material #812
Comments
Hello, In reference to my previous comment regarding generating key_material, I updated the patch. Latest patch. Overview of this patch is as follows:
As per value of length and label, key_material will be generated before handshake randbytes get swapped. |
Hi Rohan, Thanks in-advance. I'm running Mbed TLS as a core security library, in embedded platform. Following are the setup details I'm using TLSv1.2 with cipher-suite MBEDTLS_TLS_RSA_WITH_AES_256_GCM_SHA384 But when i use MBEDTLS_TLS_RSA_WITH_AES_256_GCM_SHA256 / MBEDTLS_TLS_RSA_WITH_AES_128_CBC_SHA which intern uses tls_prf_sha256, what i found is MPPE key generated is matching at both end However as per TLS v1.2 RFC, provision has been made to dynamically select the cipher-suite based on the client-server negotiation. but in case of less than TLSv1.2 it uses tls1_prf function. When i looking into openssl code, freeradius and wpa_supplicant code it uses the function SSL_export_keying_material . May i know what else im missing. Thanks & Regards, |
@rohanghige - I am doing the same job as you did and I think the correct solution would be to support https://tools.ietf.org/html/rfc5705 . The RFC 5705 expects that user could use the negotiated session PRF to derive new key material. So the solution could be to export a function with following signature/prototype: PRF(label, lenght). This function will use the negotiated master secret and random bytes without exposing them. |
I too would like to have support for RFC 5705 Keying Material Exporters. It's a much cleaner interface than the current "export" callback. The current export callback does not provide the needed information to write something compatible with RFC 5705. Particularly, the client and server random are missing. In my case, I'd like to use it to generate the data channel keys for the OpenVPN data channel (instead of doing our own key negotiation dance that depends on the TLS1 PRF, which we do now). I'm willing to write a patch that adds RFC 5705 support, with a similar API to how OpenSSL does it (https://www.openssl.org/docs/man1.1.1/man3/SSL_export_keying_material.html). Would such a patch be considered for inclusion in mbed TLS? |
@manuelgavidia @syzzer if you look into the latest mbedos code with have latest version of mbedtls2.19 has the separate callback which will meet your requirement. |
@maniteja007 thanks. I noticed yesterday too, when I checked out the development branch to start on development for RFC 5705. The interface is still a bit cumbersome, but it is usable now. |
Hi,
Currently mbedTLS has support to export keys, master secret using callback function. User need to define MBEDTLS_SSL_EXPORT_KEYS and register callback function for exporting using api 'mbedtls_ssl_conf_export_keys_cb'.
But for EAP-TLS, I need 'key_material' which is generated from master secret and handshake randbytes with label 'client EAP encryption' (ref. RFC 5216: https://www.ietf.org/rfc/rfc5216.txt). But mbedTLS does have support to generate this key_material.
I created patch for that , in which key_material will generated with the same method as keyblk (ref: library/ssl_tls.c:658), difference in the label only, and before handshake randbytes gets swapped. This can be exported instead of keyblk.
Is this correct approach for this.
The text was updated successfully, but these errors were encountered: