RFC 4109 - Algorithms for Internet Key Exchange version 1 (IKEv1) 日本語訳

URL : https://tools.ietf.org/html/rfc4109
タイトル : RFC 4109 - インターネット鍵交換バージョン1のアルゴリズム（IKEv1の）
翻訳編集 : 自動生成

Network Working Group                                         P. Hoffman
Request for Comments: 4109                                VPN Consortium
Updates: 2409                                                   May 2005
Category: Standards Track

         Algorithms for Internet Key Exchange version 1 (IKEv1)

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 required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today.

オリジナルのインターネット鍵交換バージョン1（のIKEv1）仕様で必要と提案したアルゴリズムは、IPsec市場の要求の現在の現実を反映していません。元の仕様は、弱いセキュリティを可能にし、薄く実装されるアルゴリズムを提案しています。このドキュメントの更新RFC 2409、元の仕様、今日デプロイされたすべてのIKEv1実装を対象としています。

1. Introduction

1. はじめに

The original IKEv1 definition, [RFC2409], has a set of MUST-level and SHOULD-level requirements that do not match the needs of IPsec users. This document updates RFC 2409 by changing the algorithm requirements defined there.

オリジナルのIKEv1の定義、[RFC2409]は、IPsecのユーザーのニーズに合致していないMUSTレベルおよびSHOULDレベルの要件のセットがあります。この文書では、そこに定義されたアルゴリズムの要件を変更することにより、RFC 2409を更新します。

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].

彼らは、この文書に表示される[RFC2119]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。

2. Old Algorithm Requirements

2.旧アルゴリズムの要件

RFC 2409 has the following MUST-level and SHOULD-level requirements:

RFC 2409には、以下のMUSTレベルおよびSHOULDレベルの要件があります。

o DES for encryption MUST be supported. o MD5 and SHA-1 for hashing and HMAC functions MUST be supported. o Pre-shared secrets for authentication MUST be supported. o Diffie-Hellman MODP group 1 (discrete log 768 bits) MUST be supported. o TripleDES for encryption SHOULD be supported. o Tiger for hashing SHOULD be supported. o DSA and RSA for authentication with signatures SHOULD be supported. o RSA for authentication with encryption SHOULD be supported. o Diffie-Hellman MODP group 2 (discrete log 1024 bits) SHOULD be supported.

O暗号化のためのDESをサポートしなければなりません。 O MD5とSHA-1ハッシュ及びHMAC関数のをサポートしなければなりません。 O認証に事前共有秘密をサポートしなければなりません。 Oディフィー・ヘルマンMODPグループ1（離散対数768ビット）をサポートしなければなりません。 O暗号化のトリプルDESがサポートされる必要があります。 Oハッシュのためのタイガーは、サポートされる必要があります。 O署名による認証のためのDSAおよびRSAがサポートされるべきです。 Oの暗号化と認証のためのRSAは、サポートされる必要があります。 Oディフィー・ヘルマンMODPグループ2（離散対数1024ビット）がサポートされる必要があります。

RFC 2409 gives two conflicting requirement levels for Diffie-Hellman MODP groups with elliptic curves. Section 4 of that specification says that "IKE implementations ... MAY support ECP and EC2N groups", but Sections 6.3 and 6.4 say that MODP groups 3 and 4 for EC2N groups SHOULD be supported.

RFC 2409は、楕円曲線とのディフィー - ヘルマンMODPグループのための2つの相反する要求レベルを与えます。その仕様の第4章では、「IKE実装は... ECPとEC2Nグループをサポートするかもしれ」と言っていますが、セクション6.3と6.4はEC2NグループのためのMODPグループ3と4がサポートされるべきであると言います。

3. New Algorithm Requirements

3.新しいアルゴリズムの要件

The new requirements for IKEv1 are listed here. Note that some of the requirements are the same as those in RFC 2409, whereas others are changed.

IKEv1のための新たな要件はここに記載されています。他の人が変更されたのに対し、要件のいくつかは、RFC 2409と同じであることに留意されたいです。

o TripleDES for encryption MUST be supported. o AES-128 in CBC mode [RFC3602] for encryption SHOULD be supported. o SHA-1 for hashing and HMAC functions MUST be supported. o Pre-shared secrets for authentication MUST be supported. o AES-128 in XCBC mode for PRF functions ([RFC3566] and [RFC3664]) SHOULD be supported. o Diffie-Hellman MODP group 2 (discrete log 1024 bits) MUST be supported.

