[要約] RFC 4308は、IPsecのための暗号スイートに関する仕様であり、セキュリティプロトコルの選択と設定に関するガイドラインを提供します。その目的は、IPsecの実装者が適切な暗号スイートを選択し、セキュリティ要件を満たすための支援をすることです。
Network Working Group P. Hoffman
Request for Comments: 4308 VPN Consortium
Category: Standards Track December 2005
Cryptographic Suites for IPsec
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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、Internet Key Exchange（IKE）、およびIKEV2プロトコルは、セキュリティアルゴリズムに依存して、イニシエーターとレスポンダーの間にプライバシーと認証を提供します。このようなアルゴリズムが多く利用可能で、2つのIPSECシステムが同じアルゴリズムを使用していない限り相互運用できません。このドキュメントは、IKEV1またはIKEV2を使用して、手動キーイングモードで使用された場合にIPSECの管理を簡素化するために使用できるアルゴリズムと属性のオプションのスイートを指定します。
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.
マニュアルキーモードでのIPSECおよびIKEでの実装エクスペリエンスは、典型的なシステム管理者が慎重な前面付けなしに相互運用性を達成することが困難であることを作成するための非常に多くの選択肢があることを示しています。このため、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]で説明されているように解釈されるべきです。
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プロトコルを決して変更しません。具体的には、UIスイートが使用されるかどうかに関係なく、指定された各オプションの値を与えるために、IKEおよびIKEV2の変換基盤を使用する必要があります。
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によって登録されています。
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]
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]
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の場合）またはcreate_child_sa（ikev2の場合）の再キー化は、このスイートの両当事者によってサポートされる必要があります。この交換のイニシエーターには、新しいdiffie-hellmanキーが含まれる場合があります。含まれている場合は、タイプ1024ビットMODPでなければなりません。交換のイニシエーターにdiffie-hellmanキーが含まれている場合、レスポンダーにはdiffie-hellmanキーを含める必要があり、タイプ1024ビットmodpの必要があります。
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]
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]
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の場合）またはcreate_child_sa（ikev2の場合）の再キー化は、このスイートの両当事者によってサポートされる必要があります。この交換のイニシエーターには、新しいdiffie-hellmanキーが含まれる場合があります。含まれている場合は、タイプ2048ビットMODPでなければなりません。交換のイニシエーターにdiffie-hellmanキーが含まれている場合、レスポンダーにはdiffie-hellmanキーを含める必要があり、タイプ2048ビットmodpの必要があります。
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セキュリティ協会（SAS）の寿命があります。VPN-AまたはVPN-BスイートのいずれかでIKEV1を使用するシステムは、フェーズ1で86400秒（1日）のSA寿命、およびフェーズ2で28800秒（8時間）のSA寿命を使用する必要があります。
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.
このドキュメントのテキストとアイデアの多くは、Charlie Kaufmanが編集したIKEV2ドキュメントの以前のバージョンから来ました。その他のテキストとアイデアは、IPSECワーキンググループの他のメンバーによって提供されました。
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.
これらのスイートで指定されたセキュリティオプションの一部は、この文書が作成された時点で信じられていたものよりも著しく弱いプロパティを持つことが将来見つかる可能性があります。
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-A RFC 4308 VPN-B RFC 4308で定義されている識別子
[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] Frankel、S.、Glenn、R。、およびS. Kelly、「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] Hoffman、P。、「インターネットキーエクスチェンジプロトコル（IKE）のAES-XCBC-PRF-128アルゴリズム」、RFC 3664、2004年1月。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、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.、Bellare、M。、およびR. CaNetti、「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] 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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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. Glenn、「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] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[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月。
[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月。
[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月。
Author's Address
著者の連絡先
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポールホフマンVPNコンソーシアム127セグレプレイスサンタクルス、カリフォルニア95060 USA
EMail: paul.hoffman@vpnc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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エディター機能の資金は現在、インターネット協会によって提供されています。