Not logged in. · Lost password · Register
Forum: Support Bug reports and troubleshooting RSS
XMPP-SASL: plain text authentication fails
jense #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:
  1. @@ -345,9 +345,9 @@
  2.                      # http://www.xmpp.org/extensions/attic/jep-0078-1.7.html
  3.                      # The plaintext mechanism SHOULD NOT be used unless the underlying stream is encrypted (using SSL or TLS)
  4.                      # and the client has verified that the server certificate is signed by a trusted certificate authority.
  5. -                    } else if (in_array('PLAIN', $methods) && (isset($this->session['ssl']) || isset($this->session['tls']))) {
  6. +                    } else if (in_array('PLAIN', $methods)/* && (isset($this->session['ssl']) || isset($this->session['tls']))*/) {
  7.                          $this->send("<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'>"
  8. -                                      . base64_encode(chr(0) . $this->user . '@' . $this->server . chr(0) . $this->password) .
  9. +                                      . base64_encode(chr(0) . $this->user/* . '@' . $this->server*/ . chr(0) . $this->password) .
  10.                                      "</auth>");
  11.                      } else if (in_array('ANONYMOUS', $methods)) {
  12.                          $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
Avatar
Yves (Administrator) #2
User title: UNB developer & webmaster
Member since Jan 2004 · 3864 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 #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
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Go to forum
This board is powered by the Unclassified NewsBoard software, 20120620-dev, © 2003-2011 by Yves Goergen
Page created in 160.9 ms (114.6 ms) · 56 database queries in 98.9 ms
Current time: 2014-11-23, 05:16:50 (UTC +01:00)