4.  Securing RTP Applications

   In the following, we provide guidelines for how to choose appropriate
   security mechanisms for RTP applications.

4.1.  Application Requirements

   This section discusses a number of application requirements that need
   to be considered.  An application designer choosing security
   solutions requires a good understanding of what level of security is
   needed and what behavior they strive to achieve.

4.1.1.  Confidentiality

   When it comes to confidentiality of an RTP session, there are several
   aspects to consider:

   Probability of compromise:  When using encryption to provide media
      confidentiality, it is necessary to have some rough understanding
      of the security goal and how long one can expect the protected
      content to remain confidential.  National or other regulations
      might provide additional requirements on a particular usage of an
      RTP.  From that, one can determine which encryption algorithms are
      to be used from the set of available transforms.

   Potential for other leakage:  RTP-based security in most of its forms
      simply wraps RTP and RTCP packets into cryptographic containers.
      This commonly means that the size of the original RTP payload is
      visible to observers of the protected packet flow.  This can
      provide information to those observers.  A well-documented case is
      the risk with variable bitrate speech codecs that produce
      different sized packets based on the speech input [RFC6562].
      Potential threats such as these need to be considered and, if they
      are significant, then restrictions will be needed on mode choices
      in the codec, or additional padding will need to be added to make
      all packets equal size and remove the informational leakage.

      Another case is RTP header extensions.  If SRTP is used, header
      extensions are normally not protected by the security mechanism
      protecting the RTP payload.  If the header extension carries
      information that is considered sensitive, then the application
      needs to be modified to ensure that mechanisms used to protect
      against such information leakage are employed.

   Who has access:  When considering the confidentiality properties of a
      system, it is important to consider where the media handled in the
      clear.  For example, if the system is based on an RTP mixer that
      needs the keys to decrypt the media, process it, and repacketize
      it, then is the mixer providing the security guarantees expected
      by the other parts of the system?  Furthermore, it is important to
      consider who has access to the keys.  The policies for the
      handling of the keys, and who can access the keys, need to be
      considered along with the confidentiality goals.

   As can be seen, the actual confidentiality level has likely more to
   do with the application's usage of centralized nodes, and the details
   of the key management solution chosen, than with the actual choice of
   encryption algorithm (although, of course, the encryption algorithm
   needs to be chosen appropriately for the desired security level).

4.1.2.  Integrity

   Protection against modification of content by a third party, or due
   to errors in the network, is another factor to consider.  The first
   aspect that one assesses is what resilience one has against
   modifications to the content.  Some media types are extremely
   sensitive to network bit errors, whereas others might be able to
   tolerate some degree of data corruption.  Equally important is to
   consider the sensitivity of the content, who is providing the
   integrity assertion, what is the source of the integrity tag, and
   what are the risks of modifications happening prior to that point
   where protection is applied.  These issues affect what cryptographic
   algorithm is used, the length of the integrity tags, and whether the
   entire payload is protected.

   RTP applications that rely on central nodes need to consider if
   hop-by-hop integrity is acceptable or if true end-to-end integrity
   protection is needed.  Is it important to be able to tell if a
   middlebox has modified the data?  There are some uses of RTP that
   require trusted middleboxes that can modify the data in a way that
   doesn't break integrity protection as seen by the receiver, for
   example, local advertisement insertion in IPTV systems.  There are
   also uses where it is essential that such in-network modification be
   detectable.  RTP can support both with appropriate choices of
   security mechanisms.

   Integrity of the data is commonly closely tied to the question of
   source authentication.  That is, it becomes important to know who
   makes an integrity assertion for the data.

