Alternatively, other services, other implementations of services and
other algorithms may be defined for RTP in the future if warranted.
The selection presented here is meant to simplify implementation of
interoperable, secure applications and provide guidance to
implementors. No claim is made that the methods presented here are
appropriate for a particular security need. A profile may specify
which services and algorithms should be offered by applications, and
may provide guidance as to their appropriate use.
Key distribution and certificates are outside the scope of this
document.
9.1 Confidentiality
Confidentiality means that only the intended receiver(s) can decode
the received packets; for others, the packet contains no useful
information. Confidentiality of the content is achieved by
encryption.
When encryption of RTP or RTCP is desired, all the octets that will
be encapsulated for transmission in a single lower-layer packet are
encrypted as a unit. For RTCP, a 32-bit random number is prepended to
the unit before encryption to deter known plaintext attacks. For RTP,
no prefix is required because the sequence number and timestamp
fields are initialized with random offsets.
For RTCP, it is allowed to split a compound RTCP packet into two
lower-layer packets, one to be encrypted and one to be sent in the
clear. For example, SDES information might be encrypted while
reception reports were sent in the clear to accommodate third-party
monitors that are not privy to the encryption key. In this example,
depicted in Fig. 4, the SDES information must be appended to an RR
packet with no reports (and the encrypted) to satisfy the requirement
that all compound RTCP packets begin with an SR or RR packet.
Schulzrinne, et al Standards Track [Page 49]
RFC 1889 RTP January 1996
UDP packet UDP packet
------------------------------------- -------------------------
[32-bit ][ ][ # ] [ # sender # receiver]
[random ][ RR ][SDES # CNAME, ...] [ SR # report # report ]
[integer][(empty)][ # ] [ # # ]
------------------------------------- -------------------------
encrypted not encrypted
#: SSRC
Figure 4: Encrypted and non-encrypted RTCP packets
The presence of encryption and the use of the correct key are
confirmed by the receiver through header or payload validity checks.
Examples of such validity checks for RTP and RTCP headers are given
in Appendices A.1 and A.2.
