Am 11.11.19 um 00:10 schrieb Steffan Karger:
> Since mbed TLS 2.18, mbed TLS can also implement RFC 5705. As a first
> step towards using the keying material exporter as a method to generate
> key material for the data channel, implement the
> --keying-material-exporter function we already have for OpenSSL also for
> mbed TLS builds.
> 
> Implementing RFC 5705 for mbed TLS is a bit more cumbersome, because the
> library itself only provides a callback that is called during connection
> setup, which enables us to implement RFC 5705 ourselves. To protect
> ourselves against mistakes, we immediately perform the required key
> derivation to generate the exporterd keying material, and only cache the
> derived key material until we can actually export it to the environment
> (similar to the OpenSSL builds).
> 
> To test this, I found it easiest to temporarily move the call to
> key_state_export_keying_material outside the if statement, and use a
> script that runs after connection setup (e.g. --ipchange) that prints
> the environment. E.g.
> 
>   #!/bin/sh
>   env | sort
> 
> This should show the same value for the exported_keying_material env
> variable for both mbed TLS and OpenSSL builds. Of course you can also
> use the code as-is, and write a plugin to verify the same thing.
> 
> Signed-off-by: Steffan Karger <stef...@karger.me>


If we do a v2 of the patch could we rename HAVE_EKM to something better
like HAVE_EXPORT_KEYMATERIAL? EKM is a bit a too short for my taste.


Otherwise it looks good to me. I cannot really test it because I
currently do not have anything that uses export keymaterial.

As background why we want/need this patch. We currently use a fixed PRF
for determining the data channel key. While what we use (SHA1 +MD5 like
TLS 1.0) is perfectly fine, it would nice to instead use a more modern
approach. And using RFC 5705 for something like key-method 3 avoids
reinventing the wheel.

So from me point of view:

Acked-By: Arne Schwabe <a...@rfc2549.org>

Arne


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to