4.1.3.  Source Authentication

   Source authentication is about determining who sent a particular RTP
   or RTCP packet.  It is normally closely tied with integrity, since a
   receiver generally also wants to ensure that the data received is
   what the source really sent, so source authentication without
   integrity is not particularly useful.  Similarly, integrity
   protection without source authentication is also not particularly
   useful; a claim that a packet is unchanged that cannot itself be
   validated as from the source (or some from other known and trusted
   party) is meaningless.

   Source authentication can be asserted in several different ways:

   Base level:  Using cryptographic mechanisms that give authentication
      with some type of key management provide an implicit method for
      source authentication.  Assuming that the mechanism has sufficient
      strength not to be circumvented in the time frame when you would
      accept the packet as valid, it is possible to assert a source-
      authenticated statement; this message is likely from a source that
      has the cryptographic key(s) to this communication.

      What that assertion actually means is highly dependent on the
      application and how it handles the keys.  If only the two peers
      have access to the keys, this can form a basis for a strong trust
      relationship that traffic is authenticated coming from one of the
      peers.  However, in a multiparty scenario where security contexts
      are shared among participants, most base-level authentication
      solutions can't even assert that this packet is from the same
      source as the previous packet.

   Binding the source and the signaling:  A step up in the assertion
      that can be done in base-level systems is to tie the signaling to
      the key exchange.  Here, the goal is to at least be able to assert
      that the source of the packets is the same entity with which the
      receiver established the session.  How feasible this is depends on
      the properties of the key management system, the ability to tie
      the signaling to a particular source, and the degree of trust the
      receiver places on the different nodes involved.

      For example, systems where the key exchange is done using the
      signaling systems, such as security descriptions [RFC4568] enable
      a direct binding between signaling and key exchange.  In such
      systems, the actual security depends on the trust one can place in
      the signaling system to correctly associate the peer's identifier
      with the key exchange.

   Using identifiers:  If the applications have access to a system that
      can provide verifiable identifiers, then the source authentication
      can be bound to that identifier.  For example, in a point-to-point
      communication, even symmetric key crypto, where the key management
      can assert that the key has only been exchanged with a particular
      identifier, can provide a strong assertion about the source of the
      traffic.  SIP Identity [RFC4474] provides one example of how this
      can be done and could be used to bind DTLS-SRTP certificates used
      by an endpoint to the identity provider's public key to
      authenticate the source of a DTLS-SRTP flow.

      Note that all levels of the system need to have matching
      capability to assert identifiers.  If the signaling can assert
      that only a given entity in a multiparty session has a key, then
      the media layer might be able to provide guarantees about the
      identifier used by the media sender.  However, using a signaling
      authentication mechanism built on a group key can limit the media
      layer to asserting only group membership.

4.1.4.  Identifiers and Identity

   There exist many different types of systems providing identifiers
   with different properties (e.g., SIP Identity [RFC4474]).  In the
   context of RTP applications, the most important property is the
   possibility to perform source authentication and verify such
   assertions in relation to any claimed identifiers.  What an
   identifier really represents can also vary but, in the context of
   communication, one of the most obvious is the identifiers
   representing the identity of the human user with which one
   communicates.  However, the human user can also have additional
   identifiers in a particular role.  For example, the human (Alice) can
   also be a police officer, and in some cases, an identifier for her
   role as police officer will be more relevant than one that asserts
   that she is Alice.  This is common in contact with organizations,
   where it is important to prove the person's right to represent the
   organization.  Some examples of identifier/identity mechanisms that
   can be used:

   Certificate based:  A certificate is used to assert the identifiers
      used to claim an identity; by having access to the private part of
      the certificate, one can perform signing to assert one's identity.
      Any entity interested in verifying the assertion then needs the
      public part of the certificate.  By having the certificate, one
      can verify the signature against the certificate.  The next step
      is to determine if one trusts the certificate's trust chain.
      Commonly, by provisioning the verifier with the public part of a
      root certificate, this enables the verifier to verify a trust
      chain from the root certificate down to the identifier in the

      certificate.  However, the trust is based on all steps in the
      certificate chain being verifiable and trusted.  Thus, the
      provisioning of root certificates and the ability to revoke
      compromised certificates are aspects that will require
      infrastructure.

   Online identity providers:  An online identity provider (IdP) can
      authenticate a user's right to use an identifier and then perform
      assertions on their behalf or provision the requester with short-
      term credentials to assert the identifiers.  The verifier can then
      contact the IdP to request verification of a particular
      identifier.  Here, the trust is highly dependent on how much one
      trusts the IdP.  The system also becomes dependent on having
      access to the relevant IdP.

   In all of the above examples, an important part of the security
   properties is related to the method for authenticating the access to
   the identity.

