[Standards] [Fwd: [Security] End-to-End Security Summary]

Peter Saint-Andre stpeter at stpeter.im
Sun Jan 11 15:10:35 UTC 2009


FYI. Discuss on the security at 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 <security at xmpp.org>
From: Dirk Meyer <dmeyer at 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:dmeyer at 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="test at domain/client2" type="set" id="jingle_6"
from="test at domain/client1">
    <jingle xmlns="urn:xmpp:tmp:jingle" action="session-initiate"
            initiator="test at 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="test at domain/client1" type="result" id="jingle_6"
from="test at domain/client2"/>

Open IBB
<iq to="test at domain/client1" type="set" id="open_7"
from="test at 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="test at domain/client1" type="set" id="offer"
from="test at 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="test at domain/client2" type="result" id="open_7"
from="test at domain/client1"/>

Client1 chooses TLS based on X.509 certificates.
<iq to="test at domain/client2" type="result" id="offer"
from="test at 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="test at domain/client1" type="set" id="jingle_8"
from="test at domain/client2">
    <jingle xmlns="urn:xmpp:tmp:jingle" action="session-accept"
            initiator="test at 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.





More information about the Standards mailing list