RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8221
タイトル : RFC 8221 - 暗号化アルゴリズムの実装要件とセキュリティペイロード（ESP）および認証ヘッダー（AH）のカプセル化に関する使用ガイダンス
翻訳編集 : 自動生成

[要約] RFC 8221は、IPsecプロトコルスイートの一部であるEncapsulating Security Payload (ESP) と Authentication Header (AH) のための暗号化アルゴリズムの実装要件と使用ガイダンスに関する文書です。このRFCの目的は、安全な通信を確保するために推奨される暗号化アルゴリズムとその強度、およびこれらのアルゴリズムの適切な使用方法を提供することにあります。主にVPNやセキュアなネットワーク接続の設定に利用され、IPsecのセキュリティを強化するための基準を定めています。関連するRFCにはRFC 4302 (AHの仕様), RFC 4303 (ESPの仕様), およびRFC 7321 (IPsecのアーキテクチャに関する文書) などがあります。

Internet Engineering Task Force (IETF)                        P. Wouters
Request for Comments: 8221                                       Red Hat
Obsoletes: 7321                                               D. Migault
Category: Standards Track                                    J. Mattsson
ISSN: 2070-1721                                                 Ericsson
                                                                  Y. Nir
                                                             Check Point
                                                              T. Kivinen
                                                            October 2017

Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)

暗号化アルゴリズムの実装要件とセキュリティペイロード（ESP）および認証ヘッダー（AH）のカプセル化に関する使用ガイダンス

Abstract

概要

This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable.

このドキュメントは、RFC 7321「暗号化アルゴリズムの実装要件と、セキュリティペイロード（ESP）および認証ヘッダー（AH）のカプセル化に関するガイダンス」を置き換えます。このドキュメントの目的は、ESPとAHがIPsecを相互運用可能にしながら、最新の暗号化を利用できるようにすることです。

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/rfc8221.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8221で入手できます。

著作権表示

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.  Updating Algorithm Implementation Requirements and Usage
           Guidance  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Updating Algorithm Requirement Levels . . . . . . . . . .   3
     1.3.  Document Audience . . . . . . . . . . . . . . . . . . . .   4
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
   3.  Manual Keying . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Encryption Must Be Authenticated  . . . . . . . . . . . . . .   6
   5.  ESP Encryption Algorithms . . . . . . . . . . . . . . . . . .   7
   6.  ESP and AH Authentication Algorithms  . . . . . . . . . . . .   9
   7.  ESP and AH Compression Algorithms . . . . . . . . . . . . . .  10
   8.  Summary of Changes from RFC 7321  . . . . . . . . . . . . . .  11
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     11.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1. Introduction

1. はじめに

The Encapsulating Security Payload (ESP) [RFC4303] and the Authentication Header (AH) [RFC4302] are the mechanisms for applying cryptographic protection to data being sent over an IPsec Security Association (SA) [RFC4301].

カプセル化セキュリティペイロード（ESP）[RFC4303]および認証ヘッダー（AH）[RFC4302]は、IPsecセキュリティアソシエーション（SA）[RFC4301]を介して送信されるデータに暗号保護を適用するためのメカニズムです。

This document provides guidance and recommendations so that ESP and AH can be used with cryptographic algorithms that are up to date. The challenge of such documents is making sure that, over time, IPsec implementations can use secure and up-to-date cryptographic algorithms while keeping IPsec interoperable.

このドキュメントでは、ESPとAHを最新の暗号化アルゴリズムで使用できるように、ガイダンスと推奨事項を提供します。このようなドキュメントの課題は、時間の経過とともに、IPsecの実装がIPsecの相互運用性を維持しながら、安全で最新の暗号化アルゴリズムを使用できるようにすることです。

1.1. Updating Algorithm Implementation Requirements and Usage Guidance

1.1. アルゴリズムの実装要件と使用ガイダンスの更新

The field of cryptography evolves continuously: new, stronger algorithms appear, and existing algorithms are found to be less secure than originally thought. Therefore, algorithm implementation requirements and usage guidance need to be updated from time to time to reflect the new reality. The choices for algorithms must be conservative to minimize the risk of algorithm compromise. Algorithms need to be suitable for a wide variety of CPU architectures and device deployments ranging from high-end bulk encryption devices to small, low-power Internet of Things (IoT) devices.

暗号化の分野は絶えず進化しています。新しい強力なアルゴリズムが登場し、既存のアルゴリズムは当初考えられていたよりも安全性が低いことが判明しています。したがって、アルゴリズムの実装要件と使用方法のガイダンスは、新しい現実を反映するために時々更新する必要があります。アルゴリズムの妥協のリスクを最小限に抑えるために、アルゴリズムの選択は保守的である必要があります。アルゴリズムは、ハイエンドのバルク暗号化デバイスから小型で低電力のモノのインターネット（IoT）デバイスに至るまで、さまざまなCPUアーキテクチャとデバイスの展開に適している必要があります。

The algorithm implementation requirements and usage guidance may need to change over time to adapt to the changing world. For this reason, the selection of mandatory-to-implement algorithms was removed from the main Internet Key Exchange Protocol Version 2 (IKEv2) specification [RFC7296] and placed in a separate document.

アルゴリズムの実装要件と使用方法のガイダンスは、変化する世界に適応するために、時間とともに変化する必要がある場合があります。このため、必須から実装までのアルゴリズムの選択は、メインのインターネットキーエクスチェンジプロトコルバージョン2（IKEv2）仕様[RFC7296]から削除され、別のドキュメントに配置されました。

1.2. Updating Algorithm Requirement Levels

1.2. アルゴリズム要件レベルの更新

