Am 24.08.20 um 09:59 schrieb Eric Thorpe: > Hi Arne, > > The main scenario this addresses is 2FA authentication which needs to > transmit very long responses such as those requiring keys. In these > cases, the responses can be upwards of 1500 bytes. Management is > restricted (currently) to 256 bytes and the control channel I believe to > 1024, however the larger problem is low MTU connections or poorly > configured connection with fragmentation problems would refuse to > transmit packets of this size over the control channel, so we need the > ability to break these up. > > At the moment I'm experimenting with the following layout which has > shown success: > > client-auth-pending <CID> CR_TEXT:R,C:2 > client-auth-pending-extra <CID> CR_TEXT:CN,1:<data> > client-auth-pending-extra <CID> CR_TEXT:CN,2:<data> > > Where flag C=Chunked data and 2 is the number of chunks to expect. Then > CN,<chunk number>:<data>. > > The other issue this addresses is there are scenario where more than one > challenge reply is required. A simple example of this is resident key > registration, where the username is pulled from the clients certificate, > a password is queried, then attestation is queried, and then > authentication is queried.
Depends on if these should asked sequentially, the you just send another CR_TEXT challenge after the first is answer or in parallel. > client-auth-pending-extra is a bit of a catch-all addition where it > effectively opens up the client-auth-pending spec to allow the control > channel to be used without having to constantly drop the connection like > the current AUTH_DENY method pre-2.5, but without spamming the user with > AUTH_PENDING notifications, and allows a connected management script to > handle it without adding further complexity internally to OpenVPN. CR_TEXT is challenge response text and those clients that currently implement it only allow a single line. I would suggest the following to get the patch in a acceptable state: - Document your authentication method also in management.txt and also what IV_SSO flag indicates this authentication method. - to avoid the 256 byte management limit and multiple commands use maybe the same approach as client-auth that allows a longer frame, you can still limit that to 1024. Otherwise I think this the right direction. Arne
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
