[jdev] Alternate MUC Authentication Mechanisms

[Kurt Zeilenga]

On Oct 21, 2010, at 12:08 PM, Alex Milowski wrote:

> On Wed, Oct 20, 2010 at 3:29 PM, Kurt Zeilenga <Kurt.Zeilenga at isode.com> wrote:
>> 
>> If the former, however, I would have significant reservations.   SASL mechanisms such as SCRAM is commonly used to authenticate the user's identity to an application service, they are not intended to be used to establish who knows a password shared amongst many users.   How would a user know whether to which identity/password, their personal subscriber password or the room's, to use in computing the challenge responses?  If this was going to be done, I'd argue that the identity they should assert is the room's jid (versus any identity string specific to the subscriber).
>> 
> 
> You could use the same argument against HTTP DIGEST authentication
> over https but it is well known that DIGEST is a much better choice
> and offers better security in a number of ways.

What?  I take no issue with use of Digest over a TLS protected stream.

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.

Now, if one were to establish a TLS stream between the subscriber and the MUC service, I'd have little problem with use of SASL in that stream (preferable a mechanism which provided channel bindings).

> 
> Most simply, I want to be able to use something like DIGEST
> authentication to keep the shared secret from being exposed.  I think
> that is a simple request that is fairly straightforward to accomodate.

I think there are complications, see above.

>  A simple hash scheme doesn't protect against replay attacks and so
> we do need the challenge in the mix somehow.

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.

-- Kurt

> 
> 
> -- 
> --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: JDev-unsubscribe at jabber.org
> _______________________________________________