[要約] RFC 4869は、IPsecのためのSuite B暗号スイートに関する標準化ドキュメントであり、米国政府の要件に基づいて開発されました。その目的は、セキュアな通信を提供するために、強力な暗号アルゴリズムとプロトコルを定義することです。

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

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).

Copyright(C)IETF Trust(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.

このドキュメントでは、RFC 4308で指定されている2つのスイートと同様に、IPsec用の4つのオプションの暗号化ユーザーインターフェイススイート(「UIスイート」)を提案します。4つの新しいスイートは、米国国家安全保障局のスイート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. 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スイート」)を提案しています。 VPN-AとVPN-Bの2つのスイートは、現在一般的に使用されている企業VPNセキュリティの選択肢と予想される将来の選択肢をそれぞれ表しています。このドキュメントは、米国国家安全保障局のSuite Bアルゴリズム([SuiteB]を参照)の実装に基づく4つの新しいUIスイートを提案します。

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スイートと同様に、スイート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」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および「MAY」は、[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スイートは、ESP([RFC4303]を参照)、IKEv1およびIKEv2([RFC2409]および[RFC4306]を参照)の選択肢を提供します。 4つのスイートは、暗号化アルゴリズムの強度の選択と、カプセル化セキュリティペイロード(ESP)が機密性と完全性の両方を提供するか、または完全性のみを提供するかを選択することによって区別されます。スイート名は、ESPに指定されたAdvanced Encryption Standard [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スイートを使用するIPsec実装は、ここにリストされているスイート名を使用する必要があります(SHOULD)。 IPsec実装は、ここに記載されているスイートと異なる名前を使用してはならず(SHOULD NOT)、これらの値と一致しないスイートには、ここに記載されている名前を使用してはなりません(MUST NOT)。これらの要件は相互運用性のために必要です。

3.1. Suite "Suite-B-GCM-128"
3.1. スイート「Suite-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整合性保護と機密性を提供します。このスイートまたは次のスイートは、ESP整合性保護と暗号化の両方が必要な場合に使用する必要があります。

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

ESP:128ビットキーとGCMモードの16オクテット整合性チェック値(ICV)を使用した暗号化AES [RFC4106]整合性NULL

   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
        

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の場合、フェーズ1はメインモードを使用する必要があります(SHOULD)。 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]
        

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

フェーズ2(IKEv1の場合)またはCREATE_CHILD_SA(IKEv2の場合)の鍵の再生成は、このスイートの両方のパーティでサポートされている必要があります。

3.2. Suite "Suite-B-GCM-256"
3.2. スイート「Suite-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整合性保護と機密性を提供します。このスイートまたは前述のスイートは、ESP整合性保護と暗号化の両方が必要な場合に使用する必要があります。

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

ESP:GCMモードの256ビットキーと16オクテットICVを使用した暗号化AES [RFC4106]整合性NULL

   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
        

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の場合、フェーズ1はメインモードを使用する必要があります(SHOULD)。 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]
        

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

フェーズ2(IKEv1の場合)またはCREATE_CHILD_SA(IKEv2の場合)の鍵の再生成は、このスイートの両方のパーティでサポートされている必要があります。

3.3. Suite "Suite-B-GMAC-128"
3.3. スイート「Suite-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整合性保護を提供しますが、機密性は提供しません。このスイートまたは次のスイートは、ESP暗号化が必要ない場合にのみ使用してください。

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

ESP:GMACモードの128ビットキーを使用した暗号化NULL整合性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
        

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の場合、フェーズ1はメインモードを使用する必要があります(SHOULD)。 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]
        

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

フェーズ2(IKEv1の場合)またはCREATE_CHILD_SA(IKEv2の場合)の鍵の再生成は、このスイートの両方のパーティでサポートされている必要があります。

3.4. Suite "Suite-B-GMAC-256"
3.4. スイート「Suite-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整合性保護を提供しますが、機密性は提供しません。このスイートまたは前述のスイートは、ESP暗号化が必要ない場合にのみ使用してください。

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

ESP:GMACモードの256ビットキーによる暗号化NULL整合性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
        

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の場合、フェーズ1はメインモードを使用する必要があります(SHOULD)。 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]
        

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

フェーズ2(IKEv1の場合)またはCREATE_CHILD_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.

これらのスイートで指定されているセキュリティオプションのいくつかは、このドキュメントが作成されたときに信じられていたものよりも著しく弱いプロパティを持つことが将来的に見つかる可能性があります。

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-Suites]を参照)。レジストリは、関連する変換をリストするテキスト文字列と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

Suite-B-GCM-128 RFC 4869 Suite-B-GCM-256 RFC 4869 Suite-B-GMAC-128 RFC 4869 Suite-B-GMAC-256 RFC 4869で定義された識別子

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]変更通知付きのFIPS 180-2、「Secure Hash Standard」、国立標準技術研究所、2004年2月。

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

[IANA-Suites] Internet Assigned Numbers Authority、「Cryptographic Suites for IKEv1、IKEv2、およびIPsec」、<http://www.iana.org/assignments/crypto-suites>。

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

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

[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. McGrew、「IPsecカプセル化セキュリティペイロード(ESP)でのガロア/カウンターモード(GCM)の使用」、RFC 4106、2005年6月。

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

[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード(ESP)」、RFC 4303、2005年12月。

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

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

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

[RFC4308]ホフマン、P。、「IPsecの暗号スイート」、RFC 4308、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] McGrew、D。およびJ. Viega、「IPsec ESPおよびAHでのガロアメッセージ認証コード(GMAC)の使用」、RFC 4543、2006年5月。

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

[RFC4753] Fu、D。およびJ. Solinas、「IKEおよびIKEv2のECPグループ」、RFC 4753、2006年11月。

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

[RFC4754] Fu、D。およびJ. Solinas、「IKESおよびIKEv2 Authentication Using ECDSA」、RFC 4754、2006年11月。

[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の使用」、RFC 4868、2007年5月。

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]米国商務省/国立標準技術研究所、「Advanced Encryption Standard(AES)」、FIPS PUB 197、2001年11月、<http://csrc.nist.gov/publications/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/ Assets / 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] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms(SHA and HMAC-SHA)」、RFC 4634、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 Suite B暗号化」、2005年7月、<http://www.nsa.gov/ia/ Industry / crypto_Suite_b.cfm?MenuID = 10.2.7>。

Authors' Addresses

著者のアドレス

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

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

   EMail: lelaw@orion.ncsc.mil
        

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

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

   EMail: jasolin@orion.ncsc.mil
        

Full Copyright Statement

完全な著作権表示

Copyright (C) The IETF Trust (2007).

Copyright(C)IETF Trust(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.

このドキュメントは、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, 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は、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 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は、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。

Acknowledgement

謝辞

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

RFC Editor機能への資金提供は、現在Internet Societyから提供されています。