[Standards] Major issues when using SOCKS (XEP-0065) in a muc

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Thu Mar 5 16:39:52 UTC 2009

On Thursday 05 March 2009 05:45:09 Guillaume Desmottes wrote:
> First, the XEP is unclear about JID's usage when trying to establish a
> bytestream with a muc contact (for example to send him a file).

Yes, S5B is totally busted with MUC JIDs.  We mostly brushed this off, saying 
that you have to use real JIDs.  I think it is not unreasonable to require 
using real JIDs for a P2P connection, if only we had a better way of 
communicating the JIDs (e.g. trading them in the file transfer exchange, 
rather than requiring a non-anonymous MUC).

> C) When activation failed (or if the initiator can't connect to the
> proxy for any reason), the initiator is never informed of the failure
> and think the bytestream is open.

You mean the target is never informed.

> A) We should always MUC JID's so we don't restrict ourself to
> non-anonymous muc.

Do we have to require their use?  Is there a harm in using real JIDs even if 
both peers are in a MUC?  I don't think this needs to be specified.

> B) The activation IQ should contain the initiator JID instead of
> assuming it from the "from" attribute of the IQ.

This may be fine, but, does it open up any security issues?  People hijacking 
proxy connections by spoofing initiator JIDs?

> C) We should add an extra IQ round trip between the initiator and the
> target. Once the initiator got the activation IQ reply, he sends an IQ
> to the initiator to inform him of the success (or failure) of the
> operation. The target shouldn't consider the bytestream as open while he
> don't receive this IQ.

I'd have to think more about this, but maybe it's fine.

Of course, your modifications would have to be optional extensions, to ensure 
backwards compatibility.


More information about the Standards mailing list