[Date Prev][Date Next]
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
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.
Patch related to "(ITS#6110) GSSAPI signing/encryption for
unsuspectingly applications" is more an enhancement than a bug report.
That's fine, patches are supposed to be tracked in ITS anyway.
However, it seems to me that these patches are duplicating functionality
that's already provided by SASL/GSSAPI. On that basis I'm inclined to
But if ldap_gssapi_bind_s() can be used then communication works well.
reject them. I'm beginning to regret including the ldap_gssapi_bind_s()
function as well; that is totally nonstandard and duplicates
functionality that has been available in the standard API for over 8 years.
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
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
I really don't know what is the right decision....hmmm.
Please have a look at patch on
or ITS report on
In short that patch:
1) adds call of ldap_gssapi_bind_s() at the beginning of
ldap_sasl_interactive_bind_s() which can be turn on or off by an GSSAPI
OPTION (manual update of ldap.conf (5) included) to provide GSSAPI
signing/encryption for applications that use (and only know)
2) adds the missed implementation of "switch off" functionality of all
other GSSAPI OPTIONS.
3) corrects one string length problem in guess_service_principal() and
4) corrects one hostname resolving problem in guess_service_principal().
Sorry for that kind of announcement but I hope now it is on the right