Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 7201 Ericsson
Category: Informational C. Perkins
ISSN: 2070-1721 University of Glasgow
April 2014
Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 7201 Ericsson
Category: Informational C. Perkins
ISSN: 2070-1721 University of Glasgow
April 2014
Options for Securing RTP Sessions
保护RTP会话的选项
Abstract
摘要
The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism.
实时传输协议（RTP）用于大量不同的应用领域和环境。这种异构性意味着需要不同的安全机制来提供适合各种环境的RTP和RTP控制协议（RTCP）数据包的保密性、完整性和源认证等服务。解决方案的范围使得基于RTP的应用程序开发人员很难选择最合适的机制。本文档概述了RTP的许多安全解决方案，并就如何选择适当的安全机制为开发人员提供了指导。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7201.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7201.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Point-to-Point Sessions . . . . . . . . . . . . . . . . . 5
2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 5
2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 6
2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 6
2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 8
2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 8
2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8
3. Security Options . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 12
3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 14
3.1.3. Key Management for SRTP: Security Descriptions . . . 15
3.1.4. Key Management for SRTP: Encrypted Key Transport . . 16
3.1.5. Key Management for SRTP: ZRTP and Other Solutions . . 17
3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 17
3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 18
3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 18
3.6. Media Content Security/Digital Rights Management . . . . 19
3.6.1. ISMA Encryption and Authentication . . . . . . . . . 19
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 20
4.1. Application Requirements . . . . . . . . . . . . . . . . 20
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 20
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 21
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 22
4.1.4. Identifiers and Identity . . . . . . . . . . . . . . 23
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Application Structure . . . . . . . . . . . . . . . . . . 25
4.3. Automatic Key Management . . . . . . . . . . . . . . . . 25
4.4. End-to-End Security vs. Tunnels . . . . . . . . . . . . . 25
4.5. Plaintext Keys . . . . . . . . . . . . . . . . . . . . . 26
4.6. Interoperability . . . . . . . . . . . . . . . . . . . . 26
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Media Security for SIP-Established Sessions Using
DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 27
5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 28
5.4. 3GPP Packet-Switched Streaming Service (PSS) . . . . . . 29
5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
8. Informative References . . . . . . . . . . . . . . . . . . . 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Point-to-Point Sessions . . . . . . . . . . . . . . . . . 5
2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 5
2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 6
2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 6
2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 8
2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 8
2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8
3. Security Options . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 12
3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 14
3.1.3. Key Management for SRTP: Security Descriptions . . . 15
3.1.4. Key Management for SRTP: Encrypted Key Transport . . 16
3.1.5. Key Management for SRTP: ZRTP and Other Solutions . . 17
3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 17
3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 18
3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 18
3.6. Media Content Security/Digital Rights Management . . . . 19
3.6.1. ISMA Encryption and Authentication . . . . . . . . . 19
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 20
4.1. Application Requirements . . . . . . . . . . . . . . . . 20
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 20
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 21
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 22
4.1.4. Identifiers and Identity . . . . . . . . . . . . . . 23
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Application Structure . . . . . . . . . . . . . . . . . . 25
4.3. Automatic Key Management . . . . . . . . . . . . . . . . 25
4.4. End-to-End Security vs. Tunnels . . . . . . . . . . . . . 25
4.5. Plaintext Keys . . . . . . . . . . . . . . . . . . . . . 26
4.6. Interoperability . . . . . . . . . . . . . . . . . . . . 26
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Media Security for SIP-Established Sessions Using
DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 27
5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 28
5.4. 3GPP Packet-Switched Streaming Service (PSS) . . . . . . 29
5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
8. Informative References . . . . . . . . . . . . . . . . . . . 31
The Real-time Transport Protocol (RTP) [RFC3550] is widely used in a large variety of multimedia applications, including Voice over IP (VoIP), centralized multimedia conferencing, sensor data transport, and Internet television (IPTV) services. These applications can range from point-to-point phone calls, through centralized group teleconferences, to large-scale television distribution services. The types of media can vary significantly, as can the signaling methods used to establish the RTP sessions.
实时传输协议（RTP）[RFC3550]广泛应用于各种多媒体应用，包括IP语音（VoIP）、集中式多媒体会议、传感器数据传输和互联网电视（IPTV）服务。这些应用范围从点到点的电话呼叫，通过集中的群组电话会议，到大规模的电视分发服务。媒体的类型可以显著不同，用于建立RTP会话的信令方法也可以显著不同。
So far, this multidimensional heterogeneity has prevented development of a single security solution that meets the needs of the different applications. Instead, a significant number of different solutions have been developed to meet different sets of security goals. This makes it difficult for application developers to know what solutions exist and whether their properties are appropriate. This memo gives an overview of the available RTP solutions and provides guidance on their applicability for different application domains. It also attempts to provide an indication of actual and intended usage at the time of writing as additional input to help with considerations such as interoperability, availability of implementations, etc. The guidance provided is not exhaustive, and this memo does not provide normative recommendations.
到目前为止，这种多维异构性阻碍了满足不同应用程序需求的单一安全解决方案的开发。相反，已经开发了大量不同的解决方案来满足不同的安全目标集。这使得应用程序开发人员很难知道存在哪些解决方案以及它们的属性是否合适。本备忘录概述了可用的RTP解决方案，并就其在不同应用领域的适用性提供了指导。它还试图在撰写本文时提供实际和预期用途的指示，作为额外的输入，以帮助考虑互操作性、实施的可用性等问题。提供的指南并不详尽，本备忘录也没有提供规范性建议。
It is important that application developers consider the security goals and requirements for their application. The IETF considers it important that protocols implement secure modes of operation and makes them available to users [RFC3365]. Because of the heterogeneity of RTP applications and use cases, however, a single security solution cannot be mandated [RFC7202]. Instead, application developers need to select mechanisms that provide appropriate security for their environment. It is strongly encouraged that common mechanisms be used by related applications in common environments. The IETF publishes guidelines for specific classes of applications, so it is worth searching for such guidelines.
重要的是应用程序开发人员考虑其应用程序的安全目标和要求。IETF认为协议实现安全操作模式并使其可供用户使用非常重要[RFC3365]。但是，由于RTP应用程序和用例的异构性，无法强制执行单个安全解决方案[RFC7202]。相反，应用程序开发人员需要选择为其环境提供适当安全性的机制。强烈鼓励公共环境中的相关应用程序使用公共机制。IETF为特定类别的应用发布了指南，因此值得搜索此类指南。
The remainder of this document is structured as follows. Section 2 provides additional background. Section 3 outlines the available security mechanisms at the time of this writing and lists their key security properties and constraints. Section 4 provides guidelines and important aspects to consider when securing an RTP application. Finally, in Section 5, we give some examples of application domains where guidelines for security exist.
本文件其余部分的结构如下。第2节提供了额外的背景资料。第3节概述了撰写本文时可用的安全机制，并列出了它们的关键安全属性和约束。第4节提供了在确保RTP应用程序时要考虑的指导原则和重要方面。最后，在第5节中，我们给出了一些应用程序域的示例，其中有安全指南。
RTP can be used in a wide variety of topologies due to its support for point-to-point sessions, multicast groups, and other topologies built around different types of RTP middleboxes. In the following, we review the different topologies supported by RTP to understand their implications for the security properties and trust relations that can exist in RTP sessions.
由于RTP支持点对点会话、多播组以及围绕不同类型的RTP中间盒构建的其他拓扑，因此RTP可以用于多种拓扑。在下文中，我们将回顾RTP支持的不同拓扑，以了解它们对RTP会话中可能存在的安全属性和信任关系的影响。
The most basic use case is two directly connected endpoints, shown in Figure 1, where A has established an RTP session with B. In this case, the RTP security is primarily about ensuring that any third party be unable to compromise the confidentiality and integrity of the media communication. This requires confidentiality protection of the RTP session, integrity protection of the RTP/RTCP packets, and source authentication of all the packets to ensure no man-in-the-middle (MITM) attack is taking place.
最基本的用例是两个直接连接的端点，如图1所示，其中A与B建立了RTP会话。在这种情况下，RTP安全性主要是确保任何第三方都不能破坏媒体通信的机密性和完整性。这需要对RTP会话进行保密保护，对RTP/RTCP数据包进行完整性保护，并对所有数据包进行源身份验证，以确保不会发生中间人（MITM）攻击。
The source authentication can also be tied to a user or an endpoint's verifiable identity to ensure that the peer knows with whom they are communicating. Here, the combination of the security protocol protecting the RTP session (and, hence, the RTP and RTCP traffic) and the key management protocol becomes important to determine what security claims can be made.
源身份验证还可以绑定到用户或端点的可验证身份，以确保对等方知道他们与谁通信。这里，保护RTP会话（以及因此而保护RTP和RTCP通信量）的安全协议和密钥管理协议的组合对于确定可以作出什么安全声明变得非常重要。
+---+ +---+
| A |<------->| B |
+---+ +---+
+---+ +---+
| A |<------->| B |
+---+ +---+
Figure 1: Point-to-Point Topology
图1：点对点拓扑
An RTP mixer is an RTP session-level middlebox around which one can build a multiparty RTP-based conference. The RTP mixer might actually perform media mixing, like mixing audio or compositing video images into a new media stream being sent from the mixer to a given participant, or it might provide a conceptual stream; for example, the video of the current active speaker. From a security point of view, the important features of an RTP mixer are that it generates a new media stream, has its own source identifier, and does not simply forward the original media.
RTP混音器是一个RTP会话级别的中间盒，可以围绕它构建基于RTP的多方会议。RTP混合器可能实际执行媒体混合，例如将音频或视频图像混合到从混合器发送给给定参与者的新媒体流中，或者它可能提供概念流；例如，当前活动扬声器的视频。从安全的角度来看，RTP混合器的重要特性是，它生成新的媒体流，具有自己的源标识符，并且不简单地转发原始媒体。
An RTP session using a mixer might have a topology like that in Figure 2. In this example, participants A through D each send unicast RTP traffic to the RTP mixer, and receive an RTP stream from the mixer, comprising a mixture of the streams from the other participants.
使用混合器的RTP会话可能具有如图2所示的拓扑结构。在该示例中，参与者A到D各自向RTP混合器发送单播RTP业务，并从混合器接收RTP流，该RTP流包括来自其他参与者的流的混合。
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 2: Example RTP Mixer Topology
图2：示例RTP混频器拓扑
A consequence of an RTP mixer having its own source identifier and acting as an active participant towards the other endpoints is that the RTP mixer needs to be a trusted device that has access to the security context(s) established. The RTP mixer can also become a security-enforcing entity. For example, a common approach to secure the topology in Figure 2 is to establish a security context between the mixer and each participant independently and have the mixer source authenticate each peer. The mixer then ensures that one participant cannot impersonate another.
RTP混合器具有其自己的源标识符并充当其他端点的活动参与者的结果是，RTP混合器需要是能够访问所建立的安全上下文的受信任设备。RTP混合器也可以成为安全强制实体。例如，图2中保护拓扑的常见方法是在混合器和每个参与者之间独立地建立安全上下文，并让混合器源对每个对等方进行身份验证。然后，混合器确保一个参与者不能模拟另一个参与者。
RTP translators are middleboxes that provide various levels of in-network media translation and transcoding. Their security properties vary widely, depending on which type of operations they attempt to perform. We identify and discuss three different categories of RTP translators: transport translators, gateways, and media transcoders.
RTP翻译器是提供各种级别的网络媒体翻译和转码的中间盒。它们的安全属性差异很大，这取决于它们尝试执行的操作类型。我们确定并讨论了三种不同类型的RTP转换器：传输转换器、网关和媒体转码器。
A transport translator [RFC5117] operates on a level below RTP and RTCP. It relays the RTP/RTCP traffic from one endpoint to one or more other addresses. This can be done based only on IP addresses and transport protocol ports, and each receive port on the translator can have a very basic list of where to forward traffic. Transport translators also need to implement ingress filtering to prevent random traffic from being forwarded that isn't coming from a participant in the conference.
传输转换器[RFC5117]在低于RTP和RTCP的级别上运行。它将RTP/RTCP通信从一个端点中继到一个或多个其他地址。这只能基于IP地址和传输协议端口来完成，转换器上的每个接收端口都可以有一个转发通信的基本列表。传输转换器还需要实现入口过滤，以防止转发并非来自会议参与者的随机流量。
Figure 3 shows an example transport translator, where traffic from any one of the four participants will be forwarded to the other three
图3显示了一个示例传输转换器，其中来自四个参与者中任何一个的流量将转发给其他三个参与者
participants unchanged. The resulting topology is very similar to an Any Source Multicast (ASM) session (as discussed in Section 2.4) but is implemented at the application layer.
与会者保持不变。生成的拓扑非常类似于任意源多播（ASM）会话（如第2.4节所述），但在应用层实现。
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | Relay | +---+
| Translator |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | Relay | +---+
| Translator |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 3: RTP Relay Translator Topology
图3:RTP中继转换器拓扑
A transport translator can often operate without needing access to the security context, as long as the security mechanism does not provide protection over the transport-layer information. A transport translator does, however, make the group communication visible and, thus, can complicate keying and source authentication mechanisms. This is further discussed in Section 2.4.
传输转换器通常可以在不需要访问安全上下文的情况下运行，只要安全机制不提供对传输层信息的保护。然而，传输转换器确实会使组通信可见，因此会使键控和源身份验证机制复杂化。第2.4节对此进行了进一步讨论。
Gateways are deployed when the endpoints are not fully compatible. Figure 4 shows an example topology. The functions a gateway provides can be diverse and range from transport-layer relaying between two domains not allowing direct communication, via transport or media protocol function initiation or termination, to protocol- or media-encoding translation. The supported security protocol might even be one of the reasons a gateway is needed.
当端点不完全兼容时部署网关。图4显示了一个示例拓扑。网关提供的功能多种多样，从不允许通过传输或媒体协议功能启动或终止直接通信的两个域之间的传输层中继到协议或媒体编码转换。支持的安全协议甚至可能是需要网关的原因之一。
+---+ +-----------+ +---+
| A |<---->| Gateway |<---->| B |
+---+ +-----------+ +---+
+---+ +-----------+ +---+
| A |<---->| Gateway |<---->| B |
+---+ +-----------+ +---+
Figure 4: RTP Gateway Topology
图4:RTP网关拓扑
The choice of security protocol, and the details of the gateway function, will determine if the gateway needs to be trusted with access to the application security context. Many gateways need to be trusted by all peers to perform the translation; in other cases, some or all peers might not be aware of the presence of the gateway. The security protocols have different properties depending on the degree of trust and visibility needed. Ensuring communication is possible without trusting the gateway can be a strong incentive for accepting different security properties. Some security solutions will be able to detect the gateways as manipulating the media stream, unless the gateway is a trusted device.
安全协议的选择以及网关功能的详细信息将决定是否需要信任网关访问应用程序安全上下文。许多网关需要得到所有对等方的信任才能执行翻译；在其他情况下，一些或所有对等方可能不知道网关的存在。根据所需的信任度和可见性，安全协议具有不同的属性。在不信任网关的情况下确保通信是可能的，这可能是接受不同安全属性的强烈动机。某些安全解决方案将能够在操纵媒体流时检测网关，除非网关是受信任的设备。
A media transcoder is a special type of gateway device that changes the encoding of the media being transported by RTP. The discussion in Section 2.3.2 applies. A media transcoder alters the media data and, thus, needs to be trusted with access to the security context.
媒体转码器是一种特殊类型的网关设备，用于更改RTP传输的媒体的编码。第2.3.2节中的讨论适用。媒体转码器改变媒体数据，因此需要信任对安全上下文的访问。
Any Source Multicast [RFC1112] is the original multicast model where any multicast group participant can send to the multicast group and get their packets delivered to all group members (see Figure 5). This form of communication has interesting security properties due to the many-to-many nature of the group. Source authentication is important, but all participants with access to the group security context will have the necessary secrets to decrypt and verify the integrity of the traffic. Thus, use of any group security context fails if the goal is to separate individual sources; alternate solutions are needed.
任意源多播[RFC1112]是原始多播模型，其中任何多播组参与者都可以向多播组发送数据包，并将其数据包发送给所有组成员（见图5）。由于组的多对多性质，这种通信形式具有有趣的安全特性。源身份验证很重要，但是所有访问组安全上下文的参与者都将拥有解密和验证流量完整性所需的机密。因此，如果目标是分离单个源，则任何组安全上下文的使用都会失败；需要其他解决办法。
+-----+
+---+ / \ +---+
| A |----/ \---| B |
+---+ / \ +---+
+ Multicast +
+---+ \ Network / +---+
| C |----\ /---| D |
+---+ \ / +---+
+-----+
+-----+
+---+ / \ +---+
| A |----/ \---| B |
+---+ / \ +---+
+ Multicast +
+---+ \ Network / +---+
| C |----\ /---| D |
+---+ \ / +---+
+-----+
Figure 5: Any Source Multicast (ASM) Group
图5：任意源多播（ASM）组
In addition, the potential large size of multicast groups creates some considerations for the scalability of the solution and how the key management is handled.
此外，多播组的潜在较大规模为解决方案的可伸缩性以及密钥管理的处理方式带来了一些考虑因素。
Source-Specific Multicast (SSM) [RFC4607] allows only a specific endpoint to send traffic to the multicast group, irrespective of the number of RTP media sources. The endpoint is known as the media distribution source. For the RTP session to function correctly with RTCP over an SSM session, extensions have been defined in [RFC5760]. Figure 6 shows a sample SSM-based RTP session where several media sources, MS1...MSm, all send media to a distribution source, which then forwards the media data to the SSM group for delivery to the receivers, R1...Rn, and the feedback targets, FT1...FTn. RTCP reception quality feedback is sent unicast from each receiver to one
源特定多播（SSM）[RFC4607]只允许特定端点向多播组发送流量，而不考虑RTP媒体源的数量。该端点称为媒体分发源。为了使RTP会话在SSM会话上与RTCP一起正常工作，在[RFC5760]中定义了扩展。图6显示了一个基于SSM的RTP会话示例，其中多个媒体源MS1…MSm都将媒体发送到分发源，然后分发源将媒体数据转发到SSM组，以交付给接收器R1…Rn和反馈目标FT1…FTn。RTCP接收质量反馈从每个接收机单播发送到一个接收机
of the feedback targets. The feedback targets aggregate reception quality feedback and forward it upstream towards the distribution source. The distribution source forwards (possibly aggregated and summarized) reception feedback to the SSM group and back to the original media sources. The feedback targets are also members of the SSM group and receive the media data, so they can send unicast repair data to the receivers in response to feedback if appropriate.
反馈目标的定义。反馈以聚合接收质量反馈为目标，并将其向上游转发到分发源。分发源向SSM组转发（可能聚合和汇总）接收反馈，并返回到原始媒体源。反馈目标也是SSM组的成员并接收媒体数据，因此，如果适当，它们可以响应反馈向接收器发送单播修复数据。
+-----+ +-----+ +-----+
| MS1 | | MS2 | .... | MSm |
+-----+ +-----+ +-----+
^ ^ ^
| | |
V V V
+---------------------------------+
| Distribution Source |
+--------+ |
| FT Agg | |
+--------+------------------------+
^ ^ |
: . |
: +...................+
: | .
: / \ .
+------+ / \ +-----+
| FT1 |<----+ +----->| FT2 |
+------+ / \ +-----+
^ ^ / \ ^ ^
: : / \ : :
: : / \ : :
: : / \ : :
: ./\ /\. :
: /. \ / .\ :
: V . V V . V :
+----+ +----+ +----+ +----+
| R1 | | R2 | ... |Rn-1| | Rn |
+----+ +----+ +----+ +----+
+-----+ +-----+ +-----+
| MS1 | | MS2 | .... | MSm |
+-----+ +-----+ +-----+
^ ^ ^
| | |
V V V
+---------------------------------+
| Distribution Source |
+--------+ |
| FT Agg | |
+--------+------------------------+
^ ^ |
: . |
: +...................+
: | .
: / \ .
+------+ / \ +-----+
| FT1 |<----+ +----->| FT2 |
+------+ / \ +-----+
^ ^ / \ ^ ^
: : / \ : :
: : / \ : :
: : / \ : :
: ./\ /\. :
: /. \ / .\ :
: V . V V . V :
+----+ +----+ +----+ +----+
| R1 | | R2 | ... |Rn-1| | Rn |
+----+ +----+ +----+ +----+
Figure 6: Example SSM-Based RTP Session with Two Feedback Targets
图6：具有两个反馈目标的基于SSM的RTP会话示例
The use of SSM makes it more difficult to inject traffic into the multicast group, but not impossible. Source authentication requirements apply for SSM sessions, too; an individual verification of who sent the RTP and RTCP packets is needed. An RTP session using SSM will have a group security context that includes the media sources, distribution source, feedback targets, and the receivers. Each has a different role and will be trusted to perform different actions. For example, the distribution source will need to
SSM的使用使得向多播组注入流量变得更加困难，但并非不可能。源认证要求也适用于SSM会话；需要对发送RTP和RTCP数据包的人进行单独验证。使用SSM的RTP会话将具有一个组安全上下文，其中包括媒体源、分发源、反馈目标和接收器。每个人都有不同的角色，并将被信任执行不同的操作。例如，分发源将需要
authenticate the media sources to prevent unwanted traffic from being distributed via the SSM group. Similarly, the receivers need to authenticate both the distribution source and their feedback target to prevent injection attacks from malicious devices claiming to be feedback targets. An understanding of the trust relationships and group security context is needed between all components of the system.
对媒体源进行身份验证，以防止通过SSM组分发不需要的流量。类似地，接收方需要对分发源及其反馈目标进行身份验证，以防止来自声称是反馈目标的恶意设备的注入攻击。需要了解系统所有组件之间的信任关系和组安全上下文。
This section provides an overview of security requirements and the current RTP security mechanisms that implement those requirements. This cannot be a complete survey, since new security mechanisms are defined regularly. The goal is to help applications designers by reviewing the types of solutions that are available. This section will use a number of different security-related terms, as described in the Internet Security Glossary, Version 2 [RFC4949].
本节概述了安全需求和实现这些需求的当前RTP安全机制。这不是一个完整的调查，因为新的安全机制是定期定义的。目标是通过查看可用的解决方案类型来帮助应用程序设计者。本节将使用许多不同的安全相关术语，如Internet安全术语表第2版[RFC4949]中所述。
The Secure Real-time Transport Protocol (SRTP) [RFC3711] is one of the most commonly used mechanisms to provide confidentiality, integrity protection, source authentication, and replay protection for RTP. SRTP was developed with RTP header compression and third-party monitors in mind. Thus, the RTP header is not encrypted in RTP data packets, and the first 8 bytes of the first RTCP packet header in each compound RTCP packet are not encrypted. The entirety of RTP packets and compound RTCP packets are integrity protected. This allows RTP header compression to work and lets third-party monitors determine what RTP traffic flows exist based on the synchronization source (SSRC) fields, but it protects the sensitive content.
安全实时传输协议（SRTP）[RFC3711]是为RTP提供机密性、完整性保护、源认证和重播保护的最常用机制之一。SRTP的开发考虑了RTP报头压缩和第三方监视器。因此，RTP报头在RTP数据分组中未加密，并且每个复合RTCP分组中的第一RTCP分组报头的前8个字节未加密。RTP数据包和复合RTCP数据包的完整性受到保护。这允许RTP报头压缩工作，并允许第三方监控器根据同步源（SSRC）字段确定存在哪些RTP流量，但它保护敏感内容。
SRTP works with transforms where different combinations of encryption algorithm, authentication algorithm, and pseudorandom function can be used, and the authentication tag length can be set to any value. SRTP can also be easily extended with additional cryptographic transforms. This gives flexibility but requires more security knowledge by the application developer. To simplify things, Session Description Protocol (SDP) security descriptions (see Section 3.1.3) and Datagram Transport Layer Security Extension for SRTP (DTLS-SRTP) (see Section 3.1.1) use predefined combinations of transforms, known as SRTP crypto suites and SRTP protection profiles, that bundle together transforms and other parameters, making them easier to use but reducing flexibility. The Multimedia Internet Keying (MIKEY) protocol (see Section 3.1.2) provides flexibility to negotiate the full selection of transforms. At the time of this writing, the following transforms, SRTP crypto suites, and SRTP protection profiles are defined or under definition:
SRTP使用的变换可以使用加密算法、身份验证算法和伪随机函数的不同组合，并且身份验证标记长度可以设置为任何值。SRTP还可以通过附加的加密转换轻松扩展。这提供了灵活性，但需要应用程序开发人员掌握更多的安全知识。为了简化，会话描述协议（SDP）安全描述（见第3.1.3节）和SRTP的数据报传输层安全扩展（DTLS-SRTP）（见第3.1.1节）使用预定义的转换组合，称为SRTP加密套件和SRTP保护配置文件，将转换和其他参数捆绑在一起，使它们更易于使用，但降低了灵活性。多媒体互联网密钥（MIKEY）协议（见第3.1.2节）提供了协商转换完整选择的灵活性。在撰写本文时，已定义或正在定义以下转换、SRTP加密套件和SRTP保护配置文件：
AES-CM and HMAC-SHA-1: AES Counter Mode encryption with 128-bit keys combined with 160-bit keyed HMAC-SHA-1 with an 80-bit authentication tag. This is the default cryptographic transform that needs to be supported. The transforms are defined in SRTP [RFC3711], with the corresponding SRTP crypto suite defined in [RFC4568] and SRTP protection profile defined in [RFC5764].
AES-CM和HMAC-SHA-1:AES计数器模式加密，128位密钥与160位密钥HMAC-SHA-1结合，带有80位身份验证标签。这是需要支持的默认加密转换。转换在SRTP[RFC3711]中定义，相应的SRTP加密套件在[RFC4568]中定义，SRTP保护配置文件在[RFC5764]中定义。
AES-f8 and HMAC-SHA-1: AES f8-mode encryption using 128-bit keys combined with keyed HMAC-SHA-1 using 80-bit authentication. The transforms are defined in [RFC3711], with the corresponding SRTP crypto suite defined in [RFC4568]. The corresponding SRTP protection profile is not defined.
AES-f8和HMAC-SHA-1：使用128位密钥的AES f8模式加密与使用80位身份验证的密钥HMAC-SHA-1相结合。转换在[RFC3711]中定义，相应的SRTP加密套件在[RFC4568]中定义。未定义相应的SRTP保护配置文件。
SEED: A Korean national standard cryptographic transform that is defined to be used with SRTP in [RFC5669]. Three options are defined: one using SHA-1 authentication, one using Counter Mode with Cipher Block Chaining Message Authentication Code (CBC-MAC), and one using Galois Counter Mode.
SEED：韩国国家标准密码转换，在[RFC5669]中定义为与SRTP一起使用。定义了三个选项：一个使用SHA-1身份验证，一个使用带密码块链接消息身份验证码（CBC-MAC）的计数器模式，一个使用Galois计数器模式。
ARIA: A Korean block cipher [ARIA-SRTP] that supports 128-, 192-, and 256-bit keys. It also defines three options: Counter Mode where combined with HMAC-SHA-1 with 80- or 32-bit authentication tags, Counter Mode with CBC-MAC, and Galois Counter Mode. It also defines a different key derivation function than the AES-based systems.
ARIA：一种韩国分组密码[ARIA-SRTP]，支持128、192和256位密钥。它还定义了三个选项：计数器模式（与HMAC-SHA-1和80位或32位身份验证标签相结合）、计数器模式（与CBC-MAC相结合）和伽罗瓦计数器模式。它还定义了与基于AES的系统不同的密钥派生函数。
AES-192-CM and AES-256-CM: Cryptographic transforms for SRTP based on AES-192 and AES-256 Counter Mode encryption and 160-bit keyed HMAC-SHA-1 with 80- and 32-bit authentication tags. These provide 192- and 256-bit encryption keys, but otherwise match the default 128-bit AES-CM transform. The transforms are defined in [RFC3711] and [RFC6188], and the SRTP crypto suites are defined in [RFC6188].
AES-192-CM和AES-256-CM：基于AES-192和AES-256计数器模式加密和160位键控HMAC-SHA-1以及80位和32位认证标签的SRTP加密转换。它们提供192位和256位加密密钥，但在其他方面与默认的128位AES-CM转换匹配。变换在[RFC3711]和[RFC6188]中定义，SRTP加密套件在[RFC6188]中定义。
AES-GCM and AES-CCM: AES Galois Counter Mode and AES Counter Mode with CBC-MAC for AES-128 and AES-256. This authentication is included in the cipher text, which becomes expanded with the length of the authentication tag instead of using the SRTP authentication tag. This is defined in [AES-GCM].
AES-GCM和AES-CCM：AES-128和AES-256的AES伽罗瓦计数器模式和带CBC-MAC的AES计数器模式。此身份验证包含在密文中，密文随身份验证标记的长度而扩展，而不是使用SRTP身份验证标记。这在[AES-GCM]中有定义。
NULL: SRTP [RFC3711] also provides a NULL cipher that can be used when no confidentiality for RTP/RTCP is requested. The corresponding SRTP protection profile is defined in [RFC5764].
NULL:SRTP[RFC3711]还提供了一个空密码，在不请求RTP/RTCP保密性时可以使用该密码。[RFC5764]中定义了相应的SRTP保护配置文件。
The source authentication guarantees provided by SRTP depend on the cryptographic transform and key management used. Some transforms give strong source authentication even in multiparty sessions; others give weaker guarantees and can authenticate group membership but not
SRTP提供的源身份验证保证取决于所使用的加密转换和密钥管理。有些转换即使在多方会话中也提供强大的源身份验证；其他人提供较弱的保证，可以验证组成员身份，但不能
sources. Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4383] offers a complement to the regular symmetric keyed authentication transforms, like HMAC-SHA-1, and can provide per-source authentication in some group communication scenarios. The downside is the need for buffering the packets for a while before authenticity can be verified.
来源。定时高效流丢失容忍认证（TESLA）[RFC4383]提供了对常规对称密钥认证转换的补充，如HMAC-SHA-1，并且可以在某些组通信场景中提供每源认证。缺点是在验证真实性之前需要缓冲数据包一段时间。
[RFC4771] defines a variant of the authentication tag that enables a receiver to obtain the Roll over Counter for the RTP sequence number that is part of the Initialization Vector (IV) for many cryptographic transforms. This enables quicker and easier options for joining a long-lived RTP group; for example, a broadcast session.
[RFC4771]定义了认证标签的一种变体，该变体使接收器能够获得RTP序列号的滚动计数器，RTP序列号是许多加密转换的初始化向量（IV）的一部分。这使得加入长寿命RTP组的选择更快、更容易；例如，广播会话。
RTP header extensions are normally carried in the clear and are only integrity protected in SRTP. This can be problematic in some cases, so [RFC6904] defines an extension to also encrypt selected header extensions.
RTP标头扩展通常以透明方式进行，并且仅在SRTP中受完整性保护。在某些情况下，这可能会有问题，因此[RFC6904]定义了一个扩展来对选定的头扩展进行加密。
SRTP is specified and deployed in a number of RTP usage contexts; significant support is provided in SIP-established VoIP clients, including IP Multimedia Subsystems (IMS), and in the Real Time Streaming Protocol (RTSP) [RTSP] and RTP-based media streaming. Thus, SRTP in general is widely deployed. When it comes to cryptographic transforms, the default (AES-CM and HMAC-SHA-1) is the most commonly used, but it might be expected that AES-GCM, AES-192-CM, and AES-256-CM will gain usage in future, especially due to the AES- and GCM-specific instructions in new CPUs.
在许多RTP使用上下文中指定和部署SRTP；SIP建立的VoIP客户端（包括IP多媒体子系统（IMS））以及实时流协议（RTSP）[RTSP]和基于RTP的媒体流提供了重要的支持。因此，SRTP通常被广泛部署。当涉及到加密转换时，默认值（AES-CM和HMAC-SHA-1）是最常用的，但是可以预期AES-GCM、AES-192-CM和AES-256-CM将在将来得到使用，特别是由于新CPU中的AES和GCM特定指令。
SRTP does not contain an integrated key management solution; instead, it relies on an external key management protocol. There are several protocols that can be used. The following sections outline some popular schemes.
SRTP不包含集成的密钥管理解决方案；相反，它依赖于外部密钥管理协议。有几种协议可以使用。以下各节概述了一些流行的方案。
A Datagram Transport Layer Security (DTLS) extension exists for establishing SRTP keys [RFC5763][RFC5764]. This extension provides secure key exchange between two peers, enabling Perfect Forward Secrecy (PFS) and binding strong identity verification to an endpoint. PFS is a property of the key agreement protocol that ensures that a session key derived from a set of long-term keys will not be compromised if one of the long-term keys is compromised in the future. The default key generation will generate a key that contains material contributed by both peers. The key exchange happens in the media plane directly between the peers. The common key exchange procedures will take two round trips assuming no losses. Transport Layer Security (TLS) resumption can be used when establishing additional media streams with the same peer, and it reduces the setup
存在用于建立SRTP密钥的数据报传输层安全性（DTLS）扩展[RFC5763][RFC5764]。此扩展提供了两个对等方之间的安全密钥交换，实现了完美的前向保密性（PFS）并将强身份验证绑定到端点。PFS是密钥协商协议的一个属性，它确保从一组长期密钥派生的会话密钥在将来其中一个长期密钥被泄露时不会被泄露。默认密钥生成将生成一个密钥，该密钥包含两个对等方提供的材料。密钥交换直接在对等方之间的媒体平面上进行。如果没有损失，公共密钥交换程序将需要两次往返。传输层安全性（TLS）恢复可用于与同一对等方建立其他媒体流，并可减少设置
time to one RTT for these streams (see [RFC5764] for a discussion of TLS resumption in this context).
这些流的一次RTT所需的时间（参见[RFC5764]了解此上下文中TLS恢复的讨论）。
The actual security properties of an established SRTP session using DTLS will depend on the cipher suites offered and used, as well as the mechanism for identifying the endpoints of the handshake. For example, some cipher suites provide PFS, while others do not. When using DTLS, the application designer needs to select which cipher suites DTLS-SRTP can offer and accept so that the desired security properties are achieved. The next choice is how to verify the identity of the peer endpoint. One choice can be to rely on the certificates and use a PKI to verify them to make an identity assertion. However, this is not the most common way; instead, self-signed certificates are common to use to establish trust through signaling or other third-party solutions.
使用DTL建立的SRTP会话的实际安全属性将取决于提供和使用的密码套件，以及识别握手端点的机制。例如，一些密码套件提供PFS，而其他密码套件则不提供PFS。使用DTLS时，应用程序设计者需要选择DTLS-SRTP可以提供和接受的密码套件，以便实现所需的安全属性。下一个选择是如何验证对等端点的标识。一种选择是依赖证书并使用PKI验证证书以进行身份断言。然而，这不是最常见的方式；相反，自签名证书通常用于通过信令或其他第三方解决方案建立信任。
DTLS-SRTP key management can use the signaling protocol in four ways: First, to agree on using DTLS-SRTP for media security. Second, to determine the network location (address and port) where each side is running a DTLS listener to let the parts perform the key management handshakes that generate the keys used by SRTP. Third, to exchange hashes of each side's certificates to bind these to the signaling and ensure there is no MITM attack. This assumes that one can trust the signaling solution to be resistant to modification and not be in collaboration with an attacker. Finally, to provide an asserted identity, e.g., [RFC4474], that can be used to prevent modification of the signaling and the exchange of certificate hashes. That way, it enables binding between the key exchange and the signaling.
DTLS-SRTP密钥管理可以通过四种方式使用信令协议：首先，同意使用DTLS-SRTP实现媒体安全。其次，确定每一方运行DTLS侦听器的网络位置（地址和端口），让各部分执行密钥管理握手，从而生成SRTP使用的密钥。第三，交换每一方证书的哈希值，将它们绑定到信令，并确保没有MITM攻击。这假设您可以信任信令解决方案能够抵抗修改，并且不会与攻击者协作。最后，提供可用于防止修改信令和交换证书散列的断言标识，例如[RFC4474]。这样，它就可以实现密钥交换和信令之间的绑定。
This usage is well defined for SIP/SDP in [RFC5763] and, in most cases, can be adopted for use with other bidirectional signaling solutions. It is to be noted that there is work underway to revisit the SIP Identity mechanism [RFC4474] in the IETF STIR working group.
[RFC5763]中对SIP/SDP的这种用法有很好的定义，并且在大多数情况下，可用于其他双向信令解决方案。需要注意的是，在IETF STIR工作组中，正在重新研究SIP标识机制[RFC4474]。
The main question regarding DTLS-SRTP's security properties is how one verifies any peer identity or at least prevents MITM attacks. This does require trust in some DTLS-SRTP external parties: either a PKI, a signaling system, or some identity provider.
关于DTLS-SRTP安全属性的主要问题是如何验证任何对等身份或至少防止MITM攻击。这确实需要信任某些DTLS-SRTP外部方：PKI、信令系统或某些身份提供者。
DTLS-SRTP usage is clearly on the rise. It is mandatory to support in Web Real-Time Communication (WebRTC). It has growing support among SIP endpoints. DTLS-SRTP was developed in IETF primarily to meet security requirements for RTP-based media established using SIP. The requirements considered can be reviewed in "Requirements and Analysis of Media Security Management Protocols" [RFC5479].
DTLS-SRTP的使用率明显上升。必须支持网络实时通信（WebRTC）。它在SIP端点之间得到了越来越多的支持。DTLS-SRTP是在IETF中开发的，主要用于满足使用SIP建立的基于RTP的媒体的安全要求。可在“媒体安全管理协议的要求和分析”[RFC5479]中审查所考虑的要求。
Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol that has several modes with different properties. MIKEY can be used in point-to-point applications using SIP and RTSP (e.g., VoIP calls) but is also suitable for use in broadcast and multicast applications and centralized group communications.
多媒体互联网键控（MIKEY）[RFC3830]是一种键控协议，具有多种不同属性的模式。MIKEY可用于使用SIP和RTSP的点对点应用程序（如VoIP呼叫），但也适用于广播和多播应用程序以及集中式组通信。
MIKEY can establish multiple security contexts or cryptographic sessions with a single message. It is usable in scenarios where one entity generates the key and needs to distribute the key to a number of participants. The different modes and the resulting properties are highly dependent on the cryptographic method used to establish the session keys actually used by the security protocol, like SRTP.
MIKEY可以用一条消息建立多个安全上下文或加密会话。它在一个实体生成密钥并需要将密钥分发给多个参与者的场景中可用。不同的模式和结果属性高度依赖于用于建立安全协议（如SRTP）实际使用的会话密钥的加密方法。
MIKEY has the following modes of operation:
MIKEY具有以下操作模式：
Pre-Shared Key: Uses a pre-shared secret for symmetric key crypto used to secure a keying message carrying the already-generated session key. This system is the most efficient from the perspective of having small messages and processing demands. The downside is scalability, where usually the effort for the provisioning of pre-shared keys is only manageable if the number of endpoints is small.
预共享密钥：对对称密钥加密使用预共享密钥，用于保护携带已生成会话密钥的密钥消息。从具有小消息和处理需求的角度来看，该系统是最有效的。缺点是可伸缩性，通常只有在端点数量较少的情况下，预共享密钥的供应工作才是可管理的。
Public Key Encryption: Uses a public key crypto to secure a keying message carrying the already-generated session key. This is more resource intensive but enables scalable systems. It does require a public key infrastructure to enable verification.
公钥加密：使用公钥加密来保护携带已生成会话密钥的密钥消息。这是资源密集型的，但支持可扩展的系统。它确实需要一个公钥基础设施来实现验证。
Diffie-Hellman: Uses Diffie-Hellman key agreement to generate the session key, thus providing perfect forward secrecy. The downside is high resource consumption in bandwidth and processing during the MIKEY exchange. This method can't be used to establish group keys as each pair of peers performing the MIKEY exchange will establish different keys.
Diffie-Hellman：使用Diffie-Hellman密钥协议生成会话密钥，从而提供完美的前向保密性。缺点是在MIKEY交换期间，带宽和处理方面的资源消耗很高。此方法不能用于建立组密钥，因为执行MIKEY交换的每对对等方将建立不同的密钥。
HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of the Diffie-Hellman exchange that uses a pre-shared key in a keyed Hashed Message Authentication Code (HMAC) to verify authenticity of the keying material instead of a digital signature as in the previous method. This method is still restricted to point-to-point usage.
HMAC Authenticated Diffie-Hellman:[RFC4650]定义了Diffie-Hellman交换的一种变体，它使用密钥散列消息身份验证码（HMAC）中的预共享密钥来验证密钥材料的真实性，而不是像前面的方法那样使用数字签名。此方法仍限于点对点使用。
RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the public key method, which doesn't rely on the initiator of the key exchange knowing the responder's certificate. This method lets both the initiator and the responder specify the session keying
RSA-R:MIKEY-RSA反向模式[RFC4738]是公钥方法的一种变体，它不依赖于密钥交换的发起人知道响应者的证书。此方法允许发起方和响应方指定会话键控
material depending on the use case. Usage of this mode requires one round-trip time.
材料取决于用例。使用此模式需要一次往返时间。
TICKET: Ticket Payload (TICKET) [RFC6043] is a MIKEY extension using a trusted centralized key management service (KMS). The initiator and responder do not share any credentials; instead, they trust a third party, the KMS, with which they both have or can establish shared credentials.
票证：票证有效负载（票证）[RFC6043]是使用可信集中密钥管理服务（KMS）的MIKEY扩展。发起方和响应方不共享任何凭据；相反，他们信任第三方KMS，他们都拥有或可以建立共享凭证。
IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) [RFC6267] uses a KMS infrastructure but with lower demand on the KMS. It claims to provide both perfect forward and backwards secrecy.
IBAKE：基于身份的认证密钥交换（IBAKE）[RFC6267]使用KMS基础设施，但对KMS的需求较低。它声称提供完美的正向和反向保密。
SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption (SAKKE) in MIKEY. It is based on Identity-based Public Key Cryptography and a KMS infrastructure to establish a shared secret value and certificateless signatures to provide source authentication. Its features include simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery.
SAKKE:[RFC6509]在MIKEY中提供Sakai Kasahara密钥加密（SAKKE）。它基于基于基于身份的公钥加密和KMS基础设施，以建立共享的秘密值和无证书签名来提供源身份验证。它的功能包括单工传输、可扩展性、低延迟呼叫设置以及对安全延迟交付的支持。
MIKEY messages have several different transports. [RFC4567] defines how MIKEY messages can be embedded in general SDP for usage with the signaling protocols SIP, Session Announcement Protocol (SAP), and RTSP. There also exists a usage of MIKEY defined by the Third Generation Partnership Project (3GPP) that sends MIKEY messages directly over UDP [T3GPP.33.246] to key the receivers of Multimedia Broadcast and Multicast Service (MBMS) [T3GPP.26.346]. [RFC3830] defines the application/mikey media type, allowing MIKEY to be used in, e.g., email and HTTP.
MIKEY消息有几种不同的传输方式。[RFC4567]定义了如何将MIKEY消息嵌入到通用SDP中，以便与信令协议SIP、会话公告协议（SAP）和RTSP一起使用。还存在由第三代合作伙伴计划（3GPP）定义的MIKEY使用，该计划通过UDP[T3GPP.33.246]直接向多媒体广播和多播服务（MBMS）[T3GPP.26.346]的关键接收器发送MIKEY消息。[RFC3830]定义应用程序/mikey媒体类型，允许在电子邮件和HTTP中使用mikey。
Based on the many choices, it is important to consider the properties needed in one's solution and based on that evaluate which modes are candidates for use. More information on the applicability of the different MIKEY modes can be found in [RFC5197].
基于许多选择，重要的是考虑在一个解决方案中需要的属性，并在此基础上评估哪些模式是候选使用。有关不同MIKEY模式适用性的更多信息，请参见[RFC5197]。
MIKEY with pre-shared keys is used by 3GPP MBMS [T3GPP.33.246], and IMS media security [T3GPP.33.328] specifies the use of the TICKET mode transported over SIP and HTTP. RTSP 2.0 [RTSP] specifies use of the RSA-R mode. There are some SIP endpoints that support MIKEY. The modes they use are unknown to the authors.
3GPP MBMS[T3GPP.33.246]使用带有预共享密钥的MIKEY，IMS媒体安全[T3GPP.33.328]指定通过SIP和HTTP传输的票证模式的使用。RTSP 2.0[RTSP]指定使用RSA-R模式。有一些SIP端点支持MIKEY。作者不知道他们使用的模式。
[RFC4568] provides a keying solution based on sending plaintext keys in SDP [RFC4566]. It is primarily used with SIP and the SDP Offer/ Answer model and is well defined in point-to-point sessions where each side declares its own unique key. Using security descriptions to establish group keys is less well defined and can have security
[RFC4568]提供了一种基于在SDP[RFC4566]中发送明文密钥的密钥设置解决方案。它主要与SIP和SDP提供/应答模型一起使用，并且在点对点会话中定义良好，其中每一方声明自己的唯一密钥。使用安全性描述来建立组密钥的定义不太明确，并且可能具有安全性
issues since it's difficult to guarantee unique SSRCs (as needed to avoid a "two-time pad" attack -- see Section 9 of [RFC3711]).
问题，因为难以保证唯一的SSRC（根据需要避免“两次pad”攻击——参见[RFC3711]第9节）。
Since keys are transported in plaintext in SDP, they can easily be intercepted unless the SDP carrying protocol provides strong end-to-end confidentiality and authentication guarantees. This is not normally the case; instead, hop-by-hop security is provided between signaling nodes using TLS. This leaves the keying material sensitive to capture by the traversed signaling nodes. Thus, in most cases, the security properties of security descriptions are weak. The usage of security descriptions usually requires additional security measures; for example, the signaling nodes are trusted and protected by strict access control. Usage of security descriptions requires careful design in order to ensure that the security goals can be met.
由于密钥在SDP中以明文传输，因此，除非SDP承载协议提供强大的端到端机密性和身份验证保证，否则密钥很容易被拦截。通常情况并非如此；相反，使用TLS在信令节点之间提供逐跳安全性。这使得键控材料对被遍历的信令节点捕获非常敏感。因此，在大多数情况下，安全描述的安全属性很弱。安全描述的使用通常需要额外的安全措施；例如，信令节点受严格的访问控制的信任和保护。安全描述的使用需要仔细设计，以确保能够满足安全目标。
Security descriptions are the most commonly deployed keying solution for SIP-based endpoints, where almost all endpoints that support SRTP also support security descriptions. It is also used for access protection in IMS Media Security [T3GPP.33.328].
安全描述是基于SIP的端点最常用的密钥设置解决方案，其中几乎所有支持SRTP的端点都支持安全描述。它还用于IMS媒体安全中的访问保护[T3GPP.33.328]。
Encrypted Key Transport (EKT) [EKT] is an SRTP extension that enables group keying despite using a keying mechanism like DTLS-SRTP that doesn't support group keys. It is designed for centralized conferencing, but it can also be used in sessions where endpoints connect to a conference bridge or a gateway and need to be provisioned with the keys each participant on the bridge or gateway uses to avoid decryption and encryption cycles. This can enable interworking between DTLS-SRTP and other keying systems where either party can set the key (e.g., interworking with security descriptions).
加密密钥传输（EKT）[EKT]是一个SRTP扩展，尽管使用了DTLS-SRTP等不支持组密钥的密钥机制，但它仍支持组密钥。它是为集中式会议而设计的，但也可以在端点连接到会议网桥或网关的会话中使用，并且需要为网桥或网关上的每个参与者提供密钥，以避免解密和加密周期。这可以实现DTLS-SRTP和其他密钥系统之间的互通，其中任何一方都可以设置密钥（例如，与安全描述的互通）。
The mechanism is based on establishing an additional EKT key, which everyone uses to protect their actual session key. The actual session key is sent in an expanded authentication tag to the other session participants. This key is only sent occasionally or periodically depending on use cases and depending on what requirements exist for timely delivery or notification.
该机制基于建立一个额外的EKT密钥，每个人都使用它来保护他们的实际会话密钥。实际会话密钥以扩展的身份验证标记发送给其他会话参与者。此密钥仅偶尔或定期发送，具体取决于用例以及及时交付或通知的要求。
The only known deployment of EKT so far is in some Cisco video conferencing products.
目前已知的唯一EKT部署是在一些Cisco视频会议产品中。
The ZRTP [RFC6189] key management system for SRTP was proposed as an alternative to DTLS-SRTP. ZRTP provides best effort encryption independent of the signaling protocol and utilizes key continuity, Short Authentication Strings, or a PKI for authentication. ZRTP wasn't adopted as an IETF Standards Track protocol, but was instead published as an Informational RFC in the IETF stream. Commercial implementations exist.
SRTP的ZRTP[RFC6189]密钥管理系统是作为DTLS-SRTP的替代方案提出的。ZRTP提供独立于信令协议的尽力而为的加密，并利用密钥连续性、短身份验证字符串或PKI进行身份验证。ZRTP没有被采纳为IETF标准跟踪协议，而是作为信息RFC发布在IETF流中。存在商业实现。
Additional proprietary solutions are also known to exist.
还存在其他专有解决方案。
Section 9 of the RTP standard [RFC3550] defines a Data Encryption Standard (DES) or 3DES-based encryption of RTP and RTCP packets. This mechanism is keyed using plaintext keys in SDP [RFC4566] using the "k=" SDP field. This method can provide confidentiality but, as discussed in Section 9 of [RFC3550], it has extremely weak security properties and is not to be used.
RTP标准[RFC3550]第9节定义了基于数据加密标准（DES）或3DES的RTP和RTCP数据包加密。此机制是使用SDP[RFC4566]中的明文键通过“k=”SDP字段键入的。这种方法可以提供机密性，但如[RFC3550]第9节所述，它的安全性非常弱，不可使用。
IPsec [RFC4301] can be used in either tunnel or transport mode to protect RTP and RTCP packets in transit from one network interface to another. This can be sufficient when the network interfaces have a direct relation or in a secured environment where it can be controlled who can read the packets from those interfaces.
IPsec[RFC4301]可以在隧道或传输模式中使用，以保护从一个网络接口传输到另一个网络接口的RTP和RTCP数据包。当网络接口具有直接关系时，或者在可以控制谁可以从这些接口读取数据包的安全环境中，这就足够了。
The main concern with using IPsec to protect RTP traffic is that in most cases, using a VPN approach that terminates the security association at some node prior to the RTP endpoint leaves the traffic vulnerable to attack between the VPN termination node and the endpoint. Thus, usage of IPsec requires careful thought and design of its usage so that it meets the security goals. An important question is how one ensures the IPsec terminating peer and the ultimate destination are the same. Applications can have issues using existing APIs when determining if IPsec is being used or not and when determining who the authenticated peer entity is when IPsec is used.
使用IPsec保护RTP流量的主要问题是，在大多数情况下，使用VPN方法在RTP端点之前终止某些节点上的安全关联会使流量容易受到VPN终止节点和端点之间的攻击。因此，IPsec的使用需要对其使用进行仔细的思考和设计，以满足安全目标。一个重要的问题是如何确保IPsec终止对等方和最终目的地相同。在确定是否使用IPsec以及在确定使用IPsec时经过身份验证的对等实体是谁时，应用程序在使用现有API时可能会遇到问题。
IPsec with RTP is more commonly used as a security solution between infrastructure nodes that exchange many RTP sessions and media streams. The establishment of a secure tunnel between such nodes minimizes the key management overhead.
带RTP的IPsec更常用作交换许多RTP会话和媒体流的基础结构节点之间的安全解决方案。在这样的节点之间建立一个安全隧道可以最大限度地减少密钥管理开销。
Just as RTP can be sent over TCP [RFC4571], it can also be sent over TLS over TCP [RFC4572], using TLS to provide point-to-point security services. The security properties TLS provides are confidentiality, integrity protection, and possible source authentication if the client or server certificates are verified and provide a usable identity. When used in multiparty scenarios using a central node for media distribution, the security provided is only between the central node and the peers, so the security properties for the whole session are dependent on what trust one can place in the central node.
正如RTP可以通过TCP[RFC4571]发送一样，它也可以通过TCP[RFC4572]通过TLS发送，使用TLS提供点对点安全服务。TLS提供的安全属性包括机密性、完整性保护，以及在验证客户端或服务器证书并提供可用身份时可能进行的源身份验证。当在使用中心节点进行媒体分发的多方场景中使用时，提供的安全性仅在中心节点和对等方之间，因此整个会话的安全属性取决于可以在中心节点中放置的信任。
RTSP 1.0 [RFC2326] and 2.0 [RTSP] specify the usage of RTP over the same TLS/TCP connection that the RTSP messages are sent over. It appears that RTP over TLS/TCP is also used in some proprietary solutions that use TLS to bypass firewalls.
RTSP 1.0[RFC2326]和2.0[RTSP]指定在发送RTSP消息的同一TLS/TCP连接上使用RTP。似乎在一些使用TLS绕过防火墙的专有解决方案中也使用了TLS/TCP上的RTP。
DTLS [RFC6347] is based on TLS [RFC5246] but designed to work over an unreliable datagram-oriented transport rather than requiring reliable byte stream semantics from the transport protocol. Accordingly, DTLS can provide point-to-point security for RTP flows analogous to that provided by TLS but over a datagram transport such as UDP. The two peers establish a DTLS association between each other, including the possibility to do certificate-based source authentication when establishing the association. All RTP and RTCP packets flowing will be protected by this DTLS association.
DTLS[RFC6347]基于TLS[RFC5246]，但设计用于不可靠的面向数据报的传输，而不需要传输协议提供可靠的字节流语义。因此，DTL可以为RTP流提供点对点安全性，类似于TLS提供的安全性，但通过数据报传输（如UDP）。两个对等方在彼此之间建立DTLS关联，包括在建立关联时进行基于证书的源身份验证的可能性。所有RTP和RTCP数据包流都将受到此DTLS关联的保护。
Note that using DTLS for RTP flows is different from using DTLS-SRTP key management. DTLS-SRTP uses the same key management steps as DTLS, but uses SRTP for the per-packet security operations. Using DTLS for RTP flows uses the normal datagram TLS data protection, wrapping complete RTP packets. When using DTLS for RTP flows, the RTP and RTCP packets are completely encrypted with no headers in the clear; when using DTLS-SRTP, the RTP headers are in the clear and only the payload data is encrypted.
请注意，对RTP流使用DTLS与使用DTLS-SRTP密钥管理不同。DTLS-SRTP使用与DTLS相同的密钥管理步骤，但使用SRTP进行每包安全操作。将DTLS用于RTP流使用正常的数据报TLS数据保护，包装完整的RTP数据包。当对RTP流使用DTL时，RTP和RTCP数据包被完全加密，在clear中没有头；使用DTLS-SRTP时，RTP报头处于清除状态，并且仅对有效负载数据进行加密。
DTLS can use similar techniques to those available for DTLS-SRTP to bind a signaling-side agreement to communicate to the certificates used by the endpoint when doing the DTLS handshake. This enables use without having a certificate-based trust chain to a trusted certificate root.
DTLS可以使用与DTLS-SRTP可用的技术类似的技术来绑定信令端协议，以便在进行DTLS握手时与端点使用的证书通信。这样就可以使用，而无需将基于证书的信任链连接到受信任的证书根。
There does not appear to be significant usage of DTLS for RTP.
对于RTP，DTL的使用似乎并不多。
Mechanisms have been defined that encrypt only the media content operating within the RTP payload data and leaving the RTP headers and RTCP unaffected. There are several reasons why this might be appropriate, but a common rationale is to ensure that the content stored by RTSP streaming servers has the media content in a protected format that cannot be read by the streaming server (this is mostly done in the context of Digital Rights Management). These approaches then use a key management solution between the rights provider and the consuming client to deliver the key used to protect the content and do not give the media server access to the security context. Such methods have several security weaknesses such as the fact that the same key is handed out to a potentially large group of receiving clients, increasing the risk of a leak.
已定义的机制仅加密RTP有效负载数据内运行的媒体内容，不影响RTP标头和RTCP。这可能有几个原因，但一个常见的理由是确保RTSP流式服务器存储的内容具有流式服务器无法读取的受保护格式的媒体内容（这主要是在数字版权管理的环境中完成的）。然后，这些方法在权限提供者和消费客户端之间使用密钥管理解决方案来交付用于保护内容的密钥，而不授予媒体服务器访问安全上下文的权限。这种方法有几个安全弱点，例如，同一密钥被分发给潜在的大量接收客户端，增加了泄漏的风险。
Use of this type of solution can be of interest in environments that allow middleboxes to rewrite the RTP headers and select which streams are delivered to an endpoint (e.g., some types of centralized video conference systems). The advantage of encrypting and possibly integrity protecting the payload but not the headers is that the middlebox can't eavesdrop on the media content, but it can still provide stream switching functionality. The downside of such a system is that it likely needs two levels of security: the payload-level solution, to provide confidentiality and source authentication, and a second layer with additional transport security ensuring source authentication and integrity of the RTP headers associated with the encrypted payloads. This can also result in the need to have two different key management systems as the entity protecting the packets and payloads are different with a different set of keys.
在允许中间盒重写RTP报头并选择将哪些流传送到端点（例如，某些类型的集中式视频会议系统）的环境中，使用这种类型的解决方案可能很有意义。加密和可能的完整性保护有效负载（而不是报头）的优点是，中间盒不能窃听媒体内容，但它仍然可以提供流交换功能。这种系统的缺点是，它可能需要两个级别的安全性：有效负载级别的解决方案，以提供机密性和源身份验证，以及具有额外传输安全性的第二层，以确保与加密有效负载相关联的RTP报头的源身份验证和完整性。这还可能导致需要有两个不同的密钥管理系统，因为保护数据包和有效负载的实体使用不同的密钥集是不同的。
The aspect of two tiers of security are present in ISMACryp (see Section 3.6.1) and the deprecated 3GPP Packet-switched Streaming Service solution; see Annex K of [T3GPP.26.234R8].
ISMACryp（见第3.6.1节）和不推荐的3GPP分组交换流媒体服务解决方案中存在两层安全性；见[T3GPP.26.234R8]的附录K。
The Internet Streaming Media Alliance (ISMA) has defined ISMA Encryption and Authentication 2.0 [ISMACryp2]. This specification defines how one encrypts and packetizes the encrypted application data units (ADUs) in an RTP payload using the MPEG-4 generic payload format [RFC3640]. The ADU types that are allowed are those that can be stored as elementary streams in an ISO Media File format-based file. ISMACryp uses SRTP for packet-level integrity and source authentication from a streaming server to the receiver.
互联网流媒体联盟（ISMA）定义了ISMA加密和认证2.0[ISMACryp2]。本规范定义了如何使用MPEG-4通用有效载荷格式[RFC3640]对RTP有效载荷中的加密应用程序数据单元（ADU）进行加密和打包。允许的ADU类型是那些可以作为基本流存储在基于ISO媒体文件格式的文件中的类型。ISMACryp使用SRTP实现从流服务器到接收器的数据包级完整性和源身份验证。
Key management for an ISMACryp-based system can be achieved through Open Mobile Alliance (OMA) Digital Rights Management 2.0 [OMADRMv2], for example.
例如，基于ISMACryp的系统的密钥管理可以通过开放移动联盟（OMA）数字版权管理2.0[OMADRMv2]实现。
In the following, we provide guidelines for how to choose appropriate security mechanisms for RTP applications.
在下文中，我们将为如何为RTP应用程序选择适当的安全机制提供指导。
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.
本节讨论了一些需要考虑的应用程序需求。选择安全解决方案的应用程序设计师需要很好地了解需要什么级别的安全性以及他们努力实现的行为。
When it comes to confidentiality of an RTP session, there are several aspects to consider:
当涉及RTP会话的机密性时，有几个方面需要考虑：
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.
泄露概率：当使用加密提供媒体机密性时，有必要对安全目标以及受保护内容的保密时间有一些粗略的了解。国家或其他法规可能会对RTP的特定用途提出额外要求。由此，可以从可用的转换集合中确定要使用哪些加密算法。
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.
其他泄漏的可能性：大多数形式的基于RTP的安全性只是将RTP和RTCP数据包包装到加密容器中。这通常意味着原始RTP有效负载的大小对于受保护分组流的观察者是可见的。这可以向这些观察员提供信息。一个众所周知的例子是可变比特率语音编解码器的风险，该编解码器根据语音输入产生不同大小的数据包[RFC6562]。需要考虑这些潜在威胁，如果这些威胁很严重，则需要限制编解码器中的模式选择，或者需要添加额外的填充，以使所有数据包大小相等并消除信息泄漏。
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.
另一种情况是RTP头扩展。如果使用SRTP，头扩展通常不受保护RTP有效负载的安全机制的保护。如果报头扩展包含被认为是敏感的信息，那么需要修改应用程序，以确保使用用于防止此类信息泄漏的机制。
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.
谁有权访问：当考虑系统的机密属性时，重要的是要考虑媒体在哪里清除。例如，如果系统基于RTP混合器，需要密钥来解密媒体、处理媒体和重新打包媒体，那么混合器是否提供了系统其他部分所期望的安全保证？此外，重要的是考虑谁可以访问密钥。处理密钥的策略，以及谁可以访问密钥，需要与保密目标一起考虑。
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).
可以看出，实际的保密级别可能更多地与应用程序对集中式节点的使用以及所选密钥管理解决方案的细节有关，而不是与加密算法的实际选择有关（当然，需要根据所需的安全级别适当选择加密算法）。
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.
依赖于中心节点的RTP应用需要考虑是否逐跳完整性是可接受的，或者是否需要真正的端到端完整性保护。知道中间箱是否修改了数据是否重要？RTP的一些用途需要可信的中间盒，这些中间盒可以以不破坏完整性保护的方式修改数据，如在IPTV系统中插入本地广告。在某些情况下，这种网络内修改必须是可检测的。RTP可以通过选择适当的安全机制来支持这两种方法。
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.
数据的完整性通常与源身份验证问题密切相关。也就是说，了解谁对数据进行完整性断言变得非常重要。
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.
源身份验证是关于确定谁发送了特定的RTP或RTCP数据包。它通常与完整性密切相关，因为接收方通常还希望确保接收到的数据是源真正发送的数据，因此没有完整性的源身份验证不是特别有用。同样，没有源认证的完整性保护也不是特别有用；声称一个数据包是未更改的，而该数据包本身无法从源（或其他已知和受信任方）验证，这是毫无意义的。
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.
例如，使用信令系统进行密钥交换的系统，例如安全描述[RFC4568]启用信令和密钥交换之间的直接绑定。在这样的系统中，实际的安全性取决于人们可以在信令系统中放置的信任，以正确地将对等方的标识符与密钥交换相关联。
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.
使用标识符：如果应用程序可以访问可以提供可验证标识符的系统，那么源身份验证可以绑定到该标识符。例如，在点到点通信中，即使是对称密钥加密（其中密钥管理可以断言密钥仅与特定标识符交换）也可以提供关于流量源的强断言。SIP Identity[RFC4474]提供了一个示例，说明了如何实现这一点，并可用于将端点使用的DTLS-SRTP证书绑定到身份提供程序的公钥，以验证DTLS-SRTP流的源。
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.
请注意，系统的所有级别都需要具有断言标识符的匹配功能。如果信令可以断言多方会话中只有给定实体具有密钥，那么媒体层可能能够提供关于媒体发送方使用的标识符的保证。但是，使用建立在组密钥上的信令身份验证机制可以限制媒体层仅声明组成员身份。
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:
存在许多不同类型的系统，提供具有不同属性的标识符（例如，SIP标识[RFC4474]）。在RTP应用程序的上下文中，最重要的属性是执行源身份验证和验证与任何声明的标识符相关的断言的可能性。标识符真正表示的内容也可能有所不同，但在通信上下文中，最明显的是表示与之通信的人类用户身份的标识符。然而，人类用户也可以在特定角色中具有附加标识符。例如，人（Alice）也可以是警官，在某些情况下，她作为警官角色的标识符比声称她是Alice的标识符更相关。这在与组织的接触中很常见，证明该人代表该组织的权利很重要。可以使用的标识符/标识机制的一些示例：
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.
在线身份提供者：在线身份提供者（IdP）可以验证用户使用标识符的权利，然后代表他们执行断言，或者为请求者提供短期凭据以断言标识符。验证器然后可以联系IdP以请求对特定标识符的验证。在这里，信任在很大程度上取决于人们对IdP的信任程度。系统还取决于是否能够访问相关的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.
在上述所有示例中，安全属性的一个重要部分与验证对身份的访问的方法有关。
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应用程序需要考虑他们的隐私目标。由于RTP应用程序在许多情况下直接在对等方之间通信，因此任何通信对等方的IP地址都是可用的。IP地址的主要隐私问题与地理位置和跟踪端点用户的可能性有关。避免此类问题的主要方法是引入中继（例如，使用中继NAT（TURN）服务器[RFC5766]进行遍历）或集中式媒体混合器或转发器，这些转发器对任何其他对等方隐藏对等方的地址。显然，需要仔细考虑这些继电器的安全性和可靠性。
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].
如果规范名称（CNAME）是根据RTP规范以user@host. 此类RTCP CNAME可能在多个会话中长期稳定，允许跟踪用户。这对于长期的故障跟踪和诊断是可取的，但它显然具有隐私含义。相反，可以按照“选择RTP控制协议（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.
如果存在隐私目标，则需要考虑这些目标，并根据这些目标设计系统。此外，某些RTP功能可能必须配置为保护隐私，或者对如何实现有要求。
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.
谈到RTP安全性，最合适的解决方案通常高度依赖于通信会话的拓扑结构。信令还影响可以提供哪些信息，以及这对于一个组来说是实例特定的还是通用的。最后，密钥管理系统将极大地影响应用程序实现的安全属性。同时，应用程序的通信结构限制了适用的关键管理方法。由于不同的密钥管理方法对底层基础设施有不同的要求，因此在设计的早期考虑这一方面很重要。
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.
加密密钥管理指南[RFC4107]概述了为什么自动密钥管理很重要。它们还强烈建议使用自动密钥管理。本文档中介绍的大多数安全解决方案都提供或支持自动密钥管理，至少用于建立会话密钥。在一些更长期的用例中，在某些情况下可能需要手动部署凭据。
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.
对于SRTP，自动密钥管理的一个重要方面是确保不会出现两个时间pad，特别是通过防止多个端点使用相同的会话密钥和SSRC。在这些情况下，自动密钥管理方法可能对信令功能有很强的依赖性，以确保其正常运行。如果无法满足这些依赖关系，则可能需要对使用进行额外的限制，例如每个端点会话密钥，以避免该问题。
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.
在选择RTP应用程序的安全机制时，考虑密钥管理的特性是很重要的。使用自动和集成的密钥管理将为用户提供最小的中断，这对于确保默认情况下可以并将保持安全性非常重要。
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
如果安全机制仅提供安全隧道，例如，像IPSec的一些常见用途（第3.3节），那么考虑系统的完整端到端属性是很重要的。如何确保从端点到本地隧道入口/出口的路径是安全的，并且可以信任（对于隧道的另一端也是如此）？当安全协议标识隧道的另一端时，如何处理对等方的源身份验证？当考虑基于隧道的安全协议而不是基于
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.
端到端的。即使有明确的需求和知识，即仍然可以使用基于隧道的解决方案实现安全属性，也应该更喜欢使用端到端机制，因为它们不太可能违反关于部署的任何假设。这些假设也很难自动验证。
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.
使用明文密钥的密钥管理解决方案，如SDP安全说明（第3.1.3节），需要注意确保包含明文密钥的信令消息的安全传输。对于明文密钥，系统的安全属性取决于在发送方和接收方之间端到端保护明文密钥的安全程度。不仅需要考虑为信令消息提供哪些传输保护，包括密钥，而且还要考虑信令中的任何中间人的信任程度。不受信任的中介可以对通信执行MITM攻击，也可以记录密钥，从而在实际通信发生后导致加密严重受损。
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.
很少有RTP应用程序作为独立的应用程序存在，它们从不与任何其他应用程序进行互操作。相反，它们能够与潜在的大量其他系统进行通信。为了最小化需要实施的安全机制的数量，重要的是考虑是否可以使用与其他应用程序相同的安全机制。这还可以减少确定在特定会话中实际协商的安全级别的问题。
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.
在某些情况下，互操作的愿望可能与应用程序的安全要求相冲突。为了实现安全目标，可能需要牺牲互操作性。或者，可以实现多种安全机制；然而，这带来了确保用户理解使用特定安全系统意味着什么的复杂性。此外，应用程序可能会变得容易受到出价下降攻击。
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.
在下文中，我们将介绍一些使用RTP服务或框架的应用程序安全解决方案示例。提供这些示例是为了说明可用的选择。它们不是安全方面的规范性建议。
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.
2009年，IETF评估了使用点对点SIP会话建立的RTP会话的媒体安全性。确定了一些要求，并在此基础上分析了现有的媒体安全解决方案，特别是密钥方法。由此产生的需求和分析发表在[RFC5479]中。基于此分析和工作组讨论，DTLS-SRTP被确定为最佳解决方案。
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-SRTP的SIP安全解决方案在“使用数据报传输层安全性（DTLS）建立安全实时传输协议（SRTP）安全上下文的框架”中定义[RFC5763]。在较高级别上，该框架使用SIP和SDP提供/应答过程来交换网络地址，其中服务器端点将运行启用DTLS SRTP的服务器。SIP信令还用于交换每个端点将在DTLS建立过程中使用的证书的指纹。当信令充分完成时，DTLS-SRTP客户端执行DTLS握手并建立SRTP会话密钥。客户端还验证证书的指纹，以验证中间没有人插入到交换机中。
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.
DTLS具有许多良好的安全属性。例如，要启用MITM，信令路径中的某人需要执行活动操作并修改信令消息和DTLS握手。还存在使指纹能够绑定到身份的解决方案。SIP标识为每个用户提供由第一个代理建立的标识[RFC4474]。这减少了连接用户代理必须信任的节点数量，以仅包括第一跳代理，而不是完整的信令路径。该系统最大的安全弱点是对信令的依赖性。SIP信令通过多个节点，通常没有部署消息安全性，只有节点之间的逐跳传输安全性（如果有的话）。
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].
Web实时通信（WebRTC）[WebRTC]是一种在浏览器之间直接为JavaScript Web应用程序提供实时媒体的解决方案。使用RTP传输媒体，并使用SRTP[RFC3711]的强制应用程序进行保护，使用DTLS-SRTP[RFC5764]进行键控。安全配置在“WebRTC安全体系结构”[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
将对等方证书的散列提供给JavaScript web应用程序，允许该web应用程序验证对等方的身份。有几种方法可以使用证书哈希
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.
已证实的WebRTC安全体系结构[WebRTC SEC]中确定的一种方法是使用身份提供程序。在该解决方案中，作为web应用程序的第三方的身份提供者对DTLS-SRTP哈希进行签名，并结合一条关于已用于签名哈希的用户身份有效性的声明。这样的身份断言的接收者随后可以独立地验证用户身份，以确保该用户身份是接收者打算与之通信的身份，并且密码断言持有该用户身份；这样，用户可以确定应用程序也不能执行MITM并获取媒体通信的密钥。存在验证证书哈希的其他方法；例如，可以根据一些带外通道中的散列（例如，与打印在名片上的散列进行比较）或使用口头短认证字符串（例如，如ZRTP[RFC6189]）或使用散列连续性来验证它们。
In the development of WebRTC, there has also been attention given to privacy considerations. The main RTP-related concerns that have been raised are:
在WebRTC的开发过程中，也注意到了隐私问题。提出的主要RTP相关问题包括：
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.
位置泄露：由于交互式连接建立（ICE）协商[RFC5245]为浏览器提供IP地址和端口，这会将信令中的位置信息泄露给对等方。为了防止这种情况，可以阻止任何不是中继候选的ICE候选的使用，即，提供的IP和端口属于服务提供商媒体流量中继。
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.
阻止会话之间的跟踪：静态RTP CNAMEs和DTLS-SRTP证书提供在会话实例之间重用的信息。因此，为了防止跟踪，这些信息不应该在会话之间重用，或者不应该以明文形式发送。请注意，每次生成新证书都会妨碍身份验证的连续性，但是，由于WebRTC用户预期将使用多个设备访问同一通信服务，因此无论如何都不能期望这种连续性；相反，必须依赖上述身份机制。
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.
注意：上述案例的重点是从其他方提供隐私，而不是从提供WebRTC JavaScript应用程序的web服务器提供隐私。
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
在IMS中，核心网络由单个运营商控制，或者由多个相互高度信任的运营商控制。除某些类型的访问外，运营商完全控制，没有包通过Internet路由。核心网络中的节点提供
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).
语音邮件、与传统系统（公共交换电话网（PSTN）、全球移动通信系统（GSM）和3G）的互通以及转码等服务。端点在SIP注册期间使用IMS和身份验证和密钥协议（AKA）（使用用户身份模块（SIM）凭据）或SIP摘要（使用密码）进行身份验证。
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.
因此，在IMS媒体安全[T3GPP.33.328]中，端到端加密不被视为需要或期望的加密，因为它会阻碍例如互通和转码，使得不兼容终端之间的呼叫不可能。因此，IMS媒体安全主要使用端到端访问边缘安全，其中SRTP在核心网络的第一个节点中终止。由于SIP信令是受信任和加密的（使用TLS或IPsec），因此安全描述[RFC4568]被认为能够很好地防止未加密的访问（GSM、3G和长期演进（LTE））上的窃听。媒体源身份验证基于对SRTP会话密钥的了解和信任，因为IMS网络将只转发来自正确端点的媒体。
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.
对于企业和政府机构来说，它们可能对IMS核心网络的信任度较低，并且可以假设它们有兼容的终端，可以通过部署自己的密钥管理服务器来实现端到端的安全性。
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.
与WebRTC的互通工作目前正在进行中；安全性仍将是端到端访问边缘，但使用DTLS-SRTP[RFC5763]代替安全性描述。
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）[T3GPP.26.234R11]的3GPP第11版PSS规范在附录R中定义了一组安全机制。这些安全机制涉及保护内容不被复制，即数字版权管理（DRM）。为了通过指定的解决方案实现这些目标，客户机实现和应用程序平台可以受到信任，以防止攻击者的访问和修改。
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
PSS是由RTSP 1.0[RFC2326]通过RTP进行流媒体控制的媒体。因此，其用户希望访问受保护内容的RTSP客户端将请求受保护内容的会话描述（SDP[RFC4566]）。此SDP将指示媒体受ISMACryp 2.0[ISMACryp2]编码应用单元（AUs）保护。用于保护介质的密钥以两种方式之一提供。如果使用单个密钥，则客户端使用某个DRM系统来检索SDP中指示的密钥。通常，OMA DRM v2[OMADRMv2]将用于检索密钥。如果要使用多个键
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].
然后建立与媒体流并行的用于密钥更新的附加RTSP流，其中密钥更新使用OMA移动广播服务[OMABCAST]的“移动广播服务的服务和内容保护”部分[omacp]中定义的短期密钥消息发送到客户端。
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.
值得注意的是，该解决方案没有为RTP报头和有效负载报头信息提供任何完整性验证方法；只有已编码的媒体AU受到保护。3GPP尚未定义支持任何可提供该服务的解决方案的任何要求。因此，重播或插入攻击是可能的。另一个属性是，媒体内容可以由提供媒体的内容提供保护，因此RTSP服务器的操作员无法访问未受保护的内容。相反，所有想要访问媒体的人都应该联系DRM密钥服务器，如果设备可以接受，他们将获得解密媒体的密钥。
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.
为了保护信令，RTSP 1.0支持使用TLS。然而，PSS规范中并未明确讨论这一点。TLS的使用可以防止修改会话描述信息，并有助于维护用户正在观看的内容的隐私，因为所有URL都将受到保密保护。
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.
实时流协议2.0[RTSP]与PSS服务（第5.4节）进行了有趣的比较，PSS服务基于RTSP 1.0和移动运营商感知的服务要求。RTSP 1.0和RTSP 2.0之间的一个主要区别是，2.0完全是在强制实施安全机制的要求下定义的。由于它通过RTP指定了一种传输介质，它还为RTP传输的介质流定义了安全机制。
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.
RTSP 2.0中RTP的安全目标是确保RTSP服务器和客户端之间具有机密性、完整性和源身份验证。这是为了防止出于隐私原因窃听用户正在观看的内容，并防止对媒体流的重播或注入攻击。为了达到这些目标，还必须保护信令，要求在客户端和服务器之间使用TLS。
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
使用TLS保护的信令，客户机和服务器在执行设置请求和响应时就媒体传输方法达成一致。安全的媒体传输通常是通过UDP的SRTP（SAVP/RTP）。SRTP的密钥管理是使用RSA-R模式的MIKEY。选择RSA-R模式是因为它允许RTSP服务器选择密钥，尽管RTSP客户端启动了MIKEY交换。它也
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.
在创建MIKEY消息时允许重用RTSP服务器的TLS证书，从而确保RTSP服务器和密钥交换之间的绑定。假设设置过程正常，这将在RTSP服务器和客户端之间为RTP传输的媒体流建立SRTP加密上下文。
This entire document is about security. Please read it.
整个文档都是关于安全性的。请读一下。
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).
我们感谢IESG对[RFC7202]的仔细审查，这导致了本备忘录的编写。John Mattsson提供了IMS媒体安全示例（第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.
作者希望感谢Christian Correll、Dan Wing、Kevin Gross、Alan Johnston、Michael Peck、Ole Jacobsen、Spencer Dawkins、Stephen Farrell、John Mattsson和Suresh Krishnan对文本的评论和改进建议。
[AES-GCM] McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", Work in Progress, September 2013.
[AES-GCM]McGrew，D.和K.Igoe，“安全RTP（SRTP）中的AES-GCM和AES-CCM认证加密”，正在进行的工作，2013年9月。
[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.
[ARIA-SRTP]Kim，W.，Lee，J.，Kim，D.，Park，J.，和D.Kwon，“ARIA算法及其与安全实时传输协议（SRTP）的使用”，正在进行的工作，2013年11月。
[EKT] McGrew, D. and D. Wing, "Encrypted Key Transport for Secure RTP", Work in Progress, February 2014.
[EKT]McGrew，D.和D.Wing，“安全RTP的加密密钥传输”，正在进行的工作，2014年2月。
[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>.
[ISMACryp2]互联网流媒体联盟（ISMA），“ISMA加密和认证版本2.0”，2007年11月<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>.
[OMABCAST]开放式移动联盟，“移动广播服务1.0版”，2009年2月<http://technical.openmobilealliance.org/Technical/ 发布程序/bcast\u v1\u 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>.
[OMADRMv2]开放式移动联盟，“OMA数字版权管理V2.0”，2008年7月<http://technical.openmobilealliance.org/ 技术/发布计划/drm\U v2\u 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>.
[OMACP]开放式移动联盟，“移动广播服务的服务和内容保护”，2013年1月<http://technical.openmobilealliance.org/Technical/ 发布程序/docs/BCAST/V1\u 0\u 1-20130109-A/OMA-TS-BCAST\u SvcCntProtection-V1\u 0\u 1-20130109-A.pdf>。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002.
[RFC3365]Schiller，J.“互联网工程任务组标准协议的强大安全要求”，BCP 61，RFC 3365，2002年8月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[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.
[RFC3640]van der Meer，J.，Mackie，D.，Swaminathan，V.，Singer，D.，和P.Gentric，“MPEG-4基本流传输的RTP有效载荷格式”，RFC 36402003年11月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[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.
[RFC4383]Baugher，M.和E.Carrara，“在安全实时传输协议（SRTP）中使用定时高效流丢失容忍认证（TESLA）”，RFC 4383，2006年2月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[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.
[RFC4567]Arkko，J.，Lindholm，F.，Naslund，M.，Norrman，K.，和E.Carrara，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，2006年7月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568]Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 4568，2006年7月。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4571]Lazzaro，J.，“面向连接传输上的帧实时传输协议（RTP）和RTP控制协议（RTCP）数据包”，RFC 4571，2006年7月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572]Lennox，J.，“会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输”，RFC 4572，2006年7月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650]Euchner，M.“HMAC认证的Diffie Hellman多媒体互联网密钥（MIKEY）”，RFC 46502006年9月。
[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.
[RFC4738]Ignjatic，D.，Dondeti，L.，Audet，F.，和P.Lin，“MIKEY-RSA-R：多媒体互联网密钥分配（MIKEY）中的另一种密钥分配模式”，RFC 4738，2006年11月。
[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.
[RFC4771]Lehtovirta，V.，Naslund，M.，和K.Norrman，“安全实时传输协议（SRTP）的完整性转换携带滚动计数器”，RFC 4771，2007年1月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 51172008年1月。
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions", RFC 5197, June 2008.
[RFC5197]Fries，S.和D.Ignjatic，“关于各种多媒体互联网键控（MIKEY）模式和扩展的适用性”，RFC 51972008年6月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009.
[RFC5479]Wing，D.，Fries，S.，Tschofenig，H.，和F.Audet，“媒体安全管理协议的要求和分析”，RFC 5479，2009年4月。
[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.
[RFC5669]Yoon，S.，Kim，J.，Park，H.，Jeong，H.，和Y.Won，“种子密码算法及其与安全实时传输协议（SRTP）的使用”，RFC 5669，2010年8月。
[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.
[RFC5760]Ott，J.，Chesterfield，J.，和E.Schooler，“具有单播反馈的单源多播会话的RTP控制协议（RTCP）扩展”，RFC 57602010年2月。
[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.
[RFC5763]Fischl，J.，Tschofenig，H.，和E.Rescorla，“使用数据报传输层安全性（DTLS）建立安全实时传输协议（SRTP）安全上下文的框架”，RFC 5763，2010年5月。
[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.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，2010年5月。
[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.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，2010年4月。
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6043, March 2011.
[RFC6043]Mattsson，J.和T.Tian，“MIKEY-TICKET：多媒体互联网密钥分配（MIKEY）中基于票据的密钥分配模式”，RFC 60432011年3月。
[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure RTP", RFC 6188, March 2011.
[RFC6188]McGrew，D.“AES-192和AES-256在安全RTP中的使用”，RFC 6188，2011年3月。
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, April 2011.
[RFC6189]Zimmermann，P.，Johnston，A.，和J.Callas，“ZRTP：单播安全RTP的媒体路径密钥协议”，RFC 6189，2011年4月。
[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.
[RFC6267]Cakulev，V.和G.Sundaram，“MIKEY-IBAKE：多媒体互联网密钥分配（MIKEY）中基于身份的认证密钥交换（IBAKE）模式”，RFC 6267，2011年6月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY)", RFC 6509, February 2012.
[RFC6509]Groves，M.，“MIKEY-SAKKE:Sakai Kasahara多媒体互联网密钥加密（MIKEY）”，RFC 65092012年2月。
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.
[RFC6562]Perkins，C.和JM。Valin，“带安全RTP的可变比特率音频使用指南”，RFC 6562，2012年3月。
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, April 2013.
[RFC6904]Lennox，J.，“安全实时传输协议（SRTP）中的报头扩展加密”，RFC 69042013年4月。
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, September 2013.
[RFC7022]Begen，A.，Perkins，C.，Wing，D.，和E.Rescorla，“选择RTP控制协议（RTCP）规范名称（CNAMEs）的指南”，RFC 7022，2013年9月。
[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.
[RFC7202]Perkins，C.和M.Westerlund，“保护RTP协议框架：为什么RTP不要求单一媒体安全解决方案”，RFC 7202，2014年4月。
[RTSP] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", Work in Progress, February 2014.
[RTSP]Schulzrinne，H.，Rao，A.，Lanphier，R.，Westerlund，M.，和M.Stiemerling，“实时流协议2.0（RTSP）”，正在进行的工作，2014年2月。
[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.234R11]3GPP，“技术规范组服务和系统方面；透明端到端分组交换流媒体服务（PSS）；协议和编解码器”，3GPP TS 26.234 11.1.012年9月<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.234R8]3GPP，“技术规范组服务和系统方面；透明端到端分组交换流媒体服务（PSS）；协议和编解码器”，3GPP TS 26.234 8.4.02009年9月<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.26.346]3GPP，“多媒体广播/多播服务（MBMS）；协议和编解码器”，3GPP TS 26.346 10.7.012013年3月<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.246]3GPP，“3G安全；多媒体广播/多播服务（MBMS）的安全”，3GPP TS 33.246 11.1.012年12月<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>.
[T3GPP.33.328]3GPP，“IP多媒体子系统（IMS）媒体平面安全”，3GPP TS 33.328 12.1.01212年12月<http://www.3gpp.org/DynaReport/33328.htm>.
[WebRTC-SEC] Rescorla, E., "WebRTC Security Architecture", Work in Progress, February 2014.
[WebRTC SEC]Rescorla，E.，“WebRTC安全架构”，正在进行的工作，2014年2月。
[WebRTC] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, February 2014.
[WebRTC]Alvestrand，H.，“概述：基于浏览器的应用程序的实时协议”，进展中的工作，2014年2月。
Authors' Addresses
作者地址
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden
Magnus Westerlund Ericsson Farogatan 6 SE-164 80瑞典基斯塔
Phone: +46 10 714 82 87
EMail: magnus.westerlund@ericsson.com
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
柯林帕金斯格拉斯哥大学计算科学学院格拉斯哥G128QQ英国
EMail: csp@csperkins.org
URI: http://csperkins.org/
EMail: csp@csperkins.org
URI: http://csperkins.org/