RFC 5288 - AES Galois Counter Mode (GCM) Cipher Suites for TLS 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5288
タイトル : RFC 5288 - TLS用のAES Galois Counter Mode（GCM）暗号スイート
翻訳編集 : 自動生成

[要約] RFC 5288は、TLS (Transport Layer Security) プロトコルにおいて、AES (Advanced Encryption Standard) Galois Counter Mode (GCM) 暗号スイートを定義しています。この文書の目的は、データの機密性と完全性を保護するために、より強力な暗号化方式をTLSに導入することです。AES-GCMは、効率的な暗号化と認証を同時に提供し、ネットワーク通信のセキュリティを強化します。このRFCは、TLSのセキュリティを向上させるために、特にウェブブラウザやサーバ間の安全な通信に利用されます。関連するRFCには、RFC 5246 (TLS 1.2の定義) やRFC 5289 (TLSのElliptic Curve Cryptography (ECC) サイファースイート) などがあります。

Network Working Group                                         J. Salowey
Request for Comments: 5288                                  A. Choudhury
Category: Standards Track                                      D. McGrew
                                                     Cisco Systems, Inc.
                                                             August 2008

AES Galois Counter Mode (GCM) Cipher Suites for TLS

TLS用のAES Galois Counter Mode（GCM）暗号スイート

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

概要

This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms.

このメモは、ガロア/カウンターモード（GCM）でのAdvanced Encryption Standard（AES）のトランスポート層セキュリティ（TLS）認証済み暗号化操作としての使用について説明しています。 GCMは機密性とデータ発信元認証の両方を提供し、ハードウェアに効率的に実装して毎秒10ギガビット以上の速度を実現でき、ソフトウェアの実装にも適しています。このメモは、RSA、DSA、およびDiffie-Hellmanベースの鍵交換メカニズムでAES-GCMを使用するTLS暗号スイートを定義します。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 2
   3.  AES-GCM Cipher Suites . . . . . . . . . . . . . . . . . . . . . 2
   4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
     6.1.  Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 4
     6.2.  Recommendations for Multiple Encryption Processors  . . . . 4
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6

1. Introduction

1. はじめに

This document describes the use of AES [AES] in Galois Counter Mode (GCM) [GCM] (AES-GCM) with various key exchange mechanisms as a cipher suite for TLS. AES-GCM is an authenticated encryption with associated data (AEAD) cipher (as defined in TLS 1.2 [RFC5246]) providing both confidentiality and data origin authentication. The following sections define cipher suites based on RSA, DSA, and Diffie-Hellman key exchanges; ECC-based (Elliptic Curve Cryptography) cipher suites are defined in a separate document [RFC5289].

このドキュメントでは、ガロアカウンターモード（GCM）でのAES [AES]の使用について説明します。[GCM]（AES-GCM）は、TLSの暗号スイートとしてさまざまな鍵交換メカニズムを備えています。 AES-GCMは、関連データ（AEAD）暗号（TLS 1.2 [RFC5246]で定義）による認証済み暗号化であり、機密性とデータ発信元認証の両方を提供します。以下のセクションでは、RSA、DSA、およびDiffie-Hellman鍵交換に基づく暗号スイートを定義します。 ECCベースの（Elliptic Curve Cryptography）暗号スイートは、別のドキュメント[RFC5289]で定義されています。

AES-GCM is not only efficient and secure, but hardware implementations can achieve high speeds with low cost and low latency, because the mode can be pipelined. Applications that require high data throughput can benefit from these high-speed implementations. AES-GCM has been specified as a mode that can be used with IPsec ESP [RFC4106] and 802.1AE Media Access Control (MAC) Security [IEEE8021AE].

AES-GCMは効率的で安全であるだけでなく、モードをパイプライン化できるため、ハードウェア実装は低コストで低遅延で高速を実現できます。高いデータスループットを必要とするアプリケーションは、これらの高速実装の恩恵を受けることができます。 AES-GCMは、IPsec ESP [RFC4106]および802.1AEメディアアクセスコントロール（MAC）セキュリティ[IEEE8021AE]で使用できるモードとして指定されています。

2. Conventions Used in This Document

2. このドキュメントで使用される規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. AES-GCM Cipher Suites

3. AES-GCM暗号スイート

The following cipher suites use the new authenticated encryption modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:

