955220 - SASL auth fails when using a grouped nick (but not the first of the group)

Status: NEW

(Chat Core :: IRC, defect)

Description

[aleth [:aleth]]

*** Original post on bio 1788 at 2012-11-10 13:08:00 UTC ***

This might require an advanced account option.

We also write some misleading warning/error messages to the console in this case, and send CAP END twice.

Is it possible one of the two nicknames we send on AUTHENTICATE shoudl be the first grouped nick?
http://lxr.instantbird.org/instantbird/source/chat/protocols/irc/ircSASL.jsm#34

Comment 1

[aleth [:aleth]]

*** Original post on bio 1788 at 2012-11-10 13:30:25 UTC ***

Relevant part of the log:
...
irc: :morgan.freenode.net CAP * LS :account-notify extended-join identify-msg multi-prefix sasl
irc: Sending:
CAP REQ sasl
...
irc: :morgan.freenode.net CAP testtb ACK :sasl
irc: Sending:
AUTHENTICATE PLAIN
irc: AUTHENTICATE +
irc: Sending:
AUTHENTICATE (...)
irc: :morgan.freenode.net 904 testtb :SASL authentication failed
irc: The server does not support SASL PLAIN authentication.
irc: Sending:
CAP END
irc: :morgan.freenode.net 906 testtb :SASL authentication aborted
irc: Registration completed before SASL authentication completed.
irc: Sending:
CAP END
irc: :morgan.freenode.net 001 testtb :Welcome to the freenode Internet Relay Chat Network testtb
irc: Sending:
IDENTIFY <password not logged>

Comment 2

[aleth [:aleth]]

*** Original post on bio 1788 at 2012-11-10 14:46:51 UTC ***

As far as the error messages go, for 904 I suggest "The server does not support SASL PLAIN auth" -> "SASL authentication failed", as it doesn't jump to conclusions. For 906 we should also not conclude that the registration is completed (in this case it clearly was not). I don't think sending CAP END twice is a problem.

According to the SASL PLAIN spec, the AUTHENTICATE parameters are "the authorization identity (identity to act as), followed by a NUL (U+0000) character, followed by the authentication identity (identity whose password will be used), followed by a NUL (U+0000) character, followed by the clear-text password."
https://www.ietf.org/rfc/rfc4616.txt
It seems that for a grouped nick we should be sending the first grouped password as the authentication identity. For this we would have to have it/store it in the first place of course.

Comment 3

[Patrick Cloke [:clokep]]

*** Original post on bio 1788 at 2012-11-12 00:04:21 UTC ***

This needs to wait until after 1.3. I'll take a look at this soon.

Comment 4

[Patrick Cloke [:clokep]]

*** Original post on bio 1788 at 2013-01-08 20:27:32 UTC ***

Maybe this is usful: Pidgin report with the same issue https://developer.pidgin.im/ticket/15451 (obviously the patch wouldn't be useful, but maybe an idea of how to fix it would be...)

Comment 5

[Patrick Cloke [:clokep]]

I don't see any way around having the user supply the identity they wish to authenticate as. I'm fairly loath to do this, but what do people think?

Comment 6

[Florian Quèze [:florian]]

For future reference, the IRC conversation we had after comment 5:

Florian: I think it really depends what we mean by "fix". The nick gets identified successfully, so it's not really a problem; the really annoying part of the bug IMHO is that we are putting very misleading error messages in the console, if we could just make what reaches the console match reality, that would already be a huge step forward.

clokep: Alright. Yeah, I obviously misunderstood one of the statements in the spec when I initially implemented it.