Network Working Group M. Friedl
Request for Comments: 4419 N. Provos
Category: Standards Track W. Simpson
March 2006
Network Working Group M. Friedl
Request for Comments: 4419 N. Provos
Category: Standards Track W. Simpson
March 2006
Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
用于安全外壳（SSH）传输层协议的Diffie-Hellman组交换
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 a new key exchange method for the Secure Shell (SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time.
此备忘录描述了安全Shell（SSH）协议的一种新密钥交换方法。它允许SSH服务器提出新的组，在这些组上执行与客户端的Diffie-Hellman密钥交换。建议的组不需要固定，可以随时间变化。
SSH [RFC4251] is a very common protocol for secure remote login on the Internet. Currently, SSH performs the initial key exchange using the "diffie-hellman-group1-sha1" method [RFC4253]. This method prescribes a fixed group on which all operations are performed.
SSH[RFC4251]是Internet上安全远程登录的一种非常常见的协议。目前，SSH使用“diffie-hellman-group1-sha1”方法执行初始密钥交换[RFC4253]。此方法规定了一个固定组，所有操作都在该组上执行。
The Diffie-Hellman key exchange provides a shared secret that cannot be determined by either party alone. Furthermore, the shared secret is known only to the participant parties. In SSH, the key exchange is signed with the host key to provide host authentication.
Diffie-Hellman密钥交换提供了一个无法由任何一方单独确定的共享秘密。此外，共享秘密仅为参与方所知。在SSH中，密钥交换使用主机密钥进行签名，以提供主机身份验证。
The security of the Diffie-Hellman key exchange is based on the difficulty of solving the Discrete Logarithm Problem (DLP). Since we expect that the SSH protocol will be in use for many years in the future, we fear that extensive precomputation and more efficient algorithms to compute the discrete logarithm over a fixed group might pose a security threat to the SSH protocol.
Diffie-Hellman密钥交换的安全性基于解决离散对数问题（DLP）的难度。由于我们预计SSH协议将在未来使用多年，因此我们担心大量的预计算和更有效的算法来计算固定组上的离散对数可能会对SSH协议造成安全威胁。
The ability to propose new groups will reduce the incentive to use precomputation for more efficient calculation of the discrete logarithm. The server can constantly compute new groups in the background.
提出新组的能力将减少使用预计算更有效地计算离散对数的动机。服务器可以在后台不断计算新组。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The server keeps a list of safe primes and corresponding generators that it can select from. A prime p is safe if p = 2q + 1 and q is prime. New primes can be generated in the background.
服务器保存一个安全素数和相应生成器的列表，可以从中进行选择。如果p=2q+1且q为素数，则素数p是安全的。新的素数可以在后台生成。
The generator g should be chosen such that the order of the generated subgroup does not factor into small primes; that is, with p = 2q + 1, the order has to be either q or p - 1. If the order is p - 1, then the exponents generate all possible public values, evenly distributed throughout the range of the modulus p, without cycling through a smaller subset. Such a generator is called a "primitive root" (which is trivial to find when p is "safe").
生成器g的选择应确保生成的子群的顺序不考虑小素数；也就是说，当p=2q+1时，顺序必须是q或p-1。如果阶数为p-1，则指数生成所有可能的公共值，均匀分布在模p的整个范围内，而不会循环通过较小的子集。这样的生成器称为“原始根”（当p是“安全的”时，很难找到它）。
The client requests a modulus from the server indicating the preferred size. In the following description (C is the client, S is the server, the modulus p is a large safe prime, and g is a generator for a subgroup of GF(p), min is the minimal size of p in bits that is acceptable to the client, n is the size of the modulus p in bits that the client would like to receive from the server, max is the maximal size of p in bits that the client can accept, V_S is S's version string, V_C is C's version string, K_S is S's public host key, I_C is C's KEXINIT message, and I_S is S's KEXINIT message that has been exchanged before this part begins):
客户端从服务器请求一个指示首选大小的模数。在下面的描述中（C是客户端，S是服务器，模p是一个大的安全素数，g是GF（p）的一个子组的生成器），min是客户端可以接受的以位表示的p的最小大小，n是客户端希望从服务器接收的以位表示的模数p的大小，max是客户端可以接受的以位表示的p的最大大小，V_S是S的版本字符串，V_C是C的版本字符串，K_S是S的公共主机密钥，I_C是C的KEXINIT消息，I_S是在本部分开始之前交换的S的KEXINIT消息）：
1. C sends "min || n || max" to S, indicating the minimal acceptable group size, the preferred size of the group, and the maximal group size in bits the client will accept.
1. C向S发送“min | | n | | max”，指示最小可接受组大小、组的首选大小以及客户端将接受的最大组大小（以位为单位）。
2. S finds a group that best matches the client's request, and sends "p || g" to C.
2. S找到最符合客户请求的组，并将“p | | g”发送给C。
3. C generates a random number x, where 1 < x < (p-1)/2. It computes e = g^x mod p, and sends "e" to S.
3. C生成一个随机数x，其中1<x<（p-1）/2。它计算e=g^x mod p，并向S发送“e”。
4. S generates a random number y, where 0 < y < (p-1)/2, and computes f = g^y mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S || K_S || min || n || max || p || g || e || f || K) (these elements are encoded according to their types; see below), and signature s on H with its private host key. S sends "K_S || f || s" to C. The signing operation may involve a second hashing operation.
4. S生成一个随机数y，其中0<y<（p-1）/2，并计算f=g^y mod p。S接受“e”。它计算K=e^y mod p，H=hash（V|C | V|S | I|C | I|S | K|S | min | n | max | p | g | e | f | | K）（这些元素根据它们的类型进行编码，见下文），并使用其私钥在H上签名。S向C发送“K|S|f|S”。签名操作可能涉及第二个哈希操作。
5. C verifies that K_S really is the host key for S (e.g., using certificates or a local database to obtain the public key). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks (but may be desirable for practical reasons in the short term in many environments). C then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S || min || n || max || p || g || e || f || K), and verifies the signature s on H.
5. C验证K_S是否真的是S的主机密钥（例如，使用证书或本地数据库获取公钥）。C也可以在未经验证的情况下接受密钥；但是，这样做会使协议不安全，无法抵御主动攻击（但在许多环境中，出于实际原因，短期内可能是可取的）。然后计算K=f^x mod p，H=hash（V|C|V|S|I|C|I|S|K|S|min | n | max | p | g | e | f | K），并验证H上的签名S。
Servers and clients SHOULD support groups with a modulus length of k bits, where 1024 <= k <= 8192. The recommended values for min and max are 1024 and 8192, respectively.
服务器和客户端应支持模数长度为k位的组，其中1024<=k<=8192。最小值和最大值的建议值分别为1024和8192。
Either side MUST NOT send or accept e or f values that are not in the range [1, p-1]. If this condition is violated, the key exchange fails. To prevent confinement attacks, they MUST accept the shared secret K only if 1 < K < p - 1.
任何一方不得发送或接受不在[1，p-1]范围内的e或f值。如果违反此条件，则密钥交换失败。为了防止限制攻击，只有当1<K<p-1时，他们才必须接受共享秘密K。
The server should return the smallest group it knows that is larger than the size the client requested. If the server does not know a group that is larger than the client request, then it SHOULD return the largest group it knows. In all cases, the size of the returned group SHOULD be at least 1024 bits.
服务器应返回它知道的最小组，该组大于客户端请求的大小。如果服务器不知道比客户端请求大的组，那么它应该返回它知道的最大组。在所有情况下，返回组的大小应至少为1024位。
This is implemented with the following messages. The hash algorithm for computing the exchange hash is defined by the method name, and is called HASH. The public key algorithm for signing is negotiated with the KEXINIT messages.
这是通过以下消息实现的。计算交换哈希的哈希算法由方法名定义，称为哈希。签名的公钥算法与KEXINIT消息协商。
First, the client sends:
首先，客户端发送：
byte SSH_MSG_KEY_DH_GEX_REQUEST uint32 min, minimal size in bits of an acceptable group uint32 n, preferred size in bits of the group the server will send uint32 max, maximal size in bits of an acceptable group
字节SSH\u MSG\u KEY\u DH\u GEX\u请求uint32 min，可接受组uint32 n的最小位大小，服务器将发送的组的首选位大小uint32 max，可接受组的最大位大小
The server responds with
服务器以
byte SSH_MSG_KEX_DH_GEX_GROUP mpint p, safe prime mpint g, generator for subgroup in GF(p)
字节SSH_MSG_KEX_DH_GEX_组mpint p，安全素数mpint g，GF（p）中子组的生成器
The client responds with:
客户的回应是：
byte SSH_MSG_KEX_DH_GEX_INIT mpint e
字节SSH_MSG_KEX_DH_GEX_INIT mpint e
The server responds with:
服务器响应为：
byte SSH_MSG_KEX_DH_GEX_REPLY string server public host key and certificates (K_S) mpint f string signature of H
字节SSH_MSG_KEX_DH_GEX_回复字符串服务器公共主机密钥和证书（K_S）mpint f字符串签名H
The hash H is computed as the HASH hash of the concatenation of the following:
散列H被计算为以下各项的串联的散列：
string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the host key uint32 min, minimal size in bits of an acceptable group uint32 n, preferred size in bits of the group the server will send uint32 max, maximal size in bits of an acceptable group mpint p, safe prime mpint g, generator for subgroup mpint e, exchange value sent by the client mpint f, exchange value sent by the server mpint K, the shared secret
字符串V_C、客户端的版本字符串（CR和NL除外）字符串V_s、服务器的版本字符串（CR和NL除外）字符串I_C、客户端的SSH_MSG_KEXINIT字符串I_的有效负载、服务器的SSH_MSG_KEXINIT字符串K_s的有效负载、主机密钥uint32 min、可接受组uint32 n的最小位大小，服务器将发送的组的首选大小（以位为单位）uint32 max、可接受组的最大大小（以位为单位）mpint p、安全素数mpint g、子组mpint e的生成器、客户端发送的交换值mpint f、服务器发送的交换值mpint K、共享机密
This value is called the exchange hash, and it is used to authenticate the key exchange as per [RFC4253].
该值称为交换哈希，用于根据[RFC4253]对密钥交换进行身份验证。
This document defines two new key exchange methods: "diffie-hellman-group-exchange-sha1" and "diffie-hellman-group-exchange-sha256".
本文档定义了两种新的密钥交换方法：“diffie-hellman-group-exchange-sha1”和“diffie-hellman-group-exchange-sha256”。
The "diffie-hellman-group-exchange-sha1" method specifies Diffie-Hellman Group and Key Exchange with SHA-1 [FIPS-180-2] as HASH.
“diffie-hellman-group-exchange-sha1”方法将diffie-hellman组和与SHA-1[FIPS-180-2]的密钥交换指定为散列。
The "diffie-hellman-group-exchange-sha256" method specifies Diffie-Hellman Group and Key Exchange with SHA-256 [FIPS-180-2] as HASH.
“diffie-hellman-group-exchange-sha256”方法将diffie-hellman组和密钥交换与SHA-256[FIPS-180-2]指定为散列。
Note that the hash used in key exchange (in this case, SHA-256) must also be used in the key derivation pseudo-random function (PRF), as per the requirement in the "Output from Key Exchange" section in [RFC4253].
请注意，根据[RFC4253]中“密钥交换输出”部分的要求，密钥交换中使用的哈希（在本例中为SHA-256）也必须用于密钥派生伪随机函数（PRF）。
The following message numbers have been defined in this document. They are in a name space private to this document and not assigned by IANA.
本文档中定义了以下消息编号。它们位于本文档专用的名称空间中，不由IANA分配。
#define SSH_MSG_KEX_DH_GEX_REQUEST_OLD 30 #define SSH_MSG_KEX_DH_GEX_REQUEST 34 #define SSH_MSG_KEX_DH_GEX_GROUP 31 #define SSH_MSG_KEX_DH_GEX_INIT 32 #define SSH_MSG_KEX_DH_GEX_REPLY 33
#定义SSH_MSG_KEX_DH_GEX_请求旧30#定义SSH_MSG_KEX_DH GEX_请求34#定义SSH_MSG_KEX_DH GEX_组31#定义SSH_MSG_KEX_DH GEX_初始32#定义SSH_MSG_KEX_DH GEX_答复33
SSH_MSG_KEX_DH_GEX_REQUEST_OLD is used for backward compatibility. Instead of sending "min || n || max", the client only sends "n". In addition, the hash is calculated using only "n" instead of "min || n || max".
SSH_MSG_KEX_DH_GEX_REQUEST_OLD用于向后兼容。客户端只发送“n”，而不发送“min | n | max”。此外，哈希仅使用“n”而不是“min | | n | max”计算。
The numbers 30-49 are key exchange specific and may be redefined by other kex methods.
数字30-49是特定于密钥交换的，可以通过其他kex方法重新定义。
One useful technique is to select the generator, and then limit the modulus selection sieve to primes with that generator:
一种有用的技术是选择生成器，然后将模量选择筛限制为使用该生成器的素数：
2 when p (mod 24) = 11. 5 when p (mod 10) = 3 or 7.
当p（mod 24）=11时为2。当p（mod 10）=3或7时为5。
It is recommended to use 2 as generator, because it improves efficiency in multiplication performance. It is usable even when it is not a primitive root, as it still covers half of the space of possible residues.
建议使用2作为生成器，因为它提高了乘法性能的效率。即使它不是原始根，也可以使用，因为它仍然覆盖了可能的残基的一半空间。
To increase the speed of the key exchange, both client and server may reduce the size of their private exponents. It should be at least twice as long as the key material that is generated from the shared secret. For more details, see the paper by van Oorschot and Wiener [VAN-OORSCHOT].
为了提高密钥交换的速度，客户端和服务器都可以减小其私有索引的大小。它应该至少是由共享机密生成的密钥材料的两倍长。有关更多详细信息，请参阅van Oorschot和Wiener的论文[van-Oorschot]。
This protocol aims to be simple and uses only well-understood primitives. This encourages acceptance by the community and allows for ease of implementation, which hopefully leads to a more secure system.
该协议的目标是简单，只使用易于理解的原语。这鼓励了社区的接受，并允许易于实施，这有望导致一个更安全的系统。
The use of multiple moduli inhibits a determined attacker from precalculating moduli exchange values, and discourages dedication of resources for analysis of any particular modulus.
使用多个模会阻止确定的攻击者预先计算模交换值，并阻止将资源用于分析任何特定模。
It is important to employ only safe primes as moduli, as they allow us to find a generator g so that the order of the generated subgroup does not factor into small primes, that is, with p = 2q + 1, the order has to be either q or p - 1. If the order is p - 1, then the exponents generate all possible public values, evenly distributed throughout the range of the modulus p, without cycling through a smaller subset. Van Oorshot and Wiener note that using short private exponents with a random prime modulus p makes the computation of the discrete logarithm easy [VAN-OORSCHOT]. However, they also state that this problem does not apply to safe primes.
只使用安全素数作为模是很重要的，因为它们允许我们找到一个生成器g，这样生成的子群的阶数就不会变成小素数，也就是说，当p=2q+1时，阶数必须是q或p-1。如果阶数为p-1，则指数生成所有可能的公共值，均匀分布在模p的整个范围内，而不会循环通过较小的子集。Van Oorshot和Wiener注意到，使用带有随机素数模p的短私有指数可以简化离散对数的计算[Van-OORSCHOT]。然而，他们也声明这个问题不适用于安全素数。
The least significant bit of the private exponent can be recovered when the modulus is a safe prime [MENEZES]. However, this is not a problem if the size of the private exponent is big enough. Related to this, Waldvogel and Massey note: When private exponents are chosen independently and uniformly at random from {0,...,p-2}, the key entropy is less than 2 bits away from the maximum, lg(p-1) [WALDVOGEL].
当模为安全素数[MENEZES]时，可以恢复私有指数的最低有效位。但是，如果私有指数的大小足够大，这就不是问题。与此相关，Waldvogel和Massey注：当从{0，…，p-2}中独立且均匀地随机选择私有指数时，密钥熵与最大值lg（p-1）[Waldvogel]的距离小于2位。
The security considerations in [RFC4251] also apply to this key exchange method.
[RFC4251]中的安全注意事项也适用于此密钥交换方法。
The document is derived in part from "SSH Transport Layer Protocol" [RFC4253] by T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen.
本文档部分源自T.Ylonen、T.Kivinen、M.Saarinen、T.Rinne和S.Lehtinen的“SSH传输层协议”[RFC4253]。
Markku-Juhani Saarinen pointed out that the least significant bit of the private exponent can be recovered efficiently when using safe primes and a subgroup with an order divisible by two.
Markku Juhani Saarinen指出，当使用安全素数和阶数可被2整除的子群时，可以有效地恢复私有指数的最低有效位。
Bodo Moeller suggested that the server send only one group, reducing the complexity of the implementation and the amount of data that needs to be exchanged between client and server.
Bodo Moeller建议服务器只发送一个组，从而降低了实现的复杂性以及客户端和服务器之间需要交换的数据量。
Appendix A: Generation of Safe Primes
附录A：安全素数的生成
The "Handbook of Applied Cryptography" [MENEZES] lists the following algorithm to generate a k-bit safe prime p. It has been modified so that 2 is a generator for the multiplicative group mod p.
《应用密码学手册》[MENEZES]列出了以下生成k位安全素数p的算法。它被修改为2是乘法群mod p的生成器。
1. Do the following:
1. 请执行以下操作：
1. Select a random (k-1)-bit prime q, so that q mod 12 = 5.
1. 选择一个随机（k-1）位素数q，使q mod 12=5。
2. Compute p := 2q + 1, and test whether p is prime (using, e.g., trial division and the Rabin-Miller test).
2. 计算p:=2q+1，并测试p是否为素数（例如使用试除法和Rabin-Miller测试）。
2. Repeat until p is prime.
2. 重复此步骤，直到p为素数。
If an implementation uses the OpenSSL libraries, a group consisting of a 1024-bit safe prime and 2 as generator can be created as follows:
如果实现使用OpenSSL库，则可以按如下方式创建由1024位安全素数和2个as生成器组成的组：
DH *d = NULL;
d = DH_generate_parameters(1024, DH_GENERATOR_2, NULL, NULL);
BN_print_fp(stdout, d->p);
DH *d = NULL;
d = DH_generate_parameters(1024, DH_GENERATOR_2, NULL, NULL);
BN_print_fp(stdout, d->p);
The order of the subgroup generated by 2 is q = p - 1.
由2生成的子群的顺序是q=p-1。
References
工具书类
Normative References
规范性引用文件
[FIPS-180-2] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002.
[FIPS-180-2]国家标准与技术研究所（NIST），“安全哈希标准（SHS）”，FIPS PUB 180-22002，2002年8月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251]Ylonen，T.和C.Lonvick，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[RFC4253] Lonvick, C., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253]Lonvick，C.，“安全外壳（SSH）传输层协议”，RFC4253，2006年1月。
[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月。
Informative References
资料性引用
[MENEZES] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, p. 537, 1996.
[MENEZES]MENEZES，A.，van Oorschot，P.，和S.Vanstone，“应用密码学手册”，CRC出版社，P。537, 1996.
[VAN-OORSCHOT] van Oorschot, P. and M. Wiener, "On Diffie-Hellman key agreement with short exponents", Advances in Cryptology -EUROCRYPT'96, LNCS 1070, Springer-Verlag, pp. 332-343, 1996.
[VAN-OORSCHOT]VAN OORSCHOT，P.和M.Wiener，“关于Diffie-Hellman与短指数的密钥协议”，《密码学进展——欧洲密码学》96，LNCS 1070，Springer Verlag，第332-343页，1996年。
[WALDVOGEL] Waldvogel, C. and J. Massey, "The probability distribution of the Diffie-Hellman key", Proceedings of AUSCRYPT 92, LNCS 718, Springer-Verlag, pp. 492-504, 1993.
[WALDVOGEL]WALDVOGEL，C.和J.Massey，“Diffie-Hellman密钥的概率分布”，《AUSCRYPT 92论文集》，LNCS 718，Springer Verlag，第492-504页，1993年。
Authors' Addresses
作者地址
Markus Friedl EMail: markus@openbsd.org
Markus Friedl电子邮件：markus@openbsd.org
Niels Provos EMail: provos@citi.umich.edu
Niels Provos电子邮件：provos@citi.umich.edu
William A. Simpson EMail: wsimpson@greendragon.com
William A.Simpson电子邮件：wsimpson@greendragon.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）提供。