Support for (EAP-TLS) RFC 5216 to generate key_material

[rohanghige]

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.

[rohanghige]

Hello,

In reference to my previous comment regarding generating key_material, I updated the patch. Latest patch. Overview of this patch is as follows:

• Macro added MBEDTLS_EAP_TLS_KEY_MATERIAL

• Depending on this macro 3 elements are included in SSL configuration context, namely pointer to key_material length of key_material label to generate key_material

• Added api to set these 3 value in that SSL configuration context, namely 'mbedtls_ssl_conf_set_key_material'

As per value of length and label, key_material will be generated before handshake randbytes get swapped.

[maniteja007]

Hi Rohan,

Thanks in-advance.

I'm running Mbed TLS as a core security library, in embedded platform. my application is used to connect to enterprise network using PEAPv0 with mschapv2 as phase2 authentication.

Following are the setup details server setup on Ubuntu Eap Server : Free radius with version 3.0.15 openssl :1.0.2g Ubuntu version : 16.04LTS Client side setup platform : Micro controller based platform OS : FreeRTOS

I'm using TLSv1.2 with cipher-suite MBEDTLS_TLS_RSA_WITH_AES_256_GCM_SHA384 / MBEDTLS_TLS_ECDHE_WITH_AES_256_GCM_SHA384 and im taking help of inbuilt tls-prf function for the mentioned cipher suites and it uses tls_prf_sha384 function, what i found is the MPPE key generated at client side and server side is not matching.

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 . Then alos im Not able to find the implementation difference wrt openssl "SSL_export_keying_material" function and the Mbedtls "tls_prf".

May i know what else im missing.

Thanks & Regards, Teja.

[manuelgavidia]

@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.

[syzzer]

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?

[maniteja007]

@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.

[syzzer]

@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.