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.
カウンタモードは、このようなのAdvanced Encryption Standard（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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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]です。操作のいくつかの新しいAES暗号化モードは、ESPのために指定されています：カウンタモード（CTR）[RFC3686]、ガロア/カウンタモード（GCM）[RFC4106]、およびカウンター暗号ブロック連鎖、メッセージ認証コード（CBC-MAC）モード（とCCM）[RFC4309]。およびESPとAHの両方に指定されたもの：ガロア・メッセージ認証コード（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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 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.)
動作[FIPS.800-38A.2001]のカウンタモード（CTR）は、そのパフォーマンスと実装の利点の重要になってきています。これは、CCMおよびGCMなどの暗号化と認証を組み合わせたいくつかの動作モードのための基礎です。カウンタベースのモードの全ては、単一のキーは複数の暗号化エンジンによって共有されている場合、これらのエンジンはそのキーで使用されるすべての初期化ベクトル（IV）が区別されることを保証するために調整しなければならない、ことを要求します。つまり、各キーのために、何のIV値を複数回使用することはできません、です。 IVの使用状況に関するこの制限はESP CTR、ESP GCM、およびESP CCMに課されています。暗号化に関しては、IVはナンスです。 （CBCモード[RFC3602]は予測不可能であるIVを必要とすることに留意されたい。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は、ブロック暗号カウンタモードを使用して変換したアプリケーションは、2つの異なるデータペイロードを保護するために同じ鍵、IV、ソルト値を使用していなければならないという制約があります。他のモードと比較して、このセキュリティ条件にもかかわらず、ブロック暗号カウンタモード変換は、しばしば、それらの良好な性能特性のために好ましいです。
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.
ブロック暗号カウンタモードの各々は、インターネットキー交換バージョン2（IKEv2）[RFC5996]をキーとしているポイントツーポイントアプリケーションのための材料を合わせるの構成を指定する変換します。指定された構造は、セキュリティ条件は、単一の送信者によって破られていないことを保証します。 IPsecの[RFC5374]のグループアプリケーションは、カウンタモードは価値があることが変換を見つけることがあります。いくつかのグループアプリケーションがセキュリティ条件を満たしている送信者ごとのIPSec Security Association（SA）を、作成することができ、そしてそれ以上の仕様が必要とされません。しかし、IPsecは、単一のIPsec SAは、複数の送信元IPマルチキャストアプリケーションのメンバー間のネットワークトラフィックを保護するために使用される多対多用途[RFC3170]、として知られているグループ・アプリケーションを保護するために使用することができます。いくつかの多対多のアプリケーションは、各送信者のための個別の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.
このセクションでは、安全に、単一のIPsec SAを共有するために送信者のグループを可能にIVの特定の構造を指定します。この構造は、[RFC5116]の勧告に準拠しています。この方法の理論的根拠は、この仕様で定義され構成の付録Aで与えられ、各IVは、送信者固有のIV（SSIV）フィールドと送信元識別子（SID）フィールドを連結することによって形成されています。 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 !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 1. IV with an 8-bit SID
8ビットのSIDを有する図1 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.
各特定のセキュリティアソシエーションのために、そのSAで使用される各SIDが同じ長さを持たなければならないものの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.
グループアプリケーションは、1つまたは複数のグループコントローラおよびキーサーバ（GCKS）エンティティ[RFC3740]で構成されるグループキー管理システム（GKMS）を使用します。 GKMSは、IPsecが許可グループメンバーにポリシーおよび関連する鍵素材を変換配布しています。この文書は、GKMSがグループメンバに一意のSIDを割り当て、そのようなGDOI又はGSAKMPとしてGKMプロトコルを使用してグループメンバーに配布両方のことをお勧めします。 GKMSで使用される戦略は、相互運用性を実現するために義務付けされている必要はありません。 GKMS、グループのSIDを割り当てるための責任を負うものとします。 SIDを順次割り当てること限り割り当て方法このセクションの要件を次のように許容可能です。
The following requirements apply to a GKMS that manages SIDs. One example of such a GKMS is [GDOI-UPDATE].
次の要件は、SIDを管理しGKMSに適用されます。そのような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について、GKMSは、複数のアクティブグループメンバーに同じ送信元識別子を与えてはいけません。 GKMSは、グループのメンバーに関連付けられているSIDのように不確実であるならば、それは新しいもの割り当てる必要があります。 GKMS内の複数のエンティティが送信者識別子を配布されている場合、各エンティティにより配布識別子のセットが重複してはなりません。
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、GKMSは、新しいグループのメンバーが参加できるようにするために拒否しなければなりません。また、GKMSは、すべてのグループメンバーに交換用のESPまたはAHセキュリティアソシエーションを配布することができます。代替SAが分散されている場合、GKMSはまた、より多くの送信者を収容することができるように、より大きな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 GKMSは、各グループメンバーのための単一の送信元識別子を割り当て、そのメンバーが送信者であるすべてのグループSAの送信者に、この値を発行する必要があります。この戦略はSA毎にSIDを管理する避けるためにGKMSと送信者の両方を可能にします。 SIDは再入力イベント中に変更または交換用のSASと一緒に再発行する必要はありませんので、それはまた、鍵の再生成プロセスを簡素化します。
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.
GKMSは、特定のグループのメンバがもはやグループの一部であると判断しない場合には、O、それは新しいグループメンバで使用するための、そのグループのメンバーに関連付けられた任意の送信者識別子を再び割り当てることができます。この場合、GKMSは、最初の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は予測できませんIVを必要としません。
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上のデータトラフィックの送信を停止しなければなりません。 GKMSは、問題を解決するために（例えば、新しいSIDとグループのメンバーを提供するか、新しいSAを提供する）ためのグループメンバーが時間内にGKMSを通知しない場合に発生することができ、またはGKMSは、いくつかの通知を無視した場合理由。この場合、グループのメンバーがGCKSに再登録し、それがグループに参加し続ける必要があるのSAを受け取ることを期待すべきです。
This specification does not address virtual machine rollbacks that may cause the cryptographic device to re-use nonce values.
この仕様は、暗号装置は、ナンス値を再使用することがあり、仮想マシンのロールバックに対応していません。
Other security considerations applying to IPsec SAs with multiple senders are described in [RFC5374].
複数の送信者とのIPsec SAのに適用される他のセキュリティ問題は、[RFC5374]に記載されています。
The authors wish to thank David Black, Sheela Rowles, and Alfred Hoenes for their helpful comments and suggestions.
作者は彼らの役に立つコメントと提案のためのデビッド・ブラック、シーラRowles、とアルフレッドHoenesに感謝したいです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、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]ヴァイス、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]ハフマン、D.、 "最小冗長符号の構築のための方法"、IREの会報、巻：40号：9、ページ（複数可）について：1098から1101、ISSN：0096から8390まで、 1952年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]クイン、B.およびK. Almeroth、 "IPマルチキャストアプリケーション：課題と解決策"、RFC 3170、2001年9月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、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]フランケル、S.、グレン、R.、およびS.ケリー、 "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.、RFC 3686 "IPsecのカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンタモードの使用" を、2004年1月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T.とB.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、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.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "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.マグリュー、 "IPsecのカプセル化セキュリティペイロード（ESP）におけるガロア/カウンタモード（GCM）の使用"、RFC 4106、2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309] Housley氏、R.、RFC 4309、2005年12月 "IPsecのカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）CCMモードを使用しました"。
[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]ポポフ、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]はハーニー、H.、メタ、U.、Colegrove、A.、およびG.グロスは、：RFC 4535、2006年6月、 "GSAKMPグループは、協会の鍵管理プロトコルをセキュア"。
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
[RFC4543]マグリュー、D.とJ. Viega、 "IPsecのESPとAHでガロアメッセージ認証コード（GMAC）の使用"、RFC 4543、2006年5月。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
[RFC5116]マグリュー、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]ヴァイス、B.、グロス、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]加藤、A.、神田、M.、およびS.菅野、RFC 5528 "CBC-MACモードアルゴリズムとカメリアカウンタモードとツバキカウンタ" 2009年4月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、RFC 5996、2010年9月。
Appendix A. Rationale for the IV Formation for Counter Modes with Group Keys
グループキーとカウンターモード用IVの形成のための付録A.根拠
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.
マルチ送信者環境でのIVの一意性を確保するための2つの主な選択肢は各送信者を有することであるソルト値のいずれかまたはIVが入力として使用されることを明示的なIVフィールド（リコールにおける送信元識別子（SID）値を含みます暗号化アルゴリズムは、塩と明示的なIV）を連結することによって構築されます。それは、パケット中に明示的に存在するため、明示的IVフィールドは、SIDのための場所として選ばれました。 SIDは、塩に含まれていた場合、受信機は、そのパケットを送っていたその送信者を認識することによって、特定の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値は可変長プレフィックスフリーコードのコードワードであるように選択することが持っている許容されるであろう。 IVの明瞭が全くSIDが別の接頭辞ではないという事実から、以下のため、このアプローチは、セキュリティを保持します。従って、のIVの任意の対は別個であるビットのサブセットを有します。ハフマン符号[H52]はSIDを形成するために使用される場合、最適なSIDのセットは、SIDの数はSIDの長さの所定の分布のために最大にすることができるという意味で、見つけることができます。また、そのコードワードのオクテット文字列で効率的なプリフィックスのないコードを生成するための簡単な方法があります。それにもかかわらず、これらの方法は、一般性の上にシンプルさを有利にするために、禁止されました。
Appendix B. Example
付録B.例
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管理者は、グループはすべての送信者によって共有されている1つのSAを持っていることを決定します。 SAのためのアルゴリズムは、サイズ8ビットのSIDを使用して、AES-GCMです。
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 allocated SID 2, and begins sending packets with the following IVs: 0x0200000000000001, 0x0200000000000002, 0x0200000000000003, ... with a final value of 0x02FFFFFFFFFFFFFF.
、0x0100000000000001、0x0100000000000002、0x0100000000000003 ...の最終値と：GCKSと第一送信元レジスタが、それはSID 1に割り当てられている場合、送信者は、その後、AES-GCMは、（ネットワークバイト順に示されている）以下のIVを有するパケットを暗号化し送信します0x01FFFFFFFFFFFFFF。 GCKSに登録する第二の送信者は、SID 2に割り当てられ、そして以下のIVでのパケットの送信を開始します0x0200000000000001、0x0200000000000002、0x0200000000000003、... 0x02FFFFFFFFFFFFFFの最終的な値で。
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.
グループポリシーによると、GCKSは、後で交換SAのポリシーおよび鍵材料を配布することができます。グループの送信者が新しいSAで暗号化されたAES-GCMパケットの送信を開始すると、各送信者は、以前に割り当てられたSID値を使用し続けます。例えば、送信者はSID 2は、0x0200000000000001、0x0200000000000002、0x0200000000000003のIV値を使用して新しいSAに送信されるだろう... 0x02FFFFFFFFFFFFFFの最終値に割り当てられました。
Authors' Addresses
著者のアドレス
David A. McGrew Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA
デビッド・A.マグリューシスコシステムズ170 W.タスマン・ドライブサンノゼ、カリフォルニア95134-1706 USA
Phone: +1-408-525-8651 EMail: mcgrew@cisco.com
電話：+ 1-408-525-8651 Eメール：mcgrew@cisco.com
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA
ブライアン・ワイスシスコシステムズ170 W.タスマン・ドライブサンノゼ、カリフォルニア95134-1706 USA
Phone: +1-408-526-4796 EMail: bew@cisco.com
電話：+ 1-408-526-4796 Eメール：bew@cisco.com