[Security] Jingle / e2e security (2)
dmeyer at tzi.de
Wed Jan 14 17:44:51 CST 2009
Peter Saint-Andre wrote:
> The first installment in this series was about VoIP security. Now I turn
> my attention to e2e XMPP security. The usual caveats apply (IANAMOTSM).
> For direct client-to-client ("c2c") communication where two entities
> communicate over a local or wide-area network with no server
> infrastructure in place (Serverless Messaging =
> <http://xmpp.org/extensions/xep-0174.html>), the insecure channel is an
> XML stream over TCP, and the stream can be secured using STARTTLS just
> as for c2s and s2s.
Yes. We already have that in place.
> For end-to-end communication where two entities communicate over XMPP
> through one or two intermediate servers, the insecure channel is XMPP
> itself (typically in the form of In-Band Bytestreams =
> <http://xmpp.org/extensions/xep-0047.html>) or potentially some
> out-of-band streaming transport (such as SOCKS5 Bytestreams =
> <http://xmpp.org/extensions/xep-0065.html> or someday ICE-TCP), and here
> again the stream can be secured using STARTTLS.
> So we have 4 cases: c2s, s2s, c2c, and e2e. In all of them, we start
> with an insecure channel and upgrade it to secure using STARTTLS.
We could do that, maybe we don't want to. The good thing about XTLS
compared to Jingle is that it is simple and fast. The whole STARTTLS
features takes many roundtrips we may not need...
> For e2e, we need a way to start the stream over XMPP itself. The method
> we are proposing is to use Jingle to negotiate the transport and other
> parameters as described in <http://xmpp.org/extensions/xep-0247.html>.
... we can do this without XEP-0247. It is similar to serverless
messaging and therefore easy to implement, but takes some time and is
more or less limited to XML streams. For secure file transfer, it is not
needed and it would be confusing to send XML streams on the stream
before we re-use it for file transfer...
> 1. Initiator sends Jingle session-initiate with offer, including hints
> about TLS methods and fingerprints
> 2. Initiator and responder agree on transport and negotiate IBB or
> SOCKS5 (or future ICE-TCP) connection
I agree up to this point.
> 3. Parties start XML stream over negotiated transport (e.g.,
> encapsulated in IBB packets)
> 4. Parties upgrade stream using STARTTLS
> 5. If STARTTLS succeeds, the e2e stream is now secured
Why not skip all this and fire up the TLS lib afer (2)? We know that we
want to use TLS, there is no point in doing all this. We can negotiate
XEP-0250 while we create the stream in (2). After that, give the stream
to the TLS lib and wait until it is set up. I propose:
2a. Initiator and responder agree on transport and negotiate IBB or
SOCKS5 (or future ICE-TCP) connection
2b. Initiator and responder exchange XEP-0250 information
3. Responder acts as TLS client, initiator as TLS server. The TLS lib
makes its four-way handshake
> 6. Responder sends Jingle session-accept to initiator
And then we are done. We can use the now secured stream for XML stanzas,
we can use it for file transfer, and for many other things.
Java is kind of like kindergarten. There are lots of rules you have to
remember. If you don't follow them, the compiler makes you sit in the
corner until you do. - Don Raab
More information about the Security