Network Working Group T. Wu
Request for Comments: 2945 Stanford University
Category: Standards Track September 2000
The SRP Authentication and Key Exchange System
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.
著作権（C）インターネット協会（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.
また、使いやすい安全な認証メカニズムの欠如は、現在使用されているインターネット・プロトコルの大半と長年の課題でした。問題は二つある：ユーザーが覚えられるパスワードを使用したいが、ほとんどのパスワードベースの認証システムが弱いと簡単に推測パスワードが使用されている場合は特に、でも、受動的攻撃者に対して少し保護を提供します。
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
TCP / IPネットワーク上の盗聴は明確でパスワードを送信プロトコルに対して非常に簡単かつ非常に効果的に行うことができます。倒すために設計されています[RFC 2095]と[RFC 1760]に記載のもの、のようにもいわゆる「チャレンジレスポンス」技術
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.
簡単な盗聴攻撃は、「辞書攻撃」として知られているものによって侵害される可能性があります。攻撃者は、メッセージが、プロトコルの正当な実行の間に交換キャプチャし、共通パスワードのプリコンパイルされた「辞書」から取られた推測パスワードのシリーズを検証するために、その情報を使用する場合に発生します。ユーザーは、多くの場合、必ずまた推測が容易なシンプルで覚えやすいパスワードを選択するので、これは動作します。
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.
ここで指定する価値はある実装上の問題は、文字列と整数との間のマッピングです。 SRPは、そのメッセージに代数演算を実行しながら、インターネットプロトコルは、バイト指向であるので、整数はその逆のバイトの文字列に変換することが可能な少なくとも一つのメソッドを定義することが論理的です。
An n-byte string S can be converted to an integer as follows:
次のようにnバイトストリングSは、整数に変換することができます。
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] iは整数でありますそしてS [x]は、ヒトに関してはS.のx番目のバイトの値であり、バイトのストリングは、最上位桁とベース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]に記載のダイジェストアルゴリズムSHA1メッセージを指します。
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
=ランダム（）A = gは^％N - > V = <記憶されたパスワード検証> B =ランダム（）< - B =（V + G ^ B）％N
p = <raw password> x = SHA(s | SHA(U | ":" | p))
P = <生のパスワード>は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)
S =（B - G ^ X）^（+ U * X）％NS =（*のV ^ U）^ Bの％NK = SHA_Interleave（S）K = SHA_Interleave（S）（この関数は、次に記載されていますセクション）
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は第一B、MSBのSHA1ハッシュの最初の32ビットから、その値をとる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を受け取った後にBを送らなければなりません。
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の値は、問題の両当事者によって合意されなければなりません。彼らは、事前に設定することができ、またはホストがクライアントにそれらを供給することができます。後者の場合、ホストは、塩と一緒に最初のメッセージにパラメータを送信すべきです。最大限のセキュリティのために、Nは、（Qも素数である、すなわちフォームの数N = 2Q + 1）安全素数であるべきです。また、G手段ジェネレータモジュロN（[SRP]詳細は参照）されるべきであること0 <X <Nは、値xが存在する任意のXのためのG ^ X％のN == 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ビット出力としてのセッション鍵を生成するために使用されます。この関数を計算するには、入力からすべての先行ゼロバイトを削除します。得られた文字列の長さが奇数である場合、また、最初のバイトを除去します。 F文字列に文字列Eに偶数バイトと奇数バイトを抽出し、得られた文字列Tを呼び出す、すなわち
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とそれぞれT.ハッシュの丁度半分の長さであるべきです
G = SHA(E) H = SHA(F)
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]
結果= 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での使用は推奨されています。一つの可能な構成は、他のパラメータとを連結するのではなく、各方向にハッシュをキーにKを使用して、HMAC [RFC 2104]使用します。
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交換の民間の値にほぼ対応し、長さとエントロピーの同様の制約を有します。実装は、限り、クライアントとサーバーの両方が同意するよう、パラメータ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]ハラー、AND。、 "S / Keyのワンタイムパスワードシステム"、RFC 1760、1995年2月。
[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.、ベラー、M。およびR.カネッティ、 "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）は、180-1、米国商務省が、1995年4月FIPS。
[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]ネットワーク上の1998インターネット協会シンポジウムや分散システムのセキュリティ、サンディエゴ、CA、頁97-111でT.呉、「セキュアリモートパスワードプロトコル」、。
Thomas Wu Stanford University Stanford, CA 94305
トーマス・呉スタンフォード大学、スタンフォード、CA 94305
EMail: tjw@cs.Stanford.EDU
メールアドレス：tjw@cs.Stanford.EDU
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。