SASL quoted charset

Openfire Openfire Dev
1

I was trying to get pyxmpp to work against my wildfire server. It worked against ejabberd at first attempt but failed with a sash authentication error when I tried it against wildfire. After some debugging help from Jajcus, he found that Wildfire sends the charset quoted. Examples from debug logs:

Ejabberd gave these lines:

IN: "’’

‘‘realm’’: ‘’“gazonk.cdr.se”’’

‘‘nonce’’: ‘’“661ZnPk/9XJj/jFQF25UaHJCizA8MTtwyhRlkdxA”’’

‘‘qop’’: ‘’“auth”’’

‘‘charset’’: ‘’“utf-8”’’

The rfc seems to indicate that it should be without quotes. Is it something that requires a wildfire change?

2

What RFC states this and where? There are so many out there, I couldnt track this one down. Also, what sasl mechanism is being used here?

3

I did not find it explicit in any rfc either, but in 3920 all examples got some strings in quotes and other data without quote, the charset is without quotes all the time. For example in section 6.5, step 5. The mechanism is DIGEST-MD5.

4

Ok, DIGEST-MD5 is defined in rfc 2831. Take a look at section 2.1.1, its pretty clear what elements should have double quotes around them and which should not. You are correct, charset should not have quotes. The probem is, Java is handling this SASL mechanism, so this appears to be a bug in Java itself. What release of java are you using?

5

I use sun-jdk 1.5.0.07, it seems to be the latest stable 1.5 java available for my platform.

6

I dont have the time to verify it myself, but someone could write a simple java app using http://java.sun.com/j2se/1.5.0/docs/guide/security/sasl/sasl-refguide.html as an example, and just spit out whats going on. If we can prove its a problem in Java, perhaps the Jive guys can submit a bug report to them? Seeing as Sun is a customer of Jive, I would think they can hold more weight than one of us on our own.

7

There seem to be an old closed bug at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4414072 which among other problems seem to describe issues related to this.

For example, “3. some outgoing tokens are not being treated as quoted string values as per spec”. I wonder if they overdid the quoted strings?

8

I wouldnt be suprised if they did. You might give the Java 6 beta a try and see if the overcorrection has been corrected there.

9

Part of this wildfire thread might be related: http://www.jivesoftware.org/community/message.jspa?messageID=114416

10

I don’'t seem to be able to edit my own posts so I reply to myself yet again.

Also this thread might be related.

http://www.jivesoftware.org/community/message.jspa?messageID=124371

Maybe this thread can help getting a bug report away to Sun.

11

Maybe this can be verified at the interop event? I assume the Sun xmpp server is also written in Java and might have the same problem. And maybe Sun listens to in-house bug reports even more than external.

Any thoughts from jive?

12

Jay is right. The (encoded) content of the challenge is not being created by Wildfire but Java itself. This is a good point to be mentioned in the interop event. Good idea.

Regards,

– Gato