[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:
> On Tue, Sep 05, 2006 at 11:53:25AM +0200, Simon Josefsson wrote:
>> Right. How about enforcing a minimum buffer size? Is 256 bytes a
>> reasonable minimum value?
>
> Why start that with GS2? I'd rather see the doc finished.
>
> I think, anyways, that this is a problem for SASL, not the mechanisms,
> and if the mechanisms all handle this in much the same way then that
> will make it easier for SASL to handle the problem.
>
> Please, let's not diverge from the other mechs w.r.t. maxbuf.
>
> Figuring out a good minimum has the look of a good rat hole.
RFC 4422 says this about security layers:
Each buffer of protected data is transferred over the underlying
transport connection as a sequence of octets prepended with a four-
octet field in network byte order that represents the length of the
buffer. The length of the protected data buffer MUST be no larger
than the maximum size that the other side expects. Upon the receipt
of a length field whose value is greater than the maximum size, the
receiver SHOULD close the connection, as this might be a sign of an
attack.
SASL is thus restricted to packets of size 2^32, so I withdraw my
request to be able to express "no limit".
Looking at specifications, RFC 2831 does not impose any limits on
maxbuf at all. GSSAPI restricts maxbuf to be 0..0xFFFFFF because the
integer field is 3 bytes. RFC 2831bis changes RFC 2831 and enforces
16 <= maxbuf <= 16777215. I don't know where this minimum comes from?
There doesn't seem to be much consistency here. The only consistent
value is in GSSAPI and RFC 2831bis, where the upper limit is 2^24.
That limit is not imposed by the core SASL specification, though,
which has 2^32.
For interoperability, I believe this problem should be noted, because
it may make it impossible to use a negotiated security layer.
Can we use the following and move on?
<t>The "client_maxbuf" field indicate the maximum protected
buffer size the client can receive. It MUST be 0 if the
client doesn't advertise support for any security layer, the
server MUST verify this. Small values can make it impossible
for the server to send any protected message to the client,
due to the overhead added by GSS_Wrap, and the server MAY
reject the authentication if it detects this situation.</t>
<t>The "server_maxbuf" field indicate the maximum protected data
buffer size the server can receive. It MUST be 0 if the
server doesn't advertise support for any security layer, the
client MUST verify this. Small values can make it impossible
for the client to send any protected message to the server,
due to the overhead added by GSS_Wrap, and the client MAY
reject the authentication if it detects this situation.</t>
/Simon