jabber + sasl/gssapi (was: [Gaim-commits] CVS: gaim/src/protocols/jabber auth.c, 1.42, 1.43)

[Simon Wilkinson]

On 24 Oct 2007, at 21:12, Stu Tomlinson wrote:

> (this is a late reply ;-) )
>
> This hunk of this patch...:
>                 case SASL_CB_USER:
> -                       *res = js->user->node;
> +                       *res = "";
>
> ... seems to break cyrus sasl GSSAPI authentication with Openfire (and
> possibly others?). Reverting this alone makes GSSAPI auth WorkForMe
> (tm). This is also reported as an Openfire issue :
> http://www.igniterealtime.org/issues/browse/JM-1060
>
> Is that change absolutely required for PLAIN to work with cyrus  
> sasl, or
> can we safely revert it?

The change is in relation to whether you send an authorization  
identity, or not. In general, where the authorization identity can be  
derived from the authentication identity, the authz identity should  
not be sent. Unfortunately, SASL's interaction with Jabber is poorly  
enough specified that it's not clear when this is the case (is the  
authorization identity the username, or the JID, for example) We're  
still sending an authentication identity (in response to the AUTHNAME  
callback), which is why this should work for the trivial case.

However, other bits of this patch appear to be interesting

>> @@ -192,17 +192,15 @@ static void jabber_auth_start_cyrus(Jabb
>>  	/* Set up security properties and options */
>>  	secprops.min_ssf = 0;
>>  	secprops.security_flags = SASL_SEC_NOANONYMOUS;
>> +	secprops.max_ssf = -1;
>> +	secprops.maxbufsize = -1;
>>
>>  	if (!js->gsc) {
>>  		plaintext = gaim_account_get_bool(js->gc->account,  
>> "auth_plain_in_clear", FALSE);
>>  		if (!plaintext)
>>  			secprops.security_flags |= SASL_SEC_NOPLAINTEXT;
>> -		secprops.max_ssf = -1;
>> -		secprops.maxbufsize = 4096;
>>  	} else {
>>  		plaintext = TRUE;
>> -		secprops.max_ssf = 0;
>> -		secprops.maxbufsize = 0;
>>  	}
>>  	secprops.property_names = 0;
>>  	secprops.property_values = 0;

This enables security layers for both SSL and normal connections.  
Does the security layer chaining now work correctly with SSL  
connections?

Cheers,

Simon.