Network Working Group T. Ts'o
Request for Comments: 2946 VA Linux Systems
Category: Standards Track September 2000
Telnet Data Encryption Option
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 the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. While this document summarizes currently utilized encryption types and codes, it does not define a specific encryption algorithm. Separate documents are to be published defining implementations of this option for each encryption algorithm.
この文書では、telnet、データストリームのためのデータの機密性サービスを提供する一般的な方法としてのtelnet暗号化オプションを説明します。この文書は、現在利用されている暗号化タイプとコードをまとめたが、それは特定の暗号化アルゴリズムを定義していません。別々の文書には、それぞれの暗号化アルゴリズムのために、このオプションの実装を定義し、公開することになっています。
ENCRYPT 38
ENCRYPT 38
Encryption Commands
IS 0
SUPPORT 1
REPLY 2
START 3
END 4
REQUEST-START 5
REQUEST-END 6
ENC_KEYID 7
DEC_KEYID 8
Encryption Types NULL 0 DES_CFB64 1 DES_OFB64 2
暗号化タイプ0 NULL 1 DES_CFB64のDES_OFB64 2
DES3_CFB64 3 DES3_OFB64 4 CAST5_40_CFB64 8 CAST5_40_OFB64 9 CAST128_CFB64 10 CAST128_OFB64 11
DES3_CFB64 3 DES3_OFB64 4 CAST5_40_CFB64 8 CAST5_40_OFB64 9 CAST128_CFB64 10 CAST128_OFB64 11
Following historical practice, future encryption type numbers will be assigned by the IANA under a First Come First Served policy as outlined by RFC 2434 [3]. Despite the fact that authentication type numbers are allocated out of an 8-bit number space (as are most values in the telnet specification) it is not anticipated that the number space is or will become in danger of being exhausted. However, if this should become an issue, when over 50% of the number space becomes allocated, the IANA shall refer allocation requests to either the IESG or a designated expert for approval.
歴史的な練習に続き、将来の暗号化の種類数は、まず下のIANAによって割り当てられます最初に来るRFC 2434で概説されたポリシーを務め[3]。認証タイプ番号は8ビットの番号空間から割り当てられているという事実にもかかわらず（Telnetの仕様のほとんどの値であるように）、数空間であるか、または排出される危険になることが予想されません。これは数スペースの50％以上が割り当てられてしまう問題、なるべきである場合には、IANAはIESGや承認のために指定された専門家のいずれかに割り当て要求を指すものとします。
IAC WILL ENCRYPT
IACは、暗号化します
The sender of this command is willing to send encrypted data.
このコマンドの送信者は、暗号化されたデータを送信していく所存です。
IAC WONT ENCRYPT
IAC WONT ENCRYPT
The sender of this command refuses to send encrypted data.
このコマンドの送信者は、暗号化されたデータを送信することを拒否します。
IAC DO ENCRYPT
IAC DO ENCRYPT
The sender of this command is willing to receive encrypted data.
このコマンドの送信者は、暗号化されたデータを受信していく所存です。
IAC DONT ENCRYPT
IAC DONT ENCRYPT
The sender of this command refuses to accept encrypted data.
このコマンドの送信者は、暗号化されたデータを受け入れることを拒否します。
IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE
IAC SB ENCRYPTサポート暗号化タイプリストIAC SE
The sender of this command is stating which types of encryption it will support. Only the side of the connection that is DO ENCRYPT may send the SUPPORT command. The current types of encryption are listed in the current version of the Assigned Numbers document [1].
このコマンドの送信者は、それがサポートするどの暗号化の種類述べています。 DO ENCRYPTである接続の唯一の側面は、supportコマンドを送信することができます。暗号化の現在のタイプの割り当て番号文書[1]の現在のバージョンに記載されています。
The encryption-type-list may only include types which can actually be supported during the current session. If ENCRYPT is negotiated in conjunction with AUTH the SUPPORT message MUST NOT be sent until after the session key has been determined. Otherwise, it is impossible to know if the selected encryption type can be properly initialized based upon the type and length of the key that is available."
暗号化タイプ・リストには、実際には、現在のセッション中にサポートすることが可能なタイプを含むことができます。 ENCRYPTは、AUTHと一緒に交渉されている場合SUPPORTメッセージは、セッション鍵が決定された後まで送ってはいけません。それ以外の場合は、選択された暗号化タイプが適切に利用できるキーの種類と長さに基づいて初期化することができるかどうかを知ることは不可能です。」
IAC SB ENCRYPT IS encryption-type ... IAC SE
IAC SB ENCRYPTは、暗号化タイプです... IAC SE
The sender of this command is stating which type of encryption to use, and any initial data that is needed. Only the side of the connection that is WILL ENCRYPT may send the IS command to initialize the encryption-type scheme.
このコマンドの送信者は、使用する暗号化の種類、および必要とされている任意の初期データを述べています。 WILL ENCRYPTである接続の唯一の側面は、暗号化型スキームを初期化するために、ISコマンドを送信することができます。
IAC SB ENCRYPT REPLY encryption-type ... IAC SE
IAC SB ENCRYPTのREPLY暗号化タイプ... IAC SE
The sender of this command is continuing the initial data exchange in order to initialize the encryption-type scheme. Only the side of the connection that is DO ENCRYPT may send the REPLY command.
このコマンドの送信者は、暗号化型スキームを初期化するために、最初のデータ交換を続けています。 DO ENCRYPTである接続の唯一の側面は、REPLYコマンドを送信することができます。
IAC SB ENCRYPT START keyid IAC SE
IAC SB ENCRYPT STARTキーID IAC SE
The sender of this command is stating that all data following the command in the data stream will be be encrypted via the previously negotiated method of data encryption. Only the side of the connection that is WILL ENCRYPT may send the START command.
このコマンドの送信者は、データ・ストリーム内のコマンドを以下の全てのデータは、データの暗号化の以前に交渉方法で暗号化されることを述べて。 WILL ENCRYPTである接続の唯一の側面は、STARTコマンドを送信することができます。
The keyid is a variable length field. It is used by various encryption mechanisms to identify which encryption key is to be used, when multiple encryption keys might be known on either side of the connection. The keyid field is encoded with the most significant byte first, and a keyid value of zero is reserved to indicate the default encryption key (this would typically be an encryption key derived during authentication, with the AUTHENTICATION option). The keyid field must be at least one byte long. The only valid values for "keyid" will be those that have been received in a DEC_KEYID command.
キーIDは、可変長フィールドです。複数の暗号化キーは、接続の両側で知られるかもしれない場合、使用されるべき暗号化鍵を識別するために、様々な暗号化メカニズムによって使用されます。鍵IDフィールドは、最初の最上位バイトでエンコードされ、そしてゼロのキーID値は、デフォルトの暗号化キーを（これは通常、認証オプションで、認証中に導出暗号化キーになります）を示すために予約されています。鍵IDフィールドは、少なくとも1バイト長でなければなりません。 「キーID」のための唯一の有効な値はDEC_KEYIDコマンドで受信されたものになります。
IAC SB ENCRYPT END IAC SE
IAC SB ENCRYPT END IAC SE
The sender of this command is stating that all data following the command in the data stream will not be encrypted. Only the side of the connection that is WILL ENCRYPT may send the END
このコマンドの送信者は、データストリーム内のコマンドに続くすべてのデータが暗号化されないことを述べています。 WILLのENCRYPTである接続の唯一の側がENDを送ることができ
IAC SB ENCRYPT REQUEST-START keyid IAC SE
IAC SBのENCRYPT REQUEST-STARTキーID IAC SE
The sender of this command requests that the remote side begin encryption of the telnet data stream. Only the side of the connection that is DO ENCRYPT may send the REQUEST-START command. The keyid is only advisory, and my be omitted.
リモート側がtelnetのデータ・ストリームの暗号化を開始し、このコマンド要求の送信者。 DO ENCRYPTである接続の唯一の側面は、REQUEST-STARTコマンドを送信することができます。キーIDはあくまで参考であり、省略することが私の。
IAC SB ENCRYPT REQUEST-END IAC SE
IAC SB ENCRYPT要求-END IAC SE
The sender of this command requests that the remote side stop encryption of the telnet data stream. Only the side of the connection that is DO ENCRYPT may send the REQUEST-END command.
そのtelnetのデータ・ストリームのリモート側のストップ暗号化、このコマンド要求の送信者。 DO ENCRYPTである接続の唯一の側面は、REQUEST-ENDコマンドを送信することができます。
IAC SB ENCRYPT ENC_KEYID keyid IAC SE
IAC SB ENCRYPT ENC_KEYID鍵ID IAC SE
The sender of this requests that the remote side verify that "keyid" maps to a valid key; or verifies that the "keyid" received in a DEC_KEYID command is valid. If keyid is omitted, it implies that there are no more known keyids, and that the attempt to find a common keyid has failed. Only the side of the connection that is WILL ENCRYPT may send the ENC_KEYID command.
これの送信者は、リモート側が有効なキーにその「鍵ID」のマップを確認することを要請します。またはDEC_KEYIDコマンドで受信した「鍵ID」は有効であることを確認します。キーIDが省略された場合、それはもう知らkeyidsがあることを意味しない、との共通鍵IDを見つけるための試みが失敗したこと。 WILL ENCRYPTである接続の唯一の側面はENC_KEYIDコマンドを送信することができます。
IAC SB ENCRYPT DEC_KEYID keyid IAC SE
IAC SB ENCRYPT DEC_KEYID鍵ID IAC SE
The sender of this requests that the remote side verify that "keyid" maps to a valid key on the remote side; or verifies that the "keyid" received in a ENC_KEYID command is valid. If keyid is omitted, it implies that there are no more known keyids, and that the attempt to find a common keyid has failed. Only the side of the connection that is DO ENCRYPT may send the DEC_KEYID command.
これの送信者は、リモート側が、リモート側で有効なキーにその「鍵ID」のマップを確認することを要請します。またはENC_KEYIDコマンドで受信した「鍵ID」は有効であることを確認します。キーIDが省略された場合、それはもう知らkeyidsがあることを意味しない、との共通鍵IDを見つけるための試みが失敗したこと。 DO ENCRYPTである接続の唯一の側面はDEC_KEYIDコマンドを送信することができます。
The default specification for this option is
このオプションのデフォルト仕様です
WONT ENCRYPT DONT ENCRYPT
WONT ENCRYPT DONT ENCRYPT
meaning there will not be any encryption of the Telnet data stream.
Telnetのデータストリームのいずれかの暗号化がされませんを意味します。
The Telnet protocol has no form of protection from some intervening gateway looking at IP packets as they travel through the network. This is especially dangerous when passwords are sent as clear text over the network. This option provides a method for encrypting the data stream.
彼らは、ネットワークを介して移動するようTelnetプロトコルは、IPパケットを見て、いくつかの介入ゲートウェイからの保護のno形式を持っていません。パスワードがネットワーク上でクリアテキストとして送信された場合、これは特に危険です。このオプションは、データ・ストリームを暗号化するための方法を提供します。
Once the Encryption option is in effect, all data in the negotiated direction, including TELNET options, is encrypted. Encryption begins with the octet of data immediately following the "IAC SB ENCRYPT START encryption-type IAC SE" command. Encryption ends after the "IAC SB ENCRYPT END IAC SE" command.
暗号化オプションが有効になると、TELNETオプションを含む交渉さ方向のすべてのデータは、暗号化されています。暗号化は、すぐに「IAC SB ENCRYPT START暗号化型IAC SE」コマンドに続くデータのオクテットから始まります。暗号化は、 "IAC SB ENCRYPT END IAC SE" コマンド後に終了します。
WILL and DO are used only at the beginning of the connection to obtain and grant permission for future negotiations. The ENCRYPT option must be negotiated in both directions.
そしてDOは、今後の交渉のための許可を取得して付与するだけで、接続の開始時に使用されているでしょう。 ENCRYPTオプションは、両方の方向で交渉しなければなりません。
Once the two hosts have exchanged a WILL and a DO, the sender of the DO ENCRYPT must send a ENCRYPT SUPPORT command to let the remote side know the types of encryption it is willing to accept. In the request, a list of supported encryption schemes is sent. Only the sender of the DO may send a list of supported encryption types (IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE). Only the sender of the WILL may actually transmit encrypted data. This is initiated via the "IAC SB ENCRYPT START IAC SE" command, and terminated via the "IAC SB ENCRYPT END IAC SE" command. If a START is received, and then a second START is received before receiving an END, the second START is ignored.
2つのホストがWILLとDOを交換したら、DO ENCRYPTの送信者は、リモート側がそれを受け入れても構わないと思っている暗号化の種類を知っているようにENCRYPT supportコマンドを送信する必要があります。要求では、サポートされる暗号化方式のリストが送信されます。唯一のDOの送信者は、サポートされている暗号化の種類（IAC SB ENCRYPTサポート暗号化タイプリストIAC SE）のリストを送信することができます。 WILLの送信者だけが、実際に暗号化されたデータを送信してもよいです。これは、 "IAC SB ENCRYPT START IAC SE" コマンドを使用して開始され、 "IAC SB ENCRYPT END IAC SE" コマンドで終了します。 ENDを受信する前にSTARTを受信し、次いで第2のSTARTを受信した場合、第2の開始は無視されます。
If the sender of the DO would like the remote side to begin sending encrypted data, it can send the "IAC SB ENCRYPT REQUEST-START IAC SE" command. If the sender of the DO would like the remote side to stop sending encrypted data, it can send the "IAC SB ENCRYPT REQUEST-STOP IAC SE" command.
DOの送信者が暗号化されたデータの送信を開始するために、リモート側を希望の場合、それは「IAC SBのENCRYPT REQUEST-START IAC SE」コマンドを送信することができます。 DOの送信者が暗号化されたデータの送信を停止するためのリモート側を希望の場合、それは「IAC SBのENCRYPT REQUEST-STOP IAC SE」コマンドを送信することができます。
If the receiver of the SUPPORT command does not support any of the encryption types listed in the SUPPORT command, it should send an "IAC SB ENCRYPT IS NULL IAC SE" to indicate that there are no encryption types in common. It may also send an IAC WONT ENCRYPT command to turn off the ENCRYPT option.
supportコマンドの受信機は、supportコマンドに記載されている暗号化タイプのいずれかをサポートしていない場合、それは一般的には暗号化タイプが存在しないことを示すために「IAC SB ENCRYPTがNULL IAC SE IS」送信する必要があります。また、ENCRYPTオプションをオフにするIAC WONTのENCRYPTコマンドを送信することができます。
The order of the encryption types in a SUPPORT command must be ordered to indicate a preference for different encryption types, the first type being the most preferred, and the last type the least preferred.
supportコマンドで暗号化タイプの順序が異なる暗号化タイプ、最初のタイプが最も好ましい、そして最後種類以上の好適に対する選好を示すために注文する必要があります。
If the ENCRYPT option has been enabled, and encrypted data is being received, the receipt of an "IAC WONT ENCRYPT" implies the receipt of an "IAC SB ENCRYPT END IAC SE", e.g., the Telnet data stream is no longer encrypted.
ENCRYPTオプションが有効になっていると、暗号化されたデータを受信している場合は、「IAC WONT ENCRYPT」の領収書は「IAC SB ENCRYPT END IAC SE」の受信を意味、例えば、Telnetのデータ・ストリームは、もはや暗号化されません。
The following example demonstrates the use of the option:
次の例では、オプションの使用を示しています。
Host1 Host2
ホスト1ホスト2
[ Host1 requests Host2 negotiate the encryption of data that Host2 sends to Host1. Host2 agrees to negotiate the encryption of data that it sends to Host1. ] DO ENCRYPT WILL ENCRYPT [ Host1 requests that Host2 enable encryption as soon as the initialization is completed, and informs Host2 that is supports DES_CFB64. ] IAC SB ENCRYPT REQUEST-START IAC SE IAC SB ENCRYPT SUPPORT DES_CFB64 IAC SE [ Host2 sends the initial feed to Host1. Host1 acknowledges receipt of the IV. ] IAC SB ENCRYPT IS DES_CFB64 CFB64_IV 144 146 63 229 237 148 81 143 IAC SE IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_OK 103 207 181 71 224 55 229 98 IAC SE [ Host2 is now free to start sending encrypted data, and since a REQUEST-START was received, it enables encryption. ] IAC SB ENCRYPT START IAC SE [ All data from Host2 to Host1 is now encrypted. ] IAC SB ENCRYPT END IAC SE [ All data from Host2 to Host1 is now in clear text again. ]
[ホスト1はホスト2は、ホスト2は、ホスト1に送信するデータの暗号化を交渉要求します。ホスト2は、ホスト1に送信するデータの暗号化を交渉することに同意します。 ] ENCRYPTは、ホスト1は、ホスト2は、すぐに初期化が完了すると、暗号化を有効にすることを要求し、ホスト2に知らせるDES_CFB64をサポートしている[暗号化されますください。 ] IAC SB ENCRYPT要求-START IAC SE IAC SB ENCRYPT SUPPORT DES_CFB64 IAC SE [ホスト2は、ホスト1に初期フィードを送信します。 host1がIVの受信を確認します。 ] IAC SB ENCRYPTはDES_CFB64 CFB64_IV 144 146 63 229 237 148 81 143 IAC SE IAC SBのENCRYPT応答DES_CFB64 CFB64_IV_OK 103 207 181 71 224 55 229 98 IAC SE [ホスト2は、現在暗号化されたデータの送信を開始して自由であり、REQUEST-STARTのでISそれは、暗号化を有効にし、受信しました。 ] IAC SB ENCRYPT START IAC SEは、[ホスト1のホスト2からのデータはすべて暗号化されている今。 ] IAC SB ENCRYPT END IAC SE [ホスト1のホスト2からのすべてのデータを再度クリアテキストになりました。 ]
It is expected that any implementation that supports the Telnet ENCRYPT option will support all of this specification.
のTelnet ENCRYPTオプションをサポートするすべての実装は、この仕様のすべてをサポートすることが期待されます。
The ENCRYPT option used in isolation provides protection against passive attacks, but not against active attacks. In other words, it will provide protection from someone who is just watching the IP packets as they pass through the network. However, an attacker who is able to modify packets in flight could prevent the ENCRYPT option from being negotiated.
単独で使用ENCRYPTオプションは、受動的攻撃に対してではなく、能動的な攻撃に対する保護を提供します。言い換えれば、それは彼らがネットワークを通過するだけでIPパケットを見ている誰かからの保護を提供します。しかし、飛行中のパケットを変更することで、攻撃者が交渉中からENCRYPTオプションを防ぐことができます。
This flaw can be remedied by using the Telnet Authentication option alongside the ENCRYPT option. Specifically, setting ENCRYPT_USING_TELOPT in the authentication-type-pair can be used to force that Encryption be negotiated even in the face of active attacks.
この欠陥は、ENCRYPTオプションと一緒にTelnetの認証オプションを使用することによって改善することができます。具体的には、認証型対で設定ENCRYPT_USING_TELOPTもアクティブな攻撃の面で交渉することを暗号化を強制するために使用することができます。
In addition, an active attacker can interfere with attempts to start or restart encryption. If encryption is requested by the user, and the client is unable to negotiate enabling or re-enabling encryption, the client must assume that it is being attacked, and MUST immediately terminate the telnet connection.
また、アクティブな攻撃者は、暗号化を開始または再起動しようとする試みを妨げることができます。暗号化は、ユーザによって要求され、そしてクライアントが暗号化を有効または再有効化交渉することができない場合、クライアントは、それが攻撃されていることを想定しなければならない、とすぐにtelnet接続を終えなければなりません。
The specification defines a method for providing data confidentiality to the telnet data stream. Unfortunately all of the encryption mechanism provided under this option do not provide data integrity, because of the complexity of specifying a protocol which provided integrity services efficiently in a stream-oriented protocol.
仕様は、telnetデータストリームにデータの機密性を提供するための方法を定義します。残念ながら、すべてこのオプションの下で提供暗号化メカニズムのは、理由はストリーム指向のプロトコルで効率的に整合性サービスを提供するプロトコルを指定の複雑さのため、データの整合性を提供しません。
The TELNET START_TLS specification provides a scheme which provides confidentiality, integrity, and compression, and future work for telnet encryption should closely examine using this specification. One promising approach would use the anonymous Diffie-Hellman mode of TLS, followed by the telnet AUTHENTICATION option where the authentication mechanism would include the client and server finished messages computed during the TLS negotiation.
TELNET START_TLS仕様は密接にこの仕様を使用して調べる必要のtelnet暗号化のための機密性、完全性、および圧縮、および将来の仕事を提供してスキームを提供します。一つの有望なアプローチは、認証機構は、TLSネゴシエーション中に計算され、クライアントとサーバの終了メッセージが含まれるのtelnet認証オプションに続くTLSの匿名のDiffie-Hellmanモードを、使用します。
This document was originally written by Dave Borman of Cray Research, with the assistance of Theodore Ts'o of MIT and the IETF Telnet Working Group.
この文書は、元々MITのセオドア・ツォーとIETF Telnetのワーキンググループの支援を受けて、クレイリサーチのデイブ・ボーマンによって書かれました。
[1] Reynolds, J. and J. Postel, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[1]レイノルズ、J.およびJ.ポステル、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
[2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941, September 2000.
[2] Ts'oさん、T.及びJ.アルトマン、 "Telnetの認証オプション"、RFC 2941、2000年9月。
[3] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Alvestrand、H.、およびT. Narten氏、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
Theodore Ts'o, Editor VA Linux Systems 43 Pleasant St. Medford, MA 02155
セオドア・ツォー、エディタVA Linuxシステム43プレザントセントメドフォード、MA 02155
Phone: (781) 391-3464 EMail: tytso@mit.edu
電話：（781）391-3464 Eメール：tytso@mit.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機能のための基金は現在、インターネット協会によって提供されます。