Bug#721010: SASL GSSAPI mechanism acceptor wrongly returns zero maxbufsize

Sergio Gelato Sergio.Gelato at astro.su.se
Tue Aug 27 06:43:50 UTC 2013


Package: libsasl2-modules-gssapi-mit
Version: 2.1.25.dfsg1-6+deb7u1
Tags: patch upstream

(Apparently still unfixed on upstream git master branch. Copying cyrus-bugs.)

After upgrading an LDAP server from squeeze to wheezy I started seeing
bind failures from one client application. This application uses SASL GSSAPI
binding after STARTTLS. On investigation it turned out that in the final
handshake the server was returning both a security layer bitmask of 7 and
a zero maximum token size. The issue went away after I applied the attached
patch.

My impression from reading the original code is that the problem can manifest
itself when the SSF provided by the external layer is sufficient to satisfy
the application's policy. I don't think it would be appropriate for the
server not to offer security layers that the security context can support
just because the external SSF exceeds some threshold; the client may have
reasons of its own to insist on using those layers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 9000-fix-server-buffer-size-negotiation.patch
Type: text/x-diff
Size: 1639 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20130827/cd0f7b85/attachment.patch>


More information about the Pkg-cyrus-sasl2-debian-devel mailing list