O暗号化のトリプルDESをサポートしなければなりません。暗号化のために[RFC3602]はサポートされてくださいCBCモードのAES-128、O。 O SHA-1ハッシュ及びHMAC関数のをサポートしなければなりません。 O認証に事前共有秘密をサポートしなければなりません。 O PRF関数のXCBCモード（[RFC3566]及び[RFC3664]）でAES-128がサポートされてください。 Oディフィー・ヘルマンMODPグループ2（離散対数1024ビット）をサポートしなければなりません。

o Diffie-Hellman MODP group 14 (discrete log 2048 bits) [RFC3526] SHOULD be supported. o RSA for authentication with signatures SHOULD be supported.

Oディフィー・ヘルマンMODP群14（離散対数2048ビット）[RFC3526]はサポートされる必要があります。 O署名による認証のためのRSAは、サポートされる必要があります。

If additional updates are made to IKEv1 in the future, then it is very likely that implementation of AES-128 in CBC mode for encryption will become mandatory.

追加の更新が将来のIKEv1に行われた場合、暗号化のためのCBCモードのAES-128の実装が必須になる可能性が非常に高いです。

The other algorithms that were listed at MUST-level and SHOULD-level in RFC 2409 are now MAY-level. This includes DES for encryption, MD5 and Tiger for hashing, Diffie-Hellman MODP group 1, Diffie-Hellman MODP groups with elliptic curves, DSA for authentication with signatures, and RSA for authentication with encryption.

RFC 2409でMUSTレベルおよびSHOULDレベルで列挙された他のアルゴリズム月レベルになりました。これは、暗号化と認証のための暗号化、MD5およびタイガーハッシングのため、署名と認証のためのDiffie-HellmanのMODPグループ1、楕円曲線とのディフィー - ヘルマンMODP基、DSA及びRSAのためのDESを含みます。

DES for encryption, MD5 for hashing, and Diffie-Hellman MODP group 1 are dropped to MAY due to cryptographic weakness.

暗号化のためのDES、ハッシュのためのMD5、およびDiffie-HellmanのMODPグループ1が原因暗号弱点にMAYに低下しています。

Tiger for hashing, Diffie-Hellman MODP groups with elliptic curves, DSA for authentication with signatures, and RSA for authentication with encryption are dropped due to lack of any significant deployment and interoperability.

ハッシュのためのタイガーは、楕円を使用したDiffie-Hellman MODPグループは、DSAは、暗号化と認証のための署名と認証、およびRSAのために起因する大規模に展開し、相互運用性の欠如にドロップされます。

4. Summary

4.まとめ

      Algorithm                     RFC 2409    This document
      ------------------------------------------------------------------
      DES for encryption            MUST        MAY (crypto weakness)
      TripleDES for encryption      SHOULD      MUST
      AES-128 for encryption        N/A         SHOULD
      MD5 for hashing and HMAC      MUST        MAY (crypto weakness)
      SHA1 for hashing and HMAC     MUST        MUST
      Tiger for hashing             SHOULD      MAY (lack of deployment)
      AES-XCBC-MAC-96 for PRF       N/A         SHOULD
      Pre-shared secrets            MUST        MUST
      RSA with signatures           SHOULD      SHOULD
      DSA with signatures           SHOULD      MAY (lack of deployment)
      RSA with encryption           SHOULD      MAY (lack of deployment)
      D-H Group 1 (768)             MUST        MAY (crypto weakness)
      D-H Group 2 (1024)            SHOULD      MUST
      D-H Group 14 (2048)           N/A         SHOULD
      D-H elliptic curves           SHOULD      MAY (lack of deployment)

5. Security Considerations

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

This document is all about security. All the algorithms that are either MUST-level or SHOULD-level in the "new algorithm requirements" section of this document are believed to be robust and secure at the time of this writing.

この文書では、すべてのセキュリティについてです。レベルないと、この文書の「新しいアルゴリズムの要件」セクションにあるべきであるレベルのいずれかであるすべてのアルゴリズムは、この記事の執筆時点で、堅牢かつ安全であると考えられています。

6. Normative References

6.引用規格

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

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

[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、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月。

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

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

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

Author's Address

著者のアドレス

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

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

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機能のための基金は現在、インターネット協会によって提供されます。