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

[daniel kubec]

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 TLS Keying Material Exporters [RFC-5705]
 (openvpn/doc/keying-material-exporter.txt)

Requires:
OpenVPN RFC-5705 Support, OpenSSL >= 1.0.1

Files:
  http-server.py -- Example HTTP Server listen  0.0.0.0:8080
  http-client.py -- Example HTTP Client connect 10.8.0.1:8080 [GET /$SESSIONID]

  server.ovpn-- Example HTTP SSO VPN Server configuration
  client.ovpn-- Example HTTP SSO VPN Client configuration

  sso.c, sso.so  -- Example OpenVPN Client and Server plugin

To build:
  ./build sso

To use in OpenVPN:

Enter openvpn/sample/sample-plugins/sso directory

$ openvpn --config ./server.ovpn
$ openvpn --config ./client.ovpn
$ ./http-server.py
$ ./http-client.py

Test:

openvpn --config ./server.ovpn
##

PLUGIN SSO: app session created
PLUGIN_CALL: POST ./sso.so/PLUGIN_TLS_VERIFY status=0
PLUGIN SSO: app session key:  a5885abc84d361803f58ede1ef9c0adf99e720cd
PLUGIN SSO: app session file:
/tmp/openvpn_sso_a5885abc84d361803f58ede1ef9c0adf99e720cd
PLUGIN SSO: app session user: Test-Client

openvpn --config ./client.ovpn
##
PLUGIN SSO: app session created
PLUGIN_CALL: POST ./sso.so/PLUGIN_TLS_VERIFY status=0
PLUGIN SSO: app session key:  a5885abc84d361803f58ede1ef9c0adf99e720cd
PLUGIN SSO: app session file: /tmp/openvpn_sso_user
PLUGIN_CALL: POST ./sso.so/PLUGIN_TLS_FINAL status=0

HTTP_SERVER:
http-server.py

http server started
session file: /tmp/openvpn_sso_a5885abc84d361803f58ede1ef9c0adf99e720cd
10.8.0.1 - - [02/Apr/2015 15:03:33] "GET
/a5885abc84d361803f58ede1ef9c0adf99e720cd HTTP/1.1" 200 -
session user: Test-Client
session key:  a5885abc84d361803f58ede1ef9c0adf99e720cd

HTTP_SERVER:
http-client.py
Greetings Test-Client. You are authorized



On 10 March 2015 at 09:08, Gert Doering  wrote:
> 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 to describe a good use case along the lines of what
> I described here?
>
>> On 9 March 2015 at 20:02, Gert Doering  wrote:
> [..]
>> > No code needed.  Just describe the parts that would be needed to make
>> > this work - like "on the server, you need a plugin that talks to
>> > foobar service to get a blinkenlight, on the client, you need a plugin
>> > that uses EKM to make the light blink, via..."
> [..]
>
>
> You have written a lot of crypto speak, and added a bit of handwaving why
> this is totally useful - but no specific example, how the bits and pieces
> have to be combined to make it work.
>
> Of course, single-sign-on would be extremely great - but I lack the crypto
> background (or the imagination) to see how this could be implemented using
> EKM - so, please explain it to us.
>
> gert
>
> --
> USENET is *not* the non-clickable part of WWW!
>//www.muc.de/~gert/
> Gert Doering - Munich, Germany g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


openvpn-rfc5705-sample.patch
Description: Binary data

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

[daniel kubec]

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 real
example with doc/specs based on existing general mechanism and
references in doc/keying-material-exporter.txt


Best Regards

Daniel

On 10 March 2015 at 09:08, Gert Doering  wrote:
> 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 to describe a good use case along the lines of what
> I described here?
>
>> On 9 March 2015 at 20:02, Gert Doering  wrote:
> [..]
>> > No code needed.  Just describe the parts that would be needed to make
>> > this work - like "on the server, you need a plugin that talks to
>> > foobar service to get a blinkenlight, on the client, you need a plugin
>> > that uses EKM to make the light blink, via..."
> [..]
>
>
> You have written a lot of crypto speak, and added a bit of handwaving why
> this is totally useful - but no specific example, how the bits and pieces
> have to be combined to make it work.
>
> Of course, single-sign-on would be extremely great - but I lack the crypto
> background (or the imagination) to see how this could be implemented using
> EKM - so, please explain it to us.
>
> gert
>
> --
> USENET is *not* the non-clickable part of WWW!
>//www.muc.de/~gert/
> Gert Doering - Munich, Germany g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