次の暗号スイートは、Galois Counter Mode（GCM）[GCM]のAESでTLS 1.2で定義された新しい認証済み暗号化モードを使用します。

      CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C}
      CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D}
      CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}
      CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}
      CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0xA0}
      CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0xA1}
      CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}
      CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}
      CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA4}
      CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA5}
      CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6}
      CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7}

These cipher suites use the AES-GCM authenticated encryption with associated data (AEAD) algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in [RFC5116]. Note that each of these AEAD algorithms uses a 128-bit authentication tag with GCM (in particular, as described in Section 3.5 of [RFC4366], the

これらの暗号スイートは、[RFC5116]で説明されている関連データ（AEAD）アルゴリズムAEAD_AES_128_GCMおよびAEAD_AES_256_GCMでAES-GCM認証暗号化を使用します。これらの各AEADアルゴリズムはGCMで128ビット認証タグを使用することに注意してください（特に、[RFC4366]のセクション3.5で説明されているように、

"truncated_hmac" extension does not have an effect on cipher suites that do not use HMAC). The "nonce" SHALL be 12 bytes long consisting of two parts as follows: (this is an example of a "partially explicit" nonce; see Section 3.2.1 in [RFC5116]).

「truncated_hmac」拡張は、HMACを使用しない暗号スイートには影響しません。「ノンス」は、次の2つの部分で構成される12バイトの長さである必要があります（これは「部分的に明示的な」ナンスの例です。[RFC5116]のセクション3.2.1を参照してください）。

             struct {
                opaque salt[4];
                opaque nonce_explicit[8];
             } GCMNonce;

The salt is the "implicit" part of the nonce and is not sent in the packet. Instead, the salt is generated as part of the handshake process: it is either the client_write_IV (when the client is sending) or the server_write_IV (when the server is sending). The salt length (SecurityParameters.fixed_iv_length) is 4 octets.

ソルトはノンスの「暗黙の」部分であり、パケットで送信されません。代わりに、ソルトはハンドシェイクプロセスの一部として生成されます。これは、client_write_IV（クライアントが送信する場合）またはserver_write_IV（サーバーが送信する場合）のいずれかです。ソルト長（SecurityParameters.fixed_iv_length）は4オクテットです。

The nonce_explicit is the "explicit" part of the nonce. It is chosen by the sender and is carried in each TLS record in the GenericAEADCipher.nonce_explicit field. The nonce_explicit length (SecurityParameters.record_iv_length) is 8 octets.

nonce_explicitはnonceの「明示的な」部分です。これは送信者によって選択され、GenericAEADCipher.nonce_explicitフィールドの各TLSレコードで伝達されます。 nonce_explicitの長さ（SecurityParameters.record_iv_length）は8オクテットです。

Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number.

nonce_explicitの各値は、固定キーのGCM暗号化関数の呼び出しごとに異なる必要があります。この一意性の要件を満たさないと、セキュリティが大幅に低下する可能性があります。 nonce_explicitは64ビットのシーケンス番号である場合があります。

The RSA, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges are performed as defined in [RFC5246].

RSA、DHE_RSA、DH_RSA、DHE_DSS、DH_DSS、およびDH_anonの鍵交換は、[RFC5246]の定義に従って実行されます。

The Pseudo Random Function (PRF) algorithms SHALL be as follows:

疑似ランダム関数（PRF）アルゴリズムは次のようにする必要があります。

For cipher suites ending with _SHA256, the PRF is the TLS PRF [RFC5246] with SHA-256 as the hash function.

_SHA256で終わる暗号スイートの場合、PRFは、ハッシュ関数としてSHA-256を使用したTLS PRF [RFC5246]です。

For cipher suites ending with _SHA384, the PRF is the TLS PRF [RFC5246] with SHA-384 as the hash function.

_SHA384で終わる暗号スイートの場合、PRFは、ハッシュ関数としてSHA-384を使用したTLS PRF [RFC5246]です。

Implementations MUST send TLS Alert bad_record_mac for all types of failures encountered in processing the AES-GCM algorithm.

実装は、AES-GCMアルゴリズムの処理中に発生したすべてのタイプの障害について、TLSアラートbad_record_macを送信する必要があります。

4. TLS Versions

4. TLSバージョン

These cipher suites make use of the authenticated encryption with additional data defined in TLS 1.2 [RFC5246]. They MUST NOT be negotiated in older versions of TLS. Clients MUST NOT offer these cipher suites if they do not offer TLS 1.2 or later. Servers that select an earlier version of TLS MUST NOT select one of these cipher suites. Because TLS has no way for the client to indicate that it supports TLS 1.2 but not earlier, a non-compliant server might potentially negotiate TLS 1.1 or earlier and select one of the cipher suites in this document. Clients MUST check the TLS version and generate a fatal "illegal_parameter" alert if they detect an incorrect version.

これらの暗号スイートは、TLS 1.2 [RFC5246]で定義されている追加データで認証された暗号化を利用します。古いバージョンのTLSではネゴシエーションしてはなりません。クライアントは、TLS 1.2以降を提供しない場合、これらの暗号スイートを提供してはなりません（MUST NOT）。以前のバージョンのTLSを選択するサーバーは、これらの暗号スイートのいずれかを選択してはなりません（MUST NOT）。 TLSはクライアントがTLS 1.2をサポートしているがそれ以前はサポートしていないことを示す方法がないため、非準拠サーバーがTLS 1.1以前をネゴシエートし、このドキュメントの暗号スイートの1つを選択する可能性があります。クライアントは、TLSバージョンを確認し、不正なバージョンを検出した場合に致命的な「illegal_parameter」アラートを生成する必要があります。

5. IANA Considerations

5. IANAに関する考慮事項

IANA has assigned the following values for the cipher suites defined in this document:

IANAは、このドキュメントで定義されている暗号スイートに次の値を割り当てています。

      CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C}
      CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D}
      CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}
      CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}
      CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0xA0}
      CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0xA1}
      CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}
      CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}
      CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA4}
      CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA5}
      CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6}
      CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7}

6. Security Considerations

6. セキュリティに関する考慮事項

The security considerations in [RFC5246] apply to this document as well. The remainder of this section describes security considerations specific to the cipher suites described in this document.

[RFC5246]のセキュリティに関する考慮事項は、このドキュメントにも適用されます。このセクションの残りの部分では、このドキュメントで説明されている暗号スイートに固有のセキュリティに関する考慮事項について説明します。

6.1. Counter Reuse

6.1. カウンターの再利用

AES-GCM security requires that the counter is never reused. The IV construction in Section 3 is designed to prevent counter reuse.

AES-GCMセキュリティでは、カウンターを再利用しないでください。セクション3のIV構造は、カウンターの再利用を防ぐように設計されています。

Implementers should also understand the practical considerations of IV handling outlined in Section 9 of [GCM].

実装者は、[GCM]のセクション9で概説されているIV処理の実際的な考慮事項も理解する必要があります。

6.2. Recommendations for Multiple Encryption Processors

6.2. 複数の暗号化プロセッサの推奨事項

If multiple cryptographic processors are in use by the sender, then the sender MUST ensure that, for a particular key, each value of the nonce_explicit used with that key is distinct. In this case, each encryption processor SHOULD include, in the nonce_explicit, a fixed value that is distinct for each processor. The recommended format is

送信者が複数の暗号化プロセッサを使用している場合、送信者は、特定のキーについて、そのキーで使用されるnonce_explicitの各値が異なることを確認する必要があります。この場合、各暗号化プロセッサーは、nonce_explicitに、プロセッサーごとに異なる固定値を含める必要があります（SHOULD）。推奨フォーマットは

nonce_explicit = FixedDistinct || Variable

nonce_explicit = FixedDistinct ||変数

where the FixedDistinct field is distinct for each encryption processor, but is fixed for a given processor, and the Variable field is distinct for each distinct nonce used by a particular encryption processor. When this method is used, the FixedDistinct fields used by the different processors MUST have the same length.

ここで、FixedDistinctフィールドは暗号化プロセッサごとに異なりますが、特定のプロセッサに対して固定されており、Variableフィールドは特定の暗号化プロセッサによって使用される個別のナンスごとに異なります。このメソッドを使用する場合、異なるプロセッサで使用されるFixedDistinctフィールドは同じ長さでなければなりません。

In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common part of the nonce (it is fixed, and it is common across all encryption processors), the FixedDistinct field exactly corresponds to the Fixed-Distinct field, the Variable field corresponds to the Counter field, and the explicit part exactly corresponds to the nonce_explicit.

