RFC4308 日本語訳

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

コメントを求めるワーキンググループP.ホフマン要求をネットワークでつないでください: 4308年のVPN共同体カテゴリ: 標準化過程2005年12月

                     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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(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システムは共同利用できません。このドキュメントはモードを合わせるマニュアルで使用されるとIPsecの管理を簡素化するのに使用できるアルゴリズムと属性、IKEv1またはIKEv2と共に任意のスイートを指定します。

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.

このドキュメントは2の主要な交換のIPsec[RFC2401]、プロトコル、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スイート」(「ユーザーインタフェーススイート」)と呼ばれたスイートは、任意であり、implementersがセキュリティアルゴリズムの個体選択を許容するのを防ぎません。

Hoffman                     Standards Track                     [Page 1]

RFC 4308             Cryptographic Suites for IPsec        December 2005

ホフマンStandardsは2005年12月にIPsecのためにRFC4308の暗号のスイートを追跡します[1ページ]。

   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スイートは実装するために任意ですが、ここで使用された名前で特定のスイートを呼ぶimplementersが本書では記載されたスイートに一致しなければならないので、標準化過程の上にこのドキュメントはあります。 これらのスイートは、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].

キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」は中[RFC2119]で説明されるように本書では解釈されることになっているべきです。

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プロトコルを変えません。 明確に、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スイートSHOULDを使用する実装が個々の暗号のオプションに値を指定するのに管理インタフェースを提供します。 すなわち、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スイートSHOULDを使用するIPsec実装がここに記載されたスイート名を使用します。 IPsec実装SHOULD NOTは説明されるスイートにそれらがここに記載したより異なった名前を使用して、これらの値に合っていないスイートにここに記載された名前は使用してはいけません。 これらの要件が相互運用性に必要です。

   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.

RFCsは追加スイートを定義できます。 UIスイートを特定するのに使用されるストリングはIANAによって登録されます。

Hoffman                     Standards Track                     [Page 2]

RFC 4308             Cryptographic Suites for IPsec        December 2005

ホフマンStandardsは2005年12月にIPsecのためにRFC4308の暗号のスイートを追跡します[2ページ]。

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: CBCモード[RFC2451]超能力保全HMAC-SHA1-96のプロトコルEncapsulating Security有効搭載量(超能力)[RFC2406]超能力暗号化TripleDES[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モード[RFC2451]擬似ランダム機能HMAC-SHA1[RFC2104]保全HMAC-SHA1-96[RFC2404]ディフィー-ヘルマンの暗号化TripleDESは1024年のビットの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.

_Phase2(IKEのための)かCREATE_CHILDをRekeyingして、双方はこのスイートでSA(IKEv2のための)をサポートしなければなりません。 この交換の創始者は新しいディフィー-ヘルマンキーを入れるかもしれません。 含まれているなら、タイプの1024年のビットのMODPにはそれがあるに違いありません。 交換の創始者がディフィー-ヘルマンキーを入れるなら、応答者はディフィーヘルマンキーを入れなければなりません、そして、それはタイプの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: 128ビットのキーがCBCモード[AES-CBC]超能力保全AES-XCBC-MAC-96にあるプロトコル超能力[RFC2406]超能力暗号化AES[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モード[AES-CBC]擬似ランダム機能AES-XCBC-PRF-128[AES-XCBC-PRF-128]保全AES-XCBC Mac96[AES-XCBC-MAC]ディフィー-ヘルマングループの2048年のビットのMODPにおける128ビットのキーがある暗号化AES[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.

_Phase2(IKEのための)かCREATE_CHILDをRekeyingして、双方はこのスイートでSA(IKEv2のための)をサポートしなければなりません。 この交換の創始者は新しいディフィー-ヘルマンキーを入れるかもしれません。 含まれているなら、タイプの2048年のビットのMODPにはそれがあるに違いありません。 交換の創始者がディフィー-ヘルマンキーを入れるなら、応答者はディフィーヘルマンキーを入れなければなりません、そして、それはタイプの2048年のビットのMODPについて入れなければなりません。

Hoffman                     Standards Track                     [Page 3]

RFC 4308             Cryptographic Suites for IPsec        December 2005

ホフマンStandardsは2005年12月にIPsecのためにRFC4308の暗号のスイートを追跡します[3ページ]。

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つのセキュリティパラメタ、すなわち、Phase1とPhase2セキュリティ協会(SAs)の寿命があります。 VPN-AとIKEv1を使用するシステムかVPN-BスイートがPhase1のための86400秒(1日)のSA生涯、Phase2のための28800秒(8時間)の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-A RFC4308VPN-B RFC4308で定義された識別子

Hoffman                     Standards Track                     [Page 4]

RFC 4308             Cryptographic Suites for IPsec        December 2005

ホフマンStandardsは2005年12月にIPsecのためにRFC4308の暗号のスイートを追跡します[4ページ]。

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と共にアルゴリズムとその使用を解きます」、RFC3602、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とのその使用」、RFC3566、9月2003日

   [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.、「インターネット・キー・エクスチェンジプロトコル(IKE)のためのAES-XCBC-PRF-128アルゴリズム」、RFC3664、2004年1月。

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

[IKEv2] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日

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

[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2401]          Kent, S. and R. Atkinson, "Security Architecture
                      for the Internet Protocol", RFC 2401, November
                      1998.

[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

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

そして、[RFC2404] マドソン、C.、およびR.グレン、「超能力の中のHMAC-SHA-1-96の使用、ああ、」、RFC2404、11月1998日

   [RFC2406]          Kent, S. and R. Atkinson, "IP Encapsulating
                      Security Payload (ESP)", RFC 2406, November 1998.

[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。

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

[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。

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

[RFC2451] ペレイラとR.とR.アダムス、「超能力CBC-モード暗号アルゴリズム」、RFC2451、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、「より多くのModular Exponential(MODP)ディフィー-ヘルマンはインターネット・キー・エクスチェンジ(IKE)のために分類します」、RFC3526、2003年5月。

Hoffman                     Standards Track                     [Page 5]

RFC 4308             Cryptographic Suites for IPsec        December 2005

ホフマンStandardsは2005年12月にIPsecのためにRFC4308の暗号のスイートを追跡します[5ページ]。

Author's Address

作者のアドレス

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

ポールホフマンVPN共同体127セグレ・Placeカリフォルニア95060サンタクルス(米国)

   EMail: paul.hoffman@vpnc.org

メール: paul.hoffman@vpnc.org

Hoffman                     Standards Track                     [Page 6]

RFC 4308             Cryptographic Suites for IPsec        December 2005

ホフマンStandardsは2005年12月にIPsecのためにRFC4308の暗号のスイートを追跡します[6ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

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

Hoffman                     Standards Track                     [Page 7]

ホフマン標準化過程[7ページ]