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

原文URL : https://datatracker.ietf.org/doc/html/rfc4109
タイトル : RFC 4109 - インターネットキーエクスチェンジバージョン1（IKEV1）のアルゴリズム
翻訳編集 : 自動生成

[要約] RFC 4109は、IKEv1のためのアルゴリズムに関する規格であり、IKEv1のセキュリティプロトコルの実装を支援するために作成されました。目的は、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)

インターネットキーエクスチェンジバージョン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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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.

元のInternet Key Exchangeバージョン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ユーザーのニーズと一致しない必須レベルおよびレベルの要件のセットがあります。このドキュメントは、そこに定義されているアルゴリズム要件を変更することにより、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]に記載されているように解釈される場合は、キーワードが[RFC2119]に記載されているように解釈される場合に、このドキュメントに表示される場合、必要であってはなりません。

2. Old Algorithm Requirements

2. 古いアルゴリズムの要件

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

RFC 2409には、次の必須レベルおよびレベルレベルの要件があります。

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をサポートする必要があります。HashingおよびHMAC関数のO MD5およびSHA-1をサポートする必要があります。o認証の事前に共有された秘密をサポートする必要があります。o diffie-hellman modpグループ1（離散ログ768ビット）をサポートする必要があります。o暗号化用の3倍をサポートする必要があります。oハッシュのためのTigerをサポートする必要があります。o DSAおよびRSA署名を使用した認証をサポートする必要があります。暗号化による認証用のo RSAをサポートする必要があります。o diffie-hellman 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は、楕円曲線を備えたDiffie-Hellman 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 暗号化用の3倍をサポートする必要があります。暗号化用のCBCモード[RFC3602]のo AES-128をサポートする必要があります。HashingおよびHMAC関数のoSHA-1をサポートする必要があります。o認証の事前に共有された秘密をサポートする必要があります。o PRF関数のXCBCモード（[RFC3566]および[RFC3664]）をサポートする必要があります。o diffie-hellman 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 Diffie-Hellman Modp Group 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の必見のレベルとレベルのレベルでリストされた他のアルゴリズムは、5月レベルになりました。これには、暗号化のためのDES、Hashing用MD5、Tiger、Diffie-Hellman Modp Group 1、楕円曲線を備えたDiffie-Hellman Modpグループ、署名付き認証用のDSA、暗号化の認証用のRSAが含まれます。

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は、暗号化の衰弱のために5月にドロップされます。

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.

ハッシュのためのTiger、楕円曲線を備えた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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

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

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

[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] Hoffman、P。、「インターネットキーエクスチェンジプロトコル（IKE）のAES-XCBC-PRF-128アルゴリズム」、RFC 3664、2004年1月。

Author's Address

著者の連絡先

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

ポールホフマンVPNコンソーシアム127セグレプレイスサンタクルス、カリフォルニア州95060米国

   EMail: paul.hoffman@vpnc.org

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は、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

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

RFCエディター機能の資金は現在、インターネット協会によって提供されています。