GSSAPI and "encoded packet size too big"

Bill MacAllister whm at stanford.edu
Thu Mar 21 19:24:44 EDT 2013



--On Monday, February 11, 2013 03:58:49 PM +0100 Ragnar Sundblad <ragge at csc.kth.se> wrote:

>
> On 11 feb 2013 - w7, at 00:04, Ragnar Sundblad <ragge at csc.kth.se> wrote:
>
>> We get "encoded packet size too big (8252 > 8192)" paired with
>> "decoding error: generic failure; SASL(-1): generic failure: security
>> flags do not match required, closing connection" when the imap proxy
>> is talking to the imapd.
>>
>> I have tracked down the "too big" message to _plug_decode() in
>> plugins/plugin_common.c.
>
> We have looked into this a little further.
>
> First a clarification:
> Above we had upped the buffer both in imapd (PROT_BUFSIZE in
> <imapd>/lib/prot.h) and in sasl (SASL_ENCODEV_EXTRA in
> <sasl>/lib/common.c to 8192. Before that change, the numbers
> typically were "(4156 > 4096)".
>
> We are now using sasl with SASL_ENCODEV_EXTRA=8192 (double the
> original value, and imapd with PROT_BUFSIZE=4096 (as it were
> originally), and everything finally seems to work now.
>
> The sasl GSSAPI plugin sets oparams->maxoutbuf to 8132 (8192 - 60),
> but it seems the imapd stuff still sends packets which in clear
> text are PROT_BUFSIZE, which get 60 bytes larger when encrypted,
> and which then would be to large if we hadn't upped sasl's
> SASL_ENCODEV_EXTRA.
>
> So something doesn't really work correctly here.

Did you ever figure out what the underlying issue was?

We are seeing a problem that looks a lot like this yours.  From JNDI
clients connecting to our OpenLDAP server on Debian Wheezy connections
are failing.  If the client makes a GSSAPI connection and uses SASL
encryption then the client will fail with a
java.lang.NegativeArraySizeException error.

The problem Cyrus SASL version is 2.1.25.  Also, the problem is
limited to Java JNDI clients since our non-Java clients appear to
be working.  The same failing Java applications work with version
2.1.23.

We have experimented and found that the problem is in the SASL
encryption layer.  If we configure configure the Java client to use
GSSAPI authentication and TLS encryption the clients can retrieve LDAP
data.

Bill

-- 

Bill MacAllister
Infrastructure Delivery Group, Stanford University



More information about the Cyrus-sasl mailing list