[要約] RFC 6054は、グループトラフィックを保護するために、ESPとAHというカウンターモードを使用する方法について説明しています。このRFCの目的は、グループ通信のセキュリティを向上させるためのガイドラインを提供することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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].
セキュリティペイロード（ESP）仕様[RFC4303]および認証ヘッダー（AH）[RFC4302]をカプセル化するIPは、IPSEC [RFC4301]のセキュリティプロトコルです。ESP：カウンターモード（CTR）[RFC3686]、ガロア/カウンターモード（GCM）[RFC4106]、および暗号ブロックチェーンチェーンチェーンメス認証コード（CBC-MAC）モード（CBC-MAC）モード（CBC-MAC）モード（CBC-MAC）モードにいくつかの新しいAES暗号化モードが指定されています。CCM）[RFC4309];ESPとAHの両方に指定されているもの：Galoisメッセージ認証コード（GMAC）[RFC4543]。Camelliaカウンターモード[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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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変換には、アプリケーションが同じキー、IV、および塩値を使用して2つの異なるデータペイロードを保護してはならないという制限があります。このセキュリティ条件にもかかわらず、他のモードと比較して好ましいパフォーマンス特性のために、ブロック暗号カウンターモード変換が好まれることがよくあります。
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セキュリティアソシエーション（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.
このセクションでは、送信者のグループが単一のIPSEC SAを安全に共有できるようにするIVの特定の構造を指定します。この構造は、[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 !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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が使用するビットの数は、グループポリシーによって異なる場合がありますが、特定のセキュリティ協会ごとに使用される各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変換ポリシーと関連するキーイング資料を認定グループメンバーに配布します。このドキュメントでは、GKMがグループメンバーに一意のSIDを割り当て、GDOIやGSAKMPなどのGKMプロトコルを使用してグループメンバーに配布することを推奨しています。GKMSが使用する戦略は、相互運用性を達成するために義務付けられる必要はありません。GKMSは、グループにSIDを割り当てることに責任を負います。SIDSの割り当ては、このセクションの要件に従う限り、順次容認できます。
The following requirements apply to a GKMS that manages SIDs. One example of such a GKMS is [GDOI-UPDATE].
以下の要件は、SIDSを管理するGKMSに適用されます。このようなGKMSの1つの例は[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セキュリティ関連を配布することができます。交換用SASが分布すると、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の送信者にこの値を発行する必要があります。この戦略により、GKMSと送信者の両方がSAごとにSIDの管理を避けることができます。また、Rekeyイベント中に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.
o GKMSが特定のグループメンバーがグループの一部ではなくなったと判断すると、新しいグループメンバーで使用するためにそのグループメンバーに関連付けられた送信者識別子を再割り当てすることがあります。この場合、GKMSはまず、SIDが使用されている可能性のあるアクティブなAHまたはESP SASを削除および交換する必要があります。これは、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に割り当てられていない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に問題を改善するためにGKMSに間に合わない場合（たとえば、グループメンバーに新しいSIDを提供したり、新しいSAを提供するために）、またはGKMSが一部の通知を無視している場合に発生する可能性があります。理由。この場合、グループメンバーはGCKSに再登録し、グループへの参加を継続する必要があるSASを受け取ることを期待する必要があります。
This specification does not address virtual machine rollbacks that may cause the cryptographic device to re-use nonce values.
この仕様では、暗号化デバイスが非CE値を再利用する可能性のある仮想マシンロールバックに対応していません。
Other security considerations applying to IPsec SAs with multiple senders are described in [RFC5374].
複数の送信者を備えたIPSEC SASに適用されるその他のセキュリティ上の考慮事項は、[RFC5374]で説明されています。
The authors wish to thank David Black, Sheela Rowles, and Alfred Hoenes for their helpful comments and suggestions.
著者は、デイビッド・ブラック、シーラ・ロウルズ、アルフレッド・ホーネスの有益なコメントと提案に感謝したいと考えています。
[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認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（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、Issue：9、Page（s）：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] Quinn、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.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、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。、「Advanced Encryption Standard（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、「The Multicast Group Security Architecture」、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）でのガロア/カウンターモード（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 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。、「Advanced Encryption Standard（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：Group Secure Association Key Management Protocol」、RFC 4535、2006年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、「IPSEC ESPおよびAHでのGaloisメッセージ認証コード（GMAC）の使用」、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、「Camellia Counter Mode and Camellia Counter with CBC-Mac Modeアルゴリズム」、RFC 5528、2009年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、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年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.
マルチセンダー環境でのIVの独自性を確保するための2つの主な選択肢は、各送信者に塩値または明示的なIVフィールドに送信者識別子（SID）値を含めることです（IVがIVが入力として入力として使用されたことを思い出してください暗号アルゴリズムは、塩と明示的な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の明確さが他のものの接頭辞であるという事実から続くため、セキュリティを保持します。したがって、IVSのペアには、異なるビットのサブセットがあります。Huffmanコード[H52]を使用してSIDSを形成する場合、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が1つあると判断します。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.
最初の送信者がGCKSで登録すると、SID 1が割り当てられます。その後、送信者は次のIVを使用してAES-GCM暗号化されたパケットを送信します（ネットワークバイト順序で表示）：0x0100000000000002、0x01000000000000000000000000000000000000000000000000000000000000030x01ffffffffffffff。GCKSに登録する2番目の送信者はSID 2を割り当てられ、次のIVでパケットの送信を開始します：0x020000000000000001、0x020000000000000002、0x0200000000000000000000000003、... 0x02fffffffffffffffffの最終値。
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が割り当てられた送信者は、IV値が0x0200000000000000000000000000000000000000002、0x0200000000000003、0x02ffffffffffffffffの新しいSAを送信します。
Authors' Addresses
著者のアドレス
David A. McGrew Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA
David A. McGrew Cisco Systems 170 W. Tasman Drive San Jose、California 95134-1706 USA
Phone: +1-408-525-8651
EMail: 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