[jdev] Alternate MUC Authentication Mechanisms

[Kurt Zeilenga]

On Oct 20, 2010, at 6:39 AM, Kurt Zeilenga wrote:

> 
> On Oct 20, 2010, at 1:11 AM, Dave Cridland wrote:
> 
>> 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.
> 
> For a particular subscribers bare jid and room bare jid.
> 
>> That's protecting you from a different user joining, but someone able to spoof the user can just blindly resend the hash.
> 
> Well, that's a 'duh'.

and if a significant concern, a time stamp could be added to hinder replay.


> As I noted in my post, if you don't trust servers to a significant degree, you have bigger things to worry about.
> 
>> If you sign stanzas, on the other hand, the hash is pointless.
> 
> And that's actually solving a different problem.  That is, the OP didn't want identity-based access controls, but just better protection of transmissions of a shared secret.
> 
> And I have to note that signing itself is only as good as the key management system behind it, which has yet to be discussed or detailed.   It may be best not to make great assumptions on the value of signing just yet.
> 
>> 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.
> 
> Generally speaking, I concur.  I was just throwing up a strawman which seems to address the desire to better protect the transmission of the shared secret.
>> 
>> 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.
> 
> I would argue that if this be the case, you better off jumping to encrypted tunnel between the client and the MUC service.
> 
>> 
>> c) You don't trust the servers/administrators.
> 
> My answer to b helps with lack of trust of the subscribers' servers.   But if you don't trust the MUC server itself, then you are really screwed.
> 
>> 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
>> _______________________________________________
>> 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
>> _______________________________________________
> 
> _______________________________________________
> 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
> _______________________________________________