RFC4869 日本語訳

Network Working Group                                             L. Law
Request for Comments: 4869                                    J. Solinas
Category: Informational                                              NSA
                                                                May 2007

コメントを求めるワーキンググループL.法要求をネットワークでつないでください: 4869年のJ.Solinasカテゴリ: 情報のNSA2007年5月

                 Suite B Cryptographic Suites for IPsec

IPsecのためのスイートのB暗号のスイート

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

Abstract

要約

   This document proposes four optional cryptographic user interface
   suites ("UI suites") for IPsec, similar to the two suites specified
   in RFC 4308.  The four new suites provide compatibility with the
   United States National Security Agency's Suite B specifications.

このドキュメントはIPsecのために、4つの任意の暗号のユーザーインタフェーススイート(「UIスイート」)を提案します、RFC4308で指定された2つのスイートと同様です。 4つの新しいスイートが合衆国国家安全保障局のSuite B仕様を互換性に提供します。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Requirements Terminology ........................................2
   3. New UI Suites ...................................................2
      3.1. Suite "Suite-B-GCM-128" ....................................2
      3.2. Suite "Suite-B-GCM-256" ....................................3
      3.3. Suite "Suite-B-GMAC-128" ...................................4
      3.4. Suite "Suite-B-GMAC-256" ...................................5
   4. Security Considerations .........................................5
   5. IANA Considerations .............................................6
   6. References ......................................................6
      6.1. Normative References .......................................6
      6.2. Informative References .....................................7

1. 序論…2 2. 要件用語…2 3. 新しいUIスイート…2 3.1. スイート「スイート-B-GCM-128」…2 3.2. スイート「スイート-B-GCM-256」…3 3.3. スイート「スイート-B-GMAC-128」…4 3.4. スイート「スイート-B-GMAC-256」…5 4. セキュリティ問題…5 5. IANA問題…6 6. 参照…6 6.1. 標準の参照…6 6.2. 有益な参照…7

Law & Solinas                Informational                      [Page 1]

RFC 4869         Suite B Cryptographic Suites for IPsec         May 2007

IPsec2007年5月のための法とSolinasの情報[1ページ]のRFC4869のスイートのB暗号のスイート

1.  Introduction

1. 序論

   [RFC4308] proposes two optional cryptographic user interface suites
   ("UI suites") for IPsec.  The two suites, VPN-A and VPN-B, represent
   commonly used present-day corporate VPN security choices and
   anticipated future choices, respectively.  This document proposes
   four new UI suites based on implementations of the United States
   National Security Agency's Suite B algorithms (see [SuiteB]).

[RFC4308]はIPsecのために、2つの任意の暗号のユーザーインタフェーススイート(「UIスイート」)を提案します。 2つのスイート、VPN-A、およびVPN-Bはそれぞれ一般的に使用された現代の法人のVPNセキュリティ選択と予期された将来の選択を表します。 このドキュメントは合衆国国家安全保障局のSuite Bアルゴリズムの実装に基づく4つの新しいUIスイートを提案します([SuiteB]を見てください)。

   As with the VPN suites, the Suite B suites are simply collections of
   values for some options in IPsec.  Use of UI suites does not change
   the IPsec protocols in any way.

VPNスイートのように、Suite Bスイートは単にIPsecのいくつかのオプションのための値の収集です。 UIスイートの使用は何らかの方法でIPsecプロトコルを変えません。

2.  Requirements Terminology

2. 要件用語

   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]で説明されるように本書では解釈されることになっているべきです。

3.  New UI Suites

3. 新しいUIスイート

   Each of the following UI suites provides choices for ESP (see
   [RFC4303]) and for IKEv1 and IKEv2 (see [RFC2409] and [RFC4306]).
   The four suites are differentiated by the choice of cryptographic
   algorithm strengths and a choice of whether the Encapsulating
   Security Payload (ESP) is to provide both confidentiality and
   integrity or integrity only.  The suite names are based on the
   Advanced Encryption Standard [AES] mode and AES key length specified
   for ESP.

