[jdev] Alternate MUC Authentication Mechanisms

[Dave Cridland]

On Thu Oct 21 23:58:22 2010, Alex Milowski wrote:
> 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.

Well, I think that's really my point, right there.

Given an attacker who is in a position to hijack C2S or S2S streams  
and inject stanzas, mere replacement of a plaintext method with even  
a challenge/response-based hash method doesn't appear to change the  
security issues of MUC all that much at all.

All, in fact, it protects against (that a plaintext password doesn't)  
is that a purely passive easvesdropper cannot acquire the password.  
But if that's your sole threat, then Kurt's original salted hash is  
fine, sans timestamp.

On the other hand, if you're concerned about tampering with the  
stanzas between the client and the service to any degree, then of  
course you note Kurt's hash replays. But, equally, so does all the  
other traffic, allowing someone to hijack a stream and inject any  
other traffic they choose the moment their victim has joined, leaving  
all the traffic in the MUC - that presumably you're trying to  
establish trust for - vulnerable to a wide range of attacks.

To put it another way, even if you proof the join request against  
replay and spoofing, such that it becomes a (mythical) perfectly  
secure operation, it'll still be rather like having a six-inch thick  
steel front door but leaving all your windows open.

Therefore, in order to minimize round-trips and provide security, you  
need to:

1) Sign all the stanzas with a certificate trusted by the MUC service.

2) Arrange some mechanism for provisioning that certificate. (Which  
might be a prearranged common trust anchor, or some mechanism whereby  
the client authenticates in a more complex manner with the MUC  
service as a one-off to agree on, or sign, a certificate.)

It's this latter case where I propose using SASL, not in the MUC join.

I'm not saying, by the way, that I feel this model is at all  
sensible. I think it's a fantastic overkill. But it's a sensible  
option *if* you think the threat model includes a likely injection  
attack, including replay.

This is why I've been trying to figure out exactly what your threat  
model is - that is, what potential attacks you're attempting to  
protect against - in order to figure out how far we need to go to  
mitigate those attacks.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade