On Thu, Aug 25, 2016 at 11:36 AM, David Sommerseth <openvpn@sf.lists. topphemmelig.net> wrote:
> > On 25/08/16 16:32, Selva Nair wrote: > > > > On Thu, Aug 25, 2016 at 10:15 AM, David Sommerseth > > <open...@sf.lists.topphemmelig.net > > <mailto:open...@sf.lists.topphemmelig.net>> wrote: > > > > On 25/08/16 15:58, David Woodhouse wrote: > >> On Thu, 2016-08-25 at 15:45 +0200, David Sommerseth wrote: > >>> > >>> > >>> I've been working a bit on a new patch-set which enables > >>> third-party user/password authentication mechanisms using two > >>> factor authentications [2FA] (such as OTP) and not needing to > >>> disable the renegotiation features of OpenVPN. > >> > >> Hm, you handle the server side of OTP through PAM alone? > > > > This change does not change the initial authentication at all. > > You still need an authentication plug-in or > > --auth-user-pass-verify script. But once this first authentication > > passes successfully, the OpenVPN server takes over the coming > > authentications required due to re-negotiations. > > > > > > Why not let the auth-user-pass-verify script do this verification > > bypass? The server knows whether its an initial CONNECT or REAUTH > > and can pass that info to the verify script. Then the script can > > bypass verification if appropriate. Currently > > management-client-auth is already capable of doing this as "REAUTH" > > versus "CONNECT" info is passed to it. Adding that to the env and > > passing to scripts should be easy. > > This is to avoid needing to modify any third-party authentication > mechanisms. But passing information that it is a re-auth is might be > a good idea, that isn't too hard to add. > > However, it would need to be a flag to --auth-gen-token in addition - > otherwise third party authentication mechanisms which have not been > updated will fail. On the other hand, if anyone is willing to update > an auth-plugin or script to support this, they could just as well > implement the auth-token generation themselves independently and not > require --auth-gen-token at all; which speaks against such a flag. > > Also remember that this implementation covers both --plugin and > - --auth-user-pass-verify. For many it will be quite hard to modify a > plug-in compared to updating a script. > > I'll grant that the 'auth-token' feature is a well hidden and not > documented. But the issue with 2FA and --reneg-* options have been a > long standing issue, which have not been fixed in most of the > authentication plug-ins used by the community. > > In regards to documentation, I'll try to improve that as well - > regardless of this patch-set. And there's another benefit if making > use of this auth-token feature itself, as the client doesn't need to > cache the users password any more. (I do need to verify that though, > but there is no reason why it would be needed.) > I was not aware of this auth-token feature. Just scanned through the implementation: looks like a good way of handling user-auth during reneg. And possibly safer than just distinguishing reauth vs connect in the script. As is, it could be used from a verify-script or a management-client-auth script by setting the token at first connect and verifying it (instead of username/password) during reauth. Agreed, an option for the server itself to generate the token would be a good addition. And yes, the token could be made the default user-auth mechanism during reneg regardless of 2FA is in use or not. As for caching, either the token will have to be cached unless management is in use in which case the UI/GUI can remember the token and supply it during reneg. Selva
------------------------------------------------------------------------------
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