それぞれの以下のUIスイートは超能力([RFC4303]を見る)とIKEv1とIKEv2に選択を供給します([RFC2409]と[RFC4306]を見てください)。 4つのスイートが暗号アルゴリズムの強さの選択と選択でEncapsulating Security有効搭載量(超能力)が秘密性と保全か保全だけの両方を提供するかどうかことであることを差別化されます。 スイート名は超能力に指定されたエー・イー・エス[AES]モードとAESキー長に基づいています。

   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は説明されるスイートにそれらがここに記載したより異なった名前を使用して、これらの値に合っていないスイートにここに記載された名前は使用してはいけません。 これらの要件が相互運用性に必要です。

3.1.  Suite "Suite-B-GCM-128"

3.1. スイート「スイート-B-GCM-128」

   This suite provides ESP integrity protection and confidentiality
   using 128-bit AES-GCM (see [RFC4106]).  This suite or the following
   suite should be used when ESP integrity protection and encryption are
   both needed.

このスイートは、128ビットのAES-GCMを使用することで保全保護と秘密性を超能力に提供します([RFC4106]を見てください)。 超能力保全保護と暗号化がともに必要であるときに、このスイートか以下のスイートが使用されるべきです。

   ESP:
     Encryption     AES with 128-bit keys and 16-octet Integrity
                      Check Value (ICV) in GCM mode [RFC4106]
     Integrity      NULL

超能力: 128ビットのキーと16八重奏のIntegrity Check Value(ICV)がGCMモード[RFC4106]保全NULLにある暗号化AES

Law & Solinas                Informational                      [Page 2]

RFC 4869         Suite B Cryptographic Suites for IPsec         May 2007

IPsec2007年5月のための法とSolinasの情報[2ページ]のRFC4869のスイートのB暗号のスイート

   IKEv1:
     Encryption                   AES with 128-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-256 [RFC4868]
     Hash                         SHA-256 [FIPS-180-2] [RFC4634]
     Diffie-Hellman group         256-bit random ECP group [RFC4753]
     Group Type                   ECP

IKEv1: 128ビットのキーがCBCモード[RFC3602]擬似ランダム機能HMAC-SHA-256[RFC4868]ハッシュSHA-256[FIPS-180-2][RFC4634]ディフィー-ヘルマングループ256ビットの無作為のECPグループ[RFC4753]グループType ECPにある暗号化AES

   For IKEv1, Phase 1 SHOULD use Main mode.  IKEv1 implementations MUST
   support pre-shared key authentication [RFC2409] for interoperability.
   The authentication method used with IKEv1 MAY be either pre-shared
   key [RFC2409] or ECDSA-256 [RFC4754].

IKEv1のために、Phase1SHOULDはMainモードを使用します。 IKEv1実装は、相互運用性のためにあらかじめ共有された主要な認証が[RFC2409]であるとサポートしなければなりません。 IKEv1と共に使用される認証方法は、あらかじめ共有されたキー[RFC2409]かECDSA-256のどちらかであるかもしれません[RFC4754]。

   IKEv2:
     Encryption                   AES with 128-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-256 [RFC4868]
     Integrity                    HMAC-SHA-256-128 [RFC4868]
     Diffie-Hellman group         256-bit random ECP group [RFC4753]
     Authentication               ECDSA-256 [RFC4754]

IKEv2: 128ビットのキーがCBCモード[RFC3602]擬似ランダム機能HMAC-SHA-256[RFC4868]保全HMAC-SHA-256-128[RFC4868]ディフィー-ヘルマングループ256ビットの無作為のECPグループ[RFC4753]認証ECDSA-256にある暗号化AES[RFC4754]

   Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
   MUST be supported by both parties in this suite.

_Phase2(IKEv1のための)かCREATE_CHILDをRekeyingして、双方はこのスイートでSA(IKEv2のための)をサポートしなければなりません。

3.2.  Suite "Suite-B-GCM-256"

3.2. スイート「スイート-B-GCM-256」

   This suite provides ESP integrity protection and confidentiality
   using 256-bit AES-GCM (see [RFC4106]).  This suite or the preceding
   suite should be used when ESP integrity protection and encryption are
   both needed.

このスイートは、256ビットのAES-GCMを使用することで保全保護と秘密性を超能力に提供します([RFC4106]を見てください)。 超能力保全保護と暗号化がともに必要であるときに、このスイートか前のスイートが使用されるべきです。

   ESP:
     Encryption     AES with 256-bit keys and 16-octet ICV in GCM mode
                      [RFC4106]
     Integrity      NULL

超能力: 256ビットのキーと16八重奏のICVがGCMモード[RFC4106]保全NULLにある暗号化AES

   IKEv1:
     Encryption                   AES with 256-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-384 [RFC4868]
     Hash                         SHA-384 [FIPS-180-2] [RFC4634]
     Diffie-Hellman group         384-bit random ECP group [RFC4753]
     Group Type                   ECP

IKEv1: 256ビットのキーがCBCモード[RFC3602]擬似ランダム機能HMAC-SHA-384[RFC4868]ハッシュSHA-384[FIPS-180-2][RFC4634]ディフィー-ヘルマングループ384ビットの無作為のECPグループ[RFC4753]グループType ECPにある暗号化AES

   For IKEv1, Phase 1 SHOULD use Main mode.  IKEv1 implementations MUST
   support pre-shared key authentication [RFC2409] for interoperability.
   The authentication method used with IKEv1 MAY be either pre-shared
   key [RFC2409] or ECDSA-384 [RFC4754].

IKEv1のために、Phase1SHOULDはMainモードを使用します。 IKEv1実装は、相互運用性のためにあらかじめ共有された主要な認証が[RFC2409]であるとサポートしなければなりません。 IKEv1と共に使用される認証方法は、あらかじめ共有されたキー[RFC2409]かECDSA-384のどちらかであるかもしれません[RFC4754]。

Law & Solinas                Informational                      [Page 3]

RFC 4869         Suite B Cryptographic Suites for IPsec         May 2007

IPsec2007年5月のための法とSolinasの情報[3ページ]のRFC4869のスイートのB暗号のスイート

   IKEv2:
     Encryption                   AES with 256-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-384 [RFC4868]
     Integrity                    HMAC-SHA-384-192 [RFC4868]
     Diffie-Hellman group         384-bit random ECP group [RFC4753]
     Authentication               ECDSA-384 [RFC4754]

IKEv2: 256ビットのキーがCBCモード[RFC3602]擬似ランダム機能HMAC-SHA-384[RFC4868]保全HMAC-SHA-384-192[RFC4868]ディフィー-ヘルマングループ384ビットの無作為のECPグループ[RFC4753]認証ECDSA-384にある暗号化AES[RFC4754]

   Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
   MUST be supported by both parties in this suite.

_Phase2(IKEv1のための)かCREATE_CHILDをRekeyingして、双方はこのスイートでSA(IKEv2のための)をサポートしなければなりません。

3.3.  Suite "Suite-B-GMAC-128"

3.3. スイート「スイート-B-GMAC-128」

   This suite provides ESP integrity protection using 128-bit AES-GMAC
   (see [RFC4543]) but does not provide confidentiality.  This suite or
   the following suite should be used only when there is no need for ESP
   encryption.

このスイートは、128ビットのAES-GMAC([RFC4543]を見る)を使用することで超能力保全保護を提供しますが、秘密性は提供しません。 超能力暗号化の必要は全くないときだけ、このスイートか以下のスイートが使用されるべきです。

   ESP:
     Encryption     NULL
     Integrity      AES with 128-bit keys in GMAC mode [RFC4543]

超能力: GMACモードによる128ビットのキーがある暗号化NULL Integrity AES[RFC4543]

   IKEv1:
     Encryption                   AES with 128-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-256 [RFC4868]
     Hash                         SHA-256 [FIPS-180-2] [RFC4634]
     Diffie-Hellman group         256-bit random ECP group [RFC4753]
     Group Type                   ECP

IKEv1: 128ビットのキーがCBCモード[RFC3602]擬似ランダム機能HMAC-SHA-256[RFC4868]ハッシュSHA-256[FIPS-180-2][RFC4634]ディフィー-ヘルマングループ256ビットの無作為のECPグループ[RFC4753]グループType ECPにある暗号化AES

   For IKEv1, Phase 1 SHOULD use Main mode.  IKEv1 implementations MUST
   support pre-shared key authentication [RFC2409] for interoperability.
   The authentication method used with IKEv1 MAY be either pre-shared
   key [RFC2409] or ECDSA-256 [RFC4754].

