So my previous suggestion was subject to a limited replay attack. In particular, someone who was able to hijack the C2S, S2S, or the intermediate server could do a replay. Here's another suggestion that eliminates this replay attack and doesn't require any additional roadtrips.
This would look something like: <iq from='[email protected]/pda' id='disco3' to='[email protected]' type='get'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq> <iq from='[email protected]' id='disco3' to='[email protected]/pda' type='result'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='conference' name='A Dark Cave' type='text'/> <feature var='http://jabber.org/protocol/muc'/> <feature var='muc_cr_protected'/> <challenge xmlns='http://jabber.org/protocol/muc/cr' algorithm="cr-sha2" challenge-attributes="" /> </query> </iq> No hash provided: <presence from='[email protected]' to='[email protected]/pda' type='error'> <x xmlns='http://jabber.org/protocol/muc'/> <error type='auth'> <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </presence> User provides hash: <presence from='[email protected]/pda' to='[email protected]/thirdwitch'> <x xmlns='http://jabber.org/protocol/muc'> <response xmlns='http://jabber.org/protocol/muc/hash' algorithm="cr-sha2" response-attributes="" />response</response> </x> </presence> This would support any single round-trip challenge-response algorithm, with salts, nonces, and whatever other goodies one might want in the non-cleartext mechanism. I would suggest something loosely based on SCRAM. That is, a one-roundtrip version of SCRAM (no mutual auth, no channel binding). This would should be more than sufficient to mitigate the threat posed by eavesdroppers, would not be subject to replay attack. Of course, like most of the suggestions discussed in this thread, this would be subject to various hijack attacks. In particular, if an attacker can hijack the S2S session in/out of the MUC service or the subscribers C2S session, the attacker can then downgrade the disco advertisement to muc_password, wait for the client to respond, and win the password. If folks were interested in such a single-roundtrip approach, I would be willing to draft an XEP on this. -- Kurt _______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
