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...
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":
<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>
[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".]
2. Use of the XTLS or DTLS tunnel as a bootstrapping mechanism, whereby
you form an association between the encrypted channel you've negotiated
and some application type that you want to secure. This is very similar
to DTLS-SRTP:
http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework
http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp
So we'd need a way to exchange information about the association via
Jingle. In DTLS-SRTP you need a separate DTLS-SRTP session for each
host/port quartet, but you can share the same *DTLS* session for
multiple DTLS-SRTP sessions. Therefore the same association information
would apply to all the possible transport candidates so I think we would
exchange this information at the level of the application type (in this
case the RTP session). Thus we might have:
<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='dtls-srtp'>
<print>FC:FE:B0:...</print>
</method>
</methods>
</description>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:0'/>
</content>
</jingle>
</iq>
3. Exchange of keying material for a secure media transport within the
Jingle content-description. This is secure only if the Jingle exchange
happens over a secure channel, such as an XTLS tunnel as described under
#1. This is what we currently have in XEP-0167 for SRTP, although we
might want to refactor the XML a bit for consistency:
<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>
We still need to define something here for ZRTP, but I think that's
fairly straightforward because AFAICS all that we need to include is the
zrtp-hash:
<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='zrtp'>
<hash>zrtp-hash-here</hash>
</method>
</methods>
</description>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:0'/>
</content>
</jingle>
</iq>
And if desired the initiator could offer all three rtpsec methods
(DTLS-SRTP, SRTP, and ZRTP):
<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='dtls-srtp'>
<print>FC:FE:B0:...</print>
</method>
<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>
<method name='zrtp'>
<hash>zrtp-hash-here</hash>
</method>
</methods>
</description>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:0'/>
</content>
</jingle>
</iq>
If we define secure media transports other than RTP, we'd need to work
on those separately.
Corrections welcome.
/psa
