Dirk Meyer wrote:
> 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.
It would have been more accurate for me to say "*for now* I see three"
because clearly there are more use cases -- any given application type
could be done in a secure manner. However, secure file transfer may be
nothing more than e2e-tls with special payloads. And VPN or VNC setup is
a different application type that we'll need to discuss at some point.
>> 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).
I think the idea here is that you are signalling your intent to start an
encrypted tunnel. You don't want an end-to-end stream just for the fun
of it, you want an encrypted connection (which you might also use to
bootstrap security into other channels). So here XTLS is the application
type.
>> <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.
Yes, that's another way to look at it. I was hoping that we would define
one <encryption/> element / namespace (I don't think we want to call it
<crypto/> because we use that for SRTP) and then that might include
>> [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.
Correct.
> 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.
That's what I was thinking, but I'm not wedded to any of this yet. We
can discuss more on the list here or at FOSDEM.
>> 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).
Yes, I think that is reasonable. But I need to think about it some more...
/psa
