SDP & RTP security

As noted earlier SDP enables you to say that you will encrypt the media stream which is sent via RTP - such as DES in CBC Mode (DES-CBC)^† or AES in f8-mode [Blom 2001].

This is done via adding to the SDP for each media description:

k=encryption key

^†All encryption capable RTP clients must support this as their default algorithm. In addition, to prevent known plain text attacks, RTCP headers have a 32 bit random prefix.

Slide Notes

Rolf Blom, Elisabetta Carrara, Karl Norrman, Mats Näslund, “RTP Encryption for 3G Networks”, Communications Security Lab, Ericsson - IETF proceeding, December 2000, talk dated: Jan. 3, 2001. http://www.ietf.org/proceedings/00dec/slides/AVT-3/tsld001.htm Links to an external site.

Transcript

[slide358] Now, we could put in the SDP a key using the k parameter, and we could use one of several different protocols, and you can read about those. Now, the disadvantage of this is that we have to send it in the SDP. And what's the problem if we have a key that we use for a long period of time, or a key that we transmit ahead of the time when we're actually going to use it? It weakens it. If we use a key for a long period of time, because, of course, we could have a tremendous amount of content, particularly if it's high-resolution video, we would need to refresh the key. This doesn't have any support for that except doing a new SDP negotiation. And we'll see later that SRTP, the secure RTP, was introduced that can provide some ways around that.