4.1.5.  Privacy

   RTP applications need to consider what privacy goals they have.  As
   RTP applications communicate directly between peers in many cases,
   the IP addresses of any communication peer will be available.  The
   main privacy concern with IP addresses is related to geographical
   location and the possibility to track a user of an endpoint.  The
   main way to avoid such concerns is the introduction of relay (e.g., a
   Traversal Using Relay NAT (TURN) server [RFC5766]) or centralized
   media mixers or forwarders that hide the address of a peer from any
   other peer.  The security and trust placed in these relays obviously
   needs to be carefully considered.

   RTP itself can contribute to enabling a particular user to be tracked
   between communication sessions if the Canonical Name (CNAME) is
   generated according to the RTP specification in the form of
   user@host.  Such RTCP CNAMEs are likely long-term stable over
   multiple sessions, allowing tracking of users.  This can be desirable
   for long-term fault tracking and diagnosis, but it clearly has
   privacy implications.  Instead, cryptographically random ones could
   be used as defined by "Guidelines for Choosing RTP Control Protocol
   (RTCP) CNAMEs" [RFC7022].

   If privacy goals exist, they need to be considered and the system
   designed with them in mind.  In addition, certain RTP features might
   have to be configured to safeguard privacy or have requirements on
   how the implementation is done.

4.2.  Application Structure

   When it comes to RTP security, the most appropriate solution is often
   highly dependent on the topology of the communication session.  The
   signaling also impacts what information can be provided and if this
   can be instance specific or common for a group.  In the end, the key
   management system will highly affect the security properties achieved
   by the application.  At the same time, the communication structure of
   the application limits what key management methods are applicable.
   As different key management methods have different requirements on
   underlying infrastructure, it is important to take that aspect into
   consideration early in the design.

4.3.  Automatic Key Management

   The guidelines for Cryptographic Key Management [RFC4107] provide an
   overview of why automatic key management is important.  They also
   provide a strong recommendation on using automatic key management.
   Most of the security solutions reviewed in this document provide or
   support automatic key management, at least to establish session keys.
   In some more long-term use cases, credentials might need to be
   manually deployed in certain cases.

   For SRTP, an important aspect of automatic key management is to
   ensure that two-time pads do not occur, in particular by preventing
   multiple endpoints using the same session key and SSRC.  In these
   cases, automatic key management methods can have strong dependencies
   on signaling features to function correctly.  If those dependencies
   can't be fulfilled, additional constrains on usage, e.g., per-
   endpoint session keys, might be needed to avoid the issue.

   When selecting security mechanisms for an RTP application, it is
   important to consider the properties of the key management.  Using
   key management that is both automatic and integrated will provide
   minimal interruption for the user and is important to ensure that
   security can, and will remain, to be on by default.

4.4.  End-to-End Security vs. Tunnels

   If the security mechanism only provides a secured tunnel, for
   example, like some common uses of IPsec (Section 3.3), it is
   important to consider the full end-to-end properties of the system.
   How does one ensure that the path from the endpoint to the local
   tunnel ingress/egress is secure and can be trusted (and similarly for
   the other end of the tunnel)?  How does one handle the source
   authentication of the peer, as the security protocol identifies the
   other end of the tunnel?  These are some of the issues that arise
   when one considers a tunnel-based security protocol rather than an

   end-to-end one.  Even with clear requirements and knowledge that one
   still can achieve the security properties using a tunnel-based
   solution, one ought to prefer to use end-to-end mechanisms, as they
   are much less likely to violate any assumptions made about
   deployment.  These assumptions can also be difficult to automatically
   verify.

4.5.  Plaintext Keys

   Key management solutions that use plaintext keys, like SDP security
   descriptions (Section 3.1.3), require care to ensure a secure
   transport of the signaling messages that contain the plaintext keys.
   For plaintext keys, the security properties of the system depend on
   how securely the plaintext keys are protected end-to-end between the
   sender and receiver(s).  Not only does one need to consider what
   transport protection is provided for the signaling message, including
   the keys, but also the degree to which any intermediaries in the
   signaling are trusted.  Untrusted intermediaries can perform MITM
   attacks on the communication or can log the keys, resulting in the
   encryption being compromised significantly after the actual
   communication occurred.

