[Jingle] SRTP

[Robert McQueen]

We decided (eventually) that SRTP shouldn't be represented as a
transport, because the encryption/keying/etc is specific to RTP (it
makes no sense to consider file transfer over SRTP, for example).
However, it should also not be a new content description, as the
codec/payload type negotiation is in common with the RTP content
description, and we don't really want to nest the RTP stuff inside
another namespace either.

Therefore, it should be an optional element which can be added to RTP
content descriptions. Mapping to SIP profiles like RTP/AVP and SRTP/AVP
is doable by inspecting whether or not this element is present. Diana
Cionoiu has a proposal for a <crypto> element to achieve this, which she
can follow up with.

I have no particularly strong feelings on whether this should be in a
separate XEP/namespace, or just an optional part of the RTP XEP-0167. I
think it should probably just go in XEP-0167.

(note that some kind of E2E encryption is necessary for exchanging an
SRTP key in your signalling to be meaningful, but we hope that working
stream transports/fallbacks in Jingle will enable TLS encrypted peer to
peer XMPP streams to be negotiated with Jingle)

Regards,
Rob

[Johansson Olle E]

23 jul 2008 kl. 03.18 skrev Robert McQueen:

> (note that some kind of E2E encryption is necessary for exchanging an
> SRTP key in your signalling to be meaningful, but we hope that working
> stream transports/fallbacks in Jingle will enable TLS encrypted peer
> to
> peer XMPP streams to be negotiated with Jingle)

There is a huge difference between TLS in XMPP, which is hop to hop
protection,
and end-to-end security. I want to emphasize the peer2peer part of
your statement
here :-)

I am not fully sure, but I think that there are modes of the MIKEY key
exchange
used for SRTP key exchange in SIP/SDP that doesn't require E2E
protection.
They may rely on pre-shared keys though.

Check RFC 4567 "Key Management Extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP)" and
RFC3830. Both are, well, not judged as easy-reading material. :-)

/O

[Robert McQueen]

Johansson Olle E wrote:
> There is a huge difference between TLS in XMPP, which is hop to hop
> protection,
> and end-to-end security. I want to emphasize the peer2peer part of your
> statement
> here :-)

Yeah, XTLS is the current suggested way for a simpler implementation of
end to end security in XMPP. The idea is that you use Jingle to signal a
peer to peer XMPP connection (XEP-0247), and then establish TLS over
that connection with <starttls>. We discussed this a bit over dinner at
the XMPP summit, I think Peter will follow up with more of the ideas.

> I am not fully sure, but I think that there are modes of the MIKEY key
> exchange
> used for SRTP key exchange in SIP/SDP that doesn't require E2E protection.
> They may rely on pre-shared keys though.
>
> Check RFC 4567 "Key Management Extensions for Session Description
> Protocol (SDP) and Real Time Streaming Protocol (RTSP)" and
> RFC3830. Both are, well, not judged as easy-reading material. :-)

I'm happy to leave this to other people to wrangle with. Mostly we just
need to be able to put some node in our RTP description which encodes
the same information SDP does when SRTP is in use. I think Diana has the
definition of that.

> /O

Regards,
Rob

[Peter Saint-Andre]

Robert McQueen wrote:
> Johansson Olle E wrote:
>> There is a huge difference between TLS in XMPP, which is hop to hop
>> protection,
>> and end-to-end security. I want to emphasize the peer2peer part of your
>> statement
>> here :-)
>
> Yeah, XTLS is the current suggested way for a simpler implementation of
> end to end security in XMPP. The idea is that you use Jingle to signal a
> peer to peer XMPP connection (XEP-0247), and then establish TLS over
> that connection with <starttls>. We discussed this a bit over dinner at
> the XMPP summit, I think Peter will follow up with more of the ideas.

Right. But probably not on this list, since that's a security topic, not
(directly) a Jingle topic. :)

>> I am not fully sure, but I think that there are modes of the MIKEY key
>> exchange
>> used for SRTP key exchange in SIP/SDP that doesn't require E2E protection.
>> They may rely on pre-shared keys though.
>>
>> Check RFC 4567 "Key Management Extensions for Session Description
>> Protocol (SDP) and Real Time Streaming Protocol (RTSP)" and
>> RFC3830. Both are, well, not judged as easy-reading material. :-)
>
> I'm happy to leave this to other people to wrangle with. Mostly we just
> need to be able to put some node in our RTP description which encodes
> the same information SDP does when SRTP is in use. I think Diana has the
> definition of that.

OK, cool. :)

/psa

[Peter Saint-Andre]

Robert McQueen wrote:
> We decided (eventually) that SRTP shouldn't be represented as a
> transport, because the encryption/keying/etc is specific to RTP (it
> makes no sense to consider file transfer over SRTP, for example).
> However, it should also not be a new content description, as the
> codec/payload type negotiation is in common with the RTP content
> description, and we don't really want to nest the RTP stuff inside
> another namespace either.
>
> Therefore, it should be an optional element which can be added to RTP
> content descriptions. Mapping to SIP profiles like RTP/AVP and SRTP/AVP
> is doable by inspecting whether or not this element is present. Diana
> Cionoiu has a proposal for a <crypto> element to achieve this, which she
> can follow up with.
>
> I have no particularly strong feelings on whether this should be in a
> separate XEP/namespace, or just an optional part of the RTP XEP-0167. I
> think it should probably just go in XEP-0167.

I think that putting this in XEP-0167 makes sense.

/psa