Internet Engineering Task Force (IETF) J. Lennox
Request for Comments: 6904 Vidyo
Updates: 3711 April 2013
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Lennox
Request for Comments: 6904 Vidyo
Updates: 3711 April 2013
Category: Standards Track
ISSN: 2070-1721
Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)
安全实时传输协议（SRTP）中报头扩展的加密
Abstract
摘要
The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.
安全实时传输协议（SRTP）提供实时传输协议（RTP）数据包报头的身份验证，但不提供加密。然而，RTP报头扩展可能携带多媒体会话参与者希望保密的敏感信息。本文提供了一种扩展SRTP机制的机制，用于选择性地加密SRTP中的RTP头扩展。
This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted.
本文档更新了安全实时传输协议规范RFC 3711，要求所有未来的SRTP加密转换指定如何加密RTP头扩展。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6904.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6904.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encryption Mechanism . . . . . . . . . . . . . . . . . . . . 4
3.1. Example Encryption Mask . . . . . . . . . . . . . . . . . 6
3.2. Header Extension Keystream Generation for Existing
Encryption Transforms . . . . . . . . . . . . . . . . . . 7
3.3. Header Extension Keystream Generation for Future
Encryption Transforms . . . . . . . . . . . . . . . . . . 8
4. Signaling (Setup) Information . . . . . . . . . . . . . . . . 8
4.1. Backward Compatibility . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 13
A.1. Key Derivation Test Vectors . . . . . . . . . . . . . . . 13
A.2. Header Encryption Test Vectors Using AES-CM . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encryption Mechanism . . . . . . . . . . . . . . . . . . . . 4
3.1. Example Encryption Mask . . . . . . . . . . . . . . . . . 6
3.2. Header Extension Keystream Generation for Existing
Encryption Transforms . . . . . . . . . . . . . . . . . . 7
3.3. Header Extension Keystream Generation for Future
Encryption Transforms . . . . . . . . . . . . . . . . . . 8
4. Signaling (Setup) Information . . . . . . . . . . . . . . . . 8
4.1. Backward Compatibility . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 13
A.1. Key Derivation Test Vectors . . . . . . . . . . . . . . . 13
A.2. Header Encryption Test Vectors Using AES-CM . . . . . . . 14
The Secure Real-time Transport Protocol [RFC3711] specification provides confidentiality, message authentication, and replay protection for multimedia payloads sent using the Real-time Protocol (RTP) [RFC3550]. However, in order to preserve RTP header compression efficiency, SRTP provides only authentication and replay protection for the headers of RTP packets, not confidentiality.
安全实时传输协议[RFC3711]规范为使用实时协议（RTP）[RFC3550]发送的多媒体有效载荷提供保密性、消息认证和重播保护。然而，为了保持RTP报头压缩效率，SRTP仅为RTP数据包的报头提供身份验证和重播保护，而不提供机密性。
For the standard portions of an RTP header, providing only authentication and replay protection does not normally present a problem, as the information carried in an RTP header does not provide much information beyond that which an attacker could infer by observing the size and timing of RTP packets. Thus, there is little need for confidentiality of the header information.
对于RTP报头的标准部分，仅提供身份验证和重播保护通常不会出现问题，因为RTP报头中携带的信息不会提供攻击者通过观察RTP数据包的大小和时间推断出的更多信息。因此，不需要对报头信息进行保密。
However, the security requirements can be different for information carried in RTP header extensions. A number of recent proposals for header extensions using the mechanism described in "A General Mechanism for RTP Header Extensions" [RFC5285] carry information for which confidentiality could be desired or essential. Notably, two recent specifications ([RFC6464] and [RFC6465]) contain information about per-packet sound levels of the media data carried in the RTP payload and specify that exposing this information to an eavesdropper is unacceptable in many circumstances (as described in the Security Considerations sections of those RFCs).
但是，RTP头扩展中携带的信息的安全要求可能不同。使用“RTP报头扩展的通用机制”[RFC5285]中描述的机制进行报头扩展的一些最新建议包含可能需要保密的信息。值得注意的是，最近的两个规范（[RFC6464]和[RFC6465]）包含关于RTP有效载荷中承载的媒体数据的每包声级的信息，并规定在许多情况下向窃听者公开该信息是不可接受的（如那些RFC的安全注意事项部分所述）。
This document, therefore, defines a mechanism by which encryption can be applied to RTP header extensions when they are transported using SRTP. As an RTP sender may wish some extension information to be sent in the clear (for example, it may be useful for a network monitoring device to be aware of RTP transmission time offsets [RFC5450]), this mechanism can be selectively applied to a subset of the header extension elements carried in an SRTP packet.
因此，本文档定义了一种机制，在使用SRTP传输RTP头扩展时，可以通过该机制将加密应用于RTP头扩展。由于RTP发送方可能希望以明文形式发送一些扩展信息（例如，网络监视设备可以知道RTP传输时间偏移[RFC5450]），因此该机制可以选择性地应用于SRTP分组中携带的报头扩展元素的子集。
The mechanism defined by this document encrypts packets' header extensions using the same cryptographic algorithms and parameters as are used to encrypt the packets' RTP payloads. This document defines how this is done for the encryption transforms defined in [RFC3711], [RFC5669], and [RFC6188], which are the SRTP encryption transforms defined by Standards Track RFCs at the time of this writing. It also updates [RFC3711] to indicate that specifications of future SRTP encryption transforms must define how header extension encryption is to be performed.
本文档定义的机制使用与加密数据包RTP有效载荷相同的加密算法和参数加密数据包的报头扩展。本文档定义了如何对[RFC3711]、[RFC5669]和[RFC6188]中定义的加密转换执行此操作，这是在撰写本文时由标准跟踪RFC定义的SRTP加密转换。它还更新了[RFC3711]，指出未来SRTP加密转换的规范必须定义如何执行头扩展加密。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指出符合性实施的要求级别。
Encrypted header extension elements are carried in the same manner as non-encrypted header extension elements, as defined by [RFC5285]. The one- or two-byte header of the extension elements is not encrypted, nor is any of the header extension padding. If multiple different header extension elements are being encrypted, they have separate element identifier values, just as they would if they were not encrypted. Similarly, encrypted and non-encrypted header extension elements have separate identifier values.
按照[RFC5285]的定义，加密的报头扩展元素以与非加密的报头扩展元素相同的方式携带。扩展元素的一个或两个字节头未加密，任何头扩展填充也未加密。如果对多个不同的头扩展元素进行加密，则它们具有单独的元素标识符值，就像未加密时一样。类似地，加密和非加密头扩展元素具有单独的标识符值。
Encrypted header extension elements are carried only in packets encrypted using the Secure Real-time Transport Protocol [RFC3711]. To encrypt (or decrypt) encrypted header extension elements, an SRTP participant first uses the SRTP key derivation algorithm, specified in Section 4.3.1 of [RFC3711], to generate header encryption and header salting keys, using the same pseudorandom function family as is used for the key derivation for the SRTP session. These keys are derived as follows:
加密的报头扩展元素仅在使用安全实时传输协议[RFC3711]加密的数据包中携带。为了加密（或解密）加密的报头扩展元素，SRTP参与者首先使用[RFC3711]第4.3.1节中规定的SRTP密钥派生算法，使用与SRTP会话密钥派生相同的伪随机函数族生成报头加密和报头加密密钥。这些键的推导如下：
o k_he (SRTP header encryption): <label> = 0x06, n=n_e.
o k_he（SRTP头加密）：<label>=0x06，n=n_e。
o k_hs (SRTP header salting key): <label> = 0x07, n=n_s.
o k_hs（SRTP标头盐析键）：<label>=0x07，n=n_s。
where n_e and n_s are from the cryptographic context: the same size encryption key and salting key are used as are used for the SRTP payload. Additionally, the same master key, master salt, index, and key_derivation_rate are used as for the SRTP payload. (Note that since RTP headers, including header extensions, are authenticated in SRTP, no new authentication key is needed for header extensions.)
其中n_e和n_s来自加密上下文：使用与SRTP有效负载相同大小的加密密钥和satting密钥。此外，与SRTP有效负载使用相同的主密钥、主盐、索引和密钥导出率。（请注意，由于RTP标头（包括标头扩展）在SRTP中经过身份验证，因此标头扩展不需要新的身份验证密钥。）
A header extension keystream is generated for each packet containing encrypted header extension elements. The details of how this header extension keystream is generated depend on the encryption transform that is used for the SRTP packet. For encryption transforms that have been standardized as of the date of publication of this document, see Section 3.2; for requirements for new transforms, see Section 3.3.
为包含加密的报头扩展元素的每个数据包生成报头扩展密钥流。如何生成此标头扩展密钥流的详细信息取决于用于SRTP数据包的加密转换。关于截至本文件发布之日已标准化的加密转换，请参见第3.2节；有关新转换的要求，请参见第3.3节。
After the header extension keystream is generated, the SRTP participant then computes an encryption mask for the header extension, identifying the portions of the header extension that are, or are to be, encrypted. (For an example of this procedure, see Section 3.1.) This encryption mask corresponds to the entire payload of each header extension element that is encrypted. It does not include any non-encrypted header extension elements, any extension element headers, or any padding octets. The encryption mask has all-bits-1 octets (i.e., hexadecimal 0xff) for header extension octets that are to be encrypted and all-bits-0 octets for header extension octets that are not to be encrypted. The set of extension elements to be encrypted is communicated between the sender and the receiver using the signaling mechanisms described in Section 4.
在生成报头扩展密钥流之后，SRTP参与者然后计算报头扩展的加密掩码，识别报头扩展中已加密或将要加密的部分。（有关此过程的示例，请参阅第3.1节。）此加密掩码对应于加密的每个标头扩展元素的整个有效负载。它不包括任何未加密的头扩展元素、任何扩展元素头或任何填充八位字节。加密掩码具有用于要加密的报头扩展八位字节的所有位1八位字节（即十六进制0xff），以及用于不加密的报头扩展八位字节的所有位0八位字节。使用第4节中描述的信令机制在发送方和接收方之间传送要加密的扩展元素集。
This encryption mask is computed separately for every packet that carries a header extension. Based on the non-encrypted portions of the headers and the signaled list of encrypted extension elements, a receiver can always determine the correct encryption mask for any encrypted header extension.
该加密掩码是为每个带有报头扩展的数据包单独计算的。基于报头的非加密部分和加密扩展元素的信号列表，接收方始终可以确定任何加密报头扩展的正确加密掩码。
The SRTP participant bitwise-ANDs the encryption mask with the keystream to produce a masked keystream. It then bitwise exclusive-ORs the header extension with this masked keystream to produce the ciphertext version of the header extension. (Thus, octets indicated as all-bits-1 in the encrypted mask are encrypted, whereas those indicated as all-bits-0 are not.)
SRTP参与者将加密掩码与密钥流按位相加，以生成屏蔽密钥流。然后，它用这个屏蔽密钥流对报头扩展进行位异或运算，以生成报头扩展的密文版本。（因此，加密掩码中指示为all-bits-1的八位字节是加密的，而指示为all-bits-0的八位字节不是。）
The header extension encryption process does not include the "defined by profile" or "length" fields of the header extension, only the field that Section 5.3.1 of [RFC3550] calls "header extension" proper, starting with the first [RFC5285] ID and length. Thus, both the encryption mask and the keystream begin at this point.
标头扩展加密过程不包括标头扩展的“由配置文件定义”或“长度”字段，仅包括[RFC3550]第5.3.1节调用的“标头扩展”字段，从第一个[RFC5285]ID和长度开始。因此，加密掩码和密钥流都从这一点开始。
This header extension encryption process could, equivalently, be computed by considering the encryption mask as a mixture of the encrypted and unencrypted headers, i.e., as
该报头扩展加密过程可以等效地通过将加密掩码视为加密报头和未加密报头的混合来计算，即：
EncryptedHeader = (Encrypt(Key, Plaintext) AND MASK) OR
(Plaintext AND (NOT MASK))
EncryptedHeader = (Encrypt(Key, Plaintext) AND MASK) OR
(Plaintext AND (NOT MASK))
where Encrypt is the encryption function, MASK is the encryption mask, and AND, OR, and NOT are bitwise operations. This formulation of the encryption process might be preferred by implementations for which encryption is performed by a separate module and cannot be modified easily.
其中，Encrypt是加密函数，MASK是加密掩码，and、OR和NOT是按位操作。这种加密过程的公式可能是由单独模块执行加密且不容易修改的实现的首选。
The SRTP authentication tag is computed across the encrypted header extension, i.e., the data that is actually transmitted on the wire. Thus, header extension encryption MUST be done before the authentication tag is computed, and authentication tag validation MUST be done on the encrypted header extensions. For receivers, header extension decryption SHOULD be done only after the receiver has validated the packet's message authentication tag, and the receiver MUST NOT take any actions based on decrypted headers, prior to validating the authentication tag, that could affect the security or proper functioning of the system.
SRTP认证标签是通过加密的报头扩展计算的，即，实际在线路上传输的数据。因此，必须在计算身份验证标记之前进行头扩展加密，并且必须对加密的头扩展进行身份验证标记验证。对于接收者，只有在接收者验证了数据包的消息身份验证标签之后，才能进行报头扩展解密，并且在验证身份验证标签之前，接收者不得基于解密的报头采取任何可能影响系统安全性或正常功能的操作。
If a sender wished to send a header extension containing an encrypted SMPTE timecode [RFC5484] with ID 1, a plaintext transmission time offset [RFC5450] with ID 2, an encrypted audio level indication [RFC6464] with ID 3, and an encrypted NTP timestamp [RFC6051] with ID 4, the plaintext RTP header extension might look like this:
如果发送方希望发送包含ID为1的加密SMPTE时间码[RFC5484]、ID为2的明文传输时间偏移[RFC5450]、ID为3的加密音频电平指示[RFC6464]和ID为4的加密NTP时间戳[RFC6051]的报头扩展，则明文RTP报头扩展可能如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=1 | len=7 | SMTPE timecode (long form) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE timecode (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE (cont'd)| ID=2 | len=2 | toffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| toffset (ct'd)| ID=3 | len=0 | audio level | ID=4 | len=6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp (Variant B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp (Variant B, cont'd) | padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=1 | len=7 | SMTPE timecode (long form) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE timecode (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE (cont'd)| ID=2 | len=2 | toffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| toffset (ct'd)| ID=3 | len=0 | audio level | ID=4 | len=6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp (Variant B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp (Variant B, cont'd) | padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Structure of Plaintext Example Header Extension
图1：纯文本示例头扩展的结构
The corresponding encryption mask would then be:
相应的加密掩码将是：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encryption Mask for Example Header Extension
图2：头扩展示例的加密掩码
In the mask, the octets corresponding to the payloads of the encrypted header extension elements are set to all-1 values, and the octets corresponding to non-encrypted header extension elements, element headers, and header extension padding are set to all-zero values.
在掩码中，与加密的报头扩展元素的有效负载相对应的八位字节被设置为all-1值，与非加密的报头扩展元素、元素报头和报头扩展填充相对应的八位字节被设置为所有零值。
3.2. Header Extension Keystream Generation for Existing Encryption Transforms
3.2. 为现有加密转换生成标头扩展密钥流
For the AES-CM and AES-f8 transforms [RFC3711], the SEED-CTR transform [RFC5669], and the AES_192_CM and AES_256_CM transforms [RFC6188], the header extension keystream SHALL be generated for each packet containing encrypted header extension elements using the same encryption transform and Initialization Vector (IV) as are used for that packet's SRTP payload, except that the SRTP encryption and salting keys k_e and k_s are replaced by the SRTP header encryption and header salting keys k_he and k_hs, respectively, as defined above.
对于AES-CM和AES-f8转换[RFC3711]、SEED-CTR转换[RFC5669]以及AES_192_CM和AES_256_CM转换[RFC6188]，应使用相同的加密转换和初始化向量（IV）为包含加密报头扩展元素的每个数据包生成报头扩展密钥流as用于该数据包的SRTP有效载荷，但SRTP加密和加密密钥k_e和k_s分别被SRTP报头加密和报头加密密钥k_he和k_hs替换，如上所述。
For the SEED-CCM and SEED-GCM transforms [RFC5669], the header extension keystream SHALL be generated using the algorithm specified above for the SEED-CTR algorithm. (Because the Authenticated Encryption with Associated Data (AEAD) transform used on the payload in these algorithms includes the RTP header, including the RTP header extension, in its Associated Authenticated Data (AAD), counter-mode encryption for the header extension is believed to be of equivalent cryptographic strength to the CCM and GCM transforms.)
对于SEED-CCM和SEED-GCM转换[RFC5669]，应使用上文为SEED-CTR算法指定的算法生成报头扩展密钥流。（因为在这些算法中，有效负载上使用的带关联数据的身份验证加密（AEAD）转换在其关联的身份验证数据（AAD）中包括RTP报头，包括RTP报头扩展），标头扩展的计数器模式加密被认为与CCM和GCM转换具有同等的加密强度。）
For the NULL encryption transform [RFC3711], the header extension keystream SHALL be all-zero.
对于空加密转换[RFC3711]，报头扩展密钥流应全部为零。
3.3. Header Extension Keystream Generation for Future Encryption Transforms
3.3. 用于未来加密转换的头扩展密钥流生成
When new SRTP encryption transforms are defined, this document updates [RFC3711] as follows: in addition to the rules specified in Section 6 of RFC 3711, the Standards Track RFC defining the new transform MUST specify how the encryption transform is to be used with header extension encryption.
当定义新的SRTP加密转换时，本文档更新[RFC3711]如下：除了RFC 3711第6节中指定的规则外，定义新转换的标准跟踪RFC必须指定如何将加密转换与标头扩展加密一起使用。
It is RECOMMENDED that new transformations follow the same mechanisms as are defined in Section 3.2 of this document if they are applicable and are believed to be cryptographically adequate for the transform in question.
建议新的转换遵循本文件第3.2节中定义的相同机制，前提是这些机制适用，并且被认为在密码方面适用于所讨论的转换。
Encrypted header extension elements are signaled in the Session Description Protocol (SDP) extmap attribute using the URI "urn:ietf:params:rtp-hdrext:encrypt" followed by the URI of the header extension element being encrypted, as well as any extensionattributes that extension normally takes. Figure 3 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] showing this grammar extension, extending the grammar defined in [RFC5285].
在会话描述协议（SDP）extmap属性中，使用URI“urn:ietf:params:rtp hdrext:encrypt”，后跟被加密的头扩展元素的URI，以及扩展通常采用的任何ExtensionAttribute，向加密的头扩展元素发送信号。图3给出了一个正式的扩展的Backus-Naur形式（ABNF）[RFC5234]显示了这个语法扩展，扩展了[RFC5285]中定义的语法。
enc-extensionname = %x75.72.6e.3a.69.65.74.66.3a.70.61.72.61.6d.73.3a
%x72.74.70.2d.68.64.72.65.78.74.3a.65.6e.63.72.79.70.74
; "urn:ietf:params:rtp-hdrext:encrypt" in lower case
enc-extensionname = %x75.72.6e.3a.69.65.74.66.3a.70.61.72.61.6d.73.3a
%x72.74.70.2d.68.64.72.65.78.74.3a.65.6e.63.72.79.70.74
; "urn:ietf:params:rtp-hdrext:encrypt" in lower case
extmap =/ mapentry SP enc-extensionname SP extensionname [SP extensionattributes]
extmap=/mapentry SP enc extensionname SP extensionname[SP extensionattributes]
; extmap, mapentry, extensionname, and extensionattributes ; are defined in [RFC5285]
; extmap、mapentry、extensionname和ExtensionAttribute；定义见[RFC5285]
Figure 3: Syntax of the "encrypt" extmap
图3：“加密”extmap的语法
Thus, for example, to signal an SRTP session using encrypted SMPTE timecodes [RFC5484], while simultaneously signaling plaintext transmission time offsets [RFC5450], an SDP document could contain the text shown in Figure 4 (line breaks have been added for formatting).
因此，例如，为了使用加密的SMPTE时间码[RFC5484]向SRTP会话发送信号，同时向明文传输时间偏移[RFC5450]发送信号，SDP文档可以包含图4所示的文本（已添加换行符以进行格式化）。
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32 \
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt \
urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32 \
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt \
urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
Figure 4: Sample SDP Document Offering Encrypted Headers
图4：提供加密头的示例SDP文档
This example uses SDP security descriptions [RFC4568] for SRTP keying, but this is merely for illustration. Any SRTP keying mechanism to establish session keys will work.
本例使用SDP安全描述[RFC4568]进行SRTP键控，但这仅用于说明。任何用于建立会话密钥的SRTP密钥机制都可以工作。
The extmap SDP attribute is defined in [RFC5285] as being either a session or media attribute. If the extmap for an encrypted header extension is specified as a media attribute, it MUST be specified only for media that use SRTP-based RTP profiles. If such an extmap is specified as a session attribute, there MUST be at least one media in the SDP session that uses an SRTP-based RTP profile. The session-level extmap applies to all the SRTP-based media in the session and MUST be ignored for all other (non-SRTP or non-RTP) media.
[RFC5285]中将extmap SDP属性定义为会话或媒体属性。如果将加密标头扩展的extmap指定为媒体属性，则必须仅为使用基于SRTP的RTP配置文件的媒体指定该属性。如果将此类extmap指定为会话属性，则SDP会话中必须至少有一个媒体使用基于SRTP的RTP配置文件。会话级extmap适用于会话中所有基于SRTP的介质，对于所有其他（非SRTP或非RTP）介质，必须忽略。
The "urn:ietf:params:rtp-hdrext:encrypt" extension MUST NOT be recursively applied to itself.
“urn:ietf:params:rtp hdrext:encrypt”扩展不能递归应用于自身。
Following the procedures in [RFC5285], an SDP endpoint that does not understand the "urn:ietf:params:rtp-hdrext:encrypt" extension URI will ignore the extension and, for SDP offer/answer, will negotiate not to use it.
按照[RFC5285]中的过程，不理解“urn:ietf:params:rtp hdrext:encrypt”扩展URI的SDP端点将忽略该扩展，并且对于SDP提供/应答，将协商不使用它。
For backward compatibility with endpoints that do not implement this specification, in a negotiated session (whether using offer/answer or some other means), best-effort encryption of a header extension element is possible: an endpoint MAY offer the same header extension element both encrypted and unencrypted. An offerer MUST offer only best-effort negotiation when lack of confidentiality would be acceptable in the backward-compatible case. Answerers (or equivalent peers in a negotiation) that understand header extension encryption SHOULD choose the encrypted form of the offered header extension element and mark the unencrypted form "inactive", unless they have an explicit reason to prefer the unencrypted form. In all cases, answerers MUST NOT negotiate the use of, and senders MUST NOT send, both encrypted and unencrypted forms of the same header extension.
为了与未实现此规范的端点向后兼容，在协商会话中（无论是使用提供/应答还是其他方式），可以尽最大努力加密标头扩展元素：端点可以提供加密和未加密的相同标头扩展元素。如果在向后兼容的情况下，缺乏保密性是可以接受的，则报价人必须尽最大努力进行谈判。理解标头扩展加密的应答者（或谈判中的等效对等方）应选择所提供标头扩展元素的加密形式，并将未加密形式标记为“非活动”，除非他们有明确的理由选择未加密形式。在所有情况下，应答者不得协商使用同一报头扩展的加密和未加密形式，发送者不得发送。
Note that, as always, users of best-effort encryption MUST be cautious of bid-down attacks, where a man-in-the-middle attacker removes a higher-security option, forcing endpoints to negotiate a lower-security one. Appropriate countermeasures depend on the signaling protocol in use, but users can ensure, for example, that signaling is integrity-protected.
请注意，与往常一样，尽力而为加密的用户必须小心出价下降攻击，中间人攻击者会删除更高安全性的选项，迫使端点协商较低安全性的选项。适当的对策取决于所使用的信令协议，但用户可以确保，例如，信令是完整性保护的。
The security properties of header extension elements protected by the mechanism in this document are equivalent to those for SRTP payloads.
本文档中受机制保护的头扩展元素的安全属性与SRTP有效负载的安全属性相同。
The mechanism defined in this document does not provide confidentiality about which header extension elements are used for a given SRTP packet, only for the content of those header extension elements. This appears to be in the spirit of SRTP itself, which does not encrypt RTP headers. If this is a concern, an alternate mechanism would be needed to provide confidentiality.
本文档中定义的机制不为给定SRTP数据包使用哪些报头扩展元素提供机密性，仅为这些报头扩展元素的内容提供机密性。这似乎符合SRTP本身的精神，它不加密RTP头。如果这是一个问题，则需要另一种机制来提供机密性。
For the two-byte-header form of header extension elements (0x100N, where "N" is the appbits field), this mechanism does not provide any protection to zero-length header extension elements (for which their presence or absence is the only information they carry). It also does not provide any protection for the appbits (field 256, the lowest four bits of the "defined by profile" field) of the two-byte headers. Neither of these features is present in the one-byte-header form of header extension elements (0xBEDE), so these limitations do not apply in that case.
对于报头扩展元素的两字节报头形式（0x100N，其中“N”是appbits字段），此机制不为零长度报头扩展元素提供任何保护（它们的存在或不存在是它们携带的唯一信息）。它也不为两字节头的appbits（字段256，“由概要文件定义”字段的最低四位）提供任何保护。这些特性都不存在于头扩展元素（0xBEDE）的单字节头形式中，因此这些限制不适用于这种情况。
This mechanism cannot protect RTP header extensions that do not use the mechanism defined in [RFC5285].
此机制无法保护不使用[RFC5285]中定义的机制的RTP标头扩展。
This document does not specify the circumstances in which extension header encryption should be used. Documents defining specific header extension elements should provide guidance on when encryption is appropriate for these elements.
本文档未指定在何种情况下应使用扩展标头加密。定义特定标头扩展元素的文档应提供有关加密何时适用于这些元素的指导。
If a middlebox does not have access to the SRTP authentication keys, it has no way to verify the authenticity of unencrypted RTP header extension elements (or the unencrypted RTP header), even though it can monitor them. Therefore, such middleboxes MUST treat such headers as untrusted and potentially generated by an attacker, in the same way as they treat unauthenticated traffic. (This does not mean that middleboxes cannot view and interpret such traffic, of course, only that appropriate skepticism needs to be maintained about the results of such interpretation.)
如果中间盒无权访问SRTP身份验证密钥，则它无法验证未加密RTP标头扩展元素（或未加密RTP标头）的真实性，即使它可以监视这些元素。因此，此类中间盒必须将此类标头视为不受信任且可能由攻击者生成，处理方式与处理未经验证的流量相同。（当然，这并不意味着中间商无法查看和解释此类流量，只是需要对此类解释的结果保持适当的怀疑。）
There is no mechanism defined to protect header extensions with different algorithms or encryption keys than are used to protect the RTP payloads. In particular, it is not possible to provide confidentiality for a header extension while leaving the payload in cleartext.
没有定义任何机制来使用与用于保护RTP有效负载不同的算法或加密密钥来保护报头扩展。特别是，在将有效负载保留为明文的同时，不可能为标头扩展提供机密性。
The dangers of using weak or NULL authentication with SRTP, described in Section 9.5 of [RFC3711], apply to encrypted header extensions as well. In particular, since some header extension elements will have some easily guessed plaintext bits, strong authentication is REQUIRED if an attacker setting such bits could have a meaningful effect on the behavior of the system.
[RFC3711]第9.5节中描述的在SRTP中使用弱或空身份验证的危险也适用于加密头扩展。特别是，由于某些标头扩展元素将具有一些容易猜测的明文位，如果攻击者设置这些位可能对系统行为产生有意义的影响，则需要进行强身份验证。
The technique defined in this document can be applied only to encryption transforms that work by generating a pseudorandom keystream and bitwise exclusive-ORing it with the plaintext, such as CTR or f8. It will not work with ECB, CBC, or any other encryption method that does not use a keystream.
本文档中定义的技术只能应用于通过生成伪随机密钥流并使用明文（如CTR或f8）对其进行逐位异或的加密转换。它不适用于ECB、CBC或任何其他不使用密钥流的加密方法。
This document defines a new extension URI to the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data:
本文档根据以下数据为实时传输协议（RTP）参数注册表的RTP Compact Header Extensions子域定义了一个新的扩展URI：
Extension URI: urn:ietf:params:rtp-hdrext:encrypt
Description: Encrypted header extension element
Contact: jonathan@vidyo.com
Reference: RFC 6904
Extension URI: urn:ietf:params:rtp-hdrext:encrypt
Description: Encrypted header extension element
Contact: jonathan@vidyo.com
Reference: RFC 6904
Thanks to Benoit Claise, Roni Even, Stephen Farrell, Kevin Igoe, Joel Jaeggli, David McGrew, David Singer, Robert Sparks, Magnus Westerlund, Qin Wu, and Felix Wyss for their comments and suggestions in the development of this specification.
感谢Benoit Claise、Roni Even、Stephen Farrell、Kevin Igoe、Joel Jaeggli、David McGrew、David Singer、Robert Sparks、Magnus Westerlund、Qin Wu和Felix Wyss在本规范制定过程中提出的意见和建议。
[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月。
[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月。
[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月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008.
[RFC5285]Singer，D.和H.Desneni，“RTP标头扩展的一般机制”，RFC 5285，2008年7月。
[RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)", RFC 5669, August 2010.
[RFC5669]Yoon，S.，Kim，J.，Park，H.，Jeong，H.，和Y.Won，“种子密码算法及其与安全实时传输协议（SRTP）的使用”，RFC 5669，2010年8月。
[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure RTP", RFC 6188, March 2011.
[RFC6188]McGrew，D.“AES-192和AES-256在安全RTP中的使用”，RFC 6188，2011年3月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568]Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 4568，2006年7月。
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in RTP Streams", RFC 5450, March 2009.
[RFC5450]Singer，D.和H.Desneni，“RTP流中的传输时间偏移”，RFC 54502009年3月。
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 5484, March 2009.
[RFC5484]Singer，D.“将时间码与RTP流相关联”，RFC 5484，2009年3月。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.
[RFC6051]Perkins，C.和T.Schierl，“RTP流的快速同步”，RFC 60512010年11月。
[RFC6464] Lennox, J., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, December 2011.
[RFC6464]Lennox，J.，Ivov，E.，和E.Marocco，“用于客户端到混音器音频电平指示的实时传输协议（RTP）头扩展”，RFC 64642011年12月。
[RFC6465] Ivov, E., Marocco, E., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, December 2011.
[RFC6465]Ivov，E.，Marocco，E.，和J.Lennox，“混音器到客户端音频电平指示的实时传输协议（RTP）头扩展”，RFC 6465，2011年12月。
This section provides test data for the header extension key derivation function, using AES-128 in Counter Mode. (The algorithms and keys used are the same as those for the test vectors in Appendix B.3 of [RFC3711].)
本节在计数器模式下使用AES-128，为标头扩展密钥派生函数提供测试数据。（使用的算法和键与[RFC3711]附录B.3中测试向量的算法和键相同。）
The inputs to the key derivation function are the 16-octet master key and the 14-octet master salt:
密钥派生函数的输入是16个八位字节的主密钥和14个八位字节的主密钥：
master key: E1F97A0D3E018BE0D64FA32C06DE4139
master key: E1F97A0D3E018BE0D64FA32C06DE4139
master salt: 0EC675AD498AFEEBB6960B3AABE6
主盐：0EC675AD498AFEEBB6960B3AABE6
Following [RFC3711], the input block for AES-CM is generated by exclusive-ORing the master salt with the concatenation of the encryption key label 0x06 with (index DIV kdr), then padding on the right with two null octets, which implements the multiply-by-2^16 operation (see Section 4.3.3 of [RFC3711]). The resulting value is then AES-CM-encrypted using the master key to get the cipher key.
在[RFC3711]之后，AES-CM的输入块是通过将加密密钥标签0x06与（索引DIV kdr）串联在一起对主盐进行异或生成的，然后在右侧填充两个空八位字节，这实现了乘2^16运算（参见[RFC3711]第4.3.3节）。然后使用主密钥对结果值进行AES CM加密，以获得密码密钥。
index DIV kdr: 000000000000
label: 06
master salt: 0EC675AD498AFEEBB6960B3AABE6
--------------------------------------------------
XOR: 0EC675AD498AFEEDB6960B3AABE6 (x, PRF input)
index DIV kdr: 000000000000
label: 06
master salt: 0EC675AD498AFEEBB6960B3AABE6
--------------------------------------------------
XOR: 0EC675AD498AFEEDB6960B3AABE6 (x, PRF input)
x*2^16: 0EC675AD498AFEEDB6960B3AABE60000 (AES-CM input)
x*2^16: 0EC675AD498AFEEDB6960B3AABE60000 (AES-CM input)
hdr. cipher key: 549752054D6FB708622C4A2E596A1B93 (AES-CM output)
hdr。密码密钥：549752054D6FB708622C4A2E596A1B93（AES-CM输出）
Next, we show how the cipher salt is generated. The input block for AES-CM is generated by exclusive-ORing the master salt with the concatenation of the encryption salt label. That value is padded and encrypted as above.
接下来，我们将展示密码salt是如何生成的。AES-CM的输入块是通过将主盐与加密盐标签的串联进行异或生成的。该值如上所述进行填充和加密。
index DIV kdr: 000000000000 label: 07 master salt: 0EC675AD498AFEEBB6960B3AABE6
索引分区kdr:000000000000标签：07主盐：0EC675AD498AFEEBB6960B3AABE6
--------------------------------------------------
XOR: 0EC675AD498AFEECB6960B3AABE6 (x, PRF input)
--------------------------------------------------
XOR: 0EC675AD498AFEECB6960B3AABE6 (x, PRF input)
x*2^16: 0EC675AD498AFEECB6960B3AABE60000 (AES-CM input)
x*2^16: 0EC675AD498AFEECB6960B3AABE60000 (AES-CM input)
AB01818174C40D39A3781F7C2D270733 (AES-CM ouptut)
AB018174C40D39A3781F7C2D270733（AES-CM ouptut）
hdr. cipher salt: AB01818174C40D39A3781F7C2D27
hdr。密码：AB018174C40D39A3781F7C2D27
This section provides test vectors for the encryption of a header extension using the AES_CM cryptographic transform.
本节提供了使用AES_CM加密转换对报头扩展进行加密的测试向量。
The header extension is encrypted using the header cipher key and header cipher salt computed in Appendix A.1. The header extension is carried in an SRTP-encrypted RTP packet with SSRC 0xCAFEBABE, sequence number 0x1234, and an all-zero rollover counter.
使用附录A.1中计算的报头密钥和报头密码salt对报头扩展进行加密。标头扩展在SRTP加密的RTP数据包中进行，该数据包具有SSRC 0xCAFEBABE、序列号0x1234和全零滚动计数器。
Session Key: 549752054D6FB708622C4A2E596A1B93 Session Salt: AB01818174C40D39A3781F7C2D27
会话密钥：549752054D6FB708622C4A2E596A1B93会话盐：AB01818174C40D39A3781F7C2D27
SSRC: CAFEBABE
Rollover Counter: 00000000
Sequence Number: 1234
----------------------------------------------
Init. Counter: AB018181BE3AB787A3781F7C3F130000
SSRC: CAFEBABE
Rollover Counter: 00000000
Sequence Number: 1234
----------------------------------------------
Init. Counter: AB018181BE3AB787A3781F7C3F130000
The SRTP session was negotiated to indicate that header extension ID values 1, 3, and 4 are encrypted.
SRTP会话已协商，以指示标头扩展ID值1、3和4已加密。
In hexadecimal, the header extension being encrypted is as follows (spaces have been added to show the internal structure of the header extension):
在十六进制中，要加密的标头扩展如下所示（已添加空格以显示标头扩展的内部结构）：
17 414273A475262748 22 0000C8 30 8E 46 55996386B395FB 00
17 414273A475262748 22 0000C8 30 8E 46 55996386B395FB 00
This header extension is 24 bytes long. (Its values are intended to represent plausible values of the header extension elements shown in Section 3.1, but their specific meaning is not important for the example.) The header extension "defined by profile" and "length" fields, which in this case are BEDE 0006 in hexadecimal, are not included in the encryption process.
此标头扩展名的长度为24字节。（其值旨在表示第3.1节中所示的标题扩展元素的合理值，但其具体含义在本例中并不重要。）加密过程中不包括标题扩展“由概要文件定义”和“长度”字段，在本例中为十六进制的BEDE 0006。
In hexadecimal, the corresponding encryption mask selecting the bodies of header extensions 1, 2, and 4 (corresponding to the mask in Figure 2) is:
在十六进制中，选择头扩展1、2和4主体的相应加密掩码（对应于图2中的掩码）为：
00 FFFFFFFFFFFFFFFF 00 000000 00 FF 00 FFFFFFFFFFFFFF 00
00 FFFFFFFFFFFFFF00 00000000 FFFFFF00 FFFFFFFFFFFFFF00
Finally, we compute the keystream from the session key and the initial counter, apply the mask to the keystream, and then exclusive-OR the keystream with the plaintext:
最后，我们从会话密钥和初始计数器计算密钥流，将掩码应用于密钥流，然后使用明文对密钥流进行异或：
Initial keystream: 1E19C8E1D481C779549ED1617AAA1B7A FC0D933AE7ED6CC8 Mask (hex): 00FFFFFFFFFFFFFFFF0000000000FF00 FFFFFFFFFFFFFF00 Masked keystream: 0019C8E1D481C7795400000000001B00 FC0D933AE7ED6C00 Plaintext: 17414273A475262748220000C8308E46 55996386B395FB00 Ciphertext: 17588A9270F4E15E1C220000C8309546 A994F0BC54789700
初始密钥流：1E19C8E1D481C779549ED1617AAA1B7A FC0D933AE7ED6CC8掩码（十六进制）：00FFFFFFFFFF000000FF00 FFFFFFFFFFFFFFFF00掩码密钥流：0019C8E1D481C7795400000000001B00 FC0D933AE7ED6C00明文：17414273A4752748220000C8308E46 55996386B395FB00密文：17588A9270F4E15E120000C83046 A994BC5479700
Author's Address
作者地址
Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US
Jonathan Lennox Vidyo，Inc.美国新泽西州哈肯萨克大街433号哈肯萨克七楼，邮编：07601
EMail: jonathan@vidyo.com
EMail: jonathan@vidyo.com