[Openvpn-devel,0/5] Implement additional two step authentication methods

  These patches mainly implement forwarding passing/forwarding extra
messages between management interface on server and client side.

These new extra messages can be used to implement a two step
authentication like TOTP (Google Authenticator) or web based
out of band (like SAML).

Since this requires a tight integration on both client and
server side, it is currently only supported with the management
interface.

Arne Schwabe (5):
  Implement parsing and sending INFO and INFO_PRE control messages
  Implement forwarding client CR_RESPONSE messages to management
  Implement support for signalling IV_SSO to server
  Implement sending response to challenge via CR_RESPONSE
  Implement sending SSO challenge to clients

 doc/management-notes.txt |  74 ++++++++++++++++++++++++++++
 src/openvpn/forward.c    |  12 +++++
 src/openvpn/init.c       |  25 ++++++++++
 src/openvpn/manage.c     | 101 ++++++++++++++++++++++++++++++++++++++-
 src/openvpn/manage.h     |   8 ++++
 src/openvpn/multi.c      |  19 ++++++++
 src/openvpn/push.c       |  78 ++++++++++++++++++++++++++++++
 src/openvpn/push.h       |   7 +++
 src/openvpn/ssl.c        |   4 +-
 9 files changed, 325 insertions(+), 3 deletions(-)
  

Hi

On Thu, Jun 13, 2019 at 10:42 AM Arne Schwabe <arne@rfc2549.org> wrote:
>
> These patches mainly implement forwarding passing/forwarding extra
> messages between management interface on server and client side.
>
> These new extra messages can be used to implement a two step
> authentication like TOTP (Google Authenticator) or web based
> out of band (like SAML).
>
> Since this requires a tight integration on both client and
> server side, it is currently only supported with the management
> interface.
>
> Arne Schwabe (5):
>   Implement parsing and sending INFO and INFO_PRE control messages
>   Implement forwarding client CR_RESPONSE messages to management
>   Implement support for signalling IV_SSO to server
>   Implement sending response to challenge via CR_RESPONSE
>   Implement sending SSO challenge to clients

I haven't looked at the patches, but a quick question. I haven't come across any
2FA mechanisms that cannot be handled (in principle) by the current static an
dynamic CR in OpenVPN. Except that some dynamic CR (e.g, U2F) will require
the possibility to transmit larger messages than currently possible --
especially
the 256 byte limitation in responses from the management as those are
parsed by the config-parser. And possibly the TLS channel buffer size may need
to be increased.

Once those limits are extended, do we need anything more?

You mention google-authenticator OTP but that can perfectly handled as a static
challenge as many do right now.

The current dynamic response implementation is a bad hack -- fail the auth
with challenge embedded in the reason text and then send the response as a
"password" during the next round. So is this about making a cleaner
implementation? Or am I missing something more subtle?

Selva
  

Hi,

On Thu, Jun 13, 2019 at 2:35 PM Selva Nair <selva.nair@gmail.com> wrote:
>
> Hi
>
> On Thu, Jun 13, 2019 at 10:42 AM Arne Schwabe <arne@rfc2549.org> wrote:
> >
> > These patches mainly implement forwarding passing/forwarding extra
> > messages between management interface on server and client side.
> >
> > These new extra messages can be used to implement a two step
> > authentication like TOTP (Google Authenticator) or web based
> > out of band (like SAML).
> >
> > Since this requires a tight integration on both client and
> > server side, it is currently only supported with the management
> > interface.
> >
> > Arne Schwabe (5):
> >   Implement parsing and sending INFO and INFO_PRE control messages
> >   Implement forwarding client CR_RESPONSE messages to management
> >   Implement support for signalling IV_SSO to server
> >   Implement sending response to challenge via CR_RESPONSE
> >   Implement sending SSO challenge to clients
>
> I haven't looked at the patches, but a quick question. I haven't come across any
> 2FA mechanisms that cannot be handled (in principle) by the current static an
> dynamic CR in OpenVPN.

+1. What functionality does this new mechanism add?

Tunnelblick implements 2FA through the management interface using the
existing static and dynamic challenge-response mechanism. For a
dynamic challenge, for example. Tunnelblick gets a response from the user in
a popup window or from a user-specified script. (A script is usually
used to get the response from hardware devices.)

Best regards,

Jon Bullard
  

> I haven't looked at the patches, but a quick question. I haven't come across any
> 2FA mechanisms that cannot be handled (in principle) by the current static an
> dynamic CR in OpenVPN. Except that some dynamic CR (e.g, U2F) will require
> the possibility to transmit larger messages than currently possible --
> especially
> the 256 byte limitation in responses from the management as those are
> parsed by the config-parser. And possibly the TLS channel buffer size may need
> to be increased.
> 
> Once those limits are extended, do we need anything more?
> 
> You mention google-authenticator OTP but that can perfectly handled as a static
> challenge as many do right now.
> 
> The current dynamic response implementation is a bad hack -- fail the auth
> with challenge embedded in the reason text and then send the response as a
> "password" during the next round. So is this about making a cleaner
> implementation? Or am I missing something more subtle?


Two things basically that play to together making it cleaner and allow
web based authentication to actually not a horrible hack. WEB based SSO
would work as follows:

- Clients connects
- Server get the client auth request.

- Instead of sending success/failed right way, it will send a challenge
   - OPENURL:example.com/logintomyvpn

- Client will continue to wait in this not yet authenticated state

- User will login into the web page, the backend of the web notifies the
VPN server about the result

- VPN will send do client auth succces/failed depending on result

- Client is connected.

Arne
  

> 
> +1. What functionality does this new mechanism add?
> 
> Tunnelblick implements 2FA through the management interface using the
> existing static and dynamic challenge-response mechanism. For a
> dynamic challenge, for example. Tunnelblick gets a response from the user in
> a popup window or from a user-specified script. (A script is usually
> used to get the response from hardware devices.)
> 


It adds 2FA without reconnect dance and also the ability to do something
like web based SSO authentication. But a server should not use these
unless your client will announce support for them via IV_SSO variable.

The v2 version of the patch will describe the IV_SSO variable too.

Arne