FYI. Discuss on the secur...@xmpp.org list. There are follow-ups here: http://mail.jabber.org/pipermail/security/2009-January/000588.html
http://mail.jabber.org/pipermail/security/2009-January/000589.html http://mail.jabber.org/pipermail/security/2009-January/000590.html -------- Original Message -------- To: XMPP Security <secur...@xmpp.org> From: Dirk Meyer <dme...@tzi.de> Date: Thu, 08 Jan 2009 13:10:56 +0100 Subject: [Security] End-to-End Security Summary Hi, as promised in the council meeting yesterday, I put my XMPP lib into debug mode and dumped the messages for end-to-end security. The code can be found at svn://svn.freevo.org/kaa/trunk in the xmpp subdir. If you want to play with it, check the test dir, ask me at #freevo on irc.gnu.org, or contact me at xmpp:dme...@jabber.org. This may give you an idea how much work it may be to add support for it in another lib. Now let's start with Jingle-Streams. We need Jingle, XEP-0247, and XEP-0250 is also a good idea. The code is not complete, it does not support transport-replace -- which is OK since it also only supports IBB as transport. First we open a session with Jingle, open an IBB as transport, and start an e2e stream which will be secured by the starttls feature. The log can be found at: http://www.tzi.de/~dmeyer/jingle.log My first thought when I saw the complete log: wow, that is a lot of stanzas. OK, now the XTLS in the latest version that can be found in the inbox at http://xmpp.org/extensions/inbox/xtls.html. The implementation is simpler and would even be simpler if we would use IBB and not define something similar in the XTLS namespace. The previous version was like that. Now the log: http://www.tzi.de/~dmeyer/xtls.log Now that is what I call simple. Well, it is not 100% complete, my implementation lacks XEP-0250 support for XTLS. But that wouldn't make a huge difference. So what is better? I'm not sure. Both have advantages and disadvantages. XTLS is simpler, easier to implement. Jingle-Streams is more flexible and can be used with a future ICE-TCP-like XEP. If you have a Jingle implementation and also support link-local messaging, it is actual _easier_ to implement. If you ask me what to choose: neither! Why not use Jingle to set up the stream, but instead of going though XEP-0247 we use the simple way of XTLS. If you look at the log, the biggest part is XEP-0247. And if you remember the thread "XEP-0166, XEP-0167, XTLS - crypto and other stories." from this list, we could move TLS into the Jingle layer. This would also provide TLS secured file transfer based on Jingle. One TLS code can be used for various Jingle applications. I put up a fake log similar to the ones above. The main difference is the formatting, I _tried_ to fit it into 80chars/line. Client1 starts a Jingle Session based on an IBB transport and with TLS security (new: the crypto schema). The first message of the XEP-0250 offers are included. <iq to="t...@domain/client2" type="set" id="jingle_6" from="t...@domain/client1"> <jingle xmlns="urn:xmpp:tmp:jingle" action="session-initiate" initiator="t...@domain/client1" sid="SID"> <content name="xmlstream" creator="initiator"> <description xmlns="urn:xmpp:tmp:jingle:apps:xmlstream" tls="required" disclosure="never" authentication="optional" logging="mustnot"/> <transport xmlns="urn:xmpp:tmp:jingle:transports:ibb"/> <crypto xmlns='urn:xmpp:jingle:crypto:tls:0'> <offer xmlns="urn:xmpp:tmp:c2ctls"> <keyinfo xmlns="urn:xmpp:tmp:pubkey"> <name>5efb609be0075586f6a025178b694448e7971f4a</name> </keyinfo> <srp/> </offer> </content> </jingle> </iq> Client2 is happy with IBB and opens it. AT THE SAME TIME a modified version of the XEP-0250 offer IQ is send from Client2 to Client1 to check how to use TLS. Since opening the transport will always take at least one round trip, there is no additional delay caused by XEP-0250. The following is send more or less at the same time, the messages do not need to wait for answers from Client1. Send IQ result for the session-initiate <iq to="t...@domain/client1" type="result" id="jingle_6" from="t...@domain/client2"/> Open IBB <iq to="t...@domain/client1" type="set" id="open_7" from="t...@domain/client2"> <open xmlns="http://jabber.org/protocol/ibb"; block-size="4096" sid="SID"/> </iq> Based on the offer in session-initiate send Client2's offer <iq to="t...@domain/client1" type="set" id="offer" from="t...@domain/client2"> <offer xmlns="urn:xmpp:tmp:c2ctls"> <keyinfo xmlns="urn:xmpp:tmp:pubkey"> <name>5efb609be0075586f6a025178b694448e7971f4a</name> </keyinfo> </offer> </iq> Client1 accepts the incoming IBB and chooses the TLS method to use based on the offer. Both messages are IQ results based on the last stanzas from Client2 Client1 accepts the IBB <iq to="t...@domain/client2" type="result" id="open_7" from="t...@domain/client1"/> Client1 chooses TLS based on X.509 certificates. <iq to="t...@domain/client2" type="result" id="offer" from="t...@domain/client1"> <x509 xmlns="urn:xmpp:tmp:c2ctls"/> </iq> Note: The x509 tag is not part of urn:xmpp:tmp:c2ctls yet Now Client2 starts the TLS handshake on the IBB. Four messages / two round trips later the TLS layer is ready for data. The Jingle TLS Session is now open to be used. Client2 sends session-accept <iq to="t...@domain/client1" type="set" id="jingle_8" from="t...@domain/client2"> <jingle xmlns="urn:xmpp:tmp:jingle" action="session-accept" initiator="t...@domain/client1" sid="SID"> <content name="xmlstream" creator="initiator"> <description xmlns="urn:xmpp:tmp:jingle:apps:xmlstream" tls="required" disclosure="never" authentication="optional" logging="mustnot"/> <transport xmlns="urn:xmpp:tmp:jingle:transports:ibb"/> <crypto xmlns='urn:xmpp:jingle:crypto:tls:0'/> </content> </jingle> </iq> That's it. It is a bit more complicated than XTLS, but much simpler than Jingle-Streams. If you replace the <content> stuff with the schema from XEP-0234 you get TLS secured file transfer. The message flow is exactly the same (except the content). How much time will it cost to implement it? IBB already exists, so does Jingle in my case. If you take a look at my code, Jingle for TCP-like streams is not that complicated. It will get complicate when we use ICE-TCP, but that is optional. IBB works fine. The additional crypto stanzas are also easy to code, for me it is mostly copy-paste from the other two e2e extensions. So I guess: less than one day of work for me. If you lack Jingle support and have no XEP-0250 code, it will take additional two or three days. Dirk -- Conversation, n.: A vocal competition in which the one who is catching his breath is called the listener.
