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.