[要約] RFC 8263は、GDOI GROUPKEY-PUSH Acknowledgement Messageの仕様を定義しています。この仕様の目的は、GDOIグループキープッシュメッセージの確認応答を提供することです。
Internet Engineering Task Force (IETF) B. Weis
Request for Comments: 8263 Cisco Systems
Category: Standards Track U. Mangla
ISSN: 2070-1721 Juniper Networks Inc.
T. Karl
Deutsche Telekom
N. Maheshwari
November 2017
Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message
Group Domain of Interpretation（GDOI）GROUPKEY-PUSH確認メッセージ
Abstract
概要
The Group Domain of Interpretation (GDOI) includes the ability of a Group Controller/Key Server (GCKS) to provide a set of current Group Member (GM) devices with additional security associations (e.g., to rekey expiring security associations). This memo adds the ability of a GCKS to request that the GM devices return an acknowledgement of receipt of its rekey message and specifies the acknowledgement method.
Group Domain of Interpretation（GDOI）には、Group Controller / Key Server（GCKS）の機能が含まれており、現在のグループメンバー（GM）デバイスのセットに追加のセキュリティアソシエーションを提供します（たとえば、期限切れになるセキュリティアソシエーションのキーを再生成するなど）。このメモは、GMデバイスがそのキー再生成メッセージの受信の確認を返すことを要求するGCKSの機能を追加し、確認方法を指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8263.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8263で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Acronyms and Abbreviations .................................4
2. Acknowledgement Message Request .................................5
2.1. REKEY_ACK_KEK_SHA256 Type ..................................5
2.2. REKEY_ACK_LKH_SHA256 Type ..................................6
2.3. REKEY_ACK_KEK_SHA512 Type ..................................6
2.4. REKEY_ACK_LKH_SHA512 Type ..................................6
3. GROUPKEY-PUSH Acknowledgement Message ...........................6
3.1. HDR ........................................................7
3.2. HASH .......................................................8
3.3. SEQ ........................................................9
3.4. ID .........................................................9
4. Group Member Operations .........................................9
5. GCKS Operations ................................................10
6. Management Considerations ......................................10
7. Security Considerations ........................................12
7.1. Protection of the GROUPKEY-PUSH ACK .......................12
7.2. Transmitting a GROUPKEY-PUSH ACK ..........................13
7.3. Receiving a GROUPKEY-PUSH ACK .............................13
8. IANA Considerations ............................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................16
Acknowledgements ..................................................17
Authors' Addresses ................................................17
The Group Domain of Interpretation (GDOI) [RFC6407] is a group key management method by which a Group Controller/Key Server (GCKS) distributes security associations (i.e., cryptographic policy and keying material) to a set of Group Member (GM) devices. The GDOI meets the requirements set forth in [RFC4046] ("Multicast Security (MSEC) Group Key Management Architecture"), including a Registration Protocol and a Rekey Protocol. The GDOI describes the Rekey Protocol as a GROUPKEY-PUSH message.
Group Domain of Interpretation（GDOI）[RFC6407]は、グループコントローラー/キーサーバー（GCKS）がセキュリティアソシエーション（つまり、暗号化ポリシーとキー情報）をグループメンバー（GM）デバイスのセットに配布するグループキー管理方法です。 。 GDOIは、[RFC4046]（「マルチキャストセキュリティ（MSEC）グループキー管理アーキテクチャ」）に記載されている要件（登録プロトコルと再生成プロトコルを含む）を満たしています。 GDOIは、キー再生成プロトコルをGROUPKEY-PUSHメッセージとして記述します。
A GDOI GCKS uses a GROUPKEY-PUSH message (Section 4 of [RFC6407]) to alert GMs to updates in policy for the group, including new policy and keying material, replacement policy and keying material, and indications of deleted policy and keying material. Usually, the GCKS does not require a notification that the GM actually received the policy. However, in some cases it is beneficial for a GCKS to be told by each receiving GM that it received the rekey message and, by implication, has reacted to the policy contained within. For example, a GCKS policy can use the acknowledgements to determine which GMs are receiving the current group policy and which GMs are no longer participating in the group.
GDOI GCKSはGROUPKEY-PUSHメッセージ（[RFC6407]のセクション4）を使用して、新しいポリシーとキー情報、置換ポリシーとキー情報、削除されたポリシーとキー情報の表示など、グループのポリシーの更新をGMに警告します。通常、GCKSは、GMが実際にポリシーを受信したという通知を必要としません。ただし、場合によっては、各受信GMがrekeyメッセージを受信し、暗黙のうちにその中に含まれるポリシーに反応したことをGCKSに通知することが有益です。たとえば、GCKSポリシーは確認応答を使用して、現在のグループポリシーを受信しているGMと、グループに参加していないGMを特定できます。
This memo introduces a method by which a GM returns an Acknowledgement Message to the GCKS. Initially, a GCKS requests that a GM acknowledge GROUPKEY-PUSH messages as part of a distributed group policy. Then, as shown in Figure 1, when the GCKS delivers a GROUPKEY-PUSH message, each GM that honors the GCKS request returns a GROUPKEY-PUSH Acknowledgement Message. The rest of this memo describes this method in detail.
このメモは、GMが承認メッセージをGCKSに返す方法を紹介しています。最初に、GCKSは、GMが分散グループポリシーの一部としてGROUPKEY-PUSHメッセージを確認することを要求します。次に、図1に示すように、GCKSがGROUPKEY-PUSHメッセージを配信すると、GCKS要求を受け入れる各GMがGROUPKEY-PUSH確認メッセージを返します。このメモの残りの部分では、この方法について詳しく説明しています。
GCKS GM1 GM2
| | |
| +---------->| |
| GROUPKEY-PUSH | | |
|-----------------+ | |
| | | |
| +-------------------->|
| | |
|<----------------------------| |
| GROUPKEY-PUSH ACK | |
| | |
|<--------------------------------------|
| GROUPKEY-PUSH ACK | |
Figure 1: GROUPKEY-PUSH Rekey Event
図1：GROUPKEY-PUSHキー再生成イベント
Implementation of the GROUPKEY-PUSH Acknowledgement Message is OPTIONAL.
GROUPKEY-PUSH確認応答メッセージの実装はオプションです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following acronyms and abbreviations are used throughout this document.
このドキュメントでは、次の頭字語と略語を使用しています。
ACK Acknowledgement Message
ACK確認メッセージ
D Delete
D削除
GCKS Group Controller/Key Server
GCKSグループコントローラー/キーサーバー
GDOI Group Domain of Interpretation
GDOIグループの解釈のドメイン
GM Group Member
GMグループメンバー
HDR Header
HDRヘッダー
HMAC Hashed Message Authentication Code
HMACハッシュメッセージ認証コード
IV Initialization Vector
IV初期化ベクトル
KD Key Download
KDキーのダウンロード
KDF Key Derivation Function
KDF鍵導出関数
KEK Key Encryption Key
ケーキの暗号化とは何ですか？
LKH Logical Key Hierarchy
LKH論理キー階層
MSEC Multicast Security
MSECマルチキャストセキュリティ
PRF Pseudorandom Function
PRF疑似ランダム関数
SA Security Association SEQ Sequence Number
SA SAシーケンス番号
SIG Signature
SIG署名
SPI Security Parameter Index
SPIセキュリティパラメータインデックス
When a GM is ready to join a group, it contacts the GCKS with a GROUPKEY-PULL Registration Protocol. When the GCKS has authenticated and verified that the GM is an authorized member of the group, it downloads several sets of policy in a Security Association (SA) payload. If the group includes the use of a GROUPKEY-PUSH Rekey Protocol, the SA payload includes an SA Key Encryption Key (KEK) payload (Section 5.3 of [RFC6407]). When necessary, the GROUPKEY-PUSH Rekey Protocol also contains an SA payload that includes the SA KEK policy. The SA KEK policy indicates how the GM will be receiving and handling the GROUPKEY-PUSH Rekey Protocol.
GMがグループに参加する準備ができると、GMはGROUPKEY-PULL登録プロトコルでGCKSに連絡します。 GCKSは、GMがグループの承認されたメンバーであることを認証および検証すると、セキュリティアソシエーション（SA）ペイロードでいくつかのポリシーセットをダウンロードします。グループにGROUPKEY-PUSHキー再生成プロトコルの使用が含まれる場合、SAペイロードにはSAキー暗号化キー（KEK）ペイロードが含まれます（[RFC6407]のセクション5.3）。必要に応じて、GROUPKEY-PUSHキー再生成プロトコルには、SA KEKポリシーを含むSAペイロードも含まれています。 SA KEKポリシーは、GMがGROUPKEY-PUSHキー再生成プロトコルを受信して処理する方法を示します。
When the GCKS policy includes the use of the GROUPKEY-PUSH Acknowledgement Message, the GCKS reports this policy to the GM within the SA KEK policy. The GCKS includes a new KEK attribute with the name KEK_ACK_REQUESTED (9), which indicates that the GM is requested to return a GROUPKEY-PUSH Acknowledgement Message.
GCKSポリシーにGROUPKEY-PUSH確認応答メッセージの使用が含まれている場合、GCKSはこのポリシーをSA KEKポリシー内のGMに報告します。 GCKSには、KEK_ACK_REQUESTED（9）という名前の新しいKEK属性が含まれています。これは、GMがGROUPKEY-PUSH確認応答メッセージを返すように要求されていることを示します。
As part of the SA KEK policy, the GCKS specifies information on the keying material that is used to protect the GROUPKEY-PUSH Rekey Protocol (e.g., the presence of a KEK management algorithm). Parts of this information are used by a GM to derive the ack_key (defined in Section 3.2), which protects the GROUPKEY-PUSH Acknowledgement Message. There are different types of Rekey Acknowledgement Messages; they share an identical message format but differ in the keying material used.
SA KEKポリシーの一部として、GCKSは、GROUPKEY-PUSHキー再生成プロトコル（KEK管理アルゴリズムの存在など）を保護するために使用されるキー情報に関する情報を指定します。この情報の一部は、GMがack_key（セクション3.2で定義）を導出するために使用され、GROUPKEY-PUSH確認応答メッセージを保護します。 Rekey Acknowledgementメッセージにはさまざまなタイプがあります。それらは同じメッセージ形式を共有しますが、使用されるキー情報が異なります。
The following values of the KEK_ACK_REQUESTED attribute are defined in this memo.
このメモでは、KEK_ACK_REQUESTED属性の次の値が定義されています。
This type of Rekey ACK is used when the KEK Download Type (Section 5.6.2 of [RFC6407]) is part of the group policy. The prf (defined in Section 3.2) is PRF-HMAC-SHA-256 [RFC4868]. The base_key (also defined in Section 3.2) is the KEK_ALGORITHM_KEY used to decrypt the GROUPKEY-PUSH message. Note that for some algorithms the KEK_ALGORITHM_KEY will include an explicit Initialization Vector (IV) before the actual key (Section 5.6.2.1 of [RFC6407]), but it is not used in the definition of the base_key.
このタイプのRekey ACKは、KEKダウンロードタイプ（[RFC6407]のセクション5.6.2）がグループポリシーの一部である場合に使用されます。 prf（セクション3.2で定義）はPRF-HMAC-SHA-256 [RFC4868]です。 base_key（セクション3.2でも定義）は、GROUPKEY-PUSHメッセージの復号化に使用されるKEK_ALGORITHM_KEYです。一部のアルゴリズムでは、KEK_ALGORITHM_KEYには実際のキーの前に明示的な初期化ベクトル（IV）が含まれますが（[RFC6407]のセクション5.6.2.1）、base_keyの定義では使用されません。
This type of Rekey ACK can be used when the KEK_MANAGEMENT_ALGORITHM KEK attribute with a value representing the Logical Key Hierarchy (LKH) is part of the group policy (Section 5.3.1.1 of [RFC6407]). The prf is PRF-HMAC-SHA-256. The base_key is the Key Data field value taken from the first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute (see Section 5.6.3.1 of [RFC6407]). This is a secret symmetric key that the GCKS shares with the GM. Note that for some algorithms the LKH Key structure will include an explicit IV before the actual key (Section 5.6.3.1 of [RFC6407]), but it is not used in the definition of the base_key.
このタイプのRekey ACKは、論理キー階層（LKH）を表す値を持つKEK_MANAGEMENT_ALGORITHM KEK属性がグループポリシーの一部である場合に使用できます（[RFC6407]のセクション5.3.1.1）。 prfはPRF-HMAC-SHA-256です。 base_keyは、LKH_DOWNLOAD_ARRAY属性の最初のLKHキー構造から取得したキーデータフィールド値です（[RFC6407]のセクション5.6.3.1を参照）。これは、GCKSがGMと共有する秘密の対称鍵です。一部のアルゴリズムでは、LKHキー構造には実際のキーの前に明示的なIVが含まれますが（[RFC6407]のセクション5.6.3.1）、base_keyの定義では使用されません。
This type of Rekey ACK is identical to the REKEY_ACK_KEK_SHA256 Type, except that the prf is PRF-HMAC-SHA-512 (defined in [RFC4868]).
このタイプのRekey ACKは、prfがPRF-HMAC-SHA-512（[RFC4868]で定義）であることを除いて、REKEY_ACK_KEK_SHA256タイプと同じです。
This type of Rekey ACK is identical to the REKEY_ACK_LKH_SHA256 Type, except that the prf is PRF-HMAC-SHA-512 (defined in [RFC4868]).
このタイプのRekey ACKは、prfがPRF-HMAC-SHA-512（[RFC4868]で定義）であることを除いて、REKEY_ACK_LKH_SHA256タイプと同じです。
The GROUPKEY-PUSH message defined in [RFC6407] is reproduced in Figure 2. The SA and Key Download (KD) payloads contain the actual policy and keying material being distributed to the GM. The Sequence Number (SEQ) payload contains a sequence number that is used by the GM for replay protection. This sequence number defines a unique rekey message delivered to that GM. One or more Delete (D) payloads optionally specify the deletion of the existing group policy. The Signature (SIG) payload includes a signature of a hash of the entire GROUPKEY-PUSH message (excepting the SIG payload octets) before it has been encrypted.
[RFC6407]で定義されているGROUPKEY-PUSHメッセージは、図2に再現されています。SAおよびキーダウンロード（KD）ペイロードには、GMに配布される実際のポリシーとキー情報が含まれています。シーケンス番号（SEQ）ペイロードには、GMがリプレイ保護のために使用するシーケンス番号が含まれています。このシーケンス番号は、そのGMに配信される一意のキー再生成メッセージを定義します。 1つ以上の削除（D）ペイロードは、オプションで既存のグループポリシーの削除を指定します。署名（SIG）ペイロードには、暗号化される前のGROUPKEY-PUSHメッセージ全体（SIGペイロードオクテットを除く）のハッシュの署名が含まれています。
GM GCKS
-- ----
<---- HDR*, SEQ, [D,] SA, KD, SIG
* Protected by the Rekey SA KEK; encryption occurs after HDR
* Rekey SA KEKによって保護されています。暗号化はHDRの後に行われます
Figure 2: GROUPKEY-PUSH Message (from RFC 6407)
図2：GROUPKEY-PUSHメッセージ（RFC 6407から）
When the GM has received a KEK_ACK_REQUESTED attribute in an SA KEK and it chooses to respond, it returns the value of the Sequence Number taken from the GROUPKEY-PUSH message to the GCKS along with its identity. This tuple alerts the GCKS that the GM has received the GROUPKEY-PUSH message and implemented the policy contained therein. The GROUPKEY-PUSH Acknowledgement Message is shown in Figure 3.
GMがSA KEKでKEK_ACK_REQUESTED属性を受信し、応答することを選択した場合、GMはGROUPKEY-PUSHメッセージから取得したシーケンス番号の値とそのIDをGCKSに返します。このタプルは、GMがGROUPKEY-PUSHメッセージを受信し、そこに含まれるポリシーを実装したことをGCKSに警告します。 GROUPKEY-PUSH確認応答メッセージを図3に示します。
GM GCKS
-- ----
HDR, HASH, SEQ, ID ---->
Figure 3: GROUPKEY-PUSH Acknowledgement Message
図3：GROUPKEY-PUSH確認メッセージ
The IP header for the GROUPKEY-PUSH Acknowledgement Message is constructed as if it were a reply to the GROUPKEY-PUSH message. That is, the source address of the GROUPKEY-PUSH message becomes the destination address of the GROUPKEY-PUSH Acknowledgement Message, and the GM includes its own IP address as the source address of the GROUPKEY-PUSH Acknowledgement Message. The source port in the GROUPKEY-PUSH message UDP header becomes the destination port of the GROUPKEY-PUSH Acknowledgement Message UDP header, and the destination port of the GROUPKEY-PUSH message UDP header becomes the source port of the GROUPKEY-PUSH Acknowledgement Message UDP header.
GROUPKEY-PUSH確認応答メッセージのIPヘッダーは、GROUPKEY-PUSHメッセージへの応答であるかのように作成されます。つまり、GROUPKEY-PUSHメッセージの送信元アドレスがGROUPKEY-PUSH確認応答メッセージの宛先アドレスになり、GMは独自のIPアドレスをGROUPKEY-PUSH確認応答メッセージの送信元アドレスとして含めます。 GROUPKEY-PUSHメッセージUDPヘッダーの送信元ポートはGROUPKEY-PUSH確認応答メッセージUDPヘッダーの宛先ポートになり、GROUPKEY-PUSHメッセージUDPヘッダーの宛先ポートはGROUPKEY-PUSH確認応答メッセージUDPヘッダーの送信元ポートになります。
The following sections describe the payloads in the GROUPKEY-PUSH Acknowledgement Message.
次のセクションでは、GROUPKEY-PUSH確認応答メッセージのペイロードについて説明します。
The message begins with a header as defined for the GDOI GROUPKEY-PUSH message in Section 4.2 of [RFC6407]. The fields in the HDR MUST be initialized as follows. The cookies of a GROUPKEY-PUSH message act as a Security Parameter Index (SPI) and are copied to the Acknowledgement Message. "Next Payload" identifies a "Hash (HASH)" payload (value 8) [ISAKMP-NP]. Major Version is 1 and Minor Version is 0. The Exchange Type has value 35 for the GDOI GROUPKEY-PUSH Acknowledgement Message. Flags are set to 0. Message ID MUST be set to 0. Length is according to Section 4.2 of [RFC6407].
メッセージは、[RFC6407]のセクション4.2でGDOI GROUPKEY-PUSHメッセージ用に定義されたヘッダーで始まります。 HDRのフィールドは、次のように初期化する必要があります。 GROUPKEY-PUSHメッセージのCookieは、セキュリティパラメータインデックス（SPI）として機能し、確認メッセージにコピーされます。 「Next Payload」は「Hash（HASH）」ペイロード（値8）[ISAKMP-NP]を識別します。メジャーバージョンは1で、マイナーバージョンは0です。ExchangeタイプのGDOI GROUPKEY-PUSH確認応答メッセージの値は35です。フラグは0に設定されています。メッセージIDは0に設定する必要があります。長さは[RFC6407]のセクション4.2に準拠しています。
The HASH payload is the same one used in the GDOI GROUPKEY-PULL exchange defined in Section 3.2 of [RFC6407]. The hash data in the HASH payload is created as follows:
HASHペイロードは、[RFC6407]のセクション3.2で定義されているGDOI GROUPKEY-PULL交換で使用されるものと同じです。 HASHペイロードのハッシュデータは次のように作成されます。
HASH = prf(ack_key, SEQ | ID)
HASH = prf（ack_key、SEQ | ID）
where:
ただし：
o "prf" is specific to the KEK_ACK_REQUESTED value and is described as part of that description.
o 「prf」はKEK_ACK_REQUESTED値に固有であり、その説明の一部として説明されています。
o "|" indicates concatenation.
o 「|」連結を示します。
o "SEQ" and "ID" represent the bytes comprising the Sequence Number and Identification payloads.
o 「SEQ」と「ID」は、シーケンス番号と識別ペイロードを構成するバイトを表します。
The ack_key is computed from a Key Derivation Function (KDF) that conforms to KDF in feedback mode as defined in NIST SP800-108 [SP800-108], where the length of the derived keying material is the same as the output of the prf, there is no IV, and the optional counter is not used. Note: When the derived ack_key is smaller than the prf block size (i.e., 512 bits for PRF-HMAC-SHA-256), it is zero-filled to the right, as specified in Section 2.1.2 of [RFC4868].
ack_keyは、NIST SP800-108 [SP800-108]で定義されているフィードバックモードのKDFに準拠するKey Derivation Function（KDF）から計算されます。ここで、派生したキー情報の長さは、prfの出力と同じです。 IVはなく、オプションのカウンターは使用されません。注：派生したack_keyがprfブロックサイズ（つまり、PRF-HMAC-SHA-256の場合は512ビット）より小さい場合、[RFC4868]のセクション2.1.2で指定されているように、右側にゼロが埋め込まれます。
ack_key = prf(base_key, "GROUPKEY-PUSH ACK" | SPI | L)
One_key = prof（sit_key、 "group-push one" | sp | l）
where:
ただし：
o "prf" is specific to the KEK_ACK_REQUESTED value and is described as part of that description.
o 「prf」はKEK_ACK_REQUESTED値に固有であり、その説明の一部として説明されています。
o "base_key" is specific to the KEK_ACK_REQUESTED value and is described as part of that description. If the base_key is smaller than the prf block size (i.e., 512 bits for PRF-HMAC-SHA-256), then it is zero-filled to the right, as specified in Section 2.1.2 of [RFC4868].
o 「base_key」はKEK_ACK_REQUESTED値に固有であり、その説明の一部として説明されています。 [RFC4868]のセクション2.1.2で指定されているように、base_keyがprfブロックサイズ（つまり、PRF-HMAC-SHA-256の場合は512ビット）よりも小さい場合は、右側がゼロで埋められます。
o "|" indicates concatenation.
o 「|」連結を示します。
o "GROUPKEY-PUSH ACK" is a label encoded as a null-terminated ASCII string.
o 「GROUPKEY-PUSH ACK」は、ヌルで終わるASCII文字列としてエンコードされたラベルです。
o "SPI" (per [RFC6407]) is the Initiator Cookie followed by the Responder Cookie taken from the GROUPKEY-PUSH message HDR, which describes the context of the key usage.
o 「SPI」（[RFC6407]ごと）は、キーの使用法のコンテキストを説明するGROUPKEY-PUSHメッセージHDRから取得したイニシエーターCookieとそれに続くレスポンダーCookieです。
o "L" is a length field matching the number of bits in the ack_key. L MUST match the length of the base_key (i.e., 512 bits for PRF-HMAC-SHA-256). The value L is represented as two octets in network byte order (that is, most significant byte first).
o 「L」は、ack_keyのビット数と一致する長さフィールドです。 Lはbase_keyの長さと一致する必要があります（つまり、PRF-HMAC-SHA-256の場合は512ビット）。値Lは、ネットワークバイトオーダーの2オクテットとして表されます（つまり、最上位バイトが最初）。
The Sequence Number payload is defined in Section 5.7 of [RFC6407]. The value in the GROUPKEY-PUSH SEQ payload is copied to the GROUPKEY-PUSH ACK SEQ payload.
シーケンス番号ペイロードは、[RFC6407]のセクション5.7で定義されています。 GROUPKEY-PUSH SEQペイロードの値は、GROUPKEY-PUSH ACK SEQペイロードにコピーされます。
The Identification payload is used as defined in Section 5.1 of [RFC6407]. The ID payload contains an ID Type of ID_IPV4_ADDR, ID_IPV6_ADDR, or ID_OID as defined in [RFC8052] for GDOI exchanges. The Protocol ID and Port fields MUST be set to 0. The address provided in the ID payload represents the IP address of the GM and MUST match the source IP address used for the most recent GROUPKEY-PULL exchange.
識別ペイロードは、[RFC6407]のセクション5.1で定義されているとおりに使用されます。 IDペイロードには、GDOI交換の[RFC8052]で定義されているIDタイプのID_IPV4_ADDR、ID_IPV6_ADDR、またはID_OIDが含まれています。プロトコルIDおよびポートフィールドは0に設定する必要があります。IDペイロードで提供されるアドレスはGMのIPアドレスを表し、最新のGROUPKEY-PULL交換に使用されるソースIPアドレスと一致する必要があります。
When a GM receives an SA KEK payload (in a GROUPKEY-PULL exchange or GROUPKEY-PUSH message) including a KEK_ACK_REQUESTED attribute, it records in its group state some indication that it is expected to return a GROUPKEY-PUSH ACK. A GM recognizing the attribute MUST honor the KEK_ACK_REQUESTED attribute by returning Acknowledgements, because it can be expected that the GCKS is likely to take some policy-specific action regarding unresponsive GMs, including ceasing to deliver GROUPKEY-PUSH messages to it.
GMは、KEK_ACK_REQUESTED属性を含むSA KEKペイロードを（GROUPKEY-PULL交換またはGROUPKEY-PUSHメッセージで）受信すると、GROUPKEY-PUSH ACKを返すことが予想されることを示すグループ状態を記録します。属性を認識するGMは、確認応答を返すことでKEK_ACK_REQUESTED属性を尊重する必要があります。これは、GCKSがGROUPKEY-PUSHメッセージの配信を停止するなど、応答しないGMに関するポリシー固有のアクションを実行する可能性が高いためです。
If a GM cannot respond with the requested type of Acknowledgement, it continues with protocol exchange and participates in the group. In any case, if a GM stops receiving GROUPKEY-PUSH messages from a GCKS, it will re-register before existing SAs expire, so omitting the sending of Acknowledgements should not be critical.
GMが要求されたタイプの確認応答で応答できない場合、GMはプロトコル交換を続行し、グループに参加します。いずれにせよ、GMがGCKSからのGROUPKEY-PUSHメッセージの受信を停止した場合、GMは既存のSAが期限切れになる前に再登録するため、確認の送信を省略することは重要ではありません。
When a GM receives a GROUPKEY-PUSH message that contains a KEK_ACK_REQUESTED attribute in the SA KEK payload, it processes the message according to RFC 6407. When it concludes successful processing of the message, it formulates the GROUPKEY-PUSH ACKs as described in Section 3 and delivers the message to the GCKS from which the GROUPKEY-PUSH message was received. A GROUPKEY-PUSH ACK is sent even if the GROUPKEY-PUSH message contains a Delete payload for the KEK used to protect the GROUPKEY-PUSH message.
GMは、SA KEKペイロードにKEK_ACK_REQUESTED属性を含むGROUPKEY-PUSHメッセージを受信すると、RFC 6407に従ってメッセージを処理します。メッセージの正常な処理を完了すると、セクション3で説明されているように、GROUPKEY-PUSH ACKを作成します。そして、GROUPKEY-PUSHメッセージが受信されたGCKSにメッセージを配信します。 GROUPKEY-PUSHメッセージを保護するために使用されるKEKの削除ペイロードがGROUPKEY-PUSHメッセージに含まれている場合でも、GROUPKEY-PUSH ACKが送信されます。
When a GCKS policy includes requesting a GROUPKEY-PUSH ACK from GMs, it includes the KEK_ACK_REQUESTED attribute in the SA KEK payload. It does this each time the SA KEK is delivered, in both GROUPKEY-PULL exchanges and GROUPKEY-PUSH messages. The value of the KEK_ACK_REQUESTED attribute will depend upon the type of SA KEK policy, as described in Section 2.
GCKSポリシーにGMからのGROUPKEY-PUSH ACKの要求が含まれる場合、SA KEKペイロードにKEK_ACK_REQUESTED属性が含まれます。これは、SA KEKが配信されるたびに、GROUPKEY-PULL交換とGROUPKEY-PUSHメッセージの両方で行われます。セクション2で説明されているように、KEK_ACK_REQUESTED属性の値はSA KEKポリシーのタイプによって異なります。
When a GCKS receives a GROUPKEY-PUSH ACK (identified by an Exchange Type of GROUPKEY-PUSH-ACK), it first verifies that the group policy includes receiving GROUPKEY-PUSH ACKs. If not, the message is discarded. GCKS implementations SHOULD keep a record (e.g., a hash value) of recently received GROUPKEY-PUSH Acknowledgement Messages and reject duplicate messages prior to performing cryptographic operations. This enables an early discard of the replayed messages.
GCKSがGROUPKEY-PUSH ACK（ExchangeタイプGROUPKEY-PUSH-ACKで識別される）を受信すると、最初に、グループポリシーにGROUPKEY-PUSH ACKの受信が含まれていることを確認します。そうでない場合、メッセージは破棄されます。 GCKS実装は、最近受信したGROUPKEY-PUSH確認応答メッセージのレコード（ハッシュ値など）を保持し、暗号化操作を実行する前に重複メッセージを拒否する必要があります（SHOULD）。これにより、再生されたメッセージを早期に破棄できます。
If the message is expected, the GCKS validates the format of the message and verifies that the HASH has been properly constructed as described in Section 3.2. If validation fails, the message is discarded. The GCKS extracts the sequence number and identity of the GM from the SEQ and ID payloads, respectively, and records the fact that the GM received the GROUPKEY-PUSH message represented by its sequence number.
メッセージが予期される場合、GCKSはメッセージの形式を検証し、セクション3.2で説明されているようにHASHが適切に構築されていることを確認します。検証が失敗した場合、メッセージは破棄されます。 GCKSは、シーケンス番号とIDペイロードからそれぞれGMのシーケンス番号とIDを抽出し、GMがそのシーケンス番号で表されるGROUPKEY-PUSHメッセージを受信したという事実を記録します。
The GCKS manages group policy as well as determining which GM devices are presently "live" members of the group (i.e., members either sending or receiving messages). Group policy includes a strategy to ensure that rekey messages with current group policy reach all live GMs. This is discussed briefly in Section 5.3 of [RFC4046]. The GROUPKEY-PUSH Acknowledgement Message specified in this memo provides the GCKS with an additional method to assess if a GM is live and has received the current group policy. But it is possible for a rekey message or GROUPKEY-PUSH Acknowledgement Message to be discarded in the network, resulting in a live GM appearing to be unresponsive. Also, a GM might not be able to respond with a GROUPKEY-PUSH ACK, so the GCKS should use caution in using a lack of an Acknowledgement Message as the only factor in determining whether a GM is live. In particular, a GCKS SHOULD NOT consider a GM to have left the group until it has received at least one ACK from the GM.
GCKSはグループポリシーを管理し、現在どのGMデバイスがグループの「ライブ」メンバーであるか（つまり、メッセージを送信または受信しているメンバー）を決定します。グループポリシーには、現在のグループポリシーのキー再生成メッセージがすべてのライブGMに確実に届くようにするための戦略が含まれています。これについては、[RFC4046]のセクション5.3で簡単に説明しています。このメモで指定されているGROUPKEY-PUSH確認メッセージは、GMがライブで現在のグループポリシーを受け取っているかどうかを評価するための追加の方法をGCKSに提供します。ただし、キーの再生成メッセージまたはGROUPKEY-PUSH確認応答メッセージがネットワークで破棄され、ライブGMが応答していないように見える可能性があります。また、GMはGROUPKEY-PUSH ACKで応答できない場合があるため、GCKSは、GMがライブかどうかを判断する唯一の要素として確認メッセージの欠如を使用する場合は注意を払う必要があります。特に、GCKSは、GMから少なくとも1つのACKを受信するまで、GMがグループを離れたと見なすべきではありません（SHOULD NOT）。
Some management considerations for determining how a GM handles Acknowledgement Messages are as follows:
GMが確認応答メッセージを処理する方法を決定するための管理上の考慮事項は次のとおりです。
o A GM MUST respond with Acknowledgement Messages when requested, as a GCKS can subsequently determine when a GM unexpectedly becomes unresponsive.
o GMは、要求されたときに確認応答メッセージで応答する必要があります。これは、GCKSが、GMが予期せず応答しなくなったときを後で判断できるためです。
o A GM receiving a GROUPKEY-PUSH message as a multicast message MAY introduce jitter to the timing of its Acknowledgement Message to help the GCKS better manage replies from GMs. A GM MUST NOT delay sending an Acknowledgement Message for more than 5 seconds. a GCKS SHOULD NOT declare an Acknowledgement Message as missing until it has waited at least 10 seconds. Implementations SHOULD make these timers configurable.
o GROUPKEY-PUSHメッセージをマルチキャストメッセージとして受信するGMは、その確認応答メッセージのタイミングにジッタを導入して、GMからの応答をGCKSがより適切に管理できるようにする場合があります。 GMは、確認メッセージの送信を5秒以上遅延させてはなりません。 GCKSは、少なくとも10秒間待機するまで、確認メッセージが欠落していることを宣言しないでください。実装では、これらのタイマーを構成可能にする必要があります。
Some management considerations for determining how the GCKS handles Acknowledgement Messages are as follows:
GCKSが確認メッセージを処理する方法を決定するための管理上の考慮事項は次のとおりです。
o Non-receipt of an Acknowledgement Message is an indication that a GM is unable to respond. A GCKS SHOULD wait at least several seconds before determining non-receipt, as GMs could add jitter to the response time before sending an Acknowledgement Message.
o 確認メッセージを受信しないことは、GMが応答できないことを示しています。 GMは確認応答メッセージを送信する前に応答時間にジッターを追加する可能性があるため、GCKSは少なくとも数秒待ってから未受信を判断する必要があります。
o If the GCKS is aware that GMs are expected to respond, then non-receipt of an Acknowledgement Message SHOULD trigger a logging event. The GCKS MAY be configured with such additional policy actions as transmitting the GROUPKEY-PUSH message several times in a short period of time (as suggested in [RFC4046]), thereby mitigating loss of either the GROUPKEY-PUSH message or an Acknowledgement Message. Another policy action could be to alert GCKS administrators of GMs that do not return several consecutive Acknowledgement Messages or even removing unresponsive GMs from the group. However, a GCKS with a policy of removing GMs from the group needs to be aware that a GM that has not responded will not receive a newer group policy until it initiates contact with the GCKS again.
o GCKSがGMの応答が予想されることを認識している場合、確認応答メッセージを受信しないとロギングイベントがトリガーされるはずです（SHOULD）。 GCKSは、GROUPKEY-PUSHメッセージを短時間に数回送信する（[RFC4046]で提案されているように）などの追加のポリシーアクションを使用して構成できます。これにより、GROUPKEY-PUSHメッセージまたは確認応答メッセージの損失が軽減されます。もう1つのポリシーアクションは、GMKSのGCKS管理者に、連続した複数の確認応答メッセージを返さない、またはグループから応答しないGMを削除しないように警告することです。ただし、グループからGMを削除するポリシーを持つGCKSは、応答しなかったGMがGCKSとの接続を再び開始するまで、新しいグループポリシーを受信しないことに注意する必要があります。
o When a GROUPKEY-PUSH message includes a Delete payload for the KEK used to protect the GROUPKEY-PUSH message, the GCKS SHOULD NOT itself delete the KEK until it has given GMs the opportunity to acknowledge receipt of the GROUPKEY-PUSH message. This could be several seconds, as GMs could add jitter to the response time before sending an Acknowledgement Message.
o GROUPKEY-PUSHメッセージにGROUPKEY-PUSHメッセージの保護に使用されるKEKの削除ペイロードが含まれている場合、GMがGROUPKEY-PUSHメッセージの受信を確認する機会を与えるまで、GCKS自体はKEKを削除しないでください。 GMは確認応答メッセージを送信する前に応答時間にジッタを追加する可能性があるため、これは数秒になる可能性があります。
o A GCKS SHOULD log failure events, such as receiving Acknowledgement Messages for a group in which the GCKS has not requested Acknowledgements, receiving malformed Acknowledgements, and Acknowledgements that fail validation.
o GCKSは、GCKSが確認応答を要求していないグループの確認応答メッセージの受信、不正な形式の確認応答の受信、検証に失敗した確認応答などの失敗イベントをログに記録する必要があります（SHOULD）。
There are three areas of security considerations to consider: the protection of the GROUPKEY-PUSH ACK, whether the GM should transmit a GROUPKEY-PUSH ACK, and whether a GCKS should accept a GROUPKEY-PUSH ACK. These are addressed in the following subsections.
セキュリティに関する考慮事項には、考慮すべき3つの領域があります。GROUPKEY-PUSHACKの保護、GMがGROUPKEY-PUSH ACKを送信するかどうか、GCKSがGROUPKEY-PUSH ACKを受け入れるかどうかです。これらについては、次のサブセクションで説明します。
The construction of the HASH defined in this memo uses PRF-HMAC-SHA-256 or PRF-HMAC-SHA-512. The strengths of PRF-HMAC-SHA-256 and PRF-HMAC-SHA-512 were unquestioned at the time this memo was developed. When a HASH construction using a different prf becomes necessary, a new KEK_ACK_REQUESTED value will be defined in a new specification.
このメモで定義されているHASHの構築は、PRF-HMAC-SHA-256またはPRF-HMAC-SHA-512を使用します。 PRF-HMAC-SHA-256とPRF-HMAC-SHA-512の強みは、このメモが作成された時点では問題ありませんでした。異なるprfを使用したHASH構築が必要になると、新しいKEK_ACK_REQUESTED値が新しい仕様で定義されます。
The GROUPKEY-PUSH ACK is an Internet Security Association and Key Management Protocol (ISAKMP) message as discussed in [RFC2408]. (Note: RFC 2408 has been obsoleted by RFC 7296, but only RFC 2408 applies in this context.) Message authentication and protection against man-in-the-middle attacks are provided by the inclusion of a HASH payload that includes the output of an HMAC computation over the bytes of the message.
GROUPKEY-PUSH ACKは、[RFC2408]で説明されているインターネットセキュリティアソシエーションおよびキー管理プロトコル（ISAKMP）メッセージです。 （注：RFC 2408はRFC 7296によって廃止されましたが、このコンテキストではRFC 2408のみが適用されます。）メッセージ認証と中間者攻撃に対する保護は、の出力を含むHASHペイロードを含めることで提供されます。メッセージのバイトに対するHMAC計算。
Because the KEK is a group secret, when the value of REKEY_ACK_KEK is specified, impersonation of a victim GM by another authorized GM is possible. However, security considerations regarding such an impersonation are limited to a false claim that a victim GM has received a GROUPKEY-PUSH when the victim GM has in fact not received it (e.g., because an active attacker has discarded the GROUPKEY-PUSH). If a GCKS policy includes sending retransmissions of the GROUPKEY-PUSH message to that victim GM, then the victim GM might not receive replacement SAs. However, this does not introduce any additional threats over a use case where the GROUPKEY-PUSH ACK is not deployed and GROUPKEY-PUSH messages are withheld from a victim GM by an active attacker. These threats can be mitigated by using a value of REKEY_ACK_LKH, due to the use of a secret pairwise key shared between the GCKS and an individual GM.
KEKはグループシークレットであるため、REKEY_ACK_KEKの値が指定されている場合、別の許可されたGMによる犠牲者GMの偽装が可能です。ただし、このようななりすましに関するセキュリティ上の考慮事項は、被害者GMが実際にGROUPKEY-PUSHを受け取っていないという誤った主張に限定されます（たとえば、アクティブな攻撃者がGROUPKEY-PUSHを破棄したため）。 GCKSポリシーがGROUPKEY-PUSHメッセージの再送信をその被害者GMに送信することを含む場合、被害者GMは交換SAを受信しない可能性があります。ただし、これは、GROUPKEY-PUSH ACKが展開されておらず、GROUPKEY-PUSHメッセージがアクティブな攻撃者によって被害者のGMから差し控えられているユースケースに対して追加の脅威をもたらすことはありません。これらの脅威は、GCKSと個々のGM間で共有される秘密のペアワイズキーを使用するため、REKEY_ACK_LKHの値を使用することで軽減できます。
Confidentiality is not provided for the GROUPKEY-PUSH ACK. The contents of the message, including the hash value, the sequence number from the GROUPKEY-PUSH message to which it is acknowledging receipt, and the identity of the GM, can be observed by a passive attacker. Observation of a hash value or set of hash values will not compromise the hash key. The identity of the GM is also available to the passive attacker as the source IP address of the packet. Note that the sequence number in the GROUPKEY-PUSH ACK does reveal the sequence number (previously not available to the attacker) that was included in the GROUPKEY-PUSH message. However, the attacker is assumed to not be in possession of the key used to encrypt the message and thus cannot create a spoofed GROUPKEY-PUSH message. Therefore, the attacker does not derive any direct value from learning the sequence number.
GROUPKEY-PUSH ACKには機密性は提供されません。ハッシュ値、受信を確認するGROUPKEY-PUSHメッセージからのシーケンス番号、およびGMのIDを含むメッセージの内容は、パッシブ攻撃者によって監視される可能性があります。ハッシュ値またはハッシュ値のセットを監視しても、ハッシュキーは危険にさらされません。 GMのIDは、パッシブ攻撃者がパケットの送信元IPアドレスとしても利用できます。 GROUPKEY-PUSH ACKのシーケンス番号は、GROUPKEY-PUSHメッセージに含まれていたシーケンス番号（以前は攻撃者が利用できなかった）を明らかにすることに注意してください。ただし、攻撃者はメッセージの暗号化に使用されるキーを所持していないと想定されるため、スプーフィングされたGROUPKEY-PUSHメッセージを作成できません。したがって、攻撃者はシーケンス番号の学習から直接的な値を導き出すことはありません。
A GM transmits an ACK only when the policy of the most recently received SA KEK includes a request by the GCKS for ACKs, and the ACK is only returned after processing the GROUPKEY-PUSH message according to Section 4.4 of [RFC6407]. In other words, the form of the GROUPKEY-PUSH message will have been validated, replay protection completed, and the digital signature verified as being genuine. Therefore, the threat of a GM responding to a spoofed or resent GROUPKEY-PUSH message, and the possibility of the GM being used to propagate a Distributed Denial of Service (DDoS) attack on a GCKS, are mitigated. For more information, see the security considerations for a GROUPKEY-PUSH message as described in Section 7.3 of [RFC6407].
最後に受信したSA KEKのポリシーにACKのGCKSによる要求が含まれている場合にのみGMがACKを送信し、[RFC6407]のセクション4.4に従ってGROUPKEY-PUSHメッセージを処理した後にのみACKが返されます。つまり、GROUPKEY-PUSHメッセージの形式が検証され、再生保護が完了し、デジタル署名が本物であることが検証されます。したがって、スプーフィングまたは再送信されたGROUPKEY-PUSHメッセージに応答するGMの脅威、およびGMがGCKSに対する分散型サービス拒否（DDoS）攻撃の伝播に使用される可能性が軽減されます。詳細については、[RFC6407]のセクション7.3に記載されているGROUPKEY-PUSHメッセージのセキュリティに関する考慮事項をご覧ください。
A GCKS receiving ACKs will follow the validation steps described in Section 5 before interpreting the contents of the message. The GCKS will then be sure to operate only on messages that have been sent by an authorized GM.
ACKを受信するGCKSは、メッセージの内容を解釈する前に、セクション5で説明されている検証手順に従います。その後、GCKSは、承認されたGMによって送信されたメッセージに対してのみ動作するようになります。
A GCKS SHOULD be prepared to receive GROUPKEY-PUSH ACKs from each GM to which it was sent. That is, it needs to ensure that it has sufficient resources (e.g., receive queue size) so that it does not unnecessarily drop ACKs. A GCKS should be aware that a large number of replayed or invalid GROUPKEY-PUSH messages could be addressed to it. However, this is no worse a threat than if it received a large number of other types of replayed or invalid GDOI or other messages containing a HASH payload.
GCKSは、送信先の各GMからGROUPKEY-PUSH ACKを受信できるように準備する必要があります（SHOULD）。つまり、ACKが不必要にドロップされないように、十分なリソース（受信キューのサイズなど）があることを確認する必要があります。 GCKSは、大量の再生または無効なGROUPKEY-PUSHメッセージが送信される可能性があることを認識しておく必要があります。ただし、これは、他のタイプの再生または無効なGDOIまたはHASHペイロードを含む他のメッセージを多数受信した場合よりも脅威ではありません。
How a GCKS processes the sequence number and identity included in an ACK is a matter of local policy and is outside the scope of this memo.
GCKSがACKに含まれるシーケンス番号とIDをどのように処理するかはローカルポリシーの問題であり、このメモの範囲外です。
The following additions have been made to the "Group Domain of Interpretation (GDOI) Payloads" [GDOI-REG] registry.
「Group Domain of Interpretation（GDOI）Payloads」[GDOI-REG]レジストリに次の追加が行われました。
A new attribute has been added to the "SA KEK Payload Values - KEK Attributes" registry. The ID Class name is KEK_ACK_REQUESTED with a value of 9 and is a Basic attribute.
「SA KEKペイロード値-KEK属性」レジストリに新しい属性が追加されました。 IDクラス名はKEK_ACK_REQUESTEDで、値は9で、基本属性です。
A new registry defining values for KEK_ACK_REQUESTED, "SA KEK Payload Values - KEK_ACK_REQUESTED", has been added; the initial registrations are shown in the following table. The terms "Reserved", "Unassigned", and "Private Use" are to be applied as defined in [RFC8126]. The registration procedure is Specification Required.
KEK_ACK_REQUESTEDの値を定義する新しいレジストリ「SA KEKペイロード値-KEK_ACK_REQUESTED」が追加されました。初期登録を次の表に示します。 「予約済み」、「未割り当て」、および「私用」という用語は、[RFC8126]で定義されているように適用されます。登録手続きは「要指定」です。
Value Type
------- --------------------
0 Reserved
1 REKEY_ACK_KEK_SHA256
2 REKEY_ACK_LKH_SHA256
3 REKEY_ACK_KEK_SHA512
4 REKEY_ACK_LKH_SHA512
5-128 Unassigned
129-255 Private Use
A new registry describing ISAKMP Exchange Types for the GDOI, "GDOI DOI Exchange Types", has been added under the "Group Domain of Interpretation (GDOI) Payloads" registry [GDOI-REG]. This new registry defines DOI Specific Use values [ISAKMP-EXCH], which are Exchange Type values used with the ISAKMP GDOI DOI. The registration procedure is Specification Required. The terms "Known Unregistered Use" and "Unassigned" are to be applied as defined in [RFC8126].
GDOIのISAKMP交換タイプを説明する新しいレジストリである「GDOI DOI交換タイプ」が、「Group Domain of Interpretation（GDOI）Payloads」レジストリ[GDOI-REG]の下に追加されました。この新しいレジストリは、DOI固有の使用値[ISAKMP-EXCH]を定義します。これは、ISAKMP GDOI DOIで使用されるExchange Type値です。登録手続きは「要指定」です。 「未登録の既知の使用」および「未割り当て」という用語は、[RFC8126]で定義されているとおりに適用されます。
Value Phase Reference
---------------------- ------ ---------
GROUPKEY-PULL 32 RFC 6407
GROUPKEY-PUSH 33 RFC 6407
Known Unregistered Use 34
GROUPKEY-PUSH-ACK 35 RFC 8263
Unassigned 36-239
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.
[RFC4868]ケリー、S.、S。フランケル、「IPsecでのHMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512の使用」、RFC 4868、DOI 10.17487 / RFC4868、2007年5月、<https： //www.rfc-editor.org/info/rfc4868>。
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[RFC6407] Weis、B.、Rowles、S.、T。Hardjono、「The Group Domain of Interpretation」、RFC 6407、DOI 10.17487 / RFC6407、2011年10月、<https://www.rfc-editor.org/ info / rfc6407>。
[RFC8052] Weis, B., Seewald, M., and H. Falk, "Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services", RFC 8052, DOI 10.17487/RFC8052, June 2017, <https://www.rfc-editor.org/info/rfc8052>.
[RFC8052] Weis、B.、Seewald、M。、およびH. Falk、「Group Domain of Interpretation（GDOI）Protocol Support for IEC 62351 Security Services」、RFC 8052、DOI 10.17487 / RFC8052、2017年6月、<https：/ /www.rfc-editor.org/info/rfc8052>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[GDOI-REG] Internet Assigned Numbers Authority, "Group Domain of Interpretation (GDOI) Payload Type Values", IANA Registry, September 2017, <https://www.iana.org/assignments/ gdoi-payloads/>.
[GDOI-REG] Internet Assigned Numbers Authority、「Group Domain of Interpretation（GDOI）Payload Type Values」、IANA Registry、2017年9月、<https://www.iana.org/assignments/gdoi-payloads/>。
[ISAKMP-EXCH] Internet Assigned Numbers Authority, "Internet Key Exchange (IKE) Attributes Exchange Type Values", IANA Registry, May 2013, <https://www.iana.org/assignments/ipsec-registry/>.
[ISAKMP-EXCH] Internet Assigned Numbers Authority、「Internet Key Exchange（IKE）Attributes Exchange Type Values」、IANA Registry、2013年5月、<https://www.iana.org/assignments/ipsec-registry/>。
[ISAKMP-NP] Internet Assigned Numbers Authority, "Internet Key Exchange (IKE) Attributes Next Protocol Types", IANA Registry, May 2013, <https://www.iana.org/assignments/ipsec-registry/>.
[ISAKMP-NP] Internet Assigned Numbers Authority、「Internet Key Exchange（IKE）Attributes Next Protocol Types」、IANA Registry、2013年5月、<https://www.iana.org/assignments/ipsec-registry/>。
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998, <https://www.rfc-editor.org/info/rfc2408>.
[RFC2408] Maughan、D.、Schertler、M.、Schneider、M。、およびJ. Turner、「Internet Security Association and Key Management Protocol（ISAKMP）」、RFC 2408、DOI 10.17487 / RFC2408、1998年11月、<https： //www.rfc-editor.org/info/rfc2408>。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, <https://www.rfc-editor.org/info/rfc4046>.
[RFC4046]バウアー、M。、カネッティ、R。、ドンデティ、L。、およびF.リンホルム、「マルチキャストセキュリティ（MSEC）グループキー管理アーキテクチャ」、RFC 4046、DOI 10.17487 / RFC4046、2005年4月、<https：/ /www.rfc-editor.org/info/rfc4046>。
[SP800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions (Revised)", National Institute of Science and Technology, NIST Special Publication 800-108, DOI 10.6028/NIST.SP.800-108, October 2009, <http://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-108.pdf>.
[SP800-108]チェンL.、「擬似ランダム関数を使用した鍵導出の推奨事項（改訂）」、国立科学技術研究所、NIST特別刊行物800-108、DOI 10.6028 / NIST.SP.800-108、2009年10月、<http://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-108.pdf>。
Acknowledgements
謝辞
Mike Hamada, Adrian Farrel, and Yaron Sheffer provided many useful technical and editorial comments and suggestions for improvement.
Mike Hamada、Adrian Farrel、およびYaron Shefferは、技術的および編集上役立つ多くのコメントと改善のための提案を提供しました。
Authors' Addresses
著者のアドレス
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 United States of America
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose、California 95134-1706 United States of America
Phone: +1-408-526-4796
Email: bew@cisco.com
Umesh Mangla Juniper Networks Inc. 1133 Innovation Way Sunnyvale, California 94089 United States of America
Umesh Mangla Juniper Networks Inc. 1133 Innovation Wayサニーベール、カリフォルニア州94089アメリカ合衆国
Phone: +1-408-936-1022
Email: umangla@juniper.net
Thomas Karl Deutsche Telekom Landgrabenweg 151 Bonn 53227 Germany
Thomas Karl Deutsche Telekom Landgrabenweg 151ボン53227ドイツ
Phone: +49-228-18138122
Email: thomas.karl@telekom.de
Nilesh Maheshwari
ニレシュ・マヘシュワリ
Email: nileshm@gmail.com