[要約] RFC 2945は、SRP認証およびキー交換システムに関する仕様です。その目的は、安全な認証と鍵交換を提供することです。
Network Working Group T. Wu
Request for Comments: 2945 Stanford University
Category: Standards Track September 2000
The SRP Authentication and Key Exchange System
SRP認証とキー交換システム
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. This mechanism is suitable for negotiating secure connections using a user-supplied password, while eliminating the security problems traditionally associated with reusable passwords. This system also performs a secure key exchange in the process of authentication, allowing security layers (privacy and/or integrity protection) to be enabled during the session. Trusted key servers and certificate infrastructures are not required, and clients are not required to store or manage any long-term keys. SRP offers both security and deployment advantages over existing challenge-response techniques, making it an ideal drop-in replacement where secure password authentication is needed.
このドキュメントでは、セキュアリモートパスワード（SRP）プロトコルとして知られる暗号的に強力なネットワーク認証メカニズムについて説明します。このメカニズムは、再利用可能なパスワードに従来関連するセキュリティの問題を排除しながら、ユーザーがサプライされたパスワードを使用して安全な接続を交渉するのに適しています。また、このシステムは、認証のプロセスで安全なキー交換を実行し、セッション中にセキュリティレイヤー（プライバシーおよび/または整合性保護）を有効にすることができます。信頼できるキーサーバーと証明書インフラストラクチャは必要ありません。クライアントは、長期キーを保存または管理するために必要ではありません。SRPは、既存のチャレンジ応答技術よりもセキュリティと展開の利点を提供し、安全なパスワード認証が必要な場合の理想的なドロップイン交換となっています。
The lack of a secure authentication mechanism that is also easy to use has been a long-standing problem with the vast majority of Internet protocols currently in use. The problem is two-fold: Users like to use passwords that they can remember, but most password-based authentication systems offer little protection against even passive attackers, especially if weak and easily-guessed passwords are used.
使いやすい安全な認証メカニズムの欠如は、現在使用されているインターネットプロトコルの大部分にとって長年にわたる問題でした。問題は2つあります。ユーザーは覚えているパスワードを使用するのが好きですが、ほとんどのパスワードベースの認証システムは、特に弱くて簡単に推測されるパスワードを使用している場合、パスティブ攻撃者からも保護しません。
Eavesdropping on a TCP/IP network can be carried out very easily and very effectively against protocols that transmit passwords in the clear. Even so-called "challenge-response" techniques like the one described in [RFC 2095] and [RFC 1760], which are designed to defeat simple sniffing attacks, can be compromised by what is known as a "dictionary attack". This occurs when an attacker captures the messages exchanged during a legitimate run of the protocol and uses that information to verify a series of guessed passwords taken from a precompiled "dictionary" of common passwords. This works because users often choose simple, easy-to-remember passwords, which invariably are also easy to guess.
TCP/IPネットワーク上の盗聴は、クリアでパスワードを送信するプロトコルに対して非常に簡単かつ非常に効果的に実行できます。[RFC 2095]や[RFC 1760]に記載されているようないわゆる「チャレンジ応答」テクニックでさえ、単純なスニッフィング攻撃を倒すように設計されていますが、「辞書攻撃」として知られているものによって妥協することができます。これは、攻撃者がプロトコルの合法的な実行中に交換されたメッセージをキャプチャし、その情報を使用して、一般的なパスワードの事前にコンパイルされた「辞書」から取られた一連の推測されたパスワードを検証するときに発生します。これは、ユーザーが多くの場合、シンプルで覚えやすいパスワードを選択するため、常に簡単に推測できます。
Many existing mechanisms also require the password database on the host to be kept secret because the password P or some private hash h(P) is stored there and would compromise security if revealed. That approach often degenerates into "security through obscurity" and goes against the UNIX convention of keeping a "public" password file whose contents can be revealed without destroying system security.
また、多くの既存のメカニズムでは、パスワードPまたはいくつかのプライベートハッシュH（P）がそこに保存され、明らかにされた場合にセキュリティを妥協するため、ホストのパスワードデータベースを秘密にしておく必要があります。そのアプローチは、しばしば「あいまいさを通じてセキュリティ」に退化し、システムセキュリティを破壊することなく内容を明らかにできる「公開」パスワードファイルを維持するというUNIX条約に反します。
SRP meets the strictest requirements laid down in [RFC 1704] for a non-disclosing authentication protocol. It offers complete protection against both passive and active attacks, and accomplishes this efficiently using a single Diffie-Hellman-style round of computation, making it feasible to use in both interactive and non-interactive authentication for a wide range of Internet protocols. Since it retains its security when used with low-entropy passwords, it can be seamlessly integrated into existing user applications.
SRPは、非開示認証プロトコルのために[RFC 1704]で定められた最も厳しい要件を満たしています。パッシブ攻撃とアクティブな攻撃の両方に対する完全な保護を提供し、単一のdiffie-hellmanスタイルの計算ラウンドを使用してこれを効率的に達成し、幅広いインターネットプロトコルのインタラクティブおよび非インタラクティブ認証の両方で使用することができます。低エントロピーパスワードで使用するとセキュリティを保持するため、既存のユーザーアプリケーションにシームレスに統合できます。
The protocol described by this document is sometimes referred to as "SRP-3" for historical purposes. This particular protocol is described in [SRP] and is believed to have very good logical and cryptographic resistance to both eavesdropping and active attacks.
このドキュメントで説明されているプロトコルは、歴史的な目的のために「SRP-3」と呼ばれることもあります。この特定のプロトコルは[SRP]で説明されており、盗聴攻撃とアクティブな攻撃の両方に対して非常に優れた論理的および暗号化抵抗があると考えられています。
This document does not attempt to describe SRP in the context of any particular Internet protocol; instead it describes an abstract protocol that can be easily fitted to a particular application. For example, the specific format of messages (including padding) is not specified. Those issues have been left to the protocol implementor to decide.
このドキュメントは、特定のインターネットプロトコルのコンテキストでSRPを説明しようとはしません。代わりに、特定のアプリケーションに簡単に適合できる抽象プロトコルを説明します。たとえば、メッセージの特定の形式（パディングを含む）は指定されていません。これらの問題は、プロトコル実装者に決定するために任されています。
The one implementation issue worth specifying here is the mapping between strings and integers. Internet protocols are byte-oriented, while SRP performs algebraic operations on its messages, so it is logical to define at least one method by which integers can be converted into a string of bytes and vice versa.
ここで指定する価値のある1つの実装の問題は、文字列と整数の間のマッピングです。インターネットプロトコルはバイト指向であり、SRPはメッセージに対して代数操作を実行するため、整数をバイトの文字列に変換し、その逆にすることができる少なくとも1つの方法を定義することは論理的です。
An n-byte string S can be converted to an integer as follows:
nバイト文字列は、次のように整数に変換できます。
i = S[n-1] + 256 * S[n-2] + 256^2 * S[n-3] + ... + 256^(n-1) * S[0] where i is the integer and S[x] is the value of the x'th byte of S. In human terms, the string of bytes is the integer expressed in base 256, with the most significant digit first. When converting back to a string, S[0] must be non-zero (padding is considered to be a separate, independent process). This conversion method is suitable for file storage, in-memory representation, and network transmission of large integer values. Unless otherwise specified, this mapping will be assumed.
i = s [n-1] 256 * s [n-2] 256^2 * s [n-3] ... 256^（n-1） * s [0]ここで、私は整数であり、s [xです]は、S。のx'thバイトの値であり、人間の用語では、バイトの文字列はベース256で表される整数であり、最初に最も重要な数字があります。文字列に戻る場合、s [0]はゼロ以外でなければなりません（パディングは別の独立したプロセスと見なされます）。この変換方法は、ファイルストレージ、メモリの表現、および大規模な整数値のネットワーク伝送に適しています。特に指定されていない限り、このマッピングは想定されます。
If implementations require padding a string that represents an integer value, it is recommended that they use zero bytes and add them to the beginning of the string. The conversion back to integer automatically discards leading zero bytes, making this padding scheme less prone to error.
実装では、整数値を表す文字列をパディングする必要がある場合は、ゼロバイトを使用して文字列の先頭に追加することをお勧めします。整数への変換は、先頭のゼロバイトを自動的に破棄し、このパディングスキームがエラーの発生傾向を低下させます。
The SHA hash function, when used in this document, refers to the SHA-1 message digest algorithm described in [SHA1].
SHAハッシュ関数は、このドキュメントで使用される場合、[SHA1]で説明されているSHA-1メッセージダイジェストアルゴリズムを指します。
This section describes an implementation of the SRP authentication and key-exchange protocol that employs the SHA hash function to generate session keys and authentication proofs.
このセクションでは、SHAハッシュ関数を使用してセッションキーと認証プルーフを生成するSRP認証とキー交換プロトコルの実装について説明します。
The host stores user passwords as triplets of the form
ホストはユーザーパスワードをフォームのトリプレットとして保存します
{ <username>, <password verifier>, <salt> }
Password entries are generated as follows:
パスワードエントリは次のように生成されます。
<salt> = random()
x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
<password verifier> = v = g^x % N
The | symbol indicates string concatenation, the ^ operator is the exponentiation operation, and the % operator is the integer remainder operation. Most implementations perform the exponentiation and remainder in a single stage to avoid generating unwieldy intermediate results. Note that the 160-bit output of SHA is implicitly converted to an integer before it is operated upon.
|シンボルは文字列の連結を示し、 ^演算子は指数操作であり、％演算子は整数の残り操作です。ほとんどの実装は、扱いにくい中間結果の生成を避けるために、単一の段階で指数と残りを実行します。SHAの160ビット出力は、整数が動作する前に暗黙的に整数に変換されることに注意してください。
Authentication is generally initiated by the client.
認証は通常、クライアントによって開始されます。
Client Host
-------- ------
U = <username> -->
<-- s = <salt from passwd file>
Upon identifying himself to the host, the client will receive the salt stored on the host under his username.
ホストに自分自身を識別すると、クライアントはユーザー名の下でホストに保管されている塩を受け取ります。
a = random()
A = g^a % N -->
v = <stored password verifier>
b = random()
<-- B = (v + g^b) % N
p = <raw password>
x = SHA(s | SHA(U | ":" | p))
S = (B - g^x) ^ (a + u * x) % N S = (A * v^u) ^ b % N
K = SHA_Interleave(S) K = SHA_Interleave(S)
(this function is described
in the next section)
The client generates a random number, raises g to that power modulo the field prime, and sends the result to the host. The host does the same thing and also adds the public verifier before sending it to the client. Both sides then construct the shared session key based on the respective formulae.
クライアントは乱数を生成し、Gをその電力測定値に上げ、フィールドプライムになり、結果をホストに送信します。ホストは同じことを行い、クライアントに送信する前にパブリック検証を追加します。その後、それぞれの式に基づいて共有セッションキーを構築します。
The parameter u is a 32-bit unsigned integer which takes its value from the first 32 bits of the SHA1 hash of B, MSB first.
パラメーターuは32ビットの符号なし整数であり、最初にbのsha1ハッシュの最初の32ビットから値を取得します。
The client MUST abort authentication if B % N is zero.
B％nがゼロの場合、クライアントは認証を中止する必要があります。
The host MUST abort the authentication attempt if A % N is zero. The host MUST send B after receiving A from the client, never before.
ホストは、％nがゼロの場合、認証試行を中止する必要があります。ホストは、クライアントからAを受け取った後、これまでにないことを送信する必要があります。
At this point, the client and server should have a common session key that is secure (i.e. not known to an outside party). To finish authentication, they must prove to each other that their keys are identical.
この時点で、クライアントとサーバーには、安全な（つまり、外部の当事者には知られていない）共通のセッションキーが必要です。認証を完了するには、キーが同一であることを互いに証明する必要があります。
M = H(H(N) XOR H(g) | H(U) | s | A | B | K)
-->
<-- H(A | M | K)
The server will calculate M using its own K and compare it against the client's response. If they do not match, the server MUST abort and signal an error before it attempts to answer the client's challenge. Not doing so could compromise the security of the user's password.
サーバーは、独自のKを使用してMを計算し、クライアントの応答と比較します。それらが一致しない場合、サーバーはクライアントの課題に答えようとする前に、エラーを中止および信号する必要があります。そうしないと、ユーザーのパスワードのセキュリティが損なわれる可能性があります。
If the server receives a correct response, it issues its own proof to the client. The client will compute the expected response using its own K to verify the authenticity of the server. If the client responded correctly, the server MUST respond with its hash value.
サーバーが正しい応答を受信した場合、クライアントに独自の証明を発行します。クライアントは、独自のKを使用して予想される応答を計算して、サーバーの信頼性を確認します。クライアントが正しく応答した場合、サーバーはハッシュ値で応答する必要があります。
The transactions in this protocol description do not necessarily have a one-to-one correspondence with actual protocol messages. This description is only intended to illustrate the relationships between the different parameters and how they are computed. It is possible, for example, for an implementation of the SRP-SHA1 mechanism to consolidate some of the flows as follows:
このプロトコルの説明のトランザクションには、必ずしも実際のプロトコルメッセージと1対1の対応があるとは限りません。この説明は、異なるパラメーターとそれらの計算方法との関係を説明することのみを目的としています。たとえば、SRP-SHA1メカニズムの実装が次のようにいくつかのフローを統合することが可能です。
Client Host
-------- ------
U, A -->
<-- s, B
H(H(N) XOR H(g) | H(U) | s | A | B | K)
-->
<-- H(A | M | K)
The values of N and g used in this protocol must be agreed upon by the two parties in question. They can be set in advance, or the host can supply them to the client. In the latter case, the host should send the parameters in the first message along with the salt. For maximum security, N should be a safe prime (i.e. a number of the form N = 2q + 1, where q is also prime). Also, g should be a generator modulo N (see [SRP] for details), which means that for any X where 0 < X < N, there exists a value x for which g^x % N == X.
このプロトコルで使用されるNとGの値は、問題の2つの当事者によって合意されなければなりません。事前に設定することも、ホストがクライアントに供給することもできます。後者の場合、ホストは塩とともに最初のメッセージのパラメーターを送信する必要があります。最大のセキュリティのために、nは安全なプライムである必要があります（つまり、n = 2q 1のフォームn = 2q 1、qもプライム）。また、Gは発電機モジュロn（詳細については[srp]を参照）である必要があります。これは、0 <x <nでは、g^x％n == xの値xが存在することを意味します。
The SHA_Interleave function used in SRP-SHA1 is used to generate a session key that is twice as long as the 160-bit output of SHA1. To compute this function, remove all leading zero bytes from the input. If the length of the resulting string is odd, also remove the first byte. Call the resulting string T. Extract the even-numbered bytes into a string E and the odd-numbered bytes into a string F, i.e.
SRP-Sha1で使用されるSHA_INTERLEAVE関数は、SHA1の160ビット出力の2倍の長さのセッションキーを生成するために使用されます。この関数を計算するには、入力からすべての先頭のゼロバイトを削除します。結果の文字列の長さが奇妙な場合は、最初のバイトも削除します。結果の文字列Tを呼び出します。偶数のバイトを文字列Eに抽出し、奇数のバイトを文字列fに抽出します。
E = T[0] | T[2] | T[4] | ... F = T[1] | T[3] | T[5] | ...
E = T [0] |t [2] |t [4] |... f = t [1] |t [3] |t [5] |...
Both E and F should be exactly half the length of T. Hash each one with regular SHA1, i.e.
EとFの両方は、通常のSHA1、つまり、それぞれそれぞれの長さの長さの正確な長さでなければなりません。
G = SHA(E)
H = SHA(F)
Interleave the two hashes back together to form the output, i.e.
2つのハッシュを一緒に戻して出力を形成します。
result = G[0] | H[0] | G[1] | H[1] | ... | G[19] | H[19]
result = g [0] |H [0] |G [1] |H [1] |... |G [19] |H [19]
The result will be 40 bytes (320 bits) long.
結果は40バイト（320ビット）の長さになります。
SRP can be used with hash functions other than SHA. If the hash function produces an output of a different length than SHA (20 bytes), it may change the length of some of the messages in the protocol, but the fundamental operation will be unaffected.
SRPは、SHA以外のハッシュ関数で使用できます。ハッシュ関数がSHA（20バイト）とは異なる長さの出力を生成すると、プロトコル内のメッセージの長さが変更される可能性がありますが、基本操作は影響を受けません。
Earlier versions of the SRP mechanism used the MD5 hash function, described in [RFC 1321]. Keyed hash transforms are also recommended for use with SRP; one possible construction uses HMAC [RFC 2104], using K to key the hash in each direction instead of concatenating it with the other parameters.
SRPメカニズムの以前のバージョンは、[RFC 1321]で説明されているMD5ハッシュ機能を使用しました。SRPでの使用には、キー付きハッシュ変換もお勧めします。可能な構造の1つは、HMAC [RFC 2104]を使用し、Kを使用して他のパラメーターと連結するのではなく、各方向にハッシュをキーします。
Any hash function used with SRP should produce an output of at least 16 bytes and have the property that small changes in the input cause significant nonlinear changes in the output. [SRP] covers these issues in more depth.
SRPで使用されるハッシュ関数は、少なくとも16バイトの出力を生成し、入力の小さな変化が出力に大きな非線形変化を引き起こすという特性を持つ必要があります。[SRP]は、これらの問題をより深くカバーしています。
This entire memo discusses an authentication and key-exchange system that protects passwords and exchanges keys across an untrusted network. This system improves security by eliminating the need to send cleartext passwords over the network and by enabling encryption through its secure key-exchange mechanism.
このメモ全体では、信頼できないネットワーク全体でパスワードを保護し、キーを交換する認証とキー交換システムについて説明します。このシステムは、ネットワーク上でクリアテキストパスワードを送信する必要性を排除し、安全なキー交換メカニズムを介して暗号化を有効にすることにより、セキュリティを改善します。
The private values for a and b correspond roughly to the private values in a Diffie-Hellman exchange and have similar constraints of length and entropy. Implementations may choose to increase the length of the parameter u, as long as both client and server agree, but it is not recommended that it be shorter than 32 bits.
AとBのプライベート値は、Diffie-Hellman Exchangeのプライベート値に大まかに対応し、長さとエントロピーの同様の制約を持っています。実装は、クライアントとサーバーの両方が同意する限り、パラメーターUの長さを増やすことを選択する場合がありますが、32ビットよりも短くなることは推奨されません。
SRP has been designed not only to counter the threat of casual password-sniffing, but also to prevent a determined attacker equipped with a dictionary of passwords from guessing at passwords using captured network traffic. The SRP protocol itself also resists active network attacks, and implementations can use the securely exchanged keys to protect the session against hijacking and provide confidentiality.
SRPは、カジュアルなパスワードスニフィングの脅威に対抗するだけでなく、パスワードの辞書を装備した攻撃者がキャプチャされたネットワークトラフィックを使用してパスワードを推測するのを防ぐために設計されています。SRPプロトコル自体もアクティブなネットワーク攻撃に抵抗し、実装は安全に交換されたキーを使用して、セッションをハイジャックから保護し、機密性を提供することができます。
SRP also has the added advantage of permitting the host to store passwords in a form that is not directly useful to an attacker. Even if the host's password database were publicly revealed, the attacker would still need an expensive dictionary search to obtain any passwords. The exponential computation required to validate a guess in this case is much more time-consuming than the hash currently used by most UNIX systems. Hosts are still advised, though, to try their best to keep their password files secure.
SRPには、ホストが攻撃者に直接役に立たないフォームでパスワードを保存することを許可するという追加の利点もあります。ホストのパスワードデータベースが公開されたとしても、攻撃者はパスワードを取得するために高価な辞書検索が必要になります。この場合、推測を検証するために必要な指数計算は、現在ほとんどのUNIXシステムで使用されているハッシュよりもはるかに時間がかかります。ただし、ホストは、パスワードファイルを安全に保つために最善を尽くすことをお勧めします。
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC 1321] Rivest、R。、「MD5メッセージダイジストアルゴリズム」、RFC 1321、1992年4月。
[RFC 1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[RFC 1704]ハラー、N。およびR.アトキンソン、「インターネット認証について」、RFC 1704、1994年10月。
[RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC 1760, Feburary 1995.
[RFC 1760]ハラー、N。、「S/キーのワンスタイムパスワードシステム」、RFC 1760、1995年FEBRARY。
[RFC 2095] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2095, January 1997.
[RFC 2095] Klensin、J.、Catoe、R。、およびP. Krumviede、「IMAP/POPは、単純なチャレンジ/応答の拡張を承認します」、RFC 2095、1997年1月。
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC 2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[SHA1] National Institute of Standards and Technology (NIST), "Announcing the Secure Hash Standard", FIPS 180-1, U.S. Department of Commerce, April 1995.
[SHA1]国立標準技術研究所（NIST）、「安全なハッシュ標準の発表」、FIPS 180-1、米国商務省、1995年4月。
[SRP] T. Wu, "The Secure Remote Password Protocol", In Proceedings of the 1998 Internet Society Symposium on Network and Distributed Systems Security, San Diego, CA, pp. 97-111.
[SRP] T. Wu、「セキュアーリモートパスワードプロトコル」、1998年のインターネットソサエティシンポジウムに関するネットワークおよび分散システムセキュリティの議事録、カリフォルニア州サンディエゴ、97-111ページ。
Thomas Wu Stanford University Stanford, CA 94305
トーマスウースタンフォード大学スタンフォード、カリフォルニア州94305
EMail: tjw@cs.Stanford.EDU
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。