[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: How to disable SSF (integrity) on GSSAPI mech?



> 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