> On 04/15/15 21:10 +0000, Osipov, Michael wrote:
> >Hi folks,
> >
> >I am binding against Active Directory with GSSAPI mech and would like to
> disable SASL integrity for debugging purposes with Wireshark.
> Unfortunately, this call fails:
> >
> >char *secprops = "minssf=0,maxssf=0";
> >rc = ldap_set_option(ld, LDAP_OPT_X_SASL_SECPROPS, secprops);
> >
> >with:
> >
> >Diagnostic message: SASL(-1): generic failure: GSSAPI Error: A required
> input parameter could not be read (Unknown error)
> >Result code: -2
> 
> This error is likely produced by your Kerberos library (whichever one
> Cyrus
> is compiled against), or perhaps with the way the security properties are
> passed down from OpenLDAP to Cyrus to Kerberos.

This error comes from MIT Kerberos which receives invalid config input from 
Cyrus SASL.

> Setting a minssf should not be necessary. Do you also get this error with
> "maxssf=0"? "maxssf=1" may be a more workable option, since encryption is
> really what you want to turn off, not integrity.

Yes, the error remains the same. Maxssf=1 does not help because integrity won't 
be disabled.
The encryption you are talking about is GSS confidentiality which won't be 
active anyway with
maxssf=1.

I read SASL's code and it is somewhat confusing. You cannot turn off integrity. 
See here:
https://github.com/Paaat/cyrus-sasl/blob/master/plugins/gssapi.c#L1585-L1597

/* 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;
            }
        }

This definitively deserves improvement, additionally, mutual auth should be 
enabled by default.

So, I wouldn't say that this is an error in OpenLDAP.

Michael

Reply via email to