Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s

[Kurt@OpenLDAP.org]

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=