RFC 4635 - HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4635
タイトル : RFC 4635 - HMAC SHA（ハッシュメッセージ認証コード、セキュアハッシュアルゴリズム）TSIGアルゴリズム識別子
翻訳編集 : 自動生成

[要約] RFC 4635は、HMAC SHA（ハッシュメッセージ認証コード、セキュアハッシュアルゴリズム）TSIGアルゴリズム識別子に関する規格です。このRFCの目的は、DNSセキュリティ拡張（DNSSEC）において、TSIGアルゴリズムの識別子を定義することです。

Network Working Group                                    D. Eastlake 3rd
Request for Comments: 4635                         Motorola Laboratories
Category: Standards Track                                    August 2006

HMAC SHA TSIG Algorithm Identifiers

HMAC SHA TSIGアルゴリズム識別子

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

概要

Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently, identifiers have been specified only for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG.

ドメインネームシステムのTSIGリソースレコードを使用するには、暗号メッセージ認証コードを指定する必要があります。現在、識別子はHMAC MD5（ハッシュメッセージ認証コード、メッセージダイジェスト5）およびGSS（Generic Security Service）TSIGアルゴリズムに対してのみ指定されています。このドキュメントは、追加のHMAC SHA（Secure Hash Algorithm）TSIGアルゴリズムの識別子と実装要件を標準化し、TSIGでHMAC値の切り捨てを指定および処理する方法を標準化します。

Table of Contents

   1. Introduction ....................................................2
   2. Algorithms and Identifiers ......................................2
   3. Specifying Truncation ...........................................3
      3.1. Truncation Specification ...................................4
   4. TSIG Truncation Policy and Error Provisions .....................4
   5. IANA Considerations .............................................5
   6. Security Considerations .........................................5
   7. Normative References ............................................6
   8. Informative References. .........................................7

1. Introduction

1. はじめに

