[要約] RFC 7321は、ESPとAHの暗号アルゴリズムの実装要件と使用ガイダンスに関するものです。その目的は、ネットワークセキュリティプロトコルの実装者に対して、適切な暗号アルゴリズムの選択と使用方法に関する指針を提供することです。
Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 7321 Cisco Systems
Obsoletes: 4835 P. Hoffman
Category: Standards Track VPN Consortium
ISSN: 2070-1721 August 2014
Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
暗号化アルゴリズムの実装要件とセキュリティペイロード（ESP）および認証ヘッダー（AH）のカプセル化に関する使用ガイダンス
Abstract
概要
This document updates the Cryptographic Algorithm Implementation Requirements for the Encapsulating Security Payload (ESP) and Authentication Header (AH). It also adds usage guidance to help in the selection of these algorithms.
このドキュメントでは、カプセル化セキュリティペイロード（ESP）および認証ヘッダー（AH）の暗号化アルゴリズムの実装要件を更新します。また、これらのアルゴリズムの選択に役立つ使用方法のガイダンスを追加します。
ESP and AH protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to-implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms.
ESPおよびAHプロトコルは、さまざまな暗号化アルゴリズムを利用して、IPセキュリティ（IPsec）アーキテクチャで保護されたデータ通信に機密性および/またはデータ発信元認証を提供します。異種の実装間の相互運用性を確保するために、IPsec標準では、実装に必須の一連のアルゴリズムを指定しています。このドキュメントでは、ESPおよびAHの実装に必須のアルゴリズムの現在のセットを指定し、将来的には必須に昇格する可能性があるため実装する必要のあるアルゴリズムを指定し、一部の古いアルゴリズムの実装を推奨しません。 ESPとAHのユーザーが暗号化アルゴリズムを適切に選択することでセキュリティ目標を最もよく達成できるように、使用方法のガイダンスも提供されています。
This document obsoletes RFC 4835.
このドキュメントはRFC 4835を廃止します。
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/rfc7321.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7321で入手できます。
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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Implementation Requirements . . . . . . . . . . . . . . . . . 4
2.1. ESP Authenticated Encryption (Combined Mode Algorithms) . 4
2.2. ESP Encryption Algorithms . . . . . . . . . . . . . . . . 4
2.3. ESP Authentication Algorithms . . . . . . . . . . . . . . 5
2.4. AH Authentication Algorithms . . . . . . . . . . . . . . 5
2.5. Summary of Changes from RFC 4835 . . . . . . . . . . . . 5
3. Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . 5
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authenticated Encryption . . . . . . . . . . . . . . . . 7
4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 7
4.3. Authentication Transforms . . . . . . . . . . . . . . . . 7
5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
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]を介して送信されるデータに暗号保護を適用するためのメカニズムです。
To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms. This ensures that there is at least one algorithm that all implementations will have in common. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of mechanisms.
異種の実装間の相互運用性を確保するには、実装に必須のアルゴリズムのセットを指定する必要があります。これにより、すべての実装に共通のアルゴリズムが少なくとも1つあることが保証されます。このドキュメントでは、ESPおよびAHの実装に必須のアルゴリズムの現在のセットを指定し、将来的には必須に昇格する可能性があるため実装する必要のあるアルゴリズムを指定し、一部の古いアルゴリズムの実装を推奨しません。 ESPとAHのユーザーが適切なメカニズムを選択することでセキュリティ目標を最もよく達成できるように、使用方法のガイダンスも提供されています。
The nature of cryptography is that new algorithms surface continuously and existing algorithms are continuously attacked. An algorithm believed to be strong today may be demonstrated to be weak tomorrow. Given this, the choice of mandatory-to-implement algorithm should be conservative so as to minimize the likelihood of it being compromised quickly. Thought should also be given to performance considerations, as many uses of IPsec will be in environments where performance is a concern.
暗号化の性質は、新しいアルゴリズムが継続的に表面化し、既存のアルゴリズムが継続的に攻撃されることです。今日強力であると考えられているアルゴリズムは、明日は弱いことが示される場合があります。このことを考えると、実装から実装への必須アルゴリズムの選択は、それがすぐに危険にさらされる可能性を最小限に抑えるために控えめにする必要があります。 IPsecの多くの使用は、パフォーマンスが懸念される環境で行われるため、パフォーマンスの考慮事項も考慮する必要があります。
The ESP and AH mandatory-to-implement algorithm(s) may need to change over time to adapt to new developments in cryptography. For this reason, the specification of the mandatory-to-implement algorithms is not included in the main IPsec, ESP, or AH specifications, but is instead placed in this document. Ideally, the mandatory-to-implement algorithm of tomorrow should already be available in most implementations of IPsec by the time it is made mandatory. To facilitate this, this document identifies such algorithms, as they are known today. There is no guarantee that the algorithms that we predict will be mandatory in the future will actually be so. All algorithms known today are subject to cryptographic attack and may be broken in the future.
ESPおよびAHの実装に必須のアルゴリズムは、暗号化の新しい開発に適応するために、時間とともに変化する必要がある場合があります。このため、必須から実装までのアルゴリズムの仕様は、メインのIPsec、ESP、またはAH仕様には含まれていませんが、代わりにこのドキュメントに記載されています。理想的には、明日の必須から実装までのアルゴリズムは、IPsecのほとんどの実装で、それが必須になるまでにすでに利用可能であるはずです。これを容易にするために、このドキュメントでは、今日知られているようなアルゴリズムを特定します。私たちが将来必須であると予測するアルゴリズムが実際に必須であるという保証はありません。今日知られているすべてのアルゴリズムは、暗号攻撃の対象であり、将来は破壊される可能性があります。
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]で説明されているように解釈されます。
We define some additional keywords here:
ここでいくつかの追加キーワードを定義します。
MUST- This term means the same as MUST. However, we expect that at some point in the future this algorithm will no longer be a MUST.
MUST-この用語は、MUSTと同じことを意味します。ただし、将来的にこのアルゴリズムは必須ではなくなると予想されます。
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 +この用語は、SHOULDと同じことを意味します。ただし、SHOULD +としてマークされたアルゴリズムは、将来的には、MUSTになるようにプロモートされる可能性があります。
This section specifies the cryptographic algorithms that MUST be implemented, and provides guidance about ones that SHOULD or SHOULD NOT be implemented.
このセクションでは、実装する必要がある暗号化アルゴリズムを指定し、実装する必要がある、または実装してはならないアルゴリズムについてのガイダンスを提供します。
In the following sections, all AES modes are for 128-bit AES. 192-bit and 256-bit AES MAY be supported for those modes, but the requirements here are for 128-bit AES.
以下のセクションでは、すべてのAESモードは128ビットAES向けです。これらのモードでは、192ビットおよび256ビットのAESがサポートされる場合がありますが、ここでの要件は128ビットAESに対するものです。
ESP combined mode algorithms provide both confidentiality and authentication services; in cryptographic terms, these are authenticated encryption algorithms [RFC5116]. Authenticated encryption transforms are listed in the ESP encryption transforms IANA registry.
ESP複合モードアルゴリズムは、機密性と認証サービスの両方を提供します。暗号化の用語では、これらは認証された暗号化アルゴリズムです[RFC5116]。認証された暗号化トランスフォームは、ESP暗号化トランスフォームIANAレジストリにリストされています。
Requirement Authenticated Encryption Algorithm
----------- ----------------------------------
SHOULD+ AES-GCM with a 16 octet ICV [RFC4106]
MAY AES-CCM [RFC4309]
Requirement Encryption Algorithm
----------- --------------------------
MUST NULL [RFC2410]
MUST AES-CBC [RFC3602]
MAY AES-CTR [RFC3686]
MAY TripleDES-CBC [RFC2451]
MUST NOT DES-CBC [RFC2405]
Requirement Authentication Algorithm (notes)
----------- -----------------------------
MUST HMAC-SHA1-96 [RFC2404]
SHOULD+ AES-GMAC with AES-128 [RFC4543]
SHOULD AES-XCBC-MAC-96 [RFC3566]
MAY NULL [RFC4303]
Note that the requirement level for NULL authentication depends on the type of encryption used. When using authenticated encryption from Section 2.1, the requirement for NULL encryption is the same as the requirement for the authenticated encryption itself. When using the encryption from Section 2.2, the requirement for NULL encryption is truly "MAY"; see Section 3 for more detail.
NULL認証の要件レベルは、使用する暗号化のタイプによって異なることに注意してください。セクション2.1の認証済み暗号化を使用する場合、NULL暗号化の要件は認証済み暗号化自体の要件と同じです。セクション2.2の暗号化を使用する場合、NULL暗号化の要件は真に「MAY」です。詳細については、セクション3を参照してください。
The requirements for AH are the same as for ESP Authentication Algorithms, except that NULL authentication is inapplicable.
AHの要件は、NULL認証が適用できないことを除いて、ESP認証アルゴリズムの要件と同じです。
The following is a summary of the changes from RFC 4835.
以下は、RFC 4835からの変更点の要約です。
Old New
Requirement Requirement Algorithm (notes)
---- ----------- -----------------
MAY SHOULD+ AES-GCM with a 16 octet ICV [RFC4106]
MAY SHOULD+ AES-GMAC with AES-128 [RFC4543]
MUST- MAY TripleDES-CBC [RFC2451]
SHOULD NOT MUST NOT DES-CBC [RFC2405]
SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566]
SHOULD MAY AES-CTR [RFC3686]
Since ESP and AH can be used in several different ways, this document provides guidance on the best way to utilize these mechanisms.
ESPとAHはいくつかの異なる方法で使用できるため、このドキュメントでは、これらのメカニズムを利用するための最良の方法に関するガイダンスを提供します。
ESP can provide confidentiality, data origin authentication, or the combination of both of those security services. AH provides only data origin authentication. Background information on those security services is available [RFC4949]. In the following, we shorten "data origin authentication" to "authentication".
ESPは、機密性、データ発信元認証、またはそれら両方のセキュリティサービスの組み合わせを提供できます。 AHはデータ発信元認証のみを提供します。これらのセキュリティサービスに関する背景情報が利用可能です[RFC4949]。以下では、「データ発信元認証」を「認証」に短縮します。
Providing both confidentiality and authentication offers the best security. If confidentiality is not needed, providing authentication can still be useful. Confidentiality without authentication is not effective [DP07] and therefore SHOULD NOT be used. We describe each of these cases in more detail below.
機密性と認証の両方を提供すると、最高のセキュリティが提供されます。機密性が必要ない場合でも、認証を提供することは有用です。認証なしの機密性は効果的ではありません[DP07]したがって、使用すべきではありません。これらの各ケースについて、以下で詳しく説明します。
To provide both confidentiality and authentication, an authenticated encryption transform from Section 2.1 SHOULD be used in ESP, in conjunction with NULL authentication. Alternatively, an ESP encryption transform and ESP authentication transform MAY be used together. It is NOT RECOMMENDED to use ESP with NULL authentication in conjunction with AH; some configurations of this combination of services have been shown to be insecure [PD10].
機密性と認証の両方を提供するには、セクション2.1の認証済み暗号化トランスフォームをNULL認証と組み合わせてESPで使用する必要があります（SHOULD）。あるいは、ESP暗号化トランスフォームとESP認証トランスフォームを一緒に使用することもできます。 AHと組み合わせてNULL認証でESPを使用することはお勧めしません。このサービスの組み合わせの一部の構成は、安全でないことが示されています[PD10]。
To provide authentication without confidentiality, an authentication transform MUST be used in either ESP or AH. The IPsec community generally prefers ESP with NULL encryption over AH. AH is still required in some protocols and operational environments when there are security-sensitive options in the IP header, such as source routing headers; ESP inherently cannot protect those IP options. It is not possible to provide effective confidentiality without authentication, because the lack of authentication undermines the trustworthiness of encryption [B96][V02]. Therefore, an encryption transform MUST NOT be used with a NULL authentication transform (unless the encryption transform is an authenticated encryption transform from Section 2.1).
機密性なしで認証を提供するには、ESPまたはAHのいずれかで認証変換を使用する必要があります。 IPsecコミュニティは一般に、AHよりもNULL暗号化のESPを優先します。ソースルーティングヘッダーなど、IPヘッダーにセキュリティの影響を受けやすいオプションがある場合、一部のプロトコルおよび運用環境ではAHが依然として必要です。 ESPは本質的にこれらのIPオプションを保護できません。認証がないと暗号化の信頼性が損なわれるため、認証なしでは効果的な機密性を提供することはできません[B96] [V02]。したがって、暗号化トランスフォームをNULL認証トランスフォームと一緒に使用してはなりません（暗号化トランスフォームがセクション2.1の認証済み暗号化トランスフォームである場合を除く）。
Triple-DES SHOULD NOT be used in any scenario in which multiple gigabytes of data will be encrypted with a single key. As a 64-bit block cipher, it leaks information about plaintexts above that "birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement for the sake of backwards compatibility, but its use is discouraged.
Triple-DESは、複数のギガバイトのデータが単一のキーで暗号化されるシナリオでは使用しないでください。 64ビットのブロック暗号として、「誕生日の境界」[M13]を超えるプレーンテキストに関する情報を漏らします。 Triple-DES CBCは、下位互換性のためにMAY実装としてリストされていますが、その使用はお勧めしません。
This section explains the principles behind the implementation requirements described above.
このセクションでは、上記の実装要件の背後にある原則について説明します。
The algorithms listed as "MAY implement" are not meant to be endorsed over other non-standard alternatives. All of the algorithms that appeared in [RFC4835] are included in this document, for the sake of continuity. In some cases, these algorithms have moved from being "SHOULD implement" to "MAY implement".
「実装可能」としてリストされているアルゴリズムは、他の非標準の代替手段を推奨することを意図したものではありません。 [RFC4835]に登場したすべてのアルゴリズムは、継続性のためにこのドキュメントに含まれています。場合によっては、これらのアルゴリズムは「実装する必要がある」から「実装する可能性がある」に移行しています。
This document encourages the use of authenticated encryption algorithms because they can provide significant efficiency and throughput advantages, and the tight binding between authentication and encryption can be a security advantage [RFC5116].
認証された暗号化アルゴリズムは、効率とスループットを大幅に向上させ、認証と暗号化の間の緊密な結合がセキュリティ上の利点となるため、このドキュメントはその使用を推奨します[RFC5116]。
AES-GCM [RFC4106] brings significant performance benefits [KKGEGD], has been incorporated into IPsec recommendations [RFC6379], and has emerged as the preferred authenticated encryption method in IPsec and other standards.
AES-GCM [RFC4106]は、パフォーマンス上の大きな利点[KKGEGD]をもたらし、IPsecの推奨事項[RFC6379]に組み込まれ、IPsecおよびその他の標準で推奨される認証済み暗号化方式として浮上しています。
Since ESP encryption is optional, support for the "NULL" algorithm is required to maintain consistency with the way services are negotiated. Note that while authentication and encryption can each be "NULL", they MUST NOT both be "NULL" [RFC4301] [H10].
ESP暗号化はオプションであるため、サービスのネゴシエーション方法との一貫性を維持するには、「NULL」アルゴリズムのサポートが必要です。認証と暗号化はそれぞれ「NULL」にすることができますが、両方が「NULL」であってはならないことに注意してください[RFC4301] [H10]。
AES Counter Mode (AES-CTR) is an efficient encryption method, but it provides no authentication capability. The AES-GCM authenticated encryption method has all of the advantages of AES-CTR, while also providing authentication. Thus, this document moves AES-CTR from a SHOULD to a MAY.
AESカウンターモード（AES-CTR）は効率的な暗号化方式ですが、認証機能はありません。 AES-GCMで認証された暗号化方式は、AES-CTRの利点をすべて備えながら、認証も提供します。したがって、このドキュメントはAES-CTRをSHOULDからMAYに移動します。
The Triple Data Encryption Standard (TDES) is obsolete because of its small block size; as with all 64-bit block ciphers, it SHOULD NOT be used to encrypt more than one gigabyte of data with a single key [M13]. Its key size is smaller than that of the Advanced Encryption Standard (AES), while at the same time its performance and efficiency are worse. Thus, its use in new implementations is discouraged.
Triple Data Encryption Standard（TDES）は、ブロックサイズが小さいため廃止されました。すべての64ビットブロック暗号と同様に、1つのキーで複数のギガバイトのデータを暗号化するために使用しないでください[M13]。鍵のサイズはAdvanced Encryption Standard（AES）のサイズよりも小さいですが、同時にそのパフォーマンスと効率は低下しています。したがって、新しい実装での使用はお勧めしません。
The Data Encryption Standard (DES) is obsolete because of its small key size and small block size. There have been publicly demonstrated and open-design special-purpose cracking hardware. Therefore, its use is has been changed to MUST NOT in this document.
データ暗号化標準（DES）は、鍵のサイズとブロックサイズが小さいため、廃止されました。公に実証されたオープン設計の特殊用途のクラッキングハードウェアがありました。したがって、その使用法はこのドキュメントでは変更してはなりません（MUST NOT）。
AES-GMAC provides good security along with performance advantages, even over HMAC-MD5. In addition, it uses the same internal components as AES-GCM and is easy to implement in a way that shares components with that authenticated encryption algorithm.
AES-GMACは、HMAC-MD5よりも優れたセキュリティとパフォーマンスの利点を提供します。さらに、AES-GCMと同じ内部コンポーネントを使用し、その認証された暗号化アルゴリズムとコンポーネントを共有する方法で実装するのは簡単です。
The MD5 hash function has been found to not meet its goal of collision resistance; it is so weak that its use in digital signatures is highly discouraged [RFC6151]. There have been theoretical results against HMAC-MD5, but that message authentication code does not seem to have a practical vulnerability. Thus, it may not be urgent to remove HMAC-MD5 from the existing protocols.
MD5ハッシュ関数は、耐衝突性という目標を満たさないことが判明しています。非常に弱いため、デジタル署名での使用は推奨されていません[RFC6151]。 HMAC-MD5に対する理論的な結果はありましたが、そのメッセージ認証コードには実際的な脆弱性はないようです。したがって、既存のプロトコルからHMAC-MD5を削除することが緊急ではない場合があります。
SHA-1 has been found to not meet its goal of collision resistance. However, HMAC-SHA-1 does not rely on this property, and HMAC-SHA-1 is believed to be secure.
SHA-1は、衝突抵抗という目標を達成していないことが判明しています。ただし、HMAC-SHA-1はこのプロパティに依存しておらず、HMAC-SHA-1は安全であると考えられています。
HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to provide a good security margin, and they perform adequately on many platforms. However, these algorithms are not recommended for implementation in this document, because HMAC-SHA-1 support is widespread and its security is good, AES-GMAC provides good security with better performance, and Authenticated Encryption algorithms do not need any authentication methods.
HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512は、優れたセキュリティマージンを提供すると考えられており、多くのプラットフォームで適切に動作します。ただし、これらのアルゴリズムは、HMAC-SHA-1のサポートが広く普及しており、セキュリティが優れているため、このドキュメントでの実装にはお勧めしません。AES-GMACは、優れたパフォーマンスと優れたセキュリティを提供し、Authenticated Encryptionアルゴリズムは認証方法を必要としません。
AES-XCBC has not seen widespread deployment, despite being previously recommended as a SHOULD+ in RFC 4835. Thus, this document lists it only as a SHOULD.
AES-XCBCは、RFC 4835でSHOULD +として以前推奨されていたにもかかわらず、広範囲に展開されていません。したがって、このドキュメントでは、SHOULDとしてのみリストしています。
When the AES cipher was first adopted, it was decided to continue encouraging the implementation of Triple-DES, in order to provide algorithm diversity. But the passage of time has eroded the viability of Triple-DES as an alternative to AES. As it is a 64-bit block cipher, its security is inadequate at high data rates (see Section 4.2). Its performance in software and Field-Programmable Gate Arrays (FPGAs) is considerably worse than that of AES. Since it would not be possible to use Triple-DES as an alternative to AES in high data rate environments, or in environments where its performance could not keep up the requirements, the rationale of retaining Triple-DES to provide algorithm diversity is disappearing. (Of course, this does not change the rationale of retaining Triple-DES in IPsec implementations for backwards compatibility.)
AES暗号が最初に採用されたとき、アルゴリズムの多様性を提供するために、Triple-DESの実装を引き続き奨励することが決定されました。しかし、時間の経過により、AESの代替としてのTriple-DESの実現可能性が損なわれました。これは64ビットのブロック暗号であるため、高いデータレートではセキュリティは不十分です（セクション4.2を参照）。ソフトウェアおよびフィールドプログラマブルゲートアレイ（FPGA）でのパフォーマンスは、AESのパフォーマンスよりもかなり劣ります。高データレート環境、またはパフォーマンスが要件を維持できない環境では、トリプルDESをAESの代替として使用することは不可能であるため、トリプルDESを保持してアルゴリズムの多様性を提供する根拠はなくなっています。 （もちろん、これは下位互換性のためにIPsec実装でTriple-DESを保持する根拠を変更しません。）
Recent discussions in the IETF have started considering how to make the selection of a different cipher that could provide algorithm diversity in IPsec and other IETF standards. That work is expected to take a long time and involve discussions among many participants and organizations.
IETFでの最近の議論では、IPsecおよびその他のIETF標準でアルゴリズムの多様性を提供できる別の暗号を選択する方法を検討し始めました。その作業には長い時間がかかり、多くの参加者や組織の間での議論が含まれることが予想されます。
It is important to bear in mind that it is very unlikely that an exploitable flaw will be found in AES (e.g., a flaw that required less than a terabyte of known plaintext, when AES is used in a conventional mode of operation). The only reason that algorithm diversity deserves any consideration is because there would be large problems if such a flaw were found.
悪用可能な欠陥がAESで見つかる可能性は非常に低いことを覚えておくことが重要です（たとえば、AESが従来の操作モードで使用されている場合、テラバイト未満の既知の平文を必要とする欠陥）。アルゴリズムの多様性が考慮に値する唯一の理由は、そのような欠陥が見つかった場合に大きな問題が発生するためです。
Some of the wording herein was adapted from [RFC4835], the document that this one obsoletes. That RFC itself borrows from earlier RFCs, notably RFC 4305 and 4307. RFC 4835, RFC 4305, and RFC 4307 were authored by Vishwas Manral, Donald Eastlake, and Jeffrey Schiller respectively.
ここでの表現の一部は、[RFC4835]（これが廃止されたという文書）から改作されたものです。そのRFC自体は、以前のRFC、特にRFC 4305および4307から借用しています。RFC4835、RFC 4305、およびRFC 4307は、それぞれVishwas Manral、Donald Eastlake、およびJeffrey Schillerによって作成されました。
Thanks are due to Wajdi Feghali, Brian Weis, Cheryl Madson, Dan Harkins, Paul Wouters, Ran Atkinson, Scott Fluhrer, Tero Kivinen, and Valery Smyslov for insightful feedback on this document.
このドキュメントに関する洞察に満ちたフィードバックを提供してくれたWajdi Feghali、Brian Weis、Cheryl Madson、Dan Harkins、Paul Wouters、Ran Atkinson、Scott Fluhrer、Valery Smyslovに感謝します。
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を使用するための暗号化アルゴリズムの選択、特に必須から実装へのアルゴリズムの選択に関係しています。このドキュメントで「実装する必要がある」または「実装する必要がある」と識別されたアルゴリズムは現時点では壊れていないことがわかっており、現在までの暗号研究により、当面はそれらが安全であり続けると思われます。ただし、これは必ずしも永遠ではありません。したがって、このドキュメントの改訂版は、この分野の現在のベストプラクティスを反映するために随時発行されることを期待しています。
[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月。
[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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[B96] Bellovin, S., "Problem areas for the IP security protocols", Proceedings of the Sixth Usenix Unix Security Symposium, 1996.
[B96] Bellovin、S。、「IPセキュリティプロトコルの問題領域」、Proceedings of the Sixth Usenix Unix Security Symposium、1996。
[DP07] Degabriele, J. and K. Paterson, "Attacking the IPsec Standards in Encryption-only Configurations", IEEE Symposium on Privacy and Security, 2007.
[DP07] Degabriele、J。およびK. Paterson、「暗号化のみの構成におけるIPsec標準の攻撃」、プライバシーおよびセキュリティに関するIEEEシンポジウム、2007年。
[H10] Hoban, A., "Using Intel AES New Instructions and PCLMULQDQ to Significantly Improve IPSec Performance on Linux", Intel White Paper, August 2010.
[H10] Hoban、A。、「Intel AES New InstructionsとPCLMULQDQを使用してLinuxのIPSecパフォーマンスを大幅に向上させる」、Intelホワイトペーパー、2010年8月。
[KKGEGD] Kounavis, M., Kang, X., Grewal, K., Eszenyi, M., Gueron, S., and D. Durham, "Encrypting the Internet", SIGCOMM, 2010.
[KKGEGD] Kounavis、M.、Kang、X.、Grewal、K.、Eszenyi、M.、Gueron、S。、およびD. Durham、「Encrypting the Internet」、SIGCOMM、2010。
[M13] McGrew, D., "Impossible plaintext cryptanalysis and probable-plaintext collision attacks of 64-bit block cipher modes", IACR ePrint, 2012.
[M13] McGrew、D。、「64ビットブロック暗号モードのあり得ない平文暗号解読およびありそうな平文衝突攻撃」、IACR ePrint、2012年。
[PD10] Paterson, K. and J. Degabriele, "On the (in)security of IPsec in MAC-then-encrypt configurations", CCS '10, ACM Conference on Computer and Communications Security, 2010.
[PD10] Paterson、K。およびJ. Degabriele、「MAC-then-encrypt構成におけるIPsecの（非）セキュリティについて」、CCS '10、コンピュータおよび通信セキュリティに関するACM会議、2010年。
[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月。
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405] Madson、C。およびN. Doraswamy、「明示的なIVを使用したESP DES-CBC暗号アルゴリズム」、RFC 2405、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月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106] Viega、J。およびD. McGrew、「IPsecカプセル化セキュリティペイロード（ESP）でのガロア/カウンターモード（GCM）の使用」、RFC 4106、2005年6月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309] Housley、R。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）CCMモードの使用」、RFC 4309、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月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835] Manral、V。、「カプセル化セキュリティペイロード（ESP）および認証ヘッダー（AH）の暗号化アルゴリズム実装要件」、RFC 4835、2007年4月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェイスとアルゴリズム」、RFC 5116、2008年1月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]ターナー、S。およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、2011年3月。
[RFC6379] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 6379, October 2011.
[RFC6379] Law、L。およびJ. Solinas、「Suite B Cryptographic Suites for IPsec」、RFC 6379、2011年10月。
[V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - Applications to SSL, IPSEC, WTLS ...", EUROCRYPT, 2002.
[V02] Vaudenay、S。、「CBCパディングによって引き起こされるセキュリティの欠陥-SSL、IPSEC、WTLSへのアプリケーション...」、EUROCRYPT、2002年。
Authors' Addresses
著者のアドレス
David McGrew Cisco Systems
David McGrew Cisco Systems
EMail: mcgrew@cisco.com
Paul Hoffman VPN Consortium
ポールホフマンVPNコンソーシアム
EMail: paul.hoffman@vpnc.org