[jdev] Alternate MUC Authentication Mechanisms

[Kurt Zeilenga]

On Oct 13, 2010, at 4:23 PM, Alex Milowski wrote:

> I've been playing around with Multi-user Chat and I'm wondering if anyone has experience with extending the protocol to include alternate room password mechanisms?  Specifically, I'm interest in using something like digest authentication in conjunction with signed stanzas.  I'd like to have better guarantees on who is actually in the room.

While one has to demonstrate they know the MUC room password to join, this demonstration does not authenticate who they are.  Presently, the MUC service relies on the subscriber's server to authenticate the subscriber's identity in processing of identity-based access controls.

Today's XMPP services places a fair amount of trust in the subscriber's server.  If we want not to trust the subscriber's server as much as we today, protecting the MUC password is the least of our worries.  So I'm going to assume there are other risks that one desires to mitigate here by using a 'digest' method for proving one knows the room's password.

For instance, there is the risk that the password could be sniffed off the unencrypted passwords and be used to gain access to rooms not protected by identity-based access controls.

So one could extend the MUC specification to allow assertion of a hash over the password and subscribingJID.  This would effectively block eavesdroppers from gaining access to the plain text password, and replay risk is limited to entities we already trust (namely the subscriber's server).

One could extend the MUC service to support such hashes fairly easy.

I note that SASL is about identity proof.  Since the room password is not about identity proof, SASL itself doesn't seem applicable here, though I guess one could (ab)use it here if they like.

-- Kurt

> 
> --Alex Milowski
> 
> _______________________________________________
> 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
> _______________________________________________