Network Working Group F. Andreasen
Request for Comments: 4568 M. Baugher
Category: Standards Track D. Wing
Cisco Systems
July 2006
Network Working Group F. Andreasen
Request for Comments: 4568 M. Baugher
Category: Standards Track D. Wing
Cisco Systems
July 2006
Session Description Protocol (SDP) Security Descriptions for Media Streams
媒体流的会话描述协议（SDP）安全描述
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message.
本文档定义了单播媒体流的会话描述协议（SDP）加密属性。该属性描述用于在单个消息或往返交换中为单播媒体流配置安全性的加密密钥和其他参数。该属性可用于各种SDP媒体传输，本文档定义了如何将其用于安全实时传输协议（SRTP）单播媒体流。SDP crypto属性需要数据安全协议的服务来保护SDP消息。
Table of Contents
目录
1. Introduction ....................................................3
2. Notational Conventions ..........................................5
3. Applicability ...................................................5
4. SDP "Crypto" Attribute and Parameters ...........................5
4.1. Tag ........................................................6
4.2. Crypto-Suite ...............................................6
4.3. Key Parameters .............................................7
4.4. Session Parameters .........................................8
4.5. Example ....................................................8
5. General Use of the crypto Attribute .............................9
5.1. Use with Offer/Answer ......................................9
5.1.1. Generating the Initial Offer - Unicast Streams ......9
1. Introduction ....................................................3
2. Notational Conventions ..........................................5
3. Applicability ...................................................5
4. SDP "Crypto" Attribute and Parameters ...........................5
4.1. Tag ........................................................6
4.2. Crypto-Suite ...............................................6
4.3. Key Parameters .............................................7
4.4. Session Parameters .........................................8
4.5. Example ....................................................8
5. General Use of the crypto Attribute .............................9
5.1. Use with Offer/Answer ......................................9
5.1.1. Generating the Initial Offer - Unicast Streams ......9
5.1.2. Generating the Initial Answer - Unicast Streams ....10
5.1.3. Processing of the Initial Answer - Unicast
Streams ............................................11
5.1.4. Modifying the Session ..............................11
5.2. Use Outside Offer/Answer ..................................11
5.3. General Backwards Compatibility Considerations ............12
6. SRTP Security Descriptions .....................................12
6.1. SRTP Key Parameter ........................................13
6.2. Crypto-Suites .............................................16
6.2.1. AES_CM_128_HMAC_SHA1_80 ............................16
6.2.2. AES_CM_128_HMAC_SHA1_32 ............................17
6.2.3. F8_128_HMAC_SHA1_80 ................................17
6.2.4. Adding New Crypto-Suite Definitions ................17
6.3. Session Parameters ........................................17
6.3.1. KDR=n ..............................................18
6.3.2. UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP .............18
6.3.3. UNAUTHENTICATED_SRTP ...............................18
6.3.4. FEC_ORDER=order ....................................19
6.3.5. FEC_KEY=key-params .................................19
6.3.6. Window Size Hint (WSH) .............................19
6.3.7. Defining New SRTP Session Parameters ...............20
6.4. SRTP Crypto Context Initialization ........................20
6.4.1. Late Binding of One or More SSRCs to a
Crypto Context .....................................21
6.4.2. Sharing Cryptographic Contexts among
Sessions or SSRCs ..................................22
6.5. Removal of Crypto Contexts ................................23
7. SRTP-Specific Use of the Crypto Attribute ......................23
7.1. Use with Offer/Answer .....................................23
7.1.1. Generating the Initial Offer - Unicast Streams .....23
7.1.2. Generating the Initial Answer - Unicast Streams ....24
7.1.3. Processing of the Initial Answer - Unicast
Streams ............................................25
7.1.4. Modifying the Session ..............................25
7.1.5. Offer/Answer Example ...............................27
7.2. SRTP-Specific Use Outside Offer/Answer ....................28
7.3. Support for SIP Forking ...................................28
7.4. SRTP-Specific Backwards Compatibility Considerations ......29
7.5. Operation with KEYMGT= and k= lines .......................29
8. Security Considerations ........................................29
8.1. Authentication of Packets .................................30
8.2. Keystream Reuse ...........................................30
8.3. Signaling Authentication and Signaling Encryption .........31
9. Grammar ........................................................32
9.1. Generic "Crypto" Attribute Grammar ........................32
9.2. SRTP "Crypto" Attribute Grammar ...........................32
10. IANA Considerations ...........................................34
10.1. Registration of the "crypto" Attribute ...................34
5.1.2. Generating the Initial Answer - Unicast Streams ....10
5.1.3. Processing of the Initial Answer - Unicast
Streams ............................................11
5.1.4. Modifying the Session ..............................11
5.2. Use Outside Offer/Answer ..................................11
5.3. General Backwards Compatibility Considerations ............12
6. SRTP Security Descriptions .....................................12
6.1. SRTP Key Parameter ........................................13
6.2. Crypto-Suites .............................................16
6.2.1. AES_CM_128_HMAC_SHA1_80 ............................16
6.2.2. AES_CM_128_HMAC_SHA1_32 ............................17
6.2.3. F8_128_HMAC_SHA1_80 ................................17
6.2.4. Adding New Crypto-Suite Definitions ................17
6.3. Session Parameters ........................................17
6.3.1. KDR=n ..............................................18
6.3.2. UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP .............18
6.3.3. UNAUTHENTICATED_SRTP ...............................18
6.3.4. FEC_ORDER=order ....................................19
6.3.5. FEC_KEY=key-params .................................19
6.3.6. Window Size Hint (WSH) .............................19
6.3.7. Defining New SRTP Session Parameters ...............20
6.4. SRTP Crypto Context Initialization ........................20
6.4.1. Late Binding of One or More SSRCs to a
Crypto Context .....................................21
6.4.2. Sharing Cryptographic Contexts among
Sessions or SSRCs ..................................22
6.5. Removal of Crypto Contexts ................................23
7. SRTP-Specific Use of the Crypto Attribute ......................23
7.1. Use with Offer/Answer .....................................23
7.1.1. Generating the Initial Offer - Unicast Streams .....23
7.1.2. Generating the Initial Answer - Unicast Streams ....24
7.1.3. Processing of the Initial Answer - Unicast
Streams ............................................25
7.1.4. Modifying the Session ..............................25
7.1.5. Offer/Answer Example ...............................27
7.2. SRTP-Specific Use Outside Offer/Answer ....................28
7.3. Support for SIP Forking ...................................28
7.4. SRTP-Specific Backwards Compatibility Considerations ......29
7.5. Operation with KEYMGT= and k= lines .......................29
8. Security Considerations ........................................29
8.1. Authentication of Packets .................................30
8.2. Keystream Reuse ...........................................30
8.3. Signaling Authentication and Signaling Encryption .........31
9. Grammar ........................................................32
9.1. Generic "Crypto" Attribute Grammar ........................32
9.2. SRTP "Crypto" Attribute Grammar ...........................32
10. IANA Considerations ...........................................34
10.1. Registration of the "crypto" Attribute ...................34
10.2. New IANA Registries and Registration Procedures ..........34
10.2.1. Key Method Registry and Registration ..............34
10.2.2. Media Stream Transport Registry and Registration ..35
10.3. Initial Registrations ....................................35
10.3.1. Key Method ........................................35
10.3.2. SRTP Media Stream Transport .......................35
10.3.2.1. SRTP Crypto Suite Registry and
Registration .............................35
10.3.2.2. SRTP Session Parameter Registration ......36
11. Acknowledgements ..............................................36
12. Normative References ..........................................36
13. Informative References ........................................37
Appendix A - Rationale for Keying Material Directionality .........40
10.2. New IANA Registries and Registration Procedures ..........34
10.2.1. Key Method Registry and Registration ..............34
10.2.2. Media Stream Transport Registry and Registration ..35
10.3. Initial Registrations ....................................35
10.3.1. Key Method ........................................35
10.3.2. SRTP Media Stream Transport .......................35
10.3.2.1. SRTP Crypto Suite Registry and
Registration .............................35
10.3.2.2. SRTP Session Parameter Registration ......36
11. Acknowledgements ..............................................36
12. Normative References ..........................................36
13. Informative References ........................................37
Appendix A - Rationale for Keying Material Directionality .........40
The Session Description Protocol (SDP) [RFC4566] describes multimedia sessions, which can be audio, video, whiteboard, fax, modem, and other media streams. Security services such as data origin authentication, integrity, and confidentiality are often needed for those streams. The Secure Real-time Transport Protocol (SRTP) [RFC3711] provides security services for RTP media and is signaled by use of secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an SDP media (m=) line. However, there are no means within SDP itself to configure SRTP beyond using default values. This document specifies a new SDP attribute called "crypto", which is used to signal and negotiate cryptographic parameters for media streams in general, and for SRTP in particular. The definition of the crypto attribute in this document is limited to two-party unicast media streams where each source has a unique cryptographic key; support for multicast media streams or multipoint unicast streams is for further study.
会话描述协议（SDP）[RFC4566]描述多媒体会话，可以是音频、视频、白板、传真、调制解调器和其他媒体流。这些流通常需要数据源身份验证、完整性和机密性等安全服务。安全实时传输协议（SRTP）[RFC3711]为RTP介质提供安全服务，并通过在SDP介质（m=）线路中使用安全RTP传输（例如，“RTP/SAVP”或“RTP/SAVPF”）发出信号。但是，除了使用默认值之外，SDP本身无法配置SRTP。本文档指定了一个名为“crypto”的新SDP属性，该属性通常用于向媒体流发送信号并协商加密参数，尤其是SRTP。本文档中加密属性的定义仅限于两方单播媒体流，其中每个源具有唯一的加密密钥；对多播媒体流或多点单播流的支持有待进一步研究。
The crypto attribute is defined in a generic way to enable its use with SRTP and any other secure transports that can establish cryptographic parameters with only a single message or in a single round-trip exchange using the offer/answer model [RFC3264]. Extensions to transports other than SRTP, however, is beyond the scope of this document. Each type of secure media transport needs its own specification for the crypto-attribute parameter. These definitions are frequently unique to the particular type of transport and must be specified in a Standards-Track RFC and registered with IANA according to the procedures defined in Section 10. This document defines the security parameters and keying material for SRTP only.
crypto属性以一种通用的方式定义，以使其能够与SRTP和任何其他安全传输一起使用，这些传输可以仅使用一条消息或使用提供/应答模型在一次往返交换中建立加密参数[RFC3264]。但是，对SRTP以外的传输的扩展超出了本文档的范围。每种类型的安全媒体传输都需要自己的加密属性参数规范。这些定义通常是特定类型运输的唯一定义，必须在标准轨道RFC中指定，并根据第10节中定义的程序向IANA注册。本文件仅定义了SRTP的安全参数和密钥材料。
It would be self-defeating not to secure cryptographic keys and other parameters at least as well as the data are secured. Data security protocols such as SRTP rely upon a separate key management system to securely establish encryption and/or authentication keys. Key management protocols provide authenticated key establishment (AKE) procedures to authenticate the identity of each endpoint and protect against man-in-the-middle, reflection/replay, connection hijacking, and some denial-of-service attacks [skeme]. Along with the key, an AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK [kink], IKE [ike], Secure Multiparts [s/mime, pgp/mime], or TLS [TLS] securely disseminates information describing both the key and the data-security session. AKE is needed because it is pointless to provide a key over a medium where an attacker can snoop the key, alter the definition of the key to render it useless, or change the parameters of the security session to gain unauthorized access to session-related information.
如果不确保加密密钥和其他参数的安全（至少数据是安全的），那将是自相矛盾的。数据安全协议（如SRTP）依赖于单独的密钥管理系统来安全地建立加密和/或身份验证密钥。密钥管理协议提供身份验证密钥建立（AKE）过程，以验证每个端点的身份，并防止中间人、反射/重放、连接劫持和一些拒绝服务攻击[skeme]。与密钥一起，诸如MIKEY[MIKEY]、GDOI[GDOI]、KINK[KINK]、IKE[IKE]、Secure Multiparts[s/mime、pgp/mime]或TLS[TLS]等AKE协议安全地传播描述密钥和数据安全会话的信息。之所以需要AKE，是因为在攻击者可以窥探密钥、更改密钥定义使其无效或更改安全会话参数以获得对会话相关信息的未经授权访问的介质上提供密钥是毫无意义的。
SDP, however, was not designed to provide AKE services, and the media security descriptions defined in this document do not add AKE services to SDP. This specification is no replacement for a key management protocol or for the conveyance of key management messages in SDP [keymgt]. The SDP security descriptions defined here are suitable for restricted cases only where IPsec, TLS, or some other encapsulating data-security protocol (e.g., SIP S/MIME) protects the SDP message. This document adds security descriptions to those encrypted and/or authenticated SDP messages through the new SDP "crypto" attribute, which provides the cryptographic parameters of a media stream.
然而，SDP并不是为提供AKE服务而设计的，并且本文档中定义的媒体安全描述不会将AKE服务添加到SDP中。本规范不能替代密钥管理协议或SDP[keymgt]中密钥管理消息的传输。此处定义的SDP安全描述仅适用于IPsec、TLS或某些其他封装数据安全协议（例如SIP S/MIME）保护SDP消息的受限情况。本文档通过新的SDP“crypto”属性向加密和/或认证的SDP消息添加安全描述，该属性提供媒体流的加密参数。
The "crypto" attribute can be adapted to any media transport, but its precise definition is unique to a particular transport.
“crypto”属性可以适用于任何媒体传输，但其精确定义对于特定传输是唯一的。
In Section 2, we provide notational conventions followed by an applicability statement for the crypto attribute in Section 3. In Section 4, we introduce the general SDP crypto attribute, and in Section 5, we define how it is used with and without the offer/answer model. In Section 6, we define the crypto attribute details needed for SRTP, and in Section 7, we define SRTP-specific use of the attribute with and without the offer/answer model. Section 8 recites security considerations, and Section 9 gives an Augmented-BNF grammar for the general crypto attribute as well as the SRTP-specific use of the crypto attribute. IANA considerations are provided in Section 10.
在第2节中，我们提供了符号约定，然后在第3节中提供了加密属性的适用性声明。在第4节中，我们介绍了通用SDP加密属性，在第5节中，我们定义了如何在有和没有提供/应答模型的情况下使用它。在第6节中，我们定义了SRTP所需的加密属性详细信息，在第7节中，我们定义了SRTP在提供/应答模型和不提供/应答模型的情况下对属性的特定使用。第8节叙述了安全注意事项，第9节给出了通用加密属性的扩充BNF语法以及加密属性的SRTP特定用法。IANA注意事项见第10节。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terminology in this document conforms to [RFC2828], "Internet Security Glossary".
本文件中的关键词“必须”、“不得”、“必需”、“应该”、“不应该”、“建议”、“可能”和“可选”应按照[RFC2119]中所述进行解释。本文件中的术语符合[RFC2828]“互联网安全术语表”。
n^r is exponentiation, where n is multiplied by itself r times; n and r are integers. 0..k is an integer range of all integers from 0 through k, inclusive.
n^r是指数运算，其中n乘以自身r倍；n和r是整数。0..k是从0到k（含）的所有整数的整数范围。
The terms 'transport' and 'media transport' are used to mean 'transport protocol' as defined in RFC 4566.
术语“传输”和“媒体传输”用于表示RFC 4566中定义的“传输协议”。
Explanatory notes are provided in several places throughout the document; these notes are indented three spaces from the surrounding text.
在整个文件的几个地方提供了解释性说明；这些注释从周围文本缩进三个空格。
RFC 4567 provides similar cryptographic key distribution capabilities and is intended for use when the signaling is to be confidential and/or integrity-protected separately from the keying material.
RFC 4567提供了类似的加密密钥分发功能，并打算在信令与密钥材料分开进行保密和/或完整性保护时使用。
In contrast, this specification carries the keying material within the SDP message, and it is intended for use when the keying material is protected along with the signaling. Implementations MUST employ security mechanisms that provide confidentiality and integrity for the keying material. When this specification is used in the context of SIP [RFC3261], the application SHOULD employ either the SIPS URI or S/MIME to provide protection for the SDP message and the keying material that it contains. The use of transport layer or IP layer security in lieu of the SIPS URI or S/MIME protection is NOT RECOMMENDED since the protection of the SDP message and the keying material that it contains cannot be ensured through all intermediate entities such as SIP proxies.
相比之下，本规范在SDP消息中承载键控材料，并且其旨在当键控材料与信令一起受到保护时使用。实现必须采用安全机制，为密钥材料提供机密性和完整性。当在SIP[RFC3261]上下文中使用此规范时，应用程序应使用SIPS URI或S/MIME为SDP消息及其包含的键控材料提供保护。不建议使用传输层或IP层安全性代替SIPS URI或S/MIME保护，因为无法通过所有中间实体（如SIP代理）确保对SDP消息及其包含的密钥材料的保护。
A new media-level SDP attribute called "crypto" describes the cryptographic suite, key parameters, and session parameters for the preceding unicast media line. The "crypto" attribute MUST only appear at the SDP media level (not at the session level). The "crypto" attribute follows the format (see Section 9.1 for the formal ABNF grammar):
名为“crypto”的新媒体级SDP属性描述了前面单播媒体线路的加密套件、密钥参数和会话参数。“crypto”属性只能出现在SDP媒体级别（而不是会话级别）。“crypto”属性遵循以下格式（形式ABNF语法见第9.1节）：
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
The fields tag, crypto-suite, key-params, and session-params are described in the following sub-sections. The values of each of these fields is case-insensitive, unless otherwise noted. However, implementers are encouraged to use the actual case shown in this document and any extensions to it. Note that per normal SDP rules, the "crypto" attribute name itself is case-sensitive. Below, we show an example of the crypto attribute for the "RTP/SAVP" transport, i.e., the secure RTP extension to the Audio/Video Profile [RFC3711]. In the following, newlines are included for formatting reasons only:
标签、加密套件、密钥参数和会话参数字段在以下小节中描述。除非另有说明，否则每个字段的值都不区分大小写。但是，鼓励实施者使用本文档中显示的实际案例及其任何扩展。请注意，根据正常的SDP规则，“crypto”属性名称本身是区分大小写的。下面，我们展示了“RTP/SAVP”传输的加密属性示例，即音频/视频配置文件的安全RTP扩展[RFC3711]。在以下内容中，包含换行符仅出于格式原因：
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32
The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined by the text starting with "inline:", and session-params is omitted.
加密套件为AES_CM_128_HMAC_SHA1_80，密钥参数由以“inline:”开头的文本定义，会话参数省略。
The tag is a decimal number used as an identifier for a particular crypto attribute (see Section 9.1 for details); leading zeroes MUST NOT be used. The tag MUST be unique among all crypto attributes for a given media line. It is used with the offer/answer model to determine which of several offered crypto attributes were chosen by the answerer (see Section 5.1).
标签是一个十进制数字，用作特定加密属性的标识符（详情见第9.1节）；不得使用前导零。标记在给定媒体行的所有加密属性中必须是唯一的。它与提供/应答模型一起使用，以确定应答者选择了几个提供的加密属性中的哪一个（见第5.1节）。
In the offer/answer model, the tag is a negotiated parameter.
在提供/应答模型中，标记是一个协商参数。
The crypto-suite field is an identifier that describes the encryption and authentication algorithms (e.g., AES_CM_128_HMAC_SHA1_80) for the transport in question (see Section 9.1 for details). The possible values for the crypto-suite parameter are defined within the context of the transport, i.e., each transport defines a separate namespace for the set of crypto-suites. For example, the crypto-suite "AES_CM_128_HMAC_SHA1_80" defined within the context "RTP/SAVP" transport applies to Secure RTP only; the string may be reused for another transport (e.g., "RTP/SAVPF" [srtpf]), but a separate definition would be needed.
crypto suite字段是一个标识符，用于描述有关传输的加密和身份验证算法（例如，AES_CM_128_HMAC_SHA1_80）（有关详细信息，请参阅第9.1节）。crypto suite参数的可能值在传输上下文中定义，即，每个传输为加密套件集定义一个单独的命名空间。例如，在“RTP/SAVP”传输上下文中定义的加密套件“AES_CM_128_HMAC_SHA1_80”仅适用于安全RTP；该字符串可用于其他传输（例如，“RTP/SAVPF”[srtpf]），但需要单独定义。
In the offer/answer model, the crypto-suite is a negotiated parameter.
在提供/应答模型中，加密套件是一个协商参数。
The key-params field provides one or more sets of keying material for the crypto-suite in question. The field consists of a method indicator followed by a colon, and the actual keying information as shown below (the formal grammar is provided in Section 9.1):
key params字段为所讨论的加密套件提供一组或多组密钥材料。该字段由方法指示符（后跟冒号）和实际键控信息组成，如下所示（第9.1节提供了形式语法）：
key-params = <key-method> ":" <key-info>
key-params = <key-method> ":" <key-info>
Keying material might be provided by different means from that for key-params; however, this is out of scope. Only one method is defined in this document, namely, "inline", which indicates that the actual keying material is provided in the key-info field itself. There is a single name space for the key-method, i.e., the key-method is transport independent. New key-methods (e.g., use of a URL) may be defined in a Standards-Track RFC in the future. Although the key-method itself may be generic, the accompanying key-info definition is specific not only to the key-method, but also to the transport in question. Key-info encodes keying material for a crypto suite, which defines that keying material. New key methods MUST be registered with the IANA according to the procedures defined in Section 10.2.1.
可通过不同于键参数的方式提供键控材料；然而，这超出了范围。本文档中只定义了一种方法，即“内联”，这表示实际的键控材料是在键控信息字段本身中提供的。密钥方法只有一个名称空间，即密钥方法与传输无关。未来可能会在标准跟踪RFC中定义新的关键方法（例如，使用URL）。尽管密钥方法本身可能是通用的，但附带的密钥信息定义不仅特定于密钥方法，而且特定于所讨论的传输。密钥信息对加密套件的密钥材料进行编码，该套件定义了该密钥材料。新的关键方法必须按照第10.2.1节规定的程序向IANA注册。
Key-info is defined as a general octet string (see Section 9.1 for details); further transport and key-method specific syntax and semantics MUST be provided in a Standards-Track RFC for each combination of transport and key-method that uses it; definitions for SRTP are provided in Section 6. Note that such definitions are provided within the context of both a particular transport (e.g., "RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will register the list of supported key methods for each transport.
密钥信息定义为通用八位字节字符串（详见第9.1节）；标准跟踪RFC中必须为使用它的每个传输和关键方法组合提供更多传输和关键方法特定的语法和语义；第6节提供了SRTP的定义。请注意，这些定义是在特定传输（如“RTP/SAVP”）和特定键方法（如“内联”）的上下文中提供的。IANA将为每个传输注册支持的关键方法列表。
When multiple keys are included in the key parameters, it MUST be possible to determine which of the keys is being used in a given media packet by a simple inspection of the media packet received; a trial-and-error approach between the possible keys MUST NOT be performed.
当在密钥参数中包括多个密钥时，必须能够通过简单地检查所接收的媒体分组来确定在给定媒体分组中使用的密钥中的哪一个；不得在可能的钥匙之间进行试错操作。
For SRTP, this could be achieved by use of Master Key Identifiers (MKI) [RFC3711]. Use of <"From, "To"> values are not supported in SRTP security descriptions for reasons explained in Section 6.1, below.
对于SRTP，这可以通过使用主密钥标识符（MKI）[RFC3711]来实现。由于下文第6.1节解释的原因，SRTP安全说明中不支持使用<“从”到“>值。
In the offer/answer model, the key parameter is a declarative parameter.
在提供/应答模型中，关键参数是声明性参数。
Session parameters are specific to a given transport and use of them is OPTIONAL in the security descriptions framework, where they are just defined as general character strings. If session parameters are to be used for a given transport, then transport-specific syntax and semantics MUST be provided in a Standards-Track RFC; definitions for SRTP are provided in Section 6.
会话参数是特定于给定传输的，在安全描述框架中使用它们是可选的，在安全描述框架中它们仅定义为通用字符串。如果会话参数将用于给定的传输，则必须在标准跟踪RFC中提供特定于传输的语法和语义；第6节提供了SRTP的定义。
In the offer/answer model, session parameters may be either negotiated or declarative; the definition of specific session parameters MUST indicate whether they are negotiated or declarative. Negotiated parameters apply to data sent in both directions, whereas declarative parameters apply only to media sent by the entity that generated the SDP. Thus, a declarative parameter in an offer applies to media sent by the offerer, whereas a declarative parameter in an answer applies to media sent by the answerer.
在提供/应答模型中，会话参数可以是协商的或声明的；特定会话参数的定义必须指明它们是协商的还是声明的。协商参数适用于双向发送的数据，而声明性参数仅适用于生成SDP的实体发送的媒体。因此，要约中的声明性参数适用于要约人发送的媒体，而应答中的声明性参数适用于应答人发送的媒体。
This example shows use of the crypto attribute for the "RTP/SAVP" media transport type (as defined in Section 5). The "a=crypto" line is actually one long line; it is shown as two lines due to page formatting.
此示例显示了对“RTP/SAVP”媒体传输类型（如第5节所定义）使用加密属性。“a=加密”行实际上是一条长行；由于页面格式的原因，它显示为两行。
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 161.44.17.12/127
t=2873397496 2873404696
m=video 51372 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=application 32416 udp wb
a=orient:portrait
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 161.44.17.12/127
t=2873397496 2873404696
m=video 51372 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=application 32416 udp wb
a=orient:portrait
This SDP message describes three media streams, two of which use the "RTP/SAVP" transport. Each has a crypto attribute for the "RTP/SAVP" transport. These secure-RTP specific descriptions are defined in Section 6.
此SDP消息描述了三个媒体流，其中两个使用“RTP/SAVP”传输。每个都有一个用于“RTP/SAVP”传输的加密属性。这些安全RTP特定描述在第6节中定义。
In this section, we describe the general use of the crypto attribute outside of any transport or key-method specific rules.
在本节中，我们将介绍加密属性在任何传输或密钥方法特定规则之外的一般用途。
The general offer/answer rules for the crypto attribute are in addition to the rules specified in RFC 3264, which MUST be followed, unless otherwise noted. RFC 3264 defines operation for both unicast and multicast streams; the sections below describe operation for two-party unicast streams only, since support for multicast streams (and multipoint unicast streams) is for further study.
加密属性的一般提供/应答规则是RFC 3264中规定的规则之外的规则，除非另有说明，否则必须遵守这些规则。RFC 3264定义单播和多播流的操作；以下各节仅描述两方单播流的操作，因为对多播流（和多点单播流）的支持有待进一步研究。
When generating an initial offer for a unicast stream, there MUST be one or more crypto attributes present for each media stream for which security is desired. Each crypto attribute for a given media stream MUST contain a unique tag.
当为单播流生成初始报价时，对于每个需要安全性的媒体流，必须存在一个或多个加密属性。给定媒体流的每个加密属性必须包含唯一的标记。
The ordering of multiple "a=crypto" lines is significant: the most preferred crypto line is listed first. Each crypto attribute describes the crypto-suite, key(s), and possibly session parameters offered for the media stream. In general, a "more preferred" crypto-suite SHOULD be cryptographically stronger than a "less preferred" crypto-suite.
多个“a=crypto”行的顺序非常重要：首先列出最首选的加密行。每个crypto属性描述为媒体流提供的加密套件、密钥以及可能的会话参数。一般来说，“更首选”的加密套件应该比“不太首选”的加密套件在加密方面更强。
The crypto-suite always applies to media in the directions supported by the media stream (e.g., send and receive). The key(s), however, apply to data packets (e.g., SRTP and SRTCP packets) that will be sent by the same party that generated the SDP. That is, each endpoint determines its own transmission keys and sends those keys, in SDP, to the other endpoint.
加密套件始终适用于媒体流支持的方向上的媒体（例如，发送和接收）。但是，密钥适用于将由生成SDP的同一方发送的数据包（例如，SRTP和SRTCP数据包）。也就是说，每个端点确定自己的传输密钥，并在SDP中将这些密钥发送到另一个端点。
This is done for consistency. Also, in the case of SRTP, for example, secure RTCP will still be flowing in both the send and receive direction for a unidirectional stream.
这样做是为了保持一致性。此外，例如，在SRTP的情况下，对于单向流，安全RTCP仍将在发送和接收方向上流动。
The inline parameter conveys the keying material used by an endpoint to encrypt the media streams transmitted by that endpoint. The same keying material is used by the recipient to decrypt those streams.
inline参数传递端点用于加密该端点传输的媒体流的密钥材料。收件人使用相同的密钥材料对这些流进行解密。
The offer may include session parameters. There are no general offer rules for the session parameters; instead, specific rules may be provided as part of the transport-specific definitions of any session parameters.
报价可能包括会话参数。会话参数没有通用的报价规则；相反，可以提供特定规则作为任何会话参数的特定于传输的定义的一部分。
When issuing an offer, the offerer MUST be prepared to support media security in accordance with any of the crypto attributes included in the offer. There are, however, two problems associated with this. First of all, the offerer does not know which key the answerer will be using for media sent to the offerer. Second, the offerer may not be able to deduce which of the offered crypto attributes were accepted. Since media may arrive prior to the answer, delay or clipping can occur. If this is unacceptable to the offerer, the offerer SHOULD use a mechanism outside the scope of this document to prevent the above problem.
在发出要约时，要约人必须准备根据要约中包含的任何加密属性支持媒体安全。然而，有两个问题与此相关。首先，发盘方不知道应答方将使用哪一个键作为发送给发盘方的媒体。第二，报价人可能无法推断哪些提供的加密属性被接受。由于媒体可能在回答之前到达，因此可能会发生延迟或剪辑。如果报价人不能接受，报价人应使用本文件范围以外的机制来防止上述问题。
For example, in SIP [RFC3261], a "security" precondition as defined in [sprecon] could solve the above problem.
例如，在SIP[RFC3261]中，[sprecon]中定义的“安全”前提条件可以解决上述问题。
When the answerer receives the initial offer with one or more crypto attributes for a given unicast media stream, the answerer MUST either accept exactly one of the offered crypto attributes, or the offered stream MUST be rejected.
当应答者接收到具有给定单播媒体流的一个或多个加密属性的初始要约时，应答者必须恰好接受所提供的加密属性中的一个，或者所提供的流必须被拒绝。
If the answerer wishes to indicate support for other crypto attributes, those can be listed by use of the SDP Simple Capability Declaration [RFC3407] extensions.
如果回答者希望表示支持其他加密属性，可以使用SDP简单功能声明[RFC3407]扩展来列出这些属性。
Only crypto attributes that are valid can be accepted; valid attributes do not violate any of the general rules defined for security descriptions, nor any specific rules defined for the transport and key-method in question. When selecting one of the valid crypto attributes, the answerer SHOULD select the most preferred crypto attribute it can support, i.e., the first valid supported crypto attribute in the list, according to the answerer's capabilities and security policies.
只能接受有效的加密属性；有效属性不违反为安全描述定义的任何一般规则，也不违反为相关传输和密钥方法定义的任何特定规则。当选择一个有效的加密属性时，应答者应根据应答者的能力和安全策略选择其能够支持的最首选加密属性，即列表中第一个有效的受支持加密属性。
If there are one or more crypto attributes in the offer, but none of them are valid or none of the valid ones are supported, the offered media stream MUST be rejected.
如果提供中有一个或多个加密属性，但这些属性均无效或不支持任何有效属性，则必须拒绝提供的媒体流。
When an offered crypto attribute is accepted, the crypto attribute in the answer MUST contain the following:
接受提供的加密属性时，答案中的加密属性必须包含以下内容：
* The tag and crypto-suite from the accepted crypto attribute in the offer (the same crypto-suite MUST be used in the send and receive direction).
* 来自报价中accepted crypto属性的标记和加密套件（发送和接收方向必须使用相同的加密套件）。
* The key(s) the answerer will be using for media sent to the offerer. Note that a key MUST be provided, irrespective of any direction attributes in the offer or answer.
* 回答者将用于发送给报价人的媒体的密钥。请注意，无论报价或答案中的任何方向属性如何，都必须提供钥匙。
Furthermore, any session parameters that are negotiated MUST be included in the answer. Declarative session parameters provided by the offerer are not included in the answer; however, the answerer may provide its own set of declarative session parameters.
此外，任何协商的会话参数都必须包含在答案中。报价人提供的声明性会话参数不包含在回答中；但是，应答者可以提供自己的一组声明性会话参数。
Once the answerer has accepted one of the offered crypto attributes, the answerer MAY begin sending media to the offerer in accordance with the selected crypto attribute. Note, however, that the offerer may not be able to process such media packets correctly until the answer has been received.
一旦应答者已接受所提供的加密属性之一，应答者可根据所选择的加密属性开始向报价者发送媒体。然而，请注意，在收到答复之前，报价人可能无法正确处理此类媒体分组。
When the offerer receives the answer, the offerer MUST verify that one of the initially offered crypto suites and its accompanying tag were accepted and echoed in the answer. Also, the answer MUST include one or more keys, which will be used for media sent from the answerer to the offerer.
当报价人收到答复时，报价人必须验证最初提供的加密套件之一及其附带标签是否已被接受并在答复中得到响应。此外，答案必须包括一个或多个键，用于回答者发送给报价者的媒体。
If the offer contained any mandatory negotiated session parameters (see Section 6.3.7), the offerer MUST verify that said parameters are included in the answer and support them. If the answer contains any mandatory declarative session parameters, the offerer MUST be able to support those.
如果要约包含任何强制性协商会话参数（见第6.3.7节），则要约人必须验证上述参数是否包含在回答中并予以支持。如果答案包含任何强制性声明性会话参数，则报价人必须能够支持这些参数。
If any of the above fails, the negotiation MUST fail.
如果上述任何一项失败，谈判必须失败。
Once a media stream has been established, it MAY be modified at any time, as described in RFC 3264, Section 8. Such a modification MAY be triggered by the security service, e.g., in order to perform a re-keying or change the crypto-suite. If media stream security using the general security descriptions defined here is still desired, the crypto attribute MUST be included in these new offer/answer exchanges. The procedures are similar to those defined in Section 5.1.1, 5.1.2, and 5.1.3 of this document, subject to the considerations provided in RFC 3264, Section 8.
一旦建立了媒体流，就可以随时对其进行修改，如RFC 3264第8节所述。此类修改可由安全服务触发，例如，为了执行密钥更新或更改加密套件。如果仍然需要使用此处定义的一般安全性描述的媒体流安全性，则必须在这些新的提供/应答交换中包括加密属性。程序与本文件第5.1.1节、第5.1.2节和第5.1.3节中定义的程序相似，但需考虑RFC 3264第8节中规定的因素。
The crypto attribute can also be used outside the context of offer/answer where there is no negotiation of the crypto suite, cryptographic key, or session parameters. In this case, the sender determines security parameters for the stream. Since there is no negotiation mechanism, the sender MUST include exactly one crypto attribute, and the receiver MUST either accept it or SHOULD NOT
crypto属性也可以在提供/应答上下文之外使用，其中不存在加密套件、加密密钥或会话参数的协商。在这种情况下，发送方确定流的安全参数。由于没有协商机制，发送方必须只包含一个加密属性，接收方必须接受或不接受该属性
receive the associated stream. The sender SHOULD select the security description that it deems most secure for its purposes.
接收相关联的流。发送方应选择其认为最安全的安全描述。
In the offer/answer model, it is possible that the answerer supports a given secure transport (e.g., "RTP/SAVP") and accepts the offered media stream, but that the answerer does not support the crypto attribute defined in this document and hence ignores it. The offerer can recognize this situation by seeing an accepted media stream in the answer that does not include a crypto line. In that case, the security negotiation defined here MUST fail.
在提供/应答模型中，应答者可能支持给定的安全传输（例如，“RTP/SAVP”）并接受提供的媒体流，但应答者不支持本文档中定义的加密属性，因此忽略它。报价人可以通过在答案中看到不包含加密线路的可接受媒体流来识别这种情况。在这种情况下，此处定义的安全协商必须失败。
Similar issues exist when security descriptions are used outside the offer/answer model. But the source of a non-negotiated security description has no indication that the receiver has ignored the crypto attribute.
当在提供/应答模型之外使用安全描述时，也存在类似的问题。但是，非协商安全描述的来源没有表明接收方忽略了加密属性。
In this section, we provide definitions for security descriptions for SRTP media streams. In the next section, we define how to use SRTP security descriptions with and without the offer/answer model.
在本节中，我们将为SRTP媒体流的安全性描述提供定义。在下一节中，我们将定义如何使用SRTP安全性描述（有和没有提供/应答模型）。
SRTP security descriptions MUST only be used with the SRTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security descriptions for the "RTP/SAVP" profile, defined in [RFC3711]. However, it is expected that other secure RTP profiles (e.g., "RTP/SAVPF") can use the same descriptions, which are in accordance with the SRTP protocol specification [RFC3711].
SRTP安全描述只能与SRTP传输一起使用（例如，“RTP/SAVP”或“RTP/SAVPF”）。以下规定了[RFC3711]中定义的“RTP/SAVP”配置文件的安全说明。然而，预计其他安全RTP配置文件（例如，“RTP/SAVPF”）可以使用相同的描述，这些描述符合SRTP协议规范[RFC3711]。
There is no assurance that an endpoint is capable of configuring its SRTP service with a particular crypto attribute parameter, but SRTP guarantees minimal interoperability among SRTP endpoints through the default SRTP parameters [RFC3711]. More capable SRTP endpoints support a variety of parameter values beyond the SRTP defaults, and these values can be configured by the SRTP security descriptions defined here. An endpoint that does not support the crypto attribute will ignore it according to the SDP. Such an endpoint will not correctly process the particular media stream. By using the Offer/Answer model, the offerer and answerer can negotiate the crypto parameters to be used before commencement of the multimedia session (see Section 7.1).
无法保证端点能够使用特定的加密属性参数配置其SRTP服务，但SRTP通过默认SRTP参数保证SRTP端点之间的最小互操作性[RFC3711]。功能更强的SRTP端点支持SRTP默认值之外的各种参数值，这些值可以通过此处定义的SRTP安全性描述进行配置。根据SDP，不支持crypto属性的端点将忽略它。这样的端点将无法正确处理特定的媒体流。通过使用要约/应答模型，要约人和应答人可以在多媒体会话开始前协商要使用的加密参数（见第7.1节）。
There are over twenty cryptographic parameters listed in the SRTP specification. Many of these parameters have fixed values for particular cryptographic transforms. At the time of session establishment, however, there is usually no need to provide unique
SRTP规范中列出了20多个加密参数。对于特定的加密转换，其中许多参数都有固定值。但是，在会话建立时，通常不需要提供唯一的
settings for many of the SRTP parameters, such as salt length and pseudo-random function (PRF). Thus, it is possible to simplify the list of parameters by defining "cryptographic suites" that fix a set of SRTP parameter values for the security session. This approach is followed by the SRTP security descriptions, which uses the general security description parameters as follows:
许多SRTP参数的设置，如盐长度和伪随机函数（PRF）。因此，可以通过定义“加密套件”来简化参数列表，该套件为安全会话修复一组SRTP参数值。此方法之后是SRTP安全描述，它使用一般安全描述参数，如下所示：
* crypto-suite: Identifies the encryption and authentication transforms. * key parameter: SRTP keying material and parameters * session parameters: The following parameters are defined: - KDR: The SRTP Key Derivation Rate is the rate at which a pseudo-random function is applied to a master key. - UNENCRYPTED_SRTP: SRTP messages are not encrypted. - UNENCRYPTED_SRTCP: SRTCP messages are not encrypted. - UNAUTHENTICATED_SRTP: SRTP messages are not authenticated. - FEC_ORDER: Order of forward error correction (FEC) relative to SRTP services. - FEC_KEY: Master Key for FEC when the FEC stream is sent to a separate address and/or port. - WSH: Window Size Hint. - Extensions: Extension parameters can be defined.
* 加密套件：标识加密和身份验证转换。*密钥参数：SRTP密钥材料和参数*会话参数：定义了以下参数：-KDR：SRTP密钥派生率是将伪随机函数应用于主密钥的速率。-未加密的\u SRTP:SRTP消息未加密。-未加密的\u SRTCP:SRTCP消息未加密。-未经身份验证的\u SRTP:SRTP消息未经身份验证。-FEC_顺序：相对于SRTP服务的前向纠错（FEC）顺序。-FEC_密钥：当FEC流被发送到单独的地址和/或端口时，FEC的主密钥。-WSH：窗口大小提示。-扩展：可以定义扩展参数。
Please refer to the SRTP specification for a complete list of parameters and their descriptions [Section 8.2, srtp]. Regarding the UNENCRYPTED_SRTCP parameter, offerers and answerers of SDP security descriptions MUST NOT use the SRTCP E-bit to override UNENCRYPTED_SRTCP or the default, which is to encrypt all SRTCP messages (see Section 6.3.2). The key parameter, the crypto-suite, and the session parameters shown above are described in detail in the following subsections.
有关完整的参数列表及其说明，请参考SRTP规范[第8.2节，SRTP]。关于UNENCRYPTED_SRTCP参数，SDP安全描述的提供方和应答方不得使用SRTCP E位覆盖UNENCRYPTED_SRTCP或默认值，即加密所有SRTCP消息（见第6.3.2节）。下面的小节将详细描述上面显示的密钥参数、加密套件和会话参数。
SRTP security descriptions define the use of the "inline" key method as described in the following. Use of any other keying method (e.g., URL) for SRTP security descriptions is for further study.
SRTP安全描述定义了“内联”密钥方法的使用，如下所述。对SRTP安全性描述使用任何其他键控方法（如URL）有待进一步研究。
The "inline" type of key contains the keying material (master key and salt) and all policy related to that master key, including how long it can be used (lifetime) and whether it uses a master key identifier (MKI) to associate an incoming SRTP packet with a particular master key. Compliant implementations obey the policies associated with a master key and MUST NOT accept incoming packets that violate the policy (e.g., after the master key lifetime has expired).
“内联”类型的密钥包含密钥材料（主密钥和salt）以及与该主密钥相关的所有策略，包括可以使用多长时间（生命周期）以及是否使用主密钥标识符（MKI）将传入的SRTP数据包与特定主密钥相关联。兼容实现遵守与主密钥相关联的策略，并且不得接受违反该策略的传入数据包（例如，在主密钥生存期过期之后）。
The key parameter contains one or more cryptographic master keys, each of which MUST be a unique cryptographically random [RFC1750]
key参数包含一个或多个加密主密钥，每个主密钥必须是唯一的加密随机密钥[RFC1750]
value with respect to other master keys in the entire SDP message (i.e., including master keys for other streams). Each key follows the format (the formal definition is provided in Section 9.2):
与整个SDP消息中的其他主密钥相关的值（即，包括其他流的主密钥）。每个键都遵循以下格式（正式定义见第9.2节）：
"inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length]
"inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length]
key||salt concatenated master key and salt, base64 encoded (see [RFC3548], Section 3) lifetime master key lifetime (max number of SRTP or SRTCP packets using this master key) MKI:length MKI and length of the MKI field in SRTP packets
密钥| | salt级联主密钥和salt，base64编码（参见[RFC3548]，第3节）生存期主密钥生存期（使用此主密钥的SRTP或SRTCP数据包的最大数量）MKI：长度MKI和SRTP数据包中MKI字段的长度
The following definition provides an example for AES_CM_128_HMAC_SHA1_80:
以下定义提供了AES_CM_128_HMAC_SHA1_80的示例：
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4
The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the parameter is the cryptographic master key appended with the master salt; the two are first concatenated and then base64 encoded. The length of the concatenated key and salt is determined by the crypto-suite for which the key applies. If the length (after being decoded from base64) does not match that specified for the crypto-suite, the crypto attribute in question MUST be considered invalid. Each master key and salt MUST be a cryptographically random number and MUST be unique to the entire SDP message. When base64 decoding the key and salt, padding characters (i.e., one or two "=" at the end of the base64-encoded data) are discarded (see [RFC3548] for details). Base64 encoding assumes that the base64 encoding input is an integral number of octets. If a given crypto-suite requires the use of a concatenated key and salt with a length that is not an integral number of octets, said crypto-suite MUST define a padding scheme that results in the base64 input being an integral number of octets. For example, if the length defined were 250 bits, then 6 padding bits would be needed, which could be defined to be the last 6 bits in a 256 bit input.
参数的第一个字段（“d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj”）是附加主密钥的加密主密钥；这两个函数首先连接起来，然后进行base64编码。连接密钥和salt的长度由密钥应用的加密套件决定。如果长度（从base64解码后）与为crypto suite指定的长度不匹配，则必须认为有问题的crypto属性无效。每个主密钥和salt必须是一个加密随机数，并且对于整个SDP消息必须是唯一的。当base64解码密钥和salt时，将丢弃填充字符（即base64编码数据末尾的一个或两个“=”）（有关详细信息，请参阅[RFC3548]）。Base64编码假定Base64编码输入是八位字节的整数。如果给定的加密套件需要使用长度不是整数个八位字节的级联密钥和salt，则所述加密套件必须定义一个填充方案，该填充方案导致base64输入为整数个八位字节。例如，如果定义的长度为250位，则需要6个填充位，可以将其定义为256位输入中的最后6位。
The second field is the OPTIONAL lifetime of the master key as measured in maximum number of SRTP or SRTCP packets using that master key (i.e., the number of SRTP packets and the number of SRTCP packets each have to be less than the lifetime). The lifetime value MAY be written as a non-zero, positive decimal integer or as a power of 2 (see the grammar in Section 9.2 for details); leading zeroes MUST NOT be used. The "lifetime" value MUST NOT exceed the maximum packet lifetime for the crypto-suite. If the lifetime is too large or otherwise invalid, then the entire crypto attribute MUST be considered invalid. The default MAY be implicitly signaled by omitting the lifetime (note that the lifetime field never includes a
第二个字段是主密钥的可选生存期，以使用该主密钥的SRTP或SRTCP数据包的最大数量来衡量（即，SRTP数据包的数量和SRTCP数据包的数量都必须小于生存期）。寿命值可以写成非零的正十进制整数或2的幂（详见第9.2节的语法）；不得使用前导零。“生存期”值不得超过加密套件的最大数据包生存期。如果生存期过大或无效，则必须将整个crypto属性视为无效。默认值可以通过省略生存期隐式表示（注意，生存期字段从不包括
colon, whereas the third field always does). This is convenient when the SRTP cryptographic key lifetime is the default value. As a shortcut to avoid long decimal values, the syntax of the lifetime allows using the literal "2^", which indicates "two to the power of". The example above shows a case where the lifetime is specified as 2^20. The following example, which is for the AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default for the lifetime field, which means that SRTP's and SRTCP's default values will be used (see [RFC3711]):
冒号，而第三个字段总是冒号）。当SRTP加密密钥生存期为默认值时，这很方便。作为避免长十进制值的快捷方式，生存期的语法允许使用文字“2^”，表示“2的幂”。上面的示例显示了将生存期指定为2^20的情况。以下示例适用于AES_CM_128_HMAC_SHA1_80加密套件，其寿命字段具有默认值，这意味着将使用SRTP和SRTCP的默认值（请参见[RFC3711]）：
inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2|1066:4
内联：YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2 | 1066:4
The example shows a 30-octet key and concatenated salt that is base64 encoded: The 30-octet key/salt concatenation is expanded to 40 characters (octets) by the three-in-four encoding of base64.
该示例显示了一个30个八位字节的密钥和base64编码的级联salt：通过base64的四分之三编码，30个八位字节的密钥/salt级联扩展为40个字符（八位字节）。
The third field, which is also OPTIONAL, is the Master Key Identifier (MKI) and its byte length.
第三个字段也是可选的，它是主密钥标识符（MKI）及其字节长度。
"MKI" is the master key identifier associated with the SRTP master key. The MKI is here defined as a positive decimal integer that is encoded as a big-endian integer in the actual SRTP packets; leading zeroes MUST NOT be used in the integer representation. If the MKI is given, then the length of the MKI MUST also be given and separated from the MKI by a colon (":"). The MKI length is the size of the MKI field in the SRTP packet, specified in bytes as a decimal integer; leading zeroes MUST NOT be used. If the MKI length is not given or its value exceeds 128 (bytes), then the entire crypto attribute MUST be considered invalid. The substring "1:4" in the first example assigns to the key a master key identifier of 1 that is 4 bytes long, and the second example assigns a 4-byte master key identifier of 1066 to the key. One or more master keys with their associated MKI can be initially defined, and then later updated, or deleted and new ones defined.
“MKI”是与SRTP主密钥相关联的主密钥标识符。MKI在此定义为正十进制整数，其在实际SRTP分组中编码为大端整数；整数表示形式中不得使用前导零。如果给出了MKI，则还必须给出MKI的长度，并用冒号（“：”）与MKI隔开。在数据包长度字段MKI中指定为整数字节的数据包大小；不得使用前导零。如果未给出MKI长度或其值超过128（字节），则必须将整个crypto属性视为无效。第一个示例中的子字符串“1:4”将4字节长的主密钥标识符1分配给密钥，第二个示例将4字节主密钥标识符1066分配给密钥。一个或多个主密钥及其关联的MKI可以最初定义，然后更新，或删除并定义新的主密钥。
SRTP offers a second feature for specifying the lifetime of a master key in terms of two values, called "From" and "To," which are defined on the SRTP sequence number space [RFC3711]. This SRTP Security Descriptions specification, however, does not support the <"From", "To"> feature since the lifetime of an AES master key is 2^48 SRTP packets, which means that there is no cryptographic reason to replace a master key for practical point-to-point applications. For this reason, there is no need to support two means for signaling key update. The MKI is chosen over <"From", "To"> by this specification for the very few applications that need it since the MKI feature is simpler (though the MKI adds additional bytes to each packet, whereas <"From", "To"> does not).
SRTP提供了第二个功能，用于根据在SRTP序列号空间[RFC3711]上定义的两个值“From”和“To”指定主密钥的生存期。但是，本SRTP安全说明规范不支持<“从”、“到”>功能，因为AES主密钥的生存期为2^48 SRTP数据包，这意味着对于实际的点到点应用，没有密码理由替换主密钥。因此，不需要支持两种发送密钥更新信号的方法。由于MKI功能更简单（尽管MKI会向每个数据包添加额外的字节，而<“从”、“到”>不会），因此本规范为需要MKI的应用程序选择了<“从”、“到”>。
As mentioned above, the key parameter can contain one or more master keys. When the key parameter contains more than one master key, all the master keys in that key parameter MUST include an MKI value.
如上所述，key参数可以包含一个或多个主密钥。当密钥参数包含多个主密钥时，该密钥参数中的所有主密钥必须包含MKI值。
When using the MKI, the MKI length MUST be the same for all keys in a given crypto attribute.
使用MKI时，给定加密属性中所有密钥的MKI长度必须相同。
The SRTP crypto-suites define the encryption and authentication transforms to be used for the SRTP media stream. The SRTP specification has defined three crypto-suites, which are described further in the following subsections in the context of the SRTP security descriptions. The table below provides an overview of the crypto-suites and their parameters:
SRTP加密套件定义用于SRTP媒体流的加密和身份验证转换。SRTP规范定义了三个加密套件，以下小节将在SRTP安全描述的上下文中对其进行进一步描述。下表概述了加密套件及其参数：
+---------------------+-------------+--------------+---------------+
| |AES_CM_128_ | AES_CM_128_ | F8_128_ |
| |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 |
+---------------------+-------------+--------------+---------------+
| Master key length | 128 bits | 128 bits | 128 bits |
| Master salt length | 112 bits | 112 bits | 112 bits |
| SRTP lifetime | 2^48 packets| 2^48 packets | 2^48 packets |
| SRTCP lifetime | 2^31 packets| 2^31 packets | 2^31 packets |
| Cipher | AES Counter | AES Counter | AES F8 Mode |
| | Mode | Mode | |
| Encryption key | 128 bits | 128 bits | 128 bits |
| MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 |
| SRTP auth. tag | 80 bits | 32 bits | 80 bits |
| SRTCP auth. tag | 80 bits | 80 bits | 80 bits |
| SRTP auth. key len. | 160 bits | 160 bits | 160 bits |
| SRTCP auth. key len.| 160 bits | 160 bits | 160 bits |
+---------------------+-------------+--------------+---------------+
+---------------------+-------------+--------------+---------------+
| |AES_CM_128_ | AES_CM_128_ | F8_128_ |
| |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 |
+---------------------+-------------+--------------+---------------+
| Master key length | 128 bits | 128 bits | 128 bits |
| Master salt length | 112 bits | 112 bits | 112 bits |
| SRTP lifetime | 2^48 packets| 2^48 packets | 2^48 packets |
| SRTCP lifetime | 2^31 packets| 2^31 packets | 2^31 packets |
| Cipher | AES Counter | AES Counter | AES F8 Mode |
| | Mode | Mode | |
| Encryption key | 128 bits | 128 bits | 128 bits |
| MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 |
| SRTP auth. tag | 80 bits | 32 bits | 80 bits |
| SRTCP auth. tag | 80 bits | 80 bits | 80 bits |
| SRTP auth. key len. | 160 bits | 160 bits | 160 bits |
| SRTCP auth. key len.| 160 bits | 160 bits | 160 bits |
+---------------------+-------------+--------------+---------------+
AES_CM_128_HMAC_SHA1_80 is the SRTP default AES Counter Mode cipher and HMAC-SHA1 message authentication with an 80-bit authentication tag. The master-key length is 128 bits and has a default lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first [Page 39, srtp].
AES_CM_128_HMAC_SHA1_80是SRTP默认的AES计数器模式密码和HMAC-SHA1消息身份验证，带有80位身份验证标签。主密钥长度为128位，默认生存期最多为2^48 SRTP数据包或2^31 SRTCP数据包，以先到者为准[第39页，SRTP]。
SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first. However, it is RECOMMENDED that automated key management allow easy and efficient rekeying at intervals far smaller than 2^31 packets given today's media rates or even HDTV media rates.
SRTP允许2^48个SRTP数据包或2^31个SRTCP数据包，以先到者为准。但是，鉴于当今的媒体速率甚至HDTV媒体速率，建议自动密钥管理允许以远小于2^31数据包的间隔轻松高效地重新设置密钥。
The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP and SRTCP authentication key lengths are 160 bits (see Security Considerations in Section 8). The master salt value is 112 bits in length and the session salt value is 112 bits in length. The pseudo-random function (PRF) is the default SRTP pseudo-random function that uses AES Counter Mode with a 128-bit key length.
SRTP和SRTCP加密密钥长度为128位。SRTP和SRTCP认证密钥长度为160位（请参阅第8节中的安全注意事项）。主盐值的长度为112位，会话盐值的长度为112位。伪随机函数（PRF）是默认的SRTP伪随机函数，它使用具有128位密钥长度的AES计数器模式。
The length of the base64-decoded key and salt value for this crypto-suite MUST be 30 characters (i.e., 240 bits); otherwise, the crypto attribute is considered invalid.
此加密套件的base64解码密钥和salt值的长度必须为30个字符（即240位）；否则，加密属性将被视为无效。
This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except that the authentication tag is 32 bits.
此加密套件与AES_CM_128_HMAC_SHA1_80相同，只是身份验证标签为32位。
The length of the base64-decoded key and salt value for this crypto-suite MUST be 30 octets i.e., 240 bits; otherwise, the crypto attribute is considered invalid.
此加密套件的base64解码密钥和salt值的长度必须为30个八位字节，即240位；否则，加密属性将被视为无效。
This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except that the cipher is F8 [RFC3711].
该密码套件与AES_CM_128_HMAC_SHA1_80相同，只是密码为F8[RFC3711]。
The length of the base64-decoded key and salt value for this crypto-suite MUST be 30 octets, i.e., 240 bits; otherwise the crypto attribute is considered invalid.
此加密套件的base64解码密钥和salt值的长度必须为30个八位字节，即240位；否则，加密属性将被视为无效。
If new transforms are added to SRTP, new definitions for those transforms SHOULD be given for the SRTP security descriptions and published in a Standards-Track RFC. Sections 6.2.1 through 6.2.3 illustrate how to define crypto-suite values for particular cryptographic transforms. Any new crypto-suites MUST be registered with IANA following the procedures in Section 10.
如果向SRTP添加了新的转换，则应为SRTP安全描述提供这些转换的新定义，并在标准跟踪RFC中发布。第6.2.1节至第6.2.3节说明了如何为特定加密转换定义加密套件值。任何新的加密套件必须按照第10节中的程序向IANA注册。
SRTP security descriptions define a set of "session" parameters, which OPTIONALLY may be used to override SRTP session defaults for the SRTP and SRTCP streams. These parameters configure an RTP session for SRTP services. The session parameters provide session-specific information to establish the SRTP cryptographic context.
SRTP安全描述定义了一组“会话”参数，可以选择使用这些参数覆盖SRTP和SRTCP流的SRTP会话默认值。这些参数为SRTP服务配置RTP会话。会话参数提供特定于会话的信息，以建立SRTP加密上下文。
KDR specifies the Key Derivation Rate, as described in Section 4.3.1 of [RFC3711].
KDR指定密钥派生率，如[RFC3711]第4.3.1节所述。
The value n MUST be a decimal integer in the set {1,2,...,24}, which denotes a power of 2 from 2^1 to 2^24, inclusive; leading zeroes MUST NOT be used. The SRTP key derivation rate controls how frequently a new session key is derived from an SRTP master key(s) [RFC3711] given in the declaration. When the key derivation rate is not specified (i.e., the KDR parameter is omitted), a single initial key derivation is performed [RFC3711].
值n必须是集合{1,2，…，24}中的十进制整数，表示从2^1到2^24（含2^24）的2的幂；不得使用前导零。SRTP密钥派生率控制从声明中给出的SRTP主密钥[RFC3711]派生新会话密钥的频率。当未指定密钥推导速率（即，省略KDR参数）时，执行单个初始密钥推导[RFC3711]。
In the offer/answer model, KDR is a declarative parameter.
在提供/应答模型中，KDR是一个声明性参数。
SRTP and SRTCP packet payloads are encrypted by default. The UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the default behavior of the crypto-suites with which they are used:
默认情况下，SRTP和SRTCP数据包有效负载是加密的。UNENCRYPTED_SRTCP和UNENCRYPTED_SRTP会话参数修改使用它们的加密套件的默认行为：
* UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not encrypted.
* 未加密的\u SRTCP表示SRTCP数据包有效负载未加密。
* UNENCRYPTED_SRTP signals that the SRTP packet payloads are not encrypted.
* 未加密的\u SRTP表示SRTP数据包有效载荷未加密。
In the offer/answer model, these parameters are negotiated. If UNENCRYPTED_SRTCP is signaled for the session, then the SRTCP E bit MUST be clear (0) in all SRTCP messages. If the default is used, all SRTCP messages are encrypted, and the E bit MUST be set (1) on all SRTCP messages.
在报价/应答模型中，这些参数是协商的。如果为会话发送未加密的\u SRTCP信号，则所有SRTCP消息中的SRTCP E位必须为清除（0）。如果使用默认值，则所有SRTCP消息都将加密，并且必须在所有SRTCP消息上设置（1）E位。
SRTP and SRTCP packet payloads are authenticated by default. The UNAUTHENTICATED_SRTP session parameter signals that SRTP messages are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT RECOMMENDED (see Security Considerations).
默认情况下，对SRTP和SRTCP数据包有效负载进行身份验证。UNAUTHENTICATED_SRTP session参数表示SRTP消息未经身份验证。不建议使用未经验证的_SRTP（请参阅安全注意事项）。
The SRTP specification requires use of message authentication for SRTCP, but not for SRTP [RFC3711].
SRTP规范要求对SRTCP使用消息身份验证，但不要求对SRTP使用消息身份验证[RFC3711]。
In the offer/answer model, this parameter is negotiated.
在报价/应答模型中，此参数是协商的。
FEC_ORDER signals the use of forward error correction for the RTP packets [RFC2733]. The forward error correction values for "order" are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied before SRTP processing by the sender of the SRTP media and after SRTP processing by the receiver of the SRTP media; FEC_SRTP is the default. SRTP_FEC is the reverse processing.
FEC_顺序指示对RTP数据包使用前向纠错[RFC2733]。“order”的前向纠错值为FEC_SRTP或SRTP_FEC。FEC_SRTP表示在SRTP媒体的发送方进行SRTP处理之前和SRTP媒体的接收方进行SRTP处理之后应用了FEC；FEC_SRTP是默认值。SRTP_FEC是反向处理。
In the offer/answer model, FEC_ORDER is a declarative parameter.
在offer/answer模型中，FEC_ORDER是一个声明性参数。
FEC_KEY signals the use of separate master key(s) for a Forward Error Correction (FEC) stream. The master key(s) are specified with the exact same format as the SRTP Key Parameter defined in Section 6.1, and the semantic rules are the same - in particular, the master key(s) MUST be different from all other master key(s) in the SDP. An FEC_KEY MUST be specified when the FEC stream is sent to a different IP-address and/or port than the media stream to which it applies (i.e., the "m=" line), e.g., as described in RFC 2733, Section 11.1. When an FEC stream is sent to the same IP-address and port as the media stream to which it applies, an FEC_KEY MUST NOT be specified. If an FEC_KEY is specified in this latter case, the crypto attribute in question MUST be considered invalid.
FEC_密钥表示前向纠错（FEC）流使用单独的主密钥。主密钥的指定格式与第6.1节中定义的SRTP密钥参数完全相同，语义规则也相同，尤其是主密钥必须不同于SDP中的所有其他主密钥。当FEC流被发送到与其应用的媒体流（即“m=”行）不同的IP地址和/或端口时，必须指定FEC_密钥，如RFC 2733第11.1节所述。当FEC流被发送到与其应用的媒体流相同的IP地址和端口时，不得指定FEC_密钥。如果在后一种情况下指定了FEC_密钥，则相关的加密属性必须视为无效。
In the offer/answer model, FEC_KEY is a declarative parameter.
在提供/应答模型中，FEC_KEY是一个声明性参数。
SRTP defines the SRTP-WINDOW-SIZE [RFC3711, Section 3.3.2] parameter to protect against replay attacks. The minimum value is 64 [RFC3711]; however, this value may be considered too low for some applications (e.g., video).
SRTP定义了SRTP-WINDOW-SIZE[RFC3711，第3.3.2节]参数，以防止重播攻击。最小值为64[RFC3711]；但是，对于某些应用（例如视频），该值可能被认为太低。
The Window Size Hint (WSH) session parameter provides a hint for how big this window should be to work satisfactorily (e.g., based on sender knowledge of the number of packets per second). However, there might be enough information given in SDP attributes like "a=maxprate" [maxprate] and the bandwidth modifiers to allow a receiver to derive the parameter satisfactorily. Consequently, this value is only considered a hint to the receiver of the SDP that MAY choose to ignore the value provided. The value is a decimal integer; leading zeroes MUST NOT be used.
Window Size Hint（WSH）session参数提供了一个提示，说明此窗口应该有多大才能令人满意地工作（例如，基于发送方对每秒数据包数量的了解）。然而，SDP属性（如“a=maxprate”[maxprate]和带宽修饰符）中可能提供了足够的信息，以允许接收机满意地导出参数。因此，该值仅被视为对SDP的接收者的提示，该接收者可能选择忽略提供的值。该值为十进制整数；不得使用前导零。
In the offer/answer model, WSH is a declarative parameter.
在提供/应答模型中，WSH是一个声明性参数。
New SRTP session parameters for the SRTP security descriptions can be defined in a Standards-Track RFC and registered with IANA according to the registration procedures defined in Section 10.
SRTP安全描述的新SRTP会话参数可以在标准跟踪RFC中定义，并根据第10节中定义的注册程序向IANA注册。
New SRTP session parameters are by default mandatory. A newly defined SRTP session parameter that is prefixed with the dash character ("-"), however, is considered optional and MAY be ignored. If an SDP crypto attribute is received with an unknown session parameter that is not prefixed with a "-" character, that crypto attribute MUST be considered invalid.
默认情况下，新的SRTP会话参数是必需的。但是，新定义的以短划线字符（“-”）为前缀的SRTP会话参数被视为可选参数，可以忽略。如果接收到的SDP加密属性带有未知会话参数，且该参数的前缀不是“-”字符，则该加密属性必须视为无效。
In addition to the various SRTP parameters defined above, there are three pieces of information that are critical to the operation of the default SRTP ciphers:
除了上面定义的各种SRTP参数外，还有三条信息对默认SRTP密码的操作至关重要：
* SSRC: Synchronization source * ROC: Roll-over counter for a given SSRC * SEQ: Sequence number for a given SSRC
* SSRC:同步源*ROC:给定SSRC的滚动计数器*SEQ:给定SSRC的序列号
In a unicast session, as defined here, there are three constraints on these values.
在这里定义的单播会话中，这些值有三个约束。
The first constraint is on the SSRC, which makes an SRTP keystream unique from other participants. As explained in SRTP, the keystream MUST NOT be reused on two or more different pieces of plaintext. Keystream reuse makes the ciphertext vulnerable to cryptanalysis. One vulnerability is that known-plaintext fields in one stream can expose portions of the reused keystream, and this could further expose more plaintext in other streams. Since all current SRTP encryption transforms use keystreams, key sharing is a general problem [RFC3711]. SRTP mitigates this problem by including the SSRC of the sender in the keystream. But SRTP does not solve this problem in its entirety because the Real-time Transport Protocol has SSRC collisions, which although very rare [RFC3550] are quite possible. During a collision, two or more SSRCs that share a master key will have identical keystreams for overlapping portions of the RTP sequence number space. SRTP Security Descriptions avoid keystream reuse by making unique master keys REQUIRED for the sender and receiver of the security description. Thus, the first constraint is satisfied.
第一个约束是SSRC，这使得SRTP密钥流与其他参与者不同。正如在SRTP中所解释的，密钥流不能在两个或多个不同的明文段上重复使用。密钥流重用使得密文容易受到密码分析的攻击。一个漏洞是，一个流中的已知明文字段可能会暴露重用密钥流的一部分，这可能会进一步在其他流中暴露更多明文。由于当前所有SRTP加密转换都使用密钥流，因此密钥共享是一个普遍问题[RFC3711]。SRTP通过在密钥流中包含发送方的SSRC来缓解此问题。但SRTP并不能完全解决这个问题，因为实时传输协议存在SSRC冲突，尽管这种冲突非常罕见[RFC3550]，但还是有可能发生的。在冲突期间，共享主密钥的两个或多个SSRC将具有RTP序列号空间重叠部分的相同密钥流。SRTP安全描述通过生成安全描述的发送方和接收方所需的唯一主密钥来避免密钥流重用。因此，满足第一个约束。
Also note that there is a second problem with SSRC collisions: the SSRC is used to identify the crypto context and thereby the cipher, key, ROC, etc. to process incoming packets. In case of
还要注意，SSRC冲突还有第二个问题：SSRC用于识别加密上下文，从而识别密码、密钥、ROC等，以处理传入的数据包。万一
SSRC collisions, crypto context identification becomes ambiguous and correct packet processing may not occur. Furthermore, if an RTCP BYE packet is to be sent for a colliding SSRC, that packet may also have to be secured. In a (unicast) point-to-multipoint scenario, this can be problematic for the same reasons, i.e., it is not known which of the possible crypto contexts to use. Note that these problems are not unique to the SDP security descriptions; any use of SRTP needs to consider them.
SSRC冲突、加密上下文标识变得模糊，可能无法进行正确的数据包处理。此外，如果要为发生冲突的SSRC发送RTCP BYE数据包，则该数据包可能也必须得到保护。在（单播）点对多点场景中，由于同样的原因，这可能会有问题，即不知道使用哪种可能的加密上下文。请注意，这些问题并非SDP安全描述所独有；SRTP的任何使用都需要考虑它们。
The second constraint is that the ROC MUST be zero at the time that each SSRC commences sending packets. Thus, there is no concept of a "late joiner" in SRTP security descriptions, which are constrained to be unicast and pairwise. The ROC and SEQ form a "packet index" in the default SRTP transforms and the ROC is consistently set to zero at session commencement, according to this document.
第二个约束是，在每个SSRC开始发送数据包时，ROC必须为零。因此，在SRTP安全描述中没有“延迟加入者”的概念，这些安全描述被限制为单播和成对。根据本文档，ROC和SEQ在默认SRTP转换中形成“数据包索引”，并且ROC在会话开始时始终设置为零。
The third constraint is that the initial value of SEQ SHOULD be chosen to be within the range of 0..2^15-1; this avoids an ambiguity when packets are lost at the start of the session. If it is at the start of a session, an SSRC source might randomly select a high sequence-number value and put the receiver in an ambiguous situation: if initial packets are lost in transit up to the point that the sequence number wraps (i.e., exceeds 2^16-1), then the receiver might not recognize that its ROC needs to be incremented. By restricting the initial SEQ to the range of 0..2^15-1, SRTP packet-index determination will find the correct ROC value, unless all the first 2^15 packets are lost (which seems, if not impossible, rather unlikely). See Section 3.3.1 of the SRTP specification regarding packet-index determination [RFC3711].
第三个约束条件是，SEQ的初始值应选择在0..2^15-1的范围内；这避免了在会话开始时数据包丢失时出现歧义。如果是在会话开始时，SSRC源可能会随机选择一个高序列号值，并使接收器处于不明确的情况：如果初始数据包在传输过程中丢失，直到序列号换行（即，超过2^16-1），则接收器可能无法识别其ROC需要增加。通过将初始SEQ限制在0..2^15-1的范围内，SRTP分组索引确定将找到正确的ROC值，除非所有前2^15个分组都丢失（如果不是不可能的话，这似乎不太可能）。关于包索引确定[RFC3711]，参见SRTP规范第3.3.1节。
The packet index, therefore, depends on the SSRC, the SEQ of an incoming packet, and the ROC, which is an SRTP crypto context variable. Thus, SRTP has a big security dependency on SSRC uniqueness.
因此，包索引取决于SSRC、传入包的SEQ和ROC，ROC是SRTP加密上下文变量。因此，SRTP对SSRC唯一性有很大的安全依赖性。
Given the above constraints, unicast SRTP crypto contexts can be established without the need to negotiate SSRC values in the SRTP security descriptions. Instead, an approach called "late binding" is RECOMMENDED by this specification. When a packet arrives, the SSRC that is contained in it can be bound to the crypto context at the time of session commencement (i.e., SRTP packet arrival) rather than at the time of session signaling (i.e., receipt of an SDP). With the arrival of the packet containing the SSRC, all the data items needed for the SRTP crypto context are held by the receiver. (Note that the ROC value by definition is zero; if non-zero values were to be supported, additional signaling would be required.) In other words,
鉴于上述限制，可以建立单播SRTP加密上下文，而无需在SRTP安全描述中协商SSRC值。相反，本规范建议使用一种称为“后期绑定”的方法。当分组到达时，包含在其中的SSRC可以在会话开始时（即，SRTP分组到达）而不是在会话信令时（即，接收SDP）绑定到加密上下文。随着包含SSRC的数据包的到达，SRTP加密上下文所需的所有数据项都由接收方持有。（注意，根据定义，ROC值为零；如果要支持非零值，则需要额外的信令。）换句话说，
the crypto context for a secure RTP session using late binding is initially identified by the SDP as
使用后期绑定的安全RTP会话的加密上下文最初由SDP标识为
<*, address, port>
<*, address, port>
where '*' is a wildcard SSRC, "address" is the local receive address from the "c=" line, and "port" is the local receive port from the "m=" line. When the first packet arrives with ssrcX in its SSRC field, the crypto context
其中“*”是通配符SSRC，“地址”是来自“c=”行的本地接收地址，“端口”是来自“m=”行的本地接收端口。当第一个数据包到达其SSRC字段中的ssrcX时，加密上下文
<ssrcX, address, port>
<ssrcX，地址，端口>
is instantiated subject to the following constraints:
根据以下约束进行实例化：
* Media packets are authenticated: authentication MUST succeed; otherwise, the crypto context is not instantiated.
* 对媒体数据包进行身份验证：身份验证必须成功；否则，不会实例化加密上下文。
* Media packets are not authenticated: crypto context is automatically instantiated.
* 媒体数据包未经过身份验证：加密上下文将自动实例化。
Note that use of late binding when there is no authentication of the SRTP media packets is subject to numerous security attacks, and that consequently it is NOT RECOMMENDED (of course, this can be said for unauthenticated SRTP in general).
请注意，在没有对SRTP媒体数据包进行身份验证的情况下使用延迟绑定会受到许多安全攻击，因此不建议使用延迟绑定（当然，这通常可以说是针对未经身份验证的SRTP）。
Note that use of late binding without authentication will result in the creation of local state as a result of receiving a packet from any unknown SSRC. UNAUTHENTICATED_SRTP, therefore, is NOT RECOMMENDED because it invites easy denial-of-service attack. In contrast, late binding with authentication does not suffer from this weakness.
请注意，在没有身份验证的情况下使用后期绑定将导致从任何未知SSRC接收数据包时创建本地状态。因此，不建议使用未经验证的_SRTP，因为它容易招致拒绝服务攻击。与此相反，具有身份验证的后期绑定不会受到此弱点的影响。
With the constraints and procedures described above, it is not necessary to explicitly signal the SSRC, ROC, and SEQ for a unicast RTP session. So there are no a=crypto parameters for signaling SSRC, ROC, or SEQ. Thus, multiple SSRCs from the same entity will share a=crypto parameters when late binding is used. Multiple SSRCs from the same entity arise due to either multiple sources (microphones, cameras, etc.) or RTP payloads requiring SSRC multiplexing within that same session. SDP also allows multiple RTP sessions to be defined in the same media description ("m="); these RTP sessions will also share the a=crypto parameters. An application that uses a=crypto in this way serially shares a master key among RTP sessions or SSRCs and MUST replace the master key when the aggregate number of packets among all SSRCs approaches 2^31 packets. SSRCs that share a master key MUST be unique from one another.
在上述约束和过程中，没有必要为单播RTP会话显式地向SSRC、ROC和SEQ发送信号。因此，没有a=用于发送SSRC、ROC或SEQ信号的加密参数。因此，当使用后期绑定时，来自同一实体的多个SSRC将共享a=加密参数。来自同一实体的多个SSRC是由于多个源（麦克风、摄像头等）或RTP有效负载在同一会话中需要SSRC多路复用而产生的。SDP还允许在同一媒体描述中定义多个RTP会话（“m=”）；这些RTP会话还将共享a=crypto参数。以这种方式使用a=crypto的应用程序在RTP会话或SSRC之间串行共享主密钥，并且当所有SSRC中的数据包总数接近2^31个数据包时，必须替换主密钥。共享主密钥的SSRC必须彼此唯一。
The mechanism defined above addresses the issue of creating crypto contexts. However, in practice, session participants may want to remove crypto contexts prior to session termination. Since a crypto context contains information that cannot automatically be recovered (e.g., ROC), it is important that the sender and receiver agree on when a crypto context can be removed, and perhaps more importantly when it cannot.
上面定义的机制解决了创建加密上下文的问题。然而，在实践中，会话参与者可能希望在会话终止之前删除加密上下文。由于加密上下文包含无法自动恢复的信息（例如ROC），因此发送方和接收方必须就何时可以删除加密上下文达成一致，更重要的是，何时无法删除加密上下文。
Even when late binding is used for a unicast stream, the ROC is lost and cannot be recovered automatically (unless it is zero) once the crypto context is removed.
即使对单播流使用延迟绑定，一旦删除加密上下文，ROC也会丢失，并且无法自动恢复（除非为零）。
We resolve this problem as follows. When SRTP security descriptions are being used, crypto-context removal MUST follow the same rules as SSRC removal from the member table [RFC3550]; note that this can happen as the result of an SRTCP BYE packet or a simple time-out due to inactivity. Inactive session participants that wish to ensure their crypto contexts are not timed out MUST thus send SRTCP packets at regular intervals.
我们解决这个问题的方法如下。使用SRTP安全描述时，加密上下文删除必须遵循与从成员表[RFC3550]中删除SSRC相同的规则；请注意，这可能是由于SRTCP BYE数据包或由于不活动而导致的简单超时造成的。因此，希望确保其加密上下文不超时的非活动会话参与者必须定期发送SRTCP数据包。
Section 5 describes general use of the crypto attribute, and this section completes it by describing SRTP-specific use.
第5节描述了crypto属性的一般用法，本节通过描述SRTP的特定用法来完成。
In this section, we describe how the SRTP security descriptions are used with the offer/answer model to negotiate cryptographic capabilities and communicate SRTP master keys. The rules defined below complement the general offer/answer rules defined in Section 5.1, which MUST be followed, unless otherwise specified. Note that the rules below define unicast operation only; support for multicast and multipoint unicast streams is for further study.
在本节中，我们将描述如何将SRTP安全性描述与提供/应答模型一起使用，以协商加密功能和通信SRTP主密钥。以下定义的规则补充了第5.1节中定义的一般报价/应答规则，除非另有规定，否则必须遵守这些规则。请注意，以下规则仅定义单播操作；对多播和多点单播流的支持有待进一步研究。
When the initial offer is generated, the offerer MUST follow the steps in Section 5.1.1, as well as the following steps.
生成初始报价时，报价人必须遵循第5.1.1节中的步骤以及以下步骤。
For each unicast media line (m=) using the secure RTP transport where the offerer wants to specify cryptographic parameters, the offerer MUST provide at least one valid SRTP security description ("a=crypto" line), as defined in Section 6. If the media stream includes Forward
对于使用安全RTP传输的每个单播媒体线路（m=），如果报价人希望指定加密参数，报价人必须提供至少一个有效的SRTP安全描述（“a=加密”线路），如第6节所定义。如果媒体流包括转发
Error Correction with a different IP-address and/or port from that of the media stream itself, an FEC_KEY parameter MUST be included, as described in Section 6.3.5.
使用与媒体流本身不同的IP地址和/或端口进行纠错，必须包括FEC_密钥参数，如第6.3.5节所述。
The inline parameter conveys the SRTP master key used by an endpoint to encrypt the SRTP and SRTCP streams transmitted by that endpoint. The same key is used by the recipient to decrypt those streams. However, the receiver MUST NOT use that same key for the SRTP or SRTCP packets that it sends to the session because the default SRTP cipher and mode is insecure when the master key is reused across distinct SRTP streams.
内联参数传递端点用于加密该端点传输的SRTP和SRTCP流的SRTP主密钥。收件人使用相同的密钥解密这些流。但是，接收方不得对发送到会话的SRTP或SRTCP数据包使用相同的密钥，因为当主密钥跨不同的SRTP流重用时，默认的SRTP密码和模式是不安全的。
The offerer MAY include one or more other SRTP session parameters, as defined in Section 6.3. Note, however, that if any SRTP session parameters are included that are not known to the answerer, but that are nonetheless mandatory (see Section 6.3.6), the negotiation will fail if the answerer does not support them.
报价人可包括第6.3节中定义的一个或多个其他SRTP会话参数。但是，请注意，如果包括应答者不知道但却是强制性的任何SRTP会话参数（参见第6.3.6节），如果应答者不支持这些参数，协商将失败。
When the initial answer is generated, the answerer MUST follow the steps in Section 5.1.2, as well as the following steps.
生成初始答案时，回答者必须遵循第5.1.2节中的步骤以及以下步骤。
For each unicast media line that uses the secure RTP transport and contains one or more "a=crypto" lines in the offer, the answerer MUST either accept one (and only one) of the crypto lines for that media stream, or it MUST reject the media stream. Only "a=crypto" lines that are considered valid SRTP security descriptions, as defined in Section 6, can be accepted. Furthermore, all parameters (crypto-suite, key parameter, and mandatory session parameters) MUST be acceptable to the answerer in order for the offered media stream to be accepted. Note that if the media stream includes Forward Error Correction with a different IP-address and/or port from that of the media stream itself, an FEC_KEY parameter MUST be included, as described in Section 6.3.5.
对于使用安全RTP传输并在报价中包含一条或多条“a=crypto”线路的每个单播媒体线路，应答者必须为该媒体流接受一条（且仅一条）加密线路，或者必须拒绝该媒体流。只能接受第6节中定义的被视为有效SRTP安全描述的“a=crypto”行。此外，为了接受提供的媒体流，应答者必须接受所有参数（加密套件、密钥参数和强制会话参数）。请注意，如果媒体流包括与媒体流本身具有不同IP地址和/或端口的前向纠错，则必须包括FEC_密钥参数，如第6.3.5节所述。
When the answerer accepts an SRTP unicast media stream with a crypto line, the answerer MUST include one or more master keys appropriate for the selected crypto algorithm; the master key(s) included in the answer MUST be different from those in the offer.
当应答者接受带有加密线路的SRTP单播媒体流时，应答者必须包括一个或多个适用于所选加密算法的主密钥；答案中包含的主密钥必须与报价中的主密钥不同。
When the master key(s) are not shared between the offerer and answerer, SSRC collisions between the offerer and answerer will not lead to keystream reuse, and hence SSRC collisions do not necessarily have to be prevented.
当主密钥未在提供方和应答方之间共享时，提供方和应答方之间的SSRC冲突将不会导致密钥流重用，因此不必防止SSRC冲突。
If Forward Error Correction to a separate IP-address and/or port is included, the answer MUST include an FEC_KEY parameter, as described in Section 6.3.5.
如果包括对单独IP地址和/或端口的前向纠错，则答案必须包括FEC_密钥参数，如第6.3.5节所述。
Declarative session parameters may be added to the answer as usual; however, the answerer SHOULD NOT add any mandatory session parameter (see Section 6.3.6) that might be unknown to the offerer.
可以像往常一样在答案中添加声明性会话参数；但是，回答者不应添加报价人可能不知道的任何强制性会话参数（见第6.3.6节）。
If the answerer cannot find any valid crypto line that it supports, or if its configured policy prohibits any cryptographic key parameter (e.g., key length) or cryptographic session parameter (e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it is able to successfully negotiate use of SRTP by other means outside the scope of this document (e.g., by use of MIKEY [mikey]).
如果应答者无法找到其支持的任何有效加密线路，或者如果其配置的策略禁止任何加密密钥参数（例如，密钥长度）或加密会话参数（例如，KDR、FEC_顺序），则应答者必须拒绝媒体流，除非其能够通过本文件范围外的其他方式（例如，通过使用MIKEY[MIKEY]）成功协商SRTP的使用。
When the offerer receives the answer, it MUST perform the steps in Section 5.1.3, as well as the following steps for each SRTP media stream it offered with one or more crypto lines in it.
当报价人收到答复时，必须执行第5.1.3节中的步骤，以及对其提供的每个SRTP媒体流执行以下步骤，其中包含一条或多条加密线路。
If the media stream was accepted and it contains a crypto line, it MUST be checked that the crypto line is valid according to the constraints specified in Section 6 (including any FEC constraints).
如果媒体流被接受且包含加密线，则必须根据第6节中规定的约束（包括任何FEC约束）检查加密线是否有效。
If the offerer either does not support or is not willing to honor one or more of the SRTP parameters in the answer, the offerer MUST consider the crypto line invalid.
如果要约人不支持或不愿意在回答中兑现一个或多个SRTP参数，则发售方必须考虑密码行无效。
If the crypto line is not valid, or the offerer's configured policy prohibits any cryptographic key parameter (e.g., key length) or cryptographic session parameter, the SRTP security negotiation MUST be deemed to have failed.
如果加密线路无效，或者报价人配置的策略禁止任何加密密钥参数（例如，密钥长度）或加密会话参数，则必须将SRTP安全协商视为失败。
When a media stream using the SRTP security descriptions has been established and a new offer/answer exchange is performed, the offerer and answerer MUST follow the steps in Section 5.1.4, as well as the following steps.
当建立了使用SRTP安全描述的媒体流并执行了新的报价/应答交换时，报价人和应答人必须遵循第5.1.4节中的步骤以及以下步骤。
When modifying the session, all negotiated aspects of the SRTP media stream can be modified. For example, a new crypto suite can be used or a new master key can be established. As described in RFC 3264, when a new offer/answer exchange is made, there will be a window of time where the offerer and the answerer must be prepared to receive media according to both the old and new offer/answer exchange.
修改会话时，可以修改SRTP媒体流的所有协商方面。例如，可以使用新的加密套件或建立新的主密钥。如RFC 3264所述，当进行新的报价/应答交换时，将有一个时间窗口，报价人和应答人必须准备好根据新旧报价/应答交换接收媒体。
This requirement applies here as well; however, the following should be noted:
这一要求在这里也适用；但是，应注意以下几点：
* When authentication is not being used, it may not be possible for either the offerer or answerer to determine if a given packet is encrypted according to the old or new offer/answer exchange. RFC 3264 defines a couple of techniques to address this problem, e.g., changing the payload types used and/or the transport addresses. Note, however, that a change in transport addresses may have an impact on quality of service as well as on firewall and NAT traversal. The SRTP security descriptions use the MKI to deal with this (which adds a few bytes to each SRTP packet), as described in Section 6.1. For further details on the MKI, please refer to [RFC3711].
* 当未使用认证时，要约人或应答人可能无法确定给定分组是否根据旧的或新的要约/应答交换进行了加密。RFC 3264定义了解决此问题的两种技术，例如，更改使用的有效负载类型和/或传输地址。但是，请注意，传输地址的更改可能会影响服务质量以及防火墙和NAT穿越。如第6.1节所述，SRTP安全描述使用MKI来处理此问题（为每个SRTP数据包添加几个字节）。有关MKI的更多详细信息，请参阅[RFC3711]。
* If the answerer changes its master key, the offerer will not be able to process packets secured via this master key until the answer is received. This could be addressed by using a security "precondition" [sprecon].
* 如果应答者更改其主密钥，则在收到应答之前，报价者将无法处理通过该主密钥保护的数据包。这可以通过使用安全“先决条件”[sprecon]来解决。
If the offerer includes an IP address and/or port that differs from that used previously for a media stream (or FEC stream), the offerer MUST include a new master key with the offer (and in so doing, it will be creating a new crypto context where the ROC is set to zero). Similarly, if the answerer includes an IP address and/or port that differs from that used previously for a media stream (or FEC stream), the answerer MUST include a new master key with the answer (and hence create a new crypto context with the ROC set to zero). The reason for this is that when the answerer receives an offer or the offerer receives an answer with an updated IP address and/or port, it is not possible to determine if the other side has access to the old crypto context parameters (and in particular the ROC). For example, if one side is a decomposed media gateway, or if a SIP back-to-back user agent is involved, it is possible that the media endpoint changed and no longer has access to the old crypto context. By always requiring a new master key in this case, the answerer/offerer will know that the ROC is zero for this offer/answer, and any key lifetime constraints will trivially be satisfied too. Another consideration here applies to media relays; if the relay changes the media endpoint on one side transparently to the other side, the relay cannot operate as a simple packet reflector but will have to actively engage in SRTP packet processing and transformation (i.e., decryption and re-encryption, etc.).
如果报价人包括与先前用于媒体流（或FEC流）的IP地址和/或端口不同的IP地址和/或端口，报价人必须在报价中包括新的主密钥（这样做，它将创建一个新的加密上下文，其中ROC设置为零）。类似地，如果应答者包括与先前用于媒体流（或FEC流）的IP地址和/或端口不同的IP地址和/或端口，则应答者必须包括新的主密钥和应答（并因此创建新的加密上下文，ROC设置为零）。其原因是，当应答者接收到要约或要约者接收到具有更新的IP地址和/或端口的应答时，不可能确定另一方是否能够访问旧的加密上下文参数（尤其是ROC）。例如，如果一端是分解的媒体网关，或者如果涉及SIP背靠背用户代理，则媒体端点可能已更改，不再具有对旧加密上下文的访问权限。在这种情况下，通过始终需要一个新的主密钥，应答者/发盘者将知道，对于该发盘/应答，ROC为零，并且任何密钥生命周期约束也将很容易得到满足。这里的另一个考虑因素适用于媒体转播；如果中继器对另一侧透明地改变一侧的媒体端点，则中继器不能作为简单的分组反射器操作，而是必须主动参与SRTP分组处理和转换（即，解密和重新加密等）。
Finally, note that if the new offer is rejected, the old crypto parameters remain in place.
最后，请注意，如果新的报价被拒绝，则旧的加密参数将保持不变。
In this example, the offerer supports two crypto suites (f8 and AES). The a=crypto line is actually one long line, although it is shown as two lines in this document due to page formatting. The f8 example shows two inline parameters; as explained in Section 6.1, there may be one or more key (i.e., inline) parameters in a crypto attribute. In this way, multiple keys are offered to support key rotation using a Master Key Identifier (MKI).
在本例中，报价人支持两个加密套件（f8和AES）。a=crypto行实际上是一个长行，尽管由于页面格式的原因，在本文档中显示为两行。f8示例显示了两个内联参数；如第6.1节所述，加密属性中可能有一个或多个密钥（即内联）参数。这样，使用主密钥标识符（MKI）提供多个密钥以支持密钥旋转。
Offerer sends:
报价人发送：
v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=crypto:2 F8_128_HMAC_SHA1_80
inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
FEC_ORDER=FEC_SRTP
v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=crypto:2 F8_128_HMAC_SHA1_80
inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
FEC_ORDER=FEC_SRTP
Answerer replies:
答复者答复：
v=0
o=jill 25690844 8070842634 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=homer@example.com (Homer Simpson)
c=IN IP4 168.2.17.11
t=2873397526 2873405696
m=audio 32640 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
v=0
o=jill 25690844 8070842634 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=homer@example.com (Homer Simpson)
c=IN IP4 168.2.17.11
t=2873397526 2873405696
m=audio 32640 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
In this case, the session would use the AES_CM_128_HMAC_SHA1_80 crypto suite for the RTP and RTCP traffic. If F8_128_HMAC_SHA1_80 were selected by the answerer, there would be two inline keys associated with the SRTP cryptographic context. One key has an MKI value of 1 and the second has an MKI of 2.
在这种情况下，会话将对RTP和RTCP通信使用AES_CM_128_HMAC_SHA1_80加密套件。如果应答者选择了F8_128_HMAC_SHA1_80，则将有两个与SRTP加密上下文相关联的内联密钥。一个键的MKI值为1，第二个键的MKI值为2。
Use of SRTP security descriptions outside the offer/answer model is not defined.
未定义在提供/应答模型之外使用SRTP安全描述。
Use of SRTP security descriptions outside the offer/answer model could have been defined for sendonly media streams; however, there would not be a way to indicate the key to use for SRTCP by the receiver of said media stream.
可以为仅发送媒体流定义在提供/应答模型之外使用SRTP安全描述；然而，将没有一种方法指示所述媒体流的接收器用于SRTCP的密钥。
As mentioned earlier, the security descriptions defined here do not support multicast media streams or multipoint unicast streams. However, in the SIP protocol, it is possible to receive several answers to a single offer due to the use of forking (see [SIP]). Receiving multiple answers leads to a couple of problems for the SRTP security descriptions:
如前所述，此处定义的安全描述不支持多播媒体流或多点单播流。然而，在SIP协议中，由于使用了分叉（参见[SIP]），可能会收到对单个报价的多个答复。收到多个答案会导致SRTP安全描述出现两个问题：
* Different answerers may choose different ciphers, keys, etc.; however, there is no way for the offerer to associate a particular incoming media packet with a particular answer.
* 不同的应答者可以选择不同的密码、密钥等。；然而，报价人无法将特定的传入媒体包与特定的答案相关联。
* Two or more answerers may pick the same SSRC, and hence the SSRC collision problems mentioned earlier may arise.
* 两个或多个回答者可能选择相同的SSRC，因此可能出现前面提到的SSRC冲突问题。
As stated earlier, the above point-to-multipoint cases are outside the scope of the SDP security descriptions. However, there are still ways of supporting SIP forking, e.g., by changing the multipoint scenario resulting from SIP forking into multiple two-party unicast cases. This can be done as follows:
如前所述，上述点对多点情况不在SDP安全描述的范围内。然而，仍然有支持SIP分叉的方法，例如，通过将SIP分叉产生的多点场景更改为多个两方单播情况。这可以通过以下方式完成：
For each answer received beyond the initial answer, issue a new offer to that particular answerer using a new receive transport address (IP address and port); note that this requires support for the SIP UPDATE method [RFC3311]. Also, to ensure that two media sessions are not inadvertently established prior to the UPDATE being processed by one of them, use security preconditions [sprecon].
对于初始答案之外收到的每个答案，使用新的接收传输地址（IP地址和端口）向特定的回答者发出新的报价；注意，这需要支持SIP更新方法[RFC3311]。此外，为了确保在其中一个媒体会话处理更新之前不会无意中建立两个媒体会话，请使用安全先决条件[sprecon]。
Finally, note that all SIP User Agents that received the offer will know the key(s) being proposed by the initial offer. If the offerer wants to ensure security with respect to all other User Agents that may have received the offer, a new offer/answer exchange with a new key needs to be performed with the answerer as well. Note that the offerer cannot determine whether a single or multiple SIP User Agents received the offer, since intermediate forking proxies may only forward a single answer to the offerer.
最后，请注意，所有收到要约的SIP用户代理都将知道初始要约提出的密钥。如果报价人希望确保可能已收到报价的所有其他用户代理的安全，则还需要与应答人进行具有新密钥的新报价/应答交换。请注意，报价人无法确定单个或多个SIP用户代理是否收到报价，因为中间分叉代理可能只向报价人转发一个答案。
The above description is intended to suggest one possible way of supporting SIP forking. There are many details missing and it should not be considered a normative specification. Alternative approaches may also be possible
以上描述旨在建议支持SIP分叉的一种可能方式。缺少许多细节，不应将其视为规范性规范。也可能有其他办法
It is possible that the answerer supports the SRTP transport and accepts the offered media stream, but that it does not support the crypto attribute defined here. The offerer can recognize this situation by seeing an accepted SRTP media stream in the answer that does not include a crypto line. In that case, the security negotiation defined here MUST be deemed to have failed.
应答者可能支持SRTP传输并接受提供的媒体流，但不支持此处定义的加密属性。报价人可以通过在答案中看到不包括加密线路的已接受SRTP媒体流来识别这种情况。在这种情况下，此处定义的安全协商必须被视为失败。
Also, if a media stream with a given SRTP transport (e.g., "RTP/SAVP") is sent to a device that does not support SRTP, that media stream will be rejected.
此外，如果具有给定SRTP传输（例如，“RTP/SAVP”）的媒体流被发送到不支持SRTP的设备，则该媒体流将被拒绝。
An offer MAY include both "a=crypto" and "a=keymgt" lines [keymgt]. Per SDP rules, the answerer will ignore attribute lines that it does not understand. If the answerer supports both "a=crypto" and "a=keymgt", the answer MUST include either "a=crypto" or "a=keymgt", but not both, as including both is undefined.
报价可能包括“a=crypto”和“a=keymgt”行[keymgt]。根据SDP规则，回答者将忽略其不理解的属性行。如果回答者同时支持“a=crypto”和“a=keymgt”，则答案必须包含“a=crypto”或“a=keymgt”，但不能同时包含这两个，因为未定义包含这两个选项。
An offer MAY include both "a=crypto" and "k=" lines [RFC4566]. Per SDP rules, the answerer will ignore attribute lines it does not understand. If the answerer supports both "a=crypto" and "k=", the answer MUST include either "a=crypto" or "k=" but not both, as including both is undefined.
报价可能包括“a=crypto”和“k=”行[RFC4566]。根据SDP规则，回答者将忽略其不理解的属性行。如果回答者同时支持“a=crypto”和“k=”，则答案必须包含“a=crypto”或“k=”，但不能同时包含这两个选项，因为包含这两个选项是未定义的。
Like all SDP messages, SDP messages containing security descriptions are conveyed in an encapsulating application protocol (e.g., SIP, MGCP). It is the responsibility of the encapsulating protocol to ensure the protection of the SDP security descriptions. Therefore, IT IS REQUIRED that the application invoke its own security mechanisms (e.g., secure multiparts such as S/MIME [smime]) or, alternatively, utilize a lower-layer security service (e.g., TLS or IPsec). IT IS REQUIRED that this security service provide strong message authentication and packet-payload encryption, as well as effective replay protection.
与所有SDP消息一样，包含安全描述的SDP消息在封装应用程序协议（例如SIP、MGCP）中传输。封装协议负责确保SDP安全描述的保护。因此，要求应用程序调用其自身的安全机制（例如，安全多部分，如S/MIME[smime]），或者，利用较低层的安全服务（例如，TLS或IPsec）。要求该安全服务提供强大的消息身份验证和数据包有效负载加密，以及有效的重播保护。
"Replay protection" is needed against an attacker that has enough access to the communications channel to intercept messages and to deliver copies to the destination. A successful replay attack will
需要“重播保护”，以防攻击者有足够的通信通道访问权限来截获消息并将副本发送到目标。成功的重播攻击将
cause the recipient to perform duplicate processing on a message; the attack is worse when the duped recipient sends a duplicate reply to the initiator. Replay protections are not found in S/MIME or in the other secure-multiparts standard, PGP/MIME. S/MIME and PGP/MIME, therefore, need to be augmented with some replay-protection mechanism that is appropriate to the encapsulating application protocol (e.g., SIP, MGCP). Three common ways to provide replay protection are to place a sequence number in the message, to use a timestamp, or for the receiver to keep a hash of the message to be compared with incoming messages. There typically needs to be a replay "window" and some policy for keeping state information from previous messages in a "replay table" or list.
使收件人对邮件执行重复处理；当被复制的收件人向启动器发送重复的回复时，攻击会更严重。在MIME/PGP中找不到标准的或不安全的保护。因此，S/MIME和PGP/MIME需要增加一些适合于封装应用程序协议（例如SIP、MGCP）的重播保护机制。提供重播保护的三种常用方法是在消息中放置序列号、使用时间戳，或者让接收方保留消息的散列以与传入消息进行比较。通常需要有一个重播“窗口”和一些策略来保存“重播表”或列表中以前消息的状态信息。
The discussion that follows uses "message authentication" and "message confidentiality" in a manner consistent with SRTP [RFC3711]. "Message confidentiality" means that only the holder of the secret decryption key can access the plain-text content of the message. The decryption key is the same key as the encryption key, using SRTP counter mode and f8 encryption transforms, which are vulnerable to message tampering and need SRTP message authentication to detect such tampering. "Message authentication" and "message integrity validation" generally mean the same thing in IETF security standards: an SRTP message is authenticated following a successful HMAC integrity check [RFC3711], which proves that the message originated from the holder of an SRTP master key and was not altered en route. Such an "authentic" message, however, can be captured by an attacker and "replayed" when the attacker re-inserts the packet into the channel. A replayed packet can have a variety of bad effects on the session, and SRTP uses the extended sequence number to detect replayed SRTP packets [RFC3711].
下面的讨论以与SRTP[RFC3711]一致的方式使用“消息身份验证”和“消息机密性”。“消息机密性”是指只有秘密解密密钥的持有者才能访问消息的纯文本内容。解密密钥与加密密钥相同，使用SRTP计数器模式和f8加密转换，容易受到消息篡改，需要SRTP消息身份验证来检测此类篡改。“消息身份验证”和“消息完整性验证”在IETF安全标准中通常指的是同一件事：在成功的HMAC完整性检查[RFC3711]之后，对SRTP消息进行身份验证，这证明消息来自SRTP主密钥的持有者，并且在路由过程中未被更改。但是，攻击者可以捕获此类“真实”消息，并在攻击者将数据包重新插入通道时“重播”该消息。重放的数据包可能会对会话产生各种不良影响，SRTP使用扩展序列号来检测重放的SRTP数据包[RFC3711]。
The SRTP specification identifies which services and features are default values that are normative-to-implement (such as AES_CM_128_80) versus normative-to-use (such as AES_CM_128_32).
SRTP规范确定了哪些服务和功能是要实现的规范性服务（如AES_CM_128_80）和要使用的规范性服务（如AES_CM_128_32）的默认值。
Security descriptions as defined herein signal security services for RTP packets. RTP messages are vulnerable to a variety of attacks, such as replay and forging. To limit these attacks, SRTP message integrity mechanisms SHOULD be used (SRTP replay protection is always enabled).
此处定义的安全描述表示RTP数据包的安全服务。RTP消息容易受到各种攻击，例如重播和伪造。为了限制这些攻击，应使用SRTP消息完整性机制（始终启用SRTP重放保护）。
SRTP security descriptions signal configuration parameters for SRTP sessions. Misconfigured SRTP sessions are vulnerable to attacks on their encryption services when running the crypto suites defined in
SRTP安全描述信号SRTP会话的配置参数。在运行中定义的加密套件时，配置错误的SRTP会话容易受到对其加密服务的攻击
Sections 6.2.1, 6.2.2, and 6.2.3. An SRTP encryption service is "misconfigured" when two or more media streams are encrypted using the same keystream of AES blocks. When senders and receivers share derived session keys, SRTP requires that the SSRCs of session participants serve to make their corresponding keystreams unique, which is violated in the case of SSRC collision: SRTP SSRC collision drastically weakens SRTP or SRTCP payload encryption during the time that identical keystreams are used [RFC3711]. An attacker, for example, might collect SRTP and SRTCP messages and await a collision. This attack on the AES-CM and AES-f8 encryption is avoided entirely when each media stream has its own unique master key in both the send and receive direction. This specification restricts use of SDP security description to unicast point-to-point streams so that keys are not shared between SRTP hosts, and the master keys used in the send and receive direction for a given media stream are unique.
第6.2.1、6.2.2和6.2.3节。当使用AES块的相同密钥流加密两个或多个媒体流时，SRTP加密服务“配置错误”。当发送方和接收方共享派生会话密钥时，SRTP要求会话参与者的SSRC服务于使其对应的密钥流唯一，这在SSRC冲突的情况下被违反：SRTP SSRC冲突在使用相同密钥流的过程中大大削弱了SRTP或SRTCP有效负载加密[RFC3711]。例如，攻击者可能会收集SRTP和SRTCP消息并等待冲突。当每个媒体流在发送和接收方向上都有自己的唯一主密钥时，可以完全避免对AES-CM和AES-f8加密的这种攻击。本规范将SDP安全描述的使用限制在单播点到点流上，以便密钥不会在SRTP主机之间共享，并且在给定媒体流的发送和接收方向上使用的主密钥是唯一的。
There is no reason to incur the complexity and computational expense of SRTP, however, when its key establishment is exposed to unauthorized parties. In most cases, the SRTP crypto attribute and its parameters are vulnerable to denial-of-service attacks when they are carried in an unauthenticated SDP message. In some cases, the integrity or confidentiality of the RTP stream can be compromised. For example, if an attacker sets UNENCRYPTED for the SRTP stream in an offer, this could result in the answerer's not decrypting the encrypted SRTP messages. In the worst case, the answerer might itself send unencrypted SRTP and leave its data exposed to snooping.
但是，当SRTP的密钥建立暴露给未经授权的方时，没有理由承担SRTP的复杂性和计算费用。在大多数情况下，SRTP crypto属性及其参数在未经身份验证的SDP消息中携带时容易受到拒绝服务攻击。在某些情况下，RTP流的完整性或机密性可能会受到损害。例如，如果攻击者在要约中为SRTP流设置未加密，这可能导致应答者无法解密加密的SRTP消息。在最坏的情况下，应答者可能自己发送未加密的SRTP，并将其数据暴露在窥探之下。
Thus, IT IS REQUIRED that MIME secure multiparts, IPsec, TLS, or some other data security service be used to provide message authentication for the encapsulating protocol that carries the SDP messages having a crypto attribute (a=crypto). Furthermore, IT IS REQUIRED that encryption of the encapsulating payload be used whenever a master key parameter (inline) appears in the message. Failure to encrypt the SDP message containing an inline SRTP master key renders the SRTP authentication or encryption service useless in practically all circumstances. Failure to authenticate an SDP message that carries SRTP parameters renders the SRTP authentication or encryption service useless in most practical applications.
因此，需要使用MIME安全多部分、IPsec、TLS或某些其他数据安全服务来为封装协议提供消息认证，该封装协议承载具有加密属性（a=加密）的SDP消息。此外，每当消息中出现主密钥参数（内联）时，需要使用封装有效负载的加密。如果无法加密包含内联SRTP主密钥的SDP消息，则SRTP身份验证或加密服务在几乎所有情况下都将无效。如果无法对携带SRTP参数的SDP消息进行身份验证，则在大多数实际应用中，SRTP身份验证或加密服务将无效。
When the communication path of the SDP message is routed through intermediate systems that inspect parts of the SDP message, security protocols such as [IPsec] or TLS SHOULD NOT be used for encrypting and/or authenticating the security description. In the case of intermediate-system processing of a message containing SDP security descriptions, the "a=crypto" attributes SHOULD be protected end-to-end so that the intermediate system can neither modify the security
当SDP消息的通信路径通过检查SDP消息部分的中间系统路由时，不应使用[IPsec]或TLS等安全协议对安全描述进行加密和/或认证。在中间系统处理包含SDP安全性描述的消息的情况下，“a=crypto”属性应受到端到端的保护，以便中间系统既不能修改安全性描述，也不能修改安全性描述
description nor access the keying material. Network or transport security protocols that terminate at each intermediate system, therefore, SHOULD NOT be used for protecting SDP security descriptions. A security protocol SHOULD allow the security descriptions to be encrypted and authenticated end-to-end independently of the portions of the SDP message that any intermediate system modifies or inspects: MIME secure multiparts are RECOMMENDED for the protection of SDP messages that are processed by intermediate systems.
描述或访问键控材质。因此，在每个中间系统终止的网络或传输安全协议不应用于保护SDP安全描述。安全协议应允许对安全描述进行端到端加密和身份验证，独立于任何中间系统修改或检查的SDP消息部分：建议使用MIME安全多部分来保护由中间系统处理的SDP消息。
In this section, we first provide the ABNF grammar for the generic crypto attribute, and then we provide the ABNF grammar for the SRTP-specific use of the crypto attribute.
在本节中，我们首先为泛型crypto属性提供ABNF语法，然后为crypto属性的SRTP特定用途提供ABNF语法。
The ABNF grammar for the crypto attribute is defined below:
加密属性的ABNF语法定义如下：
"a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params
*(1*WSP session-param)
"a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params
*(1*WSP session-param)
tag = 1*9DIGIT
crypto-suite = 1*(ALPHA / DIGIT / "_")
tag = 1*9DIGIT
crypto-suite = 1*(ALPHA / DIGIT / "_")
key-params = key-param *(";" key-param)
key-param = key-method ":" key-info
key-method = "inline" / key-method-ext
key-method-ext = 1*(ALPHA / DIGIT / "_")
key-info = 1*(%x21-3A / %x3C-7E) ; visible (printing) chars
; except semi-colon
session-param = 1*(VCHAR) ; visible (printing) characters
key-params = key-param *(";" key-param)
key-param = key-method ":" key-info
key-method = "inline" / key-method-ext
key-method-ext = 1*(ALPHA / DIGIT / "_")
key-info = 1*(%x21-3A / %x3C-7E) ; visible (printing) chars
; except semi-colon
session-param = 1*(VCHAR) ; visible (printing) characters
where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC4234].
其中，[RFC4234]中定义了WSP、ALPHA、DIGIT和VCHAR。
This section provides an Augmented BNF [RFC4234] grammar for the SRTP-specific use of the SDP crypto attribute:
本节为特定于SRTP的SDP crypto属性的使用提供了扩充的BNF[RFC4234]语法：
crypto-suite = srtp-crypto-suite key-method = srtp-key-method key-info = srtp-key-info session-param = srtp-session-param
加密套件=srtp加密套件密钥方法=srtp密钥方法密钥信息=srtp密钥信息会话参数=srtp会话参数
srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / "F8_128_HMAC_SHA1_32" /
srtp crypto suite=“AES_CM_128_HMAC_SHA1_32”/“F8_128_HMAC_SHA1_32”/
"AES_CM_128_HMAC_SHA1_80" / srtp-crypto-suite-ext
“AES_CM_128_HMAC_SHA1_80”/srtp加密套件分机
srtp-key-method = "inline" srtp-key-info = key-salt ["|" lifetime] ["|" mki]
srtp key method=“inline”srtp key info=key salt[“|”life][“|”mki]
key-salt = 1*(base64) ; binary key and salt values
; concatenated together, and then
; base64 encoded [section 3 of
; RFC3548
key-salt = 1*(base64) ; binary key and salt values
; concatenated together, and then
; base64 encoded [section 3 of
; RFC3548
lifetime = ["2^"] 1*(DIGIT) ; see section 6.1 for "2^"
mki = mki-value ":" mki-length
mki-value = 1*DIGIT
mki-length = 1*3DIGIT ; range 1..128.
lifetime = ["2^"] 1*(DIGIT) ; see section 6.1 for "2^"
mki = mki-value ":" mki-length
mki-value = 1*DIGIT
mki-length = 1*3DIGIT ; range 1..128.
srtp-session-param = kdr / "UNENCRYPTED_SRTP" / "UNENCRYPTED_SRTCP" / "UNAUTHENTICATED_SRTP" / fec-order / fec-key / wsh / srtp-session-extension
srtp session param=kdr/“UNENCRYPTED_srtp”/“UNENCRYPTED_SRTCP”/“UNAUTHENTICATED_srtp”/fec order/fec key/wsh/srtp session extension
kdr = "KDR=" 1*2(DIGIT) ; range 0..24,
; power of two
kdr = "KDR=" 1*2(DIGIT) ; range 0..24,
; power of two
fec-order = "FEC_ORDER=" fec-type
fec-type = "FEC_SRTP" / "SRTP_FEC"
fec-key = "FEC_KEY=" key-params
fec-order = "FEC_ORDER=" fec-type
fec-type = "FEC_SRTP" / "SRTP_FEC"
fec-key = "FEC_KEY=" key-params
wsh = "WSH=" 2*DIGIT ; minimum value is 64
base64 = ALPHA / DIGIT / "+" / "/" / "="
wsh = "WSH=" 2*DIGIT ; minimum value is 64
base64 = ALPHA / DIGIT / "+" / "/" / "="
srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_")
srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC4234]
; first character must not be dash ("-")
srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_")
srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC4234]
; first character must not be dash ("-")
The IANA has registered a new SDP attribute as follows:
IANA已注册一个新的SDP属性，如下所示：
Attribute name: crypto Long form name: Security description cryptographic attribute for media streams Type of attribute: Media-level Subject to charset: No Purpose: Security descriptions Appropriate values: See Section 4
属性名称：加密长格式名称：安全描述媒体流的加密属性属性类型：媒体级别受限于字符集：无目的：安全描述适当的值：请参阅第4节
The following sub-sections define a new IANA registry with associated sub-registries to be used for the SDP security descriptions. The IANA has created an SDP Security Description registry as shown below and further described in the following sections:
以下小节定义了一个新的IANA注册表，其中包含用于SDP安全性描述的关联子注册表。IANA已创建了SDP安全描述注册表，如下所示，并在以下章节中进一步说明：
SDP Security Descriptions
|
+- Key Methods (described in 10.2.1)
|
+- Media Stream Transports (described in 10.2.2)
|
+- Transport1 (e.g., SRTP)
| |
| +- Supported Key Methods (e.g., inline)
| |
| +- crypto suites
| |
| +- session parameters
|
+- Transport2
: :
SDP Security Descriptions
|
+- Key Methods (described in 10.2.1)
|
+- Media Stream Transports (described in 10.2.2)
|
+- Transport1 (e.g., SRTP)
| |
| +- Supported Key Methods (e.g., inline)
| |
| +- crypto suites
| |
| +- session parameters
|
+- Transport2
: :
The IANA has created a new subregistry for SDP security description key methods. An IANA key method registration MUST be documented in an RFC in accordance with the [RFC2434] Standards Action, and it MUST provide the name of the key method in accordance with the grammar for key-method-ext defined in Section 9.1.
IANA为SDP安全描述密钥方法创建了一个新的子区域。IANA密钥方法注册必须根据[RFC2434]标准行动记录在RFC中，并且必须根据第9.1节中定义的密钥方法ext语法提供密钥方法的名称。
The IANA has created a new subregistry for SDP security description Media Stream Transports. An IANA media stream transport registration MUST be documented in an RFC in accordance with the RFC 2434 Standards Action and the procedures defined in Sections 4 and 5 of this document. The registration MUST provide the name of the transport and a list of supported key methods.
IANA为SDP安全描述媒体流传输创建了一个新的子区域。IANA媒体流传输注册必须按照RFC 2434标准行动和本文件第4节和第5节规定的程序记录在RFC中。注册必须提供传输的名称和支持的密钥方法列表。
In addition, each new media stream transport registry must contain a crypto-suite registry and a session parameter registry, as well as IANA instructions for how to populate these registries.
此外，每个新的媒体流传输注册表必须包含加密套件注册表和会话参数注册表，以及有关如何填充这些注册表的IANA说明。
The following security descriptions key methods are hereby registered:
特此注册以下安全说明和关键方法：
inline
内联
The IANA has created an SDP Security Description Media Stream Transport subregistry for "SRTP". The key methods supported is "inline". The reference for the SDP security description for SRTP is this document.
IANA为“SRTP”创建了SDP安全描述媒体流传输子区。支持的关键方法是“inline”。SRTP的SDP安全说明参考文件如下。
The IANA has created a new subregistry for SRTP crypto suites under the SRTP transport of the SDP Security Descriptions. An IANA SRTP crypto suite registration MUST indicate the crypto suite name in accordance with the grammar for srtp-crypto-suite-ext defined in Section 9.2.
IANA根据SDP安全说明的SRTP传输为SRTP加密套件创建了一个新的子区。IANA SRTP加密套件注册必须根据第9.2节中定义的SRTP加密套件扩展语法说明加密套件名称。
The semantics of the SRTP crypto suite MUST be described in an RFC in accordance with the RFC 2434 Standards Action, including the semantics of the "inline" key-method and any special semantics of parameters.
必须根据RFC 2434标准操作在RFC中描述SRTP加密套件的语义，包括“内联”密钥方法的语义和参数的任何特殊语义。
The following SRTP crypto suites are hereby registered:
特此注册以下SRTP加密套件：
AES_CM_128_HMAC_SHA1_80 AES_CM_128_HMAC_SHA1_32 F8_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_80 AES_CM_128_HMAC_SHA1_32 F8_128_HMAC_SHA1_80
The reference for these crypto suites is provided in this document.
本文件提供了这些加密套件的参考资料。
The IANA has created a new subregistry for SRTP session parameters under the SRTP transport of the SDP Security Descriptions. An IANA SRTP session parameter registration MUST indicate the session parameter name (srtp-session-extension as defined in Section 9.2); the name MUST NOT begin with the dash character ("-").
IANA在SDP安全说明的SRTP传输下为SRTP会话参数创建了一个新的子区域。IANA SRTP会话参数注册必须指明会话参数名称（第9.2节定义的SRTP会话扩展）；名称不能以短划线字符（“-”）开头。
The semantics of the parameter MUST be described in an RFC in accordance with the RFC 2434 Standards Action. If values can be assigned to the parameter, then the format and possible values that can be assigned MUST be described in the RFC in accordance with the RFC 2434 Standards Action as well. Also, it MUST be specified whether the parameter is declarative or negotiated in the offer/answer model.
必须根据RFC 2434标准操作在RFC中描述参数的语义。如果可以将值分配给参数，则必须根据RFC 2434标准操作在RFC中描述可以分配的格式和可能的值。此外，必须指定参数是声明性的还是在提供/应答模型中协商的。
The following SRTP session parameters are hereby registered:
特此注册以下SRTP会话参数：
KDR UNENCRYPTED_SRTP UNENCRYPTED_SRTCP UNAUTHENTICATED_SRTP FEC_ORDER FEC_KEY WSH
KDR未加密\u SRTP未加密\u SRTCP未经身份验证\u SRTP FEC\u顺序FEC\u密钥WSH
The reference for these parameters is this document.
这些参数的参考是本文档。
This document is a product of the IETF MMUSIC working group and has benefited from comments from its participants. This document also benefited from discussions with Elisabetta Cararra, Earl Carter, Per Cederqvist, Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer, Mike Thomas, Brian Weis, and Magnus Westerlund.
本文件是IETF MMUSIC工作组的产品，并从参与者的评论中获益。本文件还得益于与Elisabetta Cararra、Earl Carter、Per Cederqvist、Bill Foster、Matt Hammer、Cullen Jennings、Paul Kyzivat、David McGrew、Mats Naslund、Dave Oran、Jonathan Rosenberg、Dave Singer、Mike Thomas、Brian Weis和Magnus Westerlund的讨论。
[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月。
[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月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[RFC2828]Shirey，R.，“互联网安全词汇表”，FYI 36，RFC 2828，2000年5月。
[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月。
[RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]Eastlake 3rd，D.，Crocker，S.，和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[RFC3548]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC3548，2003年7月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[sprecon] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol Media Streams", Work in Progress, October 2005.
[sprecon]Andreasen，F.和D.Wing，“会话描述协议媒体流的安全先决条件”，正在进行的工作，2005年10月。
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002.
[RFC3407]Andreasen，F.，“会话描述协议（SDP）简单能力声明”，RFC3407，2002年10月。
[Bellovin] Bellovin, S., "Problem Areas for the IP Security Protocols," in Proceedings of the Sixth Usenix Unix Security Symposium, pp. 1-16, San Jose, CA, July 1996.
[Bellovin]Bellovin，S.，“IP安全协议的问题领域”，《第六届Usenix Unix安全研讨会论文集》，第1-16页，加利福尼亚州圣何塞，1996年7月。
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[GDOI]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[kink] Sakane, S., Kamada, K., Thomas, M. and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
[kink]Sakane，S.，Kamada，K.，Thomas，M.和J.Vilhuber，“Kerberized Internet密钥协商（kink）”，RFC 4430，2006年3月。
[ike] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[ike]Kaufman，C.，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[ipsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[ipsec]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[maxprate] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[maxprate]Westerlund，M.“会话描述协议（SDP）的传输无关带宽修改器”，RFC 38902004年9月。
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[RFC2733]Rosenberg，J.和H.Schulzrinne，“通用前向纠错的RTP有效载荷格式”，RFC 2733，1999年12月。
[s/mime] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[s/mime]Ramsdell，B.，“安全/多用途Internet邮件扩展（s/mime）版本3.1消息规范”，RFC 3851，2004年7月。
[pgp/mime] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[pgp/mime]Elkins，M.，“具有良好隐私的mime安全性（pgp）”，RFC 2015，1996年10月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[keymgt] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[keymgt]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，2006年7月。
[mikey] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[mikey]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“mikey:多媒体互联网键控”，RFC 3830，2004年8月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[skeme] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for the Internet", ISOC Secure Networks and Distributed Systems Symposium, San Diego, 1996.
[skeme]Krawczyk，H.，“skeme：一种通用的互联网安全密钥交换机制”，ISOC安全网络和分布式系统研讨会，圣地亚哥，1996年。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]Camarillo，G.，Marshall，W.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003.
[srtpf]Ott，J.和E.Carrara，“基于RTCP的反馈的扩展安全RTP配置文件（RTP/SAVPF）”，正在进行的工作，2003年10月。
[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月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002.
[RFC3311]Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年9月。
Appendix A - Rationale for Keying Material Directionality
附录A-键控材料方向性的基本原理
SDP security descriptions define the keying material for the sending direction, which is included in the SDP. Thus, the key that is carried in an SDP message is a decryption key for the receiver of that SDP message. This is in contrast to the majority of information included in SDP, which describes information for the receiving (or receiving and sending) direction. This reversed information directionality generates some challenges with using the mechanism in the offer/answer model and in particular with SIP, where early media and forking require special consideration (as described in Section 7.3). There are however good reasons for why this was done, which can be summarized as follows:
SDP安全性描述定义了SDP中包含的发送方向的键控材料。因此，SDP消息中携带的密钥是该SDP消息的接收者的解密密钥。这与SDP中包含的大多数信息形成对比，SDP描述了接收（或接收和发送）方向的信息。这种反向信息方向性在提供/应答模型中使用机制时产生了一些挑战，尤其是在SIP中，早期媒体和分叉需要特别考虑（如第7.3节所述）。然而，这样做有很好的理由，可以总结如下：
First of all, there is the general security philosophy of letting the entity that sends traffic decide what key to use for protecting it. SRTP uses counter mode, which is secure when counters do not overlap among senders who share a master key; the surest way to avoid counter overlap is for each endpoint to generate its own master key. Secondly, if SDP security descriptions had been designed to keep the normal SDP information directionality, it would have resulted in problems with supporting early media and SIP forking: If an offer generates multiple answers and the keying material was for the receive direction, some of the parameter values (e.g. lifetime) would have to be shared between all the answerers (senders of media), which would lead to considerable complexity, possibly requiring changes or extensions to SRTP. Other problems were discovered as well, which we describe further below.
首先，一般的安全理念是让发送流量的实体决定使用什么密钥来保护流量。SRTP使用计数器模式，当共享主密钥的发送方之间的计数器不重叠时，该模式是安全的；避免计数器重叠的最可靠方法是每个端点生成自己的主密钥。其次，如果SDP安全性描述被设计为保持正常的SDP信息方向性，则可能会导致支持早期媒体和SIP分叉的问题：如果提供生成多个答案，并且键入材料用于接收方向，则一些参数值（例如，寿命）必须在所有应答者（媒体发送者）之间共享，这将导致相当的复杂性，可能需要对SRTP进行更改或扩展。还发现了其他问题，我们将在下面进一步描述。
In the following scenarios, we analyze what would occur if SDP security descriptions had been designed so that the keying material was the receive keying material (rather than its actual design, where the keying material is the sending keying material):
在以下场景中，我们分析了如果SDP安全性描述的设计使键控材料为接收键控材料（而不是其实际设计，其中键控材料为发送键控材料），会发生什么情况：
Scenario A: Non-Forking Case
场景A：非分叉情况
In this scenario, the offer includes the receiving keying material, the answerer receives it and starts sending data packets towards the offerer. If there was a single crypto attribute in the offer, there would be no ambiguity about which crypto suite was being used and, hence, the incoming packet could be processed. However, in the case where the offer included multiple alternative crypto-attributes, the offerer would not know which one was chosen, and hence, if the offerer received packets before the answer came back, the offerer would be unable to process those packets (problem 1). (Use of the MKI has been suggested as one possible solution to that, however it incurs a per-packet overhead.)
在这种情况下，要约包括接收键控材料，应答者接收该材料并开始向要约者发送数据包。如果要约中只有一个加密属性，那么使用哪一个加密套件就不会有歧义，因此可以处理传入的数据包。然而，在要约包括多个备选加密属性的情况下，要约人将不知道选择了哪一个，因此，如果要约人在答复返回之前收到数据包，则要约人将无法处理这些数据包（问题1）。（有人建议使用MKI作为一种可能的解决方案，但它会导致每个数据包的开销。）
Scenario B: Serial Forking Case
场景B：串行分叉情况
In this scenario, Alice generates an offer to Bob, who starts sending (early) media towards Alice (no answer returned yet). In this scenario, we assume we aren't also encountering Scenario A (e.g., the offer includes only a single crypto-attribute) and that Bob is using a Synchronization Source (SSRC) value of 1 for his SRTP and SRTCP packets. Alice thus has a crypto-context for SSRC 1, including the associated ROC (Roll Over Counter) and SEQ (RTP Sequence Number). Bob now forwards the call to Carol (Bob still has not generated an answer). At this point, Bob has Alice's key, which sometimes might be a security weakness. As the exchange proceeds, Carol gets the original offer, including the offered crypto-attribute and starts sending media packets towards Alice. It just so happens that Carol chooses an SSRC value of 1, as did Bob. When Carol starts generating packets, there is a potential for what RFC 3711 calls a "two-time pad" issue (problem 2), as well as the potential for the ROC to be out of sync between Alice and Carol (problem 3). Note that since Bob and Carol are (presumably) using different source transport addresses, the SSRC reuse does not constitute an SSRC collision (although it may still be interpreted as such by Alice). Per RFC 3711, since the master key would be shared between Bob and Carol in this case, it is RECOMMENDED that Alice leave the session at that point in order to avoid the two-time pad issue. It should also be noted that RFC 3711 recommends against sharing SRTP master keys, which forking may accidentally introduce when the keying material is for the receiving direction.
在这个场景中，Alice向Bob生成一个报价，Bob开始向Alice发送（早期）媒体（还没有返回答案）。在这个场景中，我们假设我们没有遇到场景A（例如，报价仅包含一个加密属性），Bob对他的SRTP和SRTCP数据包使用的同步源（SSRC）值为1。因此，Alice具有SSRC 1的加密上下文，包括相关的ROC（滚动计数器）和SEQ（RTP序列号）。Bob现在将呼叫转发给Carol（Bob尚未生成应答）。此时，Bob拥有Alice的密钥，这有时可能是一个安全漏洞。随着交换的进行，Carol获得了原始报价，包括提供的加密属性，并开始向Alice发送媒体包。恰巧Carol选择了SSRC值1，Bob也选择了。当Carol开始生成数据包时，可能会出现RFC 3711所称的“两次pad”问题（问题2），以及Alice和Carol之间的ROC可能不同步（问题3）。请注意，由于Bob和Carol（可能）使用不同的源传输地址，因此SSRC重用并不构成SSRC冲突（尽管Alice可能仍将其解释为SSRC冲突）。根据RFC 3711，在这种情况下，由于主密钥将在Bob和Carol之间共享，因此建议Alice在此时退出会话，以避免两次pad问题。还应注意，RFC 3711建议不要共享SRTP主钥匙，当钥匙材料用于接收方向时，可能会意外引入分叉。
If we consider the above scenario again, but this time with keying material in the offer (and answer) being the sending keying material (as specified by SDP security descriptions), the scenario instead looks as follows: Bob again chooses SSRC 1, and Bob will
如果我们再次考虑上面的场景，但是这次在提供（和答案）中的密钥材料是发送密钥材料（如SDP安全描述所指定的），该场景相反如下：鲍伯再次选择SSRC 1，而鲍伯将
need to send back an answer to Alice, since Alice needs to learn Bob's sending key. Bob also starts sending media towards Alice (clipping may occur until Alice receives Bob's answer). Bob again forwards the call to Carol who also starts sending early media using SSRC 1. However, Carol needs to generate a new answer (for the dialog between Alice and Carol) in order for Alice to process Carol's packets . Upon receiving this answer, Alice can initiate a new offer/answer exchange (to move the session to another transport address as described in Section 7.3). In this case, there is one master key per session and a unique keystream regardless of whether or not SSRCs collide.
需要将答案发送回Alice，因为Alice需要学习Bob的发送键。Bob也开始向Alice发送媒体（在Alice收到Bob的回答之前可能会进行剪辑）。Bob再次将呼叫转发给Carol，Carol也开始使用SSRC 1发送早期媒体。但是，为了让Alice处理Carol的数据包，Carol需要生成一个新的答案（用于Alice和Carol之间的对话）。收到此应答后，Alice可以启动新的报价/应答交换（将会话移动到第7.3节所述的另一个传输地址）。在这种情况下，无论SSRC是否冲突，每个会话都有一个主密钥和一个唯一的密钥流。
Scenario C: Parallel Forking Case
场景C：并行分叉情况
In this scenario, Alice generates an offer (with receive keying material) that gets forked to Bob and Carol in parallel. Bob and Carol both start sending packets (early media) to Alice. If Bob and Carol choose different SSRCs, everything is fine initially. However, one of the crypto context parameters is the master key lifetime, and since Bob and Carol are sharing the same master key (unbeknownst to either), they do not know when they need to rekey (problem 4). If they choose the same SSRC, we have the two-time pad problem again (problem 2).
在这个场景中，Alice生成了一个报价（带有接收键控材料），该报价将并行地分给Bob和Carol。Bob和Carol都开始向Alice发送数据包（早期媒体）。如果Bob和Carol选择不同的SSRC，最初一切都很好。然而，加密上下文参数之一是主密钥生存期，由于Bob和Carol共享相同的主密钥（两人都不知道），他们不知道何时需要重新密钥（问题4）。如果他们选择相同的SSRC，我们又出现了两次pad问题（问题2）。
In summary, if keying material were for the receive direction, we would have the following problems:
总之，如果键控材质用于接收方向，我们将出现以下问题：
- Problem 1: Offerer does not know which of multiple crypto offers was chosen by answerer.
- 问题1：报价人不知道应答人选择了多个加密报价中的哪一个。
- Problem 2: SSRC reuse (or SSRC collisions) between multiple answerers (serial or parallel forking) may lead to the two-time pad issue.
- 问题2：多个应答器（串行或并行分叉）之间的SSRC重用（或SSRC冲突）可能导致两次pad问题。
- Problem 3: Part of the crypto context parameters (specifically the ROC) is not communicated but derived, and if we allow multiple entities to use the same SSRC (sequentially), the ROC can be wrong.
- 问题3：部分加密上下文参数（特别是ROC）不是通信的，而是派生的，如果我们允许多个实体（顺序）使用相同的SSRC，ROC可能是错误的。
- Problem 4: All crypto contexts that share a master key need to maintain a shared set of counters (master key lifetime), and if we allow for multiple entities on different platforms to share a master key, we would need a mechanism to synchronize these counters.
- 问题4：共享主密钥的所有加密上下文都需要维护一组共享的计数器（主密钥生存期），如果我们允许不同平台上的多个实体共享主密钥，我们将需要一种机制来同步这些计数器。
Problem 1 could be addressed by using the MKI as proposed separately; however, it would result in using extra bandwidth for each SRTP media packet. Solving problem 2 implies a need for
问题1可以通过使用单独提议的MKI来解决；然而，这将导致为每个SRTP媒体分组使用额外的带宽。解决问题2意味着需要
being able to synchronize SSRC values with the answerer (or abandon the session when SSRC reuse or SSRC collisions occur). Problem 3 implies a need for being able to synchronize ROC values on a per SSRC basis (or abandon the session when SSRC reuse occurs). Problem 4 could be solved by having the offerer (Alice, i.e., the entity receiving media) determine how many packets have actually been generated by the total set of senders to Alice and, hence, be the one to initiate the rekeying. In the case of packet losses, etc. this is not foolproof, but in practice it could probably be addressed by use of a reasonable safety margin.
能够与应答者同步SSRC值（或者在发生SSRC重用或SSRC冲突时放弃会话）。问题3意味着需要能够在每个SSRC的基础上同步ROC值（或者在发生SSRC重用时放弃会话）。问题4可以通过让提供方（Alice，即实体接收媒体）确定发送给Alice的发送方的总集合实际生成了多少个分组来解决，因此，是发起密钥更新的一方。在数据包丢失等情况下，这并不是万无一失的，但在实践中，可以通过使用合理的安全裕度来解决。
In conclusion, it would be expected from an offer/answer and SIP point of view to have the offer (and answer) keying material be the receive keying material; however, doing so would trade security for SIP friendliness, e.g., two-time pad and master key lifetime issues, and violate the RFC 3711 rule for sharing an SRTP master key across SRTP sessions.
总之，从要约/应答和SIP的角度来看，期望要约（和应答）键控材料为接收键控材料；但是，这样做会以安全性换取SIP友好性，例如，两次pad和主密钥生存期问题，并违反RFC 3711在SRTP会话之间共享SRTP主密钥的规则。
Authors' Addresses
作者地址
Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, New Jersey 08837 USA
Flemming Andreasen Cisco Systems，Inc.美国新泽西州爱迪生市索纳尔街499号8楼，邮编08837
EMail: fandreas@cisco.com
EMail: fandreas@cisco.com
Mark Baugher 5510 SW Orchid Street Portland, Oregon 97219 USA
美国俄勒冈州波特兰兰花街西南5510号马克·鲍格尔，邮编：97219
EMail: mbaugher@cisco.com
EMail: mbaugher@cisco.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Dan Wing Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。