Comment 7 for bug 1015819

Here is a follow on the comment above:

I have changes the GSSAPI mech plugin source code:

diff --git a/plugins/gssapi.c b/plugins/gssapi.c
index 2fd1b3b..39302cd 100644
--- a/plugins/gssapi.c
+++ b/plugins/gssapi.c
@@ -1583,20 +1583,9 @@ static int gssapi_client_mech_step(void *conn_context,
        }

        /* Setup req_flags properly */
- req_flags = GSS_C_INTEG_FLAG;
- if (params->props.max_ssf > params->external_ssf) {
- /* We are requesting a security layer */
- req_flags |= GSS_C_MUTUAL_FLAG | GSS_C_SEQUENCE_FLAG;
- /* Any SSF bigger than 1 is confidentiality. */
- /* Let's check if the client of the API requires confidentiality,
- and it wasn't already provided by an external layer */
- if (params->props.max_ssf - params->external_ssf > 1) {
- /* We want to try for privacy */
- req_flags |= GSS_C_CONF_FLAG;
- }
- }
-
- if (params->props.security_flags & SASL_SEC_PASS_CREDENTIALS) {
+ req_flags = GSS_C_MUTUAL_FLAG;
+
+ if (params->props.security_flags & SASL_SEC_PASS_CREDENTIALS) {
            req_flags = req_flags | GSS_C_DELEG_FLAG;
        }

And reran ldapsearch with -ZZ (STARTTLS) and whom, it did work. I tried without TLS too. Everything is shiny in Wireshark. TLS encrypted data, fully opaque, unencrypted data, fully browsable.

This code definitively requires polish as long as the SASL RFC is not violated. I am willing to provide a quality patch for that. Unfortunately, I have another patch pending on the Cyrus SASL mailing list w/o any response at the moment. Maybe someone could step up: http://asg.andrew.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&msg=10230