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

Message ID 20190613144113.6418-1-arne@rfc2549.org
Headers show
Series
  • Implement additional two step authentication methods
Related show

Message

Arne Schwabe June 13, 2019, 2:41 p.m.
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(-)

Comments

Selva Nair June 13, 2019, 6:34 p.m. | #1
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
Jonathan K. Bullard June 13, 2019, 8:05 p.m. | #2
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
Arne Schwabe June 14, 2019, 9:25 a.m. | #3
> 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