Re: GSSAPI signing/encryption for unsuspectingly applications (its not a bug)

Howard Chu wrote: You are right if you think that SASL with GSSAPI support should do that stuff. But firstly the SASL/GSSAPI code in openldap seems to support only the authentication part if you try to connect to something like an MS Active Directory Controller. After authentication is done successfully it seems so that integrity and confidential protection part via SASL/GSSAPI will be switched off.....hmmmmm. Secondly it seems so that Cyrus SASL code does not support SSF larger than 56 for GSSAPI based signing/encryption (aka integrity/confidential protection). But tickets from an AD are encrypted by default with RC4-HMAC which is SSF of 128. Additionally when I set the option "SASL_SECPROP minssf=128" this does not work with GSSAPI and I never get working communication with AD if GPO "Domain controller: LDAP server signing requirements" is turned on. Tests with DES encrypted tickets does not work too if that option is switched on. But if ldap_gssapi_bind_s() can be used then communication works well. At this point I think it can be one decision to wait till someone corrects Cyrus SASL stuff related to GSSAPI mechanism because this is the mostly used free SASL implementation. In contrast to GNU SASL (libgsasl) seams not to be an alternative for that issue at this time because it gots only partial support for GSSAPI. The part "integrity or confidentiality protection in GSSAPI mechanism" is currently not implemented (found that info on http://www.gnu.org/software/gsasl/manual/gsasl.html). Another decision can be to provide a compatibility hook via ldap_sasl_interactive_bind_s() so clients get that problem temporary work but without changing the API of openldap and without recompiling of client applications. And at some day when GNU SASL implements that feature (I think no one will do that for Cyrus SASL) this hook can be removed again. I really don't know what is the right decision....hmmm.