Patch related to "(ITS#6110) GSSAPI signing/encryption for unsuspectingly applications" is more an enhancement than a bug report.
Please have a look at patch on ftp://ftp.openldap.org/incoming/mike-becher-090512.libraries-libldap.patch or ITS report on http://www.openldap.org/its/index.cgi/Incoming?id=6110;selectid=6110
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) ldap_sasl_interactive_bind_s(), 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 mailing list.
best regards Mike
mikbec wrote:
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 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.
Please have a look at patch on ftp://ftp.openldap.org/incoming/mike-becher-090512.libraries-libldap.patch or ITS report on http://www.openldap.org/its/index.cgi/Incoming?id=6110;selectid=6110
In short that patch:
- 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) ldap_sasl_interactive_bind_s(), 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 mailing list.
best regards Mike
Howard Chu wrote:
mikbec wrote:
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
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.
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 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.
Please have a look at patch on ftp://ftp.openldap.org/incoming/mike-becher-090512.libraries-libldap.patch
or ITS report on http://www.openldap.org/its/index.cgi/Incoming?id=6110;selectid=6110
In short that patch:
- 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) ldap_sasl_interactive_bind_s(), 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 mailing list.
best regards Mike
mikbec wrote:
Howard Chu wrote:
mikbec wrote:
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
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.
I've seen this all work correctly in the past with AD, so either AD has changed recently, or your Kerberos configuration is wrong, or your Kerberos library is broken.
Secondly it seems so that Cyrus SASL code does not support SSF larger than 56 for GSSAPI based signing/encryption (aka integrity/confidential
Also wrong, Cyrus SASL/GSSAPI is known to work with up to ssf=112.
--On May 14, 2009 2:22:46 PM -0700 Howard Chu hyc@symas.com wrote:
Secondly it seems so that Cyrus SASL code does not support SSF larger than 56 for GSSAPI based signing/encryption (aka integrity/confidential
Also wrong, Cyrus SASL/GSSAPI is known to work with up to ssf=112.
Hm, I thought for the GSSAPI mech, it was hard coded to 56. I've certainly not seen it higher even with newer enc types that were at much higher encryption levels.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On May 14, 2009 2:22:46 PM -0700 Howard Chuhyc@symas.com wrote:
Secondly it seems so that Cyrus SASL code does not support SSF larger than 56 for GSSAPI based signing/encryption (aka integrity/confidential
Also wrong, Cyrus SASL/GSSAPI is known to work with up to ssf=112.
Hm, I thought for the GSSAPI mech, it was hard coded to 56. I've certainly not seen it higher even with newer enc types that were at much higher encryption levels.
Read TF code.
/* Heimdal and MIT use the following */ #ifdef GSS_KRB5_CONF_C_QOP_DES3_KD #define K5_MAX_SSF 112 #endif
--On May 14, 2009 3:05:25 PM -0700 Howard Chu hyc@symas.com wrote:
Quanah Gibson-Mount wrote:
--On May 14, 2009 2:22:46 PM -0700 Howard Chuhyc@symas.com wrote:
Secondly it seems so that Cyrus SASL code does not support SSF larger than 56 for GSSAPI based signing/encryption (aka integrity/confidential
Also wrong, Cyrus SASL/GSSAPI is known to work with up to ssf=112.
Hm, I thought for the GSSAPI mech, it was hard coded to 56. I've certainly not seen it higher even with newer enc types that were at much higher encryption levels.
Read TF code.
/* Heimdal and MIT use the following */ # ifdef GSS_KRB5_CONF_C_QOP_DES3_KD # define K5_MAX_SSF 112 # endif
But that's behind a further ifdef:
#ifdef WANT_KERBEROS5_3DES
which seems to only get set if you specifically set that at compile time. I certainly don't find it defined in any files generated from configure in my builds.
Otherwise:
#ifndef K5_MAX_SSF /* All Kerberos implementations support DES */ #define K5_MAX_SSF 56 #endif
So I stand behind it being hard coded at 56 for pretty much anyone.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On May 14, 2009 3:14:46 PM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On May 14, 2009 3:05:25 PM -0700 Howard Chu hyc@symas.com wrote:
Quanah Gibson-Mount wrote:
--On May 14, 2009 2:22:46 PM -0700 Howard Chuhyc@symas.com wrote:
Secondly it seems so that Cyrus SASL code does not support SSF larger than 56 for GSSAPI based signing/encryption (aka integrity/confidential
Also wrong, Cyrus SASL/GSSAPI is known to work with up to ssf=112.
In any case, the way cyrus-sasl current works, the reported SSF value is pretty irrelevant, since it is hard coded. If you (Mike) are particularly interested in improving the SASL/GSSAPI interactions in OpenLDAP, I'd advise you work on re-working the Cyrus SASL GSSAPI plugin to do things like get the SSF from the underlying kerberos libraries, and back when it's negotiated, so OpenLDAP can report the accurate values. The folks on the Cyrus-sasl project are actively developing again, so now is the time to start contributing to that project.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On May 14, 2009 3:14:46 PM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On May 14, 2009 3:05:25 PM -0700 Howard Chu hyc@symas.com wrote:
Quanah Gibson-Mount wrote:
--On May 14, 2009 2:22:46 PM -0700 Howard Chuhyc@symas.com wrote:
Secondly it seems so that Cyrus SASL code does not support SSF larger than 56 for GSSAPI based signing/encryption (aka integrity/confidential
Also wrong, Cyrus SASL/GSSAPI is known to work with up to ssf=112.
In any case, the way cyrus-sasl current works, the reported SSF value is pretty irrelevant, since it is hard coded. If you (Mike) are
That is absolutly correct. SSF is hard coded to 56 in Cyrus SASL for GSSAPI. Additionally I have made some tests to change that define to 128 but this doesn't change anything. It seems so that encyption type will not negotiated .... but that is only an assumption by me.
particularly interested in improving the SASL/GSSAPI interactions in OpenLDAP, I'd advise you work on re-working the Cyrus SASL GSSAPI plugin
yes .. I'm very interested in to get this work and ...
to do things like get the SSF from the underlying kerberos libraries, and back when it's negotiated, so OpenLDAP can report the accurate values. The folks on the Cyrus-sasl project are actively developing again, so now is the time to start contributing to that project.
... if they work again on SASL I will give this opportunity a try.
best regards Mike
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
On Wed, May 13, 2009 at 03:06:57PM -0700, Howard Chu wrote:
mikbec wrote:
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 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.
ldap_gssapi_bind was never meant to replace or duplicate SASL part of the code. It's only an implementation that enables using GSSAPI directly, while Cyrus SASL offers wide variety of authentication mechanisms. The difference is that ldap_gssapi_bind doesn't require any special configuration and thus it's an easy way to have an interface for Active Directory.
cheers,
Rafal Szczesniak wrote:
On Wed, May 13, 2009 at 03:06:57PM -0700, Howard Chu wrote:
mikbec wrote:
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 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.
ldap_gssapi_bind was never meant to replace or duplicate SASL part of the code. It's only an implementation that enables using GSSAPI directly, while Cyrus SASL offers wide variety of authentication mechanisms. The difference is that ldap_gssapi_bind doesn't require any special configuration and thus it's an easy way to have an interface for Active Directory.
This explanation makes no sense, since no *special* configuration is required to use SASL/GSSAPI with Active Directory. No matter what API you use, you must have Kerberos properly configured.
On Jul 2, 2009, at 2:49 AM, Howard Chu wrote:
Rafal Szczesniak wrote:
On Wed, May 13, 2009 at 03:06:57PM -0700, Howard Chu wrote:
mikbec wrote:
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 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.
ldap_gssapi_bind was never meant to replace or duplicate SASL part of the code. It's only an implementation that enables using GSSAPI directly, while Cyrus SASL offers wide variety of authentication mechanisms. The difference is that ldap_gssapi_bind doesn't require any special configuration and thus it's an easy way to have an interface for Active Directory.
This explanation makes no sense, since no *special* configuration is required to use SASL/GSSAPI with Active Directory. No matter what API you use, you must have Kerberos properly configured.
I would be concerned for having two APIs that do the same thing. This complicates clients.
I've long thought about implementing certain SASL mechanism natively, such as PLAIN and EXTERNAL, because at times I rather not deal with Cyrus SASL (or other SASL library alternatives). (I never did it because, well, because those times are rare.) BUT I think native implementations should present themselves with the same API.
If not, what happens is that client's end up having to have some configuration support (or other means) to select which implementation to use.
-- Kurt
-
Howard Chu -
Kurt Zeilenga -
mikbec -
Quanah Gibson-Mount -
Rafal Szczesniak