Re: handling of sasl packet sizes (ITS#2184)

[leg+@andrew.cmu.edu]

   From: "Howard Chu" <hyc@highlandsun.com>
   Date: Mon, 2 Dec 2002 18:56:11 -0800
[...]
   > It might be fair to expect, but that assumption is certainly not
   > covered in any protocol document. A busy server might want to have
   > small receive buffers (it gets lots of small commands frequently) but
   > large send buffers (so that it can efficiently send lots of data to a
   > few clients at a time).

   Now this makes a lot of sense to me, but that's not how the library works.
   There's only a single sasl_secprops.maxbufsize that an application can
   configure, so there is no way to specify separate receive and
   transmit buffer sizes.

You only get to specify YOUR receive buffer size. The other side gets
to specify ITS receive buffer size.

Obviously, you can always send things smaller than the other side's
maximum receive buffer size; SASL merely reports SASL_MAXOUTBUF
because that's what your application MUST obey.

[...]
   No. If we choose a max buffer size of 128K instead of our default
   of 64K, digestmd5 will refuse to decode such a large message. See
   lines 1219 and 1535 of plugins/digestmd5.c. The same error exists
   in srp.c.

I agree that there's a bug in the DIGEST-MD5 plugin. I believe it
should be comparing to text->maxbuf instead.

   >
   > RFC 2222 doesn't require any sort of minimum supported buffer size.

   RFC 2222 specifies that a message length is encoded in 3
   octets. That means a buffer size up to 0xFFFFFF is legal. All of
   the plugins should function correctly with a message that large,
   regardless of whether they can be configured with a smaller
   default. The Cyrus library should define a manifest constant for
   this value (0xFFFFFF) and use it everywhere, and export it for
   applications to use because it is an intrinsic property of the SASL
   protocol.

Actually, SASL allows ciphertext buffers up to 4 bytes in
length. Nothing is magical about 0xFFFFFF.

It would be acceptable for a mechanism to refuse to support such a
large size, but if it did so it should be negotiating the size
down. DIGEST-MD5 isn't doing this, thus the problem.

Unfortunately since I didn't know about this bug (nor do I see it in
our bug tracking database) and we don't use DIGEST-MD5 in production,
this isn't getting done. I'll add it.

   >
   > There might be individual mechanisms with smaller limits than what
   > OpenLDAP supports, but this will not cause any interoperability
   > problems.

   No, see ITS#2179, it is already causing interoperability
   problems. Even if we set secprops to allow a maxbuf of 0xFFFFFF the
   mech itself will fail when it receives a message larger than 0xFFFF.

Actually, 2179 is specifically concerned with GSSAPI (I've been
talking with Edward) and GSSAPI does it correctly. It's an Active
Directory bug---one that appears to have been fixed in the latest
.NET Server build.

Larry