Network Working Group M. Baugher
Request for Comments: 4383 Cisco
Category: Standards Track E. Carrara
Royal Institute of Technology
February 2006
Network Working Group M. Baugher
Request for Comments: 4383 Cisco
Category: Standards Track E. Carrara
Royal Institute of Technology
February 2006
The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)
在安全实时传输协议（SRTP）中使用定时高效流丢失容忍认证（TESLA）
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 memo describes the use of the Timed Efficient Stream Loss-tolerant Authentication (RFC 4082) transform within the Secure Real-time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams.
本备忘录描述了在安全实时传输协议（SRTP）内使用定时高效流丢失容忍认证（RFC 4082）转换来为多播和广播数据流提供数据源认证。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Notational Conventions .....................................3
2. SRTP ............................................................3
3. TESLA ...........................................................4
4. Usage of TESLA within SRTP ......................................5
4.1. The TESLA Extension ........................................5
4.2. SRTP Packet Format .........................................6
4.3. Extension of the SRTP Cryptographic Context ................7
4.4. SRTP Processing ............................................8
4.4.1. Sender Processing ...................................9
4.4.2. Receiver Processing .................................9
4.5. SRTCP Packet Format .......................................11
4.6. TESLA MAC .................................................13
4.7. PRFs ......................................................13
5. TESLA Bootstrapping and Cleanup ................................14
6. SRTP TESLA Default Parameters ..................................14
7. Security Considerations ........................................15
8. Acknowledgements ...............................................16
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................17
1. Introduction ....................................................2
1.1. Notational Conventions .....................................3
2. SRTP ............................................................3
3. TESLA ...........................................................4
4. Usage of TESLA within SRTP ......................................5
4.1. The TESLA Extension ........................................5
4.2. SRTP Packet Format .........................................6
4.3. Extension of the SRTP Cryptographic Context ................7
4.4. SRTP Processing ............................................8
4.4.1. Sender Processing ...................................9
4.4.2. Receiver Processing .................................9
4.5. SRTCP Packet Format .......................................11
4.6. TESLA MAC .................................................13
4.7. PRFs ......................................................13
5. TESLA Bootstrapping and Cleanup ................................14
6. SRTP TESLA Default Parameters ..................................14
7. Security Considerations ........................................15
8. Acknowledgements ...............................................16
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................17
Multicast and broadcast communications introduce some new security challenges compared to unicast communication. Many multicast and broadcast applications need "data origin authentication" (DOA), or "source authentication", in order to guarantee that a received message had originated from a given source, and was not manipulated during the transmission. In unicast communication, a pairwise security association between one sender and one receiver can provide data origin authentication using symmetric-key cryptography (such as a message authentication code, MAC). When the communication is strictly pairwise, the sender and receiver agree upon a key that is known only to them.
与单播通信相比，多播和广播通信带来了一些新的安全挑战。许多多播和广播应用程序需要“数据源身份验证”（DOA）或“源身份验证”，以确保接收到的消息来自给定的源，并且在传输过程中未被操纵。在单播通信中，一个发送方和一个接收方之间的成对安全关联可以使用对称密钥加密（如消息认证码MAC）提供数据源认证。当通信严格成对时，发送方和接收方同意一个只有他们知道的密钥。
In groups, however, a key is shared among more than two members, and this symmetric-key approach does not guarantee data origin authentication. When there is a group security association [RFC4046] instead of a pairwise security association, any of the members can alter the packet and impersonate any other member. The MAC in this case only guarantees that the packet was not manipulated by an attacker outside the group (and hence not in possession of the group key), and that the packet was sent by a source within the group.
但是，在组中，一个密钥在两个以上的成员之间共享，这种对称密钥方法不能保证数据源身份验证。当存在组安全关联[RFC4046]而不是成对安全关联时，任何成员都可以更改数据包并模拟任何其他成员。在这种情况下，MAC仅保证数据包不被组外的攻击者操纵（因此不拥有组密钥），并且数据包由组内的源发送。
Some applications cannot tolerate source ambiguity and need to identify the true sender from any other group member. A common way to solve the problem is by use of asymmetric cryptography, such as digital signatures. This method, unfortunately, suffers from high overhead in terms of time (to sign and verify) and bandwidth (to convey the signature in the packet).
某些应用程序不能容忍源歧义，需要从任何其他组成员中识别真正的发送者。解决这个问题的一种常见方法是使用非对称加密技术，如数字签名。不幸的是，这种方法在时间（签名和验证）和带宽（在数据包中传递签名）方面存在高开销。
Several schemes have been proposed to provide efficient data origin authentication in multicast and broadcast scenarios. The Timed Efficient Stream Loss-tolerant Authentication (TESLA) is one such scheme.
已经提出了几种方案来在多播和广播场景中提供有效的数据源身份验证。定时高效流丢失容忍认证（TESLA）就是这样一种方案。
This memo specifies TESLA authentication for SRTP. SRTP TESLA can provide data origin authentication to RTP applications that use group security associations (such as multicast RTP applications) so long as receivers abide by the TESLA security invariants [RFC4082].
本备忘录规定了SRTP的特斯拉认证。SRTP TESLA可以向使用组安全关联的RTP应用程序（如多播RTP应用程序）提供数据源身份验证，只要接收方遵守TESLA安全不变量[RFC4082]。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This specification assumes that the reader is familiar with both SRTP and TESLA. Few of their details are explained in this document, and the reader can find them in their respective specifications, [RFC3711] and [RFC4082]. This specification uses the same definitions as TESLA for common terms and assumes that the reader is familiar with the TESLA algorithms and protocols [RFC4082].
本规范假设读者熟悉SRTP和特斯拉。本文档中很少对其进行详细说明，读者可以在各自的规范[RFC3711]和[RFC4082]中找到它们。本规范使用与特斯拉相同的通用术语定义，并假设读者熟悉特斯拉算法和协议[RFC4082]。
The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile of RTP, which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the RTP control protocol, the Real-time Transport Control Protocol (RTCP). Note that the term "SRTP" may often be used to indicate SRTCP as well.
安全实时传输协议（SRTP）[RFC3711]是RTP的一个配置文件，它可以为RTP流量和RTP控制协议（实时传输控制协议（RTCP））提供机密性、消息认证和重播保护。注意，术语“SRTP”通常也可用于表示SRTCP。
SRTP is a framework that allows new security functions and new transforms to be added. SRTP currently does not define any mechanism to provide data origin authentication for group security associations. Fortunately, it is straightforward to add TESLA to the SRTP cryptographic framework.
SRTP是一个允许添加新安全功能和新转换的框架。SRTP目前没有定义任何机制来为组安全关联提供数据源身份验证。幸运的是，将特斯拉添加到SRTP加密框架很简单。
The TESLA extension to SRTP is defined in this specification, which assumes that the reader is familiar with the SRTP specification [RFC3711], its packet structure, and its processing rules. TESLA is
本规范中定义了SRTP的特斯拉扩展，该扩展假定读者熟悉SRTP规范[RFC3711]、其数据包结构及其处理规则。特斯拉是
an alternative message-authentication algorithm that authenticates messages from the source when a key is shared among two or more receivers.
一种替代的消息身份验证算法，当两个或多个接收者共享密钥时，对来自源的消息进行身份验证。
TESLA provides delayed per-packet data authentication and is specified in [RFC4082].
特斯拉提供延迟每包数据认证，并在[RFC4082]中规定。
In addition to its SRTP data-packet definition given here, TESLA needs an initial synchronization protocol and initial bootstrapping procedure. The synchronization protocol allows the sender and the receiver to compare their clocks and determine an upper bound of the difference. The synchronization protocol is outside the scope of this document.
除了这里给出的SRTP数据包定义外，特斯拉还需要一个初始同步协议和初始引导程序。同步协议允许发送方和接收方比较它们的时钟并确定差异的上限。同步协议不在本文档的范围内。
TESLA also requires an initial bootstrapping procedure to exchange needed parameters and the initial commitment to the key chain [RFC4082]. For SRTP, it is assumed that the bootstrapping is performed out-of-band, possibly using the key management protocol that is exchanging the security parameters for SRTP, e.g., [RFC3547, RFC3830]. Initial bootstrapping of TESLA is outside the scope of this document.
特斯拉还需要一个初始引导程序来交换所需的参数和对钥匙链的初始承诺[RFC4082]。对于SRTP，假设引导在带外执行，可能使用为SRTP交换安全参数的密钥管理协议，例如[RFC3547，RFC3830]。特斯拉的初始自举不在本文件范围内。
The present specification is an extension to the SRTP specification [RFC3711] and describes the use of TESLA with only a single key chain and delayed-authentication [RFC4082].
本规范是SRTP规范[RFC3711]的扩展，并描述了仅使用单个密钥链和延迟认证[RFC4082]的特斯拉的使用。
TESLA is an OPTIONAL authentication transform for SRTP. When used, TESLA adds the fields shown in Figure 1 per-packet. The fields added by TESLA are called "TESLA authentication extensions," whereas "authentication tag" or "integrity protection tag" indicate the normal SRTP integrity protection tag, when the SRTP master key is shared by more than two endpoints [RFC3711].
TESLA是SRTP的可选身份验证转换。使用时，特斯拉会为每个数据包添加图1所示的字段。特斯拉添加的字段称为“特斯拉认证扩展”，而当SRTP主密钥由两个以上的端点共享时，“认证标签”或“完整性保护标签”表示正常的SRTP完整性保护标签[RFC3711]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Disclosed Key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TESLA MAC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Disclosed Key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TESLA MAC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The "TESLA authentication extension".
图1。“特斯拉认证扩展”。
i: 32 bit, MANDATORY Identifier of the time interval i, corresponding to the key K_i, which is used to calculate the TESLA MAC of the current packet (and other packets sent in the current time interval i).
i:32位，时间间隔i的强制标识符，对应于密钥K_i，用于计算当前分组（以及在当前时间间隔i中发送的其他分组）的特斯拉MAC。
Disclosed Key: variable length, MANDATORY The disclosed key (K_(i-d)), which can be used to authenticate previous packets from earlier time intervals [RFC4082]. A Section 4.3 parameter establishes the size of this field.
公开密钥：可变长度，强制公开密钥（K_u2;（i-d）），可用于验证来自较早时间间隔的先前数据包[RFC4082]。第4.3节参数确定了该字段的大小。
TESLA MAC (Message Authentication Code): variable length, MANDATORY The MAC computed using the key K'_i (derived from K_i) [RFC4082], which is disclosed in a subsequent packet (in the Disclosed Key field). The MAC coverage is defined in Section 4.6. A Section 4.3 parameter establishes the size of this field.
特斯拉MAC（消息认证码）：可变长度，强制使用密钥K〃U i（源自K_i）[RFC4082]计算的MAC，该密钥在后续数据包中公开（在公开的密钥字段中）。MAC覆盖范围在第4.6节中定义。第4.3节参数确定了该字段的大小。
Figure 2 illustrates the format of the SRTP packet when TESLA is applied. When applied to RTP, the TESLA authentication extension SHALL be inserted before the (optional) SRTP MKI and (recommended) authentication tag (SRTP MAC).
图2说明了应用特斯拉时SRTP数据包的格式。当应用于RTP时，特斯拉认证扩展应插入（可选）SRTP MKI和（推荐）认证标签（SRTP MAC）之前。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+
|V=2|P|X| CC |M| PT | sequence number | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| timestamp | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| synchronization source (SSRC) identifier | | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| contributing source (CSRC) identifiers | | |
| .... | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| RTP extension (OPTIONAL) | | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | payload ... | | |
| | +-------------------------------+ | |
| | | RTP padding | RTP pad count | | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |
| | i | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ Disclosed Key ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ TESLA MAC ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+
| ~ MKI ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ MAC ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | |
+- Encrypted Portion TESLA Authenticated Portion ---+ |
|
Authenticated Portion ---+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+
|V=2|P|X| CC |M| PT | sequence number | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| timestamp | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| synchronization source (SSRC) identifier | | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| contributing source (CSRC) identifiers | | |
| .... | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| RTP extension (OPTIONAL) | | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | payload ... | | |
| | +-------------------------------+ | |
| | | RTP padding | RTP pad count | | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |
| | i | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ Disclosed Key ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ TESLA MAC ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+
| ~ MKI ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ MAC ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | |
+- Encrypted Portion TESLA Authenticated Portion ---+ |
|
Authenticated Portion ---+
Figure 2. The format of the SRTP packet when TESLA is applied.
图2。应用特斯拉时SRTP数据包的格式。
As in SRTP, the "Encrypted Portion" of an SRTP packet consists of the encryption of the RTP payload (including RTP padding when present) of the equivalent RTP packet.
与在SRTP中一样，SRTP分组的“加密部分”包括对等效RTP分组的RTP有效载荷（包括存在时的RTP填充）的加密。
The "Authenticated Portion" of an SRTP packet consists of the RTP header, the Encrypted Portion of the SRTP packet, and the TESLA authentication extension. Note that the definition is extended from [RFC3711] by the inclusion of the TESLA authentication extension.
SRTP数据包的“认证部分”包括RTP报头、SRTP数据包的加密部分和特斯拉认证扩展。请注意，通过加入特斯拉认证扩展，该定义从[RFC3711]扩展而来。
The "TESLA Authenticated Portion" of an SRTP packet consists of the RTP header and the Encrypted Portion of the SRTP packet. As shown in Figure 2, the SRTP MAC covers up to the MKI field but does not include the MKI. It is necessary for packet integrity that the SRTP-TESLA MAC tag be covered by the SRTP integrity check. SRTP does not cover the MKI field (because it does not need to be covered for SRTP packet integrity). In order to make the two tags (SRTP-TESLA MAC and SRTP-MAC) contiguous, we would need to redefine the SRTP specification to include the MKI in SRTP-MAC coverage. This change is impossible, so the MKI field separates the TESLA MAC from the SRTP MAC in the packet layout of Figure 2. This change to the packet format presents no problem to an implementation that supports the new SRTP-TESLA authentication transform.
SRTP数据包的“特斯拉认证部分”由RTP报头和SRTP数据包的加密部分组成。如图2所示，SRTP MAC覆盖了MKI字段，但不包括MKI。SRTP完整性检查必须覆盖SRTP-TESLA MAC标签，以确保数据包的完整性。SRTP不覆盖MKI字段（因为SRTP数据包完整性不需要覆盖该字段）。为了使两个标签（SRTP-TESLA MAC和SRTP-MAC）相邻，我们需要重新定义SRTP规范，将MKI包括在SRTP-MAC覆盖范围内。这种改变是不可能的，因此MKI字段在图2的数据包布局中将特斯拉MAC与SRTP MAC分开。对数据包格式的这种更改对支持新SRTP-TESLA认证转换的实现没有问题。
The lengths of the Disclosed Key and TESLA MAC fields are Section 4.3 parameters. As in SRTP, fields that follow the packet payload are not necessarily aligned on 32-bit boundaries.
公开密钥和特斯拉MAC字段的长度为第4.3节参数。与在SRTP中一样，数据包有效负载后面的字段不一定在32位边界上对齐。
When TESLA is used, the definition of cryptographic context in Section 3.2 of SRTP SHALL include the following extensions.
当使用特斯拉时，SRTP第3.2节中的加密上下文定义应包括以下扩展。
Transform-Dependent Parameters
变换相关参数
1. an identifier for the PRF (TESLA PRF), implementing the one-way function F(x) in TESLA (to derive the keys in the chain), and the one-way function F'(x) in TESLA (to derive the keys for the TESLA MAC, from the keys in the chain), e.g., to indicate HMAC-SHA1. See Section 6 for the default value.
1. PRF（特斯拉PRF）的标识符，实现特斯拉中的单向函数F（x）（用于导出链中的键）和特斯拉中的单向函数F’（x）（用于从链中的键导出特斯拉MAC的键），例如，表示HMAC-SHA1。有关默认值，请参见第6节。
2. a non-negative integer, n_p, determining the length of the F output; i.e., the length of the keys in the chain (that is also the key disclosed in an SRTP packet). See Section 6 for the default value.
2. 非负整数n_p，确定F输出的长度；i、 例如，链中密钥的长度（也就是在SRTP分组中公开的密钥）。有关默认值，请参见第6节。
3. a non-negative integer, n_f, determining the length of the output of F', i.e., of the key for the TESLA MAC. See Section 6 for the default value.
3. 一个非负整数n_f，用于确定f′的输出长度，即特斯拉MAC密钥的长度。有关默认值，请参见第6节。
4. an identifier for the TESLA MAC that accepts the output of F'(x) as its key, e.g., to indicate HMAC-SHA1. See Section 6 for the default value.
4. 特斯拉MAC的一种标识符，它接受F’（x）的输出作为其键，例如表示HMAC-SHA1。有关默认值，请参见第6节。
5. a non-negative integer, n_m, determining the length of the output of the TESLA MAC. See Section 6 for the default value.
5. 一个非负整数n_m，用于确定特斯拉MAC输出的长度。有关默认值，请参见第6节。
6. the beginning of the session T_0.
6. 会话的开始T_0。
7. the interval duration T_int (in msec).
7. 间隔持续时间T_int（毫秒）。
8. the key disclosure delay d (in number of intervals).
8. 密钥泄漏延迟d（以间隔数表示）。
9. the upper bound D_t (in sec) on the lag of the receiver clock relative to the sender clock (this quantity has to be calculated by the peers out-of-band).
9. 接收器时钟相对于发送器时钟滞后的上限D_t（以秒为单位）（该数量必须由带外对等方计算）。
10. a non-negative integer, n_c, determining the length of the key chain, K_0...K_n-1 of [RFC4082] (see also Section 6 of this document), which is determined based upon the expected duration of the stream.
10. 一个非负整数n_c，用于确定[RFC4082]的密钥链长度K_0…K_n-1（另请参见本文档第6节），该值根据流的预期持续时间确定。
11. the initial key of the chain to which the sender has committed himself.
11. 发送方已向其承诺的链的初始密钥。
F(x) is used to compute a keychain of keys in SRTP TESLA, as defined in Section 6. Also according to TESLA, F'(x) computes a TESLA MAC key with inputs as defined in Section 6.
F（x）用于计算第6节中定义的SRTP特斯拉的钥匙链。同样根据特斯拉，F’（x）使用第6节中定义的输入计算特斯拉MAC密钥。
Section 6 of this document defines the default values for the transform-specific TESLA parameters.
本文件第6节定义了特定于变换的特斯拉参数的默认值。
The SRTP packet processing is described in Section 3.3 of the SRTP specification [RFC3711]. The use of TESLA slightly changes the processing, as the SRTP MAC is checked upon packet arrival for DoS prevention, but the current packet is not TESLA-authenticated. Each packet is buffered until a subsequent packet discloses its TESLA key. The TESLA verification itself consists of some steps, such as tests of TESLA security invariants, that are described in Sections 3.5-3.7 of [RFC4082]. The words "TESLA computation" and "TESLA verification" hereby imply all those steps, which are not all spelled out in the following. In particular, notice that the TESLA verification implies checking the safety condition (Section 3.5 of [RFC4082]).
SRTP规范[RFC3711]第3.3节描述了SRTP数据包处理。特斯拉的使用略微改变了处理过程，因为在数据包到达时会检查SRTP MAC以防止DoS，但当前数据包未经特斯拉认证。每个数据包都被缓冲，直到后续数据包公开其特斯拉密钥。特斯拉验证本身包括一些步骤，如[RFC4082]第3.5-3.7节所述的特斯拉安全不变量测试。“特斯拉计算”和“特斯拉验证”这两个词在此暗示所有这些步骤，这些步骤并非在下文中详细说明。特别注意，特斯拉验证意味着检查安全条件（RFC4082第3.5节）。
As pointed out in [RFC4082], if the packet is deemed "unsafe", then the receiver considers the packet unauthenticated. It should discard unsafe packets, but, at its own risk, it may choose to use them unverified. Hence, if the safe condition does not hold, it is RECOMMENDED to discard the packet and log the event.
正如[RFC4082]中指出的，如果数据包被认为是“不安全的”，则接收方认为数据包未经验证。它应该丢弃不安全的数据包，但它可能会选择在未经验证的情况下使用这些数据包，风险自负。因此，如果安全条件不成立，建议丢弃数据包并记录事件。
The sender processing is as described in Section 3.3 of [RFC3711], up to step 5, inclusive. After that, the following process is followed:
发送方处理如[RFC3711]第3.3节所述，直至步骤5（包括步骤5）。之后，遵循以下过程：
6. When TESLA is applied, identify the key in the TESLA chain to be used in the current time interval, and the TESLA MAC key derived from it. Execute the TESLA computation to obtain the TESLA authentication extension for the current packet, by appending the current interval identifier (as i field), the disclosed key of the chain for the previous disclosure interval (i.e., the key for interval i is disclosed in interval i+d), and the TESLA MAC under the current key from the chain. This step uses the related TESLA parameters from the crypto context as for Step 4.
6. 应用特斯拉时，识别当前时间间隔内要使用的特斯拉链中的密钥，以及由此派生的特斯拉MAC密钥。通过附加当前间隔标识符（作为i字段）、先前公开间隔的链的公开密钥（即，间隔i的密钥在间隔i+d中公开）和来自链的当前密钥下的特斯拉MAC，执行特斯拉计算以获得当前分组的特斯拉认证扩展。与步骤4一样，该步骤使用加密上下文中的相关特斯拉参数。
7. If the MKI indicator in the SRTP crypto context is set to one, append the MKI to the packet.
7. 如果SRTP加密上下文中的MKI指示符设置为1，则将MKI附加到数据包。
8. When TESLA is applied, and if the SRTP authentication (external tag) is required (for DoS), compute the authentication tag as described in step 7 of Section 3.3 of the SRTP specification, but with coverage as defined in this specification (see Section 4.6).
8. 应用特斯拉时，如果需要SRTP认证（外部标签）（对于DoS），则按照SRTP规范第3.3节第7步所述计算认证标签，但覆盖范围如本规范所定义（见第4.6节）。
9. If necessary, update the rollover counter (step 8 in Section 3.3 of [RFC3711]).
9. 如有必要，更新滚动计数器（RFC3711第3.3节中的步骤8）。
The receiver processing is as described in Section 3.3 of [RFC3711], up to step 4, inclusive.
接收机处理如[RFC3711]第3.3节所述，直至步骤4（包括步骤4）。
To authenticate and replay-protect the current packet, the processing is as follows:
要对当前数据包进行身份验证和重放保护，处理如下：
First, check if the packet has been replayed (as per Section 3.3 of [RFC3711]). Note, however, that the SRTP replay list contains SRTP indices of recently received packets that have been authenticated by TESLA (i.e., replay list updates MUST NOT be based on SRTP MAC). If the packet is judged to be replayed, then the packet MUST be discarded, and the event SHOULD be logged.
首先，检查数据包是否已被重放（根据[RFC3711]第3.3节）。然而，请注意，SRTP重播列表包含最近接收到的经特斯拉认证的数据包的SRTP索引（即，重播列表更新不得基于SRTP MAC）。如果该数据包被判断为重播，则必须丢弃该数据包，并记录该事件。
Next, perform verification of the SRTP integrity protection tag (not the TESLA MAC), if present, using the rollover counter from the current packet, the authentication algorithm indicated in the cryptographic context, and the session authentication key. If the verification is unsuccessful, the packet MUST be discarded from further processing, and the event SHOULD be logged.
接下来，使用来自当前数据包的滚动计数器、加密上下文中指示的认证算法和会话认证密钥，执行SRTP完整性保护标签（而不是TESLA MAC）的验证（如果存在）。如果验证不成功，则必须从进一步处理中丢弃数据包，并记录事件。
If the verification is successful, remove and store the MKI (if present) and authentication tag fields from the packet. The packet is buffered, awaiting disclosure of the TESLA key in a subsequent packet.
如果验证成功，则从数据包中删除并存储MKI（如果存在）和身份验证标记字段。该数据包被缓冲，等待在随后的数据包中公开特斯拉密钥。
TESLA authentication is performed on a packet when the key is disclosed in a subsequent packet. Recall that a key for interval i is disclosed during interval i+d, i.e., the same key is disclosed in packets sent over d intervals of length t_int. If the interval identifier i from the packet (Section 4.1) has advanced more than d intervals from the highest value of i that has been received, then packets have been lost, and one or more keys MUST be computed as described in Section 3.2, second paragraph, of the TESLA specification [RFC4082]. The computation is performed recursively for all disclosed keys that have been lost, from the newly-received interval to the last-received interval.
当密钥在随后的分组中公开时，对分组执行特斯拉认证。回想一下，间隔i的密钥在间隔i+d期间公开，即，在长度为t_int的d个间隔上发送的数据包中公开相同的密钥。如果来自数据包（第4.1节）的间隔标识符i从已接收到的i的最高值提前了d个间隔以上，则数据包丢失，必须按照特斯拉规范[RFC4082]第3.2节第二段的规定计算一个或多个密钥。从新接收的间隔到最后接收的间隔，对丢失的所有公开密钥递归地执行计算。
When a newly-disclosed key is received or computed, perform the TESLA verification of the packet using the rollover counter from the packet, the TESLA security parameters from the cryptographic context, and the disclosed key. If the verification is unsuccessful, the packet MUST be discarded from further processing, and the event SHOULD be logged. If the TESLA verification is successful, remove the TESLA authentication extension from the packet.
当接收或计算新公开的密钥时，使用来自分组的翻转计数器、来自密码上下文的TESLA安全参数和公开的密钥来执行分组的TESLA验证。如果验证不成功，则必须从进一步处理中丢弃数据包，并记录事件。如果特斯拉验证成功，则从数据包中删除特斯拉认证扩展。
To decrypt the current packet, the processing is as follows:
要解密当前数据包，处理如下：
Decrypt the Encrypted Portion of the packet, using the decryption algorithm indicated in the cryptographic context, the session encryption key, and salt (if used) found in Step 4 with the index from Step 2.
使用加密上下文中指示的解密算法、会话加密密钥和步骤4中找到的salt（如果使用）以及步骤2中的索引对数据包的加密部分进行解密。
(Note that the order of decryption and TESLA verification is not mandated. It is RECOMMENDED that the TESLA verification be performed before decryption. TESLA application designers might choose to implement optimistic processing techniques such as notification of TESLA verification results after decryption or even after plaintext processing. Optimistic verification is beyond the scope of this document.)
（请注意，解密和特斯拉验证的顺序不是强制性的。建议在解密之前执行特斯拉验证。特斯拉应用程序设计者可以选择实施乐观处理技术，例如在解密后或甚至在明文处理后通知特斯拉验证结果。OptimISIC验证超出了本文件的范围。）
Update the rollover counter and highest sequence number, s_l, in the cryptographic context, using the packet index estimated in Step 2. If replay protection is provided, also update the Replay List (i.e., the Replay List is updated after the TESLA authentication is successfully verified).
使用步骤2中估计的数据包索引更新加密上下文中的滚动计数器和最高序列号s_l。如果提供重播保护，还应更新重播列表（即，在成功验证特斯拉认证后更新重播列表）。
Figure 3 illustrates the format of the SRTCP packet when TESLA is applied. The TESLA authentication extension SHALL be inserted before the MKI and authentication tag. Recall from [RFC3711] that in SRTCP the MKI is OPTIONAL, while the E-bit, the SRTCP index, and the authentication tag are MANDATORY. This means that the SRTP (external) MAC is MANDATORY also when TESLA is used.
图3说明了应用特斯拉时SRTCP数据包的格式。特斯拉认证扩展应插入MKI和认证标签之前。回想一下[RFC3711]，在SRTCP中，MKI是可选的，而E位、SRTCP索引和身份验证标记是必需的。这意味着使用特斯拉时，SRTP（外部）MAC也是强制性的。
As in SRTP, the "Encrypted Portion" of an SRTCP packet consists of the encryption of the RTCP payload of the equivalent compound RTCP packet, from the first RTCP packet, i.e., from the ninth (9) byte to the end of the compound packet.
与在SRTP中一样，SRTCP数据包的“加密部分”包括对等效复合RTCP数据包的RTCP有效载荷的加密，从第一个RTCP数据包开始，即从第九（9）个字节到复合数据包的结尾。
The "Authenticated Portion" of an SRTCP packet consists of the entire equivalent (eventually compound) RTCP packet, the E flag, the SRTCP index (after any encryption has been applied to the payload), and the TESLA extension. Note that the definition is extended from [RFC3711] by the inclusion of the TESLA authentication extension.
SRTCP数据包的“认证部分”包括整个等效（最终复合）RTCP数据包、E标志、SRTCP索引（在对有效负载应用任何加密后）和特斯拉扩展。请注意，通过加入特斯拉认证扩展，该定义从[RFC3711]扩展而来。
We define the "TESLA Authenticated Portion" of an SRTCP packet as consisting of the RTCP header (first 8 bytes) and the Encrypted Portion of the SRTCP packet.
我们将SRTCP数据包的“特斯拉认证部分”定义为由RTCP头（前8个字节）和SRTCP数据包的加密部分组成。
Processing of an SRTCP packets is similar to the SRTP processing (Section 4.3), but there are SRTCP-specific changes described in Section 3.4 of the SRTP specification [RFC3711] and in Section 4.6 of this memo.
SRTCP数据包的处理类似于SRTP处理（第4.3节），但SRTP规范[RFC3711]第3.4节和本备忘录第4.6节中描述了SRTCP特定的变更。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+
|V=2|P| RC | PT=SR or RR | length | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| SSRC of sender | | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| ~ sender info ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ report block 1 ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ report block 2 ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ ... ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| |V=2|P| SC | PT=SDES=202 | length | | |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| | SSRC/CSRC_1 | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ SDES items ~ | |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| ~ ... ~ | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| |E| SRTCP index | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |
| | i | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ Disclosed Key ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ TESLA MAC ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+
| ~ SRTCP MKI ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| : authentication tag : | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | |
+-- Encrypted Portion TESLA Authenticated Portion -----+ |
|
Authenticated Portion -------+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+
|V=2|P| RC | PT=SR or RR | length | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| SSRC of sender | | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| ~ sender info ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ report block 1 ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ report block 2 ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ ... ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| |V=2|P| SC | PT=SDES=202 | length | | |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| | SSRC/CSRC_1 | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ SDES items ~ | |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| ~ ... ~ | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| |E| SRTCP index | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |
| | i | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ Disclosed Key ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ TESLA MAC ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+
| ~ SRTCP MKI ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| : authentication tag : | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | |
+-- Encrypted Portion TESLA Authenticated Portion -----+ |
|
Authenticated Portion -------+
Figure 3. The format of the SRTCP packet when TESLA is applied.
图3。应用特斯拉时SRTCP数据包的格式。
Note that when additional fields are added to a packet, it will increase the packet size and thus the RTCP average packet size.
请注意，当向数据包添加其他字段时，会增加数据包大小，从而增加RTCP平均数据包大小。
Let M' denote packet data to be TESLA-authenticated. In the case of SRTP, M' SHALL consist of the SRTP TESLA Authenticated Portion (RTP header and SRTP Encrypted Portion; see Figure 2) of the packet concatenated with the rollover counter (ROC) of the same packet:
让M'表示要进行特斯拉认证的分组数据。在SRTP的情况下，M'应包括与相同数据包的滚动计数器（ROC）相连的数据包的SRTP特斯拉认证部分（RTP报头和SRTP加密部分；见图2）：
M' = ROC || TESLA Authenticated Portion.
M'=ROC | |特斯拉认证部分。
In the case of SRTCP, M' SHALL consist of the SRTCP TESLA Authenticated Portion only (RTCP header and SRTCP Encrypted Portion).
在SRTCP的情况下，M'应仅包括SRTCP特斯拉认证部分（RTCP头和SRTCP加密部分）。
The normal authentication tag (OPTIONAL for SRTP, MANDATORY for SRTCP) SHALL be applied with the same coverage as specified in [RFC3711]. That is:
正常认证标签（SRTP可选，SRTCP强制）的覆盖范围应与[RFC3711]中规定的相同。即:
- for SRTP: Authenticated Portion || ROC (with the extended definition of SRTP Authentication Portion as in Section 4.2).
- 对于SRTP：认证部分| | ROC（SRTP认证部分的扩展定义见第4.2节）。
- for SRTCP: Authenticated Portion (with the extended definition of SRTCP Authentication Portion as in Section 4.2).
- 对于SRTCP：认证部分（SRTCP认证部分的扩展定义如第4.2节所述）。
The predefined authentication transform in SRTP, HMAC-SHA1 [RFC2104], is also used to generate the TESLA MAC. For SRTP (and respectively for SRTCP), the HMAC SHALL be applied to the key in the TESLA chain corresponding to a particular time interval, and to M' as specified above. The HMAC output SHALL then be truncated to the n_m left-most bits. Default values are in Section 6.
SRTP中预定义的身份验证转换HMAC-SHA1[RFC2104]也用于生成特斯拉MAC。对于SRTP（分别适用于SRTCP），HMAC应适用于特斯拉链中对应于特定时间间隔的钥匙，以及上文规定的M'。然后，HMAC输出应截断为nμm最左边的位。默认值见第6节。
As with SRTP, the predefined HMAC-SHA1 authentication algorithm MAY be replaced with an alternative algorithm that is specified in a future Internet RFC.
与SRTP一样，预定义的HMAC-SHA1认证算法可替换为在未来互联网RFC中指定的替代算法。
TESLA requires a pseudo-random function (PRF) to implement
特斯拉需要一个伪随机函数（PRF）来实现
* one one-way function F(x) to derive the key chain, and * one one-way function F'(x) to derive (from each key of the chain) the key that is actually used to calculate the TESLA MAC.
* 一个单向函数F（x）用于推导钥匙链，一个单向函数F’（x）用于推导（从钥匙链的每个钥匙）实际用于计算特斯拉MAC的钥匙。
When TESLA is used within SRTP, the default choice of the PRF SHALL be HMAC-SHA1. Default values are in Section 6.
当特斯拉在SRTP内使用时，PRF的默认选择应为HMAC-SHA1。默认值见第6节。
Other PRFs can be chosen, and their use SHALL follow the common guidelines in [RFC3711] when adding new security parameters.
可以选择其他PRF，当添加新的安全参数时，其使用应遵循[RFC3711]中的通用指南。
The extensions to the SRTP cryptographic context include a set of TESLA parameters that are listed in Section 4.3 of this document. Furthermore, TESLA MUST be bootstrapped at session setup (for the parameter exchange and the initial key commitment) through a regular data authentication system (a digital signature algorithm is RECOMMENDED). Key management procedures can take care of this bootstrapping prior to the commencement of an SRTP session where TESLA authentication is used. The bootstrapping mechanism is out of scope for this document (it could, for example, be part of the key management protocol).
SRTP加密上下文的扩展包括本文件第4.3节中列出的一组特斯拉参数。此外，TESLA必须通过常规数据认证系统（建议使用数字签名算法）在会话设置（用于参数交换和初始密钥承诺）时自举。密钥管理程序可以在使用特斯拉认证的SRTP会话开始之前处理此引导。引导机制超出了本文档的范围（例如，它可能是密钥管理协议的一部分）。
A critical factor for the security of TESLA is that the sender and receiver need to be loosely synchronized. TESLA requires a bound on clock drift to be known (D_t). Use of TESLA in SRTP assumes that the time synchronization is guaranteed by out-of-band schemes (e.g., key management). That is, it is not in the scope of SRTP.
特斯拉安全性的一个关键因素是发送方和接收方需要松散同步。特斯拉要求已知时钟漂移的界限（D_t）。在SRTP中使用特斯拉假设时间同步由带外方案（例如，密钥管理）保证。也就是说，它不在SRTP的范围内。
It also should be noted that TESLA has some reliability requirements in that a key is disclosed for a packet in a subsequent packet, which can get lost. Since a key in a lost packet can be derived from a future packet, TESLA is robust to packet loss. This key stream stops, however, when the key-bearing data stream packets stop at the conclusion of the RTP session. To avoid this nasty boundary condition, send null packets with TESLA keys for one entire key-disclosure period following the interval in which the stream ceases: Null packets SHOULD be sent for d intervals of duration t_int (items 8 and 9 of Section 4.3). The rate of null packets SHOULD be the average rate of the session media stream.
还应注意的是，特斯拉具有一些可靠性要求，因为在随后的分组中为分组公开了密钥，这可能会丢失。由于丢失的数据包中的密钥可以从未来的数据包中导出，因此TESLA对数据包丢失具有鲁棒性。然而，当承载密钥的数据流分组在RTP会话结束时停止时，该密钥流停止。为了避免这种恶劣的边界条件，在流停止后的整个密钥公开期内发送带有特斯拉密钥的空包：空包应在持续时间t_int的d个间隔内发送（第4.3节第8项和第9项）。空数据包的速率应为会话媒体流的平均速率。
Key management procedures establish SRTP TESLA operating parameters, which are listed in Section 4.3 of this document. The operating parameters appear in the SRTP cryptographic context and have the default values that are described in this section. In the future, an Internet RFC MAY define alternative settings for SRTP TESLA that are different than those specified here. In particular, note that the settings defined in this memo can have a large impact on bandwidth, as they add 38 bytes to each packet (when the field length values are the default ones). For certain applications, this overhead may represent more than a 50% increase in packet size. Alternative settings might seek to reduce the number and length of various TESLA fields and outputs. No such optimizations are considered in this memo.
关键管理程序确定了本文件第4.3节列出的SRTP特斯拉运行参数。操作参数出现在SRTP加密上下文中，并具有本节中描述的默认值。将来，互联网RFC可能会为SRTP特斯拉定义不同于此处规定的替代设置。特别要注意的是，此备忘录中定义的设置可能会对带宽产生很大影响，因为它们会向每个数据包添加38个字节（当字段长度值为默认值时）。对于某些应用程序，此开销可能表示数据包大小增加50%以上。替代设置可能寻求减少各种特斯拉场和输出的数量和长度。本备忘录中未考虑此类优化。
It is RECOMMENDED that the SRTP MAC be truncated to 32 bits, since the SRTP MAC provides only group authentication and serves only as protection against external DoS.
建议将SRTP MAC截断为32位，因为SRTP MAC仅提供组身份验证，并且仅用于防止外部DoS。
The default values for the security parameters are listed in the following table.
下表列出了安全参数的默认值。
Parameter Mandatory-to-support Default
--------- -------------------- -------
TESLA PRF HMAC-SHA1 HMAC-SHA1
BIT-OUTPUT LENGTH n_p 160 160
BIT-OUTPUT LENGTH n_f 160 160
Parameter Mandatory-to-support Default
--------- -------------------- -------
TESLA PRF HMAC-SHA1 HMAC-SHA1
BIT-OUTPUT LENGTH n_p 160 160
BIT-OUTPUT LENGTH n_f 160 160
TESLA MAC HMAC-SHA1 HMAC-SHA1 (TRUNCATED) BIT-OUTPUT LENGTH n_m 80 80
特斯拉MAC HMAC-SHA1 HMAC-SHA1（截断）位输出长度n_m 80
As shown above, TESLA implementations MUST support HMAC-SHA1 [RFC2104] for the TESLA MAC and the TESLA PRF. The TESLA keychain generator is recursively defined as follows [RFC4082].
如上所示，特斯拉实施必须支持特斯拉MAC和特斯拉PRF的HMAC-SHA1[RFC2104]。特斯拉钥匙链生成器递归定义如下[RFC4082]。
K_i=HMAC_SHA1(K_{i+1},0), i=0..N-1
K_i=HMAC_SHA1(K_{i+1},0), i=0..N-1
where N-1=n_c from the cryptographic context.
其中N-1=加密上下文中的N_c。
The TESLA MAC key generator is defined as follows [RFC4082].
特斯拉MAC密钥生成器定义如下[RFC4082]。
K'_i=HMAC_SHA1(K_i,1)
K''u i=HMAC_SHA1（K'u i，1）
The TESLA MAC uses a truncated output of ten bytes [RFC2104] and is defined as follows.
特斯拉MAC使用十个字节的截断输出[RFC2104]，定义如下。
HMAC_SHA1(K'_i, M')
HMAC_-SHA1（K'u-i，M'）
where M' is as specified in Section 4.6.
式中，M'如第4.6节所规定。
Denial of Service (DoS) attacks on delayed authentication are discussed in [PCST]. TESLA requires receiver buffering before authentication; therefore, the receiver can suffer a denial of service attack due to a flood of bogus packets. To address this problem, the external SRTP MAC, based on the group key, MAY be used in addition to the TESLA MAC. The short size of the SRTP MAC (default 32 bits) is motivated because that MAC is purely for DoS prevention from attackers external to the group. The shorter output tag means that an attacker has a better chance of getting a forged packet accepted, which is about 2^31 attempts on average. As a first line of defense against a denial of service attack, a short tag is
[PCST]中讨论了针对延迟身份验证的拒绝服务（DoS）攻击。特斯拉在认证前要求接收器缓冲；因此，由于虚假数据包的泛滥，接收器可能遭受拒绝服务攻击。为了解决这个问题，除了特斯拉MAC之外，还可以使用基于组密钥的外部SRTP MAC。SRTP MAC的短尺寸（默认32位）是出于动机，因为该MAC纯粹用于防止组外攻击者的DoS攻击。较短的输出标记意味着攻击者有更好的机会接受伪造数据包，平均尝试次数约为2^31次。作为抵御拒绝服务攻击的第一道防线，短标记是
probably adequate; a victim will likely have ample evidence that it is under attack before accepting a forged packet, which will subsequently fail the TESLA check. [RFC4082] describes other mechanisms that can be used to prevent DoS, in place of the external group-key MAC. If used, they need to be added as processing steps (following the guidelines of [RFC4082]).
可能足够；受害者在接受伪造的数据包之前，可能有充分的证据表明自己受到了攻击，而伪造的数据包随后将无法通过特斯拉的检查。[RFC4082]描述了可用于代替外部组密钥MAC防止拒绝服务的其他机制。如果使用，则需要将其添加为处理步骤（遵循[RFC4082]的指南）。
The use of TESLA in SRTP defined in this specification is subject to the security considerations discussed in the SRTP specification [RFC3711] and in the TESLA specification [RFC4082]. In particular, the TESLA security is dependent on the computation of the "safety condition" as defined in Section 3.5 of [RFC4082].
在本规范中定义的SRTP中使用特斯拉应遵守SRTP规范[RFC3711]和特斯拉规范[RFC4082]中讨论的安全注意事项。特别是，特斯拉的安全性取决于[RFC4082]第3.5节中定义的“安全条件”的计算。
SRTP TESLA depends on the effective security of the systems that perform bootstrapping (time synchronization) and key management. These systems are external to SRTP and are not considered in this specification.
SRTP TESLA依赖于执行引导（时间同步）和密钥管理的系统的有效安全性。这些系统是SRTP的外部系统，本规范不考虑这些系统。
The length of the TESLA MAC is by default 80 bits. RFC 2104 requires the MAC length to be at least 80 bits and at least half the output size of the underlying hash function. The SHA-1 output size is 160 bits, so both of these requirements are met with the 80-bit MAC specified in this document. Note that IPsec implementations tend to use 96 bits for their MAC values to align the header with a 64-bit boundary. Both MAC sizes are well beyond the reach of current cryptanalytic techniques.
特斯拉MAC的长度默认为80位。RFC2104要求MAC长度至少为80位，且至少为底层哈希函数输出大小的一半。SHA-1输出大小为160位，因此本文件中规定的80位MAC满足这两个要求。请注意，IPsec实现往往使用96位作为其MAC值，以将报头与64位边界对齐。这两种MAC的大小都远远超出了当前密码分析技术的范围。
The authors would like to thank Ran Canetti, Karl Norrman, Mats Naslund, Fredrik Lindholm, David McGrew, and Bob Briscoe for their valuable help.
作者要感谢Ran Canetti、Karl Norrman、Mats Naslund、Fredrik Lindholm、David McGrew和Bob Briscoe提供的宝贵帮助。
[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月。
[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月。
[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月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082]Perrig，A.，Song，D.，Canetti，R.，Tygar，J.，和B.Briscoe，“定时高效流丢失容忍认证（TESLA）：多播源认证转换介绍”，RFC 40822005年6月。
[PCST] Perrig, A., Canetti, R., Song, D., Tygar, D., "Efficient and Secure Source Authentication for Multicast", in Proc. of Network and Distributed System Security Symposium NDSS 2001, pp. 35-46, 2001.
[PCST]Perrig，A.，Canetti，R.，Song，D.，Tygar，D.，“多播的高效安全源认证”，在Proc。网络和分布式系统安全研讨会NDSS 2001，第35-46页，2001年。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
[RFC4046]Baugher，M.，Canetti，R.，Dondeti，L.，和F.Lindholm，“多播安全（MSEC）组密钥管理体系结构”，RFC 4046，2005年4月。
Authors' Addresses
作者地址
Questions and comments should be directed to the authors and msec@ietf.org.
问题和意见应提交给作者和msec@ietf.org.
Mark Baugher Cisco Systems, Inc. 5510 SW Orchid Street Portland, OR 97219 USA
Mark Baugher Cisco Systems，Inc.美国波特兰兰花街西南5510号，邮编：97219
Phone: +1 408-853-4418
EMail: mbaugher@cisco.com
Phone: +1 408-853-4418
EMail: mbaugher@cisco.com
Elisabetta Carrara Royal Institute of Technology Stockholm Sweden
瑞典斯德哥尔摩皇家理工学院Elisabetta Carrara
EMail: carrara@kth.se
EMail: carrara@kth.se
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）提供。