RFC 4308 - Cryptographic Suites for IPsec 日本語訳

URL : https://tools.ietf.org/html/rfc4308
タイトル : RFC 4308 - IPsecの暗号スイート
翻訳編集 : 自動生成

Network Working Group                                         P. Hoffman
Request for Comments: 4308                                VPN Consortium
Category: Standards Track                                  December 2005

                     Cryptographic Suites for IPsec

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2005）。

Abstract

抽象

The IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2.

IPsecのインターネットキー交換（IKE）、およびIKEv2のプロトコルは、イニシエータとレスポンダの間でプライバシーと認証を提供するために、セキュリティ・アルゴリズムに依存しています。そこに多くのそのようなアルゴリズムが利用可能であり、それらが同じアルゴリズムを使用していない限り、2つのIPSecシステムが相互運用することはできません。この文書では、手動キー入力モードで使用する場合のIKEv1またはIKEv2ので、IPsecのの管理を簡素化するために使用することができアルゴリズムと属性のオプションのスイートを指定します。

1. Introduction

1. はじめに

This document is a companion to IPsec [RFC2401] and its two key exchange protocols, IKE [RFC2409] and IKEv2 [IKEv2]. Like most security protocols, IPsec, IKE, and IKEv2 allow users to chose which cryptographic algorithms they want to use to meet their security needs.

この文書では、IPsec [RFC2401]とその2つの鍵交換プロトコル、IKE [RFC2409]とのIKEv2 [IKEv2の]への仲間です。ほとんどのセキュリティプロトコルと同様に、IPsecの、IKE、およびIKEv2のは、ユーザーが彼らのセキュリティニーズを満たすために使用する暗号化されたアルゴリズム選択することができます。

Implementation experience with IPsec in manual key mode and with IKE has shown that there are so many choices for typical system administrators to make that it is difficult to achieve interoperability without careful pre-agreement. Because of this, the IPsec Working Group agreed that there should be a small number of named suites that cover typical security policies. These suites may be presented in the administrative interface of the IPsec system. These suites, often called "UI suites" ("user interface suites"), are optional and do not prevent implementers from allowing individual selection of the security algorithms.

IKE、マニュアルキーモードではととのIPsecでの実装経験は、一般的なシステム管理者は、慎重な事前の合意なしで相互運用性を達成することは困難であることを確認するために非常に多くの選択肢があることを示しています。このため、IPsecのワーキンググループは、一般的なセキュリティポリシーをカバーするという名前のスイートルームの数が少ないがなければならないことに同意しました。これらのスイートには、IPsecシステムの管理インタフェースで提示することができます。多くの場合、「UIスイート」（「ユーザー・インターフェース・スイート」）と呼ばれるこれらのスイートには、オプションであり、セキュリティ・アルゴリズムの個々の選択を可能と実装を防ぐことはできません。

Although the UI suites listed here are optional to implement, this document is on the standards track because implementers who call particular suites by the names used here have to conform to the suites listed in this document. These suites should not be considered extensions to IPsec, IKE, and IKEv2, but instead administrative methods for describing sets of configurations.

ここに記載されているUIのスイートには、実装するためにオプションですが、この文書では、ここで使用される名前で、特定のスイートを呼び出す実装は、この文書に記載されているスイートに準拠する必要があるため追跡基準にあります。これらのスイートには、コンフィギュレーションのセットを記述するためにIPsec、IKE、およびIKEv2のが、その代わりに、管理方法への拡張を考慮すべきではありません。

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [RFC2119].

[RFC2119]に記載されているようにキーワード "MUST" は、 "MUST NOT"、 "SHOULD NOT"、および本書で解釈されるべきである、 "MAY"、 "SHOULD"。

2. UI Suites

2. UIスイーツ

This section lists optional, non-mandatory suites that may be presented to system administrators to ease the burden of choosing among the many options in IPsec systems. These suites cannot cover all of the options that an administrator needs to select. Instead, they give values for a subset of the options.

このセクションでは、IPsecシステムでは多くのオプションの中から選択するの負担を軽減するために、システム管理者に提示することができるオプション、非必須スイートを示しています。これらのスイートには、管理者が選択する必要があるオプションをすべてカバーすることはできません。その代わりに、彼らはオプションのサブセットのための値を与えます。

Note that these UI suites are simply collections of values for some options in IPsec. Use of UI suites does not change the IPsec, IKE, or IKEv2 protocols in any way. Specifically, the transform substructure in IKE and IKEv2 must be used to give the value for each specified option regardless of whether or not UI suites are used.

これらのUIのスイートは、単純にIPsecでのいくつかのオプションの値の集合であることに注意してください。 UIスイートを使用すると、どのような方法でのIPsec、IKE、またはIKEv2のプロトコルを変更しません。具体的には、IKEおよびIKEv2の中に変換下部には関係なく、UIのスイートが使用されているかどうかの指定された各オプションの値を与えるために使用する必要があります。

