[要約] 要約： RFC 7146は、IP上のブロックストレージプロトコルのセキュリティを強化するためのガイドラインです。 目的は、IPsec v3の要件を更新し、ブロックストレージプロトコルのセキュリティを向上させることです。
Internet Engineering Task Force (IETF) D. Black
Request for Comments: 7146 EMC
Updates: 3720, 3723, 3821, 3822, 4018, 4172, P. Koning
4173, 4174, 5040, 5041, 5042, 5043, Dell
5044, 5045, 5046, 5047, 5048 April 2014
Category: Standards Track
ISSN: 2070-1721
Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3
IPを介したBlock Storage Protocolsの保護：IPsec v3のRFC 3723要件の更新
Abstract
概要
RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., Internet Small Computer System Interface (iSCSI)) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., the Remote Direct Memory Access Protocol (RDMAP). This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published.
RFC 3723は、IPsec v2（RFC 2401および関連RFC）に基づいて、IP（インターネットスモールコンピューターシステムインターフェイス（iSCSI）など）上のブロックストレージプロトコルのIPsec要件を指定します。これらの要件は、その後、リモートダイレクトデータプレースメントプロトコル（リモートダイレクトメモリアクセスプロトコル（RDMAP）など）に適用されました。このドキュメントでは、RFC 3723のIPsec要件をIPsec v3（RFC 4301および関連するRFC）に更新し、RFC 3723が公開されてからの暗号化の発展に基づいて、必要なアルゴリズムにいくつかの変更を加えます。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc7146.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7146で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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文書に関するIETFトラストの法的規定（http://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 Language ......................................3
1.2. Summary of Changes to RFC 3723 .............................4
1.3. Other Updated RFCs .........................................4
2. ESP Requirements ................................................6
2.1. Data Origin Authentication and Data Integrity Transforms ...6
2.2. Confidentiality Transform Requirements .....................7
3. IKEv1 and IKEv2 Requirements ....................................8
3.1. Authentication Requirements ...............................10
3.2. DH Group and PRF Requirements .............................11
4. Security Considerations ........................................11
5. References .....................................................12
5.1. Normative References ......................................12
5.2. Informative References ....................................16
Appendix A. Block Cipher Birthday Bounds ..........................17
Appendix B. Contributors ..........................................17
[RFC3723] specifies IPsec requirements for block storage protocols over IP (e.g., iSCSI [RFC3720]) based on IPsec v2 ([RFC2401] and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., RDMAP [RFC5040]. This document updates RFC 3723's IPsec requirements to IPsec v3 ([RFC4301] and related RFCs) to reflect developments since RFC 3723 was published.
[RFC3723]は、IPsec v2（[RFC2401]および関連するRFC）に基づいて、IP上のブロックストレージプロトコル（iSCSI [RFC3720]など）のIPsec要件を指定します。これらの要件は、その後、RDMAP [RFC5040]などのリモート直接データ配置プロトコルに適用されました。このドキュメントは、RFC 3723が発行されてからの進展を反映するために、RFC 3723のIPsec要件をIPsec v3（[RFC4301]および関連RFC）に更新します。
For brevity, this document uses the term "block storage protocols" to refer to all protocols to which RFC 3723's requirements apply; see Section 1.3 for details.
簡潔にするために、このドキュメントでは「ブロックストレージプロトコル」という用語を使用して、RFC 3723の要件が適用されるすべてのプロトコルを指します。詳細については、セクション1.3を参照してください。
In addition to the IPsec v2 requirements in RFC 3723, IPsec v3, as specified in [RFC4301] and related RFCs (e.g., IKEv2 [RFC5996]), SHOULD be implemented for block storage protocols. Retention of the mandatory requirement for IPsec v2 provides interoperability with existing implementations, and the strong recommendation for IPsec v3 encourages implementers to move forward to that newer version of IPsec.
[RFC4301]と関連するRFC（IKEv2 [RFC5996]など）で指定されているように、RFC 3723、IPsec v3のIPsec v2要件に加えて、ブロックストレージプロトコルに実装する必要があります（SHOULD）。 IPsec v2の必須要件を維持することで、既存の実装との相互運用性が提供され、IPsec v3の強力な推奨により、実装者は新しいバージョンのIPsecに移行することができます。
Cryptographic developments since the publication of RFC 3723 necessitate changes to the encryption transform requirements for IPsec v2, as explained further in Section 2.2; these updated requirements also apply to IPsec v3.
RFC 3723の公開以降の暗号の開発では、セクション2.2でさらに説明するように、IPsec v2の暗号化トランスフォーム要件を変更する必要があります。これらの更新された要件は、IPsec v3にも適用されます。
Block storage protocols can be expected to operate at high data rates (multiple gigabits/second). The cryptographic requirements in this document are strongly influenced by that expectation; an important example is that Triple Data Encryption Standard Cipher Block Chaining (3DES CBC) is no longer recommended for block storage protocols due to the frequent rekeying impacts of 3DES's 64-bit block size at high data rates.
ブロックストレージプロトコルは、高いデータレート（マルチギガビット/秒）で動作することが期待できます。このドキュメントの暗号化要件は、その期待に強く影響されています。重要な例は、トリプルデータ暗号化標準暗号ブロックチェーン（3DES CBC）が、高データレートでの3DESの64ビットブロックサイズの頻繁な再キーイングの影響により、ブロックストレージプロトコルに推奨されなくなったことです。
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 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
This document makes the following changes to RFC 3723:
このドキュメントは、RFC 3723に次の変更を加えます。
o Adds requirements that IPsec v3 SHOULD be implemented (Encapsulating Security Payload (ESPv3) and IKEv2) in addition to IPsec v2 (see Section 1).
o IPsec v2に加えて、IPsec v3を実装する必要がある（カプセル化セキュリティペイロード（ESPv3）およびIKEv2）要件を追加します（セクション1を参照）。
o Requires extended sequence numbers for both ESPv2 and ESPv3 (see Section 2).
o ESPv2とESPv3の両方に拡張シーケンス番号が必要です（セクション2を参照）。
o Clarifies key-size requirements for AES CBC MAC with XCBC extensions (MUST implement 128-bit keys; see Section 2.1).
o XCBC拡張を使用したAES CBC MACのキーサイズ要件を明確にします（128ビットキーを実装する必要があります。セクション2.1を参照）。
o Adds IPsec v3 requirements for AES Galois Message Authentication Code (GMAC) and Galois/Counter Mode (GCM) (SHOULD implement when IKEv2 is supported; see Sections 2.1 and 2.2).
o AESガロアメッセージ認証コード（GMAC）およびガロア/カウンターモード（GCM）のIPsec v3要件を追加します（IKEv2がサポートされている場合は実装する必要があります。セクション2.1および2.2を参照）。
o Removes implementation requirements for 3DES CBC and AES in Counter mode (AES CTR) (changes requirements for both to "MAY implement"). Adds a "MUST implement" requirement for AES CBC (see Section 2.2).
o カウンターモードの3DES CBCおよびAES（AES CTR）の実装要件を削除します（両方の要件を「実装可能」に変更します）。 AES CBCの「実装する必要がある」要件を追加します（セクション2.2を参照）。
o Adds specific IKEv2 implementation requirements (see Section 3).
o 特定のIKEv2実装要件を追加します（セクション3を参照）。
o Removes the requirement that IKEv1 use UDP port 500 (see Section 3).
o IKEv1がUDPポート500を使用するという要件を削除します（セクション3を参照）。
o Allows the use of the Online Certificate Status Protocol (OCSP) in addition to Certificate Revocation Lists (CRLs) to check certificates, and changes the Diffie-Hellman group size recommendation to a minimum of 2048 bits (see Section 3).
o 証明書失効リスト（CRL）に加えて、オンライン証明書ステータスプロトコル（OCSP）を使用して証明書をチェックできるようにし、Diffie-Hellmanグループサイズの推奨を最低2048ビットに変更します（セクション3を参照）。
RFC 3723's IPsec requirements have been applied to a number of protocols. For that reason, in addition to updating RFC 3723's IPsec requirements, this document also updates the IPsec requirements for each protocol that uses RFC 3723; that is, the following RFCs are updated -- in each case, the update is solely to the IPsec requirements:
RFC 3723のIPsec要件は、多くのプロトコルに適用されています。そのため、このドキュメントでは、RFC 3723のIPsec要件の更新に加えて、RFC 3723を使用する各プロトコルのIPsec要件も更新しています。つまり、次のRFCが更新されます。いずれの場合も、更新はIPsec要件のみに対するものです。
o [RFC3720] "Internet Small Computer Systems Interface (iSCSI)"
o [RFC3720] "インターネットスモールコンピューターシステムインターフェイス（iSCSI）"
o [RFC3821] "Fibre Channel Over TCP/IP (FCIP)"
o [RFC3821]「TCP / IPを介したファイバーチャネル（FCIP）」
o [RFC3822] "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)"
o [RFC3822]「Service Location Protocolバージョン2（SLPv2）を使用したTCP / IP（FCIP）エンティティ上のファイバーチャネルの検索」
o [RFC4018] "Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)"
o [RFC4018] "Service Location Protocolバージョン2（SLPv2）を使用したインターネットスモールコンピューターシステムインターフェイス（iSCSI）ターゲットとネームサーバーの検索"
o [RFC4172] "iFCP - A Protocol for Internet Fibre Channel Storage Networking"
o [RFC4172]「iFCP-インターネットファイバーチャネルストレージネットワーキングのプロトコル」
o [RFC4173] "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol"
o [RFC4173]「インターネットSmall Computer System Interface（iSCSI）プロトコルを使用したクライアントのブートストラップ」
o [RFC4174] "The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service"
o [RFC4174]「インターネットストレージネームサービスのIPv4動的ホスト構成プロトコル（DHCP）オプション」
o [RFC5040] "A Remote Direct Memory Access Protocol Specification"
o [RFC5040]「リモートダイレクトメモリアクセスプロトコル仕様」
o [RFC5041] "Direct Data Placement over Reliable Transports"
o [RFC5041]「信頼できるトランスポート上の直接データ配置」
o [RFC5042] "Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security"
o [RFC5042]「直接データ配置プロトコル（DDP）/リモート直接メモリーアクセスプロトコル（RDMAP）セキュリティー」
o [RFC5043] "Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation"
o [RFC5043]「ストリーム制御伝送プロトコル（SCTP）直接データ配置（DDP）適応」
o [RFC5044] "Marker PDU Aligned Framing for TCP Specification"
o [RFC5044]「TCP仕様のマーカーPDU整列フレーミング」
o [RFC5045] "Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)"
o [RFC5045]「リモートダイレクトメモリアクセスプロトコル（RDMA）とダイレクトデータ配置（DDP）の適用性」
o [RFC5046] "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)"
o [RFC5046]「リモートダイレクトメモリアクセス（RDMA）用のインターネットスモールコンピューターシステムインターフェイス（iSCSI）拡張機能」
o [RFC5047] "DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI)"
o [RFC5047]「DA：Internet Small Computer System Interface（iSCSI）用のDatamoverアーキテクチャ」
o [RFC5048] "Internet Small Computer System Interface (iSCSI) Corrections and Clarifications"
o [RFC5048] "インターネットスモールコンピューターシステムインターフェイス（iSCSI）の修正と明確化"
[RFC3721] and [RFC5387] are not updated by this document, as their usage of RFC 3723 does not encompass its IPsec requirements.
[RFC3721]と[RFC5387]は、このドキュメントでは更新されていません。RFC3723の使用にはIPsec要件が含まれていないためです。
In addition, this document's updated IPsec requirements apply to the new specifications for iSCSI [RFC7143] and iSCSI Extensions for RDMA (iSER) [RFC7145].
さらに、このドキュメントの更新されたIPsec要件は、iSCSI [RFC7143]およびRDMAのiSCSI拡張（iSER）[RFC7145]の新しい仕様に適用されます。
This document uses the term "block storage protocols" to refer to the protocols (listed above) to which RFC 3723's requirements (as updated by the requirements in this document) apply.
このドキュメントでは、「ブロックストレージプロトコル」という用語を使用して、RFC 3723の要件（このドキュメントの要件によって更新された）が適用されるプロトコル（上記にリスト）を指します。
RFC 3723 requires that implementations MUST support IPsec ESPv2 [RFC2406] in tunnel mode as part of IPsec v2 to provide security for both control packets and data packets; and that when ESPv2 is utilized, per-packet data origin authentication, integrity, and replay protection MUST be provided.
RFC 3723では、実装が制御パケットとデータパケットの両方にセキュリティを提供するために、IPsec v2の一部としてトンネルモードでIPsec ESPv2 [RFC2406]をサポートする必要があることを要求しています。 ESPv2を利用する場合は、パケットごとのデータ発信元認証、整合性、およびリプレイ保護を提供する必要があります。
This document modifies RFC 3723 to require that implementations SHOULD also support IPsec ESPv3 [RFC4303] in tunnel mode as part of IPsec v3 to provide security for both control packets and data packets; per-packet data origin authentication, integrity, and replay protection MUST be provided when ESPv3 is utilized.
このドキュメントでは、RFC 3723を変更して、実装パケットがIPsec v3の一部としてトンネルモードのIPsec ESPv3 [RFC4303]もサポートし、制御パケットとデータパケットの両方にセキュリティを提供する必要があることを要求しています。 ESPv3を使用する場合は、パケットごとのデータ発信元の認証、整合性、およびリプレイ保護を提供する必要があります。
At the high speeds at which block storage protocols are expected to operate, a single IPsec security association (SA) could rapidly exhaust the ESP 32-bit sequence number space, requiring frequent rekeying of the SA, as rollover of the ESP sequence number within a single SA is prohibited for both ESPv2 [RFC2406] and ESPv3 [RFC4303]. In order to provide the means to avoid this potentially undesirable frequent rekeying, implementations that are capable of operating at speeds of 1 gigabit/second or higher MUST implement extended (64-bit) sequence numbers for ESPv2 (and ESPv3, if supported) and SHOULD use extended sequence numbers for all block storage protocol traffic. Extended sequence number negotiation as part of security association establishment is specified in [RFC4304] for IKEv1 and [RFC5996] for IKEv2.
ブロックストレージプロトコルが動作すると予想される高速では、単一のIPsecセキュリティアソシエーション（SA）がESP 32ビットシーケンス番号スペースを急速に使い果たし、SA内でのESPシーケンス番号のロールオーバーとして、SAの頻繁な再キーイングが必要になる場合があります。 ESPv2 [RFC2406]とESPv3 [RFC4303]の両方で単一のSAは禁止されています。この潜在的に望ましくない頻繁なキー更新を回避する手段を提供するために、1ギガビット/秒以上の速度で動作できる実装は、ESPv2（およびサポートされている場合はESPv3）の拡張（64ビット）シーケンス番号を実装する必要があり、SHOULDすべてのブロックストレージプロトコルトラフィックに拡張シーケンス番号を使用します。セキュリティアソシエーションの確立の一部としての拡張シーケンス番号ネゴシエーションは、IKEv1の[RFC4304]およびIKEv2の[RFC5996]で指定されています。
RFC 3723 requires that:
RFC 3723には次の要件があります。
o HMAC-SHA1 MUST be implemented in the form of HMAC-SHA-1-96 [RFC2404].
o HMAC-SHA1は、HMAC-SHA-1-96 [RFC2404]の形式で実装する必要があります。
o AES CBC MAC with XCBC extensions SHOULD be implemented [RFC3566].
o XCBC拡張機能を備えたAES CBC MACを実装する必要があります[RFC3566]。
This document clarifies RFC 3723's key-size requirements for implementations of AES CBC MAC with XCBC extensions; 128-bit keys MUST be supported, and other key sizes MAY also be supported.
このドキュメントでは、XCBC拡張を使用したAES CBC MACの実装に関するRFC 3723のキーサイズ要件を明確にします。 128ビットキーをサポートする必要があり、他のキーサイズもサポートする必要があります。
This document also adds a requirement for IPsec v3:
このドキュメントには、IPsec v3の要件も追加されています。
o Implementations that support IKEv2 [RFC5996] SHOULD also implement AES GMAC [RFC4543]. AES GMAC implementations MUST support 128-bit keys and MAY support other key sizes.
o IKEv2 [RFC5996]をサポートする実装は、AES GMAC [RFC4543]も実装する必要があります（SHOULD）。 AES GMAC実装は、128ビットキーをサポートする必要があり、他のキーサイズをサポートする場合があります。
The rationale for the added requirement is that GMAC is more amenable to hardware implementations that may be preferable for the high data rates at which block storage protocols can be expected to operate.
追加された要件の理論的根拠は、GMACが、ブロックストレージプロトコルが動作することが期待できる高いデータレートに適している可能性のあるハードウェア実装に、より従順であるということです。
RFC 3723 requires that:
RFC 3723には次の要件があります。
o 3DES in CBC mode (3DES CBC) [RFC2451] [triple-des-spec] MUST be supported.
o CBCモードの3DES（3DES CBC）[RFC2451] [triple-des-spec]をサポートする必要があります。
o AES in Counter mode (AES CTR) [RFC3686] SHOULD be supported.
o カウンターモードのAES（AES CTR）[RFC3686]をサポートする必要があります（SHOULD）。
o NULL encryption [RFC2410] MUST be supported.
o NULL暗号化[RFC2410]をサポートする必要があります。
The above requirements from RFC 3723 regarding 3DES CBC and AES CTR are replaced in this document by requirements that both 3DES CBC and AES CTR MAY be implemented. The NULL encryption requirement is not changed by this document. The 3DES CBC requirement matched the basic encryption interoperability requirement for IPsec v2. At the time of RFC 3723's publication, AES in Counter mode was the encryption transform that was most amenable to hardware implementation, as hardware implementation may be preferable for the high data rates at which block storage protocols can be expected to operate. This document changes both of these requirements, based on cryptographic developments since the publication of RFC 3723.
3DES CBCとAES CTRに関するRFC 3723の上記の要件は、このドキュメントでは、3DES CBCとAES CTRの両方が実装される可能性があるという要件に置き換えられています。このドキュメントでは、NULL暗号化の要件は変更されていません。 3DES CBC要件は、IPsec v2の基本的な暗号化相互運用性要件と一致しました。 RFC 3723の公開時点では、ブロックモードのAESは、ハードウェアの実装に最も適している暗号化トランスフォームでした。ハードウェアの実装は、ブロックストレージプロトコルの動作が期待できる高いデータレートに適しているためです。このドキュメントは、RFC 3723の発行以降の暗号の発展に基づいて、これらの要件の両方を変更します。
The requirement for 3DES CBC has become problematic due to 3DES's 64-bit block size; i.e., the core cipher encrypts or decrypts 64 bits at a time. Security weaknesses in encryption start to appear as the amount of data encrypted under a single key approaches the birthday bound of 32 GiB (gibibytes) for a cipher with a 64-bit block size; see Appendix A and [triple-des-birthday]. It is prudent to rekey well before that bound is reached, and 32 GiB or some significant fraction thereof is less than the amount of data that a block storage protocol may transfer in a single session. This may require frequent rekeying, e.g., to obtain an order-of-magnitude (10x) safety margin by rekeying after 3 GiB on a multi-gigabit/sec link. In contrast, AES has a 128-bit block size, which results in a much larger birthday bound (2^68 bytes); see Appendix A. AES CBC [RFC3602] is the primary mandatory-to-implement encryption transform for interoperability and hence is the appropriate mandatory-to-implement transform replacement for 3DES CBC.
3DESの64ビットブロックサイズのため、3DES CBCの要件は問題になっています。つまり、コア暗号は一度に64ビットを暗号化または復号化します。単一のキーで暗号化されたデータの量が64ビットブロックサイズの暗号の誕生日の境界である32 GiB（ギビバイト）に近づくと、暗号化のセキュリティ上の弱点が現れ始めます。付録Aおよび[triple-des-birthday]を参照してください。その限界に達する前に鍵を再生成することは賢明であり、32 GiBまたはそのかなりの割合は、ブロックストレージプロトコルが単一のセッションで転送するデータ量よりも少ないです。これには、たとえば、マルチギガビット/秒のリンクで3 GiBの後でキーを再生成することにより、桁違い（10x）の安全マージンを取得するために、頻繁な再キーが必要になる場合があります。対照的に、AESのブロックサイズは128ビットであり、誕生日の境界がはるかに大きくなります（2 ^ 68バイト）。付録Aを参照してください。AESCBC [RFC3602]は、相互運用性のための主要な必須から実装への暗号化トランスフォームであり、3DES CBCに代わる必須から実装への適切なトランスフォームです。
AES in Counter mode (AES CTR) is no longer the encryption transform that is most amenable to hardware implementation. That characterization now applies to AES GCM [RFC4106], which provides both encryption and integrity protection in a single cryptographic mechanism (in contrast, neither HMAC-SHA1 nor AES CBC MAC with XCBC extensions is well suited for hardware implementation, as both transforms do not pipeline well). AES GCM is also capable of providing confidentiality protection for the IKEv2 key exchange protocol, but not the IKEv1 protocol [RFC5282], and therefore the new AES GCM "SHOULD" requirement is based on the presence of support for IKEv2.
カウンターモードのAES（AES CTR）は、ハードウェア実装に最も適している暗号化変換ではなくなりました。この特性は、AES GCM [RFC4106]に適用されます。これは、単一の暗号化メカニズムで暗号化と整合性保護の両方を提供します（対照的に、HMAC-SHA1もXCBC拡張を備えたAES CBC MACも、ハードウェア実装には適していません。よくパイプライン）。 AES GCMは、IKEv2キー交換プロトコルの機密保護も提供できますが、IKEv1プロトコル[RFC5282]は提供できません。したがって、新しいAES GCMの「SHOULD」要件は、IKEv2のサポートの存在に基づいています。
For the reasons described in the preceding paragraphs, the confidentiality transform requirements in RFC 3723 are replaced by the following:
前の段落で説明した理由により、RFC 3723の機密性変換要件は次のように置き換えられます。
o 3DES in CBC mode MAY be implemented (replaces RFC 3723's "MUST implement" requirement).
o CBCモードの3DESが実装される場合があります（RFC 3723の「MUST implement」の要件を置き換えます）。
o AES in Counter mode (AES CTR) MAY be implemented (replaces RFC 3723's "SHOULD implement" requirement).
o カウンターモードのAES（AES CTR）を実装できます（RFC 3723の「SHOULD実装」要件を置き換えます）。
o AES in CBC mode MUST be implemented. AES CBC implementations MUST support 128-bit keys and MAY support other key sizes.
o CBCモードのAESを実装する必要があります。 AES CBC実装は128ビットキーをサポートする必要があり、他のキーサイズをサポートする場合があります（MAY）。
o Implementations that support IKEv2 SHOULD also implement AES GCM. AES GCM implementations MUST support 128-bit keys and MAY support other key sizes.
o IKEv2をサポートする実装は、AES GCMも実装する必要があります（SHOULD）。 AES GCM実装は128ビットキーをサポートする必要があり、他のキーサイズをサポートする場合があります（MAY）。
o NULL encryption [RFC2410] MUST be supported.
o NULL暗号化[RFC2410]をサポートする必要があります。
The requirement for support of NULL encryption enables the use of SAs that provide data origin authentication and data integrity, but not confidentiality.
NULL暗号化のサポートの要件により、データ起源の認証とデータの整合性を提供し、機密性は提供しないSAの使用が可能になります。
Other transforms MAY be implemented in addition to those listed above.
上記にリストされたものに加えて、他の変換が実装されるかもしれません。
Note: To avoid ambiguity, the original IKE protocol [RFC2409] is referred to as "IKEv1" in this document.
注：あいまいさを避けるために、元のIKEプロトコル[RFC2409]は、このドキュメントでは「IKEv1」と呼ばれています。
This document adds requirements for IKEv2 usage with block storage protocols and makes the following two changes to the IKEv1 requirements in RFC 3723 (the new Diffie-Hellman (DH) group requirement also applies to IKEv2):
このドキュメントでは、ブロックストレージプロトコルでのIKEv2の使用に関する要件を追加し、RFC 3723のIKEv1要件に次の2つの変更を加えます（新しいDiffie-Hellman（DH）グループ要件もIKEv2に適用されます）。
o When DH groups are used, a DH group of at least 2048 bits SHOULD be offered as a part of all proposals to create IPsec security associations. The recommendation for the use of 1024-bit DH groups with 3DES CBC and HMAC-SHA1 has been removed; the use of 1024-bit DH groups is NOT RECOMMENDED, and
o DHグループを使用する場合、IPsecセキュリティアソシエーションを作成するすべての提案の一部として、少なくとも2048ビットのDHグループを提供する必要があります（SHOULD）。 3DES CBCおよびHMAC-SHA1での1024ビットDHグループの使用に関する推奨事項は削除されました。 1024ビットDHグループの使用は推奨されません。
o The requirement to use UDP port 500 is removed in order to allow NAT traversal [RFC3947].
o NATトラバーサル[RFC3947]を許可するために、UDPポート500を使用する必要がなくなりました。
There are no other changes to RFC 3723's IKEv1 requirements, but many of them are restated in this document in order to provide context for the new IKEv2 requirements.
RFC 3723のIKEv1要件には他の変更はありませんが、新しいIKEv2要件のコンテキストを提供するために、それらの多くはこのドキュメントで再説明されています。
RFC 3723 requires that IKEv1 [RFC2409] be supported for peer authentication, negotiation of security associations, and key management, using the IPsec domain of interpretation (DOI) [RFC2407], and further requires that manual keying not be used since it does not provide the rekeying support necessary for operation at high data rates. This document adds a requirement that IKEv2 [RFC5996] SHOULD be supported for peer authentication, negotiation of security associations, and key management. The prohibition of manual keying as stated in RFC 3723 is extended to IKEv2; manual keying MUST NOT be used with any version of IPsec for protocols to which the requirements in this document apply.
RFC 3723では、IKEv1 [RFC2409]がIPsecドメイン解釈（DOI）[RFC2407]を使用して、ピア認証、セキュリティアソシエーションのネゴシエーション、およびキー管理でサポートされている必要があります。さらに、高いデータレートでの操作に必要なキー更新サポート。このドキュメントは、IKEv2 [RFC5996]がピア認証、セキュリティアソシエーションのネゴシエーション、およびキー管理でサポートされる必要があるという要件を追加します。 RFC 3723で述べられている手動キーイングの禁止は、IKEv2に拡張されています。このドキュメントの要件が適用されるプロトコルのIPsecのどのバージョンでも、手動キーイングを使用してはなりません（MUST NOT）。
RFC 3723's requirements for IKEv1 mode implementation and usage are unchanged; this document does not extend those requirements to IKEv2 because IKEv2 does not have modes.
IKEv1モードの実装と使用に関するRFC 3723の要件は変更されていません。 IKEv2にはモードがないため、このドキュメントでは、これらの要件をIKEv2に拡張しません。
When IPsec is used, the receipt of an IKEv1 Phase 2 delete message or an IKEv2 INFORMATIONAL exchange that deletes the SA SHOULD NOT be interpreted as a reason for tearing down the block storage protocol connection (e.g., TCP-based). If additional traffic is sent, a new SA will be created to protect that traffic.
IPsecを使用している場合、IKEv1フェーズ2削除メッセージまたはSAを削除するIKEv2 INFORMATIONAL交換の受信は、ブロックストレージプロトコル接続（TCPベースなど）を破棄する理由として解釈されるべきではありません（SHOULD NOT）。追加のトラフィックが送信されると、そのトラフィックを保護するために新しいSAが作成されます。
The method used to determine whether a block storage protocol connection should be established using IPsec is regarded as an issue of IPsec policy administration and thus is not defined in this document. The method used by an implementation that supports both IPsec v2 and v3 to determine which versions of IPsec are supported by a block storage protocol peer is also regarded as an issue of IPsec policy administration and thus is also not defined in this document. If both IPsec v2 and v3 are supported by both endpoints of a block storage protocol connection, the use of IPsec v3 is RECOMMENDED.
IPsecを使用してブロックストレージプロトコル接続を確立する必要があるかどうかを判断するために使用される方法は、IPsecポリシー管理の問題と見なされるため、このドキュメントでは定義しません。 IPsec v2とv3の両方をサポートする実装で、ブロックストレージプロトコルピアがサポートするIPsecのバージョンを判別する方法もIPsecポリシー管理の問題と見なされるため、このドキュメントでも定義していません。 IPsec v2とv3の両方がブロックストレージプロトコル接続の両方のエンドポイントでサポートされている場合、IPsec v3の使用が推奨されます。
The authentication requirements for IKEv1 are unchanged by this document but are restated here for context, along with the authentication requirements for IKEv2:
IKEv1の認証要件はこのドキュメントでは変更されていませんが、IKEv2の認証要件とともに、ここではコンテキストについて再説明されています。
a. Peer authentication using a pre-shared cryptographic key MUST be supported. Certificate-based peer authentication using digital signatures MAY be supported. For IKEv1 [RFC2409], peer authentication using the public key encryption methods specified in Sections 5.2 and 5.3 of [RFC2409] SHOULD NOT be used.
a。事前共有暗号化キーを使用したピア認証がサポートされている必要があります。デジタル署名を使用した証明書ベースのピア認証がサポートされる場合があります。 IKEv1 [RFC2409]の場合、[RFC2409]のセクション5.2および5.3で指定されている公開鍵暗号化方式を使用したピア認証を使用してはなりません（SHOULD NOT）。
b. When digital signatures are used for authentication, all IKEv1 and IKEv2 negotiators SHOULD use Certificate Request Payload(s) to specify the certificate authority and SHOULD check the certificate validity via the pertinent Certificate Revocation List (CRL) or the use of the Online Certificate Status Protocol (OCSP) [RFC6960] before accepting a PKI certificate for use in authentication. OCSP support within the IKEv2 protocol is specified in [RFC4806].
b。認証にデジタル署名を使用する場合、すべてのIKEv1およびIKEv2ネゴシエーターは証明書要求ペイロードを使用して認証局を指定し、適切な証明書失効リスト（CRL）またはオンライン証明書ステータスプロトコルの使用を介して証明書の有効性を確認する必要があります（SHOULD）。 （OCSP）[RFC6960]認証で使用するPKI証明書を受け入れる前。 IKEv2プロトコル内のOCSPサポートは、[RFC4806]で指定されています。
c. IKEv1 implementations MUST support Main Mode and SHOULD support Aggressive Mode. Main Mode with the pre-shared key authentication method SHOULD NOT be used when either the initiator or the target uses dynamically assigned IP addresses. While in many cases pre-shared keys offer good security, situations in which dynamically assigned addresses are used force the use of a group pre-shared key, which creates vulnerability to a man-in-the-middle attack. These requirements do not apply to IKEv2 because it has no modes.
c。 IKEv1実装はメインモードをサポートする必要があり、アグレッシブモードをサポートする必要があります（SHOULD）。事前共有キー認証方式のメインモードは、イニシエーターまたはターゲットのいずれかが動的に割り当てられたIPアドレスを使用する場合は使用しないでください。多くの場合、事前共有キーは優れたセキュリティを提供しますが、動的に割り当てられたアドレスが使用される状況では、グループ事前共有キーが強制的に使用され、中間者攻撃に対する脆弱性が生じます。モードがないため、これらの要件はIKEv2には適用されません。
d. In the IKEv1 Phase 2 Quick Mode, in exchanges for creating the Phase 2 SA, the Identification Payload MUST be present. This requirement does not apply to IKEv2 because it has no modes.
d。 IKEv1フェーズ2クイックモードでは、フェーズ2 SAを作成する代わりに、識別ペイロードが存在する必要があります。モードがないため、この要件はIKEv2には適用されません。
e. The following identification type requirements apply to IKEv1. ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), and ID_FQDN Identification Types MUST be supported; ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types SHOULD NOT be used. The ID_KEY_ID Identification Type MUST NOT be used.
e。次の識別タイプ要件はIKEv1に適用されます。 ID_IPV4_ADDR、ID_IPV6_ADDR（プロトコルスタックがIPv6をサポートしている場合）、およびID_FQDN識別タイプをサポートする必要があります。 ID_USER_FQDNをサポートする必要があります（SHOULD）。 IPサブネット、IPアドレス範囲、ID_DER_ASN1_DN、およびID_DER_ASN1_GN識別タイプは使用しないでください。 ID_KEY_ID識別タイプは使用してはなりません（MUST NOT）。
f. When IKEv2 is supported, the following identification requirements apply. ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), and ID_FQDN Identification Types MUST be supported; ID_RFC822_ADDR SHOULD be supported. The ID_DER_ASN1_DN and ID_DER_ASN1_GN Identification Types SHOULD NOT be used. The ID_KEY_ID Identification Type MUST NOT be used.
f。 IKEv2がサポートされている場合、次の識別要件が適用されます。 ID_IPV4_ADDR、ID_IPV6_ADDR（プロトコルスタックがIPv6をサポートしている場合）、およびID_FQDN識別タイプをサポートする必要があります。 ID_RFC822_ADDRをサポートする必要があります（SHOULD）。 ID_DER_ASN1_DNおよびID_DER_ASN1_GN識別タイプは使用してはなりません（SHOULD NOT）。 ID_KEY_ID識別タイプは使用してはなりません（MUST NOT）。
The reasons for the identification requirements in items e and f above are as follows:
上記のeおよびfの識別要件の理由は次のとおりです。
o IP Subnet and IP Address Range are too broad to usefully identify an iSCSI endpoint.
o IPサブネットとIPアドレスの範囲が広すぎるため、iSCSIエンドポイントを効果的に識別できません。
o The _DN and _GN types are X.500 identities; it is usually better to use an identity from subjectAltName in a PKI certificate.
o _DNおよび_GNタイプはX.500 IDです。通常は、PKI証明書でsubjectAltNameのIDを使用する方が適切です。
o ID_KEY_ID is an opaque identifier that is not interoperable among different IPsec implementations as specified. Heterogeneity in some block storage protocol implementations can be expected (e.g., iSCSI initiator vs. iSCSI target implementations), and hence heterogeneity among IPsec implementations is important.
o ID_KEY_IDは、指定されたさまざまなIPsec実装間で相互運用できない不透明な識別子です。一部のブロックストレージプロトコルの実装には異質性が予想されるため（iSCSIイニシエーターとiSCSIターゲットの実装など）、IPsec実装間の異機種性が重要です。
This document does not change the support requirements for Diffie-Hellman (DH) groups and Pseudo-Random Functions (PRFs). See [RFC4109] for IKEv1 requirements and [RFC4307] for IKEv2 requirements. Implementers are advised to check for subsequent RFCs that update either of these RFCs, as such updates may change these requirements.
このドキュメントは、Diffie-Hellman（DH）グループおよび疑似ランダム関数（PRF）のサポート要件を変更しません。 IKEv1要件については[RFC4109]を、IKEv2要件については[RFC4307]を参照してください。実装者は、これらのRFCのいずれかを更新する後続のRFCをチェックすることをお勧めします。そのような更新はこれらの要件を変更する可能性があるためです。
When DH groups are used, a DH group of at least 2048 bits SHOULD be offered as a part of all proposals to create IPsec security associations for both IKEv1 and IKEv2.
DHグループを使用する場合、IKEv1とIKEv2の両方のIPsecセキュリティアソシエーションを作成するすべての提案の一部として、少なくとも2048ビットのDHグループを提供する必要があります（SHOULD）。
RFC 3723 requires that support for perfect forward secrecy in the IKEv1 Quick Mode key exchange MUST be implemented. This document extends that requirement to IKEv2; support for perfect forward secrecy in the CREATE_CHILD_SA key exchange MUST be implemented for the use of IPsec with block storage protocols.
RFC 3723では、IKEv1クイックモードキー交換での完全転送秘密のサポートを実装する必要があります。このドキュメントでは、その要件をIKEv2に拡張します。 CREATE_CHILD_SA鍵交換での完全転送秘密のサポートは、ブロックストレージプロトコルでIPsecを使用するために実装する必要があります。
This entire document is about security.
このドキュメント全体はセキュリティに関するものです。
The security considerations sections of all of the referenced RFCs apply, and particular note should be taken of the security considerations for the encryption transforms whose requirement levels are changed by this RFC:
参照されるすべてのRFCのセキュリティに関する考慮事項のセクションが適用され、このRFCによって要件レベルが変更される暗号化トランスフォームのセキュリティに関する考慮事項に特に注意する必要があります。
o AES GMAC [RFC4543] (new requirement -- SHOULD be supported when IKEv2 is supported),
o AES GMAC [RFC4543]（新しい要件-IKEv2がサポートされている場合はサポートする必要があります）、
o 3DES CBC [RFC2451] (changed from "MUST be supported" to "MAY be supported"),
o 3DES CBC [RFC2451]（「サポートする必要がある」から「サポートする可能性がある」に変更）、
o AES CTR [RFC3686] (changed from "SHOULD be supported" to "MAY be supported"),
o AES CTR [RFC3686]（「サポートする必要がある」から「サポートされる可能性がある」に変更）、
o AES CBC [RFC3602] (new requirement -- MUST be supported), and
o AES CBC [RFC3602]（新しい要件-サポートする必要があります）、および
o AES GCM [RFC4106] (new requirement -- SHOULD be supported when IKEv2 is supported).
o AES GCM [RFC4106]（新しい要件-IKEv2がサポートされている場合はサポートする必要があります）。
Of particular interest are the security considerations concerning the use of AES GCM [RFC4106] and AES GMAC [RFC4543]; both modes are vulnerable to catastrophic forgery attacks if a nonce is ever repeated with a given key.
特に興味深いのは、AES GCM [RFC4106]およびAES GMAC [RFC4543]の使用に関するセキュリティの考慮事項です。ナンスが特定のキーで繰り返される場合、どちらのモードも壊滅的な偽造攻撃に対して脆弱です。
The requirement level for 3DES CBC has been reduced, based on considerations for high-speed implementations; 3DES CBC remains an optional encryption transform that may be suitable for implementations limited to operating at lower speeds where the required rekeying frequency for 3DES is acceptable.
3DES CBCの要件レベルは、高速実装の考慮事項に基づいて削減されました。 3DES CBCはオプションの暗号化変換のままであり、3DESに必要な鍵の再生成頻度が許容される低速での動作に限定された実装に適している場合があります。
The requirement level for AES CTR has been reduced, based solely on hardware implementation considerations that favor AES GCM, as opposed to changes in AES CTR's security properties. AES CTR remains an optional security transform that is suitable for use in general, as it does not share 3DES CBC's requirement for frequent rekeying when operating at high data rates.
AES CTRのセキュリティプロパティの変更ではなく、AES GCMを支持するハードウェア実装の考慮事項のみに基づいて、AES CTRの要件レベルが削減されました。 AES CTRは、高いデータレートで動作する場合の頻繁なキー更新に関する3DES CBCの要件を共有しないため、一般的な使用に適したオプションのセキュリティトランスフォームのままです。
Key sizes with comparable strength SHOULD be used for the cryptographic algorithms and transforms for any individual IPsec security association. See Section 5.6 of [SP800-57] for further discussion.
同等の強度を持つキーサイズは、個々のIPsecセキュリティアソシエーションの暗号化アルゴリズムと変換に使用する必要があります（SHOULD）。詳細については、[SP800-57]のセクション5.6を参照してください。
[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月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S。、およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]マドソン、C。およびR.グレン、「ESPおよびAH内でのHMAC-SHA-1-96の使用」、RFC 2404、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S。、およびR.アトキンソン、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「インターネットキーエクスチェンジ（IKE）」、RFC 2409、1998年11月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410] Glenn、R。およびS. Kent、「NULL暗号化アルゴリズムとIPsecでのその使用」、RFC 2410、1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]フランケルS.およびH.ハーバート、「AES-XCBC-MAC-96アルゴリズムとIPsecでのその使用」、RFC 3566、2003年9月。
[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。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンターモードの使用」、RFC 3686、2004年1月。
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[RFC3720] Satran、J.、Meth、K.、Sapuntzakis、C.、Chadalapaka、M。、およびE. Zeidner、「Internet Small Computer Systems Interface（iSCSI）」、RFC 3720、2004年4月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723] Aboba、B.、Tseng、J.、Walker、J.、Rangan、V。、およびF. Travostino、「IP上のブロックストレージプロトコルの保護」、RFC 3723、2004年4月。
[RFC3821] Rajagopal, M., Rodriguez, E., and R. Weber, "Fibre Channel Over TCP/IP (FCIP)", RFC 3821, July 2004.
[RFC3821] Rajagopal、M.、Rodriguez、E。、およびR. Weber、「Fibre Channel Over TCP / IP（FCIP）」、RFC 3821、2004年7月。
[RFC3822] Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)", RFC 3822, July 2004.
[RFC3822] Peterson、D。、「Finding Fibre Channel over TCP / IP（FCIP）Entities Using Service Location Protocol version 2（SLPv2）」、RFC 3822、2004年7月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A。、およびV. Volpe、「IKEにおけるNATトラバーサルの交渉」、RFC 3947、2005年1月。
[RFC4018] Bakke, M., Hufferd, J., Voruganti, K., Krueger, M., and T. Sperry, "Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)", RFC 4018, April 2005.
[RFC4018] Bakke、M.、Hufferd、J.、Voruganti、K.、Krueger、M。、およびT. Sperry、「Finding Internet Small Computer Systems Interface（iSCSI）Targets and Name Servers Using Service Location Protocol version 2（ SLPv2）」、RFC 4018、2005年4月。
[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、「The Use of Galois / Counter Mode（GCM）in IPsec Encapsulating Security Payload（ESP）」、RFC 4106、2005年6月。
[RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version 1 (IKEv1)", RFC 4109, May 2005.
[RFC4109] Hoffman、P。、「Internet Key Exchange version 1（IKEv1）のアルゴリズム」、RFC 4109、2005年5月。
[RFC4172] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and M. Edwards, "iFCP - A Protocol for Internet Fibre Channel Storage Networking", RFC 4172, September 2005.
[RFC4172] Monia、C.、Mullendore、R.、Travostino、F.、Jeong、W。、およびM. Edwards、「iFCP-A Protocol for Internet Fibre Channel Storage Networking」、RFC 4172、2005年9月。
[RFC4173] Sarkar, P., Missimer, D., and C. Sapuntzakis, "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol", RFC 4173, September 2005.
[RFC4173] Sarkar、P.、Missimer、D。、およびC. Sapuntzakis、「インターネットスモールコンピュータシステムインターフェイス（iSCSI）プロトコルを使用したクライアントのブートストラップ」、RFC 4173、2005年9月。
[RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service", RFC 4174, September 2005.
[RFC4174]モニア、C.、Tseng、J。、およびK.ギボンズ、「インターネットストレージネームサービスのIPv4動的ホスト構成プロトコル（DHCP）オプション」、RFC 4174、2005年9月。
[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月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)", RFC 4304, December 2005.
[RFC4304]ケントS.、「インターネットセキュリティアソシエーションおよびキー管理プロトコル（ISAKMP）のIPsec解釈ドメイン（DOI）への拡張シーケンス番号（ESN）補遺」、RFC 4304、2005年12月。
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[RFC4307] Schiller、J。、「インターネットキーエクスチェンジバージョン2（IKEv2）で使用する暗号化アルゴリズム」、RFC 4307、2005年12月。
[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でのガロアメッセージ認証コード（GMAC）の使用」、RFC 4543、2006年5月。
[RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia, "A Remote Direct Memory Access Protocol Specification", RFC 5040, October 2007.
[RFC5040] Recio、R.、Metzler、B.、Culley、P.、Hilland、J。、およびD. Garcia、「A Remote Direct Memory Access Protocol Specification」、RFC 5040、2007年10月。
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[RFC5041] Shah、H.、Pinkerton、J.、Recio、R。、およびP. Culley、「Reliable Transportsを介した直接データ配置」、RFC 5041、2007年10月。
[RFC5042] Pinkerton, J. and E. Deleganes, "Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security", RFC 5042, October 2007.
[RFC5042] Pinkerton、J。およびE. Deleganes、「Direct Data Placement Protocol（DDP）/ Remote Direct Memory Access Protocol（RDMAP）Security」、RFC 5042、2007年10月。
[RFC5043] Bestler, C. and R. Stewart, "Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation", RFC 5043, October 2007.
[RFC5043] Bestler、C。およびR. Stewart、「Stream Control Transmission Protocol（SCTP）Direct Data Placement（DDP）Adaptation」、RFC 5043、2007年10月。
[RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. Carrier, "Marker PDU Aligned Framing for TCP Specification", RFC 5044, October 2007.
[RFC5044] Culley、P.、Elzur、U.、Recio、R.、Bailey、S。、およびJ. Carrier、「Marker PDU Aligned Framing for TCP Specification」、RFC 5044、2007年10月。
[RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)", RFC 5046, October 2007.
[RFC5046] Ko、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、Shah、H。、およびP. Thaler、「リモートダイレクトメモリアクセス（RDMA）用のInternet Small Computer System Interface（iSCSI）拡張機能） "、RFC 5046、2007年10月。
[RFC5048] Chadalapaka, M., "Internet Small Computer System Interface (iSCSI) Corrections and Clarifications", RFC 5048, October 2007.
[RFC5048] Chadalapaka、M。、「インターネットスモールコンピュータシステムインターフェイス（iSCSI）の修正と明確化」、RFC 5048、2007年10月。
[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, August 2008.
[RFC5282] Black、D。、およびD. McGrew、「Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2（IKEv2）Protocol」、RFC 5282、2008年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキー交換プロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.
[RFC6960] Santesson、S.、Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、and C. Adams、 "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP"、RFC 6960、2013年6月。
[RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, April 2014.
[RFC7143] Chadalapaka、M.、Satran、J.、Meth、K。、およびD. Black、「インターネットスモールコンピュータシステムインターフェイス（iSCSI）プロトコル（統合）」、RFC 7143、2014年4月。
[RFC7145] Ko, M. and A. Nezhinsky, "Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification", RFC 7145, April 2014.
[RFC7145] Ko、M。、およびA. Nezhinsky、「リモートダイレクトメモリアクセス（RDMA）仕様のためのインターネットスモールコンピューターシステムインターフェイス（iSCSI）拡張」、RFC 7145、2014年4月。
[SP800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "NIST Special Publication 800-57: Recommendation for Key Management - Part 1: General (Revision 3)", July 2012, <http://csrc.nist.gov/publications/nistpubs/800-57/ sp800-57_part1_rev3_general.pdf>.
[SP800-57] Barker、E.、Barker、W.、Burr、W.、Polk、W。、およびM. Smid、「NIST Special Publication 800-57：Recommendation for Key Management-Part 1：General（Revision 3 ）」、2012年7月、<http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf>。
[triple-des-birthday] McGrew, D., "Impossible plaintext cryptanalysis and probable-plaintext collision attacks of 64-bit block cipher modes (Cryptology ePrint Archive: Report 2012/ 623)", November 2012, <http://eprint.iacr.org/2012/623>.
[triple-des-birthday] McGrew、D。、「64ビットブロック暗号モードの不可能な平文暗号解読および平文衝突の可能性がある攻撃（Cryptology ePrint Archive：Report 2012/623）」、2012年11月、<http：// eprint .iacr.org / 2012/623>。
[triple-des-spec] American Bankers Association (ABA), "American National Standard for Financial Services X9.52-1998 - Triple Data Encryption Algorithm Modes of Operation", July 1998.
[triple-des-spec] American Bankers Association（ABA）、「American National Standard for Financial Services X9.52-1998-Triple Data Encryption Algorithm Modes of Operation」、1998年7月。
[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004.
[RFC3721] Bakke、M.、Hafner、J.、Hufferd、J.、Voruganti、K。、およびM. Krueger、「Internet Small Computer Systems Interface（iSCSI）Naming and Discovery」、RFC 3721、2004年4月。
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007.
[RFC4806] Myers、M。およびH. Tschofenig、「IKEv2へのオンライン証明書ステータスプロトコル（OCSP）拡張」、RFC 4806、2007年2月。
[RFC5045] Bestler, C. and L. Coene, "Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)", RFC 5045, October 2007.
[RFC5045] Bestler、C。およびL. Coene、「Remote Direct Memory Access Protocol（RDMA）and Direct Data Placement（DDP）の適用性」、RFC 5045、2007年10月。
[RFC5047] Chadalapaka, M., Hufferd, J., Satran, J., and H. Shah, "DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI)", RFC 5047, October 2007.
[RFC5047] Chadalapaka、M.、Hufferd、J.、Satran、J。、およびH. Shah、「DA：Datamover Architecture for the Internet Small Computer System Interface（iSCSI）」、RFC 5047、2007年10月。
[RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", RFC 5387, November 2008.
[RFC5387] Touch、J.、Black、D。、およびY. Wang、「Better-Than-Nothing Security（BTNS）の問題と適用性に関する声明」、RFC 5387、2008年11月。
This appendix provides the birthday bounds for the 3DES and AES ciphers based on [triple-des-birthday], which states: "Theory advises against using a w-bit block cipher to encrypt more than 2^(w/2) blocks with a single key; this is known as the birthday bound".
この付録では、[triple-des-birthday]に基づく3DES暗号とAES暗号の誕生日の境界を示し、「理論では、wビットブロック暗号を使用して、2 ^（w / 2）ブロック以上を単一のキー。これは誕生日の境界として知られています。」
For a cipher with a 64-bit block size (e.g., 3DES), w = 64, so the birthday bound is 2^32 blocks. As each block contains 8 (2^3) bytes, the birthday bound is 2^35 bytes = 2^5 gibibytes, i.e., 32 GiB, where 1 gibibyte (GiB) = 2^30 bytes. Note that a gigabyte (decimal quantity) is not the same as a gibibyte (binary quantity); 1 gigabyte (GB) = 10^6 bytes.
64ビットブロックサイズ（3DESなど）の暗号の場合、w = 64なので、誕生日の境界は2 ^ 32ブロックです。各ブロックには8（2 ^ 3）バイトが含まれているため、誕生日の境界は2 ^ 35バイト= 2 ^ 5ギビバイト、つまり32 GiBで、1ギビバイト（GiB）= 2 ^ 30バイトです。ギガバイト（10進数）はギビバイト（2進数）と同じではないことに注意してください。 1ギガバイト（GB）= 10 ^ 6バイト。
For a cipher with a 128-bit block size (e.g., AES), w = 128, so the birthday bound is 2^64 blocks. As each block contains 16 (2^4) bytes, the birthday bound is 2^68 bytes = 2^8 exbibytes, i.e., 256 EiB, where 1 exbibyte (EiB) = 2^60 bytes. Note that an exabyte (decimal quantity) is not the same as an exbibyte (binary quantity); 1 exabyte (EB) = 10^9 bytes.
128ビットブロックサイズの暗号（AESなど）の場合、w = 128なので、誕生日の境界は2 ^ 64ブロックです。各ブロックには16（2 ^ 4）バイトが含まれているため、誕生日の境界は2 ^ 68バイト= 2 ^ 8エクスビバイト、つまり256 EiBであり、1エクスビバイト（EiB）= 2 ^ 60バイトです。エクサバイト（10進数）はエクシバイト（2進数）と同じではないことに注意してください。 1エクサバイト（EB）= 10 ^ 9バイト。
David McGrew's observations about the birthday bound implications of 3DES's 64-bit block size on the ipsec@ietf.org mailing list led to changing from 3DES CBC to AES CBC as the mandatory-to-implement encryption algorithm, based on the birthday bound discussion in Appendix A.
ipsec@ietf.orgメーリングリストでの3DESの64ビットブロックサイズの誕生日の影響についてのDavid McGrewの観察は、必須の暗号化アルゴリズムとして、3DES CBCからAES CBCへの変更をもたらしました。付録A
The original authors of RFC 3723 were Bernard Aboba, Joshua Tseng, Jesse Walker, Venkat Rangan, and Franco Travostino. Comments from Francis Dupont, Yaron Sheffer, Tom Talpey, Sean Turner, and Tom Yu have improved this document and are gratefully acknowledged.
RFC 3723の最初の作成者は、Bernard Aboba、Joshua Tseng、Jesse Walker、Venkat Rangan、およびFranco Travostinoでした。 Francis Dupont、Yaron Sheffer、Tom Talpey、Sean Turner、Tom Yuからのコメントにより、このドキュメントが改善され、感謝されます。
Authors' Addresses
著者のアドレス
David L. Black EMC Corporation 176 South St. Hopkinton, MA 01748 USA
David L. Black EMC Corporation 176 South St. Hopkinton、MA 01748 USA
Phone: +1 508 293-7953
EMail: david.black@emc.com
Paul Koning Dell 300 Innovative Way Nashua, NH 03062 USA
Paul Koning Dell 300 Innovative Way Nashua、NH 03062 USA
Phone: +1 603 249-7703
EMail: paul_koning@Dell.com