[Standards] Password protected rooms

Pavel Simerda pavlix at pavlix.net
Wed Feb 11 13:39:51 UTC 2009

On Wed, 11 Feb 2009 04:58:01 -0800
Kurt Zeilenga <Kurt.Zeilenga at isode.com> wrote:

> On Feb 10, 2009, at 11:25 PM, Kevin Smith wrote:
> > On Tue, Feb 10, 2009 at 11:02 PM, Kurt Zeilenga
> > <Kurt.Zeilenga at isode.com 
> > > wrote:
> >> It seems not so sensible when the admin happens to be
> >> authenticating directly to the server hosting the chatroom.  But
> >> for the case where the
> >> administrator authenticates elsewhere, possibly to a server under  
> >> separate
> >> administrative control, (to the extent that password protected  
> >> rooms are at
> >> all sensible) it seems at least reasonable for a server to be  
> >> allowed to
> >> require the administrator know the password.
> >
> > If we assume secure s2s, it seems that requiring the muc owner know
> > a password only protects against a compromised (or maliciously
> > adminned) server where the user can be impersonated by the server
> > admin. Given that the muc password is sent in plaintext, a
> > compromised server could pull this out of the stream anyway, so
> > does it buy us much to require a password for the muc owner?
> I'm thinking more about a non-comprised server case, but just the
> case of poor administrative practices.
> Say the owner's account was deleted by his site's admin, and then
> that account name was reassigned to some other person.  Now a
> different person is in control of the owner's account.  This person
> might know or discover his account has ownership rights on various
> chatrooms and abuse those rights.

I would propose to solve this issue differently and completely, not
just for this special case.

> So I wonder if the password mechanism might be a way of mitigating  
> risks associated with such administrative practices.

Though passwords might help, IMO it's not the best solution
(e.g. a UUID published with the presence or elsewhere would do
much much better). Admin's password is rather inconvenient.

An admin's password may help to re-acquire adminship with a new JID,
though, but that would be better solved by more general
*authentication* and *authorization* that would both allow reuse
for other purposes (not only MUC) and could be much more flexible
(with regard to authentication mechanisms).

> Server implementations can add features to deal with this problem
> with both the owner and chat room are hosted on the same server, but
> I don't know any way of deal well this in the remote case except by  
> authentication of owner to room.

Easy, just add authentication :). But remember, if you want to maintain
at least some real security, you'd not only authenticate the remote
user, but also maintain integrity of all incoming data.

Please move to the security list if interested in further
authentication/authorization discussion.


> Now one can argue that the password does nothing to specifically  
> authenticate the owner, so maybe the password doesn't well mitigate  
> the risk.
> -- Kurt


Pavel Šimerda
Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti
Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

More information about the Standards mailing list