Server --auth-gen-token and client --auth-nocache do not work together

[tct]

If a server pushes an auth-token to a client using auth-nocache the client does not cache the token. Thus renegotiating a connection after --reneg-sec/bytes/pkts causes client to drop the current connection and request password from user.

Currently the fix is: do not use --auth-nocache in client config.

More information:
​https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg03511.html

[David Sommerseth]

Just documenting some test scenarios which must pass for a patch to be considered for inclusion.

Preparations

You need a simple authentication script. The example below should be sufficient:

#!/bin/bash
if [ "$password" = "pass123" ]; then
	echo "**** AUTH SUCCESSFUL"
	exit 0;
fi
echo "!!!!! AUTH FAILED: $password"
exit 1

Save this file and ensure it is executable.

The rest of the test scenarios expects a local git clone of the upstream source repositories.

Test 1: Default authentication

This is the simplest and probably most common script based authentication setups. The server will trigger a re-negotiation of the tunnel every 30th second.

Server: src/openvpn/openvpn --dev tun --server 10.8.0.0 255.255.255.0 --ca sample/sample-keys/ca.crt --key sample/sample-keys/server.key --cert sample/sample-keys/server.crt --dh sample/sample-keys/dh2048.pem --script-security 3 --auth-user-pass-verify auth.sh via-env --verb 4 --reneg-sec 30

Client: src/openvpn/openvpn --client --remote 192.168.122.1 --ca openvpn/sample/sample-keys/ca.crt --key openvpn/sample/sample-keys/client.key --cert openvpn/sample/sample-keys/client.crt --verb 4 --dev tun --auth-user-pass --ping 3 --ping-restart 6

Expected results

Using 'pass123' as the password, the connection should be established and renegotiated automatically at least every 30th second. When renegotiation happens, the client should continue to run as before. Any other passwords should fail.

Test 2: Default authentication with no cached password

Basically the same setup as Test 1, but this time the client will not cache the user's password.

Server: src/openvpn/openvpn --dev tun --server 10.8.0.0 255.255.255.0 --ca sample/sample-keys/ca.crt --key sample/sample-keys/server.key --cert sample/sample-keys/server.crt --dh sample/sample-keys/dh2048.pem --script-security 3 --auth-user-pass-verify auth.sh via-env --verb 4 --reneg-sec 30

Client: src/openvpn/openvpn --client --remote 192.168.122.1 --ca openvpn/sample/sample-keys/ca.crt --key openvpn/sample/sample-keys/client.key --cert openvpn/sample/sample-keys/client.crt --verb 4 --dev tun --auth-user-pass --ping 3 --ping-restart 6 --auth-nocache

Change from Test1: Client have added --auth-nocache

Expected results

Using 'pass123' as the password, the connection should be established and renegotiated automatically at least every 30th second. When renegotiation happens, the client will ask for username/password again. Using any other password should fail.

Test 3: Token based authentication

This is a variant of Test 1, where the user sends username/password as normal. The server sends an authentication token back to the client which replaces the locally cached password. This token is used on the following renegotiations.

Server: src/openvpn/openvpn --dev tun --server 10.8.0.0 255.255.255.0 --ca sample/sample-keys/ca.crt --key sample/sample-keys/server.key --cert sample/sample-keys/server.crt --dh sample/sample-keys/dh2048.pem --script-security 3 --auth-user-pass-verify auth.sh via-env --verb 4 --reneg-sec 30 --auth-gen-token

Client: src/openvpn/openvpn --client --remote 192.168.122.1 --ca openvpn/sample/sample-keys/ca.crt --key openvpn/sample/sample-keys/client.key --cert openvpn/sample/sample-keys/client.crt --verb 7 --dev tun --auth-user-pass --ping 3 --ping-restart 6

Change from Test 1: Server have added --auth-gen-token. Client have increased logging to --verb 7.

Expected results

Using 'pass123' as the password, any other passwords should fail. The server should send a PUSH_REPLY containing 'auth-token' with a random token. This should be seen in the client log. The connection should be established and renegotiated automatically at least every 30th second, but using the token instead of the password. The auth.sh script will only be called once. When renegotiation happens, the client should continue to run as before.

Sub-test 3A

Stop the server process while the client is connected and restart it with the same arguments. The client should reconnect but authentication should fail due to incorrect password (which is reported by the script)

Test 4: Token based authentication with --auth-nocache

This is a variant of Test 3, where the user sends username/password as normal. The server sends an authentication token back to the client which replaces the locally cached password. This token is used on the following renegotiations. But the client is configured to not cache any passwords - which should be overridden when the server sends the PUSH_REPLY containing an auth-token.

Server: src/openvpn/openvpn --dev tun --server 10.8.0.0 255.255.255.0 --ca sample/sample-keys/ca.crt --key sample/sample-keys/server.key --cert sample/sample-keys/server.crt --dh sample/sample-keys/dh2048.pem --script-security 3 --auth-user-pass-verify auth.sh via-env --verb 4 --reneg-sec 30 --auth-gen-token

Client: src/openvpn/openvpn --client --remote 192.168.122.1 --ca openvpn/sample/sample-keys/ca.crt --key openvpn/sample/sample-keys/client.key --cert openvpn/sample/sample-keys/client.crt --verb 4 --dev tun --auth-user-pass --ping 3 --ping-restart 6 --auth-nocache

Change from Test 3: Client have decreased logging to --verb 4 and added --auth-nocache

Expected results

