[Standards] XEP-0065 hashes

Peter Saint-Andre stpeter at stpeter.im
Fri Feb 19 22:59:14 UTC 2010


I've been thinking about the hashes in XEP-0065 (SOCKS5 Bytestreams),
which folks have commented on before (e.g., they don't work in MUC
rooms). For those who forget, the hash is formed as follows:

SHA-1(SessionID + Initiator JID + Target JID)

The idea here was that the proxy could check the 'from' address on the
IQ stanzas it receives as a way of correlating a bytestreaming session
with a particular JID pair (initiator and target).

However, the proxy never receives an IQ from the target -- all of its
communication with the target happens via TCP / SOCKS5, not XMPP. So we
don't necessarily have the security properties we thought we had.

To be fair, XEP-0065 says:

   Using this information, with the SID and from address on
   the packet, the Proxy is able to activate the stream by
   hashing the SID + Initiator JID + Target JID. This provides
   a reasonable level of trust that the activation request came
   from the Initiator.

So it doesn't really promise that the hash prevents someone from
masquerading as the target.

The initiator's activate request (sent to the proxy) does include the
target JID, but that information is meaningless from a security
perspective because the proxy has no way of checking the target JID.

Thus it seems to me that the best we have is a ticket that's tied to the
initiator. This is better than nothing, I suppose, but it doesn't
require the DST.ADDR to include the target JID.

As to the MUC use case (the initiator doesn't know the target's real
JID), removing the target JID from the hash would help with one part of
the problem. However, the target doesn't necesarily know the initiator's
real JID, either, so it can't construct the proper hash.

One approach would be for the initiator and target to "decloak" (share
real JIDs) before / while setting up the file transfer. If we remove the
target JID from the equation then only the initiator would need to do that.

Another approach would be to make DST.ADDR a pure ticket / bearer token
that's not tied to the JIDs in use. If you don't want someone else to
use the ticket, encrypt it in transit. (That doesn't help if you are
doing XTLS over SOCKS5 in the first place for encryption -- chicken and
egg.)

Yet another approach would be for the MUC room itself to function as a
bytestreams proxy -- it knows the room JIDs so those could be used when
sending the activate request. Or a bot in the room could act as a broker
for the bytestreaming session establishment.

I don't have the answer, but at least wanted to start a discussion about
this because it's an open issue in XEP-0065 and our file transfer
"stack" more generally.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100219/7d0def7d/attachment.bin>


More information about the Standards mailing list