[jdev] Alternate MUC Authentication Mechanisms

[Dave Cridland]

On Wed Oct 20 01:47:58 2010, Alex Milowski wrote:
> On Sun, Oct 17, 2010 at 5:32 AM, Kurt Zeilenga  
> <Kurt.Zeilenga at isode.com> wrote:
> 
> > User provides hash:
> >
> > <presence
> >    from='hag66 at shakespeare.lit/pda'
> >    to='darkcave at chat.shakespeare.lit/thirdwitch'>
> >  <x xmlns='http://jabber.org/protocol/muc'>
> >    <hash algorithm="sha2">hash</hash>
> >  </x>
> > </presence>
> >
> > where hash was the base64 encoded sha2 hash over the concat of  
> subscribers' normalized bare jid, " ", the room's normalized bare  
> jid, " ", and the shared password.
> 
> 
> Yes, this is something like what I'm after.  I'm not really looking  
> to
> have individual identities authenticate.  Instead, I'm looking for a
> more secure way to send the shared credentials for the room.
> 
> 
At the risk of somewhat contradicting my colleague...

That's equally (in)secure, since the hash is a plaintext equivalent.  
That's protecting you from a different user joining, but someone able  
to spoof the user can just blindly resend the hash. If you sign  
stanzas, on the other hand, the hash is pointless.

I suppose there's three cases:

a) You trust the servers/administrators, and trust them to be doing  
TLS (to at least prevent eavesdropping, which requires endpoint  
authentication), such that MITMs are not practical. In this case, the  
current plaintext password seems OK.

b) You trust the servers/administrators, but you consider an MITM on  
S2S (or C2S, I suppose) to be a threat. In this case, a simple hash  
allows a replay, and offers little beyond the password, and signed  
stanzas are required. As noted above, if you already sign the  
stanzas, then any "password" is pointless.

c) You don't trust the servers/administrators. In principle, such a  
situation might well lead to the wrong certificate being provisioned,  
but either way, signing/encrypting stanzas is effectively your only  
way out now.

In order to provision a certificate, you could consider one of:

1) The MUC runs (or has access to ) a CA, and you sign a CSR provided  
during registration.

2) The MUC has shared Trust Anchors with the users.

3) The MUC is supplied with a certificate (possibly self-signed)  
during registration.

In either 1/3, then one assumes that you would need some other  
credential during registration - this is where I'd envision using  
SASL, to buy you reasonable password (or shared-secret) based  
protection without trying to hack it into the MUC join presence.

> I suppose this should be shared on the muc list (muc at xmpp.org) but I
> haven't heard much come across that yet.

There's also a security list, which might be more useful for this.

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