The mandatory-to-implement algorithm of tomorrow should already be available in most implementations of AH/ESP by the time it is made mandatory. This document attempts to identify and introduce those algorithms for future mandatory-to-implement status. There is no guarantee that the algorithms in use today may become mandatory in the future. Published algorithms are continuously subjected to cryptographic attack and may become too weak or could become completely broken before this document is updated.

明日の実装に必須のアルゴリズムは、AH / ESPのほとんどの実装で、それが必須にされるまでにすでに利用可能であるはずです。このドキュメントでは、これらのアルゴリズムを特定して導入し、将来の必須から実装までのステータスを示します。現在使用されているアルゴリズムが将来必須になる可能性があるという保証はありません。公開されているアルゴリズムは継続的に暗号攻撃を受けており、このドキュメントが更新される前に弱くなりすぎたり、完全に壊れたりする可能性があります。

This document only provides recommendations for the mandatory-to-implement algorithms and "too weak" algorithms that are recommended not to be implemented. As a result, any algorithm listed at the IPsec IANA registry that is not mentioned in this document MAY be implemented. It is expected that this document will be updated over time and future versions will only mention algorithms that have evolved in status. For clarification, when an algorithm has been mentioned in [RFC7321], this document states explicitly the update of the status.

このドキュメントでは、実装が必須のアルゴリズムと、実装が推奨されない「弱すぎる」アルゴリズムの推奨のみを提供します。その結果、このドキュメントで言及されていないIPsec IANAレジストリにリストされているアルゴリズムが実装される場合があります。このドキュメントは時間の経過とともに更新され、将来のバージョンではステータスが進化したアルゴリズムについてのみ言及することが予想されます。明確にするために、アルゴリズムが[RFC7321]で言及されている場合、このドキュメントはステータスの更新を明示的に述べています。

Although this document updates the algorithms to keep the AH/ESP communication secure over time, it also aims at providing recommendations so that AH/ESP implementations remain interoperable. AH/ESP interoperability is addressed by an incremental introduction or deprecation of algorithms. In addition, this document also considers the new use cases for AH/ESP deployment, such as IoT.

このドキュメントはアルゴリズムを更新して、AH / ESP通信を長期間にわたって安全に保ちますが、AH / ESP実装の相互運用性を維持するための推奨事項を提供することも目的としています。 AH / ESPの相互運用性は、アルゴリズムの段階的な導入または廃止により対処されます。さらに、このドキュメントでは、IoTなどのAH / ESP展開の新しい使用例についても検討します。

It is expected that deprecation of an algorithm be performed gradually. This provides time for various implementations to update their implemented algorithms while remaining interoperable. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to MUST- or SHOULD, instead of MUST NOT (see Section 2). Similarly, an algorithm that has not been mentioned as mandatory-to-implement is expected to be introduced with a SHOULD instead of a MUST.

アルゴリズムの廃止は徐々に行われることが期待されています。これにより、さまざまな実装が、相互運用性を維持しながら、実装されたアルゴリズムを更新する時間が提供されます。強力なセキュリティ上の理由がない限り、アルゴリズムは、MUST NOTではなく、MUST NOTからMUST-またはSHOULDにダウングレードされることが期待されます（セクション2を参照）。同様に、実装が必須として言及されていないアルゴリズムは、MUSTの代わりにSHOULDで導入されることが期待されています。

The current trend toward IoT and its adoption of AH/ESP requires this specific use case to be taken into account as well. IoT devices are resource-constrained devices, and their choice of algorithms is motivated by minimizing the footprint of the code, the computation effort, and the size of the messages to send. This document indicates "(IoT)" when a specified algorithm is specifically listed for IoT devices. Requirement levels that are marked as "IoT" apply to IoT devices and to server-side implementations that might presumably need to interoperate with them, including any general-purpose VPN gateways.

IoTへの現在の傾向とAH / ESPの採用には、この特定のユースケースも考慮する必要があります。 IoTデバイスはリソースに制約のあるデバイスであり、アルゴリズムの選択は、コードのフットプリント、計算の労力、および送信するメッセージのサイズを最小限に抑えることによって動機付けられます。このドキュメントでは、特定のアルゴリズムがIoTデバイス用に具体的にリストされている場合、「（IoT）」を示しています。「IoT」とマークされている要件レベルは、IoTデバイスと、汎用VPNゲートウェイを含む、おそらくそれらと相互運用する必要があるサーバー側の実装に適用されます。

1.3. Document Audience

1.3. ドキュメントの対象者

The recommendations of this document mostly target AH/ESP implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure AH/ESP with only the safest cipher suite.

このドキュメントの推奨事項は主にAH / ESP実装者を対象としています。実装は、さまざまなベンダー間および異なるバージョン間での高いセキュリティの期待と高い相互運用性の両方を満たす必要があるためです。相互運用性には、より安全な暗号スイートへのスムーズな移行が必要です。これは、最も安全な暗号スイートのみでAH / ESPを展開および構成するユーザーの観点とは異なる場合があります。

This document does not give any recommendations for the use of algorithms, it only gives recommendations for implementations. The use of algorithms by a specific user is dictated by their own security policy requirements, which are outside the scope of this document.

このドキュメントでは、アルゴリズムの使用に関する推奨事項は提供していません。実装に関する推奨事項のみを提供しています。特定のユーザーによるアルゴリズムの使用は、このドキュメントの範囲外である独自のセキュリティポリシー要件によって決定されます。

The algorithms considered here are listed by IANA as part of the IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is deprecated; the recommendations of this document must not be considered for IKEv1, nor may IKEv1 parameters be considered by this document.

ここで検討されているアルゴリズムは、IKEv2パラメーターの一部としてIANAによってリストされています。 IKEv1はこのドキュメントの範囲外です。 IKEv1は非推奨です。このドキュメントの推奨事項をIKEv1について検討することはできません。また、IKEv1パラメータをこのドキュメントで検討することもできません。

The IANA registry for "Internet Key Exchange Version 2 (IKEv2) Parameters" contains some entries that are not for use with ESP or AH. This document does not modify the status of those algorithms.

「インターネットキーエクスチェンジバージョン2（IKEv2）パラメータ」のIANAレジストリには、ESPまたはAHで使用できないいくつかのエントリが含まれています。このドキュメントでは、これらのアルゴリズムのステータスは変更されません。

2. Requirements Language

2. 要件言語

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]で説明されているように解釈されます。

We define some additional terms here:

ここでいくつかの追加の用語を定義します。

SHOULD+ This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD- This term means the same as SHOULD. However, an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document. MUST- This term means the same as MUST. However, we expect at some point that this algorithm will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST-algorithm, it will remain at least a SHOULD or a SHOULD-level. IoT The Internet of Things.

SHOULD +この用語は、SHOULDと同じことを意味します。ただし、SHOULD +としてマークされたアルゴリズムは、将来的には、MUSTになるようにプロモートされる可能性があります。 SHOULD-この用語は、SHOULDと同じことを意味します。ただし、SHOULD-とマークされたアルゴリズムは、このドキュメントの将来のバージョンで非推奨になる可能性があります。 MUST-この用語は、MUSTと同じことを意味します。ただし、ある時点で、このアルゴリズムは将来のドキュメントでは必須ではなくなります。そのステータスは後で決定されますが、ドキュメントの将来のリビジョンがMUST-アルゴリズムのステータスを変更する場合、それは少なくともSHOULDまたはSHOULDレベルのままであることを期待するのは妥当です。 IoTモノのインターネット。

3. Manual Keying

3. 手動キーイング

Manual keying SHOULD NOT be used, as it is inherently dangerous. Without any secure keying protocol, such as IKE, IPsec does not offer Perfect Forward Secrecy (PFS) protection; there is no entity to ensure the refreshing of session keys, the tracking of Security Parameter Index (SPI) uniqueness, and the single use of nonces, Initialization Vectors (IVs), and counters. This document was written for deploying ESP/AH using IKE [RFC7296] and assumes that keying happens using IKEv2 or higher.

手動キーイングは本質的に危険なので、使用しないでください。 IKEなどの安全なキーイングプロトコルがない場合、IPsecはPerfect Forward Secrecy（PFS）保護を提供しません。セッションキーの更新、セキュリティパラメータインデックス（SPI）の一意性の追跡、ノンス、初期化ベクトル（IV）、およびカウンタの単独使用を保証するエンティティはありません。このドキュメントは、IKE [RFC7296]を使用してESP / AHを導入するために作成され、IKEv2以降を使用してキーイングが行われることを前提としています。

If manual keying is used regardless, Counter Mode algorithms such as ENCR_AES_CTR, ENCR_AES_CCM, ENCR_AES_GCM, and ENCR_CHACHA20_POLY1305 MUST NOT be used, as it is incompatible with a secure and persistent handling of the counter (as explained in the Security Considerations section of [RFC3686]). This particularly applies to IoT devices that have no state across reboots. At the time of writing, ENCR_AES_CBC is the only mandatory-to-implement encryption algorithm suitable for manual keying.

手動のキーイングを使用する場合は、ENCR_AES_CTR、ENCR_AES_CCM、ENCR_AES_GCM、ENCR_CHACHA20_POLY1305などのカウンターモードアルゴリズムを使用しないでください。これは、カウンターの安全で永続的な処理と互換性がないためです（[RFC3686]のセキュリティに関する考慮事項セクションで説明）。）。これは特に、再起動しても状態が変化しないIoTデバイスに当てはまります。執筆時点では、ENCR_AES_CBCは、手動キーイングに適した唯一の必須から実装までの暗号化アルゴリズムです。

4. Encryption Must Be Authenticated

4. 暗号化を認証する必要があります

Encryption without authentication is not effective and MUST NOT be used. IPsec offers three ways to provide both encryption and authentication:

認証なしの暗号化は効果がなく、使用してはなりません。 IPsecは、暗号化と認証の両方を提供する3つの方法を提供します。

o ESP with an Authenticated Encryption with Associated Data (AEAD) cipher

o Authenticated Encryption with Associated Data（AEAD）暗号を使用したESP

o ESP with a non-AEAD cipher + authentication

o 非AEAD暗号+認証を使用するESP

o ESP with a non-AEAD cipher + AH with authentication

o 非AEAD暗号を使用するESP +認証を使用するAH

The fastest and most modern method is to use ESP with a combined mode cipher, such as an AEAD cipher, that handles encryption/decryption and authentication in a single step. In this case, the AEAD cipher is set as the encryption algorithm, and the authentication algorithm is set to none. Examples of this are ENCR_AES_GCM_16 and ENCR_CHACHA20_POLY1305.

最速かつ最新の方法は、暗号化/復号化と認証を単一のステップで処理する、AEAD暗号などの複合モード暗号でESPを使用することです。この場合、AEAD暗号は暗号化アルゴリズムとして設定され、認証アルゴリズムはなしに設定されます。この例は、ENCR_AES_GCM_16およびENCR_CHACHA20_POLY1305です。

A more traditional approach is to use ESP with an encryption and an authentication algorithm. This approach is slower, as the data has to be processed twice: once for encryption/decryption and once for authentication. An example of this is ENCR_AES_CBC combined with AUTH_HMAC_SHA2_512_256.

より伝統的なアプローチは、暗号化および認証アルゴリズムを備えたESPを使用することです。データを2回処理する必要があるため、このアプローチは遅くなります。1つは暗号化/復号化、もう1つは認証です。この例は、AUTH_HMAC_SHA2_512_256と組み合わせたENCR_AES_CBCです。

The last method that can be used is ESP+AH. This method is NOT RECOMMENDED. It is the slowest method and also takes up more octets due to the double header of ESP+AH. This results in a smaller effective MTU for the encrypted data. With this method, ESP is only used for confidentiality without an authentication algorithm, and a second IPsec protocol of type AH is used for authentication. An example of this is ESP with ENCR_AES_CBC with AH with AUTH_HMAC_SHA2_512_256.

使用できる最後の方法は、ESP + AHです。この方法は推奨されません。これは最も遅い方法であり、ESP + AHのダブルヘッダーのため、より多くのオクテットを使用します。これにより、暗号化されたデータの有効MTUが小さくなります。この方法では、ESPは認証アルゴリズムなしで機密性のためにのみ使用され、タイプAHの2番目のIPsecプロトコルが認証に使用されます。これの例は、AUTH_HMAC_SHA2_512_256を使用するAHを使用するENCR_AES_CBCを使用するESPです。

5. ESP Encryption Algorithms

5. ESP暗号化アルゴリズム

    +-------------------------+------------+---------+----------------+
    | Name                    | Status     | AEAD    | Comment        |
    +-------------------------+------------+---------+----------------+
    | ENCR_DES_IV64           | MUST NOT   | No      | UNSPECIFIED    |
    | ENCR_DES                | MUST NOT   | No      | [RFC2405]      |
    | ENCR_3DES               | SHOULD NOT | No      | [RFC2451]      |
    | ENCR_BLOWFISH           | MUST NOT   | No      | [RFC2451]      |
    | ENCR_3IDEA              | MUST NOT   | No      | UNSPECIFIED    |
    | ENCR_DES_IV32           | MUST NOT   | No      | UNSPECIFIED    |
    | ENCR_NULL               | MUST       | No      | [RFC2410]      |
    | ENCR_AES_CBC            | MUST       | No      | [RFC3602][1]   |
    | ENCR_AES_CCM_8          | SHOULD     | Yes     | [RFC4309](IoT) |
    | ENCR_AES_GCM_16         | MUST       | Yes     | [RFC4106][1]   |
    | ENCR_CHACHA20_POLY1305  | SHOULD     | Yes     | [RFC7634]      |
    +-------------------------+------------+---------+----------------+

[1] - This requirement level is for 128-bit and 256-bit keys. 192-bit keys remain at the MAY level.

[1] -この要件レベルは、128ビットおよび256ビットの鍵用です。 192ビットのキーはMAYレベルのままです。

(IoT) - This requirement is for interoperability with IoT. Only 128-bit keys are at the given level.

（IoT）-この要件は、IoTとの相互運用性のためのものです。指定されたレベルにあるのは128ビットの鍵のみです。

IPsec sessions may have very long lifetime and carry multiple packets, so there is a need to move to 256-bit keys in the long term. For that purpose, the requirement level for 128-bit keys and 256-bit keys is MUST (when applicable). In that sense, the status for 256-bit keys has been raised from MAY in [RFC7321] to MUST.

IPsecセッションは非常に長い有効期間を持ち、複数のパケットを伝送する可能性があるため、長期的には256ビットの鍵に移行する必要があります。そのため、128ビットキーと256ビットキーの要件レベルは必須です（該当する場合）。その意味で、256ビットキーのステータスは[RFC7321]のMAYからMUSTに引き上げられました。

IANA has allocated codes for cryptographic algorithms that have not been specified by the IETF. Such algorithms are noted as UNSPECIFIED. Usually, the use of these algorithms is limited to specific cases, and the absence of specification makes interoperability difficult for IPsec communications. These algorithms were not mentioned in [RFC7321], and this document clarifies that such algorithms MUST NOT be implemented for IPsec communications.

IANAは、IETFによって指定されていない暗号化アルゴリズムのコードを割り当てました。そのようなアルゴリズムはUNSPECIFIEDとして示されています。通常、これらのアルゴリズムの使用は特定のケースに限定されており、指定がないと、IPsec通信の相互運用性が難しくなります。これらのアルゴリズムは[RFC7321]で言及されておらず、このドキュメントでは、そのようなアルゴリズムをIPsec通信に実装してはならないことを明確にします。

Similarly, IANA also allocated code points for algorithms that are not expected to be used to secure IPsec communications. Such algorithms are noted as non-IPsec. As a result, these algorithms MUST NOT be implemented.

同様に、IANAは、IPsec通信のセキュリティ保護に使用することが想定されていないアルゴリズムにもコードポイントを割り当てました。このようなアルゴリズムは、非IPsecとして示されています。結果として、これらのアルゴリズムは実装してはなりません（MUST NOT）。

Various ciphers that are older, not well tested, and never widely implemented have been changed to MUST NOT.

古く、十分にテストされておらず、広く実装されていないさまざまな暗号は、変更してはならない（MUST NOT）。

ENCR_3DES status has been downgraded from MAY in [RFC7321] to SHOULD NOT. ENCR_CHACHA20_POLY1305 is a more modern approach and alternative for ENCR_3DES than ENCR_AES_CBC, and so it is expected to be favored to replace ENCR_3DES.

ENCR_3DESステータスは[RFC7321]のMAYからダウンしてはいけません（SHOULD NOT）。 ENCR_CHACHA20_POLY1305は、ENCR_AES_CBCよりもENCR_3DESの最新のアプローチおよび代替手段であるため、ENCR_3DESを置き換えることが推奨されます。

ENCR_BLOWFISH has been downgraded to MUST NOT as it has been deprecated for years by TWOFISH, which is not standardized for ESP and therefore not listed in this document. Some implementations support TWOFISH using a private range number.

ENCR_BLOWFISHはTWOFISHによって何年もの間非推奨になっているため、MUST NOTにダウングレードされました。ESW用に標準化されていないため、このドキュメントには記載されていません。一部の実装では、プライベート範囲番号を使用したTWOFISHがサポートされています。

ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to enable the use of ESP with only authentication, which is preferred over AH due to NAT traversal. ENCR_NULL is expected to remain MUST by protocol requirements.

ENCR_NULLステータスは[RFC7321]でMUSTに設定され、認証のみのESPの使用を有効にするために必須であり、NATトラバーサルのためにAHよりも優先されます。 ENCR_NULLは、プロトコル要件により、MUSTのままであることが期待されます。

ENCR_AES_CBC status remains at MUST. ENCR_AES_CBC MUST be implemented in order to enable interoperability between implementations that followed [RFC7321]. However, there is a trend for the industry to move to AEAD encryption, and the overhead of ENCR_AES_CBC remains quite large, so it is expected to be replaced by AEAD algorithms in the long term.

ENCR_AES_CBCステータスはMUSTのままです。 ENCR_AES_CBCは、[RFC7321]に準拠した実装間の相互運用性を有効にするために実装する必要があります。ただし、業界ではAEAD暗号化に移行する傾向があり、ENCR_AES_CBCのオーバーヘッドは非常に大きいままであるため、長期的にはAEADアルゴリズムに置き換えられることが予想されます。

ENCR_AES_CCM_8 status was set to MAY in [RFC7321] and has been raised from MAY to SHOULD in order to interact with IoT devices. As this case is not a general use case for VPNs, its status is expected to remain as SHOULD.

ENCR_AES_CCM_8ステータスは[RFC7321]でMAYに設定され、IoTデバイスと対話するためにMAYからSHOULDに引き上げられました。このケースはVPNの一般的なユースケースではないため、そのステータスはSHOULDのままであることが予想されます。

ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order to favor the use of authenticated encryption and AEAD algorithms. ENCR_AES_GCM_16 has been widely implemented for ESP due to its increased performance and key longevity compared to ENCR_AES_CBC.

ENCR_AES_GCM_16ステータスは、認証された暗号化とAEADアルゴリズムの使用を優先するために、SHOULD +からMUSTに更新されました。 ENCR_AES_GCM_16は、ENCR_AES_CBCと比較してパフォーマンスが向上し、キーの寿命が長いため、ESPに広く実装されています。

ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of [RFC7321]. It has been recommended by the Crypto Forum Research Group (CFRG) and others as an alternative to AES-CBC and AES-GCM. At the time of writing, there are not enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to introduce it at the SHOULD+ level. Its status has been set to SHOULD and is expected to become MUST in the long term.

ENCR_CHACHA20_POLY1305は、[RFC7321]の時点で検討する準備ができていませんでした。これは、AES-CBCおよびAES-GCMの代替として、Crypto Forum Research Group（CFRG）および他の人たちから推奨されています。執筆時点では、ENCR_CHACHA20_POLY1305のESP実装は、SHOULD +レベルで導入するのに十分ではありません。そのステータスはSHOULDに設定されており、長期的にはMUSTになる予定です。

6. ESP and AH Authentication Algorithms

6. ESPおよびAH認証アルゴリズム

Authentication algorithm recommendations in this section are targeting two types of communications:

このセクションの認証アルゴリズムの推奨は、2種類の通信を対象としています。

o Authenticated-only communications without encryption, such as ESP with NULL encryption or AH communications.

o NULL暗号化を使用したESPまたはAH通信など、暗号化を使用しない認証のみの通信。

o Communications that are encrypted with a non-AEAD algorithm that MUST be combined with an authentication algorithm.

o 認証アルゴリズムと組み合わせる必要がある非AEADアルゴリズムで暗号化された通信。

   +------------------------+----------------+-------------------------+
   | Name                   | Status         | Comment                 |
   +------------------------+----------------+-------------------------+
   | AUTH_NONE              | MUST /         | [RFC7296][RFC5282]      |
   |                        | MUST NOT       | AEAD-only               |
   | AUTH_HMAC_MD5_96       | MUST NOT       | [RFC2403][RFC7296]      |
   | AUTH_HMAC_SHA1_96      | MUST-          | [RFC2404][RFC7296]      |
   | AUTH_DES_MAC           | MUST NOT       | UNSPECIFIED             |
   | AUTH_KPDK_MD5          | MUST NOT       | UNSPECIFIED             |
   | AUTH_AES_XCBC_96       | SHOULD / MAY   | [RFC3566][RFC7296]      |
   |                        |                | (IoT)                   |
   | AUTH_AES_128_GMAC      | MAY            | [RFC4543]               |
   | AUTH_AES_256_GMAC      | MAY            | [RFC4543]               |
   | AUTH_HMAC_SHA2_256_128 | MUST           | [RFC4868]               |
   | AUTH_HMAC_SHA2_512_256 | SHOULD         | [RFC4868]               |
   +------------------------+----------------+-------------------------+

(IoT) - This requirement is for interoperability with IoT.

（IoT）-この要件は、IoTとの相互運用性のためのものです。

