XMPP-SASL: plain text authentication fails

jense

2008-03-12, 15:07 #1

Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members

Show profile ·

Link to this post

Subject: XMPP-SASL: plain text authentication fails

After changing unb_lib/jabber2.lib.php:

@@ -345,9 +345,9 @@
# http://www.xmpp.org/extensions/attic/jep-0078-1.7.html
# The plaintext mechanism SHOULD NOT be used unless the underlying stream is encrypted (using SSL or TLS)
# and the client has verified that the server certificate is signed by a trusted certificate authority.
- } else if (in_array('PLAIN', $methods) && (isset($this->session['ssl']) || isset($this->session['tls']))) {
+ } else if (in_array('PLAIN', $methods)/* && (isset($this->session['ssl']) || isset($this->session['tls']))*/) {
$this->send("<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'>"
- . base64_encode(chr(0) . $this->user . '@' . $this->server . chr(0) . $this->password) .
+ . base64_encode(chr(0) . $this->user/* . '@' . $this->server*/ . chr(0) . $this->password) .
"</auth>");
} else if (in_array('ANONYMOUS', $methods)) {
$this->send("<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='ANONYMOUS'/>");

it works (cf. jingle client authentication error in jabber server).

The first change respects the `SHOULD NOT' in the specification (it does not read `MUST NOT').

Alala, Alala, Gimme three wishes - CSS

Yves (Administrator) 2008-03-12, 18:37 #2

User title: UNB developer & webmaster
Member since Jan 2004 · 3855 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members

Show profile ·

Link to this post

Okay... I had no problem with it and don't fully understand in what situations it could become a problem... but it doesn't seem to hurt either.

♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬

jense

2008-03-13, 11:26 #3

Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members

Show profile ·

Link to this post

The first change is harmless because it just allows an authentication method that has been previously advertised by the server. The original implementation has been overly cautious in not supporting this mode. * sigh * user-friendly still means clear text passwords over unencrypted streams nowadays...

The second change follows the recommendation in RFC 3920, Section 6.1:

6. If provision of a "simple username" is supported by the selected SASL mechanism (e.g., this is supported by the DIGEST-MD5 and CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI mechanisms), during authentication the initiating entity SHOULD provide as the simple username its sending domain (IP address or fully qualified domain name as contained in a domain identifier) in the case of server-to-server communications or its registered account name (user or node name as contained in an XMPP node identifier) in the case of client-to-server communications.

Plain SASL is defined in RFC 4616.

Now, I know why it's hard to implement this beast...

Alala, Alala, Gimme three wishes - CSS