Hi,
Currently OpenVPN core supports dynamic CR from console input
and the Windows OpenVPN-GUI also supports it. The following
comments are based on those implementations:
On Wed, Jun 27, 2018 at 5:56 PM, Jonathan K. Bullard
<jkbull...@gmail.com> wrote:
>
> Hi.
>
> I'm hoping to implement challenge/response ("CR") in Tunnelblick (GUI
> for OpenVPN on macOS) and have some questions after reading the
> documentation [1];
>
> 1. In Dynamic CR, does requiring a response mean that a non-empty
> response is required?
If by empty you mean the user enters an empty response so that the GUI
would have to send back
username Auth username
password Auth CRV1::state_id:: <-- empty response
it's fine. That's what would happen if the user enters just "return key"
when console prompts for a response. The Windows GUI also does the
same if the user input is empty. The authentication will likely
fail but its up to the user to enter a response or not.
>
> 2. In Dynamic CR, what is the purpose of _not_ requiring a response?
> Is it to display a message without a text input box and have the user
> only able to click "OK" or "Cancel" (and disconnect if the user clicks
> "Cancel")? Or should I display a text input box but allow the user to
> leave it empty (and send an empty "response" to the server?)
I do not know.
I suspect this feature is not used by any server-side implementations
in use. IIRC, the console prompting just ignores this flag and prompts
for a response in all cases.
In OpenVPN-GUI I decided to handle this slightly differently: we ignore the
dynamic CR request if no response is required. So, any subsequent auth
request will get treated like a normal username/pasword prompt which,
I think, is the intended behaviour. However, instead of silently ignoring it,
popping up a notification that displays the "challenge text" could be
considered.
>
>
> 3. In Dynamic CR, what is the purpose of passing the username from the
> server to the client and then back to the server? For example, am I
> supposed to display the username along with the challenge?
Here is my guess: as you might have guessed, dynamic CR is implemented
using the same logic as that of auth-user-pass prompting and associated
handshake between client and server.
step 1: auth-user-pass exchange which sets the username
of the connection at the server side, verifies password
setp 2: send a auth-failure with a specially crafted reason
step 3: repeat step 1
In step 3, the client and the server-side password verification helper
(management client auth) knows its a challenge-response, but
the core server code treats it just like a username/password
request.
Such a flow obviously requires the username to be sent a second time,
and including that in the CR handshake makes it easier for the client.
That said, the client implementation should not assume that the username
is the same string as what was sent with in the previous auth-user-pass
stage. It usually is, but the client should just echo back (after
base64 decoding etc.) what is received in the challenge string.
Although, I think, no server-side implementation would change the
username as that could break things like --username-as-common-name etc.
>
> 4. Are there any conventions about the "challenge" string? For
> example, should "\n" be interpreted as a newline?
This is not defined in the specs. In OpenVPN-GUI I just treat it as a
UTF-8 string and display in a single line text control. Embedded control
characters will not show up correctly and multiply escaped "\n" that makes
it to the GUI (after being parsed by openvpn) may display literally as "\n".
I think its fair to assume that the challenge is a "not too long", single line
text that you could display word-wrapped if necessary.
>
>
> 5. Other than not being a great workflow, is there any problem with
> displaying the static CR in a separate dialog after the
> username/password have been entered?
Apart from possibly poor UX, I see no problem with it. On Windows we
use a single dialog with three input fields (username, password and
a field labelled by the challenge text).
Selva
------------------------------------------------------------------------------
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
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
