Skip to contentSkip to conversation

man: Improve token based authentication

PATCH In review David Sommerseth 4 participants 4 messages Apr 4, 2018 – Feb 6, 2019

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 man: Improve token based authentication

Be more explicit that --auth-gen-token is to be considered a workaround for authentication scripts/plug-ins not supporting --auth-token.

Also be more explicit that invalidated --auth-token values will result in the client disconnecting.

---
 doc/openvpn.8 | 32 ++++++++++++++++++++++++++++----
 1 file changed, 28 insertions(+), 4 deletions(-)
doc/openvpn.8 +28 -4
index 4114f408..b6de2c9c 100644
@@ -3671,10 +3671,25 @@ argument defines how long the generated token is valid.  The
 lifetime is defined in seconds.  If lifetime is not set
 or it is set to 0, the token will never expire.
 
-This feature is useful for environments which is configured
-to use One Time Passwords (OTP) as part of the user/password
-authentications and that authentication mechanism does not
-implement any auth\-token support.
+.B PLEASE NOTE:
+The
+.B \-\-auth\-gen\-token
+feature is to be considered a workaround for authentication
+scripts or plug\-ins not providing proper
+.B auth\-token
+support.  The
+.B auth\-token
+feature is most commonly needed when deploying two factor
+authentications, such as One Time Password (OTP) based
+authentication.  Proper authentication scripts/plug\-ins should
+implement support for generating, sending and verifying
+.B auth\-token
+values sent to successfully authenticated clients, and particularly
+when OTP authentication is required.
+
+See also
+.B \-\-auth\-token
+for more details.
 .\"*********************************************************
 .TP
 .B \-\-opt\-verify
@@ -5291,6 +5306,15 @@ OPENVPN_PLUGIN_CLIENT_CONNECT_V2 calls.  This option provides
 a possibility to replace the clients password with an authentication
 token during the lifetime of the OpenVPN client.
 
+.B BEWARE:
+Clients which has received an
+.B auth\-token
+will be using this value as the password on each renegotiation and
+reconnection to the server until it stops running.  If the server
+has invalidated the
+.B auth\-token
+since the last authentication, the client will be disconnected.
+
 Whenever the connection is renegotiated and the
 .B \-\-auth\-user\-pass\-verify
 script or
Signature · 1 line
2.16.2
#1 lore raw

Hi,

Quoted 7 lines · David Sommerseth

Be more explicit that --auth-gen-token is to be considered a workaround for authentication scripts/plug-ins not supporting --auth-token.

Also be more explicit that invalidated --auth-token values will result in the client disconnecting.

IMO, this is just muddying up waters further. To the user its still not clear when does the token get invalidated and in which of those cases is the client left in a lurch. The token gets invalidated on (i) token expiry (a broken feature) or (ii) server restart. The client can recover from the latter as it will get an auth-failed, but the former causes a disconnection from server's perspective but client gets no notice. So saying that "will result in the client disconnecting" is not helpful.

A better quick fix would be to just remove token expiry feature from the code until a proper implementation can be devised.

Selva

#2 lore raw
Quoted 20 lines · Selva Nair

Hi,

Quoted 7 lines · David Sommerseth

Be more explicit that --auth-gen-token is to be considered a workaround for authentication scripts/plug-ins not supporting --auth-token.

Also be more explicit that invalidated --auth-token values will result in the client disconnecting.

IMO, this is just muddying up waters further. To the user its still not clear when does the token get invalidated and in which of those cases is the client left in a lurch. The token gets invalidated on (i) token expiry (a broken feature) or (ii) server restart. The client can recover from the latter as it will get an auth-failed, but the former causes a disconnection from server's perspective but client gets no notice. So saying that "will result in the client disconnecting" is not helpful.

Quoted 2 lines

A better quick fix would be to just remove token expiry feature from the code until a proper implementation can be devised.

The intention to this patch is actually not directly tied to the fixes needed to the --auth-gen-token handling at all. This is just to clarify the current behaviour.

In addition, it became clearer to me that the --auth-gen-token might be perceived as a "one-stop-fix" for authentication plug-ins/scripts not supporting auth-tokens.

Further, the token expiry is an opt-in feature. It is something the authentication script/plug-in need to handle, or explicitly enabled with --auth-gen-token by providing an expiry timeout.

Arne and I have discussed his patch today, and agreed upon a path forward of fixing these issues as well and ensure that both OpenVPN 2 in client mode and OpenVPN 3 based clients all behave in a similar way. This does also not rule out that we might need to fix OpenVPN 3 as well. But consistent behaviour across versions with a reasonably good user experience is the core goal. We just need to take this carefully, step by step.

Signature · 4 lines
kind regards,

David Sommerseth
OpenVPN Inc
#3 lore raw
Quoted 14 lines

The intention to this patch is actually not directly tied to the fixes needed to the --auth-gen-token handling at all. This is just to clarify the current behaviour.

In addition, it became clearer to me that the --auth-gen-token might be perceived as a "one-stop-fix" for authentication plug-ins/scripts not supporting auth-tokens.

Further, the token expiry is an opt-in feature. It is something the authentication script/plug-in need to handle, or explicitly enabled with --auth-gen-token by providing an expiry timeout.

Quoted 8 lines

Arne and I have discussed his patch today, and agreed upon a path forward of fixing these issues as well and ensure that both OpenVPN 2 in client mode and OpenVPN 3 based clients all behave in a similar way. This does also not rule out that we might need to fix OpenVPN 3 as well. But consistent behaviour across versions with a reasonably good user experience is the core goal. We just need to take this carefully, step by step.

I think with my current new auth-token patch set, it makes auth-token a real feature instead of just a workaround. I will mark this one superseded.

Arne