Hi,
On Wed, Mar 7, 2018 at 6:52 PM, David Sommerseth
wrote:
> On 08/03/18 00:22, Selva Nair wrote:
>> Hi,
>>
>> ...some good stuff snipped...
>>
>>>
>>> I'll admit I might see this with a bit too narrow perspective. But how I
>>> have
>>> understood this
On 08/03/18 00:22, Selva Nair wrote:
> Hi,
>
> ...some good stuff snipped...
>
>>
>> I'll admit I might see this with a bit too narrow perspective. But how I
>> have
>> understood this issue is that OpenVPN 2.x does not behave correctly as it
>> doesn't understand *why* the authentication
Hi,
...some good stuff snipped...
>
> I'll admit I might see this with a bit too narrow perspective. But how I have
> understood this issue is that OpenVPN 2.x does not behave correctly as it
> doesn't understand *why* the authentication failed. If the client side would
> understand why auth
A bit more thorough review this time.
On 05/03/18 16:50, Arne Schwabe wrote:
[...snip...]
>
> This patch changes the client behaviour:
>
> - Treat a failed auth when using an auth-token as a soft error (USR1)
> and clean the auth-token falling back to the original auth method
Conceptually,
On 07/03/18 12:52, Arne Schwabe wrote:
>> So, failure due to token expiry that normally happens during a reneg[*]
>> will not trigger AUTH_FAILED and the client will continue trying reneg
>> until the previous TLS session expires (1 hour?). This is a
>> basic limitation of the present
Hi,
On Wed, Mar 7, 2018 at 6:52 AM, Arne Schwabe wrote:
> Am 06.03.18 um 22:04 schrieb Selva Nair:
>
..
>> I want to stress this point: when the server sends back AUTH_FAILED,
>> the client does behave somewhat sanely, but not otherwise. And on that
>> count this patch
Am 06.03.18 um 22:04 schrieb Selva Nair:
> Hi,
>
> Based on the commit message this appears to cover all that is wrong
> with current auth-token implementation. I haven't carefully reviewed the
> code or tested it, but some initial remarks that looks relevant.
>
> On Mon, Mar 5, 2018 at 10:50
Hi,
Based on the commit message this appears to cover all that is wrong
with current auth-token implementation. I haven't carefully reviewed the
code or tested it, but some initial remarks that looks relevant.
On Mon, Mar 5, 2018 at 10:50 AM, Arne Schwabe wrote:
> Auth-token
Auth-token is documented as a token that the client will use instead
of a auth-token. When using an external auth-token script and OTP
authentication, it is useful to have this token survive on reconnect
(e.g. mobile device roaming). On the other hand if the token does
expire, the client should