Peter Saint-Andre wrote:
> Following up on previous posts and threads, I (who am not a member of
> the security mafia) see three security-related use cases for Jingle...
I see more: secure file transfer, secure VNC over Jingle, etc.
>
> 1. Establishment of an end-to-end tunnel ("XTLS"). The initiator sends
> an offer to the responder to negotiate TLS over some streaming transport
> (IBB, SOCKS5 Bytestreams, ICE-TCP) and the parties exchange the usual
> TLS handshake data over the transport; if the TLS negotiation succeeds,
> then the parties have a secure channel or XTLS tunnel.
>
> For #1, I think we would define a new application type, such as
> "urn:xmpp:jingle:apps:xtls":
What happened to the <crypto> element from before? I liked to have it as
extra element in content. IMHO the application here is just a simple e2e
stream: "urn:xmpp:jingle:apps:e2e". It is not secure as default, just
like file transfer and VNC. It can use different transports and an
optional crypto layer (in case of e2e using no encryption makes no
sense, but that doesn't matter for Jingle).
> <iq from='[email protected]/foo'
> id='jingle1'
> to='[email protected]/bar'
> type='set'>
> <jingle xmlns='urn:xmpp:jingle:0'
> action='session-initiate'
> initiator='[email protected]/foo'
> sid='851ba2'>
> <content creator='initiator' name='e2e-tls'>
> <description xmlns='urn:xmpp:jingle:apps:xtls'>
> <methods>
> <method name='x509'>
> <print>72:72:DF:...</print>
> </method>
> <method name='openpgp'>
> <print>E5:59:E9:...</print>
> </method>
> <method name='srp'/>
> </methods>
> </description>
> <transport xmlns='urn:xmpp:jingle:transports:ibb:0'/>
> </content>
> </jingle>
> </iq>
So let's us move this around:
<iq from='[email protected]/foo'
id='jingle1'
to='[email protected]/bar'
type='set'>
<jingle xmlns='urn:xmpp:jingle:0'
action='session-initiate'
initiator='[email protected]/foo'
sid='851ba2'>
<content creator='initiator' name='e2e-tls'>
<description xmlns='urn:xmpp:jingle:apps:e2e'/>
<transport xmlns='urn:xmpp:jingle:transports:ibb:0'/>
<crypto xmlns='urn:xmpp:jingle:crypto:tls'>
<methods>
<method name='x509'>
<print>72:72:DF:...</print>
</method>
<method name='openpgp'>
<print>E5:59:E9:...</print>
</method>
<method name='srp'/>
</methods>
</description>
</content>
</jingle>
</iq>
Now you can replace the urn:xmpp:jingle:apps:e2e with the offer from the
file transfer XEP without touching the crypto code. Similar to
exchanging the transport on Jingle level, you can change the crypto
layer. You can turn it off (for file transfer you may not need it) and
you can define something new. Maybe in the future someone finds
something better than TLS for XMPP. Just define a new crypto layer
<crypto xmlns='urn:xmpp:jingle:crypto:somethingbetter'> and everything
else does not need to be touched.
> [I don't see a need to negotiate DTLS directly via Jingle, but I suppose
> that if we need it we would define a different Jingle application type,
> such as "urn:xmpp:jingle:apps:dtls".]
Agreed, except that I would propose urn:xmpp:jingle:crypto:dtls.
> <iq from='[email protected]/orchard'
> id='jingle1'
> to='[email protected]/balcony'
> type='set'>
> <jingle xmlns='urn:xmpp:jingle:0'
> action='session-initiate'
> initiator='[email protected]/orchard'
> sid='a73sjjvkla37jfea'>
> <content creator='initiator' name='voice'>
> <description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
> <payload-type id='96' name='speex' clockrate='16000'/>
> <payload-type id='97' name='speex' clockrate='8000'/>
> <payload-type id='18' name='G729'/>
> <payload-type id='103' name='L16' clockrate='16000' channels='2'/>
> <payload-type id='98' name='x-ISAC' clockrate='8000'/>
> <methods xmlns='urn:xmpp:jingle:apps:rtp:sec:0">
> <method name='srtp'>
> <crypto
> crypto-suite='AES_CM_128_HMAC_SHA1_80'
> key-params='inline:keying-data-here'
> session-params='KDR=1;UNENCRYPTED_SRTCP'
> tag='1'/>
> </method>
> </methods>
> </description>
> <transport xmlns='urn:xmpp:jingle:transports:ice-udp:0'/>
> </content>
> </jingle>
> </iq>
Now I see why you put methods inside the description: SRTP makes no
sense in other applications than RTP. So for RTP the security layer is
bound to the application while for TCP-like streams it is independend of
it. That leaves us three choices:
1. Put the security stuff outside the description for TCP-like streams
and inside for RTP. This is inconsistent.
2. Put it always below content. This defines RTP security outside RTP
itself which looks kind of stupid.
3. Put it always inside description like you suggested. This means that
all TCP-like Jingle apps need to define methods in its schema ... or
at least expect it.
I have no idea what the correct way is. I guess I prefer 1 because it
respects the different layers. We can have two security layers: one
independend of the application and one depends on it. We could use
normal RTP over DTLS if someday people prefer to use DTLS and not SRTP
anymore.
> If we define secure media transports other than RTP, we'd need to work
> on those separately.
With 1. we may not need to. We have two transport layers: UDP and
TCP. We have TLS for both. If we define a tls and dtls crypto layer, it
works out of the box for all applications. Besides that, an application
may have its own security layer like RTP has SRTP. In that case Jingle
has no crypto layer and the application uses something on its own (just
like SRTP).
Dirk
P.S.: random signature, seems like a bad joke here right now :)
--
"Everything should be made as simple as possible, but not simpler."
(A.Einstein)
