RFC2942 日本語訳

Network Working Group                                            T. Ts'o
Request for Comments: 2942                              VA Linux Systems
Category: Standards Track                                 September 2000

コメントを求めるワーキンググループT.t o要求をネットワークでつないでください: 2942年のヴァージニアリナックスシステムカテゴリ: 標準化過程2000年9月

               Telnet Authentication: Kerberos Version 5

telnet認証: ケルベロスバージョン5

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

   This document describes how Kerberos Version 5 [1] is used with the
   telnet protocol.   It describes an telnet authentication suboption to
   be used with the telnet authentication option [2].   This mechanism
   can also used to provide keying material to provide data
   confidentiality services in conjunction with the telnet encryption
   option [3].

このドキュメントはケルベロスバージョン5[1]がtelnetプロトコルと共にどう使用されるかを説明します。 それは、telnet認証オプション[2]と共に使用されるためにtelnet認証「副-オプション」について説明します。 また、このメカニズムは、以前はtelnet暗号化オプション[3]に関連してデータの機密性サービスを提供するために材料を合わせながら、よく提供されることができました。

1. Command Names and Codes

1. コマンド名とコード

      Authentication Types

認証タイプ

         KERBEROS_V5    2

ケルベロス_V5 2

      Sub-option Commands

サブオプション命令

         AUTH               0
         REJECT             1
         ACCEPT             2
         RESPONSE           3
         FORWARD            4
         FORWARD_ACCEPT     5
         FORWARD_REJECT     6

AUTH0廃棄物1が受け入れる、2応答3フォワード4の前進の_は5の前進の_廃棄物6を受け入れます。

Ts'o                        Standards Track                     [Page 1]

RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000

t o標準化過程[1ページ]RFC2942telnet認証: ケルベロス、バージョン2000年9月5日

2.  Command Meanings

2. コマンド意味

   IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
   KRB_AP_REQ message> IAC SE

IAC SB AUTHENTICATION IS<認証タイプ組>AUTH<ケルベロスV5 KRB_AP_REQメッセージ>IAC SE

      This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the
      remote side of the connection.  The first octet of the
      <authentication-type-pair> value is KERBEROS_V5, to indicate that
      Version 5 of Kerberos is being used.  The Kerberos V5
      authenticator in the KRB_AP_REQ message must contain a Kerberos V5
      checksum of the two-byte authentication type pair.  This checksum
      must be verified by the server to assure that the authentication
      type pair was correctly negotiated.  The Kerberos V5 authenticator
      must also include the optional subkey field, which shall be filled
      in with a randomly chosen key.  This key shall be used for
      encryption purposes if encryption is negotiated, and shall be used
      as the negotiated session key (i.e., used as keyid 0) for the
      purposes of the telnet encryption option; if the subkey is not
      filled in, then the ticket session key will be used instead.

これは、ケルベロスV5[1]KRB_AP_REQメッセージを接続の遠隔地側に向かわせるのに使用されます。 認証タイプ組>が評価する<の最初の八重奏は、ケルベロスのバージョン5が使用されているのを示すためにはケルベロス_V5です。 KRB_AP_REQメッセージのケルベロスV5固有識別文字は2バイトの認証タイプ組のケルベロスV5チェックサムを含まなければなりません。 サーバは、認証タイプ組が正しく交渉されたことを保証するためにこのチェックサムについて確かめなければなりません。 また、ケルベロスV5固有識別文字は任意のサブキー分野を含まなければなりません。(それは、手当たりしだいに選ばれたキーで記入されるものとします)。 このキーは、暗号化が交渉されると暗号化目的に使用されて、telnet暗号化オプションの目的に交渉されたセッションキー(すなわち、keyid0として、使用される)として使用されるものとします。 サブキーが記入されないと、チケットセッションキーは代わりに使用されるでしょう。

      If data confidentiality services is desired the ENCRYPT_US-
      ING_TELOPT flag must be set in the authentication-type-pair as
      specified in [2].

データの機密性サービスが望まれているなら、[2]の指定されるとしての認証タイプ組でENCRYPTの_の米国のING_TELOPTの旗を設定しなければなりません。

   IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE

IAC SB認証回答<認証タイプ組>はIAC SEを受け入れます。

      This command indicates that the authentication was successful.