IKEv1のために、Phase1SHOULDはMainモードを使用します。 IKEv1実装は、相互運用性のためにあらかじめ共有された主要な認証が[RFC2409]であるとサポートしなければなりません。 IKEv1と共に使用される認証方法は、あらかじめ共有されたキー[RFC2409]かECDSA-256のどちらかであるかもしれません[RFC4754]。

   IKEv2:
     Encryption                   AES with 128-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-256 [RFC4868]
     Integrity                    HMAC-SHA-256-128 [RFC4868]
     Diffie-Hellman group         256-bit random ECP group [RFC4753]
     Authentication               ECDSA-256 [RFC4754]

IKEv2: 128ビットのキーがCBCモード[RFC3602]擬似ランダム機能HMAC-SHA-256[RFC4868]保全HMAC-SHA-256-128[RFC4868]ディフィー-ヘルマングループ256ビットの無作為のECPグループ[RFC4753]認証ECDSA-256にある暗号化AES[RFC4754]

   Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
   MUST be supported by both parties in this suite.

_Phase2(IKEv1のための)かCREATE_CHILDをRekeyingして、双方はこのスイートでSA(IKEv2のための)をサポートしなければなりません。

Law & Solinas                Informational                      [Page 4]

RFC 4869         Suite B Cryptographic Suites for IPsec         May 2007

IPsec2007年5月のための法とSolinasの情報[4ページ]のRFC4869のスイートのB暗号のスイート

3.4.  Suite "Suite-B-GMAC-256"

3.4. スイート「スイート-B-GMAC-256」

   This suite provides ESP integrity protection using 256-bit AES-GMAC
   (see [RFC4543]) but does not provide confidentiality.  This suite or
   the preceding suite should be used only when there is no need for ESP
   encryption.

このスイートは、256ビットのAES-GMAC([RFC4543]を見る)を使用することで超能力保全保護を提供しますが、秘密性は提供しません。 超能力暗号化の必要は全くないときだけ、このスイートか前のスイートが使用されるべきです。

   ESP:
     Encryption     NULL
     Integrity      AES with 256-bit keys in GMAC mode [RFC4543]

超能力: GMACモードによる256ビットのキーがある暗号化NULL Integrity AES[RFC4543]

   IKEv1:
     Encryption                   AES with 256-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-384 [RFC4868]
     Hash                         SHA-384 [FIPS-180-2] [RFC4634]
     Diffie-Hellman group         384-bit random ECP group [RFC4753]
     Group Type                   ECP

IKEv1: 256ビットのキーがCBCモード[RFC3602]擬似ランダム機能HMAC-SHA-384[RFC4868]ハッシュSHA-384[FIPS-180-2][RFC4634]ディフィー-ヘルマングループ384ビットの無作為のECPグループ[RFC4753]グループType ECPにある暗号化AES

   For IKEv1, Phase 1 SHOULD use Main mode.  IKEv1 implementations MUST
   support pre-shared key authentication [RFC2409] for interoperability.
   The authentication method used with IKEv1 MAY be either pre-shared
   key [RFC2409] or ECDSA-384 [RFC4754].

IKEv1のために、Phase1SHOULDはMainモードを使用します。 IKEv1実装は、相互運用性のためにあらかじめ共有された主要な認証が[RFC2409]であるとサポートしなければなりません。 IKEv1と共に使用される認証方法は、あらかじめ共有されたキー[RFC2409]かECDSA-384のどちらかであるかもしれません[RFC4754]。

   IKEv2:
     Encryption                   AES with 256-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-384 [RFC4868]
     Integrity                    HMAC-SHA-384-192 [RFC4868]
     Diffie-Hellman group         384-bit random ECP group [RFC4753]
     Authentication               ECDSA-384 [RFC4754]

IKEv2: 256ビットのキーがCBCモード[RFC3602]擬似ランダム機能HMAC-SHA-384[RFC4868]保全HMAC-SHA-384-192[RFC4868]ディフィー-ヘルマングループ384ビットの無作為のECPグループ[RFC4753]認証ECDSA-384にある暗号化AES[RFC4754]

   Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
   MUST be supported by both parties in this suite.

