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

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

[要約] RFC 4307は、IKEv2（RFC 4306）の実装において必須または推奨される暗号アルゴリズム（暗号化、PRF、整合性、Diffie-Hellman）を規定しています。異なるベンダーの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)

IKEv2（インターネット鍵交換バージョン2）で使用する暗号アルゴリズム

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.

この文書は、インターネット標準化過程にあるプロトコルをインターネットコミュニティ向けに規定し、改善に向けた議論や提案を求めるものです。このプロトコルの標準化段階と状態については、「Internet Official Protocol Standards」（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プロトコル群は、セキュリティサービスを提供するためにさまざまな暗号アルゴリズムを使用します。Internet Key Exchange（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 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.

Internet Key Exchange（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-と指定されたアルゴリズムは、本書の将来版でMAYに格下げされる可能性があります。

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ではなくなると想定しています。正式な扱いは後日決まりますが、将来の改訂で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をMUST-レベルの要件として実装し、AES-128-CBCをSHOULD+レベルで実装することが推奨されます。整合性については、HMAC-SHA1を実装しなければなりません (MUST)。

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拡張文書の両方で定義されています。これらはグループ番号によって識別されます。ここに記載されていないグループはすべて「実装してもよい (MAY)」と見なされます。

      Group Number        Bit Length            Status     Defined
      2                   1024 MODP Group       MUST-      [RFC2409]
      14                  2048 MODP Group       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は、Transform Type 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

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.

Transform Type 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+

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.

Transform Type 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+

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で使う暗号アルゴリズム、特に「実装必須」アルゴリズムの選定を扱います。本書で「必須実装 (MUST)」または「推奨実装 (SHOULD)」と分類するアルゴリズムは、現時点で破られたとは知られておらず、これまでの暗号研究からは、予見可能な将来にわたり安全性を保つ可能性が高いと考えられます。ただし、それが永続するとは限りません。この分野の最新の慣行を反映するため、本書は随時改訂される見込みです。

5. Normative References

5. 引用文献

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

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

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

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

[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.

[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.

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

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

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

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

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

[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.

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

Author's Address

著者の連絡先

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

   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.

本書およびここに含まれる情報は「現状有姿」で提供されます。寄稿者、その寄稿者が代表する、または寄稿を後援する組織（該当する場合）、Internet Society、およびInternet Engineering Task Forceは、明示・黙示を問わず一切の保証を否認します。これには、本書の情報の使用がいかなる権利も侵害しないことの保証や、商品性および特定目的への適合性に関する黙示の保証も含まれますが、これらに限定されません。

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は、本標準の実装に必要となる可能性のある技術を対象とする著作権、特許、特許出願、その他の所有権について、関係者から情報を寄せるよう呼びかけています。情報はietf-ipr@ietf.org宛てにIETFへお送りください。

Acknowledgement

謝辞

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

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