Hi Arne,
The first we are trying to migrate across is U2F -
https://www.sparklabs.com/support/kb/article/yubikey-u2f-two-factor-authentication-with-openvpn-and-viscosity/
<https://www.sparklabs.com/support/kb/article/yubikey-u2f-two-factor-authentication-with-openvpn-and-viscosity/>
Even though the patches in the above article work for the vast majority,
they are a bit of a hack and we want to get away from them as they're
still prone to failing on connections with low MTU or fragmentation
issues as previously mentioned.
All our 2FA supported methods that we want to migrate across to
AUTH_PENDING instead of AUTH_FAILED are available here as well if you'd
like some further examples of what this would be used for -
https://github.com/thesparklabs/openvpn-two-factor-extensions
<https://github.com/thesparklabs/openvpn-two-factor-extensions>
Anything using this new method would also end up in the above repo.
Regards,
Eric
---
Eric Thorpe
SparkLabs Developer
https://www.sparklabs.com
https://twitter.com/sparklabs
supp...@sparklabs.com
On 26/08/2020 6:55 pm, Arne Schwabe wrote:
Am 26.08.20 um 03:15 schrieb Eric Thorpe:
Hi Arne,
I'm happy to resubmit the patch with further documentation to what I
have already included with this patch, however I need to know what is
likely to be accepted.
Per my previous question and example, is it acceptable to keep using
CR_TEXT and document the C and CR flags, or, as I think you have hinted,
would you prefer I create a fourth INFOPRE spec, for example CR_DATA,
and document that instead?
Maybe. I am not against the idea of allowing more authentication
methods. But I am not sure what you are trying to achieve.
It would also be highly appreciated if I could get some indication if
this patch is acceptable outside of the requirement for further
documentation or if the code needs further changes.
Currently I don't understand what authentication method you are trying
to implement. It is frustrating for me that you avoid that question.
For accepting it is very simple. Either is something everyone using
OpenVPN can implement and understand and you are willing to share with
OpenVPN. Then the patches can go. If it a special private authentication
method and you don't want to share that, then your patches can also be
kept private and applied your own branch/client/server.
Arne
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
