[jdev] Alternate MUC Authentication Mechanisms

[Alex Milowski]

On Thu, Oct 21, 2010 at 3:53 PM, Kurt Zeilenga <Kurt.Zeilenga at isode.com> wrote:
>
> I have number of concerns.
>
> I am concerned that a client or the user would not know why SASL authentication was being offered, what id to use, etc..   Aside from user confusion, I fear attackers will actually highjack the S2S connections between the S2S server and the MUC server, offer SASL/PLAIN (or terribly weak mechanism) to the clients in hopes users will enter the password they use to authenticate to their server.
>
> I rather not open such attack doors.

I'm not sure we are talking about the same thing.  I want to use
something like DIGEST
authentication to send the *room* credentials and not the user's credentials.

I don't see how having a non-cleartext authentication mechanism for
MUC rooms changes any security issues that might already be present
via a MUC room service.


>
> As previously noted in this thread, one can mitigate replay attacks by including a timestamp in the hash (as well as subscriber and room jids)... and the replay can only be mounted by someone who takes control of the subscriber's server or S2S sessions or C2S sessions.  If an attacker has comprised the system to the point of being able to replay, they generally would have the ability to mount a wide range of attacks which SASL authentication by itself will do little to protect against.

That's the point of using a nonce and other aspects of various
challenge base authentication mechanism.  I don't see why we would
develop a new method.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics