jabberd2 2.1.23+GSASL 0.2.25 incompatibility with Cyrus-based Pidgin 2.4.0

[marty]

Please refer to the following for details:

http://developer.pidgin.im/ticket/5213#comment:18

[smoku]

Following http://www.ietf.org/rfc/rfc2831.txt

charset This directive, if present, specifies that the server supports UTF-8 encoding for the username and password. If not present, the username and password must be encoded in ISO 8859-1 (of which US-ASCII is a subset). The directive is needed for backwards compatibility with HTTP Digest, which only supports ISO 8859-1. This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.

The server challenge you presented has charset=utf-8 present, so server expects you to reply using utf-8 charset.

[marty]

Reopening: Here is the problematic transaction. I don't see "charset=utf-8" being presented explicitly here in the challenge, as you said above. My apologies if I'm missing something...

(14:59:35) proxy: Connected to domain.com:5222.
(14:59:35) jabber: Sending: <?xml version='1.0' ?>
(14:59:35) jabber: Sending: <stream:stream to='domain.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(14:59:35) jabber: Recv (188): <?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' from='domain.com' version='1.0' id='qafvjk6oetojufbawfebo4uh0bchp6ofg3b0nhp2'>
(14:59:35) jabber: Recv (205): <stream:features xmlns:stream='http://etherx.jabber.org/streams'><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'><required/></starttls><auth xmlns='http://jabber.org/features/iq-auth'/></stream:features>
(14:59:35) jabber: Sending: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
(14:59:35) jabber: Recv (50): <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
(14:59:35) jabber: Sending (ssl): <stream:stream to='domain.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(14:59:35) jabber: Recv (ssl)(188): <?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' from='domain.com' version='1.0' id='ael5uxgqcu20zxi08uhy16di9oix680hmmnhj37v'>
(14:59:36) jabber: Recv (ssl)(260): <stream:features xmlns:stream='http://etherx.jabber.org/streams'><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>PLAIN</mechanism><mechanism>DIGEST-MD5</mechanism></mechanisms><auth xmlns='http://jabber.org/features/iq-auth'/></stream:features>
(14:59:36) sasl: Mechs found: PLAIN DIGEST-MD5 
(14:59:36) jabber: Sending (ssl): <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/>
(14:59:36) jabber: Recv (ssl)(216): <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>cmVhbG09Imxpbmtsb2NrZXIuY29tIiwgbm9uY2U9IkRQbHc0Y2NhanFKRjNOOWt3c0xpa3c9PSIsIHFvcD0iYXV0aCwgYXV0aC1pbnQiLCBjaGFyc2V0PXV0Zi04LCBhbGdvcml0aG09bWQ1LXNlc3M=</challenge>
(14:59:36) sasl: DIGEST-MD5 client step 2
(14:59:36) jabber: Sending (ssl): <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>dXNlcm5hbWU9Im1hcnR5IixyZWFsbT0ibGlua2xvY2tlci5jb20iLG5vbmNlPSJEUGx3NGNjYWpxSkYzTjlrd3NMaWt3PT0iLGNub25jZT0iWUZkRkNUY1pXU1UzSFVsRVVCUkFlMWwyR0NzV2Z6cC9ERkFNT0hjR2NpVT0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvbGlua2xvY2tlci5jb20iLHJlc3BvbnNlPTE1OWI2YWIyNGYwZjZmZDVhMzYwMGI5M2ZhYzBkMmQw</response>
(14:59:36) jabber: Recv (ssl)(80): <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><malformed-request/></failure>
(14:59:36) account: Disconnecting account 01844850
(14:59:36) connection: Disconnecting connection 018AD908
(14:59:36) connection: Destroying connection 018AD908

[smoku]

(14:59:36) jabber: Recv (ssl)(216): <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>cmVhbG09Imxpbmtsb2NrZXIuY29tIiwgbm9uY2U9IkRQbHc0Y2NhanFKRjNOOWt3c0xpa3c9PSIsIHFvcD0iYXV0aCwgYXV0aC1pbnQiLCBjaGFyc2V0PXV0Zi04LCBhbGdvcml0aG09bWQ1LXNlc3M=</challenge>

