| Message ID | 20190613144113.6418-1-arne@rfc2549.org |
|---|---|
| Headers | show |
| Series | Implement additional two step authentication methods | expand |
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