openvpn-rfc5705-doc-v3.patch
Description: Binary data


openvpn-rfc5705-v3.patch
Description: Binary data

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

[Gert Doering]

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 to describe a good use case along the lines of what 
I described here?

> On 9 March 2015 at 20:02, Gert Doering  wrote:
[..]
> > No code needed.  Just describe the parts that would be needed to make
> > this work - like "on the server, you need a plugin that talks to
> > foobar service to get a blinkenlight, on the client, you need a plugin
> > that uses EKM to make the light blink, via..."
[..]


You have written a lot of crypto speak, and added a bit of handwaving why
this is totally useful - but no specific example, how the bits and pieces
have to be combined to make it work.

Of course, single-sign-on would be extremely great - but I lack the crypto
background (or the imagination) to see how this could be implemented using 
EKM - so, please explain it to us.

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpiPEikzNoDs.pgp
Description: PGP signature

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

[daniel kubec]

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 using label in environment
(exported_keying_material) for use by plugins in OPENVPN_PLUGIN_TLS_FINAL
callback."

"Keying Material Exporter [RFC-5705] allow additional keying material to be
derived from existing TLS channel. This exported keying material can then be
used for a variety of purposes. TLS allows client and server to establish
keying material for use in the upper layers between the TLS end-points"

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.

Daniel

On 9 March 2015 at 20:02, Gert Doering  wrote:
> 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 comes across this in
> a few months or years - a good example in the docs would really be
> appreciated.
>
> No code needed.  Just describe the parts that would be needed to make
> this work - like "on the server, you need a plugin that talks to
> foobar service to get a blinkenlight, on the client, you need a plugin
> that uses EKM to make the light blink, via..."
>
> Right now I see crypto that adds code, seems to not break anything, but
> the only reason why the extra code is there is "oh, you can do lots of
> cool things with it" - this should be spelled out better, to make it
> useful to more people.
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>//www.muc.de/~gert/
> Gert Doering - Munich, Germany g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

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

[Gert Doering]

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 comes across this in 
a few months or years - a good example in the docs would really be
appreciated.

No code needed.  Just describe the parts that would be needed to make
this work - like "on the server, you need a plugin that talks to
foobar service to get a blinkenlight, on the client, you need a plugin
that uses EKM to make the light blink, via..."

Right now I see crypto that adds code, seems to not break anything, but
the only reason why the extra code is there is "oh, you can do lots of
cool things with it" - this should be spelled out better, to make it
useful to more people.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpfs5X_ubx6o.pgp
Description: PGP signature

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

[daniel kubec]

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 authenticated VPN then you dont need for example to
discomfort users with username/password in protocols on top of VPN
(Kerberos, HTTP(s), ...)
and you can automatically authenticate "(SSO)" these layers using this
exported keying material [RFC-5705].

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.

Daniel

On 6 March 2015 at 19:45, Gert Doering  wrote:
> 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 mechanisms helps you to achive *this* goal!") instead of links to
> very theoretic documents was more what I had in mind.
>
> The text itself is not bad, but it's still way to crypto-self-centric -
> if you can explain this to someone who doesn't know crypto but wants to
> use that feature for something cool, then you've achieved the goal.
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>//www.muc.de/~gert/
> Gert Doering - Munich, Germany g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

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

[daniel kubec]

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
 wrote:
> -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:
>> exported_keying_material 4) minimum set to 16 bytes and maximum set
>> to 4095 bytes.
>>
>> Added 2 patches related to [RFC-5705] (code + docs).
>>
>> Regards
>>
>> Daniel
>>
>> On 25 February 2015 at 23:39, Steffan Karger 
>> wrote: On 23-02-15 17:28, David Sommerseth wrote:
> On 23/02/15 17:18, Gert Doering wrote:
>> 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 useful for, or how to
>> use it, so right now this is "extra code complexity with no
>> well-explained gain" to me.
>
>> I understand that David understands this, but we really
>> really need to have documentation understandable to
>> non-crypto-geeks about it before it can go in.
>
> Fair enough.
>
> Daniel, would it be possible to add some docs and possibly a
> very simple tool + plugin which could be used to demonstrate
> this feature?  API docs should go into the docs/ sub-folder
> and the demo code into sample/sample-plugins/.
>
> I suggest this comes as a separate patch, for patch
> maintainability. Will probably be a good idea to even split
> docs and demo/sample code into separate patches too?   (I'm
> not too keen on big patches doing several things)
>>
>> Agreed that a bit more documentation would make this patch a lot
>> more useful.
>>
>> - From a crypto perspective I think the codes is good. I do have a
>> few practicals nits though:
>>
>> 1) Instead of using just M_DEBUG in dmsg(), please add a log
>> level. Since you are printing derived key material, I think a
>> rather high log level like D_TLS_DEBUG, or perhaps D_TLS_DEBUG_MED
>> would make sense.
>>
>> 2) ekm_used in struct tls_options is equivalent to (ekm_size > 0).
>> You could just get rid of this extra variable.
>>
>> 3) tls_binding_key might not be the best env var name. That name
>> hints at the use case you have in mind for this mechanisms, but it
>> does not cover all use cases, nor does it easily match to the
>> 'keying-material-exporter' name of the option you introduce.
>> Something like 'exported_keying_material' might me more
>> appropriate.
>>
>> 4) We might want to enforce a minimum length for the exported
>> keying material. How about 128 bits / 16 bytes? Just to prevent a
>> user making a typo from ending up with ridiculously small keys.
>>
>> -Steffan
>
> I have looked at the plug-in side of the code, and code wise it looks
> good to me.  But I wonder if there's an unintended bug here, related
> to the usage of format_hex_ex().
>
> I have written a very simple plug-in, basically based on
> sample/sample-plugins/log/log_v3.c.  It attaches itself to
> OPENVPN_PLUGIN_TLS_FINAL, and when this stage happens, it logs the
> contents of the 'exported_keying_material' environment variable when
> reaching this state.
>
> The log code looks like this:
> - -
> const char *keyingmat = NULL;
>
> keyingmat = get_env("exported_keying_material", args->envp);
> ovpnlog(PLOG_NOTE, "rfc5705-tester",
> "*** Received keying material %s", keyingmat);
> - -
>
> This all seems to work fine, until I pass a 'len' argument larger than
> 19, then I see this in my log:
>
>   Received keying material 642e0422ed1ea8ed8d93b471bfd258[more...]
>
> If I reduce it to 19, the '[more...]' part disappears.  Increasing the
> lenght of the "EXPORTER" string doesn't seem to help either.  As the
> length is restricted to 4096, I'd expect to go at least a bit further
> than 20.
>
> I wonder if it is just a misunderstanding how of format_hex_ex()
> works, where the maxoutput is not a traditional truncation limit.  If
> maxoutput is 0, it will allocate the needed space for the string
> buffer automatically, based on the input string.  The "traditional"
> truncation limit is set by the 'size' argument.
>
>
> - --
> kind regards,
>
> David Sommerseth
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iEYEARECAAYFAlT6A4wACgkQDC186MBRfrqsXwCeOY9CC0/UIlUNErcytTcniyVN
> 

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

[David Sommerseth]

-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:
> exported_keying_material 4) minimum set to 16 bytes and maximum set
> to 4095 bytes.
> 
> Added 2 patches related to [RFC-5705] (code + docs).
> 
> Regards
> 
> Daniel
> 
> On 25 February 2015 at 23:39, Steffan Karger 
> wrote: On 23-02-15 17:28, David Sommerseth wrote:
 On 23/02/15 17:18, Gert Doering wrote:
> 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 useful for, or how to
> use it, so right now this is "extra code complexity with no
> well-explained gain" to me.
 
> I understand that David understands this, but we really
> really need to have documentation understandable to
> non-crypto-geeks about it before it can go in.
 
 Fair enough.
 
 Daniel, would it be possible to add some docs and possibly a
 very simple tool + plugin which could be used to demonstrate
 this feature?  API docs should go into the docs/ sub-folder
 and the demo code into sample/sample-plugins/.
 
 I suggest this comes as a separate patch, for patch 
 maintainability. Will probably be a good idea to even split
 docs and demo/sample code into separate patches too?   (I'm
 not too keen on big patches doing several things)
> 
> Agreed that a bit more documentation would make this patch a lot
> more useful.
> 
> - From a crypto perspective I think the codes is good. I do have a
> few practicals nits though:
> 
> 1) Instead of using just M_DEBUG in dmsg(), please add a log
> level. Since you are printing derived key material, I think a
> rather high log level like D_TLS_DEBUG, or perhaps D_TLS_DEBUG_MED
> would make sense.
> 
> 2) ekm_used in struct tls_options is equivalent to (ekm_size > 0).
> You could just get rid of this extra variable.
> 
> 3) tls_binding_key might not be the best env var name. That name
> hints at the use case you have in mind for this mechanisms, but it
> does not cover all use cases, nor does it easily match to the 
> 'keying-material-exporter' name of the option you introduce.
> Something like 'exported_keying_material' might me more
> appropriate.
> 
> 4) We might want to enforce a minimum length for the exported
> keying material. How about 128 bits / 16 bytes? Just to prevent a
> user making a typo from ending up with ridiculously small keys.
> 
> -Steffan

I have looked at the plug-in side of the code, and code wise it looks
good to me.  But I wonder if there's an unintended bug here, related
to the usage of format_hex_ex().

I have written a very simple plug-in, basically based on
sample/sample-plugins/log/log_v3.c.  It attaches itself to
OPENVPN_PLUGIN_TLS_FINAL, and when this stage happens, it logs the
contents of the 'exported_keying_material' environment variable when
reaching this state.

The log code looks like this:
- -
const char *keyingmat = NULL;

keyingmat = get_env("exported_keying_material", args->envp);
ovpnlog(PLOG_NOTE, "rfc5705-tester",
"*** Received keying material %s", keyingmat);
- -

This all seems to work fine, until I pass a 'len' argument larger than
19, then I see this in my log:

  Received keying material 642e0422ed1ea8ed8d93b471bfd258[more...]

If I reduce it to 19, the '[more...]' part disappears.  Increasing the
lenght of the "EXPORTER" string doesn't seem to help either.  As the
length is restricted to 4096, I'd expect to go at least a bit further
than 20.

I wonder if it is just a misunderstanding how of format_hex_ex()
works, where the maxoutput is not a traditional truncation limit.  If
maxoutput is 0, it will allocate the needed space for the string
buffer automatically, based on the input string.  The "traditional"
truncation limit is set by the 'size' argument.


- -- 
kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlT6A4wACgkQDC186MBRfrqsXwCeOY9CC0/UIlUNErcytTcniyVN
rwoAn2TcaaoILYjCN2C6mFb59jmqa4Bf
=fdfs
-END PGP SIGNATURE-

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

[Gert Doering]

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 mechanisms helps you to achive *this* goal!") instead of links to 
very theoretic documents was more what I had in mind.

The text itself is not bad, but it's still way to crypto-self-centric - 
if you can explain this to someone who doesn't know crypto but wants to
use that feature for something cool, then you've achieved the goal.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpjWoxV3kurg.pgp
Description: PGP signature

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

[daniel kubec]

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 related to [RFC-5705] (code + docs).

Regards

Daniel

