Network Working Group D. Wing, Ed.
Request for Comments: 5479 Cisco
Category: Informational S. Fries
Siemens AG
H. Tschofenig
Nokia Siemens Networks
F. Audet
Nortel
April 2009
Network Working Group D. Wing, Ed.
Request for Comments: 5479 Cisco
Category: Informational S. Fries
Siemens AG
H. Tschofenig
Nokia Siemens Networks
F. Audet
Nortel
April 2009
Requirements and Analysis of Media Security Management Protocols
媒体安全管理协议的需求与分析
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document.
本文档描述了协议的要求，以协商SIP信号安全RTP（SRTP）媒体的安全上下文。除了自然的安全需求外，该协商协议还必须在某些方面与SIP良好地互操作。已经发布了许多提案，这些提案的摘要见本文件附录。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
4. Call Scenarios and Requirements Considerations . . . . . . . . 7
4.1. Clipping Media before Signaling Answer . . . . . . . . . . 7
4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 8
4.3. Recording . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. PSTN Gateway . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Call Setup Performance . . . . . . . . . . . . . . . . . . 12
4.6. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Upgrading to SRTP . . . . . . . . . . . . . . . . . . . . 13
4.8. Interworking with Other Signaling Protocols . . . . . . . 14
4.9. Certificates . . . . . . . . . . . . . . . . . . . . . . . 14
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Key Management Protocol Requirements . . . . . . . . . . . 15
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 16
5.3. Requirements outside of the Key Management Protocol . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Overview and Evaluation of Existing Keying
Mechanisms . . . . . . . . . . . . . . . . . . . . . 24
A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 25
A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 25
A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 25
A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 25
A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 25
A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 26
A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 26
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 26
A.1.8. SDP Security Descriptions with SIPS . . . . . . . . . 26
A.1.9. SDP Security Descriptions with S/MIME . . . . . . . . 27
A.1.10. SDP-DH (Expired) . . . . . . . . . . . . . . . . . . . 27
A.1.11. MIKEYv2 in SDP (Expired) . . . . . . . . . . . . . . . 27
A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 27
A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.3. Signaling and Media Path Keying Techniques . . . . . . . . 28
A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 28
A.3.3. MIKEYv2 Inband (Expired) . . . . . . . . . . . . . . . 29
A.4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . 29
A.4.1. Secure Retargeting and Secure Forking . . . . . . . . 29
A.4.2. Clipping Media before SDP Answer . . . . . . . . . . . 31
A.4.3. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
4. Call Scenarios and Requirements Considerations . . . . . . . . 7
4.1. Clipping Media before Signaling Answer . . . . . . . . . . 7
4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 8
4.3. Recording . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. PSTN Gateway . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Call Setup Performance . . . . . . . . . . . . . . . . . . 12
4.6. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Upgrading to SRTP . . . . . . . . . . . . . . . . . . . . 13
4.8. Interworking with Other Signaling Protocols . . . . . . . 14
4.9. Certificates . . . . . . . . . . . . . . . . . . . . . . . 14
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Key Management Protocol Requirements . . . . . . . . . . . 15
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 16
5.3. Requirements outside of the Key Management Protocol . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Overview and Evaluation of Existing Keying
Mechanisms . . . . . . . . . . . . . . . . . . . . . 24
A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 25
A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 25
A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 25
A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 25
A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 25
A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 26
A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 26
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 26
A.1.8. SDP Security Descriptions with SIPS . . . . . . . . . 26
A.1.9. SDP Security Descriptions with S/MIME . . . . . . . . 27
A.1.10. SDP-DH (Expired) . . . . . . . . . . . . . . . . . . . 27
A.1.11. MIKEYv2 in SDP (Expired) . . . . . . . . . . . . . . . 27
A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 27
A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.3. Signaling and Media Path Keying Techniques . . . . . . . . 28
A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 28
A.3.3. MIKEYv2 Inband (Expired) . . . . . . . . . . . . . . . 29
A.4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . 29
A.4.1. Secure Retargeting and Secure Forking . . . . . . . . 29
A.4.2. Clipping Media before SDP Answer . . . . . . . . . . . 31
A.4.3. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . 33
A.5. Evaluation Criteria - Security . . . . . . . . . . . . . . 35
A.5.1. Distribution and Validation of Persistent Public
Keys and Certificates . . . . . . . . . . . . . . . . 35
A.5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 38
A.5.3. Best Effort Encryption . . . . . . . . . . . . . . . . 39
A.5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . 40
Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 42
B.1. Shared Key Conferencing . . . . . . . . . . . . . . . . . 42
A.5. Evaluation Criteria - Security . . . . . . . . . . . . . . 35
A.5.1. Distribution and Validation of Persistent Public
Keys and Certificates . . . . . . . . . . . . . . . . 35
A.5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 38
A.5.3. Best Effort Encryption . . . . . . . . . . . . . . . . 39
A.5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . 40
Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 42
B.1. Shared Key Conferencing . . . . . . . . . . . . . . . . . 42
The work on media security started when the Session Initiation Protocol (SIP) was still in its infancy. With the increased SIP deployment and the availability of new SIP extensions and related protocols, the need for end-to-end security was re-evaluated. The procedure of re-evaluating prior protocol work and design decisions is not an uncommon strategy and, to some extent, considered necessary to ensure that the developed protocols indeed meet the previously envisioned needs for the users on the Internet.
关于媒体安全的工作始于会话启动协议（SIP）尚处于起步阶段。随着SIP部署的增加以及新SIP扩展和相关协议的可用性，对端到端安全性的需求进行了重新评估。重新评估先前协议工作和设计决策的程序并非罕见的策略，在某种程度上，被认为是必要的，以确保开发的协议确实满足互联网用户先前设想的需求。
This document summarizes media security requirements, i.e., requirements for mechanisms that negotiate security context such as cryptographic keys and parameters for SRTP.
本文档总结了媒体安全要求，即协商安全上下文（如SRTP的加密密钥和参数）的机制的要求。
The organization of this document is as follows: Section 2 introduces terminology, Section 3 describes various attack scenarios against the signaling path and media path, Section 4 provides an overview about possible call scenarios, and Section 5 lists requirements for media security. The main part of the document concludes with the security considerations Section 6, and acknowledgements in Section 7. Appendix A lists and compares available solution proposals. The following Appendix A.4 compares the different approaches regarding their suitability for the SIP signaling scenarios described in Appendix A, while Appendix A.5 provides a comparison regarding security aspects. Appendix B lists non-goals for this document.
本文档的组织结构如下：第2节介绍了术语，第3节描述了针对信令路径和媒体路径的各种攻击场景，第4节概述了可能的呼叫场景，第5节列出了媒体安全要求。本文件的主要部分以第6节中的安全注意事项和第7节中的确认作为结束。附录A列出并比较了可用的解决方案建议。以下附录A.4比较了不同方法对附录A中描述的SIP信令场景的适用性，而附录A.5提供了关于安全方面的比较。附录B列出了本文件的非目标。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], with the important qualification that, unless otherwise stated, these terms apply to the design of the media security key management protocol, not its implementation or application.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释，其重要限定条件是，除非另有说明，否则这些术语适用于媒体安全密钥管理协议的设计，不是它的实现或应用。
Furthermore, the terminology described in SIP [RFC3261] regarding functions and components are used throughout the document.
此外，SIP[RFC3261]中描述的有关功能和组件的术语在整个文档中使用。
Additionally, the following items are used in this document:
此外，本文件中使用了以下项目：
AOR (Address-of-Record): A SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user.
AOR（记录地址）：指向具有位置服务的域的SIP或SIPS URI，该服务可以将URI映射到用户可能可用的另一个URI。通常，位置服务是通过注册来填充的。AOR通常被认为是用户的“公共地址”。
SSRC: The 32-bit value that defines the synchronization source, used in RTP. These are generally unique, but collisions can occur.
SSRC：定义同步源的32位值，用于RTP。这些通常是唯一的，但也可能发生碰撞。
two-time pad: The use of the same key and the same keystream to encrypt different data. For SRTP, a two-time pad occurs if two senders are using the same key and the same RTP SSRC value.
两次加密：使用相同的密钥和相同的密钥流加密不同的数据。对于SRTP，如果两个发送方使用相同的键和相同的RTP SSRC值，则会发生两次pad。
Perfect Forward Secrecy (PFS): The property that disclosure of the long-term secret keying material that is used to derive an agreed ephemeral key does not compromise the secrecy of agreed keys from earlier runs.
完美前向保密（PFS）：用于导出约定临时密钥的长期密钥材料的披露不会损害先前运行的约定密钥的保密性。
active adversary: An active adversary is able to alter data communication to affect its operation (see also [RFC4949]).
主动对手：主动对手能够改变数据通信以影响其操作（另请参见[RFC4949]）。
passive adversary: A passive adversary is able to learn information from data communication, but not alter that data communication (see also [RFC4949]).
被动对手：被动对手能够从数据通信中学习信息，但不能改变数据通信（另请参见[RFC4949]）。
signaling path: The signaling path is the route taken by SIP signaling messages transmitted between the calling and called user agents. This can be either direct signaling between the calling and called user agents or, more commonly, involves the SIP proxy servers that were involved in the call setup.
信令路径：信令路径是在主叫和被叫用户代理之间传输的SIP信令消息所采用的路由。这可以是呼叫和被叫用户代理之间的直接信令，或者更常见的是，涉及呼叫设置中涉及的SIP代理服务器。
media path: The media path is the route taken by media packets exchanged by the endpoints. In the simplest case, the endpoints exchange media directly, and the "media path" is defined by a quartet of IP addresses and TCP/UDP ports, along with an IP route. In other cases, this path may include RTP relays, mixers, transcoders, session border controllers, NATs, or media gateways.
媒体路径：媒体路径是端点交换的媒体包所采用的路由。在最简单的情况下，端点直接交换媒体，“媒体路径”由四个IP地址和TCP/UDP端口以及IP路由定义。在其他情况下，该路径可能包括RTP中继、混频器、转码器、会话边界控制器、NAT或媒体网关。
Moreover, as this document discusses requirements for media security, the nomenclature R-XXX is used to mark requirements, where XXX is the requirement, which needs to be met.
此外，由于本文件讨论了媒体安全的要求，术语R-XXX用于标记要求，其中XXX是需要满足的要求。
The discussion in this section relates to requirements R-ASSOC (specified in Section 5.1) R-PASS-MEDIA, R-PASS-SIG, R-SIG-MEDIA, R-ACT-ACT, and R-ID-BINDING (specified in Section 5.2).
本节中的讨论涉及R-ASSOC（第5.1节规定）R-PASS-MEDIA、R-PASS-SIG、R-SIG-MEDIA、R-ACT-ACT和R-ID-BINDING（第5.2节规定）的要求。
This document classifies adversaries according to their access and their capabilities. An adversary might have access:
本文档根据对手的访问权限和能力对其进行分类。对手可以访问：
1. only to the media path,
1. 仅限于媒体路径，
2. only to the signaling path,
2. 仅适用于信令路径，
3. to the media path and to the signaling path.
3. 到媒体路径和信令路径。
An attacker that can solely be located along the signaling path, and does not have access to media (item 2), is not considered in this document.
本文档不考虑仅位于信令路径上且无法访问介质（第2项）的攻击者。
There are two different types of adversaries: active and passive. An active adversary may need to be active with regard to the key exchange relevant information traveling along the media path or traveling along the signaling path.
有两种不同类型的对手：主动和被动。主动对手可能需要对沿媒体路径或沿信令路径移动的密钥交换相关信息保持主动。
Based on their robustness against the adversary capabilities described above, we can group security mechanisms using the following labels. This list is generally ordered from easiest to compromise (at the top) to more difficult to compromise:
基于它们对上述对手能力的鲁棒性，我们可以使用以下标签对安全机制进行分组。此列表通常从最容易妥协（顶部）到更难妥协：
+---------------+---------+--------------------------------------+
| SIP signaling | media | abbreviation |
+---------------+---------+--------------------------------------+
| none | passive | no-signaling-passive-media |
| none | active | no-signaling-active-media |
| passive | passive | passive-signaling-passive-media |
| passive | active | passive-signaling-active-media |
| active | passive | active-signaling-passive-media |
| active | active | active-signaling-active-media |
| active | active | active-signaling-active-media-detect |
+---------------+---------+--------------------------------------+
+---------------+---------+--------------------------------------+
| SIP signaling | media | abbreviation |
+---------------+---------+--------------------------------------+
| none | passive | no-signaling-passive-media |
| none | active | no-signaling-active-media |
| passive | passive | passive-signaling-passive-media |
| passive | active | passive-signaling-active-media |
| active | passive | active-signaling-passive-media |
| active | active | active-signaling-active-media |
| active | active | active-signaling-active-media-detect |
+---------------+---------+--------------------------------------+
no-signaling-passive-media: Access only to the media path is sufficient to reveal the content of the media traffic.
无信令被动媒体：仅访问媒体路径就足以显示媒体流量的内容。
passive-signaling-passive-media: Passive attack on the signaling and passive attack on the media path is necessary to reveal the content of the media traffic.
被动信令被动媒体：必须对信令和媒体路径进行被动攻击，以揭示媒体流量的内容。
passive-signaling-active-media: Passive attack on the signaling and active attack on the media path is necessary to reveal the content of the media traffic.
被动信令主动媒体：对信令的被动攻击和对媒体路径的主动攻击是揭示媒体流量内容所必需的。
active-signaling-passive-media: Active attack on the signaling path and passive attack on the media path is necessary to reveal the content of the media traffic.
主动信令被动媒体：主动攻击信令路径和被动攻击媒体路径是揭示媒体流量内容的必要条件。
no-signaling-active-media: Active attack on the media path is sufficient to reveal the content of the media traffic.
无信令活动媒体：对媒体路径的主动攻击足以揭示媒体流量的内容。
active-signaling-active-media: Active attack on both the signaling path and the media path is necessary to reveal the content of the media traffic.
主动信令主动媒体：必须对信令路径和媒体路径进行主动攻击，以显示媒体流量的内容。
active-signaling-active-media-detect: Active attack on both signaling and media path is necessary to reveal the content of the media traffic (as with active-signaling-active-media), and the attack is detectable by protocol messages exchanged between the endpoints.
主动信令-主动媒体检测：必须对信令和媒体路径进行主动攻击，以显示媒体流量的内容（与主动信令-主动媒体一样），并且通过端点之间交换的协议消息可以检测到攻击。
For example, unencrypted RTP is vulnerable to no-signaling-passive-media.
例如，未加密的RTP易受无信令被动介质的攻击。
As another example, SDP Security Descriptions [RFC4568], when protected by TLS (as it is commonly implemented and deployed), belong in the passive-signaling-passive-media category since the adversary needs to learn the SDP Security Descriptions key by seeing the SIP signaling message at a SIP proxy (assuming that the adversary is in control of the SIP proxy). The media traffic can be decrypted using that learned key.
作为另一个示例，当SDP安全描述[RFC4568]受到TLS保护时（通常实施和部署），属于被动信令被动媒体类别，因为对手需要通过在SIP代理上查看SIP信令消息来学习SDP安全描述密钥（假设对手控制着SIP代理）。可以使用该学习密钥对媒体流量进行解密。
As another example, DTLS-SRTP (Datagram Transport Layer Security Extension for SRTP) falls into active-signaling-active-media category when DTLS-SRTP is used with a public-key-based ciphersuite with self-signed certificates and without SIP Identity [RFC4474]. An adversary would have to modify the fingerprint that is sent along the signaling path and subsequently to modify the certificates carried in the DTLS handshake that travel along the media path. If DTLS-SRTP is used with both SIP Identity [RFC4474] and SIP Connected Identity [RFC4916], the RFC-4474 signature protects both the offer and the answer, and such a system would then belong to the active-signaling-active-media-detect category (provided, of course, the signaling path to the RFC-4474 authenticator and verifier is secured as per RFC 4474, and the RFC-4474 authenticator and verifier are behaving as per RFC 4474).
作为另一个示例，当DTLS-SRTP与具有自签名证书且无SIP标识的基于公钥的密码套件一起使用时，DTLS-SRTP（SRTP的数据报传输层安全扩展）属于主动信令主动媒体类别[RFC4474]。对手必须修改沿信令路径发送的指纹，然后修改沿媒体路径传输的DTLS握手中携带的证书。如果DTLS-SRTP与SIP标识[RFC4474]和SIP连接标识[RFC4916]一起使用，则RFC-4474签名保护提供和应答，这样的系统将属于主动信令主动媒体检测类别（当然，前提是到RFC-4474验证器和验证器的信令路径按照RFC 4474进行保护，并且RFC-4474验证器和验证器按照RFC 4474进行操作）。
The above discussion of DTLS-SRTP demonstrates how a single security protocol can be in different classes depending on the mode in which it is operated. Other protocols can achieve a similar effect by adding functions outside of the on-the-wire key management protocol itself. Although it may be appropriate to deploy lower-classed mechanisms in some cases, the ultimate security requirement for a media security negotiation protocol is that it have a mode of operation available in which is detect-attack, which provides protection against the passive and active attacks and provides detection of such attacks. That is, there must be a way to use the protocol so that an active attack is required against both the signaling and media paths, and so that such attacks are detectable by the endpoints.
上面对DTLS-SRTP的讨论演示了单个安全协议如何根据其操作模式分为不同的类别。其他协议可以通过在在线密钥管理协议本身之外添加功能来实现类似的效果。尽管在某些情况下可能适合部署较低级别的机制，但媒体安全协商协议的最终安全要求是，它具有一种可用的操作模式，即检测攻击，该模式针对被动和主动攻击提供保护，并提供对此类攻击的检测。也就是说，必须有一种使用协议的方法，以便对信令和媒体路径都需要主动攻击，并且这样的攻击可以被端点检测到。
The following subsections describe call scenarios that pose the most challenge to the key management system for media data in cooperation with SIP signaling.
以下小节描述了对与SIP信令协作的媒体数据密钥管理系统构成最大挑战的呼叫场景。
Throughout the subsections, requirements are stated by using the nomenclature R- to state an explicit requirement. All of the stated requirements are explained in detail in Section 5. They are listed according to their association to the key management protocol, to attack scenarios, and requirements that can be met inside the key management protocol or outside of the key management protocol.
在整个小节中，通过使用术语R-说明明确的要求来说明要求。第5节详细解释了所有规定的要求。它们是根据它们与密钥管理协议的关联、攻击场景以及可以在密钥管理协议内部或外部满足的要求列出的。
The discussion in this section relates to requirements R-AVOID-CLIPPING and R-ALLOW-RTP.
本节中的讨论涉及R-AVOID-CLIPPING和R-ALLOW-RTP要求。
Per the Session Description Protocol (SDP) Offer/Answer Model [RFC3264]:
根据会话描述协议（SDP）提供/应答模型[RFC3264]：
Once the offerer has sent the offer, it MUST be prepared to receive media for any recvonly streams described by that offer. It MUST be prepared to send and receive media for any sendrecv streams in the offer, and send media for any sendonly streams in the offer (of course, it cannot actually send until the peer provides an answer with the needed address and port information).
一旦要约人发送了要约，它必须准备接收该要约所描述的任何可接收流的媒体。它必须准备好为要约中的任何sendrecv流发送和接收媒体，并为要约中的任何sendonly流发送媒体（当然，在对等方提供带有所需地址和端口信息的应答之前，它无法实际发送）。
To meet this requirement with SRTP, the offerer needs to know the SRTP key for arriving media. If either endpoint receives encrypted media before it has access to the associated SRTP key, it cannot play the media -- causing clipping.
为了满足SRTP的这一要求，报价人需要知道到达媒体的SRTP密钥。如果任一端点在访问相关SRTP密钥之前接收到加密媒体，则无法播放该媒体，从而导致剪辑。
For key exchange mechanisms that send the answerer's key in SDP, a SIP provisional response [RFC3261], such as 183 (session progress), is useful. However, the 183 messages are not reliable unless both the calling and called endpoint support Provisional Response ACKnowledgement (PRACK) [RFC3262], use TCP across all SIP proxies, implement Security Preconditions [RFC5027], or both ends implement Interactive Connectivity Establishment [ICE] and the answerer implements the reliable provisional response mechanism described in ICE. Unfortunately, there is not wide deployment of any of these techniques and there is industry reluctance to require these techniques to avoid the problems described in this section.
对于在SDP中发送应答者密钥的密钥交换机制，SIP临时响应[RFC3261]非常有用，例如183（会话进度）。然而，183条消息并不可靠，除非主叫端和被叫端都支持临时响应确认（PRACK）[RFC3262]，在所有SIP代理中使用TCP，实现安全先决条件[RFC5027]，或者两端都实现交互式连接建立[ICE]应答者实现了ICE中描述的可靠临时响应机制。不幸的是，这些技术中的任何一种都没有得到广泛的应用，行业不愿意要求这些技术来避免本节中描述的问题。
Note that the receipt of an SDP answer is not always sufficient to allow media to be played to the offerer. Sometimes, the offerer must send media in order to open up firewall holes or NAT bindings before media can be received (for details, see [MIDDLEBOX]). In this case, even a solution that makes the key available before the SDP answer arrives will not help.
请注意，收到SDP回复并不总是足以让媒体播放给报价人。有时，为了打开防火墙漏洞或NAT绑定，报价人必须先发送媒体，然后才能接收媒体（有关详细信息，请参阅[MIDDLEBOX]）。在这种情况下，即使是在SDP答案到达之前提供密钥的解决方案也没有帮助。
Preventing the arrival of early media (i.e., media that arrives at the SDP offerer before the SDP answer arrives) might obsolete the R-AVOID-CLIPPING requirement, but at the time of writing such early media exists in many normal call scenarios.
阻止早期媒体（即，在SDP应答到达之前到达SDP报价人的媒体）的到来可能会使R-AVOID-CLIPPING要求过时，但在撰写本文时，这种早期媒体存在于许多正常呼叫场景中。
The discussion in this section relates to requirements R-FORK-RETARGET, R-DISTINCT, R-HERFP, and R-BEST-SECURE.
本节中的讨论涉及R-FORK-RETARGET、R-DISTINCT、R-HERFP和R-BEST-SECURE的需求。
In SIP, a request sent to a specific AOR but delivered to a different AOR is called a "retarget". A typical scenario is a "call forwarding" feature. In Figure 1, Alice sends an INVITE in step 1 that is sent to Bob in step 2. Bob responds with a redirect (SIP response code 3xx) pointing to Carol in step 3. This redirect typically does not propagate back to Alice but only goes to a proxy (i.e., the retargeting proxy) that sends the original INVITE to Carol in step 4.
在SIP中，发送到特定AOR但传递到不同AOR的请求称为“重定目标”。一个典型的场景是“呼叫转移”功能。在图1中，Alice在步骤1中发送一个邀请，在步骤2中发送给Bob。Bob在步骤3中用指向Carol的重定向（SIP响应代码3xx）进行响应。此重定向通常不会传播回Alice，而只会传播到在步骤4中将原始邀请发送给Carol的代理（即重定目标代理）。
+-----+
|Alice|
+--+--+
|
| INVITE (1)
V
+----+----+
| proxy |
++-+-----++
| ^ |
INVITE (2) | | | INVITE (4)
& redirect (3) | | |
V | V
++-++ ++----+
|Bob| |Carol|
+---+ +-----+
+-----+
|Alice|
+--+--+
|
| INVITE (1)
V
+----+----+
| proxy |
++-+-----++
| ^ |
INVITE (2) | | | INVITE (4)
& redirect (3) | | |
V | V
++-++ ++----+
|Bob| |Carol|
+---+ +-----+
Figure 1: Retargeting
图1：重定目标
Using retargeting might lead to situations where the User Agent Client (UAC) does not know where its request will be going. This might not immediately seem like a serious problem; after all, when one places a telephone call on the Public Switched Telephone Network (PSTN), one never really knows if it will be forwarded to a different number, who will pick up the line when it rings, and so on. However, when considering SIP mechanisms for authenticating the called party, this function can also make it difficult to differentiate an intermediary that is behaving legitimately from an attacker. From this perspective, the main problems with retargeting are:
使用重定目标可能会导致用户代理客户端（UAC）不知道其请求的去向。这可能不会立即成为一个严重的问题；毕竟，当一个人在公共交换电话网（PSTN）上打电话时，他永远不知道电话是否会被转接到另一个号码，电话铃响时谁来接电话，等等。但是，在考虑对被叫方进行身份验证的SIP机制时，此功能也会使区分行为合法的中间人和攻击者变得困难。从这个角度来看，重定目标的主要问题是：
Not detectable by the caller: The originating user agent has no means of anticipating that the condition will arise, nor any means of determining that it has occurred until the call has already been set up.
呼叫方无法检测到：发起用户代理无法预测该情况将出现，也无法确定该情况已发生，直到呼叫已建立。
Not preventable by the caller: There is no existing mechanism that might be employed by the originating user agent in order to guarantee that the call will not be retargeted.
调用者不可预防：发起用户代理不可能使用现有机制来保证调用不会被重定目标。
The mechanism used by SIP for identifying the calling party is SIP Identity [RFC4474]. However, due to the nature of retargeting, SIP Identity can only identify the calling party (that is, the party that initiated the SIP request). Some key exchange mechanisms predate SIP Identity and include their own identity mechanism (e.g., Multimedia Internet KEYing (MIKEY)). However, those built-in identity mechanism also suffer from the SIP retargeting problem. While Connected Identity [RFC4916] allows positive identification of the called party, the primary difficulty still remains that the calling party
SIP用于识别呼叫方的机制是SIP标识[RFC4474]。然而，由于重定目标的性质，SIP标识只能识别主叫方（即发起SIP请求的一方）。一些密钥交换机制早于SIP身份，并且包括它们自己的身份机制（例如，多媒体互联网密钥（MIKEY））。然而，这些内置的身份机制也存在SIP重定目标问题。虽然连接标识[RFC4916]允许对被叫方进行正面识别，但主叫方仍然是主要的困难
does not know if a mismatched called party is legitimate (i.e., due to authorized retargeting) or illegitimate (i.e., due to unauthorized retargeting by an attacker above to modify SIP signaling).
不知道不匹配的被叫方是合法的（即，由于授权的重定目标）还是非法的（即，由于上述攻击者未经授权的重定目标以修改SIP信令）。
In SIP, 'forking' is the delivery of a request to multiple locations. This happens when a single AOR is registered more than once. An example of forking is when a user has a desk phone, PC client, and mobile handset all registered with the same AOR.
在SIP中，“分叉”是将请求传递到多个位置。当一个AOR被多次注册时，就会发生这种情况。分叉的一个例子是，当用户的台式电话、PC客户端和移动手机都注册了相同的AOR时。
+-----+
|Alice|
+--+--+
|
| INVITE
V
+-----+-----+
| proxy |
++---------++
| |
INVITE | | INVITE
V V
+--+--+ +--+--+
|Bob-1| |Bob-2|
+-----+ +-----+
+-----+
|Alice|
+--+--+
|
| INVITE
V
+-----+-----+
| proxy |
++---------++
| |
INVITE | | INVITE
V V
+--+--+ +--+--+
|Bob-1| |Bob-2|
+-----+ +-----+
Figure 2: Forking
图2：分叉
With forking, both Bob-1 and Bob-2 might send back SDP answers in SIP responses. Alice will see those intermediate (18x) and final (200) responses. It is useful for Alice to be able to associate the SIP response with the incoming media stream. Although this association can be done with ICE [ICE], and ICE is useful to make this association with RTP, it is not desirable to require ICE to accomplish this association.
使用分叉，Bob-1和Bob-2都可以在SIP响应中发回SDP应答。Alice将看到这些中间（18x）和最终（200）响应。Alice能够将SIP响应与传入的媒体流相关联是很有用的。尽管这种关联可以通过ICE[ICE]来实现，并且ICE对于与RTP进行这种关联是有用的，但不希望要求ICE来实现这种关联。
Forking and retargeting are often used together. For example, a boss and secretary might have both phones ring (forking) and rollover to voice mail if neither phone is answered (retargeting).
分叉和重定目标通常一起使用。例如，如果两部电话都没有接听（重定目标），老板和秘书可能同时有电话铃响（分叉）和翻滚到语音邮件。
To maintain the security of the media traffic, only the endpoint that answers the call should know the SRTP keys for the session. Forked and retargeted calls only reveal sensitive information to non-responders when the signaling messages contain sensitive information (e.g., SRTP keys) that is accessible by parties that receive the offer, but may not respond (i.e., the original recipients in a retargeted call, or non-answering endpoints in a forked call). For key exchange mechanisms that do not provide secure forking or secure retargeting, one workaround is to rekey immediately after forking or
为了维护媒体流量的安全性，只有应答呼叫的端点应该知道会话的SRTP密钥。当信令消息包含敏感信息（例如，SRTP密钥）时，分叉呼叫和重定目标呼叫仅向无应答者透露敏感信息，该敏感信息可由接收要约的各方访问，但可能不响应（例如，重定目标呼叫中的原始收件者，或分叉呼叫中的无应答端点）。对于不提供安全分叉或安全重定目标的密钥交换机制，一种解决方法是在分叉或重定目标后立即重新设置密钥
retargeting. However, because the originator may not be aware that the call forked this mechanism requires rekeying immediately after every session is established. This doubles the number of messages processed by the network.
重新定位。但是，由于发起人可能不知道呼叫分叉，因此该机制需要在每次会话建立后立即重新键入。这使网络处理的消息数量增加了一倍。
Further compounding this problem is a unique feature of SIP that, when forking is used, there is always only one final error response delivered to the sender of the request: the forking proxy is responsible for choosing which final response to choose in the event where forking results in multiple final error responses being received by the forking proxy. This means that if a request is rejected, say with information that the keying information was rejected and providing the far end's credentials, it is very possible that the rejection will never reach the sender. This problem, called the Heterogeneous Error Response Forking Problem (HERFP) [RFC3326], is difficult to solve in SIP. Because we expect the HERFP to continue to be a problem in SIP for the foreseeable future, a media security system should function even in the presence of HERFP behavior.
进一步加剧这个问题的是SIP的一个独特功能，当使用分叉时，始终只有一个最终错误响应传递给请求的发送方：如果分叉导致分叉代理收到多个最终错误响应，分叉代理负责选择哪个最终响应。这意味着，如果请求被拒绝，比如说密钥信息被拒绝并提供远端的凭据，那么拒绝很可能永远不会到达发送方。这个问题称为异构错误响应分叉问题（HERFP）[RFC3326]，在SIP中很难解决。由于我们预计在可预见的未来，HERFP将继续成为SIP中的一个问题，因此即使存在HERFP行为，媒体安全系统也应该正常工作。
The discussion in this section relates to requirement R-RECORDING.
本节中的讨论与R记录要求有关。
Some business environments, such as stock brokerages, banks, and catalog call centers, require recording calls with customers. This is the familiar "this call is being recorded for quality purposes" heard during calls to these sorts of businesses. In these environments, media recording is typically performed by an intermediate device (with RTP, this is typically implemented in a 'sniffer').
某些业务环境，如股票经纪公司、银行和目录呼叫中心，需要记录与客户的通话。这是在打电话给这类企业时听到的熟悉的“为了提高质量，正在录制此电话”。在这些环境中，媒体记录通常由中间设备执行（对于RTP，这通常在“嗅探器”中实现）。
When performing such call recording with SRTP, the end-to-end security is compromised. This is unavoidable, but necessary because the operation of the business requires such recording. It is desirable that the media security is not unduly compromised by the media recording. The endpoint within the organization needs to be informed that there is an intermediate device and needs to cooperate with that intermediate device.
当使用SRTP执行此类通话记录时，端到端安全性受到威胁。这是不可避免的，但也是必要的，因为业务运营需要此类记录。希望媒体安全不被媒体记录不当地损害。需要通知组织内的端点存在中间设备，并且需要与该中间设备协作。
This scenario does not place a requirement directly on the key management protocol. The requirement could be met directly by the key management protocol (e.g., MIKEY-NULL or [RFC4568]) or through an external out-of-band mechanism (e.g., [SRTP-KEY]).
此场景不会直接对密钥管理协议提出要求。可通过密钥管理协议（如MIKEY-NULL或[RFC4568]）或通过外部带外机制（如[SRTP-key]）直接满足该要求。
The discussion in this section relates to requirement R-PSTN.
本节中的讨论与R-PSTN要求有关。
It is desirable, even when one leg of a call is on the PSTN, that the IP leg of the call be protected with SRTP.
理想的情况是，即使呼叫的一个分支在PSTN上，呼叫的IP分支也应使用SRTP进行保护。
A typical case of using media security where two entities are having a Voice over IP (VoIP) conversation over IP-capable networks. However, there are cases where the other end of the communication is not connected to an IP-capable network. In this kind of setting, there needs to be some kind of gateway at the edge of the IP network that converts the VoIP conversation to a format understood by the other network. An example of such a gateway is a PSTN gateway sitting at the edge of IP and PSTN networks (such as the architecture described in [RFC3372]).
使用媒体安全的典型案例，其中两个实体通过支持IP的网络进行IP语音（VoIP）对话。然而，存在通信的另一端未连接到具有IP能力的网络的情况。在这种设置中，IP网络边缘需要某种网关，将VoIP会话转换为另一个网络可以理解的格式。此类网关的一个示例是位于IP和PSTN网络边缘的PSTN网关（如[RFC3372]中描述的架构）。
If media security (e.g., SRTP protection) is employed in this kind of gateway-setting, then media security and the related key management is terminated at the PSTN gateway. The other network (e.g., PSTN) may have its own measures to protect the communication, but this means that from media security point of view the media security is not employed truly end-to-end between the communicating entities.
如果在这种网关设置中使用了媒体安全性（例如，SRTP保护），则媒体安全性和相关密钥管理将在PSTN网关处终止。另一个网络（例如，PSTN）可以有其自己的措施来保护通信，但这意味着从媒体安全的角度来看，媒体安全并没有在通信实体之间真正地端到端地使用。
The discussion in this section relates to requirement R-REUSE.
本节中的讨论涉及需求R-重用。
Some devices lack sufficient processing power to perform public key operations or Diffie-Hellman operations for each call, or prefer to avoid performing those operations on every call. The ability to reuse previous public key or Diffie-Hellman operations can vastly decrease the call setup delay and processing requirements for such devices.
有些设备缺乏足够的处理能力，无法对每个呼叫执行公钥操作或Diffie-Hellman操作，或者宁愿避免对每个呼叫执行这些操作。重用以前的公钥或Diffie-Hellman操作的能力可以大大减少此类设备的呼叫设置延迟和处理要求。
In certain devices, it can take a second or two to perform a Diffie-Hellman operation. Examples of these devices include handsets, IP Multimedia Services Identity Modules (ISIMs), and PSTN gateways. PSTN gateways typically utilize a Digital Signal Processor (DSP) that is not yet involved with typical DSP operations at the beginning of a call; thus, the DSP could be used to perform the calculation, so as to avoid having the central host processor perform the calculation. However, not all PSTN gateways use DSPs (some have only central processors or their DSPs are incapable of performing the necessary public key or Diffie-Hellman operation), and handsets lack a separate, unused processor to perform these operations.
在某些设备中，执行Diffie-Hellman操作可能需要一两秒钟。这些设备的示例包括手机、IP多媒体服务标识模块（ISIM）和PSTN网关。PSTN网关通常利用数字信号处理器（DSP），该数字信号处理器在呼叫开始时尚未涉及典型的DSP操作；因此，可以使用DSP来执行计算，从而避免由中央主机处理器执行计算。然而，并不是所有PSTN网关都使用DSP（有些只有中央处理器，或者它们的DSP无法执行必要的公钥或Diffie-Hellman操作），手机也缺少单独的、未使用的处理器来执行这些操作。
Two scenarios where R-REUSE is useful are calls between an endpoint and its voicemail server or its PSTN gateway. In those scenarios, calls are made relatively often and it can be useful for the voicemail server or PSTN gateway to avoid public key operations for subsequent calls.
R重用非常有用的两种场景是端点与其语音邮件服务器或PSTN网关之间的调用。在这些场景中，呼叫相对频繁，语音邮件服务器或PSTN网关可以避免后续呼叫的公钥操作。
Storing keys across sessions often interferes with perfect forward secrecy (R-PFS).
跨会话存储密钥通常会干扰完美前向保密（R-PFS）。
The discussion in this section relates to requirement R-TRANSCODER.
本节中的讨论与需求R转码器有关。
In some environments, it is necessary for network equipment to transcode from one codec (e.g., a highly compressed codec that makes efficient use of wireless bandwidth) to another codec (e.g., a standardized codec to a SIP peering interface). With RTP, a transcoding function can be performed with the combination of a SIP back-to-back user agent (B2BUA) to modify the SDP and a processor to perform the transcoding between the codecs. However, with end-to-end secured SRTP, a transcoding function implemented the same way is a man-in-the-middle attack, and the key management system prevents its use.
在一些环境中，网络设备必须从一个编解码器（例如，高效利用无线带宽的高压缩编解码器）转码到另一个编解码器（例如，标准化编解码器到SIP对等接口）。利用RTP，可以通过SIP背对背用户代理（B2BUA）的组合来执行转码功能，以修改SDP和处理器以执行编解码器之间的转码。然而，对于端到端安全SRTP，以相同方式实现的转码功能是中间人攻击，密钥管理系统阻止其使用。
However, such a network-based transcoder can still be realized with the cooperation and approval of the endpoint, and can provide end-to-transcoder and transcoder-to-end security.
然而，这种基于网络的转码器仍然可以在端点的合作和批准下实现，并且可以提供端到端转码器和转码器到端安全性。
The discussion in this section relates to the requirement R-ALLOW-RTP.
本节中的讨论与R-ALLOW-RTP要求有关。
Legitimate RTP media can be sent to an endpoint for announcements, colorful ringback tones (e.g., music), advertising, or normal call progress tones. The RTP may be received before an associated SDP answer. For details on various scenarios, see [EARLY-MEDIA].
合法的RTP媒体可以发送到端点，用于公告、彩色回铃音（如音乐）、广告或正常通话进度音。可以在相关联的SDP应答之前接收RTP。有关各种场景的详细信息，请参阅[早期媒体]。
While receiving such RTP exposes the calling party to a risk of receiving malicious RTP from an attacker, SRTP endpoints will need to receive and play out RTP media in order to be compatible with deployed systems that send RTP to calling parties.
虽然接收此类RTP会使主叫方面临从攻击者处接收恶意RTP的风险，但SRTP端点将需要接收并播放RTP媒体，以便与向主叫方发送RTP的已部署系统兼容。
The discussion in this section relates to the requirement R-OTHER-SIGNALING.
本节中的讨论涉及R-OTHER-SIGNALING的要求。
In many environments, some devices are signaled with protocols other than SIP that do not share SIP's offer/answer model (e.g., [H.248.1] or do not utilize SDP (e.g., H.323). In other environments, both endpoints may be SIP, but may use different key management systems (e.g., one uses MIKEY-RSA, the other MIKEY-RSA-R).
在许多环境中，一些设备使用SIP以外的协议发送信号，这些协议不共享SIP的提供/应答模型（例如，[H.248.1]或不使用SDP（例如，H.323）。在其他环境中，两个端点可以是SIP，但可以使用不同的密钥管理系统（例如，一个使用MIKEY-RSA，另一个使用MIKEY-RSA-R）。
In these environments, it is desirable to have SRTP -- rather than RTP -- between the two endpoints. It is always possible, although undesirable, to interwork those disparate signaling systems or disparate key management systems by decrypting and re-encrypting each SRTP packet in a device in the middle of the network (often the same device performing the signaling interworking). This is undesirable due to the cost and increased attack area, as such an SRTP/SRTP interworking device is a valuable attack target.
在这些环境中，最好在两个端点之间使用SRTP，而不是RTP。通过对网络中间的设备中的每个SRTP分组进行解密和重新加密（通常是执行信令互通的同一设备），总是可能的，尽管不希望的是互通这些不同的信令系统或不同的密钥管理系统。由于成本和增加的攻击区域，这是不可取的，因为这样的SRTP/SRTP互通设备是有价值的攻击目标。
At the time of this writing, interworking is considered important. Interworking without decryption/encryption of the SRTP, while useful, is not yet deemed critical because the scale of such SRTP deployments is, to date, relatively small.
在撰写本文时，互通被认为是重要的。在没有对SRTP进行解密/加密的情况下进行互通虽然很有用，但还不被认为是至关重要的，因为迄今为止，此类SRTP部署的规模相对较小。
The discussion in this section relates to R-CERTS.
本节中的讨论与R-CERTS相关。
On the Internet and on some private networks, validating another peer's certificate is often done through a trust anchor -- a list of Certificate Authorities that are trusted. It can be difficult or expensive for a peer to obtain these certificates. In all cases, both parties to the call would need to trust the same trust anchor (i.e., "certificate authority"). For these reasons, it is important that the media plane key management protocol offer a mechanism that allows end-users who have no prior association to authenticate to each other without acquiring credentials from a third-party trust point. Note that this does not rule out mechanisms in which servers have certificates and attest to the identities of end-users.
在Internet和某些专用网络上，验证另一个对等方的证书通常是通过信任锚来完成的——信任的证书颁发机构列表。对等方获取这些证书可能很困难，也可能很昂贵。在所有情况下，调用的双方都需要信任相同的信任锚（即“证书颁发机构”）。出于这些原因，重要的是，媒体平面密钥管理协议提供了一种机制，允许没有先前关联的最终用户相互验证，而无需从第三方信任点获取凭据。请注意，这并不排除服务器拥有证书并证明最终用户身份的机制。
This section is divided into several parts: requirements specific to the key management protocol (Section 5.1), attack scenarios (Section 5.2), and requirements that can be met inside the key management protocol or outside of the key management protocol (Section 5.3).
本节分为几个部分：密钥管理协议的特定要求（第5.1节）、攻击场景（第5.2节）以及密钥管理协议内部或外部可满足的要求（第5.3节）。
SIP Forking and Retargeting, from Section 4.2:
SIP分叉和重定目标，来自第4.2节：
R-FORK-RETARGET: The media security key management protocol MUST securely support forking and retargeting when all endpoints are willing to use SRTP without causing the call setup to fail. This requirement means the endpoints that did not answer the call MUST NOT learn the SRTP keys (in either direction) used by the answering endpoint.
R-FORK-RETARGET：当所有端点都愿意使用SRTP而不会导致呼叫设置失败时，媒体安全密钥管理协议必须安全地支持分叉和重定目标。此要求意味着未应答呼叫的端点不得学习应答端点使用的SRTP键（在任何方向）。
R-DISTINCT: The media security key management protocol MUST be capable of creating distinct, independent cryptographic contexts for each endpoint in a forked session.
R-DISTINCT：媒体安全密钥管理协议必须能够为分叉会话中的每个端点创建不同的、独立的加密上下文。
R-HERFP: The media security key management protocol MUST function securely even in the presence of HERFP behavior, i.e., the rejection of key information does not reach the sender.
R-HERFP：媒体安全密钥管理协议必须安全运行，即使存在HERFP行为，即拒绝密钥信息不会到达发送方。
Performance considerations:
性能注意事项：
R-REUSE: The media security key management protocol MAY support the reuse of a previously established security context.
R-重用：媒体安全密钥管理协议可支持重用先前建立的安全上下文。
Note: reuse of the security context does not imply reuse of RTP parameters (e.g., payload type or SSRC).
注意：重用安全上下文并不意味着重用RTP参数（例如，有效负载类型或SSRC）。
Media considerations:
媒体注意事项：
R-AVOID-CLIPPING: The media security key management protocol SHOULD avoid clipping media before SDP answer without requiring Security Preconditions [RFC5027]. This requirement comes from Section 4.1.
R-AVOID-CLIPPING：介质安全密钥管理协议应避免在SDP应答之前剪切介质，而无需安全前提条件[RFC5027]。该要求来自第4.1节。
R-RTP-CHECK: If SRTP key negotiation is performed over the media path (i.e., using the same UDP/TCP ports as media packets), the key negotiation packets MUST NOT pass the RTP validity check defined in Appendix A.1 of [RFC3550], so that SRTP negotiation packets can be differentiated from RTP packets.
R-RTP-CHECK：如果通过媒体路径执行SRTP密钥协商（即，使用与媒体数据包相同的UDP/TCP端口），则密钥协商数据包不得通过[RFC3550]附录A.1中定义的RTP有效性检查，以便将SRTP协商数据包与RTP数据包区分开来。
R-ASSOC: The media security key management protocol SHOULD include a mechanism for associating key management messages with both the signaling traffic that initiated the session and with protected media traffic. It is useful to associate key management messages with call signaling messages, as this allows the SDP offerer to avoid performing CPU-consuming operations (e.g., Diffie-Hellman or public key operations) with attackers that have not seen the signaling messages.
R-ASSOC：媒体安全密钥管理协议应包括一种机制，用于将密钥管理消息与启动会话的信令通信量和受保护的媒体通信量相关联。将密钥管理消息与呼叫信令消息相关联非常有用，因为这允许SDP提供方避免与未看到信令消息的攻击者执行CPU消耗操作（例如Diffie Hellman或公钥操作）。
For example, if using a Diffie-Hellman keying technique with security preconditions that forks to 20 endpoints, the call initiator would get 20 provisional responses containing 20 signed Diffie-Hellman key pairs. Calculating 20 Diffie-Hellman secrets and validating signatures can be a difficult task for some devices. Hence, in the case of forking, it is not desirable to perform a Diffie-Hellman operation with every party, but rather only with the party that answers the call (and incur some media clipping). To do this, the signaling and media need to be associated so the calling party knows which key management exchange needs to be completed. This might be done by using the transport address indicated in the SDP, although NATs can complicate this association.
例如，如果使用Diffie-Hellman键控技术，并将安全先决条件分叉到20个端点，则调用发起方将获得20个临时响应，其中包含20个签名的Diffie-Hellman密钥对。对某些设备来说，计算20个Diffie-Hellman秘密和验证签名可能是一项困难的任务。因此，在分叉的情况下，不希望对每一方执行Diffie-Hellman操作，而是只对接听电话的一方执行操作（并引起一些媒体剪辑）。为此，需要将信令和媒体关联起来，以便呼叫方知道需要完成哪个密钥管理交换。这可以通过使用SDP中指示的传输地址来实现，尽管NAT会使这种关联复杂化。
Note: due to RTP's design requirements, it is expected that SRTP receivers will have to perform authentication of any received SRTP packets.
注：由于RTP的设计要求，预计SRTP接收器必须对任何接收到的SRTP数据包进行身份验证。
R-NEGOTIATE: The media security key management protocol MUST allow a SIP User Agent to negotiate media security parameters for each individual session. Such negotiation MUST NOT cause a two-time pad (Section 9.1 of [RFC3711]).
R-协商：媒体安全密钥管理协议必须允许SIP用户代理协商每个会话的媒体安全参数。此类协商不得导致两次pad（RFC3711第9.1节）。
R-PSTN: The media security key management protocol MUST support termination of media security in a PSTN gateway. This requirement is from Section 4.4.
R-PSTN：媒体安全密钥管理协议必须支持在PSTN网关中终止媒体安全。该要求来自第4.4节。
This section describes overall security requirements and specific requirements from the attack scenarios (Section 3).
本节描述了攻击场景的总体安全要求和具体要求（第3节）。
Overall security requirements:
总体安全要求：
R-PFS: The media security key management protocol MUST be able to support perfect forward secrecy.
R-PFS：媒体安全密钥管理协议必须能够支持完美的前向保密。
R-COMPUTE: The media security key management protocol MUST support offering additional SRTP cipher suites without incurring significant computational expense.
R-COMPUTE：媒体安全密钥管理协议必须支持提供额外的SRTP密码套件，而不会产生大量计算费用。
R-CERTS: The key management protocol MUST NOT require that end-users obtain credentials (certificates or private keys) from a third- party trust anchor.
R-CERTS：密钥管理协议不得要求最终用户从第三方信任锚获得凭据（证书或私钥）。
R-FIPS: The media security key management protocol SHOULD use algorithms that allow FIPS 140-2 [FIPS-140-2] certification or similar country-specific certification (e.g., [AISITSEC]).
R-FIPS：媒体安全密钥管理协议应使用允许FIPS 140-2[FIPS-140-2]认证或类似国家特定认证（例如[AISITSEC]）的算法。
The United States Government can only purchase and use crypto implementations that have been validated by the FIPS-140 [FIPS-140-2] process:
美国政府只能购买和使用经过FIPS-140[FIPS-140-2]流程验证的加密实现：
The FIPS-140 standard is applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems, including voice systems. The adoption and use of this standard is available to private and commercial organizations.
FIPS-140标准适用于所有使用基于密码的安全系统保护计算机和电信系统（包括语音系统）中敏感信息的联邦机构。本标准的采用和使用适用于私人和商业组织。
Some commercial organizations, such as banks and defense contractors, require or prefer equipment that has received the same validation.
一些商业组织，如银行和国防承包商，要求或更喜欢获得相同验证的设备。
R-DOS: The media security key management protocol MUST NOT introduce any new significant denial-of-service vulnerabilities (e.g., the protocol should not request the endpoint to perform CPU-intensive operations without the client being able to validate or authorize the request).
R-DOS：媒体安全密钥管理协议不得引入任何新的重大拒绝服务漏洞（例如，在客户端无法验证或授权请求的情况下，协议不应请求端点执行CPU密集型操作）。
R-EXISTING: The media security key management protocol SHOULD allow endpoints to authenticate using pre-existing cryptographic credentials, e.g., certificates or pre-shared keys.
R-EXISTING：媒体安全密钥管理协议应允许端点使用预先存在的加密凭据（例如证书或预共享密钥）进行身份验证。
R-AGILITY: The media security key management protocol MUST provide crypto- agility, i.e., the ability to adapt to evolving cryptography and security requirements (update of cryptographic algorithms without substantial disruption to deployed implementations).
R-敏捷性：媒体安全密钥管理协议必须提供加密敏捷性，即适应不断发展的加密和安全要求的能力（加密算法的更新不会对部署的实现造成实质性中断）。
R-DOWNGRADE: The media security key management protocol MUST protect cipher suite negotiation against downgrading attacks.
降级：媒体安全密钥管理协议必须保护密码套件协商免受降级攻击。
R-PASS-MEDIA: The media security key management protocol MUST have a mode that prevents a passive adversary with access to the media path from gaining access to keying material used to protect SRTP media packets.
R-PASS-MEDIA：媒体安全密钥管理协议必须具有一种模式，以防止访问媒体路径的被动对手访问用于保护SRTP媒体数据包的密钥材料。
R-PASS-SIG: The media security key management protocol MUST have a mode in which it prevents a passive adversary with access to the signaling path from gaining access to keying material used to protect SRTP media packets.
R-PASS-SIG：媒体安全密钥管理协议必须具有一种模式，在该模式下，它可以防止访问信令路径的被动对手访问用于保护SRTP媒体数据包的密钥材料。
R-SIG-MEDIA: The media security key management protocol MUST have a mode in which it defends itself from an attacker that is solely on the media path and from an attacker that is solely on the signaling path. A successful attack refers to the ability for the adversary to obtain keying material to decrypt the SRTP encrypted media traffic.
R-SIG-MEDIA：媒体安全密钥管理协议必须具有一种模式，在该模式下，它可以防御仅位于媒体路径上的攻击者和仅位于信令路径上的攻击者。成功的攻击是指对手能够获得密钥材料以解密SRTP加密的媒体流量。
R-ID-BINDING: The media security key management protocol MUST enable the media security keys to be cryptographically bound to an identity of the endpoint.
R-ID-BINDING：媒体安全密钥管理协议必须允许媒体安全密钥以加密方式绑定到端点的标识。
Note: This allows domains to deploy SIP Identity [RFC4474].
注意：这允许域部署SIP标识[RFC4474]。
R-ACT-ACT: The media security key management protocol MUST support a mode of operation that provides active-signaling-active-media-detect robustness, and MAY support modes of operation that provide lower levels of robustness (as described in Section 3).
R-ACT-ACT：媒体安全密钥管理协议必须支持提供主动信令的操作模式主动媒体检测鲁棒性，并可支持提供较低鲁棒性水平的操作模式（如第3节所述）。
Note: Failing to meet R-ACT-ACT indicates the protocol cannot provide secure end-to-end media.
注意：未能满足R-ACT-ACT表示协议无法提供安全的端到端介质。
The requirements in this section are for an overall VoIP security system. These requirements can be met within the key management protocol itself, or can be solved outside of the key management protocol itself (e.g., solved in SIP or in SDP).
本节中的要求适用于整个VoIP安全系统。这些要求可以在密钥管理协议本身内得到满足，也可以在密钥管理协议本身之外得到解决（例如，在SIP或SDP中得到解决）。
R-BEST-SECURE: Even when some endpoints of a forked or retargeted call are incapable of using SRTP, a solution MUST be described that allows the establishment of SRTP associations with SRTP-capable endpoints and/or RTP associations with non-SRTP-capable endpoints.
R-BEST-SECURE：即使分支或重定目标调用的某些端点无法使用SRTP，也必须描述一种解决方案，允许与支持SRTP的端点建立SRTP关联和/或与不支持SRTP的端点建立RTP关联。
R-OTHER-SIGNALING: A solution SHOULD be able to negotiate keys for SRTP sessions created via different call signaling protocols (e.g., between Jabber, SIP, H.323, Media Gateway Control Protocol (MGCP).
R-其他-信令：解决方案应能够协商通过不同呼叫信令协议（例如，Jabber、SIP、H.323、媒体网关控制协议（MGCP））创建的SRTP会话的密钥。
R-RECORDING: A solution SHOULD be described that supports recording of decrypted media. This requirement comes from Section 4.3.
R-RECORDING：应该描述一种支持记录解密媒体的解决方案。该要求来自第4.3节。
R-TRANSCODER: A solution SHOULD be described that supports intermediate nodes (e.g., transcoders), terminating or processing media, between the endpoints.
R-转码器：应描述一种支持端点之间的中间节点（例如转码器）、终止或处理媒体的解决方案。
R-ALLOW-RTP: A solution SHOULD be described that allows RTP media to be received by the calling party until SRTP has been negotiated with the answerer, after which SRTP is preferred over RTP.
R-ALLOW-RTP：应该描述一种解决方案，允许呼叫方接收RTP介质，直到与应答方协商SRTP，之后SRTP优先于RTP。
This document lists requirements for securing media traffic. As such, it addresses security throughout the document.
本文档列出了保护媒体流量的要求。因此，它解决了整个文档中的安全问题。
For contributions to the requirements portion of this document, the authors would like to thank the active participants of the RTPSEC BoF and on the RTPSEC mailing list, and a special thanks to Steffen Fries and Dragan Ignjatic for their excellent MIKEY comparison [RFC5197] document.
对于本文件要求部分的贡献，作者要感谢RTPSEC BoF和RTPSEC邮件列表中的积极参与者，并特别感谢Steffen Fries和Dragan Ignjatic出色的MIKEY比较[RFC5197]文件。
The authors would furthermore like to thank the following people for their review, suggestions, and comments: Flemming Andreasen, Richard Barnes, Mark Baugher, Wolfgang Buecker, Werner Dittmann, Lakshminath Dondeti, John Elwell, Martin Euchner, Hans-Heinrich Grusdt, Christer Holmberg, Guenther Horn, Peter Howard, Leo Huang, Dragan Ignjatic, Cullen Jennings, Alan Johnston, Vesa Lehtovirta, Matt Lepinski, David McGrew, David Oran, Colin Perkins, Eric Raymond, Eric Rescorla, Peter Schneider, Frank Shearar, Srinath Thiruvengadam, Dave Ward, Dan York, and Phil Zimmermann.
作者还想感谢以下人士的评论、建议和评论：弗莱明·安德里森、理查德·巴恩斯、马克·鲍格尔、沃尔夫冈·布克、沃纳·迪特曼、拉克希米纳·唐德蒂、约翰·埃尔威尔、马丁·欧希纳、汉斯·海因里希·格鲁斯德、克里斯特·霍姆伯格、根瑟·霍恩、彼得·霍华德、里奥·黄、德拉根·伊格纳蒂克、，卡伦·詹宁斯、艾伦·约翰斯顿、维萨·莱赫托维塔、马特·莱宾斯基、大卫·麦克格鲁、大卫·奥兰、科林·帕金斯、埃里克·雷蒙德、埃里克·瑞斯科拉、彼得·施耐德、弗兰克·希拉尔、斯里纳特·蒂鲁文亚当、戴夫·沃德、丹·约克和菲尔·齐默尔曼。
[FIPS-140-2] NIST, "Security Requirements for Cryptographic Modules", June 2005, <http://csrc.nist.gov/ publications/fips/fips140-2/fips1402.pdf>.
[FIPS-140-2]NIST，“加密模块的安全要求”，2005年6月<http://csrc.nist.gov/ 出版物/fips/fips140-2/fips1402.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 32622，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[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月。
[AISITSEC] Bundesamt fuer Sicherheit in der Informationstechnik [Federal Office of Information Security - Germany], "Anwendungshinweise und Interpretationen (AIS) zu ITSEC", January 2002, <http://www.bsi.de/zertifiz/zert/interpr/ aisitsec.htm>.
[AISITSEC]德国联邦信息技术局[Federal Office of Information Security-Germany]，“信息安全与解释”（AIS）委员会，2002年1月<http://www.bsi.de/zertifiz/zert/interpr/ aisitec.htm>。
[DTLS-SRTP] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", Work in Progress, October 2008.
[DTLS-SRTP]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全性（DTLS）扩展”，正在进行的工作，2008年10月。
[EARLY-MEDIA] Stucker, B., "Coping with Early Media in the Session Initiation Protocol (SIP)", Work in Progress, October 2006.
[早期媒体]Stucker，B.，“在会话启动协议（SIP）中应对早期媒体”，正在进行的工作，2006年10月。
[EKT] McGrew, D., "Encrypted Key Transport for Secure RTP", Work in Progress, July 2007.
[EKT]McGrew，D.，“安全RTP的加密密钥传输”，正在进行的工作，2007年7月。
[H.248.1] ITU, "Gateway control protocol", Recommendation H.248, June 2000, <http://www.itu.int/rec/T-REC-H.248/e>.
[H.248.1]国际电联，“网关控制协议”，建议H.248，2000年6月<http://www.itu.int/rec/T-REC-H.248/e>.
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[ICE]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，正在进行的工作，2007年10月。
[MIDDLEBOX] Stucker, B. and H. Tschofenig, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, July 2008.
[MIDDLEBOX]Stucker，B.和H.Tschofenig，“媒体路径上信令协议通信的中间盒交互分析”，正在进行的工作，2008年7月。
[MIKEY-ECC] Milne, A., "ECC Algorithms for MIKEY", Work in Progress, June 2007.
[MIKEY-ECC]Milne，A.，“MIKEY的ECC算法”，正在进行的工作，2007年6月。
[MIKEYv2] Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY, revisited", Work in Progress, March 2007.
[MIKEYv2]Dondeti，L.，“MIKEYv2：使用MIKEY的SRTP密钥管理，再次访问”，正在进行的工作，2007年3月。
[MULTIPART] Wing, D. and C. Jennings, "Session Initiation Protocol (SIP) Offer/Answer with Multipart Alternative", Work in Progress, March 2006.
[多部分]Wing，D.和C.Jennings，“会话启动协议（SIP）提供/回答多部分备选方案”，正在进行的工作，2006年3月。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[RFC3326]Schulzrinne，H.，Oran，D.，和G.Camarillo，“会话启动协议（SIP）的原因头字段”，RFC 3326，2002年12月。
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
[RFC3372]Vemuri，A.和J.Peterson，“电话会话启动协议（SIP-T）：上下文和体系结构”，BCP 63，RFC 3372，2002年9月。
[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月。
[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月。
[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月。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，2006年5月。
[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月。
[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月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916]Elwell，J.，“会话启动协议（SIP）中的连接身份”，RFC 4916，2007年6月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，2007年8月。
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5027, October 2007.
[RFC5027]Andreasen，F.和D.Wing，“会话描述协议（SDP）媒体流的安全先决条件”，RFC 5027，2007年10月。
[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月。
[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月。
[SDP-CAP] Andreasen, F., "SDP Capability Negotiation", Work in Progress, July 2008.
[SDP-CAP]Andreasen，F.，“SDP能力谈判”，正在进行的工作，2008年7月。
[SDP-DH] Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for Multimedia Sessions", Work in Progress, February 2006.
[SDP-DH]Baugher，M.和D.McGrew，“Diffie-Hellman多媒体会话交换”，进展中的工作，2006年2月。
[SIP-CERTS] Jennings, C. and J. Fischl, "Certificate Management Service for The Session Initiation Protocol (SIP)", Work in Progress, November 2008.
[SIP-CERTS]Jennings，C.和J.Fischl，“会话启动协议（SIP）的证书管理服务”，正在进行的工作，2008年11月。
[SIP-DTLS] Fischl, J., "Datagram Transport Layer Security (DTLS) Protocol for Protection of Media Traffic Established with the Session Initiation Protocol", Work in Progress, July 2007.
[SIP-DTLS]Fischl，J.，“使用会话启动协议建立的用于保护媒体流量的数据报传输层安全（DTLS）协议”，正在进行的工作，2007年7月。
[SRTP-KEY] Wing, D., Audet, F., Fries, S., Tschofenig, H., and A. Johnston, "Secure Media Recording and Transcoding with the Session Initiation Protocol", Work in Progress, October 2008.
[SRTP-KEY]Wing，D.，Audet，F.，Fries，S.，Tschofenig，H.，和A.Johnston，“使用会话启动协议的安全媒体录制和转码”，正在进行的工作，2008年10月。
[ZRTP] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, February 2009.
[ZRTP]Zimmermann，P.，Johnston，A.，和J.Callas，“ZRTP：安全RTP的媒体路径密钥协议”，正在进行的工作，2009年2月。
Based on how the SRTP keys are exchanged, each SRTP key exchange mechanism belongs to one general category:
根据SRTP密钥的交换方式，每个SRTP密钥交换机制属于一个一般类别：
signaling path: All the keying is carried in the call signaling (SIP or SDP) path.
信令路径：所有键控都在呼叫信令（SIP或SDP）路径中进行。
media path: All the keying is carried in the SRTP/SRTCP media path, and no signaling whatsoever is carried in the call signaling path.
媒体路径：所有键控都在SRTP/SRTCP媒体路径中进行，呼叫信令路径中不进行任何信令。
signaling and media path: Parts of the keying are carried in the SRTP/SRTCP media path, and parts are carried in the call signaling (SIP or SDP) path.
信令和媒体路径：部分键控在SRTP/SRTCP媒体路径中进行，部分键控在呼叫信令（SIP或SDP）路径中进行。
One of the significant benefits of SRTP over other end-to-end encryption mechanisms, such as for example IPsec, is that SRTP is bandwidth efficient and SRTP retains the header of RTP packets. Bandwidth efficiency is vital for VoIP in many scenarios where access bandwidth is limited or expensive, and retaining the RTP header is important for troubleshooting packet loss, delay, and jitter.
与其他端到端加密机制（例如IPsec）相比，SRTP的一个显著优点是SRTP具有带宽效率，并且SRTP保留RTP数据包的报头。在许多接入带宽有限或昂贵的场景中，带宽效率对VoIP至关重要，保留RTP报头对于排除数据包丢失、延迟和抖动故障非常重要。
Related to SRTP's characteristics is a goal that any SRTP keying mechanism to also be efficient and not cause additional call setup delay. Contributors to additional call setup delay include network or database operations: retrieval of certificates and additional SIP or media path messages, and computational overhead of establishing keys or validating certificates.
与SRTP的特性相关的一个目标是，任何SRTP键控机制也要有效，并且不会导致额外的呼叫设置延迟。造成额外呼叫设置延迟的因素包括网络或数据库操作：检索证书和额外的SIP或媒体路径消息，以及建立密钥或验证证书的计算开销。
When examining the choice between keying in the signaling path, keying in the media path, or keying in both paths, it is important to realize the media path is generally "faster" than the SIP signaling path. The SIP signaling path has computational elements involved that parse and route SIP messages. The media path, on the other hand, does not normally have computational elements involved, and even when computational elements such as firewalls are involved, they cause very little additional delay. Thus, the media path can be useful for exchanging several messages to establish SRTP keys. A disadvantage of keying over the media path is that interworking different key exchange requires the interworking function be in the media path, rather than just in the signaling path; in practice, this involvement is probably unavoidable anyway.
在检查信令路径中的键控、媒体路径中的键控或两条路径中的键控之间的选择时，重要的是要认识到媒体路径通常比SIP信令路径“更快”。SIP信令路径包含解析和路由SIP消息的计算元素。另一方面，媒体路径通常不涉及计算元素，即使涉及诸如防火墙之类的计算元素，它们也几乎不会造成额外的延迟。因此，媒体路径可用于交换多个消息以建立SRTP密钥。通过媒体路径进行键控的缺点是，不同密钥交换的互通要求互通功能在媒体路径中，而不仅仅在信令路径中；在实践中，这种参与可能无论如何都是不可避免的。
MIKEY-NULL [RFC3830] has the offerer indicate the SRTP keys for both directions. The key is sent unencrypted in SDP, which means the SDP must be encrypted hop-by-hop (e.g., by using TLS (SIPS)) or end-to-end (e.g., by using Secure/Multipurpose Internet Mail Extensions (S/MIME)).
MIKEY-NULL[RFC3830]让报价人指示两个方向的SRTP键。密钥在SDP中未加密发送，这意味着SDP必须逐跳加密（例如，使用TLS（SIPS））或端到端加密（例如，使用安全/多用途Internet邮件扩展（S/MIME））。
MIKEY-NULL requires one message from offerer to answerer (half a round trip), and does not add additional media path messages.
MIKEY-NULL需要从报价人到应答人发送一条消息（半个往返），并且不添加额外的媒体路径消息。
MIKEY-PSK (pre-shared key) [RFC3830] requires that all endpoints share one common key. MIKEY-PSK has the offerer encrypt the SRTP keys for both directions using this pre-shared key.
MIKEY-PSK（预共享密钥）[RFC3830]要求所有端点共享一个公共密钥。MIKEY-PSK让报价人使用该预共享密钥加密双向SRTP密钥。
MIKEY-PSK requires one message from offerer to answerer (half a round trip), and does not add additional media path messages.
MIKEY-PSK要求发盘人向应答人发送一条消息（半往返），并且不添加额外的媒体路径消息。
MIKEY-RSA [RFC3830] has the offerer encrypt the keys for both directions using the intended answerer's public key, which is obtained from a mechanism outside of MIKEY.
MIKEY-RSA[RFC3830]让报价人使用从MIKEY之外的机制获得的预期应答人公钥对双向密钥进行加密。
MIKEY-RSA requires one message from offerer to answerer (half a round trip), and does not add additional media path messages. MIKEY-RSA requires the offerer to obtain the intended answerer's certificate.
MIKEY-RSA要求报价人向应答人发送一条消息（半往返），并且不添加额外的媒体路径消息。MIKEY-RSA要求报价人获得预期应答人的证书。
MIKEY-RSA-R [RFC4738] is essentially the same as MIKEY-RSA but reverses the role of the offerer and the answerer with regards to providing the keys. That is, the answerer encrypts the keys for both directions using the offerer's public key. Both the offerer and answerer validate each other's public keys using a standard X.509 validation techniques. MIKEY-RSA-R also enables sending certificates in the MIKEY message.
MIKEY-RSA-R[RFC4738]本质上与MIKEY-RSA相同，但在提供密钥方面颠倒了报价人和应答人的角色。也就是说，应答者使用提供者的公钥对两个方向的密钥进行加密。报价人和应答人都使用标准的X.509验证技术验证对方的公钥。MIKEY-RSA-R还支持在MIKEY消息中发送证书。
MIKEY-RSA-R requires one message from offerer to answer, and one message from answerer to offerer (full round trip), and does not add additional media path messages. MIKEY-RSA-R requires the offerer validate the answerer's certificate.
MIKEY-RSA-R要求发盘方发送一条消息进行应答，发盘方发送一条消息（全程往返），并且不添加额外的媒体路径消息。MIKEY-RSA-R要求报价人验证应答人的证书。
In MIKEY-DHSIGN [RFC3830], the offerer and answerer derive the key from a Diffie-Hellman (DH) exchange. In order to prevent an active man-in-the-middle, the DH exchange itself is signed using each endpoint's private key and the associated public keys are validated using standard X.509 validation techniques.
在MIKEY-DHSIGN[RFC3830]中，发盘方和应答方从Diffie-Hellman（DH）交换中获得密钥。为了防止中间有活跃的人，DH exchange本身使用每个端点的私钥进行签名，并使用标准的X.509验证技术验证相关的公钥。
MIKEY-DHSIGN requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages. MIKEY-DHSIGN requires the offerer and answerer to validate each other's certificates. MIKEY-DHSIGN also enables sending the answerer's certificate in the MIKEY message.
MIKEY-DHSIGN要求发信人向发信人发送一条信息，发信人向发信人发送一条信息（全程往返），并且不添加额外的媒体路径信息。MIKEY-DHSIGN要求报价人和应答人验证对方的证书。MIKEY-DHSIGN还允许在MIKEY消息中发送应答者的证书。
MIKEY-DHHMAC [RFC4650] uses a pre-shared secret to HMAC the Diffie-Hellman exchange, essentially combining aspects of MIKEY-PSK with MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for certificate authentication.
MIKEY-DHHMAC[RFC4650]使用预先共享的秘密对HMAC进行Diffie-Hellman交换，基本上结合了MIKEY-PSK和MIKEY-DHSIGN的各个方面，但不需要MIKEY-DHSIGN进行证书身份验证。
MIKEY-DHHMAC requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages.
MIKEY-DHHMAC要求发信人向发信人发送一条信息，发信人向发信人发送一条信息（全程往返），并且不添加额外的媒体路径信息。
ECC Algorithms For MIKEY [MIKEY-ECC] describes how ECC can be used with MIKEY-RSA (using Elliptic Curve Digital Signature Algorithm (ECDSA) signature) and with MIKEY-DHSIGN (using a new DH-Group code), and also defines two new ECC-based algorithms, Elliptic Curve Integrated Encryption Scheme (ECIES) and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) .
MIKEY的ECC算法[MIKEY-ECC]描述了ECC如何与MIKEY-RSA（使用椭圆曲线数字签名算法（ECDSA）签名）和MIKEY-DHSIGN（使用新的DH组码）一起使用，并定义了两种新的基于ECC的算法，椭圆曲线集成加密方案（ECIES）和椭圆曲线Menezes Qu Vanstone（ECMQV）。
With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV function exactly like MIKEY-RSA, and the new DH-Group code function exactly like MIKEY-DHSIGN. Therefore, these ECC mechanisms are not discussed separately in this document.
根据该方案，ECDSA签名、MIKEY-ECIES和MIKEY-ECMQV的功能与MIKEY-RSA完全相同，而新的DH组码的功能与MIKEY-DHSIGN完全相同。因此，本文件不单独讨论这些ECC机制。
SDP Security Descriptions [RFC4568] have each side indicate the key they will use for transmitting SRTP media, and the keys are sent in the clear in SDP. SDP Security Descriptions rely on hop-by-hop (TLS via "SIPS:") encryption to protect the keys exchanged in signaling.
SDP安全说明[RFC4568]中的每一方都说明了他们将用于传输SRTP媒体的密钥，并且这些密钥在SDP中以明文形式发送。SDP安全描述依靠逐跳（TLS通过“SIPS:”）加密来保护信令中交换的密钥。
SDP Security Descriptions requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages.
SDP安全性描述要求提供方向应答方发送一条消息，应答方向提供方发送一条消息（完整往返），并且不添加额外的媒体路径消息。
This keying mechanism is identical to Appendix A.1.8 except that, rather than protecting the signaling with TLS, the entire SDP is encrypted with S/MIME.
该键控机制与附录A.1.8相同，不同之处在于，不是使用TLS保护信令，而是使用S/MIME对整个SDP进行加密。
SDP Diffie-Hellman [SDP-DH] exchanges Diffie-Hellman messages in the signaling path to establish session keys. To protect against active man-in-the-middle attacks, the Diffie-Hellman exchange needs to be protected with S/MIME, SIPS, or SIP Identity [RFC4474] and SIP Connected Identity [RFC4916].
SDP Diffie-Hellman[SDP-DH]在信令路径中交换Diffie-Hellman消息以建立会话密钥。为了防止主动中间人攻击，Diffie-Hellman交换需要使用S/MIME、SIPS或SIP标识[RFC4474]和SIP连接标识[RFC4916]进行保护。
SDP-DH requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages.
SDP-DH需要从发盘方到应答方的一条消息，以及从应答方到发盘方的一条消息（完整往返），并且不添加额外的媒体路径消息。
MIKEYv2 [MIKEYv2] adds mode negotiation to MIKEYv1 and removes the time synchronization requirement. It therefore now takes 2 round trips to complete. In the first round trip, the communicating parties learn each other's identities, agree on a MIKEY mode, crypto algorithm, SRTP policy, and exchanges nonces for replay protection. In the second round trip, they negotiate unicast and/or group SRTP context for SRTP and/or SRTCP.
MIKEYv2[MIKEYv2]将模式协商添加到MIKEYv1并删除时间同步要求。因此，现在需要2次往返才能完成。在第一次往返过程中，通信双方了解彼此的身份，就MIKEY模式、加密算法、SRTP策略达成一致，并交换nonce以进行重播保护。在第二次往返中，他们为SRTP和/或SRTCP协商单播和/或组SRTP上下文。
Furthermore, MIKEYv2 also defines an in-band negotiation mode as an alternative to SDP (see Appendix A.3.3).
此外，MIKEYv2还将带内协商模式定义为SDP的替代方案（见附录A.3.3）。
ZRTP [ZRTP] does not exchange information in the signaling path (although it's possible for endpoints to exchange a hash of the ZRTP Hello message with "a=zrtp-hash" in the initial offer if sent over an integrity-protected signaling channel. This provides some useful correlation between the signaling and media layers). In ZRTP, the keys are exchanged entirely in the media path using a Diffie-Hellman exchange. The advantage to this mechanism is that the signaling channel is used only for call setup and the media channel is used to establish an encrypted channel -- much like encryption devices on the
ZRTP[ZRTP]不交换信令路径中的信息（尽管如果通过完整性保护的信令通道发送，端点可以将ZRTP Hello消息的散列与初始报价中的“a=ZRTP散列”交换。这在信令层和媒体层之间提供了一些有用的关联）。在ZRTP中，使用Diffie-Hellman交换在媒体路径中完全交换密钥。这种机制的优点是，信令通道仅用于呼叫设置，而媒体通道用于建立加密通道——与网络上的加密设备非常相似
PSTN. ZRTP uses voice authentication of its Diffie-Hellman exchange by having each person read digits or words to the other person. Subsequent sessions with the same ZRTP endpoint can be authenticated using the stored hash of the previously negotiated key rather than voice authentication. ZRTP uses four media path messages (Hello, Commit, DHPart1, and DHPart2) to establish the SRTP key, and three media path confirmation messages. These initial messages are all sent as non-RTP packets.
公共电话网。ZRTP使用Diffie-Hellman交换的语音认证，让每个人向另一个人读取数字或单词。具有相同ZRTP端点的后续会话可以使用先前协商的密钥的存储哈希而不是语音身份验证进行身份验证。ZRTP使用四条媒体路径消息（Hello、Commit、DHPart1和DHPart2）来建立SRTP密钥，以及三条媒体路径确认消息。这些初始消息都作为非RTP数据包发送。
Note: that when ZRTP probing is used, unencrypted RTP can be exchanged until the SRTP keys are established.
注意：当使用ZRTP探测时，可以交换未加密的RTP，直到建立SRTP密钥。
EKT [EKT] relies on another SRTP key exchange protocol, such as SDP Security Descriptions or MIKEY, for bootstrapping. In the initial phase, each member of a conference uses an SRTP key exchange protocol to establish a common key encryption key (KEK). Each member may use the KEK to securely transport its SRTP master key and current SRTP rollover counter (ROC), via RTCP, to the other participants in the session.
EKT[EKT]依赖另一个SRTP密钥交换协议（如SDP安全描述或MIKEY）进行引导。在初始阶段，会议的每个成员使用SRTP密钥交换协议来建立公共密钥加密密钥（KEK）。每个成员都可以使用KEK通过RTCP将其SRTP主密钥和当前SRTP滚动计数器（ROC）安全地传输给会话中的其他参与者。
EKT requires the offerer to send some parameters (EKT_Cipher, KEK, and security parameter index (SPI)) via the bootstrapping protocol such as SDP Security Descriptions or MIKEY. Each answerer sends an SRTCP message that contains the answerer's SRTP Master Key, rollover counter, and the SRTP sequence number. Rekeying is done by sending a new SRTCP message. For reliable transport, multiple RTCP messages need to be sent.
EKT要求报价人通过自举协议（如SDP安全描述或MIKEY）发送一些参数（EKT_密码、KEK和安全参数索引（SPI））。每个应答者发送一条SRTCP消息，其中包含应答者的SRTP主密钥、翻转计数器和SRTP序列号。通过发送新的SRTCP消息来完成密钥更新。为了可靠传输，需要发送多个RTCP消息。
DTLS-SRTP [DTLS-SRTP] exchanges public key fingerprints in SDP [SIP-DTLS] and then establishes a DTLS session over the media channel. The endpoints use the DTLS handshake to agree on crypto suites and establish SRTP session keys. SRTP packets are then exchanged between the endpoints.
DTLS-SRTP[DTLS-SRTP]在SDP[SIP-DTLS]中交换公钥指纹，然后通过媒体通道建立DTLS会话。端点使用DTLS握手来商定加密套件并建立SRTP会话密钥。然后在端点之间交换SRTP数据包。
DTLS-SRTP requires one message from offerer to answerer (half round trip), and one message from the answerer to offerer (full round trip) so the offerer can correlate the SDP answer with the answering endpoint. DTLS-SRTP uses four media path messages to establish the SRTP key.
DTLS-SRTP要求发信人向发信人发送一条消息（半往返），发信人向发信人发送一条消息（全往返），以便发信人能够将SDP应答与应答端点相关联。DTLS-SRTP使用四条媒体路径消息来建立SRTP密钥。
This document assumes DTLS will use TLS_RSA_WITH_AES_128_CBC_SHA as its cipher suite, which is the mandatory-to-implement cipher suite in TLS [RFC5246].
本文档假设DTLS将使用TLS_RSA_和_AES_128_CBC_SHA作为其密码套件，这是在TLS[RFC5246]中实现密码套件的强制性要求。
As defined in Appendix A.1.11, MIKEYv2 also defines an in-band negotiation mode as an alternative to SDP (see Appendix A.3.3). The details are not sorted out in the document yet on what in-band actually means (i.e., UDP, RTP, RTCP, etc.).
如附录A.1.11所述，MIKEYv2还将带内协商模式定义为SDP的替代方案（见附录A.3.3）。文档中尚未对带内实际含义（即UDP、RTP、RTCP等）进行详细分类。
This section considers how each keying mechanism interacts with SIP features.
本节讨论每个键控机制如何与SIP功能交互。
Retargeting and forking of signaling requests is described within Section 4.2. The following builds upon this description.
第4.2节描述了信令请求的重定目标和分叉。以下内容基于此描述。
The following list compares the behavior of secure forking, answering association, two-time pads, and secure retargeting for each keying mechanism.
下表比较了每个键控机制的安全分叉、应答关联、两个时间键盘和安全重定目标的行为。
MIKEY-NULL Secure Forking: No, all AORs see offerer's and answerer's keys. Answer is associated with media by the SSRC in MIKEY. Additionally, a two-time pad occurs if two branches choose the same 32-bit SSRC and transmit SRTP packets.
MIKEY-NULL安全分叉：不，所有AOR都能看到报价人和应答人的钥匙。答案与媒体有关，由米奇的SSRC提供。此外，如果两个分支选择相同的32位SSRC并传输SRTP数据包，则会发生两次pad。
Secure Retargeting: No, all targets see offerer's and answerer's keys. Suffers from retargeting identity problem.
安全重定目标：不，所有目标都能看到报价人和应答人的钥匙。遇到重定目标身份问题。
MIKEY-PSK Secure Forking: No, all AORs see offerer's and answerer's keys. Answer is associated with media by the SSRC in MIKEY. Note that all AORs must share the same pre-shared key in order for forking to work at all with MIKEY-PSK. Additionally, a two-time pad occurs if two branches choose the same 32-bit SSRC and transmit SRTP packets.
MIKEY-PSK安全分叉：不，所有AOR都能看到报价人和应答人的钥匙。答案与媒体有关，由米奇的SSRC提供。请注意，所有AOR必须共享相同的预共享密钥，以便分叉与MIKEY-PSK一起工作。此外，如果两个分支选择相同的32位SSRC并传输SRTP数据包，则会发生两次pad。
Secure Retargeting: Not secure. For retargeting to work, the final target must possess the correct PSK. As this is likely in scenarios where the call is targeted to another device belonging to the same user (forking), it is very unlikely that other users will possess that PSK and be able to successfully answer that call.
安全重定目标：不安全。要使重定目标有效，最终目标必须具有正确的PSK。由于这在呼叫针对属于同一用户的另一设备（分叉）的情况下很可能发生，因此其他用户不太可能拥有该PSK并能够成功应答该呼叫。
MIKEY-RSA Secure Forking: No, all AORs see offerer's and answerer's keys. Answer is associated with media by the SSRC in MIKEY. Note that all AORs must share the same private key in order for forking to work at all with MIKEY-RSA. Additionally, a two-time pad occurs if two branches choose the same 32-bit SSRC and transmit SRTP packets.
MIKEY-RSA安全分叉：不，所有AOR都能看到报价人和应答人的钥匙。答案与媒体有关，由米奇的SSRC提供。请注意，所有AOR必须共享相同的私钥，以便分叉与MIKEY-RSA一起工作。此外，如果两个分支选择相同的32位SSRC并传输SRTP数据包，则会发生两次pad。
Secure Retargeting: No.
安全重定目标：否。
MIKEY-RSA-R Secure Forking: Yes, answer is associated with media by the SSRC in MIKEY.
MIKEY-RSA-R安全分叉：是的，答案与MIKEY中SSRC的媒体相关。
Secure Retargeting: Yes.
安全重定目标：是。
MIKEY-DHSIGN Secure Forking: Yes, each forked endpoint negotiates unique keys with the offerer for both directions. Answer is associated with media by the SSRC in MIKEY.
MIKEY-DHSIGN安全分叉：是的，每个分叉端点都与报价人协商双向的唯一密钥。答案与媒体有关，由米奇的SSRC提供。
Secure Retargeting: Yes, each target negotiates unique keys with the offerer for both directions.
安全重定目标：是的，每个目标在两个方向上与报价人协商唯一密钥。
MIKEYv2 in SDP The behavior will depend on which mode is picked.
SDP中的MIKEYv2行为将取决于选择的模式。
MIKEY-DHHMAC Secure Forking: Yes, each forked endpoint negotiates unique keys with the offerer for both directions. Answer is associated with media by the SSRC in MIKEY.
MIKEY-DHHMAC安全分叉：是的，每个分叉端点都与报价人协商两个方向的唯一密钥。答案与媒体有关，由米奇的SSRC提供。
Secure Retargeting: Yes, each target negotiates unique keys with the offerer for both directions. Note that for the keys to be meaningful, it would require the PSK to be the same for all the potential intermediaries, which would only happen within a single domain.
安全重定目标：是的，每个目标在两个方向上与报价人协商唯一密钥。请注意，为了使密钥有意义，它将要求所有潜在中介的PSK相同，这只会发生在单个域中。
SDP Security Descriptions with SIPS Secure Forking: No, each forked endpoint sees the offerer's key. Answer is not associated with media.
带有SIPS安全分叉的SDP安全描述：不，每个分叉端点都可以看到报价人的密钥。答案与媒体无关。
Secure Retargeting: No, each target sees the offerer's key.
安全重定目标：不，每个目标都能看到报价人的钥匙。
SDP Security Descriptions with S/MIME Secure Forking: No, each forked endpoint sees the offerer's key. Answer is not associated with media.
带有S/MIME安全分叉的SDP安全描述：不，每个分叉端点都可以看到报价人的密钥。答案与媒体无关。
Secure Retargeting: No, each target sees the offerer's key. Suffers from retargeting identity problem.
安全重定目标：不，每个目标都能看到报价人的钥匙。遇到重定目标身份问题。
SDP-DH Secure Forking: Yes, each forked endpoint calculates a unique SRTP key. Answer is not associated with media.
SDP-DH安全分叉：是的，每个分叉端点计算一个唯一的SRTP密钥。答案与媒体无关。
Secure Retargeting: Yes, the final target calculates a unique SRTP key.
安全重定目标：是的，最终目标计算唯一的SRTP密钥。
ZRTP Secure Forking: Yes, each forked endpoint calculates a unique SRTP key. With the "a=zrtp-hash" attribute, the media can be associated with an answer.
ZRTP安全分叉：是的，每个分叉端点计算一个唯一的SRTP密钥。通过“a=zrtp哈希”属性，媒体可以与应答关联。
Secure Retargeting: Yes, the final target calculates a unique SRTP key.
安全重定目标：是的，最终目标计算唯一的SRTP密钥。
EKT Secure Forking: Inherited from the bootstrapping mechanism (the specific MIKEY mode or SDP Security Descriptions). Answer is associated with media by the SPI in the EKT protocol. Answer is associated with media by the SPI in the EKT protocol.
EKT安全分叉：继承自引导机制（特定的MIKEY模式或SDP安全描述）。应答通过EKT协议中的SPI与媒体相关联。应答通过EKT协议中的SPI与媒体相关联。
Secure Retargeting: Inherited from the bootstrapping mechanism (the specific MIKEY mode or SDP Security Descriptions).
安全重定目标：继承自引导机制（特定的MIKEY模式或SDP安全描述）。
DTLS-SRTP Secure Forking: Yes, each forked endpoint calculates a unique SRTP key. Answer is associated with media by the certificate fingerprint in signaling and certificate in the media path.
DTLS-SRTP安全分叉：是的，每个分叉端点计算一个唯一的SRTP密钥。应答通过信令中的证书指纹和媒体路径中的证书与媒体相关联。
Secure Retargeting: Yes, the final target calculates a unique SRTP key.
安全重定目标：是的，最终目标计算唯一的SRTP密钥。
MIKEYv2 Inband The behavior will depend on which mode is picked.
MIKEYv2带内行为将取决于选择的模式。
Clipping media before receiving the signaling answer is described within Section 4.1. The following builds upon this description.
第4.1节描述了在接收信号应答之前剪切媒体。以下内容基于此描述。
Furthermore, the problem of clipping gets compounded when forking is used. For example, if using a Diffie-Hellman keying technique with security preconditions that forks to 20 endpoints, the call initiator would get 20 provisional responses containing 20 signed Diffie-Hellman half keys. Calculating 20 DH secrets and validating
此外，使用分叉时，剪裁问题变得更加复杂。例如，如果使用Diffie-Hellman键控技术和安全先决条件，将分支到20个端点，则调用发起方将得到20个临时响应，其中包含20个签名的Diffie-Hellman半键。计算20个DH秘密并验证
signatures can be a difficult task depending on the device capabilities.
根据设备功能的不同，签名可能是一项困难的任务。
The following list compares the behavior of clipping before SDP answer for each keying mechanism.
下面的列表比较了每个键控机制在SDP应答之前的剪切行为。
MIKEY-NULL Not clipped. The offerer provides the answerer's keys.
MIKEY-NULL未被剪裁。报价人提供应答人的钥匙。
MIKEY-PSK Not clipped. The offerer provides the answerer's keys.
MIKEY-PSK没有被剪掉。报价人提供应答人的钥匙。
MIKEY-RSA Not clipped. The offerer provides the answerer's keys.
MIKEY-RSA没有剪掉。报价人提供应答人的钥匙。
MIKEY-RSA-R Clipped. The answer contains the answerer's encryption key.
MIKEY-RSA-R被剪掉了。答案包含回答者的加密密钥。
MIKEY-DHSIGN Clipped. The answer contains the answerer's Diffie-Hellman response.
米奇-迪恩的标志被剪掉了。答案包含回答者的Diffie Hellman回答。
MIKEY-DHHMAC Clipped. The answer contains the answerer's Diffie-Hellman response.
米奇-迪哈迈克剪了。答案包含回答者的Diffie Hellman回答。
MIKEYv2 in SDP The behavior will depend on which mode is picked.
SDP中的MIKEYv2行为将取决于选择的模式。
SDP Security Descriptions with SIPS Clipped. The answer contains the answerer's encryption key.
已剪裁SIP的SDP安全说明。答案包含回答者的加密密钥。
SDP Security Descriptions with S/MIME Clipped. The answer contains the answerer's encryption key.
S/MIME裁剪的SDP安全性描述。答案包含回答者的加密密钥。
SDP-DH Clipped. The answer contains the answerer's Diffie-Hellman response.
SDP-DH被剪掉了。答案包含回答者的Diffie Hellman回答。
ZRTP Not clipped because the session initially uses RTP. While RTP is flowing, both ends negotiate SRTP keys in the media path and then switch to using SRTP.
ZRTP未被剪裁，因为会话最初使用RTP。当RTP流动时，两端协商媒体路径中的SRTP密钥，然后切换到使用SRTP。
EKT Not clipped, as long as the first RTCP packet (containing the answerer's key) is not lost in transit. The answerer sends its encryption key in RTCP, which arrives at the same time (or before) the first SRTP packet encrypted with that key.
只要第一个RTCP数据包（包含应答者密钥）在传输过程中没有丢失，EKT就不会被剪裁。应答者在RTCP中发送其加密密钥，该密钥与使用该密钥加密的第一个SRTP数据包同时（或之前）到达。
Note: RTCP needs to work, in the answerer-to-offerer direction, before the offerer can decrypt SRTP media.
注：RTCP需要在报价人能够解密SRTP媒体之前按照报价人的指示工作。
DTLS-SRTP No clipping after the DTLS-SRTP handshake has completed. SRTP keys are exchanged in the media path. Need to wait for SDP answer to ensure DTLS-SRTP handshake was done with an authorized party.
DTLS-SRTP握手完成后不进行剪裁。SRTP密钥在媒体路径中交换。需要等待SDP应答，以确保与授权方进行DTLS-SRTP握手。
If a middlebox interferes with the media path, there can be clipping [MIDDLEBOX].
如果中间盒干扰了媒体路径，则可能会出现剪辑[中间盒]。
MIKEYv2 Inband Not clipped. Keys are exchanged in the media path without relying on the signaling path.
MIKEYv2带未修剪。密钥在媒体路径中交换，而不依赖于信令路径。
In SRTP, a cryptographic context is defined as the SSRC, destination network address, and destination transport port number. Whereas RTP, a flow is defined as the destination network address and destination transport port number. This results in a problem -- how to communicate the SSRC so that the SSRC can be used for the cryptographic context.
在SRTP中，加密上下文定义为SSRC、目标网络地址和目标传输端口号。而RTP则将流定义为目标网络地址和目标传输端口号。这导致了一个问题——如何通信SSRC，以便SSRC可以用于加密上下文。
Two approaches have emerged for this communication. One, used by all MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY exchange. Another, used by SDP Security Descriptions, is to apply "late binding" -- that is, any new packet containing a previously unseen SSRC (which arrives at the same destination network address and destination transport port number) will create a new cryptographic context. Another approach, common amongst techniques with media-path SRTP key establishment, is to require a handshake over that media path before SRTP packets are sent. MIKEY's approach changes RTP's SSRC collision detection behavior by requiring RTP to pre-establish the SSRC values for each session.
这种交流出现了两种方法。所有MIKEY模式都使用的一种模式是将SSRC与MIKEY交换中的对等方进行通信。SDP安全描述使用的另一种方法是应用“后期绑定”——也就是说，任何包含以前未看到的SSRC（到达相同的目标网络地址和目标传输端口号）的新数据包都将创建新的加密上下文。另一种方法，在媒体路径SRTP密钥建立技术中常见，是在发送SRTP分组之前要求通过该媒体路径进行握手。MIKEY的方法通过要求RTP为每个会话预先建立SSRC值来改变RTP的SSRC冲突检测行为。
Another related issue is that SRTP introduces a rollover counter (ROC), which records how many times the SRTP sequence number has rolled over. As the sequence number is used for SRTP's default ciphers, it is important that all endpoints know the value of the ROC. The ROC starts at 0 at the beginning of a session.
另一个相关问题是SRTP引入了一个滚动计数器（ROC），它记录SRTP序列号的滚动次数。由于序列号用于SRTP的默认密码，因此所有端点都知道ROC的值非常重要。ROC在会话开始时从0开始。
Some keying mechanisms cause a two-time pad to occur if two endpoints of a forked call have an SSRC collision.
如果分叉调用的两个端点发生SSRC冲突，某些键控机制会导致出现两次键盘。
Note: A proposal has been made to send the ROC value on every Nth SRTP packet[RFC4771]. This proposal has not yet been incorporated into this document.
注：已建议每N个SRTP数据包发送ROC值[RFC4771]。该提案尚未纳入本文件。
The following list examines handling of SSRC and ROC:
以下列表检查SSRC和ROC的处理：
MIKEY-NULL Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEY-NULL每个端点表示一组SSRC及其传输的SRTP数据包的ROC。
MIKEY-PSK Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEY-PSK每个端点表示一组SSRC及其传输的SRTP数据包的ROC。
MIKEY-RSA Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEY-RSA每个端点表示一组SSRC及其传输的SRTP数据包的ROC。
MIKEY-RSA-R Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEY-RSA-R每个端点表示一组SSRC及其传输的SRTP数据包的ROC。
MIKEY-DHSIGN Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEY-DHSIGN每个端点表示一组SSRC及其传输的SRTP数据包的ROC。
MIKEY-DHHMAC Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEY-DHHMAC每个端点表示一组SSRC和它传输的SRTP数据包的ROC。
MIKEYv2 in SDP Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
SDP中的MIKEYv2每个端点表示一组SSRC及其传输的SRTP数据包的ROC。
SDP Security Descriptions with SIPS Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
带有SIP的SDP安全说明SSRC和ROC均未发出信号。使用SSRC“后期绑定”。
SDP Security Descriptions with S/MIME Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
带有S/MIME的SDP安全描述不显示SSRC或ROC。使用SSRC“后期绑定”。
SDP-DH Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
SDP-DH未发出SSRC或ROC信号。使用SSRC“后期绑定”。
ZRTP Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
ZRTP SSRC和ROC均未发出信号。使用SSRC“后期绑定”。
EKT The SSRC of the SRTCP packet containing an EKT update corresponds to the SRTP master key and other parameters within that packet.
EKT包含EKT更新的SRTCP数据包的SSRC对应于该数据包内的SRTP主密钥和其他参数。
DTLS-SRTP Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
DTLS-SRTP未发出SSRC或ROC信号。使用SSRC“后期绑定”。
MIKEYv2 Inband Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEYv2带内每个端点表示一组SSRC及其传输的SRTP数据包的ROC。
This section evaluates each keying mechanism on the basis of their security properties.
本节根据每个键控机制的安全属性对其进行评估。
A.5.1. Distribution and Validation of Persistent Public Keys and Certificates
A.5.1. 持久公钥和证书的分发和验证
Using persistent public keys for confidentiality and authentication can introduce requirements for two types of systems, often implemented using certificates: (1) a system to distribute those persistent public keys certificates, and (2) a system for validating those persistent public keys. We refer to the former as a key distribution system and the latter as an authentication infrastructure. In many cases, a monolithic public key infrastructure (PKI) is used to fulfill both of these roles. However, these functions can be provided by many other systems. For instance, key distribution may be accomplished by any public repository of keys. Any system in which the two endpoints have access to trust anchors and intermediate CA certificates that can be used to validate other endpoints' certificates (including a system of self-signed certificates) can be used to support certificate validation in the below schemes.
使用持久公钥进行机密性和身份验证可能会对两种类型的系统提出要求，通常使用证书实现：（1）分发这些持久公钥证书的系统，以及（2）验证这些持久公钥的系统。我们将前者称为密钥分发系统，将后者称为身份验证基础设施。在许多情况下，使用单一公钥基础设施（PKI）来实现这两个角色。但是，这些功能可以由许多其他系统提供。例如，密钥分发可以由任何公共密钥存储库完成。两个端点可以访问信任锚和中间CA证书（可用于验证其他端点的证书）的任何系统（包括自签名证书系统）都可以用于支持以下方案中的证书验证。
With real-time communications, it is desirable to avoid fetching or validating certificates that delay call setup. Rather, it is preferable to fetch or validate certificates in such a way that call setup is not delayed. For example, a certificate can be validated while the phone is ringing or can be validated while ring-back tones are being played or even while the called party is answering the
对于实时通信，希望避免获取或验证延迟呼叫设置的证书。相反，最好以不延迟调用设置的方式获取或验证证书。例如，可以在手机铃声响起时验证证书，也可以在播放回铃音时验证证书，甚至可以在被叫方接听电话时验证证书
phone and saying "hello". Even better is to avoid fetching or validating persistent public keys at all.
打电话说“你好”。更好的方法是完全避免获取或验证持久公钥。
SRTP key exchange mechanisms that require a particular authentication infrastructure to operate (whether for distribution or validation) are gated on the deployment of a such an infrastructure available to both endpoints. This means that no media security is achievable until such an infrastructure exists. For SIP, something like sip-certs [SIP-CERTS] might be used to obtain the certificate of a peer.
SRTP密钥交换机制需要一个特定的身份验证基础设施来运行（无论是分发还是验证），这些机制在两个端点都可以使用的基础设施的部署上受到限制。这意味着，在这种基础设施存在之前，无法实现媒体安全。对于SIP，可以使用类似SIP证书[SIP-certs]的内容来获取对等方的证书。
Note: Even if sip-certs [SIP-CERTS] were deployed, the retargeting problem (Appendix A.4.1) would still prevent successful deployment of keying techniques which require the offerer to obtain the actual target's public key.
注：即使部署了sip证书[sip-certs]，重定目标问题（附录A.4.1）仍将阻止成功部署要求提供方获得实际目标公钥的键控技术。
The following list compares the requirements introduced by the use of public-key cryptography in each keying mechanism, both for public key distribution and for certificate validation.
下面的列表比较了在每个密钥机制中使用公钥加密所引入的要求，包括公钥分发和证书验证。
MIKEY-NULL Public-key cryptography is not used.
未使用MIKEY-NULL公钥加密。
MIKEY-PSK Public-key cryptography is not used. Rather, all endpoints must have some way to exchange per-endpoint or per-system pre-shared keys.
未使用MIKEY-PSK公钥加密。相反，所有端点都必须有某种方式来交换每个端点或每个系统的预共享密钥。
MIKEY-RSA The offerer obtains the intended answerer's public key before initiating the call. This public key is used to encrypt the SRTP keys. There is no defined mechanism for the offerer to obtain the answerer's public key, although [SIP-CERTS] might be viable in the future.
在发起呼叫之前，报价人获得预期应答人的公钥。此公钥用于加密SRTP密钥。虽然[SIP-CERTS]在未来可能是可行的，但没有明确的机制让报价人获得应答人的公钥。
The offer may also contain a certificate for the offerer, which would require an authentication infrastructure in order to be validated by the receiver.
要约还可以包含要约人的证书，该证书需要认证基础设施才能由接收方验证。
MIKEY-RSA-R The offer contains the offerer's certificate, and the answer contains the answerer's certificate. The answerer uses the public key in the certificate to encrypt the SRTP keys that will be used by the offerer and the answerer. An authentication infrastructure is necessary to validate the certificates.
MIKEY-RSA-R报价包含报价人的证书，答案包含应答人的证书。应答人使用证书中的公钥对报价人和应答人将使用的SRTP密钥进行加密。验证证书需要一个身份验证基础结构。
MIKEY-DHSIGN An authentication infrastructure is used to authenticate the public key that is included in the MIKEY message.
MIKEY-DHSIGN身份验证基础结构用于对MIKEY消息中包含的公钥进行身份验证。
MIKEY-DHHMAC Public-key cryptography is not used. Rather, all endpoints must have some way to exchange per-endpoint or per-system pre-shared keys.
未使用MIKEY-DHHMAC公钥加密。相反，所有端点都必须有某种方式来交换每个端点或每个系统的预共享密钥。
MIKEYv2 in SDP The behavior will depend on which mode is picked.
SDP中的MIKEYv2行为将取决于选择的模式。
SDP Security Descriptions with SIPS Public-key cryptography is not used.
不使用带有SIPS公钥加密的SDP安全说明。
SDP Security Descriptions with S/MIME Use of S/MIME requires that the endpoints be able to fetch and validate certificates for each other. The offerer must obtain the intended target's certificate and encrypts the SDP offer with the public key contained in target's certificate. The answerer must obtain the offerer's certificate and encrypt the SDP answer with the public key contained in the offerer's certificate.
S/MIME使用S/MIME的SDP安全描述要求端点能够获取和验证彼此的证书。报价人必须获得目标公司的证书，并使用目标公司证书中包含的公钥对SDP报价进行加密。回答者必须获得报价人的证书，并使用报价人证书中包含的公钥对SDP答案进行加密。
SDP-DH Public-key cryptography is not used.
未使用SDP-DH公钥加密。
ZRTP Public-key cryptography is used (Diffie-Hellman), but without dependence on persistent public keys. Thus, certificates are not fetched or validated.
使用ZRTP公钥加密（Diffie-Hellman），但不依赖于持久公钥。因此，不会获取或验证证书。
EKT Public-key cryptography is not used by itself, but might be used by the EKT bootstrapping keying mechanism (such as certain MIKEY modes).
EKT公钥密码术本身不使用，但EKT自举密钥机制（如某些MIKEY模式）可能会使用它。
DTLS-SRTP Remote party's certificate is sent in media path, and a fingerprint of the same certificate is sent in the signaling path.
DTLS-SRTP远程方的证书通过媒体路径发送，同一证书的指纹通过信令路径发送。
MIKEYv2 Inband The behavior will depend on which mode is picked.
MIKEYv2带内行为将取决于选择的模式。
In the context of SRTP, Perfect Forward Secrecy is the property that SRTP session keys that protected a previous session are not compromised if the static keys belonging to the endpoints are compromised. That is, if someone were to record your encrypted session content and later acquires either party's private key, that encrypted session content would be safe from decryption if your key exchange mechanism had perfect forward secrecy.
在SRTP的上下文中，完美前向保密性是指，如果属于端点的静态密钥被泄露，则保护先前会话的SRTP会话密钥不会被泄露。也就是说，如果有人记录了您加密的会话内容，然后获取了任何一方的私钥，那么如果您的密钥交换机制具有完美的前向保密性，则加密的会话内容将不会被解密。
The following list describes how each key exchange mechanism provides PFS.
下面的列表描述了每个密钥交换机制如何提供PFS。
MIKEY-NULL Not applicable; MIKEY-NULL does not have a long-term secret.
MIKEY-NULL不适用；MIKEY-NULL没有长期的秘密。
MIKEY-PSK No PFS.
MIKEY-PSK无PFS。
MIKEY-RSA No PFS.
MIKEY-RSA无PFS。
MIKEY-RSA-R No PFS.
MIKEY-RSA-R无PFS。
MIKEY-DHSIGN PFS is provided with the Diffie-Hellman exchange.
MIKEY-DHSIGN PFS随Diffie-Hellman交换提供。
MIKEY-DHHMAC PFS is provided with the Diffie-Hellman exchange.
MIKEY-DHHMAC PFS配有Diffie-Hellman交换机。
MIKEYv2 in SDP The behavior will depend on which mode is picked.
SDP中的MIKEYv2行为将取决于选择的模式。
SDP Security Descriptions with SIPS Not applicable; SDP Security Descriptions does not have a long-term secret.
带有SIP的SDP安全说明不适用；SDP安全描述没有长期秘密。
SDP Security Descriptions with S/MIME Not applicable; SDP Security Descriptions does not have a long-term secret.
带有S/MIME的SDP安全说明不适用；SDP安全描述没有长期秘密。
SDP-DH PFS is provided with the Diffie-Hellman exchange.
SDP-DH PFS配有Diffie-Hellman交换机。
ZRTP PFS is provided with the Diffie-Hellman exchange.
ZRTP PFS配有Diffie-Hellman交换机。
EKT No PFS.
EKT无PFS。
DTLS-SRTP PFS is provided if the negotiated cipher suite uses ephemeral keys (e.g., Diffie-Hellman (DHE_RSA [RFC5246]) or Elliptic Curve Diffie-Hellman [RFC4492]).
如果协商密码套件使用临时密钥（例如Diffie Hellman（DHE_RSA[RFC5246]）或椭圆曲线Diffie Hellman[RFC4492]），则提供DTLS-SRTP PFS。
MIKEYv2 Inband The behavior will depend on which mode is picked.
MIKEYv2带内行为将取决于选择的模式。
With best effort encryption, SRTP is used with endpoints that support SRTP, otherwise RTP is used.
通过尽力而为的加密，SRTP与支持SRTP的端点一起使用，否则使用RTP。
SIP needs a backwards-compatible best effort encryption in order for SRTP to work successfully with SIP retargeting and forking when there is a mix of forked or retargeted devices that support SRTP and don't support SRTP.
SIP需要向后兼容的尽力而为加密，以便在混合使用支持SRTP而不支持SRTP的分叉或重定目标设备时，SRTP能够成功地使用SIP重定目标和分叉。
Consider the case of Bob, with a phone that only does RTP and a voice mail system that supports SRTP and RTP. If Alice calls Bob with an SRTP offer, Bob's RTP-only phone will reject the media stream (with an empty "m=" line) because Bob's phone doesn't understand SRTP (RTP/SAVP). Alice's phone will see this rejected media stream and may terminate the entire call (BYE) and re-initiate the call as RTP-only, or Alice's phone may decide to continue with call setup with the SRTP-capable leg (the voice mail system). If Alice's phone decided to re-initiate the call as RTP-only, and Bob doesn't answer his phone, Alice will then leave voice mail using only RTP, rather than SRTP as expected.
考虑鲍伯的情况，一个只有RTP和支持SRTP和RTP的语音邮件系统的电话。如果Alice打电话给Bob提供SRTP服务，Bob的纯RTP手机将拒绝媒体流（使用空的“m=”行），因为Bob的手机不理解SRTP（RTP/SAVP）。Alice的手机将看到此被拒绝的媒体流，可能会终止整个通话（再见），并仅以RTP方式重新启动通话，或者Alice的手机可能会决定使用支持SRTP的分支（语音邮件系统）继续进行通话设置。如果Alice的手机决定只以RTP方式重新启动呼叫，而Bob不接听他的电话，Alice将只使用RTP而不是预期的SRTP方式来发送语音邮件。
Currently, several techniques are commonly considered as candidates to provide opportunistic encryption:
目前，有几种技术通常被认为是提供机会主义加密的候选技术：
multipart/alternative [MULTIPART] describes how to form a multipart/alternative body part in SIP. The significant issues with this technique are (1) that multipart MIME is incompatible with existing SIP proxies, firewalls, Session Border Controllers, and endpoints and (2) when forking, the Heterogeneous Error Response Forking Problem (HERFP) [RFC3326] causes problems if such non-multipart-capable endpoints were involved in the forking.
multipart/alternative[多部分]描述如何在SIP中形成多部分/替代主体部分。此技术的重要问题是（1）多部分MIME与现有SIP代理、防火墙、会话边界控制器和端点不兼容；（2）分叉时，异构错误响应分叉问题（HERFP）[RFC3326]会导致问题，如果分叉中涉及不支持多部分的端点。
session attribute With this technique, the endpoints signal their desire to do SRTP by signaling RTP (RTP/AVP), and using an attribute ("a=") in the SDP. This technique is entirely backwards compatible with non-SRT-aware endpoints, but doesn't use the RTP/SAVP protocol registered by SRTP [RFC3711].
会话属性使用此技术，端点通过发送RTP（RTP/AVP）信号并在SDP中使用属性（“a=”）来表示他们希望执行SRTP。该技术与不支持SRT的端点完全向后兼容，但不使用SRTP注册的RTP/SAVP协议[RFC3711]。
SDP Capability Negotiation SDP Capability Negotiation [SDP-CAP] provides a backwards-compatible mechanism to allow offering both SRTP and RTP in a single offer. This is the preferred technique.
SDP能力协商SDP能力协商[SDP-CAP]提供了一种向后兼容的机制，允许在单个产品中同时提供SRTP和RTP。这是首选技术。
Probing With this technique, the endpoints first establish an RTP session using RTP (RTP/AVP). The endpoints send probe messages, over the media path, to determine if the remote endpoint supports their keying technique. A disadvantage of probing is an active attacker can interfere with probes, and until probing completes (and SRTP is established) the media is in the clear.
使用此技术进行探测时，端点首先使用RTP（RTP/AVP）建立RTP会话。端点通过媒体路径发送探测消息，以确定远程端点是否支持其键控技术。探测的一个缺点是，主动攻击者可能会干扰探测，并且在探测完成（并建立SRTP）之前，介质处于透明状态。
The preferred technique, SDP Capability Negotiation [SDP-CAP], can be used with all key exchange mechanisms. What remains unique is ZRTP, which can also accomplish its best effort encryption by probing (sending ZRTP messages over the media path) or by session attribute (see "a=zrtp-hash" in [ZRTP]). Current implementations of ZRTP use probing.
首选技术SDP能力协商[SDP-CAP]可用于所有密钥交换机制。唯一的是ZRTP，它还可以通过探测（通过媒体路径发送ZRTP消息）或会话属性（参见[ZRTP]中的“a=ZRTP哈希”）来完成其最大努力的加密。ZRTP的当前实现使用探测。
It is necessary to allow upgrading SRTP encryption and hash algorithms, as well as upgrading the cryptographic functions used for the key exchange mechanism. With SIP's offer/answer model, this can be computationally expensive because the offer needs to contain all combinations of the key exchange mechanisms (all MIKEY modes, SDP Security Descriptions), all SRTP cryptographic suites (AES-128, AES-256) and all SRTP cryptographic hash functions (SHA-1, SHA-256) that the offerer supports. In order to do this, the offerer has to expend CPU resources to build an offer containing all of this information that becomes computationally prohibitive.
有必要允许升级SRTP加密和哈希算法，以及升级用于密钥交换机制的加密功能。对于SIP的提供/应答模型，这可能在计算上非常昂贵，因为提供需要包含提供方支持的密钥交换机制（所有MIKEY模式、SDP安全描述）、所有SRTP加密套件（AES-128、AES-256）和所有SRTP加密哈希函数（SHA-1、SHA-256）的所有组合。为了做到这一点，报价人必须花费CPU资源来构建一个包含所有这些信息的报价，而这些信息在计算上是不允许的。
Thus, it is important to keep the offerer's CPU impact fixed so that offering multiple new SRTP encryption and hash functions incurs no additional expense.
因此，重要的是保持报价人的CPU影响固定，以便提供多个新的SRTP加密和哈希函数不会产生额外费用。
The following list describes the CPU effort involved in using each key exchange technique.
下面的列表描述了使用每个密钥交换技术所涉及的CPU工作。
MIKEY-NULL No significant computational expense.
MIKEY-NULL没有显著的计算开销。
MIKEY-PSK No significant computational expense.
MIKEY-PSK没有显著的计算开销。
MIKEY-RSA For each offered SRTP crypto suite, the offerer has to perform RSA operation to encrypt the TGK (TEK Generation Key).
MIKEY-RSA对于每个提供的SRTP加密套件，报价人必须执行RSA操作以加密TGK（TEK生成密钥）。
MIKEY-RSA-R For each offered SRTP crypto suite, the offerer has to perform public key operation to sign the MIKEY message.
MIKEY-RSA-R对于每个提供的SRTP加密套件，提供方必须执行公钥操作以签署MIKEY消息。
MIKEY-DHSIGN For each offered SRTP crypto suite, the offerer has to perform Diffie-Hellman operation, and a public key operation to sign the Diffie-Hellman output.
MIKEY-DHSIGN对于每个提供的SRTP加密套件，报价人必须执行Diffie-Hellman操作，并执行公钥操作以签署Diffie-Hellman输出。
MIKEY-DHHMAC For each offered SRTP crypto suite, the offerer has to perform Diffie-Hellman operation.
对于每个提供的SRTP加密套件，报价人必须执行Diffie-Hellman操作。
MIKEYv2 in SDP The behavior will depend on which mode is picked.
SDP中的MIKEYv2行为将取决于选择的模式。
SDP Security Descriptions with SIPS No significant computational expense.
具有SIPS的SDP安全描述没有显著的计算开销。
SDP Security Descriptions with S/MIME S/MIME requires the offerer and the answerer to encrypt the SDP with the other's public key, and to decrypt the received SDP with their own private key.
带有S/MIME S/MIME的SDP安全描述要求提供方和应答方使用对方的公钥加密SDP，并使用自己的私钥解密收到的SDP。
SDP-DH For each offered SRTP crypto suite, the offerer has to perform a Diffie-Hellman operation.
SDP-DH对于每个提供的SRTP加密套件，报价人必须执行Diffie-Hellman操作。
ZRTP The offerer has no additional computational expense at all, as the offer contains no information about ZRTP or might contain "a=zrtp-hash".
ZRTP报价人没有任何额外的计算费用，因为报价不包含关于ZRTP的信息或可能包含“a=ZRTP哈希”。
EKT The offerer's computational expense depends entirely on the EKT bootstrapping mechanism selected (one or more MIKEY modes or SDP Security Descriptions).
EKT报价人的计算费用完全取决于选择的EKT引导机制（一个或多个MIKEY模式或SDP安全描述）。
DTLS-SRTP The offerer has no additional computational expense at all, as the offer contains only a fingerprint of the certificate that will be presented in the DTLS exchange.
DTLS-SRTP报价人完全没有额外的计算费用，因为报价仅包含将在DTLS交换中提供的证书指纹。
MIKEYv2 Inband The behavior will depend on which mode is picked.
MIKEYv2带内行为将取决于选择的模式。
The compromise of an endpoint that has access to decrypted media (e.g., SIP user agent, transcoder, recorder) is out of scope of this document. Such a compromise might be via privilege escalation, installation of a virus or trojan horse, or similar attacks.
可以访问解密媒体（例如，SIP用户代理、转码器、记录器）的端点的危害超出了本文档的范围。这样的妥协可能是通过权限提升、安装病毒或特洛伊木马或类似的攻击。
The consensus on the RTPSEC mailing list was to concentrate on unicast, point-to-point sessions. Thus, there are no requirements related to shared key conferencing. This section is retained for informational purposes.
关于RTPSEC邮件列表的共识是集中于单播、点对点会话。因此，没有与共享密钥会议相关的要求。保留本节仅供参考。
For efficient scaling, large audio and video conference bridges operate most efficiently by encrypting the current speaker once and distributing that stream to the conference attendees. Typically, inactive participants receive the same streams -- they hear (or see) the active speaker(s), and the active speakers receive distinct streams that don't include themselves. In order to maintain the confidentiality of such conferences where listeners share a common key, all listeners must rekeyed when a listener joins or leaves a conference.
为了有效扩展，大型音频和视频会议网桥通过对当前演讲者加密一次并将该流分发给会议与会者来最有效地运行。通常，不活跃的参与者接收相同的流——他们听到（或看到）活跃的演讲者，而活跃的演讲者接收不包括他们自己的不同流。为了维护侦听器共享公共密钥的会议的机密性，当侦听器加入或离开会议时，所有侦听器都必须重新设置密钥。
An important use case for mixers/translators is a conference bridge:
混音器/翻译器的一个重要用例是会议桥：
+----+
A --- 1 --->| |
<-- 2 ----| M |
| I |
B --- 3 --->| X |
<-- 4 ----| E |
| R |
C --- 5 --->| |
<-- 6 ----| |
+----+
+----+
A --- 1 --->| |
<-- 2 ----| M |
| I |
B --- 3 --->| X |
<-- 4 ----| E |
| R |
C --- 5 --->| |
<-- 6 ----| |
+----+
Figure 3: Centralized Keying
图3：集中键控
In the figure above, 1, 3, and 5 are RTP media contributions from Alice, Bob, and Carol, and 2, 4, and 6 are the RTP flows to those devices carrying the "mixed" media.
在上图中，1、3和5是来自Alice、Bob和Carol的RTP介质贡献，2、4和6是到那些携带“混合”介质的设备的RTP流。
Several scenarios are possible:
有几种可能的情况：
a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP sessions,
a. 多个入站会话：1、3和5是不同的RTP会话，
b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP sessions,
b. 多个出站会话：2、4和6是不同的RTP会话，
c. Single inbound session: 1, 3, and 5 are just different sources within the same RTP session,
c. 单个入站会话：1、3和5只是同一RTP会话中的不同源，
d. Single outbound session: 2, 4, and 6 are different flows of the same (multi-unicast) RTP session.
d. 单个出站会话：2、4和6是同一（多单播）RTP会话的不同流。
If there are multiple inbound sessions and multiple outbound sessions (scenarios a and b), then every keying mechanism behaves as if the mixer were an endpoint and can set up a point-to-point secure session between the participant and the mixer. This is the simplest situation, but is computationally wasteful, since SRTP processing has to be done independently for each participant. The use of multiple inbound sessions (scenario a) doesn't waste computational resources, though it does consume additional cryptographic context on the mixer for each participant and has the advantage of data origin authentication.
如果存在多个入站会话和多个出站会话（场景a和b），则每个键控机制的行为就像混合器是端点一样，可以在参与者和混合器之间设置点对点安全会话。这是最简单的情况，但在计算上是浪费的，因为SRTP处理必须为每个参与者独立完成。使用多个入站会话（场景a）不会浪费计算资源，尽管它会为每个参与者在混合器上消耗额外的加密上下文，并且具有数据源身份验证的优势。
To support a single outbound session (scenario d), the mixer has to dictate its encryption key to the participants. Some keying mechanisms allow the transmitter to determine its own key, and others allow the offerer to determine the key for the offerer and answerer. Depending on how the call is established, the offerer might be a
为了支持单个出站会话（场景d），混音器必须向参与者口述其加密密钥。一些键控机制允许发送器确定自己的键，而另一些机制则允许发信人确定发信人和应答人的键。根据呼叫建立的方式，要约人可能是
participant (such as a participant dialing into a conference bridge) or the offerer might be the mixer (such as a conference bridge calling a participant). The use of offerless INVITEs may help some keying mechanisms reverse the role of offerer/answerer. A difficulty, however, is knowing a priori if the role should be reversed for a particular call. The significant advantage of a single outbound session is the number of SRTP encryption operations remains constant even as the number of participants increases. However, a disadvantage is that data origin authentication is lost, allowing any participant to spoof the sender (because all participants know the sender's SRTP key).
参与者（例如拨入会议网桥的参与者）或报价人可能是混音器（例如呼叫参与者的会议网桥）。使用无要约邀请可能有助于某些键控机制逆转要约人/应答人的角色。然而，一个困难是先验地知道某个特定的调用是否应该颠倒角色。单个出站会话的显著优点是，即使参与者数量增加，SRTP加密操作的数量也保持不变。然而，一个缺点是数据源身份验证丢失，允许任何参与者欺骗发送方（因为所有参与者都知道发送方的SRTP密钥）。
Authors' Addresses
作者地址
Dan Wing (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Dan Wing（编辑）思科系统公司，美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com
Steffen Fries Siemens AG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
德国巴伐利亚州慕尼黑Steffen Fries Siemens AG Otto Hahn 6号环81739
EMail: steffen.fries@siemens.com
EMail: steffen.fries@siemens.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo, 02600 Finland
芬兰埃斯波6号，邮编02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Francois Audet Nortel 4655 Great America Parkway Santa Clara, CA 95054 USA
弗朗索瓦·奥德特北电4655美国加利福尼亚州圣克拉拉大美洲大道95054号
EMail: audet@nortel.com
EMail: audet@nortel.com