RFC 4432 - RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4432
タイトル : RFC 4432 - 安全なシェル（SSH）輸送層プロトコルのRSAキー交換
翻訳編集 : 自動生成

[要約] RFC 4432は、SSHトランスポート層プロトコルのためのRSA鍵交換に関する規格です。このRFCの目的は、SSHセッションのセキュリティを向上させるために、RSA鍵交換アルゴリズムを提供することです。

Network Working Group                                          B. Harris
Request for Comments: 4432                                    March 2006
Category: Standards Track

RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol

安全なシェル（SSH）輸送層プロトコルのRSAキー交換

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 a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption. It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems.

このメモは、Rivest-Shamir-Adleman（RSA）Public-Key暗号化に基づくSecure Shell（SSH）プロトコルのキー交換方法について説明しています。コアプロトコルの一部として指定されたdiffie-hellmanアルゴリズムよりもはるかに少ないクライアントCPU時間を使用するため、クライアントシステムが遅いために特に適しています。

1. Introduction

1. はじめに

Secure Shell (SSH) [RFC4251] is a secure remote-login protocol. The core protocol uses Diffie-Hellman key exchange. On slow CPUs, this key exchange can take tens of seconds to complete, which can be irritating for the user. A previous version of the SSH protocol, described in [SSH1], uses a key-exchange method based on Rivest-Shamir-Adleman (RSA) public-key encryption, which consumes an order of magnitude less CPU time on the client, and hence is particularly suitable for slow client systems such as mobile devices. This memo describes a key-exchange mechanism for the version of SSH described in [RFC4251] that is similar to that used by the older version, and about as fast, while retaining the security advantages of the newer protocol.

Secure Shell（SSH）[RFC4251]は、安全なリモートロジンプロトコルです。コアプロトコルは、Diffie-Hellman Key Exchangeを使用します。遅いCPUでは、このキーエクスチェンジは完了するのに数秒かかる場合があります。これはユーザーにとって刺激的です。[SSH1]で説明されているSSHプロトコルの以前のバージョンは、Rivest-Shamir-Adleman（RSA）Public-Key暗号化に基づいたキー交換方法を使用しています。モバイルデバイスなどのクライアントシステムの遅いシステムに特に適しています。このメモは、[RFC4251]で説明されているSSHのバージョンのキー交換メカニズムを説明します。これは、古いバージョンで使用されているものと類似しており、新しいプロトコルのセキュリティ上の利点を保持しながら、ほぼ速いです。

2. Conventions Used in This Document

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

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

このドキュメントの「必須」と「すべき」キーワードは、[RFC2119]で説明されているように解釈されます。

The data types "byte", "string", and "mpint" are defined in Section 5 of [RFC4251].

データ型「バイト」、「文字列」、および「MPINT」は、[RFC4251]のセクション5で定義されています。

Other terminology and symbols have the same meaning as in [RFC4253].

他の用語とシンボルは、[RFC4253]と同じ意味を持っています。

3. Overview

3. 概要

The RSA key-exchange method consists of three messages. The server sends to the client an RSA public key, K_T, to which the server holds the private key. This may be a transient key generated solely for this SSH connection, or it may be re-used for several connections. The client generates a string of random bytes, K, encrypts it using K_T, and sends the result back to the server, which decrypts it. The client and server each hash K, K_T, and the various key-exchange parameters to generate the exchange hash, H, which is used to generate the encryption keys for the session, and the server signs H with its host key and sends the signature to the client. The client then verifies the host key as described in Section 8 of [RFC4253].

RSAキー交換メソッドは、3つのメッセージで構成されています。サーバーは、クライアントにRSA公開キーK_Tを送信し、サーバーが秘密鍵を保持します。これは、このSSH接続のみで生成される一時的なキーであるか、いくつかの接続に対して再利用される場合があります。クライアントは、k_tを使用して一連のランダムバイトkが生成し、k_tを使用して暗号化し、結果をサーバーに送り返します。クライアントとサーバーは、各ハッシュk、k_t、およびセッションの暗号化キーを生成するために使用されるExchange Hash hash、Hash Hash hを生成するためのさまざまなキー交換パラメーター、およびHostキーでHに署名して署名を送信しますクライアントに。次に、[RFC4253]のセクション8で説明されているように、クライアントはホストキーを検証します。

