Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)

Abstract

   The Secure Real-Time Transport Protocol (SRTP) provides
   authentication, but not encryption, of the headers of Real-Time
   Transport Protocol (RTP) packets.  However, RTP header extensions may
   carry sensitive information for which participants in multimedia
   sessions want confidentiality.  This document provides a mechanism,
   extending the mechanisms of SRTP, to selectively encrypt RTP header
   extensions in SRTP.

   This document updates RFC 3711, the Secure Real-Time Transport
   Protocol specification, to require that all future SRTP encryption
   transforms specify how RTP header extensions are to be encrypted.



1.  Introduction

   The Secure Real-Time Transport Protocol [RFC3711] specification
   provides confidentiality, message authentication, and replay
   protection for multimedia payloads sent using the Real-Time Protocol
   (RTP) [RFC3550].  However, in order to preserve RTP header
   compression efficiency, SRTP provides only authentication and replay
   protection for the headers of RTP packets, not confidentiality.

   For the standard portions of an RTP header, this does not normally
   present a problem, as the information carried in an RTP header does
   not provide much information beyond that which an attacker could
   infer by observing the size and timing of RTP packets.  Thus, there
   is little need for confidentiality of the header information.

   However, this is not necessarily true for information carried in RTP
   header extensions.  A number of recent proposals for header
   extensions using the General Mechanism for RTP Header Extensions
   [RFC5285] carry information for which confidentiality could be
   desired or essential.  Notably, two recent specifications ([RFC6464]
   and [RFC6465]) carry information about per-packet sound levels of the
   media data carried in the RTP payload, and exposing this to an
   eavesdropper is unacceptable in many circumstances.

   This document, therefore, defines a mechanism by which encryption can
   be applied to RTP header extensions when they are transported using
   SRTP.  As an RTP sender may wish some extension information to be
   sent in the clear (for example, it may be useful for a network
   monitoring device to be aware of RTP transmission time offsets
   [RFC5450]), this mechanism can be selectively applied to a subset of
   the header extension elements carried in an SRTP packet.

   The mechanism defined by this document encrypts packets' header
   extensions using the same cryptographic algorithms and parameters as
   are used to encrypt the packets' RTP payloads.  This document defines
   how this is done for the encryption transforms defined in [RFC3711],
   [RFC5669], and [RFC6188], the SRTP encryption transforms defined by
   standards-track IETF documents at the time of this writing.  It also
   updates [RFC3711], to indicate that specifications of future SRTP
   encryption transforms must define how header extension encryption is
   to be performed.