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.
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.
Cheers,
Eric
---
Eric Thorpe
SparkLabs Developer
https://www.sparklabs.com
https://twitter.com/sparklabs
supp...@sparklabs.com
On 22/08/2020 7:12 pm, Arne Schwabe wrote:
Am 21.08.20 um 08:24 schrieb Eric Thorpe:
This allows extra INFO_PRE mesasges to be sent to a client during an
authentication stage. This may be required to send additional challenges,
or allow longer messages to be sent by breaking them up and sending in parts.
Could you describe for what feature you need this? If we are extending
the protocol for some multiline AUTH_PENDING feature, we should document
how this works etc...
Arne
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