[RFC5116]の図2の用語では、ソルトはナンスの固定共通部分です（固定であり、すべての暗号化プロセッサで共通です）。固定ディスティンクトフィールドは、固定ディスティンクトフィールドに正確に対応しています。変数フィールドはCounterフィールドに対応し、明示的な部分はnonce_explicitに正確に対応します。

For clarity, we provide an example for TLS in which there are two distinct encryption processors, each of which uses a one-byte FixedDistinct field:

明確にするために、2つの異なる暗号化プロセッサがあり、それぞれが1バイトのFixedDistinctフィールドを使用するTLSの例を示します。

Salt = eedc68dc FixedDistinct = 01 (for the first encryption processor) FixedDistinct = 02 (for the second encryption processor)

Salt = eedc68dc FixedDistinct = 01（最初の暗号化プロセッサの場合）FixedDistinct = 02（2番目の暗号化プロセッサの場合）

The GCMnonces generated by the first encryption processor, and their corresponding nonce_explicit, are:

最初の暗号化プロセッサによって生成されたGCMnoncesとそれに対応するnonce_explicitは次のとおりです。

          GCMNonce                    nonce_explicit
          ------------------------    ----------------------------
          eedc68dc0100000000000000    0100000000000000
          eedc68dc0100000000000001    0100000000000001
          eedc68dc0100000000000002    0100000000000002
          ...

The GCMnonces generated by the second encryption processor, and their corresponding nonce_explicit, are

2番目の暗号化プロセッサによって生成されたGCMnoncesとそれに対応するnonce_explicitは、次のとおりです。

          GCMNonce                    nonce_explicit
          ------------------------    ----------------------------
          eedc68dc0200000000000000    0200000000000000
          eedc68dc0200000000000001    0200000000000001
          eedc68dc0200000000000002    0200000000000002
          ...

7. Acknowledgements

7. 謝辞

This document borrows heavily from [RFC5289]. The authors would like to thank Alex Lam, Simon Josefsson, and Pasi Eronen for providing useful comments during the review of this document.

この文書は[RFC5289]から大いに借りています。このドキュメントのレビュー中に有益なコメントを提供してくれたAlex Lam、Simon Josefsson、およびPasi Eronenに感謝します。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS 197, November 2001.

[AES]国立標準技術研究所、「Advanced Encryption Standard（AES）」、FIPS 197、2001年11月。

[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", National Institute of Standards and Technology SP 800- 38D, November 2007.

[GCM] Dworkin、M.、「ブロック暗号モードの動作に関する推奨事項：ガロア/カウンターモード（GCM）およびGMAC」、米国標準技術局SP 800-38D、2007年11月。

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

[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.

[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェースとアルゴリズム」、RFC 5116、2008年1月。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。

8.2. Informative References

8.2. 参考引用

[IEEE8021AE] Institute of Electrical and Electronics Engineers, "Media Access Control Security", IEEE Standard 802.1AE, August 2006.

[IEEE8021AE] Institute of Electrical and Electronics Engineers、「Media Access Control Security」、IEEE Standard 802.1AE、2006年8月。

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

[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.

[RFC4366] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、2006年4月。

[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode", RFC 5289, August 2008.

[RFC5289] Rescorla、E。、「SHA-256 / 384およびAES Galoisカウンターモードを使用したTLS楕円曲線暗号スイート」、RFC 5289、2008年8月。

Authors' Addresses

著者のアドレス

Joseph Salowey Cisco Systems, Inc. 2901 3rd. Ave Seattle, WA 98121 USA

ジョセフSaloweyシスコシステムズ社2901 3位。 Ave Seattle、WA 98121 USA

   EMail: jsalowey@cisco.com

Abhijit Choudhury Cisco Systems, Inc. 3625 Cisco Way San Jose, CA 95134 USA

Abhijit Choudhury Cisco Systems、Inc. 3625 Cisco Way San Jose、CA 95134 USA

   EMail: abhijitc@cisco.com

David McGrew Cisco Systems, Inc. 170 W Tasman Drive San Jose, CA 95134 USA

David McGrew Cisco Systems、Inc. 170 W Tasman Drive San Jose、CA 95134 USA

   EMail: mcgrew@cisco.com

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, 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に情報を送信してください。