AUTH_NONE has been downgraded from MAY in [RFC7321] to MUST NOT. The only case where AUTH_NONE is acceptable is when authenticated encryption algorithms are selected from Section 5. In all other cases, AUTH_NONE MUST NOT be selected. As ESP and AH both provide authentication, one may be tempted to combine these protocols to provide authentication. As mentioned by [RFC7321], it is NOT RECOMMENDED to use ESP with NULL authentication (with non-authenticated encryption) in conjunction with AH; some configurations of this combination of services have been shown to be insecure [PD10]. In addition, AUTH_NONE authentication cannot be combined with ESP NULL encryption.

AUTH_NONEは[RFC7321]の5月からダウンしてはならない（MUST NOT）。 AUTH_NONEが受け入れられる唯一のケースは、セクション5から認証済み暗号化アルゴリズムが選択されている場合です。その他の場合は、AUTH_NONEを選択してはなりません（MUST NOT）。 ESPとAHはどちらも認証を提供するので、これらのプロトコルを組み合わせて認証を提供したくなるかもしれません。 [RFC7321]で述べられているように、AHと組み合わせてNULL認証（非認証暗号化）でESPを使用することは推奨されません。このサービスの組み合わせの一部の構成は、安全でないことが示されています[PD10]。さらに、AUTH_NONE認証をESP NULL暗号化と組み合わせることはできません。

AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in [RFC7321]. As MD5 is known to be vulnerable to collisions, these algorithms MUST NOT be used.

AUTH_HMAC_MD5_96およびAUTH_KPDK_MD5は[RFC7321]で言及されていませんでした。 MD5は衝突に対して脆弱であることが知られているため、これらのアルゴリズムを使用してはなりません（MUST NOT）。

AUTH_HMAC_SHA1_96 has been downgraded from MUST in [RFC7321] to MUST-as there is an industry-wide trend to deprecate its usage.

AUTH_HMAC_SHA1_96は、[RFC7321]のMUSTからMUSTにダウングレードされました。これは、その使用を廃止する業界全体の傾向があるためです。

AUTH_DES_MAC was not mentioned in [RFC7321]. As DES is known to be vulnerable, it MUST NOT be used.

AUTH_DES_MACは[RFC7321]で言及されていません。 DESは脆弱であることがわかっているため、使用してはなりません（MUST NOT）。

AUTH_AES_XCBC_96 is set as SHOULD only in the scope of IoT, as IoT deployments tend to prefer AES-based Hashed Message Authentication Code (HMAC) functions in order to avoid implementing SHA2. For the wide VPN deployment, as it has not been widely adopted, it has been downgraded from SHOULD to MAY.

AUTH_AES_XCBC_96は、IoTの展開ではSHA2の実装を回避するためにAESベースのハッシュメッセージ認証コード（HMAC）機能を好む傾向があるため、IoTの範囲でのみ設定する必要があります（SHOULD）。ワイドVPN展開では、広く採用されていないため、SHOULDからMAYにダウングレードされました。

AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY. Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms should only be used for AH and not for ESP. If using ENCR_NULL, AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using AES-GMAC in ESP without authentication, ENCR_NULL_AUTH_AES_GMAC is recommended. Therefore, these algorithms are kept at MAY.

AUTH_AES_128_GMACステータスがSHOULD +からMAYに格下げされました。 AUTH_AES_192_GMACおよびAUTH_AES_256_GMACとともに、これらのアルゴリズムはAHにのみ使用し、ESPには使用しないでください。 ENCR_NULLを使用する場合、整合性を保つためにAUTH_HMAC_SHA2_256_128をお勧めします。認証なしでESPでAES-GMACを使用する場合は、ENCR_NULL_AUTH_AES_GMACをお勧めします。したがって、これらのアルゴリズムは5月に保持されます。

AUTH_HMAC_SHA2_256_128 was not mentioned in [RFC7321], as no SHA2-based authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be implemented in order to replace AUTH_HMAC_SHA1_96. Note that due to a long standing common implementation bug of this algorithm that truncates the hash at 96 bits instead of 128 bits, it is recommended that implementations prefer AUTH_HMAC_SHA2_512_256 over AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256.

AUTH_HMAC_SHA2_256_128は、SHA2ベースの認証について言及されていないため、[RFC7321]で言及されていません。 AUTH_HMAC_SHA1_96を置き換えるには、AUTH_HMAC_SHA2_256_128を実装する必要があります。 128ビットではなく96ビットでハッシュを切り捨てるこのアルゴリズムの長期にわたる一般的な実装バグのため、AUTH_HMAC_SHA2_512_256を実装する場合は、AUTH_HMAC_SHA2_256_128よりもAUTH_HMAC_SHA2_512_256を優先することをお勧めします。

AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement of AUTH_HMAC_SHA2_256_128 or when stronger security is required. This value has been preferred to AUTH_HMAC_SHA2_384, as the additional overhead of AUTH_HMAC_SHA2_512 is negligible.

AUTH_HMAC_SHA2_512_256は、AUTH_HMAC_SHA2_256_128の将来の置き換えとして、またはより強力なセキュリティが必要な場合に実装する必要があります（SHOULD）。 AUTH_HMAC_SHA2_512の追加のオーバーヘッドは無視できるため、この値はAUTH_HMAC_SHA2_384よりも優先されています。

7. ESP and AH Compression Algorithms

7. ESPおよびAH圧縮アルゴリズム

                +----------------+----------+-------------+
                | Name           | Status   | Comment     |
                +----------------+----------+-------------+
                | IPCOMP_OUI     | MUST NOT | UNSPECIFIED |
                | IPCOMP_DEFLATE | MAY      | [RFC3173]   |
                | IPCOMP_LZS     | MAY      | [RFC2395]   |
                | IPCOMP_LZJH    | MAY      | [RFC3051]   |
                +----------------+----------+-------------+