4.6.  Interoperability

   Few RTP applications exist as independent applications that never
   interoperate with anything else.  Rather, they enable communication
   with a potentially large number of other systems.  To minimize the
   number of security mechanisms that need to be implemented, it is
   important to consider if one can use the same security mechanisms as
   other applications.  This can also reduce problems with determining
   what security level is actually negotiated in a particular session.

   The desire to be interoperable can, in some cases, be in conflict
   with the security requirements of an application.  To meet the
   security goals, it might be necessary to sacrifice interoperability.
   Alternatively, one can implement multiple security mechanisms; this,
   however, introduces the complication of ensuring that the user
   understands what it means to use a particular security system.  In
   addition, the application can then become vulnerable to bid-down
   attacks.

5.  Examples

   In the following, we describe a number of example security solutions
   for applications using RTP services or frameworks.  These examples
   are provided to illustrate the choices available.  They are not
   normative recommendations for security.

5.1.  Media Security for SIP-Established Sessions Using DTLS-SRTP

   In 2009, the IETF evaluated media security for RTP sessions
   established using point-to-point SIP sessions.  A number of
   requirements were determined, and based on those, the existing
   solutions for media security and especially the keying methods were
   analyzed.  The resulting requirements and analysis were published in
   [RFC5479].  Based on this analysis and working group discussion,
   DTLS-SRTP was determined to be the best solution.

   The security solution for SIP using DTLS-SRTP is defined in
   "Framework for Establishing a Secure Real-time Transport Protocol
   (SRTP) Security Context Using Datagram Transport Layer Security
   (DTLS)" [RFC5763].  On a high level, the framework uses SIP with SDP
   offer/answer procedures to exchange the network addresses where the
   server endpoint will have a DTLS-SRTP-enabled server running.  The
   SIP signaling is also used to exchange the fingerprints of the
   certificate each endpoint will use in the DTLS establishment process.
   When the signaling is sufficiently completed, the DTLS-SRTP client
   performs DTLS handshakes and establishes SRTP session keys.  The
   clients also verify the fingerprints of the certificates to verify
   that no man in the middle has inserted themselves into the exchange.

   DTLS has a number of good security properties.  For example, to
   enable a MITM, someone in the signaling path needs to perform an
   active action and modify both the signaling message and the DTLS
   handshake.  Solutions also exist that enable the fingerprints to be
   bound to identities.  SIP Identity provides an identity established
   by the first proxy for each user [RFC4474].  This reduces the number
   of nodes the connecting User Agent has to trust to include just the
   first-hop proxy rather than the full signaling path.  The biggest
   security weakness of this system is its dependency on the signaling.
   SIP signaling passes multiple nodes and there is usually no message
   security deployed, only hop-by-hop transport security, if any,
   between the nodes.

5.2.  Media Security for WebRTC Sessions

   Web Real-Time Communication (WebRTC) [WebRTC] is a solution providing
   JavaScript web applications with real-time media directly between
   browsers.  Media is transported using RTP and protected using a
   mandatory application of SRTP [RFC3711], with keying done using DTLS-
   SRTP [RFC5764].  The security configuration is further defined in
   "WebRTC Security Architecture" [WebRTC-SEC].

   A hash of the peer's certificate is provided to the JavaScript web
   application, allowing that web application to verify identity of the
   peer.  There are several ways in which the certificate hashes can be

   verified.  An approach identified in the WebRTC security architecture
   [WebRTC-SEC] is to use an identity provider.  In this solution, the
   identity provider, which is a third party to the web application,
   signs the DTLS-SRTP hash combined with a statement on the validity of
   the user identity that has been used to sign the hash.  The receiver
   of such an identity assertion can then independently verify the user
   identity to ensure that it is the identity that the receiver intended
   to communicate with, and that the cryptographic assertion holds; this
   way, a user can be certain that the application also can't perform a
   MITM and acquire the keys to the media communication.  Other ways of
   verifying the certificate hashes exist; for example, they could be
   verified against a hash carried in some out-of-band channel (e.g.,
   compare with a hash printed on a business card) or using a verbal
   short authentication string (e.g., as in ZRTP [RFC6189]) or using
   hash continuity.

   In the development of WebRTC, there has also been attention given to
   privacy considerations.  The main RTP-related concerns that have been
   raised are:

   Location disclosure:  As Interactive Connectivity Establishment (ICE)
      negotiation [RFC5245] provides IP addresses and ports for the
      browser, this leaks location information in the signaling to the
      peer.  To prevent this, one can block the usage of any ICE
      candidate that isn't a relay candidate, i.e., where the IP and
      port provided belong to the service providers media traffic relay.

   Prevent tracking between sessions:  Static RTP CNAMEs and DTLS-SRTP
      certificates provide information that is reused between session
      instances.  Thus, to prevent tracking, such information ought not
      be reused between sessions, or the information ought not be sent
      in the clear.  Note that generating new certificates each time
      prevents continuity in authentication, however, as WebRTC users
      are expected to use multiple devices to access the same
      communication service, such continuity can't be expected anyway;
      instead, the above-described identity mechanism has to be relied
      on.

   Note: The above cases are focused on providing privacy from other
   parties, not on providing privacy from the web server that provides
   the WebRTC JavaScript application.

