XMPP disconnect causes inability to reconnect

[akrherz]

When I get disconnected from my Openfire Jabber server, or get disconnected, there is no way to get connected back in. Will just get an endless stream of "Not Authorized". I'm attaching debug log.

Am seeing this on 2.0.2 on RHEL5 and WinXP.

thanks!

[akrherz]

pidgin -d logfile

[akrherz]

I was sort of vague there, sorry. The reproducer is:

1. Enable XMPP account 2. Disable the account 3. Enable the account and get "Not Authorized" no matter what I try.

[datallah]

Perhaps we should handle <failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><not-authorized/></failure> as a "wants to die" error and not keep trying.

The fact that this error is occurring doesn't appear to be caused by Pidgin doing something wrong (does the server still think the original connection is valid and is disallowing multiple connections or something?).

[akrherz]

Thanks for the response.

I should clarify that I only get the Not Authorized once every time I try to reconnect after the initial disconnect. I tried resetting the password and such and always get the Not Authorized back again. The only remedy is to restart Pidgin and it works again.

Trying it now. I connect and Openfire shows the connection. In pidgin, I disable the account and Openfire shows no connection, but netstat shows a connection in TIME_WAIT status. I wait for that to go away and I can reconnect!!

If I try to disable and enable too quickly, I get the "Not Athorized"!

Hmmm, I've been doing this for years and haven't noticed this before. Hmmm

[akrherz]

Hmmm, now I am getting that message each time, even if netstat shows no connection on both client and server side.

[kopernikus]

Same here. After disconnect, Pidgin isn't able to reconnect anymore. Server is running wildfire. Pidgin 2.1.0/Debian sid

wildfire log:

2007.08.02 19:30:47 SaslException
javax.security.sasl.SaslException: DIGEST-MD5 must not have an initial response
at com.sun.security.sasl.digest.DigestMD5Server.evaluateResponse(Unknown Source)
at org.jivesoftware.wildfire.net.SASLAuthentication.handle(SASLAuthentication.java:205)
at org.jivesoftware.wildfire.net.SocketReadingMode.authenticateClient(SocketReadingMode.java:117)
at org.jivesoftware.wildfire.net.BlockingReadingMode.readStream(BlockingReadingMode.java:136)
at org.jivesoftware.wildfire.net.BlockingReadingMode.run(BlockingReadingMode.java:62)
at org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:123)
at java.lang.Thread.run(Unknown Source)

Pidgin or wildfire bug?

[deryni]

Pidgin is attempting to send initial data in the DIGEST-MD5 auth packet and wildfire is not liking that, I'm not sure who is at fault here or if that is in fact not allowed as wildfire is claiming, I don't know enough about SASL auth to say.

[akrherz]

Hi,

Any updates on this? Should I bug the Openfire guys about it?

daryl

[akrherz]

Hi,

The Openfire forum post that corresponds to this is:

http://www.igniterealtime.org/community/thread/28577

daryl

[deryni]

Ok, so I just did a little bit of digging into SASL and the use of it in XMPP and it looks to me like the java SASL implementation is just wrong.

Given

RFC3920 Section 6.2 Point 3: The initiating entity selects a mechanism by sending an <auth/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving entity and including an appropriate value for the 'mechanism' attribute. This element MAY contain XML character data (in SASL terminology, the "initial response") if the mechanism supports or requires it; if the initiating entity needs to send a zero-length initial response, it MUST transmit the response as a single equals sign ("="), which indicates that the response is present but contains no data.

and

RFC2831 Section 2.2 (specifically 2.2.1): The client uses the values from the previous authentication and sends an initial response with a string formatted and computed according to the rules for a "digest-response", as defined above, but with a nonce-count one greater than used in the last "digest-response".

It appears to me that Cyrus is attempting to do that shorter authentication and that the java SASL can't handle it.

All that being said, it is entirely possible that there is some level of SASL configuration which allows for having turned that shorter method off, if there is such a thing and the java SASL is setting it than Cyrus is broken. But this is well beyond my level of knowledge.

[deryni]

So I just finished talking to a couple of people in the jdev@… chat room and as far as they all believe the Java SASL bits that Openfire is using is broken and initial data is allowable in the DIGEST-MD5 mechanism. I would suggest you file a bug with the Openfire folks about this. You can reference this ticket there and direct them to me/the devel list if they have questions. With that I'm going to close this ticket as I believe there isn't anything for us to do here.

[deryni]

For the record (because someone in the Ignite Realtime forums commented on this) the 'Using Digest Authentication as a SASL Mechanism' RFC (2831) specifies what the server should do if it doesn't support subsequent authentication, what it should do if the client gets the subsequent auth wrong, and even what to do if it just decides it doesn't like the subsequent auth that happened. None of those methods are what the Java SASL library is doing.

From the RFC:

2.2.2 Step Two

The server receives the "digest-response". If the server does not support subsequent authentication, then it sends a "digest-challenge", and authentication proceeds as in initial authentication. If the server has no saved nonce and nonce-count from a previous authentication, then it sends a "digest-challenge", and authentication proceeds as in initial authentication. Otherwise, the server validates the "digest-response", checks that the nonce-count is one greater than that used in the previous authentication using that nonce, and saves the new value of nonce-count.

If the response is invalid, then the server sends a "digest-challenge", and authentication proceeds as in initial authentication (and should be configurable to log an authentication failure in some sort of security audit log, since the failure may be a symptom of an attack). The nonce-count MUST NOT be incremented in this case: to do so would allow a denial of service attack by sending an out-of-order nonce-count.

If the response is valid, the server MAY choose to deem that authentication has succeeded. However, if it has been too long since the previous authentication, or for any other reason, the server MAY send a new "digest-challenge" with a new value for nonce. The challenge MAY contain a "stale" directive with value "true", which says that the client may respond to the challenge using the password it used in the previous response; otherwise, the client must solicit the password anew from the user. This permits the server to make sure that the user has presented their password recently. (The directive name refers to the previous nonce being stale, not to the last use of the password.) Except for the handling of "stale", after sending the "digest-challenge" authentication proceeds as in the case of initial authentication.

[evands@…]

(In [f6430c7013d08f95c60248eeb22c752a0107499b]) The DIGEST-MD5 implementation of CYRUS-SASL is incompatible with the implementation in Java. The result is that we failed to authenticate to Java-based servers such as OpenFire? when DIGEST-MD5 was enabled. This appears to be the result of a bug in the Java SASL library. While we -could- wait for a fix within that library and tell our users that server admins need to upgrade to get the fix, a client-side workaround is very easily accessible to us.

Our own implementation (used when compiled with SASL support) works fine. We therefore will make use of it when SASL chooses DIGEST-MD5 as the best auth mechanism.

Fixes #2095. Fixes #2186. Also fixes http://trac.adiumx.com/ticket/8135.

[nosnilmot]

I reverted the proposed fix, because a) it's a hack, and b) it caused crashes. Can anyone confirm this is actually still a problem with a more recent OpenFire? (eg. 3.4.1)?

[akrherz]

Hi,

Thanks for looking into this!

I just tested things. And this "bug" appears with Openfire 3.3.1, but doesn't appear with Openfire 3.4.1 . So perhaps it is fixed on Openfire's end now?

daryl

[deryni]

Yes, the Openfire people have inserted a hack on their end to work around the fact that the Java DIGEST-MD5 implementation is just broken. I'm going to close this because I don't think we should be working around an absolutely broken implementation.