BASE64 encoded string is:

realm="linklocker.com", nonce="DPlw4ccajqJF3N9kwsLikw==", qop="auth, auth-int", charset=utf-8, algorithm=md5-sess

[marty]

thanks. sorry for the bother.

[marty]

FYI: deryni(pidgin) seems to have a different interpretation of RFC2831

Comment (by deryni):

"This directive, if present, specifies that the server supports UTF-8 encoding for the username and password." That says supports, not requires, it especially makes no claims about what the response data should look like, if you read farther down to where the response data is explained the rfc says (for username) "The user's name in the specified realm, encoded according to the value of the "charset" directive." which (also according to the rfc "should [only] send this directive ... if the server has indicated it supports UTF-8" "should" not "must" and further it states that "if [it is] not present, the username and password must be encoded in ISO 8859-1 (of which US-ASCII is a subset)" so I still maintain that rejecting a response without the charset directive is broken, and that with a US-ASCII-only password it should work just fine.

[marty]

After evaluating the text of the RFC2831, I agree with deryni's interpretation, and am re-opening this bug as an RFC noncompliance problem for jabberd2/gsasl.

In addition, the "should only send this directive" phrase is a restriction on the client's behavior in the context of a non-utf8 server. (ie. the client should NOT send this directive to a server that has _not_ indicated utf-8 support.) But, the converse is not necessarily true.

[smoku]

This problem should be filled against GnuSASL then.

Closing as not jabberd bug.

[marty]

I have sent a bug report to the bug-gsasl@… address.

However, since this bug is manifested within jabberd2 (jabberd2 exhibits the problem, even if it is due to libgsasl), I think this should be left open. (the one for Pidgin is invalid because Pidgin is behaving correctly. In this case, the bug is a valid one because jabberd2 is behaving incorrectly.)

It ought to be closed and verified when jabberd2 behaves correctly, which would be the result of one of the following things:

1) libgsasl gets fixed 2) jabberd2 uses a different sasl implementation with correct behavior

If you disagree, go ahead and close this. I will refrain from re-opening it.

[x]

It's not only about pidgin 2.4.0. I'm experiencing the same thing with 2.2.1.

[x]

A fix for this has been committed in gsasl: http://tinyurl.com/5muak9

Smoku, could you please install todays daily snapshot on chrome so we could test the fix? http://daily.josefsson.org/gsasl/gsasl-20080412.tar.gz

[smoku]

Looks like I encoutered it earlier: trunk/contrib/gsasl-charset-validate-fix.diff. I don't know why the submitted to gsasl upstream patch was ignored.

[smoku]

OK. The new gsasl (0.2.26) is running on Chrome.pl.

[x]

Unfortunately the authentication failure persisted for:

• pidgin 2.2.1
• gajim 0.11.4
• gossip 0.26

Connection worked for:

• psi 0.10
• gabber 1.9.4.3

[scottchiefbaker]

I can confirm that gsasl-20080412.tar.gz does not solve the login problem. My local jabber server here exhibits the same login problems with pidgin as the previous version. Kopete still works fine.

[x]

The problem with gsasl authorisation seems to be caused by improper handling of the user name. See attached patch. Strangely compiler shows no error even if the variable username is undeclared before the first use.

Smoku, if you could apply this patch we should have chrome fully operational again.

[x]

Fix for authorisation with ASCII client response.

[smoku]

The patched gsasl 0.2.26 is running on chrome.pl. Please check whether it works now.

[x]

It works! I can connect with all clients now. Many thanks.

The patch has been reported to gsasl and should land in an official 0.2.26 release soon.

[smoku]

In [562]: Required gsasl 0.2.26 version for proper DIGEST-MD5 implementation. Added gsasl patch in contrib. Refs #200