Implementations that use UI suites SHOULD also provide a management interface for specifying values for individual cryptographic options. That is, it is unlikely that UI suites are a complete solution for matching the security policies of many IPsec users, and therefore an interface that gives a more complete set of options should be used as well.

UIのスイートを使用する実装は、個々の暗号化オプションの値を指定するための管理インターフェイスを提供する必要があります。つまり、UIのスイートは、多くのIPsecユーザのセキュリティポリシーに合致するための完全なソリューションであることをそうです、そしてオプションのより完全なセットを提供しますので、インターフェースは、同様に使用されなければならない、です。

IPsec implementations that use these UI suites SHOULD use the suite names listed here. IPsec implementations SHOULD NOT use names different than those listed here for the suites that are described, and MUST NOT use the names listed here for suites that do not match these values. These requirements are necessary for interoperability.

これらのUIのスイートを使用するIPsec実装は、ここに記載されているスイート名を使用すべきです。 IPsec実装が記述されているスイートのためにここに記載されているものとは異なる名前を使用しません。また、これらの値と一致しないのスイートのためにここに記載されている名前を使用してはなりません。これらの要件は、相互運用性のために必要です。

Note that the suites listed here are for use of IPsec in virtual private networks. Other uses of IPsec will probably want to define their own suites and give them different names.

ここに記載されたスイートには、仮想プライベートネットワークでのIPsecを使用するためのものであることに注意してください。 IPsecの他の用途は、おそらく自分のスイートを定義し、それらに異なる名前を与えることになるでしょう。

Additional suites can be defined by RFCs. The strings used to identify UI suites are registered by IANA.

追加のスイートには、RFCで定義することができます。 UIのスイートを識別するために使用される文字列は、IANAによって登録されています。

2.1. Suite "VPN-A"

2.1. スイート "VPN-A"

This suite matches the commonly used corporate VPN security used in IKEv1 at the time of this document's publication.

このスイートは、このドキュメントの発行時点でのIKEv1で使用される一般的に使用され、企業のVPNセキュリティと一致します。

IPsec: Protocol Encapsulating Security Payload (ESP) [RFC2406] ESP encryption TripleDES in CBC mode [RFC2451] ESP integrity HMAC-SHA1-96 [RFC2404]

IPsecの：プロトコルカプセル化セキュリティペイロード（ESP）[RFC2406] CBCモードのESP暗号化のTripleDES [RFC2451] ESPの整合性HMAC-SHA1-96 [RFC2404]

IKE and IKEv2: Encryption TripleDES in CBC mode [RFC2451] Pseudo-random function HMAC-SHA1 [RFC2104] Integrity HMAC-SHA1-96 [RFC2404] Diffie-Hellman group 1024-bit Modular Exponential (MODP) [RFC2409]

IKE及びIKEv2の：CBCモードで暗号化のTripleDES [RFC2451]擬似ランダム関数HMAC-SHA1 [RFC2104]インテグリティHMAC-SHA1-96 [RFC2404]のDiffie-Hellmanグループ1024ビットモジュラー指数（MODP）[RFC2409]

Rekeying of Phase 2 (for IKE) or the CREATE_CHILD_SA (for IKEv2) MUST be supported by both parties in this suite. The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST be of type 1024-bit MODP. If the initiator of the exchange includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and it MUST of type 1024-bit MODP.

フェーズ2（IKE）または（IKEv2のための）CREATE_CHILD_SAのリキーは、このスイートの双方によってサポートされなければなりません。この交換のイニシエータは、新しいDiffie-Hellman鍵を含むことができ、それが含まれている場合、それはタイプ1024ビットのMODPでなければなりません。交換の開始剤がのDiffie-Hellmanキーが含まれている場合、応答者はのDiffie-Hellmanキーを含まなければなりません、そして、それはタイプ1024ビットMODPのなければなりません。

2.2. Suite "VPN-B"

2.2. スイート "VPN-B"

This suite is what many people expect the commonly used corporate VPN security that will be used within a few years of the time this document's publication.

このスイートには、多くの人々が時間、本書の出版の数年以内に使用される一般的に使用され、企業のVPNセキュリティを期待するものです。

IPsec: Protocol ESP [RFC2406] ESP encryption AES with 128-bit keys in CBC mode [AES-CBC] ESP integrity AES-XCBC-MAC-96 [AES-XCBC-MAC]

IPsecの：プロトコルCBCモードでは、128ビットキーを使用してESP [RFC2406] ESP暗号化AES [AES-CBC] ESP整合性AES-XCBC-MAC-96 [AES-XCBC-MAC]

IKE and IKEv2: Encryption AES with 128-bit keys in CBC mode [AES-CBC] Pseudo-random function AES-XCBC-PRF-128 [AES-XCBC-PRF-128] Integrity AES-XCBC-MAC-96 [AES-XCBC-MAC] Diffie-Hellman group 2048-bit MODP [RFC3526]

