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 <[email protected]> >>> wrote: >>>> User provides hash: >>>> >>>> <presence >>>> from='[email protected]/pda' >>>> to='[email protected]/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 ([email protected]) 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:[email protected] - xmpp:[email protected] >> - 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: [email protected] >> _______________________________________________ > > _______________________________________________ > JDev mailing list > Forum: http://www.jabberforum.org/forumdisplay.php?f=20 > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