[RFC2845] specifies a TSIG Resource Record (RR) that can be used to authenticate DNS (Domain Name System [STD13]) queries and responses. This RR contains a domain name syntax data item that names the authentication algorithm used. [RFC2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for authentication codes using the HMAC (Hashed Message Authentication Code) [RFC2104] algorithm with the MD5 (Message Digest 5) [RFC1321] hash algorithm. IANA has also registered "gss-tsig" as an identifier for TSIG authentication where the cryptographic operations are delegated to the Generic Security Service (GSS) [RFC3645].

[RFC2845]は、DNS（ドメインネームシステム[STD13]）クエリと応答を認証するために使用できるTSIGリソースレコード（RR）を指定します。このRRには、使用される認証アルゴリズムを指定するドメイン名構文データ項目が含まれています。 [RFC2845]は、HMAC（ハッシュメッセージ認証コード）[RFC2104]アルゴリズムとMD5（メッセージダイジェスト5）[RFC1321]ハッシュアルゴリズムを使用する認証コードのHMAC-MD5.SIG-ALG.REG.INT名を定義します。 IANAは、暗号操作がGeneric Security Service（GSS）[RFC3645]に委任されるTSIG認証の識別子として「gss-tsig」も登録しました。

Note that use of TSIG presumes prior agreement, between the resolver and server involved, as to the algorithm and key to be used.

TSIGの使用は、使用されるアルゴリズムと鍵に関して、関連するリゾルバーとサーバーの間の事前の合意を前提としていることに注意してください。

In Section 2, this document specifies additional names for TSIG authentication algorithms based on US NIST SHA (United States, National Institute of Science and Technology, Secure Hash Algorithm) algorithms and HMAC and specifies the implementation requirements for those algorithms.

セクション2で、このドキュメントは、US NIST SHA（米国、国立科学技術研究所、セキュアハッシュアルゴリズム）アルゴリズムとHMACに基づくTSIG認証アルゴリズムの追加の名前を指定し、それらのアルゴリズムの実装要件を指定します。

In Section 3, this document specifies the effect of inequality between the normal output size of the specified hash function and the length of MAC (Message Authentication Code) data given in the TSIG RR. In particular, it specifies that a shorter-length field value specifies truncation and that a longer-length field is an error.

セクション3で、このドキュメントは、指定されたハッシュ関数の通常の出力サイズとTSIG RRで指定されたMAC（メッセージ認証コード）データの長さの間の不等式の影響を指定します。特に、長さが短いフィールド値は切り捨てを指定し、長さが長いフィールドはエラーであることを指定します。

In Section 4, policy restrictions and implications related to truncation are described and specified, as is a new error code to indicate truncation shorter than that permitted by policy.

セクション4では、ポリシーで許可されているよりも短い切り捨てを示す新しいエラーコードと同様に、切り捨てに関連するポリシーの制限と影響について説明および指定しています。

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

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

2. Algorithms and Identifiers

2. アルゴリズムと識別子

TSIG Resource Records (RRs) [RFC2845] are used to authenticate DNS queries and responses. They are intended to be efficient symmetric authentication codes based on a shared secret. (Asymmetric signatures can be provided using the SIG RR [RFC2931]. In particular, SIG(0) can be used for transaction signatures.) Used with a strong hash function, HMAC [RFC2104] provides a way to calculate such symmetric authentication codes. The only specified HMAC-based TSIG algorithm identifier has been HMAC-MD5.SIG-ALG.REG.INT, based on MD5 [RFC1321].

TSIGリソースレコード（RR）[RFC2845]は、DNSクエリと応答の認証に使用されます。これらは、共有シークレットに基づく効率的な対称認証コードであることを目的としています。（非対称署名は、SIG RR [RFC2931]を使用して提供できます。特に、SIG（0）はトランザクション署名に使用できます。）強力なハッシュ関数と共に使用されるHMAC [RFC2104]は、このような対称認証コードを計算する方法を提供します。指定された唯一のHMACベースのTSIGアルゴリズム識別子は、MD5 [RFC1321]に基づくHMAC-MD5.SIG-ALG.REG.INTです。

The use of SHA-1 [FIPS180-2, RFC3174], which is a 160-bit hash, as compared with the 128 bits for MD5, and additional hash algorithms in the SHA family [FIPS180-2, RFC3874, RFC4634] with 224, 256, 384, and 512 bits may be preferred in some cases. This is because increasingly successful cryptanalytic attacks are being made on the shorter hashes.

MD5の128ビットと比較して160ビットのハッシュであるSHA-1 [FIPS180-2、RFC3174]の使用、およびSHAファミリの追加のハッシュアルゴリズム[FIPS180-2、RFC3874、RFC4634]と224 、256、384、512ビットが好ましい場合があります。これは、より短いハッシュに対してますます成功する暗号解読攻撃が行われているためです。

Use of TSIG between a DNS resolver and server is by mutual agreement. That agreement can include the support of additional algorithms and criteria as to which algorithms and truncations are acceptable, subject to the restriction and guidelines in Sections 3 and 4 below. Key agreement can be by the TKEY mechanism [RFC2930] or some other mutually agreeable method.

DNSリゾルバーとサーバー間のTSIGの使用は、相互の合意によるものです。この合意には、以下のセクション3と4の制限とガイドラインに従って、どのアルゴリズムとトランケーションが許容されるかに関する追加のアルゴリズムと基準のサポートを含めることができます。鍵の合意は、TKEYメカニズム[RFC2930]またはその他の相互に合意できる方法によって行うことができます。

The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are included in the table below for convenience. Implementations that support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig and the other algorithms listed below.

現在のHMAC-MD5.SIG-ALG.REG.INTおよびgss-tsig識別子は、便宜上、以下の表に含まれています。 TSIGをサポートする実装は、HMAC SHA1とHMAC SHA256も実装する必要があり、gss-tsigと以下にリストされている他のアルゴリズムを実装できます（MAY）。

Mandatory HMAC-MD5.SIG-ALG.REG.INT Optional gss-tsig Mandatory hmac-sha1 Optional hmac-sha224 Mandatory hmac-sha256 Optional hamc-sha384 Optional hmac-sha512

必須HMAC-MD5.SIG-ALG.REG.INTオプションgss-tsig必須hmac-sha1オプションhmac-sha224必須hmac-sha256オプションhamc-sha384オプションhmac-sha512

SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.

96ビット（12オクテット）に切り捨てられたSHA-1を実装する必要があります（SHOULD）。

3. Specifying Truncation

3. 切り捨ての指定

When space is at a premium and the strength of the full length of an HMAC is not needed, it is reasonable to truncate the HMAC output and use the truncated value for authentication. HMAC SHA-1 truncated to 96 bits is an option available in several IETF protocols, including IPsec and TLS.

スペースが貴重で、HMACの全長の強度が必要ない場合は、HMAC出力を切り捨てて、切り捨てられた値を認証に使用するのが妥当です。 96ビットに切り捨てられたHMAC SHA-1は、IPsecやTLSを含むいくつかのIETFプロトコルで利用可能なオプションです。

The TSIG RR [RFC2845] includes a "MAC size" field, which gives the size of the MAC field in octets. However, [RFC2845] does not specify what to do if this MAC size differs from the length of the output of HMAC for a particular hash function. Truncation is indicated by a MAC size less than the HMAC size, as specified below.

TSIG RR [RFC2845]には、MACフィールドのサイズをオクテットで示す「MACサイズ」フィールドが含まれています。ただし、[RFC2845]は、このMACサイズが特定のハッシュ関数のHMACの出力の長さと異なる場合の対処方法を指定していません。以下で指定するように、切り捨てはHMACサイズよりも小さいMACサイズで示されます。

3.1. Truncation Specification

3.1. 打ち切り仕様

The specification for TSIG handling is changed as follows:

TSIG処理の仕様が次のように変更されました。

1. If "MAC size" field is greater than HMAC output length:

1. 「MACサイズ」フィールドがHMAC出力長より大きい場合：

This case MUST NOT be generated and, if received, MUST cause the packet to be dropped and RCODE 1 (FORMERR) to be returned.

このケースは生成されてはならず（MUST NOT）、受信された場合、パケットがドロップされ、RCODE 1（FORMERR）が返される必要があります。

2. If "MAC size" field equals HMAC output length:

2. 「MACサイズ」フィールドがHMAC出力長と等しい場合：

Operation is as described in [RFC2845], and the entire output HMAC output is present.

操作は[RFC2845]で説明されているとおりで、出力HMAC出力全体が存在します。

3. "MAC size" field is less than HMAC output length but greater than that specified in case 4, below:

3. 「MACサイズ」フィールドは、HMAC出力長未満ですが、以下のケース4で指定された長さを超えています。

This is sent when the signer has truncated the HMAC output to an allowable length, as described in RFC 2104, taking initial octets and discarding trailing octets. TSIG truncation can only be to an integral number of octets. On receipt of a packet with truncation thus indicated, the locally calculated MAC is similarly truncated and only the truncated values are compared for authentication. The request MAC used when calculating the TSIG MAC for a reply is the truncated request MAC.

これは、RFC 2104で説明されているように、署名者がHMAC出力を許容される長さに切り捨て、最初のオクテットを取り、後続のオクテットを破棄したときに送信されます。 TSIGの切り捨ては、オクテットの整数に限定されます。このように切り捨てられたパケットを受信すると、ローカルで計算されたMACも同様に切り捨てられ、切り捨てられた値のみが認証のために比較されます。応答のTSIG MACを計算するときに使用される要求MACは、切り捨てられた要求MACです。

4. "MAC size" field is less than the larger of 10 (octets) and half the length of the hash function in use:

4. 「MACサイズ」フィールドは、使用されているハッシュ関数の長さの10（オクテット）と長さの半分よりも小さいです。

With the exception of certain TSIG error messages described in RFC 2845, Section 3.2, where it is permitted that the MAC size be zero, this case MUST NOT be generated and, if received, MUST cause the packet to be dropped and RCODE 1 (FORMERR) to be returned. The size limit for this case can also, for the hash functions mentioned in this document, be stated as less than half the hash function length for hash functions other than MD5 and less than 10 octets for MD5.

RFC 2845のセクション3.2に記載されている特定のTSIGエラーメッセージを除き、MACサイズをゼロにすることが許可されています。このケースは生成してはならず、受信した場合は、パケットをドロップしてRCODE 1（FORMERR ）返されます。この場合のサイズ制限は、このドキュメントで言及されているハッシュ関数の場合、MD5以外のハッシュ関数ではハッシュ関数の長さの半分未満、MD5では10オクテット未満としても記述できます。

4. TSIG Truncation Policy and Error Provisions

4. TSIG切り捨てポリシーとエラー規定

Use of TSIG is by mutual agreement between a resolver and server. Implicit in such "agreement" are criterion as to acceptable keys and algorithms and, with the extensions in this document, truncations. Note that it is common for implementations to bind the TSIG secret key or keys that may be in place at a resolver and server to particular algorithms. Thus, such implementations only permit the use of an algorithm if there is an associated key in place. Receipt of an unknown, unimplemented, or disabled algorithm typically results in a BADKEY error.

TSIGの使用は、リゾルバーとサーバー間の相互合意によるものです。このような「合意」に含まれる暗黙的なものは、受け入れ可能なキーとアルゴリズムに関する基準であり、このドキュメントの拡張機能では切り捨てられます。実装では、リゾルバーとサーバーにあるTSIG秘密鍵を特定のアルゴリズムにバインドするのが一般的であることに注意してください。したがって、そのような実装では、関連する鍵が所定の場所にある場合にのみアルゴリズムの使用が許可されます。不明な、実装されていない、または無効になっているアルゴリズムを受信すると、通常はBADKEYエラーが発生します。

Local policies MAY require the rejection of TSIGs, even though they use an algorithm for which implementation is mandatory.

ローカルポリシーでは、実装が必須のアルゴリズムを使用している場合でも、TSIGの拒否が必要になる場合があります。

When a local policy permits acceptance of a TSIG with a particular algorithm and a particular non-zero amount of truncation, it SHOULD also permit the use of that algorithm with lesser truncation (a longer MAC) up to the full HMAC output.

ローカルポリシーが特定のアルゴリズムと特定のゼロ以外の量の切り捨てによるTSIGの受け入れを許可する場合、完全なHMAC出力まで、より少ない切り捨て（長いMAC）でそのアルゴリズムの使用も許可する必要があります（SHOULD）。

Regardless of a lower acceptable truncated MAC length specified by local policy, a reply SHOULD be sent with a MAC at least as long as that in the corresponding request, unless the request specified a MAC length longer than the HMAC output.

ローカルポリシーで指定された受け入れ可能な切り詰められたMACの長さの下限に関係なく、要求がHMAC出力よりも長いMAC長を指定していない限り、少なくとも対応する要求と同じ長さのMACで応答を送信する必要があります。

Implementations permitting multiple acceptable algorithms and/or truncations SHOULD permit this list to be ordered by presumed strength and SHOULD allow different truncations for the same algorithm to be treated as separate entities in this list. When so implemented, policies SHOULD accept a presumed stronger algorithm and truncation than the minimum strength required by the policy.

複数の許容可能なアルゴリズムや切り捨てを許可する実装では、このリストを推定強度で並べることを許可する必要があり（SHOULD）、同じアルゴリズムの異なる切り捨てをこのリストで別のエンティティとして扱うことを許可する必要があります（SHOULD）。そのように実装された場合、ポリシーは、ポリシーが必要とする最小強度よりも強力な推定アルゴリズムと切り捨てを受け入れる必要があります（SHOULD）。

If a TSIG is received with truncation that is permitted under Section 3 above but the MAC is too short for the local policy in force, an RCODE of 22 (BADTRUNC) MUST be returned.

上記のセクション3で許可されている切り捨てでTSIGを受信したが、MACが有効なローカルポリシーに対して短すぎる場合は、RCODE 22（BADTRUNC）を返さなければなりません（MUST）。

5. IANA Considerations

5. IANAに関する考慮事項

This document (1) registers the new TSIG algorithm identifiers listed in Section 2 with IANA and (2) allocates the BADTRUNC RCODE 22 in Section 4 [RFC2845].

このドキュメントでは、（1）セクション2にリストされた新しいTSIGアルゴリズム識別子をIANAに登録し、（2）セクション4のBADTRUNC RCODE 22を割り当てます[RFC2845]。

6. Security Considerations

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

For all of the message authentication code algorithms listed herein, those producing longer values are believed to be stronger; however, while there have been some arguments that mild truncation can strengthen a MAC by reducing the information available to an attacker, excessive truncation clearly weakens authentication by reducing the number of bits an attacker has to try to break the authentication by brute force [RFC2104].

ここにリストされたすべてのメッセージ認証コードアルゴリズムについて、より長い値を生成するアルゴリズムはより強力であると考えられています。ただし、攻撃者が利用できる情報を減らすことで軽度の切り捨てがMACを強化する可能性があるといういくつかの議論がありますが、過度の切り捨ては、攻撃者がブルートフォースによって認証を破ろうとする必要があるビット数を減らすことで認証を明らかに弱めます[RFC2104] 。

Significant progress has been made recently in cryptanalysis of hash function of the types used herein, all of which ultimately derive from the design of MD4. While the results so far should not effect HMAC, the stronger SHA-1 and SHA-256 algorithms are being made mandatory due to caution.

ここで使用されているタイプのハッシュ関数の暗号解読において、最近大きな進歩があり、それらはすべて最終的にMD4の設計に由来しています。これまでの結果はHMACに影響しないはずですが、より強力なSHA-1およびSHA-256アルゴリズムは注意のために必須になっています。

See the Security Considerations section of [RFC2845]. See also the Security Considerations section of [RFC2104] from which the limits on truncation in this RFC were taken.

[RFC2845]のセキュリティに関する考慮事項のセクションを参照してください。 [RFC2104]のセキュリティに関する考慮事項のセクションも参照してください。このセクションでは、このRFCの切り捨ての制限が適用されています。

7. Normative References

7. 引用文献

[FIPS180-2] "Secure Hash Standard", (SHA-1/224/256/384/512) US Federal Information Processing Standard, with Change Notice 1, February 2004.

[FIPS180-2]「Secure Hash Standard」、（SHA-1 / 224/256/384/512）US Federal Information Processing Standard、変更通知1、2004年2月。

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.

[RFC1321] Rivest、R。、「MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。

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

[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。

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

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.

[RFC2845] Vixie、P.、Gudmundsson、O.、Eastlake 3rd、D。、およびB. Wellington、「DNSの秘密鍵トランザクション認証（TSIG）」、RFC 2845、2000年5月。

[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.

[RFC3174] Eastlake 3rd、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。

[RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", RFC 3874, September 2004.

[RFC3874] Housley、R。、「224ビット一方向ハッシュ関数：SHA-224」、RFC 3874、2004年9月。

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

[RFC4634] Eastlake、D。およびT. Hansen、「US Secure Hash Algorithms（SHA）」、RFC 4634、2006年7月。

[STD13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[STD13] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。

8. Informative References.

8. 有益な参照。

[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.

[RFC2930] Eastlake 3rd、D。、「DNSの秘密鍵の確立（TKEY RR）」、RFC 2930、2000年9月。

[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.

[RFC2931] Eastlake 3rd、D。、「DNS Request and Transaction Signatures（SIG（0）s）」、RFC 2931、2000年9月。

[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., and R. Hall, "Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October 2003.

[RFC3645] Kwan、S.、Garg、P.、Gilroy、J.、Esibov、L.、Westhead、J。、およびR. Hall、「DNSの秘密鍵トランザクション認証のための汎用セキュリティサービスアルゴリズム（GSS-TSIG） "、RFC 3645、2003年10月。

Author's Address

著者のアドレス

Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA

Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford、MA 01757 USA

   Phone: +1-508-786-7554 (w)
   EMail: Donald.Eastlake@motorola.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 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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。