5.3.  IP Multimedia Subsystem (IMS) Media Security

   In IMS, the core network is controlled by a single operator or by
   several operators with high trust in each other.  Except for some
   types of accesses, the operator is in full control, and no packages
   are routed over the Internet.  Nodes in the core network offer

   services such as voice mail, interworking with legacy systems (Public
   Switched Telephone Network (PSTN), Global System for Mobile
   Communications (GSM), and 3G), and transcoding.  Endpoints are
   authenticated during the SIP registration using either IMS and
   Authentication and Key Agreement (AKA) (using Subscriber Identity
   Module (SIM) credentials) or SIP Digest (using a password).

   In IMS media security [T3GPP.33.328], end-to-end encryption is,
   therefore, not seen as needed or desired as it would hinder, for
   example, interworking and transcoding, making calls between
   incompatible terminals impossible.  Because of this, IMS media
   security mostly uses end-to-access-edge security where SRTP is
   terminated in the first node in the core network.  As the SIP
   signaling is trusted and encrypted (with TLS or IPsec), security
   descriptions [RFC4568] is considered to give good protection against
   eavesdropping over the accesses that are not already encrypted (GSM,
   3G, and Long Term Evolution (LTE)).  Media source authentication is
   based on knowledge of the SRTP session key and trust in that the IMS
   network will only forward media from the correct endpoint.

   For enterprises and government agencies, which might have weaker
   trust in the IMS core network and can be assumed to have compatible
   terminals, end-to-end security can be achieved by deploying their own
   key management server.

   Work on interworking with WebRTC is currently ongoing; the security
   will still be end-to-access-edge but using DTLS-SRTP [RFC5763]
   instead of security descriptions.

5.4.  3GPP Packet-Switched Streaming Service (PSS)

   The 3GPP Release 11 PSS specification of the Packet-switched
   Streaming Service (PSS) [T3GPP.26.234R11] defines, in Annex R, a set
   of security mechanisms.  These security mechanisms are concerned with
   protecting the content from being copied, i.e., Digital Rights
   Management (DRM).  To meet these goals with the specified solution,
   the client implementation and the application platform are trusted to
   protect against access and modification by an attacker.

   PSS is media controlled by RTSP 1.0 [RFC2326] streaming over RTP.
   Thus, an RTSP client whose user wants to access a protected content
   will request a session description (SDP [RFC4566]) for the protected
   content.  This SDP will indicate that the media is protected by
   ISMACryp 2.0 [ISMACryp2] encoding application units (AUs).  The
   key(s) used to protect the media is provided in one of two ways.  If
   a single key is used, then the client uses some DRM system to
   retrieve the key as indicated in the SDP.  Commonly, OMA DRM v2
   [OMADRMv2] will be used to retrieve the key.  If multiple keys are to

   be used, then an additional RTSP stream for key updates in parallel
   with the media streams is established, where key updates are sent to
   the client using Short Term Key Messages defined in the "Service and
   Content Protection for Mobile Broadcast Services" part [OMASCP] of
   the OMA Mobile Broadcast Services [OMABCAST].

   Worth noting is that this solution doesn't provide any integrity
   verification method for the RTP header and payload header
   information; only the encoded media AU is protected. 3GPP has not
   defined any requirement for supporting any solution that could
   provide that service.  Thus, replay or insertion attacks are
   possible.  Another property is that the media content can be
   protected by the ones providing the media, so that the operators of
   the RTSP server have no access to unprotected content.  Instead, all
   that want to access the media are supposed to contact the DRM keying
   server, and if the device is acceptable, they will be given the key
   to decrypt the media.

   To protect the signaling, RTSP 1.0 supports the usage of TLS.  This
   is, however, not explicitly discussed in the PSS specification.
   Usage of TLS can prevent both modification of the session description
   information and help maintain some privacy of what content the user
   is watching as all URLs would then be confidentiality protected.