このコマンドは、認証がうまくいったのを示します。

      If the AUTH_HOW_MUTUAL bit is set in the second octet of the
      authentication-type-pair, the RESPONSE command must be sent before
      the ACCEPT command is sent.

認証タイプ組の2番目の八重奏でAUTH_HOW_MUTUALビットを設定するなら、ACCEPTコマンドを送る前にRESPONSEコマンドを送らなければなりません。

   IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
      <optional reason for rejection> IAC SE

IAC SB AUTHENTICATION REPLY<認証タイプ組>のREJECTの<の任意の不合格理由>IAC SE

      This command indicates that the authentication was not successful,
      and if there is any more data in the sub-option, it is an ASCII
      text message of the reason for the rejection.

このコマンドは、認証がうまくいかなかったのを示します、そして、サブオプションにそれ以上のデータがあれば、それは拒絶の理由に関するASCIIテキストメッセージです。

   IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
   <KRB_AP_REP message> IAC SE

IAC SB AUTHENTICATION REPLY<認証タイプ組>RESPONSE<KRB_AP_REPメッセージ>IAC SE

      This command is used to perform mutual authentication.  It is only
      used when the AUTH_HOW_MUTUAL bit is set in the second octet of
      the authentication-type-pair.  After an AUTH command is verified,
      a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP
      message to perform the mutual authentication.

このコマンドは、互いの認証を実行するのに使用されます。 AUTH_HOW_MUTUALビットが認証タイプ組の2番目の八重奏で設定されるときだけ、それは使用されます。 AUTHコマンドについて確かめた後に、互いの認証を実行するケルベロスV5 KRB_AP_REPメッセージを含むRESPONSEコマンドを送ります。

Ts'o                        Standards Track                     [Page 2]

RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000

t o標準化過程[2ページ]RFC2942telnet認証: ケルベロス、バージョン2000年9月5日

   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
   message> IAC SE

IAC SB AUTHENTICATION<認証タイプ組>FORWARD<KRB_CREDメッセージ>IAC SE

      This command is used to forward kerberos credentials for use by
      the remote session.  The credentials are passed as a Kerberos V5
      KRB_CRED message which includes, among other things, the forwarded
      Kerberos ticket and a session key associated with the ticket.
      Part of the KRB_CRED message is encrypted in the key previously
      exchanged for the telnet session by the AUTH suboption.

このコマンドは、使用のためにリモートセッションでkerberos資格証明書を進めるのに使用されます。 特に進められたケルベロスチケットを含んでいるケルベロスV5 KRB_CREDメッセージとセッションキーがチケットと交際したので、資格証明書は通過されます。 KRB_CREDメッセージの一部が以前にtelnetセッションのためにAUTH suboptionによって交換されたキーで暗号化されます。

   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC
   SE

IAC SB認証<認証タイプ組の>の前進の_はIAC SEを受け入れます。

      This command indicates that the credential forwarding was
      successful.

このコマンドは、資格証明推進がうまくいったのを示します。

   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT
      <optional reason for rejection> IAC SE

IAC SB AUTHENTICATION<認証タイプ組>のFORWARD_REJECTの<の任意の不合格理由>IAC SE

      This command indicates that the credential forwarding was not
      successful, and if there is any more data in the suboption, it is
      an ASCII text message of the reason for the rejection.

このコマンドは、資格証明推進がうまくいかなかったのを示します、そして、それ以上のデータが「副-オプション」にあれば、それは拒絶の理由に関するASCIIテキストメッセージです。

3.  Implementation Rules

3. 実装規則

   If the second octet of the authentication-type-pair has the AUTH_WHO
   bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial
   AUTH command, and the server responds with either ACCEPT or REJECT.
   In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
   server will send a RESPONSE before it sends the ACCEPT.

認証タイプ組の2番目の八重奏でAUTH_CLIENT_TO_SERVERにAUTH_WHOビットを設定するなら、クライアントは初期のAUTHコマンドを送ります、そして、サーバはACCEPTかREJECTのどちらかと共に反応します。 さらに、AUTH_HOWビットがAUTH_HOW_MUTUALに設定されると、ACCEPTを送る前にサーバはRESPONSEを送るでしょう。

   If the second octet of the authentication-type-pair has the AUTH_WHO
   bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial
   AUTH command, and the client responds with either ACCEPT or REJECT.
   In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
   client will send a RESPONSE before it sends the ACCEPT.

