non-interactive auth-user-pass mode with dummy data

[andreas-p]

To use an external auth solution, my vpn server is configured with management-client-auth and the clients have user-auth-pass. using the oauth2 management client from https://github.com/jkroepke/openvpn-auth-oauth2, I can authenticate using my oauth2 IDP. But auth-user-pass has one disadvantage: it will force the client to ask for username/password, which are never examined with oauth2 (and probably other management clients).
Many clients can store name/password, and will never ask again for that useless input. Unfortunately, openvpn3 is explicitely designed differently, making it hard to have name/password provided automatically.

Thus I propose to invent a new option to openvpn3, which will leave the auth-user-pass client-server communication intact, but not ask for name/password, instead stuffing some random or null dummy data just to make the protocol happy.

[dsommers]

This sounds like the wrong approach to me.

OpenVPN 2.6 and OpenVPN 3 Linux should support more ways of deferred authentication. The client can get an "authentication failure" with a request for further authentication; known as the dynamic challenge protocol. I don't have a perfect example to provide, but I believe it should be possible to test and build a test case out of the sample/sample-scripts/totpauth.py example.

So if the plug-in you use could be extended to support this approach, this should be possible to be done without modifying OpenVPN at all.

[andreas-p]

@dsommers AFAICS the scripts are called after common_name is set, i.e. username has already been retrieved.

[schwabe]

@andreas-p you are mixing here some short coming of the OpenVPN server impelmentation with the protocol itself. The protoocl itself will already use empty user and empty password to indicate that no user/password has been provided.

I am not sure what providing some random username/password will accomplish here that gets ignored on the server anyway. And providing null data is just what the protocol already does when you do not have the auth-user-pass option in your config.

@andreas-p common_name is not the same as username. common name comes from the certificate. There is an option username-as-common-name for OpenVPN 2.x but these two are two different things.

[andreas-p]

@schwabe With "protocol" mentioned in the first post I meant not the OpenVPN-Protocol itself, but the user/passwd handling of openvpn3 itself.
To make my statement more precise:
I believe that deferred auth (from scripts or webauthn or so) is always performed after any normal auth, certificate and/or username/password, right? Which means I can't suppress the password by script.

[schwabe]

Yeah you have to precoinfigure if you want to ask username/password or not by adding or not adding auth-user-pass in the client config. I am not sure what problem you are trying to solve here on the client side.

[dsommers]

So just to conclude here.

• The auth-user-pass option in the client configuration will request the client to ask for user credentials before connecting. This option may not be needed in all configurations
• When the client connects to the server, the first part of the authentication is the client certificate. Username/password/2FA credentials are checked after certificate checks. Unless client certificates checks are disabled (server side configuration, see the --verify-client-cert option in the man page for details). Client configuration does not need to have certificate/key configured.
• The server side may in addition reject a connection from being established, if authentication did not pass. The server may send a request back to the client to provide a specific credential.
• How the server side responds in the "authenticate username/password" phase when this information is missing is entirely up to the authentication script or plug-in. OpenVPN itself does not do anything in regards to the authentication itself, it passes the credentials to the script/plug-in and responds to the OpenVPN client based on the result of the script/plug-in.

Is something unclear here?

I'm converting this issue to a discussion, as this does not look like an issue OpenVPN 3 Linux need to solve programmatically.