On 25 February 2015 at 23:39, Steffan Karger  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 23-02-15 17:28, David Sommerseth wrote:
>> On 23/02/15 17:18, Gert Doering wrote:
>>> 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 useful for, or how to use it, so right now this
>>> is "extra code complexity with no well-explained gain" to me.
>>
>>> I understand that David understands this, but we really really
>>> need to have documentation understandable to non-crypto-geeks
>>> about it before it can go in.
>>
>> Fair enough.
>>
>> Daniel, would it be possible to add some docs and possibly a very
>> simple tool + plugin which could be used to demonstrate this
>> feature?  API docs should go into the docs/ sub-folder and the demo
>> code into sample/sample-plugins/.
>>
>> I suggest this comes as a separate patch, for patch
>> maintainability. Will probably be a good idea to even split docs
>> and demo/sample code into separate patches too?   (I'm not too keen
>> on big patches doing several things)
>
> Agreed that a bit more documentation would make this patch a lot more
> useful.
>
> - From a crypto perspective I think the codes is good. I do have a few
> practicals nits though:
>
> 1) Instead of using just M_DEBUG in dmsg(), please add a log level.
> Since you are printing derived key material, I think a rather high log
> level like D_TLS_DEBUG, or perhaps D_TLS_DEBUG_MED would make sense.
>
> 2) ekm_used in struct tls_options is equivalent to (ekm_size > 0). You
> could just get rid of this extra variable.
>
> 3) tls_binding_key might not be the best env var name. That name hints
> at the use case you have in mind for this mechanisms, but it does not
> cover all use cases, nor does it easily match to the
> 'keying-material-exporter' name of the option you introduce. Something
> like 'exported_keying_material' might me more appropriate.
>
> 4) We might want to enforce a minimum length for the exported keying
> material. How about 128 bits / 16 bytes? Just to prevent a user making
> a typo from ending up with ridiculously small keys.
>
> - -Steffan
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJU7k8PAAoJEJgCyj0AftKIWBUIAJPG7+nbNS9dRbwDzOA8NpBU
> d0ueiNskJ5gGTfeUoRZwPK/wSlxPtRP0j1wKg7ltwJOvgJM7MCewI2KNxobPE/BF
> PptAzH8PU2X8YHMRhbgfcER4CyvTlg/KUW5PEieL7c1zAjq5pkQJMqTNIToq51Wo
> bUmQOEdtPuY5J3PF/06NpnKr9ZigM2FiIpx+M+GOietav8MX7a4OrGQVPnaZQo6E
> rtwCfhVTAxeaitRsWiJjuvg5tJOCqbs7uC8imjNNM6kCZzSpfJkC1nDDP6g+JAOa
> mTKgrbKS1HWYDlsE8kaSg8LLADWFix8Q2lTtGeXGUlbITtHYEE2n3DEAXqtgr4I=
> =vOYB
> -END PGP SIGNATURE-
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel


openvpn-rfc5705.patch
Description: Binary data


openvpn-rfc5705-doc.patch
Description: Binary data

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

[David Sommerseth]

-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 documentation about this, maybe 
> an extra .txt file under doc/ - I still(!) have *no* idea what this is 
> useful for, or how to use it, so right now this is "extra code complexity
> with no well-explained gain" to me.
> 
> I understand that David understands this, but we really really need to 
> have documentation understandable to non-crypto-geeks about it before it 
> can go in.

Fair enough.

Daniel, would it be possible to add some docs and possibly a very simple
tool + plugin which could be used to demonstrate this feature?  API docs
should go into the docs/ sub-folder and the demo code into
sample/sample-plugins/.

I suggest this comes as a separate patch, for patch maintainability.
Will probably be a good idea to even split docs and demo/sample code
into separate patches too?   (I'm not too keen on big patches doing
several things)


- -- 
kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlTrVUYACgkQDC186MBRfrr0jQCgjOBRc8VHLcuh9soopp5Ww+kd
3yMAnitmckErbeDYcwa44ZPFKOpdXbwq
=u30V
-END PGP SIGNATURE-

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

[Gert Doering]

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 
useful for, or how to use it, so right now this is "extra code complexity
with no well-explained gain" to me.

I understand that David understands this, but we really really need to 
have documentation understandable to non-crypto-geeks about it before it 
can go in.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpwXB0tSfb1n.pgp
Description: PGP signature