認証タイプ組の2番目の八重奏でAUTH_SERVER_TO_CLIENTにAUTH_WHOビットを設定するなら、サーバは初期のAUTHコマンドを送ります、そして、クライアントはACCEPTかREJECTのどちらかと共に応じます。 さらに、AUTH_HOWビットがAUTH_HOW_MUTUALに設定されると、ACCEPTを送る前にクライアントはRESPONSEを送るでしょう。

   The Kerberos principal used by the server will generally be of the
   form "host/<hostname>@realm".  That is, the first component of the
   Kerberos principal is "host"; the second component is the fully
   qualified lower-case hostname of the server; and the realm is the
   Kerberos realm to which the server belongs.

一般に、サーバによって使用されるケルベロス主体はフォーム" host/<hostname>@realm "のものになるでしょう。 すなわち、ケルベロス主体の最初のコンポーネントは「ホスト」です。 2番目のコンポーネントはサーバの完全に適切な小文字のホスト名です。 そして、分野はサーバが属するケルベロス分野です。

   Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP
   messages, the KRB_CRED structure, or the optional rejection text
   string must be doubled as specified in [4].  Otherwise the following
   byte might be mis-interpreted as a Telnet command.

[4]で指定されるようにKRB_AP_REQに起こるどんなTelnet IACキャラクタ、KRB_AP_REPメッセージ、KRB_CRED構造、または任意の拒絶テキスト文字列も倍にしなければなりません。 さもなければ、以下のバイトはTelnetコマンドとして誤解されるかもしれません。

Ts'o                        Standards Track                     [Page 3]

RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000

t o標準化過程[3ページ]RFC2942telnet認証: ケルベロス、バージョン2000年9月5日

4.  Examples

4. 例

   User "joe" may wish to log in as user "pete" on machine "foo".  If
   "pete" has set things up on "foo" to allow "joe" access to his
   account, then the client would send IAC SB AUTHENTICATION NAME "pete"
   IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE>
   IAC SE

ユーザ"joe"はマシン"foo"のユーザ"pete"としてログインしたがっているかもしれません。 "pete"が彼のアカウントへの"joe"アクセスを許すために"foo"で膳立てしたなら、クライアントはIAC SB AUTHENTICATION NAME"pete"IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH<KRB_AP_REQ_MESSAGE>IAC SEを送るでしょう。

   The server would then authenticate the user as "joe" from the
   KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by
   Kerberos, and if "pete" has allowed "joe" to use his account, the
   server would then continue the authentication sequence by sending a
   RESPONSE (to do mutual authentication, if it was requested) followed
   by the ACCEPT.

次に、サーバは"joe"としてKRB_AP_REQ_MESSAGEからユーザを認証するでしょう、そして、ケルベロスでKRB_AP_REQ_MESSAGEを受け入れて、"pete"が、"joe"が彼のアカウントを使用するのを許容したなら、次に、サーバはACCEPTによって続かれたRESPONSE(それが要求されたなら互いの認証をする)を送ることによって、認証系列を続けているでしょう。

   If forwarding has been requested, the client then sends IAC SB
   AUTHENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED
   structure with credentials to be forwarded> IAC SE.  If the server
   succeeds in reading the forwarded credentials, the server sends
   FORWARD_ACCEPT else, a FORWARD_REJECT is sent back.

推進が要求されるなら、クライアントはIAC SB AUTHENTICATION IS KERBEROS_V5 CLIENTを送ります。|KRB_CREDが>IAC SEを進めるために資格証明書で構造化するMUTUAL FORWARD<。 サーバが、進められた資格証明書を読むのに成功するなら、サーバはほかに_ACCEPTを考慮させるために送って、FORWARD_REJECTは返送されます。

       Client                           Server
                                        IAC DO AUTHENTICATION
       IAC WILL AUTHENTICATION

クライアントサーバIACは認証IACウィル認証をします。

       [ The server is now free to request authentication information.
         ]

[サーバは現在、無料で認証情報を要求できます。]

                                        IAC SB AUTHENTICATION SEND
                                        KERBEROS_V5 CLIENT|MUTUAL
                                        KERBEROS_V5 CLIENT|ONE_WAY IAC
                                        SE

