Sorry, I did not state the intent clearly in the request.
We wanted to use password field to pass authentication string, such as Token
string,which can be long, the user auth plug in on the sever side can validate
the token asthe part authentication step.
Acquiring a token, such as JWT, usually involves user interaction with the
token brokerservice provider. So it is better to do this on the client side.
I agreed on the following statement. To support a long password field in TLS
channels,the Buf size of 4096 is not enough in key_method_2_write. Should we
propose to
increase the buffer size further?
"Further, even a TLS_CHANNEL_BUF_SIZE of 4096 does not support a
password that long as there are other things like username, key-source,
local-options that have to fit into the buffer (see key_method_2_write). So
what's the logic behind 4096?"
Regards,Ning On Friday, March 16, 2018, 10:30:45 AM PDT, Selva Nair
<selva.n...@gmail.com> wrote:
Hi,
Apologies in advance if I'm misreading the intent of this patch.
On Fri, Mar 16, 2018 at 12:40 PM, Ning Wei via Openvpn-devel
<openvpn-devel@lists.sourceforge.net> wrote:
> Increase TLS_CHANNEL_BUF_SIZE to 4096. When the build is enabled with
> ENABLE_PKCS11, the password field can be 4096. The old size of
> TLS_CHANNEL_BUF_SIZE was 2048, which is not enough.
I do not follow the logic behind this. Sure, ENABLE_PKCS11 increases the
password buffer size to 4096, but pkcs11 password is only consumed
locally, not sent out to the remote.
Now, even if a auth-user-pass password or challenge response gets as
large as 4096 bytes, there are other places in the code that
need "fixing" to permit such long "passwords" (or response) -- e.g., it cannot
be submitted via the management as the parser expects a max line
length of 255 and word length of 255.
Further, even a TLS_CHANNEL_BUF_SIZE of 4096 does not support a
password that long as there are other things like username, key-source,
local-options that have to fit into the buffer (see key_method_2_write). So
what's the logic behind 4096?
Finally, are there any particular challenge-response framework that requires
such long responses? Even for U2F, we wouldn't need to send a response
that large. U2F registration response could get very long (still mostly under
2000 bytes), but doing U2F key registration via the authentication channel is
not a good implementation. Authentication responses are much smaller.
In short, it looks premature to increase this value before we start
supporting long responses via the management, and a real practical
need for long challenge response strings that won't fit in the current
2048 bytes (minus overhead) arise.
Selva
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
