Date: Mon, 26 Mar 2018 16:36:44 +0000 (UTC) From: Ning Wei Message-ID: <2645433.792870.1522082204205@...2084...> In-Reply-To: References: <20180316164059.9120-1-xiaoningning@...109...> <1783935013.3421880.1521493221569@...2084...> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_792869_301385780.1522082204203" Subject: Re: [Openvpn-devel] [PATCH] Increase TLS Control Channel Buffer Size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Selva Nair Cc: openvpn-devel ------=_Part_792869_301385780.1522082204203 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Both of key_method_2_write and key_method_2_read take TLS_Channel_Bug_Size= as buffer size.=C2=A0 The current size, 2048 is not enough to read/write a= long password response.=C2=A0 I have notice the management interface has a= much smaller than 2048 buffer size to read/write.=C2=A0 Currently, if the = management interface is not used, increasing tls channel buffer size will s= erve the need. As token provider, the size of token can be bigger or smaller.=C2=A0 Someti= me, it has more than 1600 as a token.=C2=A0 To accommodate that, a bigger b= uffer size will be needed. ThanksNing On Monday, March 19, 2018, 10:11:25 PM PDT, Selva Nair wrote:=20=20 =20 Hi, On Mon, Mar 19, 2018 at 5:00 PM, Ning Wei wrote: > Sorry, I did not state the intent clearly in the request. > > We wanted to use password field to pass authentication string, such as To= ken > string, > which can be long, the user auth plug in on the sever side can validate t= he > token as > the part authentication step. > > Acquiring a token, such as JWT, usually involves user interaction with the > token broker > service provider.=C2=A0 So it is better to do this on the client side. Its hard for me to imagine what authentication would need to pass more than ~1600 bytes=C2=A0 (that's about the current limit based on the 2048 byte buffer). Unless you are trying to fit in data unrelated to auth in the token. The U2F registration case I mentioned earlier would be such an example. How large is the data you need to transfer? If its not purely authentication data (i.e., a challenge string + signature at most), sending it as password is n= ot the right approach. If there is extra text included for convenience, pre-compressing may help. How do you plan to pass the "password" to openvpn client -- from stdin? The management i/f will not let you pass such a long password or username. > > I agreed on the following statement.=C2=A0 To support a long password fie= ld in > TLS channels, > the Buf size of 4096 is not enough in key_method_2_write.=C2=A0 Should we= propose > to > increase the buffer size further? Increasing to 4096 looks marginally useful to me and will fit a reasonably = sized user name (say < 128 bytes) and a largish challenge-response (upto ~3400 by= tes) leaving space for other things. Beyond that is unlikely to be necessary. I mentioned the overhead in key_method_2_write only because your logic behind this increase didn't make sense to me. > > "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 > 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 > wrote: >> Increase TLS_CHANNEL_BUF_SIZE to 4096. When the build is enabled with >> ENABLE_PKCS11, the password field can be 4096.=C2=A0 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 requi= res > 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 Selva =20=20= ------=_Part_792869_301385780.1522082204203 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Both of key_method_2_write and key_method_2_read take TLS_= Channel_Bug_Size as buffer size.  The current size, 2048 is not enough= to read/write a long password response.  I have notice the management= interface has a much smaller than 2048 buffer size to read/write.  Cu= rrently, if the management interface is not used, increasing tls channel bu= ffer size will serve the need.

As token provider, = the size of token can be bigger or smaller.  Sometime, it has more tha= n 1600 as a token.  To accommodate that, a bigger buffer size will be = needed.

Thanks
Ning

=20=20=20=20=20=20=20=20=20=20=20=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
On Monday, March 19, 2018, 10:11:25 PM PDT, Selva N= air <selva.nair@...277...> wrote:


Hi,

On Mon, Mar 19, 2018 at 5:00 PM, Ning Wei <xiaoningning@...109...> wrote:
> 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 th= e
> token as
> the part authentic= ation step.
>
> Acquiring a token= , such as JWT, usually involves user interaction with the
> token broker
> service provider.  So it is = better to do this on the client side.

= Its hard for me to imagine what authentication would need to pass more
than ~1600 bytes  (that's about the current limit based = on the 2048
byte buffer).
Unless you ar= e trying to fit in data unrelated to auth in the token. The U2F
registration case I mentioned earlier would be such an example.

How large is the data you need to transfer= ? If its not purely
authentication data
(i.e., a challenge string + signature at most), sending it as password is = not
the right approach. If there is extra text included f= or convenience,
pre-compressing
may hel= p.

How do you plan to pass the "passwo= rd" to openvpn client -- from stdin? The
management i/f w= ill not let you pass such a long password or username.
>
> I agreed on the following stat= ement.  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?

Increasing to 4096 looks marginally useful to me and will fit a = reasonably sized
user name (say < 128 bytes) and a lar= gish challenge-response (upto ~3400 bytes)
leaving space = for other things. Beyond that is unlikely to be necessary.

I mentioned the overhead in key_method_2_write only be= cause your logic
behind this increase didn't make sense t= o me.


>
> "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). S= o
> what's the logic behind 4096?"
&= gt;
> Regards,
> Ning
> On Friday, March 16, 2018, 10:30:45 AM PDT, Selva Nair
> <selva.nair@...277...> wrote:<= br clear=3D"none">>
>
> Hi,>
> Apologies in advance if I'm mis= reading the intent of this patch.
>
= > On Fri, Mar 16, 2018 at 12:40 PM, Ning Wei via Openvpn-devel
> <openvp= n-devel@lists.sourceforge.net> wrote:
>> Inc= rease 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, whic= h is not enough.
>
> I do not fol= low 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 c= hallenge 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
&g= t; cannot
> be submitted via the management as the par= ser 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 cha= llenge-response framework that requires
> such long re= sponses? Even for U2F, we wouldn't need to send a response
> that large. U2F registration response could get very long (still mos= tly
> under
> 2000 bytes), but do= ing U2F key registration via the authentication channel
&= gt; is
> not a good implementation. Authentication res= ponses are much smaller.
>
> In s= hort, it looks premature to increase this value before we start
> supporting long responses via the management, and a real practi= cal
> need for long challenge response strings that wo= n't fit in the current
> 2048 bytes (minus overhead) a= rise.
>
> Selva

Selva
= ------=_Part_792869_301385780.1522082204203--