IAC SB認証はケルベロス_V5クライアントを送ります。|互いのケルベロス_V5クライアント|_1つの方法IAC SE

       [ The server has requested mutual Version 5 Kerberos
         authentication.  If mutual authentication is not supported,
         then the server is willing to do one-way authentication.

サーバは互いのバージョンの5つのケルベロスの認証を要求しました。[互いの認証がサポートされないなら、サーバは、一方向認証をしても構わないと思っています。

         The client will now respond with the name of the user that it
         wants to log in as, and the Kerberos ticket.  ]

クライアントは現在、それがログインしたがっているユーザの名前、およびケルベロスチケットで応じるでしょう。 ]

       IAC SB AUTHENTICATION NAME
       "pete" IAC SE
       IAC SB AUTHENTICATION IS
       KERBEROS_V5 CLIENT|MUTUAL AUTH
       <KRB_AP_REQ message> IAC SE

IAC SB認証名前"pete"IAC SE IAC SB認証はケルベロス_V5クライアントです。|MUTUAL AUTH<KRB_AP_REQメッセージ>IAC SE

       [ Since mutual authentication is desired, the server sends across
         a RESPONSE to prove that it really is the right server.  ]

[互いの認証が望まれているので、サーバはそれが本当に正しいサーバであると立証するためにRESPONSEの向こう側に発信します。]

Ts'o                        Standards Track                     [Page 4]

RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000

t o標準化過程[4ページ]RFC2942telnet認証: ケルベロス、バージョン2000年9月5日

                                        IAC SB AUTHENTICATION REPLY
                                        KERBEROS_V5 CLIENT|MUTUAL
                                        RESPONSE <KRB_AP_REP message>
                                        IAC SE

IAC SB認証回答ケルベロス_V5クライアント|MUTUAL RESPONSE<KRB_AP_REPメッセージ>IAC SE

       [ The server responds with an ACCEPT command to state that the
         authentication was successful.  ]

[サーバは認証がうまくいったと述べるACCEPTコマンドで反応します。]

                                        IAC SB AUTHENTICATION REPLY
                                        KERBEROS_V5 CLIENT|MUTUAL ACCEPT
                                        IAC SE

IAC SB認証回答ケルベロス_V5クライアント|互いである、IAC SEを受け入れてください。

       [ If so requested, the client now sends the FORWARD command to
         forward credentials to the remote site.  ]

[そのように要求されるなら、クライアントは現在、資格証明書をリモートサイトに送るコマンドを考慮させるために送ります。]

       IAC SB AUTHENTICATION IS KER-
       BEROS_V5 CLIENT|MUTUAL
       FORWARD <KRB_CRED message> IAC
       SE

IAC SB認証はKER- BEROS_V5クライアントです。|MUTUAL FORWARD<KRB_CREDメッセージ>IAC SE

       [ The server responds with a FORWARD_ACCEPT command to state that
         the credential forwarding was successful.  ]

[サーバは資格証明推進がうまくいったと述べるFORWARD_ACCEPTコマンドで反応します。]

                                        IAC SB AUTHENTICATION REPLY
                                        KERBEROS_V5 CLIENT|MUTUAL
                                        FORWARD_ACCEPT IAC SE

IAC SB認証回答ケルベロス_V5クライアント|互いのフォワード_はIAC SEを受け入れます。

5. Security Considerations

5. セキュリティ問題

   The selection of the random session key in the Kerberos V5
   authenticator is critical, since this key will be used for encrypting
   the telnet data stream if encryption is enabled.  It is strongly
   advised that the random key selection be done using cryptographic
   techniques that involve the Kerberos ticket's session key.  For
   example, using the current time, encrypting it with the ticket
   session key, and then correcting for key parity is a strong way to
   generate a subsession key, since the ticket session key is assumed to
   be never disclosed to an attacker.

ケルベロスV5固有識別文字で主要な無作為のセッションの選択は重要です、このキーが暗号化が可能にされるならtelnetデータ・ストリームを暗号化するのに使用されるので。 ランダムキー選択がケルベロスチケットのセッションキーを伴う暗号のテクニックを使用し終わっていると強く忠告されます。 主要な同等が「副-セッション」キーを生成する強い方法であるので、チケットセッションキーによって攻撃者に決して明らかにされないと思われるとき、例えば、現在の時間を使用して、チケットセッション主要で、次に、修正しているのはそれを暗号化します。

   Care should be taken before forwarding a user's Kerberos credentials
   to the remote server.  If the remote server is not trustworthy, this
   could result in the user's credentials being compromised.  Hence, the
   user interface should not forward credentials by default; it would be
   far safer to either require the user to explicitly request
   credentials forwarding for each connection, or to have a trusted list
   of hosts for which credentials forwarding is enabled, but to not
   enable credentials forwarding by default for all machines.

