[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.

-Justin



More information about the Standards mailing list