On 25/01/17 21:28, Scott Crooks wrote:
> Greetings everyone,
> I'm doing some testing with moving our current OpenVPN solution to 2.4
> to utilize the benefits of the `auth-gen-token` parameter that was
> recently introduced. I'm a little confused about how it works in
> relation to the `reneg-sec` variable. We're using the free Authy OpenVPN
> plugin (https://github.com/authy/authy-openvpn) for 2FA.
> Our authentication follows the following chain:
> 1. User must present valid client certificate (duplicate-cn in our case)
> 2. User must present valid Authy token from their mobile device / browser
> 3. User must present valid login credentials that are validated against
> our LDAP backend
> Authy's documentation specifically says to set `reneg-sec` equal to '0'
> so that renegotiation never happens; however, this was written with
> OpenVPN 2.3 in mind. My questions are:
> 1. Since `auth-gen-token X` generates a token valid for X seconds, does
> this mean I can turn renegotiation back on? From initial testing
> (OpenVPN 2.4 on Windows 10), I set `reneg-sec` to something low (30
> seconds) to see what happened. The user is again presented with a
> password prompt, which shouldn't happen.

Correct, this should NOT happen.

> 2. Does having `auth-nocache` on the client side conflict with
> `auth-gen-token` ? Do I need to remove `auth-nocache` from the client
> side to utilize the benefits of `auth-gen-token` ?

Yes, this is a bug I detected very late in the RC releases.  I tried to
fix it, but first attempts exploded in my face.  And haven't had time to
dig into this further.

When --auth-gen-token is enabled, the server pushes --auth-token with
some random credential it saves for this particular session.  When the
client receives --auth-token push-reply, it replaces the current
password value in the user/password storage with the token value.  On
next re-authentication, the client will then send username + token value
(instead of password with expired OTP).  The server then matches this
token ("password") against the locally stored token in the session object.

What happens is that when --auth-nocache is used, it basically tells the
"retrieve user credentials function" to ignore whatever is stored in the
password field (where the token now resides) in the user/password
storage.  And since it realises it doesn't have a password, it asks for
it again.

This is very basically what happens.  And the fix is in theory very
simple (disable --auth-nocache if server have pushed --auth-token) - but
those places I tried to disable --auth-nocache didn't work or it made
things even worse in some cases (where --auth-token was not pushed).

So I have it on my TODO list ... now that people actually do test the
--auth-gen-token feature, I'm definitely going to look into it a bit sooner.

Anyhow ... quick-fix/workaround: Don't use --auth-nocache

kind regards,

David Sommerseth

Attachment: signature.asc
Description: OpenPGP digital signature

Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Openvpn-users mailing list

Reply via email to