注意はユーザのケルベロス資格証明書をリモートサーバに送るのに承認させられるべきです。リモートサーバが信頼できないなら、これは感染されるユーザの資格証明書をもたらすかもしれません。 したがって、ユーザーインタフェースはデフォルトで資格証明書を進めるはずがありません。 しかし資格証明書推進が可能にされるホストは、ユーザには、各接続のために明らかに資格証明書推進を要求するか、または信じられたリストがあるのが必要であるようにすべてのマシンのためにデフォルトで資格証明書推進を可能にしないとははるかに安全でしょう。

Ts'o                        Standards Track                     [Page 5]

RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000

t o標準化過程[5ページ]RFC2942telnet認証: ケルベロス、バージョン2000年9月5日

   The IAC SB AUTHENTICATION NAME name IAC SE message is unprotected in
   this protocol.  Its contents should be verified by a secure method
   after authentication completes before it is used.

IAC SB AUTHENTICATION NAME名前IAC SEメッセージはこのプロトコルにおいて保護がありません。 それが使用されている前にコンテンツは後認証が完成する安全なメソッドによって確かめられるべきです。

6. IANA Considerations

6. IANA問題

   The authentication type KERBEROS_V5 and its associated suboption
   values are registered with IANA.  Any suboption values used to extend
   the protocol as described in this document must be registered with
   IANA before use.  IANA is instructed not to issue new suboption
   values without submission of documentation of their use.

認証タイプケルベロス_V5とその関連「副-オプション」値はIANAに示されます。 本書では説明されるようにプロトコルを広げるのに使用されるどんな「副-オプション」値も使用の前のIANAに示さなければなりません。 IANAが彼らの使用のドキュメンテーションの提出なしで新しい「副-オプション」値を発行しないよう命令されます。

7. Acknowledgments

7. 承認

   This document was originally written by Dave Borman of Cray Research,
   Inc.  Theodore Ts'o of MIT revised it to reflect the latest
   implementation experience.  Cliff Neuman and Prasad Upasani of USC's
   Information Sciences Institute developed the credential forwarding
   support.

MITのクレイ・リサーチセオドアTs'oのデーヴ・ボーマンで、最新の実装経験を反映するためにそれを改訂しましたこのドキュメントが元々書かれた。 USCの情報Sciences Instituteのクリフ・ヌーマンとプラサードUpasaniは資格証明推進サポートを開発しました。

   In addition, the contributions of the Telnet Working Group are also
   gratefully acknowledged.

また、さらに、Telnet作業部会の貢献は感謝して承諾されます。

8. References

8. 参照

   [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication
       System (V5)", RFC 1510, September 1993.

[1] コールとJ.とB.ヌーマン、「ケルベロスネットワーク認証システム(V5)」、RFC1510、1993年9月。

   [2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941,
       September 2000.

[2] t oとT.とJ.アルトマン、「telnet認証オプション」、RFC2941、2000年9月。

   [3] Ts'o, T., "Telnet Data Encryption Option", RFC 2946, September
       2000.

[3] t o、T.、「telnetデータ暗号化オプション」、RFC2946、2000年9月。

   [4] Postel, J. and J. Reynolds, "Telnet Option Specifications", STD
       8, RFC 855, May 1983.

[4] ポステル、J.、およびJ.レイノルズ(「telnetオプション仕様」、STD8、RFC855)は1983がそうするかもしれません。

9. Editor's Address

9. エディタのアドレス

   Theodore Ts'o
   VA Linux Systems
   43 Pleasant St.
   Medford, MA 02155

快い聖メドフォード、セオドアt oヴァージニアリナックスSystems43MA 02155

   Phone: (781) 391-3464
   EMail: tytso@mit.edu

以下に電話をしてください。 (781) 391-3464 メールしてください: tytso@mit.edu

Ts'o                        Standards Track                     [Page 6]

RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000

t o標準化過程[6ページ]RFC2942telnet認証: ケルベロス、バージョン2000年9月5日

10. Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Ts'o                        Standards Track                     [Page 7]

規格が追跡するt o[7ページ]