Network Working Group S. Fries
Request for Comments: 4442 H. Tschofenig
Category: Standards Track Siemens
March 2006
Network Working Group S. Fries
Request for Comments: 4442 H. Tschofenig
Category: Standards Track Siemens
March 2006
Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
引导定时高效流丢失容忍认证（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
摘要
TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.
TESLA是一种定时高效流丢失容忍认证协议，在多播场景中提供源认证。TESLA是一种高效的协议，具有较低的通信和计算开销，可扩展到大量的接收器，并且可以容忍数据包丢失。特斯拉基于发送方和接收方之间的松散时间同步。特斯拉通过使用消息认证码（MAC）链接实现源认证。TESLA在安全实时传输协议（SRTP）中的使用已经发布，针对应用SRTP保护多媒体数据的场景中的多播认证。该解决方案假设特斯拉参数由带外机制提供。
This document specifies payloads for the Multimedia Internet Keying (MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast.
本文件规定了多媒体互联网密钥（MIKEY）协议的有效载荷，用于引导TESLA使用SRTP对安全组通信进行源认证。特斯拉可以使用一种米奇密钥管理方法进行引导，例如，通过单播、多播或广播发送数字签名的米奇消息。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. TESLA Parameter Overview ........................................4
4. Parameter Encoding within MIKEY .................................6
4.1. Security Policy (SP) Payload ...............................6
4.2. TESLA Policy ...............................................7
4.3. Time Synchronization .......................................8
4.4. Key Data Transport within MIKEY's General
Extension Payload .........................................10
5. Security Considerations ........................................11
5.1. Man-in-the-Middle Attack ..................................11
5.2. Downgrading Attack ........................................12
5.3. Denial of Service Attack ..................................12
5.4. Replay Attack .............................................13
5.5. Traffic Analysis ..........................................13
6. IANA Considerations ............................................14
7. Acknowledgements ...............................................15
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................16
1. Introduction ....................................................3
2. Terminology .....................................................4
3. TESLA Parameter Overview ........................................4
4. Parameter Encoding within MIKEY .................................6
4.1. Security Policy (SP) Payload ...............................6
4.2. TESLA Policy ...............................................7
4.3. Time Synchronization .......................................8
4.4. Key Data Transport within MIKEY's General
Extension Payload .........................................10
5. Security Considerations ........................................11
5.1. Man-in-the-Middle Attack ..................................11
5.2. Downgrading Attack ........................................12
5.3. Denial of Service Attack ..................................12
5.4. Replay Attack .............................................13
5.5. Traffic Analysis ..........................................13
6. IANA Considerations ............................................14
7. Acknowledgements ...............................................15
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................16
In many multicast, broadcast, and unicast communication scenarios, it is necessary to guarantee that a received message has been sent from a dedicated source and has not been altered in transit. In unicast communication, commonly a pairwise security association exists that enables the validation of message integrity and data origin. The approach in group-based communication is different, as here a key is normally shared between the members of a group and thus may not be used for data origin authentication. As in some applications a dedicated identification of a sender is required, there exists the requirement to support data origin authentication also in multicast scenarios. One of the methods supporting this is TESLA [RFC4082]. TESLA provides source authentication in multicast scenarios by using MAC chaining. It is based on loose time synchronization between the sender and the receivers.
在许多多播、广播和单播通信场景中，必须确保接收到的消息已从专用源发送，并且在传输过程中未被更改。在单播通信中，通常存在一个成对的安全关联，可以验证消息完整性和数据来源。基于组的通信中的方法不同，因为此处密钥通常在组的成员之间共享，因此可能不用于数据源身份验证。由于在某些应用程序中需要发送方的专用标识，因此在多播场景中也需要支持数据源身份验证。支持这一点的方法之一是特斯拉[RFC4082]。TESLA通过使用MAC链在多播场景中提供源认证。它基于发送方和接收方之间的松散时间同步。
[RFC4383] describes extensions for SRTP [RFC3711] in order to support TESLA [RFC4082] for source authentication in multicast scenarios. SRTP needs dedicated cryptographic context describing the security parameter and security policy per multimedia session to be protected. This cryptographic context needs to be enhanced with a set of TESLA parameters. It is necessary to provide these parameters before the actual multicast session starts. [RFC4383] does not address the bootstrapping for these parameters.
[RFC4383]描述了SRTP[RFC3711]的扩展，以支持特斯拉[RFC4082]在多播场景中进行源认证。SRTP需要专用的加密上下文来描述每个要保护的多媒体会话的安全参数和安全策略。这个加密上下文需要用一组特斯拉参数来增强。在实际的多播会话开始之前，必须提供这些参数。[RFC4383]没有解决这些参数的引导问题。
This document details bootstrapping of TESLA parameters in terms of parameter distribution for TESLA policy as well as the initial key, using the Multimedia Internet Keying (MIKEY) [RFC3830] protocol. MIKEY defines an authentication and key management framework that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, [RFC3830] is defined in a way that is intended to support SRTP in the first place but is open to enhancements to be used for other purposes too. Following the description in [RFC3830], MIKEY is targeted for point-to-point as well as group communication. In the context of group communication, an administrator entity can distribute session keys to the associated entities participating in the communication session. This scenario is also applicable for TESLA where one entity may provide information to many others in a way that the integrity of the communicated information can be assured. The combination of MIKEY and TESLA supports this group-based approach by utilizing the MIKEY framework to distribute TESLA parameter information to all involved entities. Note that this document focuses only on the distribution of the parameters, not on the generation of those parameters.
本文件使用多媒体互联网密钥（MIKEY）[RFC3830]协议，根据特斯拉政策的参数分布以及初始密钥，详细说明了特斯拉参数的自举。MIKEY定义了一个可用于实时应用程序的身份验证和密钥管理框架（用于点对点通信和组通信）。特别是，[RFC3830]的定义方式旨在首先支持SRTP，但也可以将增强功能用于其他目的。按照[RFC3830]中的描述，MIKEY的目标是进行点对点和组通信。在组通信上下文中，管理员实体可以将会话密钥分发给参与通信会话的关联实体。这种情况也适用于特斯拉，其中一个实体可以向许多其他实体提供信息，以确保所传达信息的完整性。MIKEY和TESLA的结合通过利用MIKEY框架将TESLA参数信息分发给所有相关实体，从而支持这种基于组的方法。请注意，本文档仅关注参数的分布，而不是这些参数的生成。
MIKEY [RFC3830] itself describes three authentication and key exchange protocols (symmetric key encryption, public key encryption,
MIKEY[RFC3830]本身描述了三种身份验证和密钥交换协议（对称密钥加密、公钥加密、，
and signed Diffie-Hellman). Extensions to the MIKEY key exchange methods have been defined. A fourth key distribution method is provided by [DHHMAC] and describes a symmetrically protected Diffie-Hellman key agreement. A further option has been proposed in [RSA-R] that describes an enhanced asymmetric exchange variant, also supporting inband certificate exchange. All the different key management schemes mentioned above may be used to provide the TESLA parameters. The required TESLA parameters to be exchanged are already described in [RFC4383], while this document describes their transport within MIKEY.
签名是迪菲·赫尔曼）。已经定义了对MIKEY密钥交换方法的扩展。[DHHMAC]提供了第四种密钥分配方法，描述了对称保护的Diffie-Hellman密钥协议。[RSA-R]中提出了另一个选项，该选项描述了一种增强的不对称交换变体，也支持带内证书交换。上述所有不同的密钥管理方案均可用于提供特斯拉参数。[RFC4383]中已经描述了需要交换的特斯拉参数，而本文件描述了它们在米奇内部的传输。
The following security requirements have to be placed on the exchange of TESLA parameters:
特斯拉参数交换必须满足以下安全要求：
o Authentication and Integrity MUST be provided when sending the TESLA parameters, especially for the initial key. o Confidentiality MAY be provided for the TESLA parameters.
o 发送特斯拉参数时，必须提供身份验证和完整性，尤其是初始密钥。o可为特斯拉参数提供保密性。
These security requirements apply to the TESLA bootstrapping procedure only. Security requirements for applications using TESLA are beyond the scope of this document. Security aspects that relate to TESLA itself are described in [RFC4082], and security issues for TESLA usage for SRTP are covered in [RFC4383].
这些安全要求仅适用于特斯拉自举程序。使用特斯拉的应用程序的安全要求超出了本文件的范围。与特斯拉自身相关的安全方面在[RFC4082]中有描述，特斯拉使用SRTP的安全问题在[RFC4383]中有介绍。
It is important to note that this document is one piece of a complete solution. Assuming that media traffic is to be secured using TESLA as described in [RFC4383], then (a) keying material and (b) parameters for TESLA are required. This document contributes the parameters and the authentication methods used in MIKEY to provide the keying material. The parameter exchange for TESLA also needs to be secured against tampering. This protection is also provided by MIKEY.
需要注意的是，本文档是完整解决方案的一部分。假设要使用[RFC4383]中所述的特斯拉保护媒体流量，则需要（a）特斯拉的键控材料和（b）参数。本文档提供了MIKEY中用于提供密钥材料的参数和身份验证方法。特斯拉的参数交换也需要防止篡改。这种保护也由MIKEY提供。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
According to [RFC4383], a number of transform-dependent parameters need to be provided for proper TESLA operation. The complete list of parameters can be found in Section 4.3 of [RFC4383]. Note that parameter 10 of [RFC4383], describing the lag of the receiver clock relative to the sender clock, is omitted in this document since it can be computed.
根据[RFC4383]，需要为正确的特斯拉操作提供许多变换相关参数。完整的参数列表见[RFC4383]第4.3节。注意，[RFC4383]的参数10，描述了接收器时钟相对于发送器时钟的滞后，在本文档中被省略，因为它可以被计算。
MIKEY already requires synchronized clocks, which also provides for synchronization for TESLA. Moreover, Section 4.3 states an option to use MIKEY for clock drift determination between the sender and receiver. Thus, this parameter does not need to be transmitted in MIKEY directly.
米奇已经要求同步时钟，这也为特斯拉提供了同步。此外，第4.3节规定了使用MIKEY确定发送方和接收方之间时钟漂移的选项。因此，该参数不需要直接在MIKEY中传输。
The information in brackets provides the default values as specified in Section 6.2 of [RFC4383].
括号中的信息提供了[RFC4383]第6.2节中规定的默认值。
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 the keyed hash function (default HMAC-SHA1).
1. PRF（特斯拉PRF）的标识符，实现特斯拉中的单向函数F（x）（用于导出链中的键）和特斯拉中的单向函数F’（x）（用于从链中的键导出特斯拉MAC的键），例如，指示键控哈希函数（默认HMAC-SHA1）。
2. A non-negative integer, determining the length of the F output, i.e., the length of the keys in the chain, which is also the key disclosed in an SRTP packet if TESLA is used in the SRTP context (default 160 bit).
2. 非负整数，确定F输出的长度，即链中密钥的长度，如果在SRTP上下文中使用TESLA，则该密钥也是SRTP分组中公开的密钥（默认160位）。
3. A non-negative integer, determining the length of the output of F', i.e., the length of the key for the TESLA MAC (default 160 bit).
3. 一个非负整数，确定F'输出的长度，即特斯拉MAC密钥的长度（默认为160位）。
4. An identifier for the TESLA MAC that accepts the output of F'(x) as its key, e.g., to indicate a keyed hashing function (default HMAC-SHA1).
4. 特斯拉MAC的一种标识符，它接受F’（x）的输出作为其键，例如，用于指示键控哈希函数（默认HMAC-SHA1）。
5. A non-negative integer, determining the length of the output of the TESLA MAC (default 80 bit).
5. 非负整数，确定特斯拉MAC输出的长度（默认为80位）。
6. The beginning of the session for which a key will be applied.
6. 将应用密钥的会话的开始。
7. The interval duration (in milliseconds) for which a dedicated key will be used.
7. 将使用专用密钥的间隔持续时间（毫秒）。
8. The key disclosure delay (in number of intervals) characterizes the period after which the key will be sent to the involved entities (e.g., as part of SRTP packets).
8. 密钥公开延迟（以间隔数表示）表征了密钥将被发送到相关实体（例如，作为SRTP分组的一部分）的时间段。
9. Non-negative integer, determining the length of the key chain, which is determined based on the expected duration of the stream.
9. 非负整数，确定密钥链的长度，该长度根据流的预期持续时间确定。
10. The initial key of the chain to which the sender has committed himself.
10. 发送方已向其承诺的链的初始密钥。
As mentioned in Section 3, TESLA parameters need to be transported before actually starting a session. MIKEY currently only defines a payload for transporting the SRTP policy (see Section 6.10 of [RFC3830]). This section describes the enhancement of MIKEY to allow the transport of a TESLA policy and additionally the initial TESLA key.
如第3节所述，在实际开始会话之前，需要传输特斯拉参数。MIKEY目前仅定义用于传输SRTP策略的有效负载（请参见[RFC3830]第6.10节）。本节描述了MIKEY的增强功能，以允许传输特斯拉政策和初始特斯拉密钥。
The Security Policy payload defines a set of policies that apply to a specific security protocol. The definition here relies on the security policy payload definition in [RFC3830].
安全策略负载定义了一组应用于特定安全协议的策略。此处的定义依赖于[RFC3830]中的安全策略有效负载定义。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Policy no ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Policy no ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): Identifies the payload that is added after this payload. See Section 6.1 of [RFC3830] for more details.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。更多详情请参见[RFC3830]第6.1节。
* Policy no (8 bits): Each security policy payload must be given a distinct number for the current MIKEY session by the local peer. This number is used to map a cryptographic session to a specific policy (see also Section 6.1.1 of [RFC3830]).
* 策略编号（8位）：本地对等方必须为当前MIKEY会话为每个安全策略有效负载指定一个不同的编号。此编号用于将加密会话映射到特定策略（另请参见[RFC3830]第6.1.1节）。
* Prot type (8 bits): This value defines the security protocol. A second value needs to be defined as shown below: (MIKEY already defines the value 0.)
* 保护类型（8位）：该值定义安全协议。需要定义第二个值，如下所示：（MIKEY已经定义了值0。）
Prot type | Value |
---------------------------
SRTP | 0 |
TESLA | 1 |
Prot type | Value |
---------------------------
SRTP | 0 |
TESLA | 1 |
* Policy param length (16 bits): This field defines the total length of the policy parameters for the selected security protocol.
* 策略参数长度（16位）：此字段定义所选安全协议的策略参数的总长度。
* Policy param (variable length): This field defines the policy for the specific security protocol.
* 策略参数（可变长度）：此字段定义特定安全协议的策略。
The Policy param part is built up by a set of Type/Length/Value (TLV) payloads. For each security protocol, a set of possible type/value pairs can be negotiated as defined.
策略参数部分由一组类型/长度/值（TLV）有效载荷组成。对于每个安全协议，可以根据定义协商一组可能的类型/值对。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ! Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ! Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Type (8 bits): Specifies the type of the parameter.
* 类型（8位）：指定参数的类型。
* Length (8 bits): Specifies the length of the Value field (in bytes).
* 长度（8位）：指定值字段的长度（字节）。
* Value (variable length): Specifies the value of the parameter.
* 值（可变长度）：指定参数的值。
This policy specifies the parameters for TESLA. The types/values that can be negotiated are defined by the following table. The concrete default values are taken from [RFC4383], but other values may also be used:
本政策规定了特斯拉的参数。下表定义了可协商的类型/值。具体默认值取自[RFC4383]，但也可使用其他值：
Type | Meaning | Possible values
---------------------------------------------------------------
1 | PRF identifier for f and f', realising | see below
F(x) and F'(x)
2 | Length of PRF f' output | 160
3 | Identifier for the TESLA MAC | see below
4 | Length of TESLA MAC output | 80 (truncated)
5 | Start of session | in bytes
6 | Interval duration (in msec) | in bytes
7 | Key disclosure delay | in bytes
8 | Key chain length (number of intervals) | in bytes
9 | Local timestamp media receiver | see below
Type | Meaning | Possible values
---------------------------------------------------------------
1 | PRF identifier for f and f', realising | see below
F(x) and F'(x)
2 | Length of PRF f' output | 160
3 | Identifier for the TESLA MAC | see below
4 | Length of TESLA MAC output | 80 (truncated)
5 | Start of session | in bytes
6 | Interval duration (in msec) | in bytes
7 | Key disclosure delay | in bytes
8 | Key chain length (number of intervals) | in bytes
9 | Local timestamp media receiver | see below
The time values stated in items 5 and 9 SHALL be transported in NTP-UTC format, which is one of the three options described in Section 6.6 of [RFC3830]. A four-byte integer value for policy item 6 and a two-byte integer value for policy item 7 are RECOMMENDED, carrying interval duration and key disclosure delay. Policy type 9 stated
第5项和第9项中规定的时间值应以NTP-UTC格式传输，NTP-UTC格式是[RFC3830]第6.6节中描述的三种选项之一。建议策略项6使用四字节整数值，策略项7使用两字节整数值，带有间隔持续时间和密钥泄漏延迟。保单类型9声明
above is optional and SHOULD be used if the time synchronization described in Section 4.3, point two, is used. Otherwise, it SHOULD be omitted.
以上是可选的，如果使用第4.3节第二点中所述的时间同步，则应使用。否则，应该省略它。
For the PRF realizing F(x) and F'(x), a one-byte length is sufficient. The currently defined possible values are:
对于实现F（x）和F’（x）的PRF，一个字节的长度就足够了。当前定义的可能值为：
TESLA PRF F(x), F'(x) | Value
------------------------------
HMAC-SHA1 | 0
TESLA PRF F(x), F'(x) | Value
------------------------------
HMAC-SHA1 | 0
For the TESLA MAC, a one-byte length is enough. The currently defined possible values are:
对于特斯拉MAC，一个字节的长度就足够了。当前定义的可能值为：
TESLA MAC | Value
-----------------------
HMAC-SHA1 | 0
TESLA MAC | Value
-----------------------
HMAC-SHA1 | 0
MIKEY as well as TESLA require the time synchronization of the communicating peers. MIKEY requires time synchronization to provide timestamp-based replay protection for the one-roundtrip authentication and key exchange protocols. TESLA, on the other hand, needs this information to determine the clock drift between the senders and the receivers in order to release the disclosed key appropriately. Two alternatives are available for time synchronization:
MIKEY和TESLA都需要通信对等方的时间同步。MIKEY需要时间同步，以便为单程身份验证和密钥交换协议提供基于时间戳的重播保护。另一方面，特斯拉需要该信息来确定发送方和接收方之间的时钟漂移，以便适当地释放所公开的密钥。时间同步有两种选择：
1. Usage of out-of-band synchronization using NTP [RFC1305]. This approach is already recommended within [RFC3830]. The advantage of this approach is the option to use the MIKEY key management variants that perform within a half-roundtrip. The disadvantage is the required time synchronization via an additional protocol.
1. 使用NTP[RFC1305]使用带外同步。[RFC3830]中已经推荐了这种方法。这种方法的优点是可以选择使用在半个往返行程内执行的MIKEY密钥管理变体。缺点是需要通过附加协议进行时间同步。
2. [RFC4082] also sketches a possible inband synchronization in Section 3.3.1. This approach is summarized here in the context of MIKEY. Note that here the actual TESLA policy payload is transmitted as part of the MIKEY responder message.
2. [RFC4082]在第3.3.1节中还绘制了可能的带内同步。本文在MIKEY的背景下总结了这种方法。请注意，此处实际特斯拉策略有效载荷作为MIKEY responder消息的一部分传输。
* The data receiver, which would be the MIKEY initiator, sets the local time parameter t_r and sends it as part of the timestamp payload as described in [RFC3830]. This value t_r needs to be stored locally.
* 数据接收器（即MIKEY启动器）设置本地时间参数t_r，并将其作为时间戳有效载荷的一部分发送，如[RFC3830]所述。此值t_r需要本地存储。
* Upon receipt of the MIKEY initiator message, the data sender replies with the MIKEY responder message, setting the local time stamp at data receiver (parameter 11) to the value t_r
* 在收到MIKEY initiator消息后，数据发送方使用MIKEY responder消息进行回复，将数据接收方（参数11）的本地时间戳设置为值t_r
received in the MIKEY initiator message, and sets his local time as a 64-bit UTC value t_s in the timestamp payload as described in [RFC3830].
在MIKEY initiator消息中接收，并将其本地时间设置为时间戳有效负载中的64位UTC值t_s，如[RFC3830]中所述。
MIKEY initiator message
[MIKEY parameter incl. local timestamp (t_r)]
------------------>
MIKEY initiator message
[MIKEY parameter incl. local timestamp (t_r)]
------------------>
MIKEY responder message
[MIKEY parameter incl. local timestamp (t_s), TESLA policy
payload, received local time stamp t_r]
<------------------
MIKEY responder message
[MIKEY parameter incl. local timestamp (t_s), TESLA policy
payload, received local time stamp t_r]
<------------------
* Upon receiving the MIKEY responder message the data receiver sets D_t = t_s - t_r + S, where S is an estimated bound on the clock drift throughout the duration of the session.
* 在接收到MIKEY responder消息后，数据接收器设置D_t=t_s-t_r+s，其中s是整个会话期间时钟漂移的估计界限。
This approach has the advantage that it does not require an additional time synchronization protocol. The disadvantage is the necessity to perform a full MIKEY handshake, to enable correct parameter transport. Moreover this approach is direction dependent, as it may only be applied if the media receiver is also the MIKEY initiator.
这种方法的优点是不需要额外的时间同步协议。缺点是必须执行完整的MIKEY握手，以实现正确的参数传输。此外，该方法依赖于方向，因为它仅在媒体接收器也是MIKEY启动器的情况下应用。
Out-of-band synchronization using NTP (i.e., alternative 1) is the RECOMMENDED approach for clock synchronization. In scenarios where the media receiver is also the MIKEY initiator piggybacking timestamp information in MIKEY (i.e., alternative 2) MAY be used to allow for inband determination of the clock drift between sender and receiver.
使用NTP（即，备选方案1）的带外同步是时钟同步的推荐方法。在媒体接收机也是MIKEY发起方的情况下，可以使用MIKEY中的时间戳信息（即，备选方案2）来允许带内确定发送方和接收机之间的时钟漂移。
The General Extensions Payload was defined to allow possible extensions to MIKEY without the need for defining a completely new payload each time. This payload can be used in any MIKEY message and is part of the authenticated/signed data part.
通用扩展有效负载的定义允许对MIKEY进行可能的扩展，而无需每次定义一个全新的有效负载。此有效负载可用于任何MIKEY消息，并且是经过身份验证/签名的数据部分的一部分。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): Identifies the payload following this payload.
* 下一个有效负载（8位）：标识此有效负载之后的有效负载。
* Type (8 bits): Identifies the type of general payload. MIKEY already defines the values 0 and 1. This document introduces a new value (2).
* 类型（8位）：标识一般有效负载的类型。MIKEY已经定义了值0和1。本文档引入了一个新值（2）。
Type | Value | Comments
----------------------------------------------------
Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs
TESLA I-Key | 2 | TESLA initial key
Type | Value | Comments
----------------------------------------------------
Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs
TESLA I-Key | 2 | TESLA initial key
* Length (16 bits): The length in bytes of the Data field.
* 长度（16位）：数据字段的字节长度。
* Data (variable length): The general payload data.
* 数据（可变长度）：一般有效负载数据。
The security properties of multi-media data in a multicast environment depends on a number of building blocks.
多播环境中多媒体数据的安全属性取决于许多构建块。
SRTP-TESLA [RFC4383] describes extensions for SRTP [RFC3711] in order to support TESLA [RFC4082] for source authentication in multicast scenarios. As such, security considerations described with TESLA (see [PCST] and [RFC4082]), the TESLA SRTP mapping [RFC4383], and SRTP [RFC3711] itself are relevant in this context.
SRTP-TESLA[RFC4383]描述了SRTP[RFC3711]的扩展，以支持TESLA[RFC4082]在多播场景中进行源认证。因此，特斯拉（见[PCST]和[RFC4082]）、特斯拉SRTP映射[RFC4383]和SRTP[RFC3711]本身所述的安全注意事项与此上下文相关。
Furthermore, since this document details bootstrapping of TESLA using the Multimedia Internet Keying (MIKEY) [RFC3830] protocol, the security considerations of MIKEY are applicable to this document.
此外，由于本文件详细说明了使用多媒体互联网密钥（MIKEY）[RFC3830]协议引导特斯拉，因此MIKEY的安全注意事项适用于本文件。
As a summary, in order for a multi-media application to support TESLA, the following protocol interactions (in relationship to this document) are necessary:
总之，为了使多媒体应用程序支持特斯拉，以下协议交互（与本文件相关）是必要的：
o MIKEY [RFC3830] is executed between the desired entities to perform authentication and a secure distribution of keying material. In order to subsequently use TESLA, the parameters described in this document are distributed using MIKEY. MIKEY itself uses another protocol for parameter transport, namely, the Session Description Protocol (SDP) [RFC2327]. SDP might again be used within Session Initiation Protocol (SIP, [RFC3261]) to set up a session between the desired entities.
o 在所需实体之间执行MIKEY[RFC3830]，以执行认证和密钥材料的安全分发。为了随后使用特斯拉，本文件中描述的参数使用MIKEY分发。MIKEY本身使用另一种协议进行参数传输，即会话描述协议（SDP）[RFC2327]。SDP也可以在会话启动协议（SIP，[RFC3261]）中使用，以在所需实体之间建立会话。
o After the algorithms, parameters, and session keys are available at the respective communication entities, data traffic protection via SRTP-TESLA [RFC4383] can be used. SRTP-TESLA itself applies TESLA to the SRTP protocol, and as such the processing guidelines of TESLA need to be followed.
o 算法、参数和会话密钥在各通信实体处可用后，可通过SRTP-TESLA[RFC4383]使用数据流量保护。SRTP-TESLA本身将特斯拉应用于SRTP协议，因此需要遵守特斯拉的处理指南。
Threat:
威胁：
The exchange of security-related parameters and algorithms without mutual authentication of the two peers can allow an adversary to perform a man-in-the-middle attack. The mechanisms described in this document do not themselves provide such an authentication and integrity protection.
交换安全相关参数和算法而无需两个对等方的相互身份验证，可允许对手执行中间人攻击。本文档中描述的机制本身并不提供这种身份验证和完整性保护。
Countermeasures:
对策：
Throughout the document, it is assumed that the parameter exchange is secured using another protocol, i.e., the exchange parameters
在整个文档中，假设参数交换使用另一个协议（即交换参数）进行安全保护
and algorithms are part of a authentication and key exchange protocol (namely, MIKEY). Source authentication of group and multicast communication cannot be provided for the data traffic if the prior signaling exchange did not provide facilities to authenticate the source. Using an authentication protocol that does not provide session keys as part of a successful protocol exchange will make it impossible to derive the necessary parameters required by TESLA. MIKEY provides session key establishment. Additionally, the exchange of parameters and algorithms MUST be authenticated and integrity protected. The security protection of the parameter exchange needs to provide the same level or a higher level of security.
算法是身份验证和密钥交换协议（即MIKEY）的一部分。如果先前的信令交换未提供对源进行身份验证的设施，则无法为数据流量提供组和多播通信的源身份验证。使用不提供会话密钥的认证协议作为成功协议交换的一部分，将无法获得特斯拉所需的必要参数。MIKEY提供会话密钥建立。此外，参数和算法的交换必须经过身份验证和完整性保护。参数交换的安全保护需要提供相同级别或更高级别的安全性。
Threat:
威胁：
The exchange of security-related parameters and algorithms is always subject to downgrading whereby an adversary modifies some (or all) of the provided parameters. For example, a few parameters require that a supported hash algorithm be listed. To mount an attack, the adversary has to modify the list of provided algorithms and to select the weakest one.
安全相关参数和算法的交换总是会被降级，从而对手修改部分（或全部）提供的参数。例如，一些参数要求列出受支持的哈希算法。要发动攻击，对手必须修改提供的算法列表，并选择最弱的算法。
Countermeasures:
对策：
TESLA parameter bootstrapping MUST be integrity protected to prevent modification of the parameters and their values. Moreover, since unmodified parameters from an unknown source are not useful, authentication MUST be provided. This functionality is not provided by mechanisms described in this document. Instead, the capabilities of the underlying authentication and key exchange protocol (MIKEY) are reused for this purpose.
特斯拉参数自举必须受到完整性保护，以防止修改参数及其值。此外，由于来自未知源的未修改参数没有用处，因此必须提供身份验证。本文档中描述的机制不提供此功能。相反，底层身份验证和密钥交换协议（MIKEY）的功能可用于此目的。
Threat:
威胁：
An adversary might want to modify parameters exchanged between the communicating entities in order to establish different state information at the respective communication entities. For example, an adversary might want to modify the key disclosure delay or the interval duration in order to disrupt the communication at a later state since the TESLA algorithm assumes that the participating communication entities know the same parameter set.
对手可能希望修改通信实体之间交换的参数，以便在各个通信实体处建立不同的状态信息。例如，由于TESLA算法假设参与的通信实体知道相同的参数集，因此对手可能想要修改密钥公开延迟或间隔持续时间，以便在稍后的状态中断通信。
Countermeasures:
对策：
The exchanged parameters and the parameters and algorithms MUST be integrity protected to allow the recipient to detect whether an adversary attempted to modify the exchanged information. Authentication and key exchange algorithms provided by MIKEY offer this protection.
交换的参数以及参数和算法必须受到完整性保护，以允许接收方检测对手是否试图修改交换的信息。MIKEY提供的身份验证和密钥交换算法提供了这种保护。
Threat:
威胁：
An adversary who is able to eavesdrop on one or multiple protocol exchanges (MIKEY exchanges with the parameters described in this document) might be able to replay the payloads in a later protocol exchange. If the recipients accept the parameters and algorithms (or even the messages that carry these payloads), then a denial of service, downgrading, or a man-in-the-middle attack might be the consequence (depending on the entire set of replayed attributes and messages).
能够窃听一个或多个协议交换（具有本文档所述参数的MIKEY交换）的对手可能能够在以后的协议交换中重播有效负载。如果收件人接受参数和算法（甚至接受承载这些有效负载的消息），则可能会导致拒绝服务、降级或中间人攻击（取决于整个重播属性和消息集）。
Countermeasures:
对策：
In order to prevent replay attacks, a freshness guarantee MUST be provided. As such, the TESLA bootstrapping message exchange MUST be unique and fresh, and the corresponding authentication and key exchange protocol MUST provide the same properties. In fact, it is essential to derive a unique and fresh session key as part of the authentication and key exchange protocol run that MUST be bound to the protocol session. This includes the exchanged parameters.
为了防止重播攻击，必须提供新鲜度保证。因此，特斯拉引导消息交换必须是唯一和新鲜的，相应的身份验证和密钥交换协议必须提供相同的属性。事实上，作为必须绑定到协议会话的身份验证和密钥交换协议运行的一部分，派生唯一且新的会话密钥非常重要。这包括交换的参数。
Threat:
威胁：
An adversary might be able to learn parameters and algorithms if he is located along the signaling path. This information can then later be used to mount attacks against the end-to-end multimedia communication. In some high-security and military environments, it might even be desirable not to reveal information about the used parameters to make it more difficult to launch an attack.
如果对手位于信令路径上，他可能能够学习参数和算法。该信息随后可用于对端到端多媒体通信发起攻击。在某些高安全性和军事环境中，甚至不披露所用参数的信息可能会使发动攻击更加困难。
Countermeasures:
对策：
Confidentiality protection can be provided by a subset of the available MIKEY authentication and key exchange protocols, namely, those providing public key encryption and symmetric key
可以通过提供公钥的对称加密和交换密钥的子集来提供加密和保护
encryption. The initial hash key, which is also one of the TESLA bootstrapping parameters, does not require confidentiality protection due to the properties of a hash chain.
加密。初始散列密钥也是特斯拉引导参数之一，由于散列链的属性，不需要保密保护。
This document requires an IANA registration for the following attributes. The registries are provided by MIKEY [RFC3830].
本文档要求对以下属性进行IANA注册。注册中心由MIKEY[RFC3830]提供。
Prot Type:
保护类型：
This attribute specifies the protocol type for the security protocol as described in Section 4.1.
此属性指定安全协议的协议类型，如第4.1节所述。
Type:
类型：
Identifies the type of the general payload. The General Extensions Payload was defined to allow possible extensions to MIKEY without the need for defining a completely new payload each time. Section 4.4 describes this attribute in more detail.
标识一般有效负载的类型。通用扩展有效负载的定义允许对MIKEY进行可能的扩展，而无需每次定义一个全新的有效负载。第4.4节更详细地描述了该属性。
Following the policies outlined in [RFC3830], the values in the range up to 240 (including 240) for the above attributes are assigned after expert review by the MSEC working group or its designated successor. The values in the range from 241 to 255 are reserved for private use.
根据[RFC3830]中概述的政策，在MSEC工作组或其指定继任者进行专家审查后，分配上述属性的最大范围为240（包括240）的值。241到255之间的值保留供私人使用。
The IANA has added the following attributes and their respective values to an existing registry created in [RFC3830]:
IANA已将以下属性及其各自的值添加到[RFC3830]中创建的现有注册表中：
Prot Type:
保护类型：
Prot Type | Value | Description
-----------------------------------------------------
TESLA | 1 | TESLA as a security protocol
Prot Type | Value | Description
-----------------------------------------------------
TESLA | 1 | TESLA as a security protocol
The value of 1 for the 'Prot Type' must be added to the 'Prot type' registry created by [RFC3830].
“保护类型”的值1必须添加到[RFC3830]创建的“保护类型”注册表中。
Type:
类型：
Type | Value | Description
-------------------------------------------
TESLA I-Key | 2 | TESLA initial key
Type | Value | Description
-------------------------------------------
TESLA I-Key | 2 | TESLA initial key
The value of 2 for the 'Type' must be added to the 'Type' registry created by [RFC3830]. The values of 0 and 1 are already registered in [RFC3830].
“Type”的值2必须添加到[RFC3830]创建的“Type”注册表中。0和1的值已在[RFC3830]中注册。
Also, the IANA has created two new registries:
此外，IANA还创建了两个新的注册中心：
TESLA-PRF: Pseudo-random Function (PRF) used in the TESLA policy:
特斯拉-PRF：特斯拉政策中使用的伪随机函数（PRF）：
This attribute specifies values for pseudo-random functions used in the TESLA policy (see Section 4.2).
该属性指定特斯拉政策中使用的伪随机函数的值（见第4.2节）。
TESLA-MAC: MAC Function used in TESLA:
特斯拉-MAC：特斯拉使用的MAC功能：
This attribute specifies values for pseudo-random functions used in the TESLA policy (see Section 4.2).
该属性指定特斯拉政策中使用的伪随机函数的值（见第4.2节）。
Following the policies outlined in [RFC2434], the values for the TESLA-PRF and the TESLA-MAC registry in the range up to 240 (including 240) for the above attributes are assigned after expert review by the MSEC working group or its designated successor. The values in the range from 241 to 255 are reserved for private use.
根据[RFC2434]中概述的政策，上述属性的特斯拉-PRF和特斯拉-MAC注册表的值在MSEC工作组或其指定继任者进行专家审查后分配，范围为240（包括240）。241到255之间的值保留供私人使用。
IANA has added the following values to the TESLA-PRF and the TESLA-MAC registry:
IANA已将以下值添加到TESLA-PRF和TESLA-MAC注册表中：
TESLA-PRF:
特斯拉-PRF：
PRF Function | Value
--------------------------
HMAC-SHA1 | 0
PRF Function | Value
--------------------------
HMAC-SHA1 | 0
TESLA-MAC:
特斯拉-MAC：
MAC Function | Value
--------------------------
HMAC-SHA1 | 0
MAC Function | Value
--------------------------
HMAC-SHA1 | 0
The authors would like to thank Mark Baugher and Ran Canetti for the discussions in context of time synchronization. Additionally, we would like to thank Lakshminath Dondeti, Russ Housley, and Allison Mankin for their document reviews and for their guidance.
作者要感谢Mark Baugher和Ran Canetti在时间同步方面的讨论。此外，我们还要感谢Lakshminath Dondeti、Russ Housley和Allison Mankin的文件审查和指导。
[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月。
[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月。
[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月。
[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月。
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006.
[RFC4383]Baugher，M.和E.Carrara，“在安全实时传输协议（SRTP）中使用定时高效流丢失容忍认证（TESLA）”，RFC 4383，2006年2月。
[DHHMAC] Euchner, M., "HMAC-authenticated Diffie-Hellman for MIKEY", Work in Progress, April 2005.
[DHHMAC]Euchner，M.，“HMAC为MIKEY认证Diffie Hellman”，正在进行的工作，2005年4月。
[PCST] Perrig, A., Canetti, R., Song, D., and D. Tygar, "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.，和D.Tygar，“多播的高效安全源认证”，在Proc。网络和分布式系统安全研讨会NDSS 2001，第35-46页，2001年。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（版本3）规范，实施”，RFC1305，1992年3月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[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月。
[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月。
[RSA-R] Ignjatic, D., "An additional mode of key distribution in MIKEY: MIKEY-RSA-R", Work in Progress, February 2006.
[RSA-R]Ignjatic，D.，“MIKEY中的另一种密钥分发模式：MIKEY-RSA-R”，正在进行的工作，2006年2月。
Authors' Addresses
作者地址
Steffen Fries Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
德国巴伐利亚州慕尼黑第6环Steffen Fries Siemens Otto Hahn 81739
EMail: steffen.fries@siemens.com
EMail: steffen.fries@siemens.com
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
德国巴伐利亚州慕尼黑第6环汉内斯·茨霍芬尼西门子奥托·哈恩81739
EMail: Hannes.Tschofenig@siemens.com
EMail: Hannes.Tschofenig@siemens.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）提供。