Compression was not mentioned in [RFC7321]. As it is not widely deployed, it remains optional and at the MAY level.

圧縮は[RFC7321]で言及されていませんでした。広く展開されていないため、オプションであり、MAYレベルのままです。

8. Summary of Changes from RFC 7321

8. RFC 7321からの変更の概要

The following table summarizes the changes from RFC 7321.

次の表は、RFC 7321からの変更点をまとめたものです。

            +-------------------+----------+-----------------+
            | Algorithm         | RFC 7321 |     RFC 8221    |
            +-------------------+----------+-----------------+
            | ENCR_AES_GCM_16   | SHOULD+  |       MUST      |
            | ENCR_AES_CCM_8    |   MAY    |      SHOULD     |
            | ENCR_AES_CTR      |   MAY    |      MAY(*)     |
            | ENCR_3DES         |   MAY    |    SHOULD NOT   |
            | AUTH_HMAC_SHA1_96 |   MUST   |      MUST-      |
            | AUTH_AES_128_GMAC | SHOULD+  |       MAY       |
            | AUTH_NONE         |   MAY    | MUST / MUST NOT |
            +-------------------+----------+-----------------+

(*) This algorithm is not mentioned in the above sections, so it defaults to MAY.

（*）このアルゴリズムは上記のセクションでは言及されていないため、デフォルトでMAYになります。

9. IANA Considerations

9. IANAに関する考慮事項

This document does not require any IANA actions.

このドキュメントでは、IANAアクションは必要ありません。

10. Security Considerations

10. セキュリティに関する考慮事項

The security of a system that uses cryptography depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering and administration of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.

暗号化を使用するシステムのセキュリティは、選択された暗号化アルゴリズムの強度と、それらのアルゴリズムで使用される鍵の強度の両方に依存します。また、セキュリティは、システム全体のセキュリティを回避する非暗号化の方法がないことを保証するために、システムが使用するプロトコルのエンジニアリングと管理に依存します。

This document concerns itself with the selection of cryptographic algorithms for the use of ESP and AH, specifically with the selection of mandatory-to-implement algorithms. The algorithms identified in this document as "MUST implement" or "SHOULD implement" are not known to be broken at the current time, and cryptographic research to date leads us to believe that they will likely remain secure into the foreseeable future. However, this is not necessarily forever. Therefore, we expect that revisions of that document will be issued from time to time to reflect the current best practice in this area.

このドキュメントは、ESPとAHを使用するための暗号化アルゴリズムの選択、特に必須から実装へのアルゴリズムの選択に関係しています。このドキュメントで「実装する必要がある」または「実装する必要がある」と識別されたアルゴリズムは現時点では壊れていないことがわかっており、現在までの暗号研究により、当面はそれらが安全であり続けると思われます。ただし、これは必ずしも永遠ではありません。したがって、このドキュメントの改訂版は、この分野の現在のベストプラクティスを反映するために随時発行されることを期待しています。

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

