[Asterisk-video] Secure video with srtp

[Christian Krützfeldt]

> -----Original Message-----
> From: asterisk-video-bounces at lists.digium.com 
> [mailto:asterisk-video-bounces at lists.digium.com] On Behalf Of 
> Olle E Johansson
> Subject: [Asterisk-video] Secure video with srtp
> 
> We have a patch for srtp in the bug tracker. This patch 
> assumes that both streams, audio and video, share the same 
> encryption properties. Is that always the case? Can we have 
> secure audio and unsecure video? Different encryption algorithms?
> Do they always use the same key?
> 
> Anyone that has looked into this?
> 
> /Olle

I checked RFC 3711, the interesting part is probably 3.2.3.

Here is 3.2.3 from http://www.rfc-editor.org/rfc/rfc3711.txt

3.2.3.  Mapping SRTP Packets to Cryptographic Contexts

   Recall that an RTP session for each participant is defined [RFC3550]
   by a pair of destination transport addresses (one network address
   plus a port pair for RTP and RTCP), and that a multimedia session is
   defined as a collection of RTP sessions.  For example, a particular
   multimedia session could include an audio RTP session, a video RTP
   session, and a text RTP session.

   A cryptographic context SHALL be uniquely identified by the triplet
   context identifier:

   context id = <SSRC, destination network address, destination
   transport port number>

   where the destination network address and the destination transport
   port are the ones in the SRTP packet.  It is assumed that, when
   presented with this information, the key management returns a context
   with the information as described in Section 3.2.

   As noted above, SRTP and SRTCP by default share the bulk of the
   parameters in the cryptographic context.  Thus, retrieving the crypto
   context parameters for an SRTCP stream in practice may imply a
   binding to the correspondent SRTP crypto context.  It is up to the
   implementation to assure such binding, since the RTCP port may not be
   directly deducible from the RTP port only.  Alternatively, the key
   management may choose to provide separate SRTP- and SRTCP- contexts,
   duplicating the common parameters (such as master key(s)).  The
   latter approach then also enables SRTP and SRTCP to use, e.g.,
   distinct transforms, if so desired.  Similar considerations arise
   when multiple SRTP streams, forming part of one single RTP session,
   share keys and other parameters.

   If no valid context can be found for a packet corresponding to a
   certain context identifier, that packet MUST be discarded.



I'm not 100% sure, but I think it allows different RTP sessions (e.g. audio and video) to share a key, but they don't have to.

Would different encryption algorithms for audio and video bring any benefits?
Can we still consider it a secure call if only one is encrypted?

Christian