Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

Hi Gert, Steffan and David ! There is Sample HTTP (SSO) OpenVPN Plugin with http.client.py and http-server.py scripts based on OpenVPN's RFC-5705 support. OpenVPN plugin examples.Daniel Kubec Examples provided: sso.c -- HTTP (SSO) Example based on

Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

Hi Gert, Steffan and David I fixed following: a) doc/keying-material-exporter.txt ( "straightforward" spelling ) b) used spaces instead of tabs in ssl_openssl.c:key_state_export_keying_material() + some minor code cleanups Gert I understand your valid questions and still thinking about some

Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

Hi, On Mon, Mar 09, 2015 at 08:46:10PM +0100, daniel kubec wrote: > It is nothing more then generating same keying material for client and > server plugins (OPENVPN_PLUGIN_TLS_FINAL callback) > without the need of transfer that key throught (D)TLS channel and/or app > layer. Why is it so hard

Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

Hi, I wanted to discuess (IRC) what exactly I should add to documentation. It's like adding standard, secure and well defined hash-function for use by plugins and then there are (N) different use-cases. "\-keying-material-exporter label len Save Exported Keying Material [RFC5705] of len bytes

Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

Hi, On Mon, Mar 09, 2015 at 07:26:28PM +0100, daniel kubec wrote: > It is actually well defines mechanism for "crypto/authentication" > plugin developers and they should know what they are doing. > > Maybe Let's try to discuss that using IRC. IRC explanation isn't going to help someone who

Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

Hi Gert, There are alot of different use-cases for this standard mechanism and I really thinkin about better explanation in general. I think that some real example will help alot but it requires alot of client+server code of different protocols (so many of do this and that). When you got

Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

Hi Steffan, David and Gert, I fixed bug related to format_hex_ex() for size > 20, removed bracers arround "-keying-material-exporter label len" and added upper bound to the check in options.c. king regards Daniel On 6 March 2015 at 20:44, David Sommerseth

Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/03/15 01:03, daniel kubec wrote: > Greetings Steffan, David and Gert > > Thank you very much for your comments. > > 1) log level switched to D_TLS_DEBUG_MED 2) ekm_size removed, > ekm_size != 0 condition is used instead. 3) changed to: >

Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

Hi, On Mon, Mar 02, 2015 at 01:03:38AM +0100, daniel kubec wrote: > Added 2 patches related to [RFC-5705] (code + docs). Thanks. TBH, this is all very nice and dandy, but it still doesn't make much sense to me... Some more real-worldish specific examples ("do *this* and *that*, and then this

Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

Greetings Steffan, David and Gert Thank you very much for your comments. 1) log level switched to D_TLS_DEBUG_MED 2) ekm_size removed, ekm_size != 0 condition is used instead. 3) changed to: exported_keying_material 4) minimum set to 16 bytes and maximum set to 4095 bytes. Added 2 patches

Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/02/15 17:18, Gert Doering wrote: > Hi, > > On Mon, Feb 23, 2015 at 04:51:34PM +0100, Daniel Kubec wrote: >> Keying Material Exporter [RFC 5705] Patch rebased to actual master >> branch. > > There definitely needs to be much(!) more

Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

Hi, On Mon, Feb 23, 2015 at 04:51:34PM +0100, Daniel Kubec wrote: > Keying Material Exporter [RFC 5705] Patch rebased to actual master > branch. There definitely needs to be much(!) more documentation about this, maybe an extra .txt file under doc/ - I still(!) have *no* idea what this is