5.5.  RTSP 2.0

   The Real-time Streaming Protocol 2.0 [RTSP] offers an interesting
   comparison to the PSS service (Section 5.4) that is based on RTSP 1.0
   and service requirements perceived by mobile operators.  A major
   difference between RTSP 1.0 and RTSP 2.0 is that 2.0 is fully defined
   under the requirement to have a mandatory-to-implement security
   mechanism.  As it specifies one transport media over RTP, it is also
   defining security mechanisms for the RTP-transported media streams.

   The security goal for RTP in RTSP 2.0 is to ensure that there is
   confidentiality, integrity, and source authentication between the
   RTSP server and the client.  This to prevent eavesdropping on what
   the user is watching for privacy reasons and to prevent replay or
   injection attacks on the media stream.  To reach these goals, the
   signaling also has to be protected, requiring the use of TLS between
   the client and server.

   Using TLS-protected signaling, the client and server agree on the
   media transport method when doing the SETUP request and response.
   The secured media transport is SRTP (SAVP/RTP) normally over UDP.
   The key management for SRTP is MIKEY using RSA-R mode.  The RSA-R
   mode is selected as it allows the RTSP server to select the key
   despite having the RTSP client initiate the MIKEY exchange.  It also

   enables the reuse of the RTSP server's TLS certificate when creating
   the MIKEY messages, thus ensuring a binding between the RTSP server
   and the key exchange.  Assuming the SETUP process works, this will
   establish a SRTP crypto context to be used between the RTSP server
   and the client for the RTP-transported media streams.

6.  Security Considerations

   This entire document is about security.  Please read it.

7.  Acknowledgements

   We thank the IESG for their careful review of [RFC7202], which led to
   the writing of this memo.  John Mattsson has contributed the IMS
   Media Security example (Section 5.3).

   The authors wish to thank Christian Correll, Dan Wing, Kevin Gross,
   Alan Johnston, Michael Peck, Ole Jacobsen, Spencer Dawkins, Stephen
   Farrell, John Mattsson, and Suresh Krishnan for their reviews and
   proposals for improvements to the text.

