Network Working Group B. Weis
Request for Comments: 4359 Cisco Systems
Category: Standards Track January 2006
Network Working Group B. Weis
Request for Comments: 4359 Cisco Systems
Category: Standards Track January 2006
The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)
在封装安全有效负载（ESP）和身份验证头（AH）中使用RSA/SHA-1签名
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 RSA digital signature algorithm as an authentication algorithm within the revised IP Encapsulating Security Payload (ESP) as described in RFC 4303 and the revised IP Authentication Header (AH) as described in RFC 4302. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet.
本备忘录描述了RSA数字签名算法作为认证算法在RFC 4303中所述经修订的IP封装安全有效负载（ESP）和RFC 4302中所述经修订的IP认证头（AH）中的使用。当密钥方法（如HMAC）不提供此属性时，使用RSA等数字签名算法可在应用程序中提供数据源身份验证。一个例子是使用ESP和AH对IP多播数据包的发送者进行身份验证。
Table of Contents
目录
1. Introduction ....................................................2
2. Algorithm and Mode ..............................................3
2.1. Key Size Discussion ........................................4
3. Performance .....................................................5
4. Interaction with the ESP Cipher Mechanism .......................6
5. Key Management Considerations ...................................6
6. Security Considerations .........................................7
6.1. Eavesdropping ..............................................7
6.2. Replay .....................................................7
6.3. Message Insertion ..........................................8
6.4. Deletion ...................................................8
6.5. Modification ...............................................8
6.6. Man in the Middle ..........................................8
6.7. Denial of Service ..........................................8
7. IANA Considerations .............................................9
8. Acknowledgements ...............................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
1. Introduction ....................................................2
2. Algorithm and Mode ..............................................3
2.1. Key Size Discussion ........................................4
3. Performance .....................................................5
4. Interaction with the ESP Cipher Mechanism .......................6
5. Key Management Considerations ...................................6
6. Security Considerations .........................................7
6.1. Eavesdropping ..............................................7
6.2. Replay .....................................................7
6.3. Message Insertion ..........................................8
6.4. Deletion ...................................................8
6.5. Modification ...............................................8
6.6. Man in the Middle ..........................................8
6.7. Denial of Service ..........................................8
7. IANA Considerations .............................................9
8. Acknowledgements ...............................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
Encapsulating Security Payload (ESP) [ESP] and Authentication Header (AH) [AH] headers can be used to protect both unicast traffic and group (e.g., IPv4 and IPv6 multicast) traffic. When unicast traffic is protected between a pair of entities, HMAC transforms (such as [HMAC-SHA]) are sufficient to prove data origin authentication. An HMAC is sufficient protection in that scenario because only the two entities involved in the communication have access to the key, and proof-of-possession of the key in the HMAC construct authenticates the sender. However, when ESP and AH authenticate group traffic, this property no longer holds because all group members share the single HMAC key. In the group case, the identity of the sender is not uniquely established, since any of the key holders has the ability to form the HMAC transform. Although the HMAC transform establishes a group-level security property, data origin authentication is not achieved.
封装安全有效负载（ESP）[ESP]和身份验证头（AH）[AH]头可用于保护单播流量和组（例如IPv4和IPv6多播）流量。当一对实体之间的单播通信受到保护时，HMAC转换（如[HMAC-SHA]）足以证明数据源身份验证。在这种情况下，HMAC是足够的保护，因为只有通信中涉及的两个实体可以访问密钥，并且HMAC构造中的密钥占有证明可以认证发送方。但是，当ESP和AH对组通信进行身份验证时，此属性不再有效，因为所有组成员共享单个HMAC密钥。在分组情况下，发送方的身份不是唯一建立的，因为任何密钥持有者都有能力形成HMAC变换。尽管HMAC转换建立了组级安全属性，但未实现数据源身份验证。
Some group applications require true data origin authentication, where one group member cannot successfully impersonate another group member. The use of asymmetric digital signature algorithms, such as RSA, can provide true data origin authentication.
某些组应用程序需要真正的数据源身份验证，其中一个组成员无法成功模拟另一个组成员。使用非对称数字签名算法（如RSA）可以提供真正的数据源身份验证。
With asymmetric algorithms, the sender generates a pair of keys, one of which is never shared (called the "private key") and one of which is distributed to other group members (called the "public key").
使用非对称算法，发送方生成一对密钥，其中一个从未共享（称为“私钥”），另一个分配给其他组成员（称为“公钥”）。
When the private key is used to sign the output of a cryptographic hash algorithm, the result is called a "digital signature". A receiver of the digital signature uses the public key, the signature value, and an independently computed hash to determine whether or not the claimed origin of the packet is correct.
当使用私钥对加密哈希算法的输出进行签名时，结果称为“数字签名”。数字签名的接收者使用公钥、签名值和独立计算的散列来确定所声称的数据包来源是否正确。
This memo describes how RSA digital signatures can be applied as an ESP and AH authentication mechanism to provide data origin authentication.
本备忘录描述了如何将RSA数字签名应用为ESP和AH身份验证机制，以提供数据源身份验证。
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 RSA Public Key Algorithm [RSA] is a widely deployed public key algorithm commonly used for digital signatures. Compared to other public key algorithms, signature verification is relatively efficient. This property is useful for groups where receivers may have limited processing capabilities. The RSA algorithm is commonly supported in hardware.
RSA公钥算法[RSA]是一种广泛部署的公钥算法，通常用于数字签名。与其他公钥算法相比，签名验证相对高效。此属性对于接收机处理能力有限的组非常有用。RSA算法通常在硬件上得到支持。
Two digital signature encoding methods are supported in [RSA]. RSASSA-PKCS1-v1_5 MUST be supported by a conforming implementation. RSASSA-PSS is generally believed to be more secure, but at the time of this writing is not ubiquitous. RSASSA-PSS SHOULD be used whenever it is available. SHA-1 [SHA] MUST be used as the signature hash algorithm used by the RSA digital signature algorithm.
[RSA]中支持两种数字签名编码方法。RSASSA-PKCS1-v1_5必须由一致性实施支持。RSASSA-PSS通常被认为更安全，但在撰写本文时，它并不普遍。无论何时，只要使用RSA-PSS，都应使用它。SHA-1[SHA]必须用作RSA数字签名算法使用的签名哈希算法。
When specified for ESP, the Integrity Check Value (ICV) is equal in size to the RSA modulus, unless the RSA modulus is not a multiple of 8 bits. In this case, the ICV MUST be prepended with between 1 and 7 bits set to zero such that the ICV is a multiple of 8 bits. This specification matches the output S [RSA, Section 8.1.1] (RSASSA-PSS) and [RSA, Section 8.2.1] (RSASSA-PKCS1-v1_5) when the RSA modulus is not a multiple of 8 bits. No implicit ESP ICV Padding bits are necessary.
当为ESP指定时，完整性检查值（ICV）的大小等于RSA模，除非RSA模不是8位的倍数。在这种情况下，ICV必须在1到7位之间设置为零，以便ICV是8位的倍数。当RSA模数不是8位的倍数时，本规范匹配输出S[RSA，第8.1.1节]（RSASSA-PSS）和[RSA，第8.2.1节]（RSASSA-PKCS1-v1_5）。不需要隐式ESP ICV填充位。
When specified for AH, the ICV is equal in size of the RSA modulus, unless the RSA modulus is not a multiple of 32 bits (IPv4) or 64 bits (IPv6) [AH, Section 2.6]. In this case, explicit ICV Padding bits are necessary to create a suitably sized ICV [AH, Section 3.3.3.2.1].
当为AH指定时，ICV的大小等于RSA模，除非RSA模不是32位（IPv4）或64位（IPv6）的倍数[AH，第2.6节]。在这种情况下，需要显式ICV填充位来创建适当大小的ICV[AH，第3.3.3.2.1节]。
The distribution mechanism of the RSA public key and its replacement interval are a group policy matter. The use of an ephemeral key pair with a lifetime of the ESP or AH Security Association (SA) is RECOMMENDED. This recommended policy reduces the exposure of the RSA
RSA公钥的分发机制及其替换间隔是一个组策略问题。建议使用寿命为ESP或AH安全关联（SA）的临时密钥对。此推荐策略可减少RSA的风险敞口
private key to the lifetime of the data being signed by the private key. Also, this obviates the need to revoke or transmit the validity period of the key pair.
私钥由私钥签名的数据的生存期。此外，这避免了撤销或传输密钥对有效期的需要。
Digital signature generation is performed as described in [RSA, Section 8.1.1] (RSASSA-PSS) and [RSA, Section 8.2.1](RSASSA-PKCS1- v1_5). The authenticated portion of the AH or ESP packet ([AH, Section 3.3.3], [ESP, Section 3.3.2]) is used as the message M, which is passed to the signature generation function. The signer's RSA private key is passed as K. Summarizing, the signature generation process computes a SHA-1 hash of the authenticated packet bytes, signs the SHA-1 hash using the private key, and encodes the result with the specified RSA encoding type. This process results in a value S, which is known as the ICV in AH and ESP.
按照[RSA，第8.1.1节]（RSASSA-PSS）和[RSA，第8.2.1节]（RSASSA-PKCS1-v1_5）中的说明执行数字签名生成。AH或ESP数据包的认证部分（[AH，第3.3.3节]，[ESP，第3.3.2节]）用作消息M，该消息传递给签名生成功能。签名者的RSA私钥作为K传递。总之，签名生成过程计算经过身份验证的数据包字节的SHA-1哈希，使用私钥对SHA-1哈希进行签名，并使用指定的RSA编码类型对结果进行编码。该过程产生一个值S，在AH和ESP中称为ICV。
Digital signature verification is performed as described in [RSA, Section 8.1.2] (RSASSA-PSS) and [RSA, Section 8.2.2] (RSASSA-PKCS1-v1_5). Upon receipt, the ICV is passed to the verification function as S. The authenticated portion of the AH or ESP packet is used as the message M, and the RSA public key is passed as (n, e). In summary, the verification function computes a SHA-1 hash of the authenticated packet bytes, decrypts the SHA-1 hash in the ICV, and validates that the appropriate encoding was applied and was correct. The two SHA-1 hashes are compared, and if they are identical the validation is successful.
按照[RSA，第8.1.2节]（RSASSA-PSS）和[RSA，第8.2.2节]（RSASSA-PKCS1-v1_5）中的说明执行数字签名验证。收到后，ICV作为S传递给验证功能。AH或ESP数据包的认证部分用作消息M，RSA公钥作为（n，e）传递。总之，验证函数计算经过身份验证的数据包字节的SHA-1散列，解密ICV中的SHA-1散列，并验证是否应用了正确的编码。比较两个SHA-1散列，如果它们相同，则验证成功。
The choice of RSA modulus size must be made carefully. If too small of a modulus size is chosen, an attacker may be able to reconstruct the private key used to sign packets before the key is no longer used by the sender to sign packets. This order of events may result in the data origin authentication property being compromised. However, choosing a modulus size larger than necessary will result in an unnecessarily high cost of CPU cycles for the sender and all receivers of the packet.
必须仔细选择RSA模数大小。如果选择的模数太小，攻击者可能会在发送方不再使用密钥对数据包进行签名之前，重构用于对数据包进行签名的私钥。此事件顺序可能导致数据源身份验证属性受损。然而，选择大于所需的模大小将导致数据包的发送方和所有接收方的CPU周期的不必要的高成本。
A conforming implementation MUST support a modulus size of 1024 bits.
一致性实现必须支持1024位的模大小。
Recent guidance [TWIRL, RSA-TR] on key sizes makes estimates as to the amount of effort an attacker would need to expend in order to reconstruct an RSA private key. Table 1 summarizes the maximum length of time that selected modulus sizes should be used. Note that these recommendations are based on factors such as the cost of processing and memory, as well as cryptographic analysis methods, which were current at the time these documents were published. As those factors change, choices of key lifetimes should take them into account.
最近关于密钥大小的指南[TWIRL，RSA-TR]对攻击者重建RSA私钥所需的工作量进行了估计。表1总结了所选模量尺寸应使用的最大时间长度。请注意，这些建议是基于处理和内存成本以及密码分析方法等因素的，这些方法在这些文档发布时是最新的。随着这些因素的变化，关键生命周期的选择应该考虑到它们。
Number of Recommended Maximum
Modulus Bits Lifetime
------------ -------------------
768 1 week
1024 1 year
Number of Recommended Maximum
Modulus Bits Lifetime
------------ -------------------
768 1 week
1024 1 year
Table 1. RSA Key Use Lifetime Recommendations
表1。RSA密钥使用寿命建议
The RSA asymmetric key algorithm is very costly in terms of processing time compared to the HMAC algorithms. However, processing cost is decreasing over time. Faster general-purpose processors are being deployed, faster software implementations are being developed, and hardware acceleration support for the algorithm is becoming more prevalent.
与HMAC算法相比，RSA非对称密钥算法在处理时间方面非常昂贵。然而，随着时间的推移，处理成本正在下降。部署更快的通用处理器，开发更快的软件实现，对算法的硬件加速支持也越来越普遍。
Care should be taken that RSA signatures are not used for applications when potential receivers are known to lack sufficient processing power to verify the signature. It is also important to use this scheme judiciously when any receiver may be battery powered.
当已知潜在接收器缺乏足够的处理能力来验证签名时，应注意不要将RSA签名用于应用程序。当任何接收器可能由电池供电时，明智地使用此方案也很重要。
The RSA asymmetric key algorithm is best suited to protect network traffic for which:
RSA非对称密钥算法最适合保护以下网络流量：
o The sender has a substantial amount of processing power, and
o 发送方具有相当大的处理能力，并且
o The network traffic is small enough that adding a relatively large authentication tag (in the range of 62 to 256 bytes) does not cause packet fragmentation.
o 网络流量足够小，因此添加相对较大的身份验证标签（在62到256字节的范围内）不会导致数据包碎片。
RSA key pair generation and signing are substantially more expensive operations than signature verification, but these are isolated to the sender.
RSA密钥对生成和签名是比签名验证更昂贵的操作，但这些操作与发送方是隔离的。
The size of the RSA modulus affects the processing required to create and verify RSA digital signatures. Care should be taken to determine the size of modulus needed for the application. Smaller modulus sizes may be chosen as long as the network traffic protected by the private key flows for less time than it is estimated that an attacker would take to discover the private key. This lifetime is considerably smaller than most public key applications that store the signed data for a period of time. But since the digital signature is used only for sender verification purposes, a modulus that is considered weak in another context may be satisfactory.
RSA模数的大小会影响创建和验证RSA数字签名所需的处理。应注意确定应用所需的模量大小。只要受私钥保护的网络流量流动的时间少于估计攻击者发现私钥所需的时间，就可以选择较小的模数大小。此生命周期比存储签名数据一段时间的大多数公钥应用程序小得多。但是，由于数字签名仅用于发送方验证目的，因此在另一上下文中被视为弱的模可能是令人满意的。
The size of the RSA public exponent can affect the processing required to verify RSA digital signatures. Low-exponent RSA signatures may result in a lower verification processing cost. At the time of this writing, no attacks are known against low-exponent RSA signatures that would allow an attacker to create a valid signature using the RSAES-OAEP scheme.
RSA公共指数的大小可能会影响验证RSA数字签名所需的处理。低指数RSA签名可以降低验证处理成本。在撰写本文时，尚不知道针对低指数RSA签名的攻击会允许攻击者使用RSAES-OAEP方案创建有效签名。
The addition of a digital signature as an authentication tag adds a significant number of bytes to the packet. This increases the likelihood that the packet encapsulated in ESP or AH may be fragmented.
添加数字签名作为身份验证标签会向数据包添加大量字节。这增加了封装在ESP或AH中的数据包碎片化的可能性。
The RSA signature algorithm cannot be used with an ESP Combined Mode algorithm that includes an explicit ICV. The Combined Mode algorithm will add the ESP ICV field, which does not allow use of a separate authentication algorithm to add the ESP ICV field. One example of such an algorithm is the ESP Galois/Counter Mode algorithm [AES-GCM].
RSA签名算法不能与包含显式ICV的ESP组合模式算法一起使用。组合模式算法将添加ESP ICV字段，这不允许使用单独的身份验证算法添加ESP ICV字段。这种算法的一个例子是ESP伽罗瓦/计数器模式算法[AES-GCM]。
Key management mechanisms negotiating the use of RSA signatures MUST include the length of the RSA modulus during policy negotiation using the Authentication Key Length SA Attribute. This gives a device the opportunity to decline use of the algorithm. This is especially important for devices with constrained processors that might not be able to verify signatures using larger key sizes.
协商RSA签名使用的密钥管理机制必须在使用身份验证密钥长度SA属性的策略协商期间包括RSA模数的长度。这使设备有机会拒绝使用该算法。这对于处理器受限的设备尤其重要，因为这些设备可能无法使用较大的密钥大小验证签名。
Key management mechanisms negotiating the use of RSA signatures also MUST include the encoding method during policy negotiation using the Signature Encoding Algorithm SA Attribute.
协商RSA签名使用的密钥管理机制还必须在使用签名编码算法SA属性的策略协商期间包括编码方法。
A receiver must have the RSA public key in order to verify integrity of the packet. When used with a group key management system (e.g., RFC 3547 [GDOI]), the public key SHOULD be sent as part of the key download policy. If the group has multiple senders, the public key of each sender SHOULD be sent as part of the key download policy.
接收方必须拥有RSA公钥才能验证数据包的完整性。当与组密钥管理系统（例如RFC 3547[GDOI]）一起使用时，公钥应作为密钥下载策略的一部分发送。如果组有多个发件人，则每个发件人的公钥应作为密钥下载策略的一部分发送。
Use of this transform to obtain data origin authentication for pairwise SAs is NOT RECOMMENDED. In the case of pairwise SAs (such as negotiated by the Internet Key Exchange [IKEV2]), data origin authentication can be achieved with an HMAC transform. Because the performance impact of an RSA signature is typically greater than an HMAC, the value of using this transform for a pairwise connection is limited.
不建议使用此转换为成对SAs获取数据源身份验证。在成对SA的情况下（例如通过互联网密钥交换[IKEV2]协商），可以通过HMAC转换实现数据源身份验证。由于RSA签名对性能的影响通常大于HMAC，因此将此转换用于成对连接的价值是有限的。
This document provides a method of authentication for ESP and AH using digital signatures. This feature provides the following protections:
本文档提供了使用数字签名对ESP和AH进行身份验证的方法。此功能提供以下保护：
o Message modification integrity. The digital signature allows the receiver of the message to verify that it was exactly the same as when the sender signed it.
o 消息修改完整性。数字签名允许消息接收者验证消息是否与发送者签名时完全相同。
o Host authentication. The asymmetric nature of the RSA public key algorithm allows the sender to be uniquely verified, even when the message is sent to a group.
o 主机身份验证。RSA公钥算法的非对称性质允许对发送者进行唯一验证，即使消息被发送到组时也是如此。
Non-repudiation is not claimed as a property of this transform. At times, the property of non-repudiation may be applied to digital signatures on application-level objects (e.g., electronic mail). However, this document describes a means of authenticating network-level objects (i.e., IP packets), which are ephemeral and not directly correlated to any application. Non-repudiation is not applicable to network-level objects (i.e., IP packets).
不可抵赖性不是此转换的属性。有时，不可否认性的属性可应用于应用程序级对象（例如电子邮件）上的数字签名。然而，本文档描述了一种验证网络级对象（即IP数据包）的方法，这些对象是短暂的，与任何应用程序都没有直接关联。不可否认性不适用于网络级对象（即IP数据包）。
A number of attacks are suggested by [RFC3552]. The following sections describe the risks those attacks present when RSA signatures are used for ESP and AH packet authentication.
[RFC3552]提出了许多攻击。以下各节描述了将RSA签名用于ESP和AH数据包身份验证时存在的这些攻击风险。
SHA-1 has been scheduled to be phased out in 2010, due to the steady advances in technology by which an adversary can double its computing power in roughly eighteen months. Recent attacks on SHA-1 underscore the importance of replacing SHA-1, but have not motivated replacing it before that date [SHA-COMMENTS]. The use of this transform after that date SHOULD be preceded by an analysis as to its continued suitability.
SHA-1计划在2010年逐步淘汰，因为技术的稳步进步，对手可以在大约18个月内将其计算能力翻一番。最近对SHA-1的攻击强调了更换SHA-1的重要性，但没有在该日期之前更换它的动机[SHA-COMMENTS]。在该日期之后使用该转换之前，应先对其持续适用性进行分析。
This document does not address confidentiality. That function, if desired, must be addressed by an ESP cipher that is used with the RSA signatures authentication method. The RSA signature itself does not need to be protected from an eavesdropper.
本文件不涉及保密性。如果需要，该函数必须由与RSA签名身份验证方法一起使用的ESP密码寻址。RSA签名本身不需要保护以防窃听。
This document does not address replay attacks. That function, if desired, is addressed through use of ESP and AH sequence numbers as defined in [ESP] and [AH].
本文档不涉及重播攻击。如果需要，可通过使用[ESP]和[AH]中定义的ESP和AH序列号来实现该功能。
This document directly addresses message insertion attacks. Inserted messages will fail authentication and be dropped by the receiver.
本文档直接处理消息插入攻击。插入的消息将无法通过身份验证，并被接收方丢弃。
This document does not address deletion attacks. It is concerned only with validating the legitimacy of messages that are not deleted.
本文档不涉及删除攻击。它只涉及验证未删除消息的合法性。
This document directly addresses message modification attacks. Modified messages will fail authentication and be dropped by the receiver.
本文档直接处理消息修改攻击。修改后的消息将无法通过身份验证，并被接收方丢弃。
As long as a receiver is given the sender RSA public key in a trusted manner (e.g., by a key management protocol), it will be able to verify that the digital signature is correct. A man in the middle will not be able to spoof the actual sender unless it acquires the RSA private key through some means.
只要接收方以可信的方式（例如通过密钥管理协议）获得发送方RSA公钥，它就能够验证数字签名是否正确。中间人不能欺骗实际发送者，除非它通过某种手段获取RSA私钥。
The RSA modulus size must be chosen carefully to ensure that the time a man in the middle needs to determine the RSA private key through cryptanalysis is longer than the amount of time that packets are signed with that private key.
必须仔细选择RSA模数大小，以确保中间人需要通过密码分析确定RSA私钥的时间比用该私钥签名的包的时间长。
According to IPsec processing rules, a receiver of an ESP and AH packet begins by looking up the Security Association in the SA database. If one is found, the ESP or AH sequence number in the packet is verified. No further processing will be applied to packets with an invalid sequence number.
根据IPsec处理规则，ESP和AH数据包的接收方首先在SA数据库中查找安全关联。如果找到一个，则验证数据包中的ESP或AH序列号。将不对序列号无效的数据包应用进一步的处理。
An attacker that sends an ESP or AH packet matching a valid SA on the system and also having a valid sequence number will cause the receiver to perform the ESP or AH authentication step. Because the process of verifying an RSA digital signature consumes relatively large amounts of processing, many such packets could lead to a denial of service (DoS) attack on the receiver.
如果攻击者发送的ESP或AH数据包与系统上的有效SA匹配，并且具有有效序列号，则会导致接收方执行ESP或AH身份验证步骤。由于验证RSA数字签名的过程消耗相对较大的处理量，因此许多此类数据包可能会导致对接收器的拒绝服务（DoS）攻击。
If the message was sent to an IPv4 or IPv6 multicast group, all group members that received the packet would be under attack simultaneously.
如果消息被发送到IPv4或IPv6多播组，则接收该数据包的所有组成员都将同时受到攻击。
This attack can be mitigated against most attackers by encapsulating ESP or AH using an RSA signature for authentication within ESP or AH using an HMAC transform for authentication. In this case, the HMAC transform would be validated first, and as long as the attacker does not possess the HMAC key no digital signatures would be evaluated on the attacker packets. However, if the attacker does possess the HMAC key (e.g., the attacker is a legitimate member of the group using the SA), then the DoS attack cannot be mitigated.
通过在ESP中使用RSA签名进行身份验证来封装ESP或AH，或者使用HMAC转换进行身份验证来封装AH，可以抵御大多数攻击者的这种攻击。在这种情况下，将首先验证HMAC转换，并且只要攻击者不拥有HMAC密钥，就不会对攻击者数据包评估数字签名。但是，如果攻击者确实拥有HMAC密钥（例如，攻击者是使用SA的组的合法成员），则无法减轻DoS攻击。
An assigned number is required in the "IPSec Authentication Algorithm" name space in the Internet Security Association and Key Management Protocol (ISAKMP) registry [ISAKMP-REG]. The mnemonic should be "SIG-RSA".
Internet安全关联和密钥管理协议（ISAKMP）注册表[ISAKMP-REG]中的“IPSec身份验证算法”名称空间中需要指定的号码。助记符应该是“SIG-RSA”。
An assigned number is also required in the "IPSEC AH Transform Identifiers" name space in the ISAKMP registry. Its mnemonic should be "AH_RSA".
ISAKMP注册表中的“IPSEC AH转换标识符”名称空间中还需要指定的编号。它的助记符应该是“AH_RSA”。
A new "IPSEC Security Association Attribute" is required in the ISAKMP registry to pass the RSA modulus size. The attribute class should be called "Authentication Key Length", and it should be a Variable type.
ISAKMP注册表中需要新的“IPSEC安全关联属性”才能传递RSA模数大小。属性类应称为“身份验证密钥长度”，并且应为变量类型。
A second "IPSEC Security Association Attribute" is required in the ISAKMP registry to pass the RSA signature encoding type. The attribute class should be called "Signature Encoding Algorithm", and it should be a Basic type. The following rules apply to define the values of the attribute:
ISAKMP注册表中需要第二个“IPSEC安全关联属性”来传递RSA签名编码类型。属性类应称为“签名编码算法”，并且应为基本类型。以下规则适用于定义属性的值：
Name Value
---- -----
Reserved 0
RSASSA-PKCS1-v1_5 1
RSASSA-PSS 2
Name Value
---- -----
Reserved 0
RSASSA-PKCS1-v1_5 1
RSASSA-PSS 2
Values 3-61439 are reserved to IANA. New values MUST be added due to a Standards Action as defined in [RFC2434]. Values 61440-65535 are for private use and may be allocated by implementations for their own purposes.
值3-61439保留给IANA。由于[RFC2434]中定义的标准操作，必须添加新值。值61440-65535仅供私人使用，可由实现分配用于其自身目的。
Scott Fluhrer and David McGrew provided advice regarding applicable key sizes. Scott Fluhrer also provided advice regarding key lifetimes. Ian Jackson, Steve Kent, and Ran Canetti provided many helpful comments. Sam Hartman, Russ Housley, and Lakshminth Dondeti provided valuable guidance in the development of this document.
Scott Fluhrer和David McGrew提供了有关适用钥匙尺寸的建议。Scott Fluhrer还提供了有关关键生命周期的建议。伊恩·杰克逊、史蒂夫·肯特和兰·卡内蒂提供了许多有益的评论。Sam Hartman、Russ Housley和Lakshminth Dondeti为本文件的编制提供了宝贵的指导。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4303，2005年12月。
[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry
[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RSA] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standard (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RSA]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[SHA] FIPS PUB 180-2: Specifications for the Secure Hash Standard, August 2002. http://csrc.nist.gov/ publications/fips/fips180-2/fips180-2.pdf.
[SHA]FIPS PUB 180-2：安全哈希标准规范，2002年8月。http://csrc.nist.gov/ 出版物/fips/fips180-2/fips180-2.pdf。
[AES-GCM] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[AES-GCM]Viega，J.和D.McGrew，“在IPsec封装安全负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, December 2002.
[GDOI]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2002年12月。
[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[HMAC-SHA]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2]Kaufman，C.，“互联网密钥交换（IKEV2）协议”，RFC4306，2005年12月。
[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月。
[RSA-TR] B. Kaliski, "TWIRL and RSA Key Size", RSA Laboratories Technical Note, http://www.rsasecurity.com/rsalabs/ node.asp?id=2004, May 6, 2003.
[RSA-TR]B.Kaliski，“旋转和RSA密钥大小”，RSA实验室技术说明，http://www.rsasecurity.com/rsalabs/ node.asp？id=20042003年5月6日。
[SHA-COMMENTS] NIST Brief Comments on Recent Cryptanalytic Attacks on Secure Hashing Functions and the Continued Security Provided by SHA-1, August, 2004. http://csrc.nist.gov/hash_standards_comments.pdf.
[SHA-COMMENTS]NIST对最近针对安全哈希函数的密码分析攻击以及SHA-1提供的持续安全性的简要评论，2004年8月。http://csrc.nist.gov/hash_standards_comments.pdf.
[TWIRL] Shamir, A., and E. Tromer, "Factoring Large Numbers with the TwIRL Device", Work in Progress, February 9, 2003.
[TWIRL]Shamir，A.和E.Tromer，“用TWIRL设备分解大数”，正在进行的工作，2003年2月9日。
Author's Address
作者地址
Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706, USA
Brian Weis Cisco Systems美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134-1706
Phone: (408) 526-4796 EMail: bew@cisco.com
电话：（408）526-4796电子邮件：bew@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。