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=