_Phase2(IKEv1のための)かCREATE_CHILDをRekeyingして、双方はこのスイートでSA(IKEv2のための)をサポートしなければなりません。

4.  Security Considerations

4. セキュリティ問題

   This document inherits all of the security considerations of the
   IPsec, IKEv1, and IKEv2 documents.  See [CNSSP-15] for guidance on
   the use of AES in these suites for the protection of U.S. Government
   information.

このドキュメントはIPsec、IKEv1、およびIKEv2ドキュメントのセキュリティ問題のすべてを引き継ぎます。 指導に関してこれらのスイートでのAESの米国政府情報の保護の使用に[CNSSP-15]を見てください。

   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.

これらのスイートで指定されたセキュリティオプションのいくつかが、将来、特性をこのドキュメントが製作されたとき信じられていたものよりかなり弱くするように見つけられるかもしれません。

Law & Solinas                Informational                      [Page 5]

RFC 4869         Suite B Cryptographic Suites for IPsec         May 2007

IPsec2007年5月のための法とSolinasの情報[5ページ]のRFC4869のスイートのB暗号のスイート

5.  IANA Considerations

5. IANA問題

   IANA has created and will maintain a registry called "Cryptographic
   Suites for IKEv1, IKEv2, and IPsec" (see [IANA-Suites]).  The
   registry consists of a text string and an RFC number that lists the
   associated transforms.  The four new suites in this document have
   been added to this registry after approval by an expert designated by
   the IESG.

IANAは、作成して、「IKEv1、IKEv2、およびIPsecのための暗号のスイート」([IANA-スイート]を見る)と呼ばれる登録であると主張するでしょう。 登録は関連変換を記載するテキスト文字列とRFC番号から成ります。4つの新しいスイートが承認の後にIESGによって任命された専門家によって本書ではこの登録に加えられます。

   The new values for the registry are:

登録への新しい値は以下の通りです。

   Identifier              Defined in
   Suite-B-GCM-128         RFC 4869
   Suite-B-GCM-256         RFC 4869
   Suite-B-GMAC-128        RFC 4869
   Suite-B-GMAC-256        RFC 4869

スイート-B-GCM-128 RFC4869スイート-B-GCM-256 RFC4869スイート-B-GMAC-128 RFC4869スイート-B-GMAC-256 RFC4869年に定義された識別子

6.  References

6. 参照

6.1.  Normative References

6.1. 引用規格

   [FIPS-180-2]  FIPS 180-2 with change notice, "Secure Hash Standard",
                 National Institute of Standards and Technology,
                 February 2004.

変更通知がある[FIPS-180-2]FIPS180-2、「安全なハッシュ規格」、米国商務省標準技術局、2004年2月。

   [IANA-Suites] Internet Assigned Numbers Authority, "Cryptographic
                 Suites for IKEv1, IKEv2, and IPsec",
                 <http://www.iana.org/assignments/crypto-suites>.

[IANA-スイート] インターネットは数の権威、「IKEv1、IKEv2、およびIPsecのための暗号のスイート」、<暗号http://www.iana.org/課題/スイート>を割り当てました。

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

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

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

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

   [RFC4106]     Viega, J. and D. McGrew, "The Use of Galois/Counter
                 Mode (GCM) in IPsec Encapsulating Security Payload
                 (ESP)", RFC 4106, June 2005.

[RFC4106] ViegaとJ.とD.マグリュー、「セキュリティが有効搭載量(超能力)であるとカプセル化するIPsecにおけるガロア/カウンタモード(GCM)の使用」、RFC4106、2005年6月。

   [RFC4303]     Kent, S., "IP Encapsulating Security Payload (ESP)",
                 RFC 4303, December 2005.

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

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

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

Law & Solinas                Informational                      [Page 6]

RFC 4869         Suite B Cryptographic Suites for IPsec         May 2007

IPsec2007年5月のための法とSolinasの情報[6ページ]のRFC4869のスイートのB暗号のスイート

   [RFC4308]     Hoffman, P., "Cryptographic Suites for IPsec", RFC
                 4308, December 2005.

