Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 6054 B. Weis
Category: Standards Track Cisco Systems
ISSN: 2070-1721 November 2010
Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 6054 B. Weis
Category: Standards Track Cisco Systems
ISSN: 2070-1721 November 2010
Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic
使用带有封装安全有效负载（ESP）和身份验证头（AH）的计数器模式来保护组流量
Abstract
摘要
Counter modes have been defined for block ciphers such as the Advanced Encryption Standard (AES). Counter modes use a counter, which is typically assumed to be incremented by a single sender. This memo describes the use of counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications.
已为分组密码（如高级加密标准（AES））定义了计数器模式。计数器模式使用计数器，通常假定计数器由单个发送方递增。本备忘录描述了在多个发送方组应用程序中应用于封装安全有效负载（ESP）和身份验证头（AH）时计数器模式的使用。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6054.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6054.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Notation ......................................2
2. Problem Statement ...............................................2
3. IV Formation for Counter Modes with Group Keys ..................3
4. Group Key Management Conventions ................................4
5. Security Considerations .........................................5
6. Acknowledgements ................................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
Appendix A. Rationale for the IV Formation for Counter Modes
with Group Keys ........................................9
Appendix B. Example ................................................9
1. Introduction ....................................................2
1.1. Requirements Notation ......................................2
2. Problem Statement ...............................................2
3. IV Formation for Counter Modes with Group Keys ..................3
4. Group Key Management Conventions ................................4
5. Security Considerations .........................................5
6. Acknowledgements ................................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
Appendix A. Rationale for the IV Formation for Counter Modes
with Group Keys ........................................9
Appendix B. Example ................................................9
The IP Encapsulating Security Payload (ESP) specification [RFC4303] and Authentication Header (AH) [RFC4302] are security protocols for IPsec [RFC4301]. Several new AES encryption modes of operation have been specified for ESP: Counter Mode (CTR) [RFC3686], Galois/Counter Mode (GCM) [RFC4106], and Counter with Cipher Block Chaining-Message Authentication Code (CBC-MAC) Mode (CCM) [RFC4309]; and one that has been specified for both ESP and AH: the Galois Message Authentication Code (GMAC) [RFC4543]. A Camellia counter mode [RFC5528] and a GOST counter mode [RFC4357] have also been specified. These new modes offer advantages over traditional modes of operation. However, they all have restrictions on their use in situations in which multiple senders are protecting traffic using the same key. This document addresses this restriction and describes how these modes can be used with group key management protocols such as the Group Domain of Interpretation (GDOI) protocol [RFC3547] and the Group Secure Association Key Management Protocol (GSAKMP) [RFC4535].
IP封装安全有效负载（ESP）规范[RFC4303]和身份验证头（AH）[RFC4302]是IPsec[RFC4301]的安全协议。为ESP指定了几种新的AES加密操作模式：计数器模式（CTR）[RFC3686]、Galois/计数器模式（GCM）[RFC4106]和带密码块链接消息认证码（CBC-MAC）的计数器模式（CCM）[RFC4309]；还有一个是为ESP和AH指定的：Galois消息认证码（GMAC）[RFC4543]。还指定了茶花计数器模式[RFC5528]和GOST计数器模式[RFC4357]。这些新模式比传统的运营模式具有优势。但是，在多个发送方使用同一密钥保护通信量的情况下，它们的使用都有限制。本文档阐述了这一限制，并描述了如何将这些模式用于组密钥管理协议，如组解释域（GDOI）协议[RFC3547]和组安全关联密钥管理协议（GSAKMP）[RFC4535]。
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 Counter Mode (CTR) of operation [FIPS.800-38A.2001] has become important because of its performance and implementation advantages. It is the basis for several modes of operation that combine authentication with encryption, including CCM and GCM. All of the counter-based modes require that, if a single key is shared by
由于其性能和实施优势，操作的计数器模式（CTR）[FIPS.800-38A.2001]变得非常重要。它是将身份验证与加密相结合的几种操作模式的基础，包括CCM和GCM。所有基于计数器的模式都要求
multiple encryption engines, those engines must coordinate to ensure that every Initialization Vector (IV) used with that key is distinct. That is, for each key, no IV value can be used more than once. This restriction on IV usage is imposed on ESP CTR, ESP GCM, and ESP CCM. In cryptographic terms, the IV is a nonce. (Note that CBC mode [RFC3602] requires IVs that are unpredictable. CTR, GCM, GMAC, and CCM do not have this restriction.)
多个加密引擎，这些引擎必须协调以确保与该密钥一起使用的每个初始化向量（IV）都是不同的。也就是说，对于每个键，任何IV值都不能被多次使用。此IV使用限制适用于ESP CTR、ESP GCM和ESP CCM。在密码术语中，IV是一个nonce。（注意CBC模式[RFC3602]需要不可预测的IVs。CTR、GCM、GMAC和CCM没有此限制。）
All ESP and AH transforms using a block cipher counter mode have a restriction that an application must not use the same key, IV, and Salt values to protect two different data payloads. Notwithstanding this security condition, block cipher counter mode transforms are often preferred because of their favorable performance characteristics as compared to other modes.
所有使用分组密码计数器模式的ESP和AH转换都有一个限制，即应用程序不得使用相同的密钥、IV和Salt值来保护两个不同的数据有效负载。尽管存在这种安全条件，分组密码计数器模式转换通常是首选的，因为与其他模式相比，它们具有良好的性能特征。
Each of the block cipher counter mode transforms specify the construction of keying material for point-to-point applications that are keyed by the Internet Key Exchange version 2 (IKEv2) [RFC5996]. The specified constructions guarantee that the security condition is not violated by a single sender. Group applications of IPsec [RFC5374] may also find counter mode transforms to be valuable. Some group applications can create an IPsec Security Association (SA) per sender, which meets the security condition, and no further specification is required. However, IPsec can be used to protect group applications known as Many-to-Many Applications [RFC3170], where a single IPsec SA is used to protect network traffic between members of a multiple-sender IP multicast application. Some Many-to-Many Applications are comprised of a large number of senders, in which case defining an individual IPsec SA for each sender is unmanageable.
每个分组密码计数器模式转换都指定由Internet密钥交换版本2（IKEv2）[RFC5996]设置密钥的点到点应用程序的密钥材料的构造。指定的构造保证单个发送方不会违反安全条件。IPsec[RFC5374]的组应用程序也可能发现计数器模式转换很有价值。某些组应用程序可以为每个发送方创建符合安全条件的IPsec安全关联（SA），无需进一步的规范。但是，IPsec可用于保护称为多对多应用程序[RFC3170]的组应用程序，其中单个IPsec SA用于保护多发送方IP多播应用程序成员之间的网络流量。一些多对多应用程序由大量发送方组成，在这种情况下，为每个发送方定义单独的IPsec SA是不可管理的。
This section specifies a particular construction of the IV that enables a group of senders to safely share a single IPsec SA. This construction conforms to the recommendations of [RFC5116]. A rationale for this method is given in Appendix A. In the construction defined by this specification, each IV is formed by concatenating a Sender Identifier (SID) field with a Sender-Specific IV (SSIV) field. The value of the SID MUST be unique for each sender, across all of the senders sharing a particular Security Association. The value of the SSIV field MUST be unique for each IV constructed by a particular sender for use with a particular SA. The SSIV MAY be chosen in any manner convenient to the sender, e.g., successive values of a counter. The leftmost bits of the IV contain the SID, and the remaining bits contain the SSIV. By way of example, Figure 1 shows the correct placement of an 8-bit SID within an Initialization Vector.
本节指定IV的特定构造，该构造使一组发送方能够安全地共享单个IPsec SA。该结构符合[RFC5116]的建议。附录A中给出了该方法的基本原理。在本规范定义的结构中，每个IV通过将发送方标识符（SID）字段与发送方特定IV（SSIV）字段连接而形成。在共享特定安全关联的所有发件人中，每个发件人的SID值必须是唯一的。SSIV字段的值对于由特定发送方构造用于特定SA的每个IV必须是唯一的。SSIV可以以发送方方便的任何方式选择，例如计数器的连续值。IV最左边的位包含SID，其余的位包含SSIV。作为示例，图1显示了8位SID在初始化向量中的正确位置。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SID ! !
+-+-+-+-+-+-+-+-+ SSIV !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SID ! !
+-+-+-+-+-+-+-+-+ SSIV !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 1. IV with an 8-bit SID
图1。具有8位SID的IV
The number of bits used by the SID may vary depending on group policy, though for each particular Security Association, each SID used with that SA MUST have the same length. To facilitate interoperability, a conforming implementation MUST support SID lengths of 8, 12, and 16 bits. It should be noted that the size of the SID associated with an SA provides a trade-off between the number of possible senders and the number of packets that each sending station is able to send using that SA.
SID使用的位数可能因组策略而异，但对于每个特定的安全关联，与该SA一起使用的每个SID必须具有相同的长度。为了促进互操作性，一致性实现必须支持8、12和16位的SID长度。应当注意，与SA相关联的SID的大小提供了可能发送者的数量和每个发送站能够使用该SA发送的分组的数量之间的折衷。
Group applications use a Group Key Management System (GKMS) composed of one or more Group Controller and Key Server (GCKS) entities [RFC3740]. The GKMS distributes IPsec transform policy and associated keying material to authorized group members. This document RECOMMENDS that the GKMS both allocate unique SIDs to group members and distribute them to group members using a GKM protocol such as GDOI or GSAKMP. The strategy used by the GKMS does not need to be mandated in order to achieve interoperability; the GKMS is solely responsible for allocating SIDs for the group. Allocating SIDs sequentially is acceptable as long as the allocation method follows the requirements in this section.
组应用程序使用由一个或多个组控制器和密钥服务器（GCKS）实体组成的组密钥管理系统（GKM）[RFC3740]。GKM将IPsec转换策略和相关的密钥材料分发给授权的组成员。本文件建议GKM向集团成员分配唯一的小岛屿发展中国家，并使用GKM协议（如GDOI或GSAKMP）将其分发给集团成员。为了实现互操作性，无需强制执行GKM使用的策略；GKMS全权负责为集团分配小岛屿发展中国家。只要分配方法符合本节的要求，就可以按顺序分配小岛屿发展中国家。
The following requirements apply to a GKMS that manages SIDs. One example of such a GKMS is [GDOI-UPDATE].
以下要求适用于管理小岛屿发展中国家的全球知识管理系统。这种GKMS的一个例子是[GDOI-UPDATE]。
o For each SA for which sender identifiers are used, the GKMS MUST NOT give the same sender identifier to more than one active group member. If the GKMS is uncertain as to the SID associated with a group member, it MUST allocate it a new one. If more than one entity within the GKMS is distributing sender identifiers, then the sets of identifiers distributed by each entity MUST NOT overlap.
o 对于使用发送方标识符的每个SA，GKM不得向多个活动组成员提供相同的发送方标识符。如果GKM不确定与组成员关联的SID，则必须为其分配一个新的SID。如果GKM中有多个实体分发发送方标识符，则每个实体分发的标识符集不得重叠。
o If the entire set of sender identifiers has been exhausted, the GKMS MUST refuse to allow new group members to join. Alternatively, the GKMS could distribute replacement ESP or AH Security Associations to all group members. When replacement SAs are distributed, the GKMS could also distribute larger SID values so that more senders can be accommodated.
o 如果完整的发送方标识符集已用完，则GKM必须拒绝允许新的组成员加入。或者，GKM可以将替代ESP或AH安全协会分发给所有集团成员。在分发替换SA时，GKM还可以分发更大的SID值，以便容纳更多的发送者。
o The GKMS SHOULD allocate a single sender identifier for each group member, and issue this value to the sender for all group SAs for which that member is a sender. This strategy enables both the GKMS and the senders to avoid managing SIDs on a per-SA basis. It also simplifies the rekeying process, since SIDs do not need to be changed or re-issued along with replacement SAs during a rekey event.
o GKM应为每个组成员分配一个发送者标识符，并为该成员作为发送者的所有组SA向发送者发出该值。这一战略使全球知识管理系统和发送方都能够避免按SA管理小岛屿发展中国家。它还简化了密钥更新过程，因为在密钥更新事件期间，不需要更改或重新发布SID以及替换SA。
o When a GKMS determines that a particular group member is no longer a part of the group, then it MAY re-allocate any sender identifier associated with that group member for use with a new group member. In this case, the GKMS MUST first delete and replace any active AH or ESP SAs with which the SID may have been used. This is necessary to avoid re-use of an IV with the cipher key associated with the SA.
o 当GKM确定某个特定的组成员不再是该组的一部分时，它可以重新分配与该组成员相关联的任何发送方标识符，以便与新的组成员一起使用。在这种情况下，GKM必须首先删除并替换可能使用SID的任何活动AH或ESP SA。这对于避免重复使用具有与SA相关联的密钥的IV是必要的。
This specification provides a method for securely using cryptographic algorithms that require a unique IV, such as a block cipher mode of operation based on counter mode, in a scenario in which there are multiple cryptographic devices that each generate IVs. This is done by partitioning the set of possible IV values such that each cryptographic device has exclusive use of a set of IV values. When the recommendations in this specification are followed, the security of the cryptographic algorithms is equivalent to the conventional case in which there is a single sender. Unlike CBC mode, CTR, GCM, GMAC, and CCM do not require IVs that are unpredictable.
本规范提供了一种方法，用于在有多个加密设备各自生成IV的情况下，安全地使用需要唯一IV的加密算法，例如基于计数器模式的分组密码操作模式。这是通过对一组可能的IV值进行分区来实现的，这样每个加密设备都独占使用一组IV值。当遵循本规范中的建议时，加密算法的安全性等同于存在单个发送方的常规情况。与CBC模式不同，CTR、GCM、GMAC和CCM不需要不可预测的IVs。
The security of a group depends upon the correct operation of the group members. Any group member using an SID not allocated to it may reduce the security of the system.
组的安全性取决于组成员的正确操作。任何使用未分配给它的SID的组成员都可能会降低系统的安全性。
As is the case with a single sender, a cryptographic device storing keying material over a reboot is responsible for storing a counter value such that upon resumption it never re-uses counters. In the context of this specification, the cryptographic device would need to store both SID and SSIV values used with a particular IPsec SA in addition to policy associated with the IPsec SA.
与单个发送方的情况一样，在重新启动时存储密钥材料的加密设备负责存储计数器值，以便在恢复时不再重复使用计数器。在本规范的上下文中，除了与IPsec SA相关联的策略外，加密设备还需要存储与特定IPsec SA一起使用的SID和SSIV值。
A group member that reaches the end of its IV space MUST stop sending data traffic on that SA. This can happen if the group member does not notify the GKMS in time for the GKMS to remedy the problem (e.g., to provide the group member with a new SID or to provide a new SA), or if the GKMS ignores the notification for some reason. In this case, the group member should re-register with the GCKS and expect to receive the SAs that it needs to continue participating in the group.
到达其IV空间末端的组成员必须停止在该SA上发送数据流量。如果集团成员未及时通知GKM，以便GKM纠正问题（例如，向集团成员提供新SID或提供新SA），或者GKM出于某种原因忽略通知，则可能发生这种情况。在这种情况下，集团成员应向GCK重新注册，并期望收到其继续参与集团所需的SA。
This specification does not address virtual machine rollbacks that may cause the cryptographic device to re-use nonce values.
此规范不解决可能导致加密设备重新使用nonce值的虚拟机回滚问题。
Other security considerations applying to IPsec SAs with multiple senders are described in [RFC5374].
[RFC5374]中描述了应用于具有多个发送方的IPsec SAs的其他安全注意事项。
The authors wish to thank David Black, Sheela Rowles, and Alfred Hoenes for their helpful comments and suggestions.
作者希望感谢David Black、Sheela Rowles和Alfred Hoenes的有益评论和建议。
[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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[FIPS.800-38A.2001] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation", Special Publication FIPS PUB 800-38A, December 2001, <http://csrc.nist.gov/publications/>.
[FIPS.800-38A.2001]国家标准与技术研究所，“分组密码操作模式建议”，特别出版物FIPS PUB 800-38A，2001年12月<http://csrc.nist.gov/publications/>.
[GDOI-UPDATE] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", Work in Progress, October 2010.
[GDOI-UPDATE]Weis，B.，Rowles，S.，和T.Hardjono，“口译的集团领域”，正在进行的工作，2010年10月。
[H52] Huffman, D., "A Method for the Construction of Minimum-Redundancy Codes", Proceedings of the IRE, Volume:40, Issue:9, On page(s): 1098-1101, ISSN: 0096-8390, September 1952, <http://ieeexplore.ieee.org/xpl/ freeabs_all.jsp?arnumber=4051119>.
[H52]Huffman，D.，“构造最小冗余码的方法”，《IRE学报》，第40卷，第9期，第1098-1101页，ISSN:0096-83901952年9月<http://ieeexplore.ieee.org/xpl/ freeabs_all.jsp？arnumber=4051119>。
[RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: Challenges and Solutions", RFC 3170, September 2001.
[RFC3170]Quinn，B.和K.Almeroth，“IP多播应用：挑战和解决方案”，RFC 31702001年9月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效负载（ESP）”，RFC 3686，2004年1月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740]Hardjono，T.和B.Weis，“多播组安全架构”，RFC 3740，2004年3月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309]Housley，R.，“使用高级加密标准（AES）CCM模式和IPsec封装安全有效载荷（ESP）”，RFC 4309，2005年12月。
[RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms", RFC 4357, January 2006.
[RFC4357]Popov，V.，Kurepkin，I.，和S.Leontiev，“用于GOST 28147-89，GOST R 34.10-94，GOST R 34.10-2001和GOST R 34.11-94算法的其他加密算法”，RFC 4357，2006年1月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]Harney，H.，Meth，U.，Colegrove，A.，和G.Gross，“GSAKMP：组安全关联密钥管理协议”，RFC 45352006年6月。
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
[RFC4543]McGrew，D.和J.Viega，“Galois消息认证码（GMAC）在IPsec ESP和AH中的使用”，RFC 4543，2006年5月。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，2008年1月。
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
[RFC5374]Weis，B.，Gross，G.和D.Ignjatic，“互联网协议安全架构的多播扩展”，RFC 5374，2008年11月。
[RFC5528] Kato, A., Kanda, M., and S. Kanno, "Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms", RFC 5528, April 2009.
[RFC5528]Kato，A.，Kanda，M.，和S.Kanno，“茶花计数器模式和具有CBC-MAC模式算法的茶花计数器”，RFC 55282009年4月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
Appendix A. Rationale for the IV Formation for Counter Modes with Group Keys
附录A.带组键的计数器模式IV形成的基本原理
The two main alternatives for ensuring the uniqueness of IVs in a multi-sender environment are to have each sender include a Sender Identifier (SID) value in either the Salt value or in the explicit IV field (recall that the IV used as input to the crypto algorithm is constructed by concatenating the Salt and the explicit IV). The explicit IV field was chosen as the location for the SID because it is explicitly present in the packet. If the SID had been included in the Salt, then a receiver would need to infer the SID value for a particular AH or ESP packet by recognizing which sender had sent that packet. This inference could be made on the IP source address, if AH or ESP is transported directly over IP. However, if an alternate transport mechanism such as UDP is being used [RFC3948] (e.g., for NAT traversal), the method used to infer the sender would need to take that mechanism into account. It is simpler to use the explicit IV field, and thus avoid the need to infer the sender from the packet at all.
在多发送方环境中，确保IVs唯一性的两个主要备选方案是让每个发送方在Salt值或显式IV字段中包含发送方标识符（SID）值（回想一下，用作加密算法输入的IV是通过连接Salt和显式IV构建的）。选择显式IV字段作为SID的位置，因为它显式存在于数据包中。如果SID包含在Salt中，那么接收方需要通过识别发送该数据包的发送方来推断特定AH或ESP数据包的SID值。如果AH或ESP直接通过IP传输，则可以对IP源地址进行此推断。但是，如果正在使用UDP等替代传输机制[RFC3948]（例如，用于NAT遍历），则用于推断发送方的方法将需要考虑该机制。使用显式IV字段更简单，因此根本不需要从数据包推断发送者。
The normative requirement that all of the SID values used with a particular Security Association must have the same length is not strictly necessary, but was added to promote simplicity of implementation. Alternatively, it would be acceptable to have the SID values be chosen to be the codewords of a variable-length prefix-free code. This approach preserves security since the distinctness of the IVs follows from the fact that no SID is a prefix of another; thus, any pair of IVs has a subset of bits that are distinct. If a Huffman code [H52] is used to form the SIDs, then a set of optimal SIDs can be found, in the sense that the number of SIDs can be maximized for a given distribution of SID lengths. Additionally, there are simple methods for generating efficient prefix-free codes whose codewords are octet strings. Nevertheless, these methods were disallowed in order to favor simplicity over generality.
严格来说，与特定安全关联一起使用的所有SID值必须具有相同长度的规范性要求不是必需的，而是为了简化实现而添加的。或者，可以将SID值选择为可变长度前缀自由码的码字。这种方法保持了安全性，因为没有SID是另一个SID的前缀这一事实导致了IVs的独特性；因此，任何一对IV都有一个不同的比特子集。如果使用哈夫曼代码[H52]形成SID，则可以找到一组最佳SID，即给定SID长度分布下的SID数量可以最大化。此外，还有一些简单的方法可以生成有效的无前缀代码，其码字是八位字符串。然而，这些方法是不允许的，以利于简单而不是一般性。
This section provides an example of SID allocation and IV generation, as defined in this document. A GCKS administrator determines that the group has one SA that is shared by all senders. The algorithm for the SA is AES-GCM using an SID of size 8 bits.
本节提供了本文档中定义的SID分配和IV生成示例。GCKS管理员确定该组有一个由所有发件人共享的SA。SA的算法是AES-GCM，使用大小为8位的SID。
When the first sender registers with the GCKS, it is allocated SID 1. The sender subsequently sends AES-GCM encrypted packets with the following IVs (shown in network byte order): 0x0100000000000001, 0x0100000000000002, 0x0100000000000003, ... with a final value of 0x01FFFFFFFFFFFFFF. The second sender registering with the GCKS is
当第一个发送方向GCKS注册时，它被分配SID 1。发送方随后发送带有以下IVs的AES-GCM加密数据包（以网络字节顺序显示）：0x0100000000000001、0x0100000002、0x0100000003、。。。最终值为0x01FFFFFFFFFFFF。向GCKS注册的第二个发件人是
allocated SID 2, and begins sending packets with the following IVs: 0x0200000000000001, 0x0200000000000002, 0x0200000000000003, ... with a final value of 0x02FFFFFFFFFFFFFF.
已分配SID 2，并开始发送具有以下IVs的数据包：0x02000000000000001、0x02000000000000002、0x02000000000000003。。。最终值为0x02FFFFFFFFFF。
According to group policy, the GCKS may later distribute policy and keying material for a replacement SA. When group senders begin sending AES-GCM packets encrypted with the new SA, each sender continues to use the SID value previously allocated to it. For example, the sender allocated SID 2 would be sending on a new SA with IV values of 0x0200000000000001, 0x0200000000000002, 0x0200000000000003, ... with a final value of 0x02FFFFFFFFFFFFFF.
根据集团政策，GCK可能会在以后分发替换SA的政策和密钥材料。当组发送方开始发送使用新SA加密的AES-GCM数据包时，每个发送方继续使用以前分配给它的SID值。例如，发送方分配的SID 2将在IV值为0x02000000000000001、0x02000000000000002、0x02000000003的新SA上发送。。。最终值为0x02FFFFFFFFFF。
Authors' Addresses
作者地址
David A. McGrew Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA
美国加利福尼亚州圣何塞塔斯曼大道170 W.David A.McGrew思科系统公司95134-1706
Phone: +1-408-525-8651
EMail: mcgrew@cisco.com
Phone: +1-408-525-8651
EMail: mcgrew@cisco.com
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA
Brian Weis Cisco Systems美国加利福尼亚州圣何塞塔斯曼大道西170号95134-1706
Phone: +1-408-526-4796
EMail: bew@cisco.com
Phone: +1-408-526-4796
EMail: bew@cisco.com