This method provides explicit server identification as defined in Section 7 of [RFC4253]. It requires a signature-capable host key.

この方法は、[RFC4253]のセクション7で定義されている明示的なサーバー識別を提供します。署名対応のホストキーが必要です。

4. Details

4. 詳細

The RSA key-exchange method has the following parameters:

RSAキー - 交換法には、次のパラメーターがあります。

HASH hash algorithm for calculating exchange hash, etc. HLEN output length of HASH in bits MINKLEN minimum transient RSA modulus length in bits

交換ハッシュなどを計算するためのハッシュハッシュアルゴリズム。ビット中のハッシュのHLEN出力の長さミンクレン最小一時的なRSAモジュラス長のビットの長さ

Their values are defined in Section 5 and Section 6 for the two methods defined by this document.

それらの値は、このドキュメントで定義された2つの方法について、セクション5およびセクション6で定義されています。

The method uses the following messages.

このメソッドは、次のメッセージを使用します。

First, the server sends:

最初に、サーバーは次のことを送信します。

byte SSH_MSG_KEXRSA_PUBKEY string server public host key and certificates (K_S) string K_T, transient RSA public key

BYTE SSH_MSG_KEXRSA_PUBKEY STRING SERVERパブリックホストキーと証明書（K_S）String K_T、TRANSIENT RSA公開キー

The key K_T is encoded according to the "ssh-rsa" scheme described in Section 6.6 of [RFC4253]. Note that unlike an "ssh-rsa" host key, K_T is used only for encryption, and not for signature. The modulus of K_T MUST be at least MINKLEN bits long.

キーK_Tは、[RFC4253]のセクション6.6で説明されている「SSH-RSA」スキームに従ってエンコードされます。「SSH-RSA」ホストキーとは異なり、K_Tは暗号化にのみ使用され、署名には使用されません。K_Tのモジュラスは、少なくともミンクレンビットの長さでなければなりません。

The client generates a random integer, K, in the range 0 <= K < 2^(KLEN-2*HLEN-49), where KLEN is the length of the modulus of K_T, in bits. The client then uses K_T to encrypt:

クライアントは、範囲0 <= k <2^（klen-2*hlen-49）でランダム整数kを生成します。ここで、klenはk_tの弾性率の長さ、ビットです。その後、クライアントはK_Tを使用して暗号化します。

mpint K, the shared secret

Mpint K、共有秘密

The encryption is performed according to the RSAES-OAEP scheme of [RFC3447], with a mask generation function of MGF1-with-HASH, a hash of HASH, and an empty label. See Appendix A for a proof that the encoding of K is always short enough to be thus encrypted. Having performed the encryption, the client sends:

暗号化は、[RFC3447]のRSAES-OAEPスキームに従って実行され、マスク生成関数はハッシュ、ハッシュのハッシュ、および空のラベルのマスク生成関数を使用します。Kのエンコードが常に暗号化されるほど短いことの証明については、付録Aを参照してください。暗号化を実行した後、クライアントは次のように送信します。

byte SSH_MSG_KEXRSA_SECRET string RSAES-OAEP-ENCRYPT(K_T, K)

byte ssh_msg_kexrsa_secret string rsaes-oaep-encrypt（k_t、k）

Note that the last stage of RSAES-OAEP-ENCRYPT is to encode an integer as an octet string using the I2OSP primitive of [RFC3447]. This, combined with encoding the result as an SSH "string", gives a result that is similar, but not identical, to the SSH "mpint" encoding applied to that integer. This is the same encoding as is used by "ssh-rsa" signatures in [RFC4253].

RSAES-OAEP-Encryptの最後の段階は、[RFC3447]のi2OSP原始を使用して整数をオクテット文字列としてエンコードすることであることに注意してください。これは、結果をSSHの「文字列」としてエンコードすることと組み合わさって、その整数に適用されるSSH「mpint」エンコードと同一ではない結果を与えます。これは、[RFC4253]の「SSH-RSA」署名で使用されるのと同じエンコードです。

The server decrypts K. If a decryption error occurs, the server SHOULD send SSH_MESSAGE_DISCONNECT with a reason code of SSH_DISCONNECT_KEY_EXCHANGE_FAILED and MUST disconnect. Otherwise, the server responds with:

サーバーはKを復号化します。復号化エラーが発生した場合、サーバーはssh_disconnect_key_exchange_failedの理由でssh_message_disconnectを送信する必要があります。それ以外の場合、サーバーは以下で応答します。

byte SSH_MSG_KEXRSA_DONE string signature of H with host key

byte ssh_msg_kexrsa_done hostキー付きhの署名

The hash H is computed as the HASH hash of the concatenation of the following:

ハッシュHは、以下の連結のハッシュハッシュとして計算されます。

string V_C, the client's identification string (CR and LF excluded) string V_S, the server's identification string (CR and LF excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the host key string K_T, the transient RSA key string RSAES_OAEP_ENCRYPT(K_T, K), the encrypted secret mpint K, the shared secret

文字列v_c、クライアントの識別文字列（crおよびlf除外）文字列v_s、サーバーの識別文字列（crおよびlf除外）文字列i_c、クライアントのssh_msg_kexinit文字列i_sのペイロード、サーバーのssh_msg_kexinit文字列k_sのペイロード、ホストキー文字列k_t、一時的なRSAキー文字列rsaes_oaep_encrypt（k_t、k）、暗号化された秘密のmpint k、共有秘密

This value is called the exchange hash, and it is used to authenticate the key exchange. The exchange hash SHOULD be kept secret.

この値はExchange Hashと呼ばれ、キーエクスチェンジの認証に使用されます。交換ハッシュは秘密にしておく必要があります。

The signature algorithm MUST be applied over H, not the original data. Most signature algorithms include hashing and additional padding. For example, "ssh-dss" specifies SHA-1 hashing. In such cases, the data is first hashed with HASH to compute H, and H is then hashed again as part of the signing operation.

署名アルゴリズムは、元のデータではなくHに適用する必要があります。ほとんどの署名アルゴリズムには、ハッシュと追加のパディングが含まれます。たとえば、「SSH-DSS」はSHA-1ハッシュを指定します。そのような場合、データは最初にハッシュでハッシュしてHを計算し、その後、署名操作の一部としてHが再びハッシュされます。

5. rsa1024-sha1

5. RSA1024-SHA1

The "rsa1024-sha1" method specifies RSA key exchange as described above with the following parameters:

「RSA1024-SHA1」メソッドは、次のパラメーターで上記のようにRSAキー交換を指定します。

HASH SHA-1, as defined in [RFC3174] HLEN 160 MINKLEN 1024

[RFC3174]で定義されているハッシュSHA-1

6. rsa2048-sha256

6. RSA2048-SHA256

The "rsa2048-sha256" method specifies RSA key exchange as described above with the following parameters:

「RSA2048-SHA256」メソッドは、次のパラメーターで上記のようにRSAキー交換を指定します。

HASH SHA-256, as defined in [FIPS-180-2] HLEN 256 MINKLEN 2048

ハッシュSHA-256、[FIPS-180-2]で定義されているHlen 256 Minklen 2048

7. Message Numbers

7. メッセージ番号

The following message numbers are defined:

次のメッセージ番号が定義されています。

SSH_MSG_KEXRSA_PUBKEY 30 SSH_MSG_KEXRSA_SECRET 31 SSH_MSG_KEXRSA_DONE 32

8. Security Considerations

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

The security considerations in [RFC4251] apply.

[RFC4251]のセキュリティ上の考慮事項が適用されます。

If the RSA private key generated by the server is revealed, then the session key is revealed. The server should thus arrange to erase this from memory as soon as it is no longer required. If the same RSA key is used for multiple SSH connections, an attacker who can find the private key (either by factorising the public key or by other means) will gain access to all of the sessions that used that key. As a result, servers SHOULD use each RSA key for as few key exchanges as possible.

サーバーによって生成されたRSA秘密キーが明らかにされた場合、セッションキーが明らかになります。したがって、サーバーは、メモリが不要になったらすぐにこれを消去するように手配する必要があります。同じRSAキーが複数のSSH接続に使用されている場合、秘密鍵を見つけることができる攻撃者（公開鍵を考慮するか、他の手段で）は、そのキーを使用したすべてのセッションにアクセスできます。その結果、サーバーは各RSAキーを使用して、できるだけ少ないキー交換に使用する必要があります。

[RFC3447] recommends that RSA keys used with RSAES-OAEP not be used with other schemes, or with RSAES-OAEP using a different hash function. In particular, this means that K_T should not be used as a host key, or as a server key in earlier versions of the SSH protocol.

[RFC3447]は、RSAES-OAEPで使用されるRSAキーを他のスキームで使用しないか、別のハッシュ関数を使用してRSAES-OAEPで使用することを推奨しています。特に、これはK_Tをホストキーとして、またはSSHプロトコルの以前のバージョンのサーバーキーとして使用しないでください。

Like all key-exchange mechanisms, this one depends for its security on the randomness of the secrets generated by the client (the random number K) and the server (the transient RSA private key). In particular, it is essential that the client use a high-quality cryptographic pseudo-random number generator to generate K. Using a bad random number generator will allow an attacker to break all the encryption and integrity protection of the Secure Shell transport layer. See [RFC4086] for recommendations on random number generation.

すべてのキー交換メカニズムと同様に、これは、クライアント（乱数k）とサーバー（過渡RSA秘密キー）によって生成された秘密のランダム性にセキュリティに依存します。特に、クライアントが高品質の暗号化擬似ランダム数ジェネレーターを使用してKを生成することが不可欠です。悪い乱数ジェネレーターを使用すると、攻撃者は安全なシェル輸送層のすべての暗号化と整合性保護を破ることができます。乱数生成に関する推奨事項については、[RFC4086]を参照してください。

The size of transient key used should be sufficient to protect the encryption and integrity keys generated by the key-exchange method. For recommendations on this, see [RFC3766]. The strength of RSAES-OAEP is in part dependent on the hash function it uses. [RFC3447] suggests using a hash with an output length of twice the security level required, so SHA-1 is appropriate for applications requiring up to 80 bits of security, and SHA-256 for those requiring up to 128 bits.

使用される一時的なキーのサイズは、キー交換法によって生成される暗号化と完全性キーを保護するのに十分でなければなりません。これに関する推奨事項については、[RFC3766]を参照してください。RSAES-OAEPの強度は、使用するハッシュ関数に部分的に依存しています。[RFC3447]は、必要なセキュリティレベルの2倍の出力長でハッシュを使用することを提案するため、SHA-1は最大80ビットのセキュリティを必要とするアプリケーションに適しています。

Unlike the Diffie-Hellman key-exchange method defined by [RFC4253], this method allows the client to fully determine the shared secret, K. This is believed not to be significant, since K is only ever used when hashed with data provided in part by the server (usually in the form of the exchange hash, H). If an extension to SSH were to use K directly and to assume that it had been generated by Diffie-Hellman key exchange, this could produce a security weakness. Protocol extensions using K directly should be viewed with extreme suspicion.

[RFC4253]で定義されたdiffie-hellmanキーエクスチェンジメソッドとは異なり、この方法により、クライアントは共有秘密K.を完全に判断できます。これは重要ではないと考えられています。サーバーによって（通常、交換ハッシュ、hの形式）。SSHの拡張がKを直接使用し、Diffie-Hellman Key Exchangeによって生成されたと仮定する場合、これはセキュリティの弱点を生み出す可能性があります。Kを直接使用したプロトコル拡張は、極端な疑いで表示する必要があります。

This key-exchange method is designed to be resistant to collision attacks on the exchange hash, by ensuring that neither side is able to freely choose its input to the hash after seeing all of the other side's input. The server's last input is in SSH_MSG_KEXRSA_PUBKEY, before it has seen the client's choice of K. The client's last input is K and its RSA encryption, and the one-way nature of RSA encryption should ensure that the client cannot choose K so as to cause a collision.

このキー交換法は、どちらの側が反対側のすべての入力を確認した後にハッシュへの入力を自由に選択できないようにすることにより、交換ハッシュに対する衝突攻撃に耐性があるように設計されています。サーバーの最後の入力はssh_msg_kexrsa_pubkeyにあります。クライアントがKを選択する前に。クライアントの最後の入力はKとそのRSA暗号化であり、RSA暗号化の一方向の性質は、クライアントがKを選択できないようにする必要があります。衝突。

9. IANA Considerations

9. IANAの考慮事項

IANA has assigned the names "rsa1024-sha1" and "rsa2048-sha256" as Key Exchange Method Names in accordance with [RFC4250].

IANAは、[RSA1024-SHA1 "および「RSA2048-SHA256」という名前を[RFC4250]に従ってキー交換メソッド名に割り当てました。

10. Acknowledgements

10. 謝辞

The author acknowledges the assistance of Simon Tatham with the design of this key exchange method.

著者は、この重要な交換方法の設計でサイモン・タタムの支援を認めています。

The text of this document is derived in part from [RFC4253].

このドキュメントのテキストは、[RFC4253]から部分的に派生しています。

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

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

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

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

[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.

[RFC3447] Jonsson、J.およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA暗号仕様バージョン2.1」、RFC 3447、2003年2月。

[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.

[RFC4251] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。

[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.

[RFC4253] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）輸送層プロトコル」、RFC 4253、2006年1月。

[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.

[RFC4250] Lehtinen、S。およびC. Lonvick、「Secure Shell（SSH）プロトコルが割り当てられた数字」、RFC 4250、2006年1月。

[FIPS-180-2] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002.

[FIPS-180-2]国立標準技術研究所（NIST）、「Secure Hash Standard（SHS）」、FIPS Pub 180-2、2002年8月。

11.2. Informative References

11.2. 参考引用

[SSH1] Ylonen, T., "SSH -- Secure Login Connections over the Internet", 6th USENIX Security Symposium, pp. 37-42, July 1996.

[SSH1] Ylonen、T。、「SSH-インターネット上のセキュアログイン接続」、第6回USENIX Security Symposium、pp。37-42、1996年7月。

[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.

[RFC3766] Orman、H。およびP. Hoffman、「対称キーの交換に使用される公共キーの強度の決定」、BCP 86、RFC 3766、2004年4月。

[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.

[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。

Appendix A. On the Size of K

付録A. kのサイズで

   The requirements on the size of K are intended to ensure that it is
   always possible to encrypt it under K_T.  The mpint encoding of K
   requires a leading zero bit, padding to a whole number of bytes, and
   a four-byte length field, giving a maximum length in bytes,
   B = (KLEN-2*HLEN-49+1+7)/8 + 4 = (KLEN-2*HLEN-9)/8 (where "/" denotes
   integer division rounding down).

   The maximum length of message that can be encrypted using RSAEP-OAEP
   is defined by [RFC3447] in terms of the key length in bytes, which is
   (KLEN+7)/8.  The maximum length is thus L = (KLEN+7-2*HLEN-16)/8 =
   (KLEN-2*HLEN-9)/8.  Thus, the encoded version of K is always small
   enough to be encrypted under K_T.

Author's Address

著者の連絡先

Ben Harris 2a Eachard Road CAMBRIDGE CB4 1XA UNITED KINGDOM

ベン・ハリス2A各ロードケンブリッジCB4 1XAイギリス

   EMail: bjh21@bjh21.me.uk

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は、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

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

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