[Openvpn-users] Clarification on auth-gen-token and 2FA

[Scott Crooks]

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.

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` ?

Thank you all!

--
Scott Crooks (王虎)
LinkedIn: http://www.linkedin.com/in/jshcrooks

[Gert Doering]

Hi,

Post by Scott Crooks
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` ?

As far as I understand (and I have not found time to actually *test* this
new stuff for my own setups), you need to remove "auth-nocache".

The token sent from the server effectively "un-caches" the username and
password set by the user anyway, replacing it with the token.

I'm not totally sure what happens when the token expires and the
next renegotiation is due - will the client prompt, or just give up
and disconnect. Definitely worth a test.

gert

[David Sommerseth]

Post by Scott Crooks
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.
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
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.

Post by Scott Crooks
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

[Gert Doering]

Hi,

Post by David Sommerseth
Anyhow ... quick-fix/workaround: Don't use --auth-nocache

What happens if you have --auth-nocache, the server sends a token, and
the token expires? Will the client get something back that it can
understand as "oh, I need to ask for a new password!"?

(Sorry, I know I *should* have tested this long ago... :-) )

gert

[David Sommerseth]

Post by Gert Doering
Hi,

Post by David Sommerseth
Anyhow ... quick-fix/workaround: Don't use --auth-nocache

What happens if you have --auth-nocache, the server sends a token, and
the token expires? Will the client get something back that it can
understand as "oh, I need to ask for a new password!"?
(Sorry, I know I *should* have tested this long ago... :-) )

The when --auth-nocache is in use, the contents of password field in
struct user_pass is wiped and later ignored, regardless if the server
sent an --auth-token or not.


--
kind regards,

David Sommerseth

[Gert Doering]

Hi,

Post by David Sommerseth

Post by Gert Doering

Post by David Sommerseth
Anyhow ... quick-fix/workaround: Don't use --auth-nocache

What happens if you have --auth-nocache, the server sends a token, and
the token expires? Will the client get something back that it can
understand as "oh, I need to ask for a new password!"?
(Sorry, I know I *should* have tested this long ago... :-) )

The when --auth-nocache is in use, the contents of password field in
struct user_pass is wiped and later ignored, regardless if the server
sent an --auth-token or not.

Uh. My question did not make sense. Trying again:

What happens if you do NOT have --auth-nocache, the server sends a token,
and the token expires? Will the client get something back that it can
understand as "oh, I need to ask for a new password!"?

gert

[David Sommerseth]

Post by Gert Doering
Hi,

Post by David Sommerseth

Post by Gert Doering

Post by David Sommerseth
Anyhow ... quick-fix/workaround: Don't use --auth-nocache

What happens if you have --auth-nocache, the server sends a token, and
the token expires? Will the client get something back that it can
understand as "oh, I need to ask for a new password!"?
(Sorry, I know I *should* have tested this long ago... :-) )

The when --auth-nocache is in use, the contents of password field in
struct user_pass is wiped and later ignored, regardless if the server
sent an --auth-token or not.

What happens if you do NOT have --auth-nocache, the server sends a token,
and the token expires? Will the client get something back that it can
understand as "oh, I need to ask for a new password!"?

Ahh! Currently, the client will disconnect due to authentication failure.

This is not optimal, and definitely not how I like it! But to fix that,
a massive code refactoring is needed so that the AUTH_FAILED message
needed to be sent with the proper "sub-code" which can be used on the
client to ask for credentials again. I have already sent some patches
to the devel ML, but those need to be improved a lot before getting
ready for inclusion.

On the other hand, this is not a very new issue actually. If external
auth-plugins rejects an authentication, it is the same situation.