8.  Informative References

   [AES-GCM]   McGrew, D. and K. Igoe, "AES-GCM and AES-CCM
               Authenticated Encryption in Secure RTP (SRTP)", Work in
               Progress, September 2013.

   [ARIA-SRTP] Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The
               ARIA Algorithm and Its Use with the Secure Real-time
               Transport Protocol(SRTP)", Work in Progress, November
               2013.

   [EKT]       McGrew, D. and D. Wing, "Encrypted Key Transport for
               Secure RTP", Work in Progress, February 2014.

   [ISMACryp2] Internet Streaming Media Alliance (ISMA), "ISMA
               Encryption and Authentication Version 2.0", November
               2007, <http://www.oipf.tv/images/site/DOCS/mpegif/ISMA/
               isma_easpec2.0.pdf>.

   [OMABCAST]  Open Mobile Alliance, "Mobile Broadcast Services Version
               1.0", February 2009,
               <http://technical.openmobilealliance.org/Technical/
               release_program/bcast_v1_0.aspx>.

   [OMADRMv2]  Open Mobile Alliance, "OMA Digital Rights Management
               V2.0", July 2008,
               <http://technical.openmobilealliance.org/
               Technical/release_program/drm_v2_0.aspx>.

   [OMASCP]    Open Mobile Alliance, "Service and Content Protection for
               Mobile Broadcast Services", January 2013,
               <http://technical.openmobilealliance.org/Technical/
               release_program/docs/BCAST/V1_0_1-20130109-A/
               OMA-TS-BCAST_SvcCntProtection-V1_0_1-20130109-A.pdf>.

   [RFC1112]   Deering, S., "Host extensions for IP multicasting", STD
               5, RFC 1112, August 1989.

   [RFC2326]   Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
               Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RFC3365]   Schiller, J., "Strong Security Requirements for Internet
               Engineering Task Force Standard Protocols", BCP 61, RFC
               3365, August 2002.

   [RFC3550]   Schulzrinne, H., Casner, S., Frederick, R., and V.
               Jacobson, "RTP: A Transport Protocol for Real-Time
               Applications", STD 64, RFC 3550, July 2003.

   [RFC3640]   van der Meer, J., Mackie, D., Swaminathan, V., Singer,
               D., and P. Gentric, "RTP Payload Format for Transport of
               MPEG-4 Elementary Streams", RFC 3640, November 2003.

   [RFC3711]   Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
               Norrman, "The Secure Real-time Transport Protocol
               (SRTP)", RFC 3711, March 2004.

   [RFC3830]   Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
               Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
               August 2004.

   [RFC4107]   Bellovin, S. and R. Housley, "Guidelines for
               Cryptographic Key Management", BCP 107, RFC 4107, June
               2005.

   [RFC4301]   Kent, S. and K. Seo, "Security Architecture for the
               Internet Protocol", RFC 4301, December 2005.

   [RFC4383]   Baugher, M. and E. Carrara, "The Use of Timed Efficient
               Stream Loss-Tolerant Authentication (TESLA) in the Secure
               Real-time Transport Protocol (SRTP)", RFC 4383, February
               2006.

   [RFC4474]   Peterson, J. and C. Jennings, "Enhancements for
               Authenticated Identity Management in the Session
               Initiation Protocol (SIP)", RFC 4474, August 2006.

   [RFC4566]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
               Description Protocol", RFC 4566, July 2006.

   [RFC4567]   Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
               Carrara, "Key Management Extensions for Session
               Description Protocol (SDP) and Real Time Streaming
               Protocol (RTSP)", RFC 4567, July 2006.

   [RFC4568]   Andreasen, F., Baugher, M., and D. Wing, "Session
               Description Protocol (SDP) Security Descriptions for
               Media Streams", RFC 4568, July 2006.

   [RFC4571]   Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
               and RTP Control Protocol (RTCP) Packets over Connection-
               Oriented Transport", RFC 4571, July 2006.

   [RFC4572]   Lennox, J., "Connection-Oriented Media Transport over the
               Transport Layer Security (TLS) Protocol in the Session
               Description Protocol (SDP)", RFC 4572, July 2006.

   [RFC4607]   Holbrook, H. and B. Cain, "Source-Specific Multicast for
               IP", RFC 4607, August 2006.

   [RFC4650]   Euchner, M., "HMAC-Authenticated Diffie-Hellman for
               Multimedia Internet KEYing (MIKEY)", RFC 4650, September
               2006.

   [RFC4738]   Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
               RSA-R: An Additional Mode of Key Distribution in
               Multimedia Internet KEYing (MIKEY)", RFC 4738, November
               2006.

   [RFC4771]   Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
               Transform Carrying Roll-Over Counter for the Secure Real-
               time Transport Protocol (SRTP)", RFC 4771, January 2007.

   [RFC4949]   Shirey, R., "Internet Security Glossary, Version 2", RFC
               4949, August 2007.

   [RFC5117]   Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
               January 2008.

   [RFC5197]   Fries, S. and D. Ignjatic, "On the Applicability of
               Various Multimedia Internet KEYing (MIKEY) Modes and
               Extensions", RFC 5197, June 2008.

   [RFC5245]   Rosenberg, J., "Interactive Connectivity Establishment
               (ICE): A Protocol for Network Address Translator (NAT)
               Traversal for Offer/Answer Protocols", RFC 5245, April
               2010.

   [RFC5246]   Dierks, T. and E. Rescorla, "The Transport Layer Security
               (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5479]   Wing, D., Fries, S., Tschofenig, H., and F. Audet,
               "Requirements and Analysis of Media Security Management
               Protocols", RFC 5479, April 2009.

   [RFC5669]   Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The
               SEED Cipher Algorithm and Its Use with the Secure Real-
               Time Transport Protocol (SRTP)", RFC 5669, August 2010.

   [RFC5760]   Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
               Protocol (RTCP) Extensions for Single-Source Multicast
               Sessions with Unicast Feedback", RFC 5760, February 2010.

   [RFC5763]   Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
               for Establishing a Secure Real-time Transport Protocol
               (SRTP) Security Context Using Datagram Transport Layer
               Security (DTLS)", RFC 5763, May 2010.

   [RFC5764]   McGrew, D. and E. Rescorla, "Datagram Transport Layer
               Security (DTLS) Extension to Establish Keys for the
               Secure Real-time Transport Protocol (SRTP)", RFC 5764,
               May 2010.

   [RFC5766]   Mahy, R., Matthews, P., and J. Rosenberg, "Traversal
               Using Relays around NAT (TURN): Relay Extensions to
               Session Traversal Utilities for NAT (STUN)", RFC 5766,
               April 2010.

   [RFC6043]   Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based
               Modes of Key Distribution in Multimedia Internet KEYing
               (MIKEY)", RFC 6043, March 2011.

   [RFC6188]   McGrew, D., "The Use of AES-192 and AES-256 in Secure
               RTP", RFC 6188, March 2011.

   [RFC6189]   Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
               Path Key Agreement for Unicast Secure RTP", RFC 6189,
               April 2011.

   [RFC6267]   Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based
               Authenticated Key Exchange (IBAKE) Mode of Key
               Distribution in Multimedia Internet KEYing (MIKEY)", RFC
               6267, June 2011.

   [RFC6347]   Rescorla, E. and N. Modadugu, "Datagram Transport Layer
               Security Version 1.2", RFC 6347, January 2012.

   [RFC6509]   Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption
               in Multimedia Internet KEYing (MIKEY)", RFC 6509,
               February 2012.

   [RFC6562]   Perkins, C. and JM. Valin, "Guidelines for the Use of
               Variable Bit Rate Audio with Secure RTP", RFC 6562, March
               2012.

   [RFC6904]   Lennox, J., "Encryption of Header Extensions in the
               Secure Real-time Transport Protocol (SRTP)", RFC 6904,
               April 2013.

   [RFC7022]   Begen, A., Perkins, C., Wing, D., and E. Rescorla,
               "Guidelines for Choosing RTP Control Protocol (RTCP)
               Canonical Names (CNAMEs)", RFC 7022, September 2013.

   [RFC7202]   Perkins, C. and M. Westerlund, "Securing the RTP Protocol
               Framework: Why RTP Does Not Mandate a Single Media
               Security Solution", RFC 7202, April 2014.

   [RTSP]      Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
               and M. Stiemerling, "Real Time Streaming Protocol 2.0
               (RTSP)", Work in Progress, February 2014.

   [T3GPP.26.234R11]
               3GPP, "Technical Specification Group Services and System
               Aspects; Transparent end-to-end Packet-switched Streaming
               Service (PSS); Protocols and codecs", 3GPP TS 26.234
               11.1.0, September 2012,
               <http://www.3gpp.org/DynaReport/26234.htm>.

   [T3GPP.26.234R8]
               3GPP, "Technical Specification Group Services and System
               Aspects; Transparent end-to-end Packet-switched Streaming
               Service (PSS); Protocols and codecs", 3GPP TS 26.234
               8.4.0, September 2009,
               <http://www.3gpp.org/DynaReport/26234.htm>.

   [T3GPP.26.346]
               3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
               Protocols and codecs", 3GPP TS 26.346 10.7.0, March 2013,
               <http://www.3gpp.org/DynaReport/26346.htm>.

   [T3GPP.33.246]
               3GPP, "3G Security; Security of Multimedia Broadcast/
               Multicast Service (MBMS)", 3GPP TS 33.246 11.1.0,
               December 2012,
               <http://www.3gpp.org/DynaReport/33246.htm>.

   [T3GPP.33.328]
               3GPP, "IP Multimedia Subsystem (IMS) media plane
               security", 3GPP TS 33.328 12.1.0, December 2012,
               <http://www.3gpp.org/DynaReport/33328.htm>.

   [WebRTC-SEC]
               Rescorla, E., "WebRTC Security Architecture", Work in
               Progress, February 2014.

   [WebRTC]   Alvestrand, H., "Overview: Real Time Protocols for
               Browser-based Applications", Work in Progress, February
               2014.

Authors' Addresses

   Magnus Westerlund
   Ericsson
   Farogatan 6
   SE-164 80 Kista
   Sweden

   Phone: +46 10 714 82 87
   EMail: magnus.westerlund@ericsson.com


   Colin Perkins
   University of Glasgow
   School of Computing Science
   Glasgow  G12 8QQ
   United Kingdom

   EMail: csp@csperkins.org
   URI:   http://csperkins.org/