[RFC4308] ホフマン、P.、「IPsecのための暗号のスイート」、RFC4308、2005年12月。

   [RFC4543]     McGrew, D. and J. Viega, "The Use of Galois Message
                 Authentication Code (GMAC) in IPsec ESP and AH", RFC
                 4543, May 2006.

[RFC4543] マグリュー、D.、およびJ.Viega、「ガロアの通報認証の使用はIPsecで超能力をコード化します、そして、(GMAC)ああ」、RFC4543、2006年5月。

   [RFC4753]     Fu, D. and J. Solinas, "ECP Groups for IKE and IKEv2",
                 RFC 4753, November 2006.

[RFC4753] フー、D.、およびJ.Solinas、「ECPは2006年11月にIKEとIKEv2"、RFC4753年のために分類します」。

   [RFC4754]     Fu, D. and J. Solinas, "IKE and IKEv2 Authentication
                 Using ECDSA", RFC 4754, November 2006.

[RFC4754] フー、D.、J.Solinas、および「ECDSAを使用するIKEとIKEv2認証」、RFC4754、11月2006日

   [RFC4868]     Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-
                 SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May
                 2007.

[RFC4868] ケリー、S.、およびS.フランケル(「IPsecとHMAC-SHA-256、HMAC- SHA-384、およびHMAC-SHA-512を使用します」、RFC4868)は2007がそうするかもしれません。

6.2.  Informative References

6.2. 有益な参照

   [AES]         U.S. Department of Commerce/National Institute of
                 Standards and Technology, "Advanced Encryption Standard
                 (AES)", FIPS PUB 197, November 2001,
                 <http://csrc.nist.gov/publications/fips/index.html>.

[AES]米国商務省/米国商務省標準技術局、「エー・イー・エス(AES)」FIPSパブ197、2001年11月、<http://csrc.nist.gov/刊行物/fips/index.html>。

   [CNSSP-15]    Committee on National Security Systems, "National
                 Policy on the Use of the Advanced Encryption Standard
                 (AES) to Protect National Security Systems and National
                 Security Information", June 2003,
                 <http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf>.

[CNSSP-15]安全保障委員会システム、「国家安全保障システムを保護するエー・イー・エス(AES)と国家安全保障情報の使用での国策」、2003年6月(<http://www.cnss.gov/資産/pdf/cnssp_15_fs.pdf>)。

   [RFC4634]     Eastlake 3rd, D. and T. Hansen, "US Secure Hash
                 Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.

[RFC4634] イーストレーク3番目とD.とT.ハンセン、「米国の安全なハッシュアルゴリズム(SHAとHMAC-SHA)」、RFC4634、2006年7月。

   [SuiteB]      U.S. National Security Agency, "Fact Sheet NSA Suite B
                 Cryptography", July 2005, <http://www.nsa.gov/ia/
                 industry/crypto_Suite_b.cfm?MenuID=10.2.7>.

[SuiteB]米国国家安全保障局、「データ表NSAスイートB暗号」、2005年7月、<http://www.nsa.gov/ia/産業/暗号_スイート_b.cfm?MenuID=10.2.7>。

Law & Solinas                Informational                      [Page 7]

RFC 4869         Suite B Cryptographic Suites for IPsec         May 2007

IPsec2007年5月のための法とSolinasの情報[7ページ]のRFC4869のスイートのB暗号のスイート

Authors' Addresses

作者のアドレス

   Laurie E. Law
   National Information Assurance Research Laboratory
   National Security Agency

ローリーE.法の国家の情報保証研究所国家安全保障局

   EMail: lelaw@orion.ncsc.mil

メール: lelaw@orion.ncsc.mil

   Jerome A. Solinas
   National Information Assurance Research Laboratory
   National Security Agency

ジェロームA.Solinas国家の情報保証研究所国家安全保障局

   EMail: jasolin@orion.ncsc.mil

メール: jasolin@orion.ncsc.mil

Law & Solinas                Informational                      [Page 8]

RFC 4869         Suite B Cryptographic Suites for IPsec         May 2007

IPsec2007年5月のための法とSolinasの情報[8ページ]のRFC4869のスイートのB暗号のスイート

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   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, THE IETF TRUST 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.

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

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

Law & Solinas                Informational                      [Page 9]

法とSolinas情報です。[9ページ]