IKE及びIKEv2の：CBCモードでは、128ビットのキーで暗号化AES [AES-CBC]擬似ランダム関数AES-XCBC-PRF-128 [AES-XCBC-PRF-128]整合性AES-XCBC-MAC-96 [AES- XCBC-MAC]のDiffie-Hellmanグループ2048ビットMODP [RFC3526]

Rekeying of Phase 2 (for IKE) or the CREATE_CHILD_SA (for IKEv2) MUST be supported by both parties in this suite. The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST be of type 2048-bit MODP. If the initiator of the exchange includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and it MUST of type 2048-bit MODP.

フェーズ2（IKE）または（IKEv2のための）CREATE_CHILD_SAのリキーは、このスイートの双方によってサポートされなければなりません。この交換のイニシエータは、新しいDiffie-Hellman鍵を含むことができ、それが含まれている場合、それはタイプ2048ビットのMODPでなければなりません。交換の開始剤がのDiffie-Hellmanキーが含まれている場合、応答者はのDiffie-Hellmanキーを含まなければなりません、そして、それはタイプ2048ビットMODPのなければなりません。

2.3. Lifetimes for IKEv1

2.3. IKEv1のための寿命

IKEv1 has two security parameters that do not appear in IKEv2, namely, the lifetime of the Phase 1 and Phase 2 security associations (SAs). Systems that use IKEv1 with either the VPN-A or VPN-B suites MUST use an SA lifetime of 86400 seconds (1 day) for Phase 1 and an SA lifetime of 28800 seconds (8 hours) for Phase 2.

IKEv1は、IKEv2のには表示されない2つのセキュリティパラメータ、フェーズ1とフェーズ2つのセキュリティアソシエーション（SA）の、すなわち、寿命があります。 VPN-AまたはVPN-BのいずれかスイートルームのIKEv1を使用するシステムは、フェーズ1とフェーズ2のための28800秒（8時間）のSAの存続期間86400秒（1日）のSAライフタイムを使用しなければなりません。

3. Acknowledgements

3.謝辞

Much of the text and ideas in this document came from earlier versions of the IKEv2 document edited by Charlie Kaufman. Other text and ideas were contributed by other members of the IPsec Working Group.

この文書内のテキストやアイデアの多くは、チャーリー・カウフマンが編集のIKEv2文書の以前のバージョンから来ました。その他のテキストやアイデアは、IPsecのワーキンググループの他のメンバーによって寄与されました。

4. Security Considerations

4.セキュリティについての考慮事項

This document inherits all of the security considerations of the IPsec, IKE, and IKEv2 documents.

この文書は、IPsec、IKE、およびIKEv2の文書のセキュリティの考慮事項のすべてを継承します。

Some of the security options specified in these suites may be found in the future to have properties significantly weaker than those that were believed at the time this document was produced.

これらのスイートに指定されたセキュリティオプションのいくつかは、この文書が作成された時点で信じられていたものよりも有意に弱い性質を持っているために、将来的に見ることができます。

5. IANA Considerations

5. IANAの考慮事項

IANA has created and will maintain a registry called, "Cryptographic Suites for IKEv1, IKEv2, and IPsec". The registry consists of a text string and an RFC number that lists the associated transforms. New entries can be added to the registry only after RFC publication and approval by an expert designated by the IESG.

IANAは、作成していると、「暗号IKEv1のためのスイート、IKEv2の、およびIPsec」と呼ばれるレジストリを維持します。レジストリは、テキスト文字列と関連付けられている変換を示していますRFC番号で構成されます。新しいエントリはIESGが指定した専門家によるRFCの公表および承認した後、レジストリに追加することができます。

The initial values for the new registry are:

新しいレジストリの初期値は次のとおりです。

Identifier Defined in VPN-A RFC 4308 VPN-B RFC 4308

VPN-RFC 4308 VPN-BのRFC 4308で定義される識別子

6. Normative References

6.引用規格

[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-XCBC-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.

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

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

[AES-XCBC-PRF-128]ホフマン、P.、 "インターネット鍵交換プロトコルのためのAES-XCBC-PRF-128アルゴリズム（IKE）"、RFC 3664、2004年1月。

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

[IKEv2の]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。

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

[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。

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

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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] Madson、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月。

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

[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。

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

[RFC2451]ペレイラ、R.とR.アダムス、 "ESP CBCモード暗号アルゴリズム"、RFC 2451、1998年11月。

[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.古城、 "インターネット鍵交換のためのより多くのモジュラー指数（MODP）のDiffie-Hellmanグループ（IKE）"、RFC 3526、2003年5月。

Author's Address

著者のアドレス

Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA

ポール・ホフマンVPNコンソーシアムセグレ127場所サンタクルス、CA 95060 USA

EMail: paul.hoffman@vpnc.org

メールアドレス：paul.hoffman@vpnc.org

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2005）。

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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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機能のための基金は現在、インターネット協会によって提供されます。