Reply-To: openvpn-devel@lists.sourceforge.net References: <20180404121357.2126-1-davids@...515...> From: David Sommerseth Message-ID: Date: Wed, 4 Apr 2018 17:07:29 +0200 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB Subject: Re: [Openvpn-devel] [PATCH] man: Improve token based authentication List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit To: Selva Nair Cc: openvpn-devel On 04/04/18 16:24, Selva Nair wrote: > Hi, > > On Wed, Apr 4, 2018 at 8:13 AM, David Sommerseth wrote: >> Be more explicit that --auth-gen-token is to be considered a workaround >> for authentication scripts/plug-ins not supporting --auth-token. >> >> Also be more explicit that invalidated --auth-token values will result >> in the client disconnecting. >> >> Signed-off-by: David Sommerseth > > IMO, this is just muddying up waters further. To the user its still not > clear when does the token get invalidated and in which of those cases > is the client left in a lurch. The token gets invalidated on (i) token > expiry (a broken feature) or (ii) server restart. The client can > recover from the latter as it will get an auth-failed, but the former > causes a disconnection from server's perspective but client gets no > notice. So saying that "will result in the client disconnecting" is > not helpful. > > A better quick fix would be to just remove token expiry feature from > the code until a proper implementation can be devised. The intention to this patch is actually not directly tied to the fixes needed to the --auth-gen-token handling at all. This is just to clarify the current behaviour. In addition, it became clearer to me that the --auth-gen-token might be perceived as a "one-stop-fix" for authentication plug-ins/scripts not supporting auth-tokens. Further, the token expiry is an opt-in feature. It is something the authentication script/plug-in need to handle, or explicitly enabled with --auth-gen-token by providing an expiry timeout. Arne and I have discussed his patch today, and agreed upon a path forward of fixing these issues as well and ensure that both OpenVPN 2 in client mode and OpenVPN 3 based clients all behave in a similar way. This does also not rule out that we might need to fix OpenVPN 3 as well. But consistent behaviour across versions with a reasonably good user experience is the core goal. We just need to take this carefully, step by step. -- kind regards, David Sommerseth OpenVPN Inc