changed notes changed state Open to Feedback
Full_Name: Scott Salley Version: HEAD OS: Linux URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch Submission from: (NULL) (67.51.54.234) Note that a similar issue/contribution was submitted in 2008 (Contrib/5369) and appears to have been 'lost'. The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch makes it possible to use the GSSAPI support in OpenLDAP by: 1. Defining --with-gssapi in configure which a. Checks for appropriate header files b. Checks for the appropriate library c. Defines HAVE_GSSAPI to 1 in everything is in order 2. Exposing ldap_gssapi_bind_s in ldap.h
ssalley@likewise.com wrote: > Full_Name: Scott Salley > Version: HEAD > OS: Linux > URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch > Submission from: (NULL) (67.51.54.234) > > > Note that a similar issue/contribution was submitted in 2008 (Contrib/5369) and > appears to have been 'lost'. > The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch > makes it possible to use the GSSAPI support in OpenLDAP by: > > 1. Defining --with-gssapi in configure which > a. Checks for appropriate header files > b. Checks for the appropriate library > c. Defines HAVE_GSSAPI to 1 in everything is in order > > 2. Exposing ldap_gssapi_bind_s in ldap.h I am still disinclined to publish any of this. The standard mechanism for using GSSAPI in LDAP is via SASL. I see no benefit to propagating more non-standard one-off ldap_XXX_bind flavors. It's a poor design approach and it increases our support workload for no appreciable gain. It increases application developer's workload as well, if they have to test for the existence of multiple flavors of ldap_XXX_bind and code for them each separately in their apps. If you really want to have "direct" access to other authentication mechanisms, the right way to do this is by adding new LDAP_AUTH_xxx definitions that can be muxed out from a single ldap_bind API. Of course, by the time you've implemented option parsing so that generic client code can be configured with arbitrary Bind mechanisms, you would have re-implemented SASL. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Jun 2, 2010, at 1:08 AM, hyc@symas.com wrote: > ssalley@likewise.com wrote: >> Full_Name: Scott Salley >> Version: HEAD >> OS: Linux >> URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch >> Submission from: (NULL) (67.51.54.234) >> >> >> Note that a similar issue/contribution was submitted in 2008 (Contrib/5369) and >> appears to have been 'lost'. > >> The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch >> makes it possible to use the GSSAPI support in OpenLDAP by: >> >> 1. Defining --with-gssapi in configure which >> a. Checks for appropriate header files >> b. Checks for the appropriate library >> c. Defines HAVE_GSSAPI to 1 in everything is in order >> >> 2. Exposing ldap_gssapi_bind_s in ldap.h > > I am still disinclined to publish any of this. The standard mechanism for > using GSSAPI in LDAP is via SASL. I see no benefit to propagating more > non-standard one-off ldap_XXX_bind flavors. It's a poor design approach and it > increases our support workload for no appreciable gain. It increases > application developer's workload as well, if they have to test for the > existence of multiple flavors of ldap_XXX_bind and code for them each > separately in their apps. I concur and add: At one time I thought it might be useful to implement a few SASL mechanisms directly in libldap for cases where one didn't want to suck in a SASL library. But for most mechanisms removing the SASL library is worth it in my eyes, especially any mechanism other than PLAIN or EXTERNAL. But where this is worth it, it should be done through existing APIs. Adding mech specific APIs should be avoided. > > If you really want to have "direct" access to other authentication mechanisms, > the right way to do this is by adding new LDAP_AUTH_xxx definitions that can > be muxed out from a single ldap_bind API. I could see adding new API to support new authentication frameworks to which LDAP was extended to support. For instance, if LDAP was extended to directly support GSS API mechanisms, then adding LDAP_AUTH_GSSAPI would make sense (here GSS API refers to the GSS API not the SASL Kerberos mechanism called GSSAPI). But for security reasons, it unlikely this will ever happen, > Of course, by the time you've > implemented option parsing so that generic client code can be configured with > arbitrary Bind mechanisms, you would have re-implemented SASL. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Howard, We are trying to make likewise-open packages available for Fedora but they only want to pull OpenLDAP patches from upstream. So I'm in a bit of a spot here. You've already accepted the lsap_bind_gssapi patch, this one simply exposes the existing code. Is it just the public ldap_bind_gssapi_s() signature that you have an issue with? If, as you suggest, we give you a patch that adds an LDAP_AUTH_GSSAPI flag to ldap_bind_s() but keep the same (existing) ldap_bind_gssapi_s() internals, would that be acceptable? cheers, jerry - -- Director of Engineering http://www.likewise.com/ Likewise-CIFS http://www.likewiseopen.org/ "What man is a man who does not make the world better?" --Balian On 6/2/10 12:10 AM, Scott Salley wrote: > > > > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Tue 6/1/2010 6:07 PM > To: Scott Salley > Cc: openldap-its@openldap.org > Subject: Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s > > ssalley@likewise.com wrote: >> Full_Name: Scott Salley >> Version: HEAD >> OS: Linux >> URL: > http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch >> Submission from: (NULL) (67.51.54.234) >> >> >> Note that a similar issue/contribution was submitted in 2008 > (Contrib/5369) and >> appears to have been 'lost'. > >> The patch > http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch >> makes it possible to use the GSSAPI support in OpenLDAP by: >> >> 1. Defining --with-gssapi in configure which >> a. Checks for appropriate header files >> b. Checks for the appropriate library >> c. Defines HAVE_GSSAPI to 1 in everything is in order >> >> 2. Exposing ldap_gssapi_bind_s in ldap.h > > I am still disinclined to publish any of this. The standard mechanism for > using GSSAPI in LDAP is via SASL. I see no benefit to propagating more > non-standard one-off ldap_XXX_bind flavors. It's a poor design approach > and it > increases our support workload for no appreciable gain. It increases > application developer's workload as well, if they have to test for the > existence of multiple flavors of ldap_XXX_bind and code for them each > separately in their apps. > > If you really want to have "direct" access to other authentication > mechanisms, > the right way to do this is by adding new LDAP_AUTH_xxx definitions that can > be muxed out from a single ldap_bind API. Of course, by the time you've > implemented option parsing so that generic client code can be configured > with > arbitrary Bind mechanisms, you would have re-implemented SASL. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMBj/7IR7qMdg1EfYRAjmcAKC1MyKit8TKa1W96cZ2Uh3Cdm/EMACeJtbu 9/F8j8UQJ5C3X0sW5LytRq8= =tkYo -----END PGP SIGNATURE-----
In looking at the code a bit more closely, one could argue that what this code actually provides is an alternative to ldap_sasl_interactive_bind_s() which, instead of negotiating any mechanism, is designed to negotiate GSS API mechanisms via GSS-SPNEGO. In that light, maybe it should be integrated into ldap_sasl_interactive_bind_s() or renamed to be more clear to be a higher level negotiation routine, maybe ldap_sasl_gss_spnego_bind_s(). However, one issue I have with this code is that highly dependent behaviors which, aside from not be standardized, aren't even specified in RFCs. For instance, there is no RFC describing dnsHostName or ldapServiceName or any specification detailing how GSS-SPNEGO is to be used in LDAP. Without a formal specification (e.g., RFC), I oppose release of this code. That is, it should stay HEAD only until such time that a formal specification (e.g., RFC) is available. I would assume GSS-SPNEGO is usable without these attributes. It seems odd to me that this code requires them. I note that use of the SASL GSS-SPNEGO in LDAP has actually be discouraged in IETF circles because SASL "GSS-SPNEGO" is itself not well specified and multiple levels of negotiation leads to downgrade attacks. The general consensus in the IETF seems that application protocol clients (including LDAP clients) should use SASL mechanism negotiation to select mechanisms, whether GSS API based mechanisms or non GSS API based mechanisms. There is a general move on foot that all new SASL mechanisms be described as GSS API mechanisms, ala SCRAM. -- Kurt
Lastly, I note that it might be good for proponent of this feature to at least offer extensions to ldapwhoami(1) and other command line tools. Aside from the educational value that would provide to developers in how this feature would be used along side other libldap features (such as ldap_sasl_interactive_bind_s), it would provide a means to test the code. Of course, without support in OpenLDAP's slapd(8), testing would be cumbersome for many. -- Kurt On Jun 1, 2010, at 6:08 PM, hyc@symas.com wrote: > ssalley@likewise.com wrote: >> Full_Name: Scott Salley >> Version: HEAD >> OS: Linux >> URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch >> Submission from: (NULL) (67.51.54.234) >> >> >> Note that a similar issue/contribution was submitted in 2008 (Contrib/5369) and >> appears to have been 'lost'. > >> The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch >> makes it possible to use the GSSAPI support in OpenLDAP by: >> >> 1. Defining --with-gssapi in configure which >> a. Checks for appropriate header files >> b. Checks for the appropriate library >> c. Defines HAVE_GSSAPI to 1 in everything is in order >> >> 2. Exposing ldap_gssapi_bind_s in ldap.h > > I am still disinclined to publish any of this. The standard mechanism for > using GSSAPI in LDAP is via SASL. I see no benefit to propagating more > non-standard one-off ldap_XXX_bind flavors. It's a poor design approach and it > increases our support workload for no appreciable gain. It increases > application developer's workload as well, if they have to test for the > existence of multiple flavors of ldap_XXX_bind and code for them each > separately in their apps. > > If you really want to have "direct" access to other authentication mechanisms, > the right way to do this is by adding new LDAP_AUTH_xxx definitions that can > be muxed out from a single ldap_bind API. Of course, by the time you've > implemented option parsing so that generic client code can be configured with > arbitrary Bind mechanisms, you would have re-implemented SASL. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > >
On Jun 2, 2010, at 4:28 AM, gcarter@likewise.com wrote: > > Is it just the public ldap_bind_gssapi_s() signature that you > have an issue with? If, as you suggest, we give you a patch > that adds an LDAP_AUTH_GSSAPI flag to ldap_bind_s() but keep > the same (existing) ldap_bind_gssapi_s() internals, would that > be acceptable? There's already LDAP_AUTH_NEGOTIATE which does this. So technically, the API is already exposed via ldap_bind_s. But I strongly oppose the introduction of abuse of the LDAP_AUTH_* enumeration of LDAP authentication methods and ldap_bind_s(). This enumeration and method are intended to have a one-to-one relationship with the wire protocol. There is no "negotiate" LDAP authentication mechanism. If this code is going to pursued (see my other comments), I think it should be treated as a high level negotiation wrapper similar to ldap_sasl_interactive_bind_s(). If at all possible, it should be integrated into ldap_sasl_interactive_bind_s() (which can handle non-interactive cases as well). However, I could (*) see it desirable for it to be separately accessible as well, so ldap_sasl_gss_spnego_bind_s() would be better. (* it might be easier to see this if a proponent of this feature would implement it in ldapwhoami(1) and slapd(8).) However, I still have objections to releasing code which implements undocumented protocol features. Someone really needs to specify the the SASL GSS-SPNEGO mechanism and how its used in LDAP. -- Kurt > > > > > > > cheers, jerry > - -- > Director of Engineering http://www.likewise.com/ > Likewise-CIFS http://www.likewiseopen.org/ > "What man is a man who does not make the world better?" --Balian > > > > > > On 6/2/10 12:10 AM, Scott Salley wrote: >> >> >> >> -----Original Message----- >> From: Howard Chu [mailto:hyc@symas.com] >> Sent: Tue 6/1/2010 6:07 PM >> To: Scott Salley >> Cc: openldap-its@openldap.org >> Subject: Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s >> >> ssalley@likewise.com wrote: >>> Full_Name: Scott Salley >>> Version: HEAD >>> OS: Linux >>> URL: >> http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch >>> Submission from: (NULL) (67.51.54.234) >>> >>> >>> Note that a similar issue/contribution was submitted in 2008 >> (Contrib/5369) and >>> appears to have been 'lost'. >> >>> The patch >> http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch >>> makes it possible to use the GSSAPI support in OpenLDAP by: >>> >>> 1. Defining --with-gssapi in configure which >>> a. Checks for appropriate header files >>> b. Checks for the appropriate library >>> c. Defines HAVE_GSSAPI to 1 in everything is in order >>> >>> 2. Exposing ldap_gssapi_bind_s in ldap.h >> >> I am still disinclined to publish any of this. The standard mechanism for >> using GSSAPI in LDAP is via SASL. I see no benefit to propagating more >> non-standard one-off ldap_XXX_bind flavors. It's a poor design approach >> and it >> increases our support workload for no appreciable gain. It increases >> application developer's workload as well, if they have to test for the >> existence of multiple flavors of ldap_XXX_bind and code for them each >> separately in their apps. >> >> If you really want to have "direct" access to other authentication >> mechanisms, >> the right way to do this is by adding new LDAP_AUTH_xxx definitions that can >> be muxed out from a single ldap_bind API. Of course, by the time you've >> implemented option parsing so that generic client code can be configured >> with >> arbitrary Bind mechanisms, you would have re-implemented SASL. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFMBj/7IR7qMdg1EfYRAjmcAKC1MyKit8TKa1W96cZ2Uh3Cdm/EMACeJtbu > 9/F8j8UQJ5C3X0sW5LytRq8= > =tkYo > -----END PGP SIGNATURE----- > >
Kurt@OpenLDAP.org wrote: > However, one issue I have with this code is that highly dependent = > behaviors which, aside from not be standardized, aren't even specified = > in RFCs. For instance, there is no RFC describing dnsHostName or = > ldapServiceName or any specification detailing how GSS-SPNEGO is to be = > used in LDAP. Without a formal specification (e.g., RFC), I oppose = > release of this code. That is, it should stay HEAD only until such time = > that a formal specification (e.g., RFC) is available. Kurt, I somewhat can understand your concerns. But as a general answer to your comment above: There is already a lot of code in OpenLDAP for which no RFC or at least an I-D was specified but which serves a certain use-case. Strictly (following your statement above) speaking one would have to hunk out all the stuff only specified in I-Ds. So I don't see the strong need to be overly strict here. Quality of certain code is another story. But I cannot comment on this. Ciao, Michael.
On Jun 2, 2010, at 11:11 AM, Michael Ströder wrote: > Kurt@OpenLDAP.org wrote: >> However, one issue I have with this code is that highly dependent = >> behaviors which, aside from not be standardized, aren't even specified = >> in RFCs. For instance, there is no RFC describing dnsHostName or = >> ldapServiceName or any specification detailing how GSS-SPNEGO is to be = >> used in LDAP. Without a formal specification (e.g., RFC), I oppose = >> release of this code. That is, it should stay HEAD only until such time = >> that a formal specification (e.g., RFC) is available. > > Kurt, I somewhat can understand your concerns. > But as a general answer to your comment above: There is already a lot of code > in OpenLDAP for which no RFC or at least an I-D was specified but which serves > a certain use-case. Strictly (following your statement above) speaking one > would have to hunk out all the stuff only specified in I-Ds. An I-D would be a start. I would think there's a number of interesting security considerations that would bubble up if someone would ever have taken the time to submit a specification regarding use of SPNEGO in SASL and in application protocols such as LDAP to an open standards organization such as the IETF. > So I don't see > the strong need to be overly strict here. It's long been a stated goal of the project to promote interoperability through open standards. This work seems more to come from a community whose stated goal is to behave like one particular vendor. I'm not a fan of chasing any particular vendor. > Quality of certain code is another story. But I cannot comment on this. How can one independently verify the code acts as intended without a specification of the intended behavior? (Saying it should act like some particular commercial product, is not a specification.) -- Kurt > > Ciao, Michael.
changed state Feedback to Open moved from Incoming to Software Bugs
ldap_gssapi stuff should be deleted 2_5_REQUIRED
changed notes
https://git.openldap.org/openldap/openldap/-/merge_requests/28
Commits: • c6493c45 by Quanah Gibson-Mount at 2020-04-10T18:19:33+00:00 ITS#6567 - Remove non-cyrus-sasl GSSAPI bits
I think there are some bits that can still be cleaned up: .gitignore:96:libraries/libldap_r/gssapi.c ^- gssapi.c itself was deleted include/ldap.h:205:/* OpenLDAP GSSAPI options */ include/ldap.h:206:#define LDAP_OPT_X_GSSAPI_DO_NOT_FREE_CONTEXT 0x6200 include/ldap.h:207:#define LDAP_OPT_X_GSSAPI_ALLOW_REMOTE_PRINCIPAL 0x6201 ^- all uses of these have been removed libraries/libldap/init.c:141:#define MAX_LDAP_ATTR_LEN sizeof("GSSAPI_ALLOW_REMOTE_PRINCIPAL") ^- previously MAX_LDAP_ATTR_LEN used "TLS_CIPHER_SUITE", probably switch it back to that (double check nothing else is longer) (note to self actually, MAX_LDAP_ATTR_LEN is almost certainly relevant for ITS#8847 too...) libraries/libldap/init.c:44: LDAP_LDO_GSSAPI_NULLARG libraries/libldap/init.c:60:#define ATTR_GSSAPI 10 libraries/libldap/ldap-int.h:308:#define LDAP_LDO_GSSAPI_NULLARG ^- I think these are just cruft as well...
Commits: • e50741e4 by Quanah Gibson-Mount at 2020-04-13T17:19:35+00:00 ITS#6567 - More cleanup