[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>。

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https://www.rfc-editor.org/info/rfc4301>。

[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.

[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、DOI 10.17487 / RFC4302、2005年12月、<https://www.rfc-editor.org/info/rfc4302>。

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.

[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<https://www.rfc-editor.org/info/rfc4303>。

[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, <https://www.rfc-editor.org/info/rfc7321>.

[RFC7321] McGrew、D。およびP. Hoffman、「暗号化アルゴリズムの実装要件とカプセル化セキュリティペイロード（ESP）および認証ヘッダー（AH）の使用ガイダンス」、RFC 7321、DOI 10.17487 / RFC7321、2014年8月、<https：/ /www.rfc-editor.org/info/rfc7321>。

[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>。

11.2. Informative References

11.2. 参考引用

[PD10] Paterson, K. and J. Degabriele, "On the (in)security of IPsec in MAC-then-encrypt configurations", Proceedings of the 17th ACM Conference on Computer and Communications Security (ACM CCS), DOI 10.1145/1866307.1866363, 2010.

[PD10] Paterson、K。およびJ. Degabriele、「MAC-then-encrypt構成におけるIPsecの（非）セキュリティについて」、第17回コンピュータおよび通信セキュリティに関するACM会議の議事録（ACM CCS）、DOI 10.1145 / 1866307.1866363 、2010年。

[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998, <https://www.rfc-editor.org/info/rfc2395>.

[RFC2395] Friend、R。およびR. Monsour、「LZSを使用したIPペイロード圧縮」、RFC 2395、DOI 10.17487 / RFC2395、1998年12月、<https://www.rfc-editor.org/info/rfc2395>。

[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November 1998, <https://www.rfc-editor.org/info/rfc2403>.

[RFC2403] Madson、C。およびR. Glenn、「The Use of HMAC-MD5-96 within ESP and AH」、RFC 2403、DOI 10.17487 / RFC2403、1998年11月、<https://www.rfc-editor.org / info / rfc2403>。

[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1998, <https://www.rfc-editor.org/info/rfc2404>.

[RFC2404] Madson、C。およびR. Glenn、「The Use of HMAC-SHA-1-96 within ESP and AH」、RFC 2404、DOI 10.17487 / RFC2404、1998年11月、<https：//www.rfc-editor .org / info / rfc2404>。

[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, DOI 10.17487/RFC2405, November 1998, <https://www.rfc-editor.org/info/rfc2405>.

[RFC2405] Madson、C。およびN. Doraswamy、「明示的なIVを使用したESP DES-CBC暗号アルゴリズム」、RFC 2405、DOI 10.17487 / RFC2405、1998年11月、<https://www.rfc-editor.org/info / rfc2405>。

[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, November 1998, <https://www.rfc-editor.org/info/rfc2410>.

[RFC2410] Glenn、R。およびS. Kent、「NULL暗号化アルゴリズムとIPsecでのその使用」、RFC 2410、DOI 10.17487 / RFC2410、1998年11月、<https://www.rfc-editor.org/info/ rfc2410>。

[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, DOI 10.17487/RFC2451, November 1998, <https://www.rfc-editor.org/info/rfc2451>.

[RFC2451] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、DOI 10.17487 / RFC2451、1998年11月、<https://www.rfc-editor.org/info/rfc2451> 。

[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051, January 2001, <https://www.rfc-editor.org/info/rfc3051>.

[RFC3051]ヒースJ.およびJ.ボーダー、「ITU-T V.44パケット方式を使用したIPペイロード圧縮」、RFC 3051、DOI 10.17487 / RFC3051、2001年1月、<https://www.rfc-editor.org / info / rfc3051>。

[RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, DOI 10.17487/RFC3173, September 2001, <https://www.rfc-editor.org/info/rfc3173>.

[RFC3173] Shacham、A.、Monsour、B.、Pereira、R。、およびM. Thomas、「IP Payload Compression Protocol（IPComp）」、RFC 3173、DOI 10.17487 / RFC3173、2001年9月、<https：// www .rfc-editor.org / info / rfc3173>。

[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566, September 2003, <https://www.rfc-editor.org/info/rfc3566>.

[RFC3566]フランケルS.およびH.ハーバート、「AES-XCBC-MAC-96アルゴリズムとIPsecでのその使用」、RFC 3566、DOI 10.17487 / RFC3566、2003年9月、<https：//www.rfc-editor .org / info / rfc3566>。

[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, DOI 10.17487/RFC3602, September 2003, <https://www.rfc-editor.org/info/rfc3602>.

[RFC3602]フランケルS.、グレンR.、およびS.ケリー、「AES-CBC暗号アルゴリズムとIPsecでのその使用」、RFC 3602、DOI 10.17487 / RFC3602、2003年9月、<https：// www。 rfc-editor.org/info/rfc3602>。

[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, <https://www.rfc-editor.org/info/rfc3686>.

[RFC3686] Housley、R。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンターモードの使用」、RFC 3686、DOI 10.17487 / RFC3686、2004年1月、<https：//www.rfc-editor。 org / info / rfc3686>。

[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, DOI 10.17487/RFC4106, June 2005, <https://www.rfc-editor.org/info/rfc4106>.

[RFC4106] Viega、J。およびD. McGrew、「The Use of Galois / Counter Mode（GCM）in IPsec Encapsulating Security Payload（ESP）」、RFC 4106、DOI 10.17487 / RFC4106、2005年6月、<https：// www .rfc-editor.org / info / rfc4106>。

[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, DOI 10.17487/RFC4309, December 2005, <https://www.rfc-editor.org/info/rfc4309>.

[RFC4309] Housley、R。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）CCMモードの使用」、RFC 4309、DOI 10.17487 / RFC4309、2005年12月、<https：//www.rfc-editor。 org / info / rfc4309>。

[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, DOI 10.17487/RFC4543, May 2006, <https://www.rfc-editor.org/info/rfc4543>.

[RFC4543] McGrew、D.、J。Viega、「The Use of Galois Message Authentication Code（GMAC）in IPsec ESP and AH」、RFC 4543、DOI 10.17487 / RFC4543、2006年5月、<https：//www.rfc- editor.org/info/rfc4543>。

[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>。

[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, DOI 10.17487/RFC5282, August 2008, <https://www.rfc-editor.org/info/rfc5282>.

[RFC5282] Black、D。、およびD. McGrew、「Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2（IKEv2）Protocol」、RFC 5282、DOI 10.17487 / RFC5282、2008年8月、<https：// www.rfc-editor.org/info/rfc5282>。

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.

[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<https://www.rfc-editor.org/info/rfc7296>。

[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, DOI 10.17487/RFC7634, August 2015, <https://www.rfc-editor.org/info/rfc7634>.

[RFC7634] Nir、Y。、「ChaCha20、Poly1305、およびインターネットキー交換プロトコル（IKE）とIPsecでのそれらの使用」、RFC 7634、DOI 10.17487 / RFC7634、2015年8月、<https：//www.rfc-editor .org / info / rfc7634>。

Acknowledgements

謝辞

Some of the wording in this document was adapted from [RFC7321], the document that this one obsoletes, which was written by D. McGrew and P. Hoffman.

この文書の表現の一部は、[RFC7321]から改作されたもので、この文書は廃止されたため、D。McGrewとP. Hoffmanが作成しました。

Authors' Addresses

著者のアドレス

Paul Wouters Red Hat

ポール・ウーターズレッドハット

   Email: pwouters@redhat.com

Daniel Migault Ericsson 8275 Trans Canada Route Saint-Laurent, QC H4S 0B6 Canada

Daniel Migault Ericsson 8275 Trans Canada Route Saint-Laurent、QC H4S 0B6 Canada

   Phone: +1 514-452-2160
   Email: daniel.migault@ericsson.com

John Mattsson Ericsson AB SE-164 80 Stockholm Sweden

John Mattsson Ericsson AB SE-164 80ストックホルムスウェーデン

   Email: john.mattsson@ericsson.com

Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim St. Tel Aviv 6789735 Israel

   Email: ynir.ietf@gmail.com

Tero Kivinen

テロ・キビネン

   Email: kivinen@iki.fi