RFC 4307 - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4307
タイトル : RFC 4307 - インターネットキーエクスチェンジバージョン2（IKEv2）で使用する暗号化アルゴリズム
翻訳編集 : 自動生成

[要約] RFC 4307は、IKEv2で使用するための暗号アルゴリズムについての仕様です。その目的は、IKEv2セッションのセキュリティを確保するために、適切な暗号アルゴリズムを提供することです。

Network Working Group                                        J. Schiller
Request for Comments: 4307         Massachusetts Institute of Technology
Category: Standards Track                                  December 2005

Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)

インターネットキーエクスチェンジバージョン2（IKEv2）で使用する暗号化アルゴリズム

Status of This Memo

本文書の状態

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time.

IPsecシリーズのプロトコルは、セキュリティサービスを提供するために、さまざまな暗号化アルゴリズムを利用しています。インターネットキー交換（IKE（RFC 2409）およびIKEv2）は、特定の関連付けで使用するアルゴリズムをネゴシエートするメカニズムを提供します。ただし、異種の実装間の相互運用性を保証するには、実装から実装までの一連のアルゴリズムを指定して、すべての実装で使用できるアルゴリズムが少なくとも1つあることを確認する必要があります。このドキュメントでは、IKEv2の一部として実装するために必須のアルゴリズムのセットと、将来的に必須に昇格する可能性があるため実装する必要のあるアルゴリズムを定義します。

1. Introduction

1. はじめに

The Internet Key Exchange protocol provides for the negotiation of cryptographic algorithms between both endpoints of a cryptographic

Internet Key Exchangeプロトコルは、暗号化の両方のエンドポイント間の暗号化アルゴリズムのネゴシエーションを提供します

association. Different implementations of IPsec and IKE may provide different algorithms. However, the IETF desires that all implementations should have some way to interoperate. In particular, this requires that IKE define a set of mandatory-to-implement algorithms because IKE itself uses such algorithms as part of its own negotiations. This requires that some set of algorithms be specified as "mandatory-to-implement" for IKE.

協会。 IPsecとIKEの実装が異なれば、提供されるアルゴリズムも異なります。ただし、IETFは、すべての実装に相互運用する方法が必要であることを望んでいます。特に、IKE自体が独自のネゴシエーションの一部としてそのようなアルゴリズムを使用するため、IKEでは、実装に必須のアルゴリズムのセットを定義する必要があります。これには、IKEの一部のアルゴリズムセットを「実装が必須」として指定する必要があります。

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の多くの使用はパフォーマンスが懸念される環境で行われるため、パフォーマンスの考慮事項にも配慮する必要があります。

Finally, we need to recognize that the mandatory-to-implement algorithm(s) 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 IKEv2 specification and placed in this document. As the choice of algorithm changes, only this document should need to be updated.

最後に、必須の実装アルゴリズムは、変化する世界に適応するために時間とともに変化する必要があるかもしれないことを認識する必要があります。このため、実装に必須のアルゴリズムの選択はメインのIKEv2仕様から削除され、このドキュメントに配置されました。アルゴリズムの選択が変わると、このドキュメントだけを更新する必要があります。

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, we will attempt to identify those algorithms (that are known today) in this document. There is no guarantee that the algorithms we believe today may be mandatory in the future will in fact become so. All algorithms known today are subject to cryptographic attack and may be broken in the future.

理想的には、明日の必須から実装までのアルゴリズムは、IPsecのほとんどの実装で、それが必須になるまでにすでに利用可能であるはずです。これを容易にするために、このドキュメントではこれらのアルゴリズム（今日知られているもの）を特定しようとします。今日、必須であると私たちが信じているアルゴリズムが実際に必須になるという保証はありません。今日知られているすべてのアルゴリズムは、暗号攻撃の対象であり、将来は破壊される可能性があります。

2. Requirements Terminology

2. 要件の用語

Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC2119].

このドキュメントに表示されるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHOULD」、「SHOULD NOT」、および「MAY」は、[RFC2119]で説明されているように解釈されます。

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 +この用語は、SHOULDと同じことを意味します。ただし、SHOULD +としてマークされたアルゴリズムは、将来的には、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.

SHOULD-この用語は、SHOULDと同じことを意味します。ただし、SHOULD-とマークされたアルゴリズムは、このドキュメントの将来のバージョンで非推奨になる可能性があります。

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

MUST-この用語は、MUSTと同じことを意味します。ただし、ある時点で、このアルゴリズムは将来のドキュメントでは必須ではなくなります。そのステータスは後で決定されますが、ドキュメントの将来のリビジョンがMUST-アルゴリズムのステータスを変更する場合、それは少なくともSHOULDまたはSHOULD-のままであることを期待するのは妥当です。

3. Algorithm Selection

3. アルゴリズムの選択

3.1. IKEv2 Algorithm Selection

3.1. IKEv2アルゴリズムの選択

3.1.1. Encrypted Payload Algorithms

3.1.1. 暗号化されたペイロードアルゴリズム

The IKEv2 Encrypted Payload requires both a confidentiality algorithm and an integrity algorithm. For confidentiality, implementations MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For integrity, HMAC-SHA1 MUST be implemented.

IKEv2暗号化ペイロードには、機密性アルゴリズムと整合性アルゴリズムの両方が必要です。機密保持のために、実装は3DES-CBCを実装する必要があり、AES-128-CBCを実装する必要があります。整合性のために、HMAC-SHA1を実装する必要があります。

3.1.2. Diffie-Hellman Groups

3.1.2. Diffie-Hellmanグループ

