SASL 2.1.27 rc8

[Carson Gaspar]

On 5/10/2018 5:28 PM, Ken Murchison wrote:
>
> The primary reason for this candidate is to revert the GSSAPI flag 
> changes.  I'd like to roll out the final release early next week, so 
> please test this RC as soon as possible.

I can confirm that rc8 behaves as well/badly as the RedHat patched 
version when connecting to an AD LDAP server. i.e. when using TLS and 
GSSAPI, one must set maxssf for it to work. So it at least isn't a step 
backwards.

I'm not sure that negotiated SSF is working as intended, however, unless 
code changes to the client are required. openldap-2.4.45 linked with rc8 
example without maxssf, showing an enctype of aes256 but SSF of 56:

$ KRB5_TRACE=/dev/stdout /var/tmp/cyrus-sasl/bin/ldapsearch -Y GSSAPI 
-LLL -H ldaps://XXXX:636 -b 'XXX"
SASL/GSSAPI authentication started
[138314] 1526000107.192106: ccselect can't find appropriate cache for 
server principal ldap/XXX@
[138314] 1526000107.192208: Getting credentials gaspar at XXX -> ldap/XXX@ 
using ccache FILE:/tmp/krb5cc_XXX
[138314] 1526000107.192288: Retrieving gaspar at XXX -> ldap/XXX@ from 
FILE:/tmp/krb5cc_XXX with result: 0/Success
[138314] 1526000107.192363: Creating authenticator for gaspar at XXX -> 
ldap/XXX@, seqnum 811872038, subkey aes256-cts/8D75, session key 
aes256-cts/16BB
[138314] 1526000107.193939: Read AP-REP, time 1526000107.192369, subkey 
aes256-cts/BB06, seqnum 497881342
SASL username: gaspar at XXX
SASL SSF: 56
SASL data security layer installed.
ldap_result: Can't contact LDAP server (-1)

If I pass in -O maxssf=[0..256] while using TLS, it works, and I get:

SASL SSF: 0

If I pass in no maxssf option or -O maxssf=[0..256] while not using TLS, 
it works, and I get:

SASL SSF: 56