Using 'pass123' as the password, any other passwords should fail. The server should send a PUSH_REPLY containing 'auth-token' with a random token. The connection should be established and renegotiated automatically at least every 30th second, but using the token instead of the password. The auth.sh script will only be called once. When renegotiation happens, the client should continue to run as before.

Sub-test 4A

Stop the server process while the client is connected and restart it with the same arguments. The client should reconnect but authentication should fail due to incorrect password (which is reported by the script)

Test 5: Token based authentication where the script generates the token

Reuse Test 3 but the auth.sh script must be modified to generate an authentication token and save that in a dynamically generated CCD file as a push "auth-token $value" line. The server configuration needs to remove --auth-gen-token. The generated token value should also be accepted as a valid password.

Expected results

The test should have the same results as Test 3, with the exception that the auth.sh script is called on every re-negotiation. The initial password should change to the generated auth-token on all the re-negotiations.

Test 6: Token based authentication where the script generates the token with --auth-nocache

Reuse Test 4, but the auth.sh script from Test 5. The server configuration needs to remove --auth-gen-token. The client needs to add --auth-nocache.

Expected results

The test should have the same results as Test 4, with the exception that the auth.sh script is called on every re-negotiation. The initial password should change to the generated auth-token on all the re-negotiations.

[tct]

​https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21291.html

[Gert Döring]

Can we revisit this for 2.6.0 and either close it or fix whatever is still open?

From my user reports, recent 2.4.x and all 2.5.y seem to behave correctly in regards to --auth-nocache and server-pushed --auth-token.

There were a number of interesting bugs in early 2.4, like the client accepting the *first* token, and then only ever sending that one to the server, never accepting subsequent tokens - but Arne fixed everything I found :-)

[tct]

I have only tested the original issue.

Server setup to use --auth-gen-token, client setup with --auth-nocache [2.6_rc1]

The client uses the token for a successful renegotiation @ --reneg-sec interval.

[tct]

After careful review of David's requirements, I believe this issue is completed.

This server log shows the client auth-token validation @reneg-sec:

2023-01-01 16:25:17 us=841642 CLIENT-01/10.1.101.21:61725 TLS: soft reset sec=180/180 bytes=876/-1 pkts=23/0
2023-01-01 16:25:17 us=918133 CLIENT-01/10.1.101.21:61725 VERIFY OK: depth=1, C=00, ST=home, L=wiscii glaß, O=tct, OU=tct @ $&$, CN=Easy-RSA CA, emailAddress=me@example.net, serialNumber=.
2023-01-01 16:25:17 us=921335 CLIENT-01/10.1.101.21:61725 VERIFY OK: depth=0, C=00, ST=home, L=wiscii glaß, O=tct, OU=tct @ $&$, CN=CLIENT-01, emailAddress=me@example.net, serialNumber=.
2023-01-01 16:25:17 us=923525 CLIENT-01/10.1.101.21:61725 peer info: IV_VER=2.6_rc1
2023-01-01 16:25:17 us=923558 CLIENT-01/10.1.101.21:61725 peer info: IV_PLAT=win
2023-01-01 16:25:17 us=923586 CLIENT-01/10.1.101.21:61725 peer info: IV_TCPNL=1
2023-01-01 16:25:17 us=923614 CLIENT-01/10.1.101.21:61725 peer info: IV_MTU=1600
2023-01-01 16:25:17 us=923644 CLIENT-01/10.1.101.21:61725 peer info: IV_NCP=2
2023-01-01 16:25:17 us=923674 CLIENT-01/10.1.101.21:61725 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM
2023-01-01 16:25:17 us=923704 CLIENT-01/10.1.101.21:61725 peer info: IV_PROTO=478
2023-01-01 16:25:17 us=923733 CLIENT-01/10.1.101.21:61725 peer info: IV_LZO_STUB=1
2023-01-01 16:25:17 us=923762 CLIENT-01/10.1.101.21:61725 peer info: IV_COMP_STUB=1
2023-01-01 16:25:17 us=923791 CLIENT-01/10.1.101.21:61725 peer info: IV_COMP_STUBv2=1
2023-01-01 16:25:17 us=923820 CLIENT-01/10.1.101.21:61725 peer info: IV_GUI_VER=OpenVPN_GUI_11
2023-01-01 16:25:17 us=923851 CLIENT-01/10.1.101.21:61725 peer info: IV_SSO=openurl,webauth,crtext
2023-01-01 16:25:17 us=923915 CLIENT-01/10.1.101.21:61725 TLS: Username/auth-token authentication succeeded for username 'dan10'
2023-01-01 16:25:17 us=923987 CLIENT-01/10.1.101.21:61725 TLS: Username/Password authentication succeeded for username 'dan10' 
2023-01-01 16:25:17 us=924039 CLIENT-01/10.1.101.21:61725 SENT CONTROL [CLIENT-01]: 'PUSH_REPLY, auth-tokenSESS_ID' (status=1)
2023-01-01 16:25:17 us=924240 CLIENT-01/10.1.101.21:61725 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2023-01-01 16:25:17 us=924272 CLIENT-01/10.1.101.21:61725 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2023-01-01 16:25:17 us=926112 CLIENT-01/10.1.101.21:61725 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 456 bit ED448, signature: ED448
2023-01-01 16:28:17 us=395995 CLIENT-01/10.1.101.21:61725 TLS: soft reset sec=180/180 bytes=6078/-1 pkts=79/0

Not sure if token and password verification is correct ?

Follow-up: ​https://github.com/OpenVPN/openvpn/issues/212