There are several Modular Exponential (MODP) groups that are defined for use in IKEv2. They are defined in both the [IKEv2] base document and in the MODP extensions document. They are identified by group number. Any groups not listed here are considered as "MAY be implemented".

IKEv2で使用するために定義されているいくつかのModular Exponential（MODP）グループがあります。これらは[IKEv2]ベースドキュメントとMODP拡張ドキュメントの両方で定義されています。グループ番号で識別されます。ここに記載されていないグループはすべて「実装可能」と見なされます。

Group Number Bit Length Status Defined 2 1024 MODP Group MUST- [RFC2409] 14 2048 MODP Group SHOULD+ [RFC3526]

グループ番号ビット長ステータス定義済み2 1024 MODPグループは必須[RFC2409] 14 2048 MODPグループSHOULD + [RFC3526]

3.1.3. IKEv2 Transform Type 1 Algorithms

3.1.3. IKEv2変換タイプ1アルゴリズム

IKEv2 defines several possible algorithms for Transfer Type 1 (encryption). These are defined below with their implementation status.

IKEv2は、転送タイプ1（暗号化）のいくつかの可能なアルゴリズムを定義します。これらは、実装ステータスとともに以下に定義されています。

Name Number Defined In Status RESERVED 0 ENCR_3DES 3 [RFC2451] MUST-ENCR_NULL 11 [RFC2410] MAY ENCR_AES_CBC 12 [AES-CBC] SHOULD+ ENCR_AES_CTR 13 [AES-CTR] SHOULD

名前番号ステータスで定義RESERVED 0 ENCR_3DES 3 [RFC2451] MUST-ENCR_NULL 11 [RFC2410] MAY ENCR_AES_CBC 12 [AES-CBC] SHOULD + ENCR_AES_CTR 13 [AES-CTR] SHOULD

3.1.4. IKEv2 Transform Type 2 Algorithms

3.1.4. IKEv2変換タイプ2アルゴリズム

Transfer Type 2 Algorithms are pseudo-random functions used to generate random values when needed.

転送タイプ2アルゴリズムは、必要に応じてランダムな値を生成するために使用される疑似ランダム関数です。

Name Number Defined In Status RESERVED 0 PRF_HMAC_MD5 1 [RFC2104] MAY PRF_HMAC_SHA1 2 [RFC2104] MUST PRF_AES128_CBC 4 [AESPRF] SHOULD+

名前ステータス定義済みRESERVED 0 PRF_HMAC_MD5 1 [RFC2104] MAY PRF_HMAC_SHA1 2 [RFC2104] MUST PRF_AES128_CBC 4 [AESPRF] SHOULD +

3.1.5. IKEv2 Transform Type 3 Algorithms

3.1.5. IKEv2変換タイプ3アルゴリズム

Transfer Type 3 Algorithms are Integrity algorithms used to protect data against tampering.

転送タイプ3アルゴリズムは、改ざんからデータを保護するために使用される整合性アルゴリズムです。

Name Number Defined In Status NONE 0 AUTH_HMAC_MD5_96 1 [RFC2403] MAY AUTH_HMAC_SHA1_96 2 [RFC2404] MUST AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+

名前番号定義済みステータスNONE 0 AUTH_HMAC_MD5_96 1 [RFC2403] MAY AUTH_HMAC_SHA1_96 2 [RFC2404] MUST AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD +

4. Security Considerations

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

The security of cryptographic-based systems 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 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 IKEv2, 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 so far leads us to believe that they will likely remain secure into the foreseeable future. However, this isn't necessarily forever. We would therefore expect that new revisions of this document will be issued from time to time that reflect the current best practice in this area.

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

5. Normative References

5. 引用文献

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

[RFC2409] Harkins、D.およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。

[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

[IKEv2] Kaufman、C。、編、「インターネットキーエクスチェンジ（IKEv2）プロトコル」、RFC 4306、2005年12月。

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

[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.

[RFC3526] Kivinen、T。、およびM. Kojo、「インターネット鍵交換（IKE）のためのより多くのモジュラー指数（MODP）Diffie-Hellmanグループ」、RFC 3526、2003年5月。

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

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

[AES-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.

[AES-CBC]フランケルS.、グレンR.、およびS.ケリー、「AES-CBC暗号アルゴリズムとIPsecでのその使用」、RFC 3602、2003年9月。

[AES-CTR] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.

[AES-CTR] Housley、R。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンターモードの使用」、RFC 3686、2004年1月。

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.

[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。

[AESPRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 3664, January 2004.

[AESPRF]ホフマン、P。、「インターネットキーエクスチェンジプロトコル（IKE）のAES-XCBC-PRF-128アルゴリズム」、RFC 3664、2004年1月。

[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.

[RFC2403]マドソン、C。およびR.グレン、「ESPおよびAH内でのHMAC-MD5-96の使用」、RFC 2403、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月。

[AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.

[AES-MAC]フランケルS.およびH.ハーバート、「AES-XCBC-MAC-96アルゴリズムとIPsecでのその使用」、RFC 3566、2003年9月。

Author's Address

著者のアドレス

Jeffrey I. Schiller Massachusetts Institute of Technology Room W92-190 77 Massachusetts Avenue Cambridge, MA 02139-4307 USA

ジェフリーI.シラーマサチューセッツ工科大学W92-190 77マサチューセッツアベニューケンブリッジ、マサチューセッツ02139-4307アメリカ

   Phone: +1 (617) 253-0161
   EMail: jis@mit.edu

Full Copyright Statement

完全な著作権表示

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能への資金提供は、現在Internet Societyから提供されています。