On Thu, Oct 21, 2010 at 3:53 PM, Kurt Zeilenga <[email protected]> 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 _______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
