[要約] RFC 2695は、ONC RPCの認証メカニズムに関する規格であり、セキュリティを向上させるために設計されています。このRFCの目的は、ONC RPCの認証プロトコルの標準化と、クライアントとサーバー間の安全な通信を確保することです。
Network Working Group A. Chiu
Request for Comments: 2695 Sun Microsystems
Category: Informational September 1999
Authentication Mechanisms for ONC RPC
ONC RPCの認証メカニズム
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
ABSTRACT
概要
This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol.
このドキュメントでは、Sun Microsystemsによって作成された2つの認証メカニズムについて説明します。これは、ONCリモートプロシージャコール（ONC RPCバージョン2）プロトコルと一般的に使用されています。
WARNING
警告
The DH authentication as defined in Section 2 in this document refers to the authentication mechanism with flavor AUTH_DH currently implemented in ONC RPC. It uses the underlying Diffie-Hellman algorithm for key exchange. The DH authentication defined in this document is flawed due to the selection of a small prime for the BASE field (Section 2.5). To avoid the flaw a new DH authentication mechanism could be defined with a larger prime. However, the new DH authentication would not be interoperable with the existing DH authentication.
このドキュメントのセクション2で定義されているDH認証は、現在ONC RPCで実装されているフレーバーAuth_DHを使用した認証メカニズムを指します。キーエクスチェンジに基礎となるDiffie-Hellmanアルゴリズムを使用します。このドキュメントで定義されているDH認証は、ベースフィールドの小さなプライムの選択により欠陥があります（セクション2.5）。欠陥を回避するために、新しいDH認証メカニズムは、より大きなプライムで定義できます。ただし、新しいDH認証は、既存のDH認証と相互運用できません。
As illustrated in [10], a large number of attacks are possible on ONC RPC system services that use non-secure authentication mechanisms. Other secure authentication mechanisms need to be developed for ONC RPC. RFC 2203 describes the RPCSEC_GSS ONC RPC security flavor, a secure authentication mechanism that enables RPC protocols to use Generic Security Service Application Program Interface (RFC 2078) to provide security services, integrity and privacy, that are independent of the underlying security mechanisms.
[10]に示されているように、非セキュア認証メカニズムを使用するONC RPCシステムサービスでは、多数の攻撃が可能です。ONC RPCのために、他の安全な認証メカニズムを開発する必要があります。RFC 2203は、RPCSEC_GSS ONC RPCセキュリティフレーバーについて説明します。RPCプロトコルが一般的なセキュリティサービスアプリケーションプログラムインターフェイス（RFC 2078）を使用して、基礎となるセキュリティメカニズムとは独立したセキュリティサービス、整合性、プライバシーを提供できる安全な認証メカニズムです。
Table of Contents
目次
1. Introduction ............................................... 2
2. Diffie-Hellman Authentication .............................. 2
2.1 Naming .................................................... 3
2.2 DH Authentication Verifiers ............................... 3
2.3 Nicknames and Clock Synchronization ....................... 5
2.4 DH Authentication Protocol Specification .................. 5
2.4.1 The Full Network Name Credential and Verifier (Client) .. 6
2.4.2 The Nickname Credential and Verifier (Client) ........... 8
2.4.3 The Nickname Verifier (Server) .......................... 9
2.5 Diffie-Hellman Encryption ................................. 9
3. Kerberos-based Authentication ............................. 10
3.1 Naming ................................................... 11
3.2 Kerberos-based Authentication Protocol Specification ..... 11
3.2.1 The Full Network Name Credential and Verifier (Client) . 12
3.2.2 The Nickname Credential and Verifier (Client) .......... 14
3.2.3 The Nickname Verifier (Server) ......................... 15
3.2.4 Kerberos-specific Authentication Status Values ......... 15
4. Security Considerations ................................... 16
5. REFERENCES ................................................ 16
6. AUTHOR'S ADDRESS .......................................... 17
7. FULL COPYRIGHT STATEMENT ...................................18
The ONC RPC protocol provides the fields necessary for a client to identify itself to a service, and vice-versa, in each call and reply message. Security and access control mechanisms can be built on top of this message authentication. Several different authentication protocols can be supported.
ONC RPCプロトコルは、クライアントが各コールと返信メッセージでサービスに自分自身を識別するために必要なフィールドを提供します。セキュリティおよびアクセス制御メカニズムは、このメッセージ認証の上に構築できます。いくつかの異なる認証プロトコルをサポートできます。
This document specifies two authentication protocols created by Sun Microsystems that are commonly used: Diffie-Hellman (DH) authentication and Kerberos (Version 4) based authentication.
このドキュメントは、一般的に使用されるSun Microsystemsによって作成された2つの認証プロトコルを指定します：Diffie-Hellman（DH）認証とKerberos（バージョン4）ベースの認証。
As a prerequisite to reading this document, the reader is expected to be familiar with [1] and [2]. This document uses terminology and definitions from [1] and [2].
このドキュメントを読むための前提条件として、読者は[1]および[2]に精通していると予想されます。このドキュメントでは、[1]および[2]の用語と定義を使用します。
System authentication (defined in [1]) suffers from some problems. It is very UNIX oriented, and can be easily faked (there is no attempt to provide cryptographically secure authentication).
システム認証（[1]で定義）は、いくつかの問題に苦しんでいます。それは非常にUnix指向であり、簡単に偽造することができます（暗号化的に安全な認証を提供する試みはありません）。
DH authentication was created to address these problems. However, it has been compromised [9] due to the selection of a small length for the prime in the ONC RPC implementation. While the information provided here will be useful for implementors to ensure interoperability with existing applications that use DH authentication, it is strongly recommended that new applications use more secure authentication, and that existing applications that currently use DH authentication migrate to more robust authentication mechanisms.
DH認証は、これらの問題に対処するために作成されました。ただし、ONC RPC実装のプライムの長さがわずかに選択されているため、侵害されています[9]。ここで提供される情報は、実装者がDH認証を使用する既存のアプリケーションとの相互運用性を確保するために役立ちますが、新しいアプリケーションがより安全な認証を使用し、現在DH認証を使用している既存のアプリケーションがより堅牢な認証メカニズムに移行することを強くお勧めします。
The client is addressed by a simple string of characters instead of by an operating system specific integer. This string of characters is known as the "netname" or network name of the client. The server is not allowed to interpret the contents of the client's name in any other way except to identify the client. Thus, netnames should be unique for every client in the Internet.
クライアントは、オペレーティングシステム固有の整数ではなく、単純な文字列によってアドレス指定されます。この一連の文字列は、クライアントの「netname」またはネットワーク名として知られています。サーバーは、クライアントを識別する以外に、クライアントの名前のコンテンツを他の方法で解釈することはできません。したがって、NetNamesは、インターネット内のすべてのクライアントにとって一意である必要があります。
It is up to each operating system's implementation of DH authentication to generate netnames for its users that insure this uniqueness when they call upon remote servers. Operating systems already know how to distinguish users local to their systems. It is usually a simple matter to extend this mechanism to the network. For example, a UNIX(tm) user at Sun with a user ID of 515 might be assigned the following netname: "unix.515@sun.com". This netname contains three items that serve to insure it is unique. Going backwards, there is only one naming domain called "sun.com" in the Internet. Within this domain, there is only one UNIX(tm) user with user ID 515. However, there may be another user on another operating system, for example VMS, within the same naming domain that, by coincidence, happens to have the same user ID. To insure that these two users can be distinguished we add the operating system name. So one user is "unix.515@sun.com" and the other is "vms.515@sun.com". The first field is actually a naming method rather than an operating system name. It happens that today there is almost a one-to-one correspondence between naming methods and operating systems. If the world could agree on a naming standard, the first field could be the name of that standard, instead of an operating system name.
各オペレーティングシステムのDH認証の実装次第で、リモートサーバーを呼び出すときにこの一意性を保証するユーザーにネット名を生成します。オペレーティングシステムは、ユーザーをシステムと区別する方法をすでに知っています。通常、このメカニズムをネットワークに拡張することは簡単な問題です。たとえば、515のユーザーIDを持つSunのUNIX（TM）ユーザーには、次のNetName「unix.515@sun.com」が割り当てられる場合があります。このNetNameには、ユニークであることを保証するのに役立つ3つのアイテムが含まれています。後退するには、インターネットには「sun.com」と呼ばれる命名ドメインが1つしかありません。このドメイン内には、ユーザーID 515を備えたUNIX（TM）ユーザーが1人だけです。ただし、同じ命名ドメイン内に、偶然にも同じユーザーがいるのと同じネーミングドメイン内に別のオペレーティングシステムがある場合があります。id。これら2人のユーザーを区別できるようにするために、オペレーティングシステム名を追加します。したがって、1人のユーザーは「unix.515@sun.com」で、もう1人は「vms.515@sun.com」です。最初のフィールドは、実際にはオペレーティングシステム名ではなく、命名方法です。今日、命名方法とオペレーティングシステムの間にはほぼ1対1の対応があることがあります。世界が命名基準に同意できた場合、最初のフィールドは、オペレーティングシステム名の代わりに、その標準の名前になる可能性があります。
Unlike System authentication, DH authentication does have a verifier so the server can validate the client's credential (and vice-versa). The contents of this verifier are primarily an encrypted timestamp. The server can decrypt this timestamp, and if it is within an accepted range relative to the current time, then the client must have encrypted it correctly. The only way the client could encrypt it correctly is to know the "conversation key" of the RPC session, and if the client knows the conversation key, then it must be the real client.
システム認証とは異なり、DH認証には検証剤があり、サーバーはクライアントの資格情報を検証できます（逆も同様）。この検証剤の内容は、主に暗号化されたタイムスタンプです。サーバーはこのタイムスタンプを復号化できます。また、現在の時刻と比較して受け入れられている範囲内にある場合、クライアントはそれを正しく暗号化している必要があります。クライアントがそれを正しく暗号化できる唯一の方法は、RPCセッションの「会話キー」を知ることであり、クライアントが会話キーを知っている場合、それは実際のクライアントでなければなりません。
The conversation key is a DES [5] key which the client generates and passes to the server in the first RPC call of a session. The conversation key is encrypted using a public key scheme in this first transaction. The particular public key scheme used in DH authentication is Diffie-Hellman [3] with 192-bit keys. The details of this encryption method are described later.
会話キーは、セッションの最初のRPC呼び出しでクライアントが生成してサーバーに渡すDES [5]キーです。会話キーは、この最初のトランザクションで公開キースキームを使用して暗号化されます。DH認証で使用される特定の公開キースキームは、192ビットキーを備えたDiffie-Hellman [3]です。この暗号化方法の詳細については、後で説明します。
The client and the server need the same notion of the current time in order for all of this to work, perhaps by using the Network Time Protocol [4]. If network time synchronization cannot be guaranteed, then the client can determine the server's time before beginning the conversation using a time request protocol.
クライアントとサーバーは、おそらくネットワークタイムプロトコル[4]を使用して、これらすべてが機能するために、現在の時間と同じ概念を必要とします。ネットワークタイムの同期を保証できない場合、クライアントは時間リクエストプロトコルを使用して会話を開始する前にサーバーの時間を決定できます。
The way a server determines if a client timestamp is valid is somewhat complicated. For any other transaction but the first, the server just checks for two things:
クライアントのタイムスタンプが有効であるかどうかをサーバーが判断する方法はやや複雑です。他のトランザクション以外のトランザクションについては、サーバーは2つのことをチェックするだけです。
(1) the timestamp is greater than the one previously seen from the same client. (2) the timestamp has not expired.
(1) タイムスタンプは、同じクライアントから以前に見られたものよりも大きいです。（2）タイムスタンプは期限切れになっていません。
A timestamp is expired if the server's time is later than the sum of the client's timestamp plus what is known as the client's "ttl" (standing for "time-to-live" - you can think of this as the lifetime for the client's credential). The "ttl" is a number the client passes (encrypted) to the server in its first transaction.
サーバーの時間がクライアントのタイムスタンプの合計とクライアントの「TTL」と呼ばれるもの（「時間」に立つ」の合計よりも遅れている場合、タイムスタンプが期限切れになります。これは、クライアントの資格情報の生涯と考えることができます）。「TTL」は、最初のトランザクションでクライアントがサーバーに渡す（暗号化された）数です。
In the first transaction, the server checks only that the timestamp has not expired. Also, as an added check, the client sends an encrypted item in the first transaction known as the "ttl verifier" which must be equal to the time-to-live minus 1, or the server will reject the credential. If either check fails, the server rejects the credential with an authentication status of AUTH_BADCRED, however if the timestamp is earlier than the previous one seen, the server returns an authentication status of AUTH_REJECTEDCRED.
最初のトランザクションでは、サーバーはタイムスタンプが期限切れになっていないことのみをチェックします。また、追加のチェックとして、クライアントは「TTL Verifier」として知られる最初のトランザクションで暗号化されたアイテムを送信します。これは、時間をマイナス1に等しくする必要があります。そうしないと、サーバーは資格情報を拒否します。いずれかのチェックが失敗した場合、サーバーはauth_badcredの認証ステータスを使用して資格情報を拒否しますが、タイムスタンプが前のものよりも早くなった場合、サーバーはauth_rejedcredの認証ステータスを返します。
The client too must check the verifier returned from the server to be sure it is legitimate. The server sends back to the client the timestamp it received from the client, minus one second, encrypted with the conversation key. If the client gets anything different than this, it will reject it, returning an AUTH_INVALIDRESP authentication status to the user.
クライアントも、サーバーから返された検証剤を確認して、正当であることを確認する必要があります。サーバーは、クライアントから受け取ったタイムスタンプをクライアントに送り返します。クライアントがこれと違うものを取得した場合、それはそれを拒否し、auth_invalidResp認証ステータスをユーザーに返します。
After the first transaction, the server's DH authentication subsystem returns in its verifier to the client an integer "nickname" which the client may use in its further transactions instead of passing its netname. The nickname could be an index into a table on the server which stores for each client its netname, decrypted conversation key and ttl.
最初のトランザクションの後、サーバーのDH認証サブシステムは、その検証者でクライアントに、クライアントがNetNameを通過する代わりにさらにトランザクションで使用できる整数「ニックネーム」を返します。ニックネームは、各クライアントにNetName、Decrypted Conversation Key、TTLを保存するサーバー上のテーブルへのインデックスである可能性があります。
Though they originally were synchronized, the client's and server's clocks can get out of synchronization again. When this happens the server returns to the client an authentication status of AUTH_REJECTEDVERF at which point the client should attempt to resynchronize.
もともとは同期されていましたが、クライアントとサーバーの時計は再び同期から抜け出すことができます。これが発生すると、サーバーはクライアントにauth_rejectedverfの認証ステータスを返します。
A client may also get an AUTH_BADCRED error when using a nickname that was previously valid. The reason is that the server's nickname table is a limited size, and it may flush entries whenever it wants. A client should resend its original full name credential in this case and the server will give it a new nickname. If a server crashes, the entire nickname table gets flushed, and all clients will have to resend their original credentials.
クライアントは、以前に有効だったニックネームを使用する場合、AUTH_BADCREDエラーを取得する場合があります。その理由は、サーバーのニックネームテーブルが限られたサイズであり、必要に応じてエントリをフラッシュする可能性があるためです。この場合、クライアントは元のフルネーム資格情報を再送信する必要があり、サーバーは新しいニックネームを提供します。サーバーがクラッシュすると、ニックネームテーブル全体がフラッシュされ、すべてのクライアントが元の資格情報を再送信する必要があります。
There are two kinds of credentials: one in which the client uses its full network name, and one in which it uses its "nickname" (just an unsigned integer) given to it by the server. The client must use its fullname in its first transaction with the server, in which the server will return to the client its nickname. The client may use its nickname in all further transactions with the server. There is no requirement to use the nickname, but it is wise to use it for performance reasons.
資格情報には2種類の資格があります。1つは、クライアントが完全なネットワーク名を使用し、1つはサーバーから与えられた「ニックネーム」（署名のない整数だけ）を使用するものです。クライアントは、サーバーとの最初のトランザクションでフルネームを使用する必要があります。サーバーでは、サーバーがクライアントにニックネームを返します。クライアントは、サーバーを使用したすべてのトランザクションでニックネームを使用できます。ニックネームを使用する必要はありませんが、パフォーマンス上の理由で使用することは賢明です。
The following definitions are used for describing the protocol:
次の定義は、プロトコルを説明するために使用されます。
enum authdh_namekind { ADN_FULLNAME = 0, ADN_NICKNAME = 1 };
enum authdh_namekind {adn_fullname = 0、adn_nickname = 1};
typedef opaque des_block[8]; /* 64-bit block of encrypted data */
const MAXNETNAMELEN = 255; /* maximum length of a netname */
The flavor used for all DH authentication credentials and verifiers
is "AUTH_DH", with the numerical value 3. The opaque data
constituting the client credential encodes the following structure:
union authdh_cred switch (authdh_namekind namekind) {
case ADN_FULLNAME:
authdh_fullname fullname;
case ADN_NICKNAME:
authdh_nickname nickname;
};
The opaque data constituting a verifier that accompanies a client credential encodes the following structure:
クライアントの資格情報に付随する検証剤を構成する不透明データは、次の構造をエンコードします。
union authdh_verf switch (authdh_namekind namekind) {
case ADN_FULLNAME:
authdh_fullname_verf fullname_verf;
case ADN_NICKNAME:
authdh_nickname_verf nickname_verf;
};
The opaque data constituting a verifier returned by a server in response to a client request encodes the following structure:
クライアントリクエストに応じてサーバーによって返される検証者を構成する不透明なデータは、次の構造をエンコードします。
struct authdh_server_verf;
struct authdh_server_verf;
These structures are described in detail below.
これらの構造については、以下で詳しく説明しています。
First, the client creates a conversation key for the session. Next, the client fills out the following structure:
まず、クライアントはセッションの会話キーを作成します。次に、クライアントは次の構造に記入します。
+---------------------------------------------------------------+
| timestamp | timestamp | | |
| seconds | micro seconds | ttl | ttl - 1 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
The fields are stored in XDR (external data representation) format. The timestamp encodes the time since midnight, January 1, 1970. These 128 bits of data are then encrypted in the DES CBC mode, using the conversation key for the session, and with an initialization vector of 0. This yields:
フィールドはXDR（外部データ表現）形式に保存されます。タイムスタンプは、1970年1月1日の真夜中からの時間をエンコードします。これらの128ビットのデータは、セッションの会話キーを使用して、0の初期化ベクトルでDES CBCモードで暗号化されます。
+---------------------------------------------------------------+
| T | | |
| T1 T2 | W1 | W2 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
where T1, T2, W1, and W2 are all 32-bit quantities, and have some correspondence to the original quantities occupying their positions, but are now interdependent on each other for proper decryption. The 64 bit sequence comprising T1 and T2 is denoted by T.
ここで、T1、T2、W1、およびW2はすべて32ビット量であり、その位置を占める元の量にある程度の対応を持っていますが、適切な復号化のために互いに依存しています。T1とT2を含む64ビットシーケンスは、Tで示されます。
The full network name credential is represented as follows using XDR notation:
完全なネットワーク名の資格情報は、XDR表記を使用して次のように表されます。
struct authdh_fullname {
string name<MAXNETNAMELEN>; /* netname of client */
des_block key; /* encrypted conversation key */
opaque w1[4]; /* W1 */
};
The conversation key is encrypted using the "common key" using the ECB mode. The common key is a DES key that is derived from the Diffie-Hellman public and private keys, and is described later.
会話キーは、ECBモードを使用して「共通キー」を使用して暗号化されます。共通キーは、Diffie-Hellmanのパブリックキーとプライベートキーから派生したDESキーであり、後で説明します。
The verifier is represented as follows:
検証剤は次のように表されます。
struct authdh_fullname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w2[4]; /* W2 */
};
Note that all of the encrypted quantities (key, w1, w2, timestamp) in the above structures are opaque.
上記の構造の暗号化された量（キー、W1、W2、タイムスタンプ）はすべて不透明であることに注意してください。
The fullname credential and its associated verifier together contain the network name of the client, an encrypted conversation key, the ttl, a timestamp, and a ttl verifier that is one less than the ttl. The ttl is actually the lifetime for the credential. The server will accept the credential if the current server time is "within" the time indicated in the timestamp plus the ttl. Otherwise, the server rejects the credential with an authentication status of AUTH_BADCRED. One way to insure that requests are not replayed would be for the server to insist that timestamps are greater than the previous one seen, unless it is the first transaction. If the timestamp is earlier than the previous one seen, the server returns an authentication status of AUTH_REJECTEDCRED.
FullName資格情報と関連する検証剤には、クライアントのネットワーク名、暗号化された会話キー、TTL、タイムスタンプ、TTLよりも1つ少ないTTL検証が含まれています。TTLは、実際には資格情報の寿命です。現在のサーバー時間がタイムスタンプとTTLに示されている時間の「内」にある場合、サーバーは資格情報を受け入れます。それ以外の場合、サーバーはauth_badcredの認証ステータスで資格情報を拒否します。リクエストが再生されないことを保証する1つの方法は、サーバーが最初のトランザクションでない限り、タイムスタンプが前のものよりも大きいことを主張することです。タイムスタンプが前の見られたものよりも早い場合、サーバーはauth_rejectedcredの認証ステータスを返します。
The server returns a authdh_server_verf structure, which is described in detail below. This structure contains a "nickname", which may be used for subsequent requests in the current conversation.
サーバーは、authdh_server_verf構造を返します。これについては、以下で詳しく説明します。この構造には、「ニックネーム」が含まれています。これは、現在の会話の後続の要求に使用できます。
In transactions following the first, the client may use the shorter nickname credential and verifier for efficiency. First, the client fills out the following structure:
最初のトランザクションでは、クライアントは効率のために短いニックネームの資格情報と検証者を使用することができます。まず、クライアントは次の構造に記入します。
+-------------------------------+
| timestamp | timestamp |
| seconds | micro seconds |
| 32 bits | 32 bits |
+-------------------------------+
0 31 63
The fields are stored in XDR (external data representation) format. These 64 bits of data are then encrypted in the DES ECB mode, using the conversation key for the session. This yields:
フィールドはXDR（外部データ表現）形式に保存されます。これらの64ビットのデータは、セッションの会話キーを使用して、DES ECBモードで暗号化されます。これは得られます：
+-------------------------------+
| (T1) | (T2) |
| T |
| 64 bits |
+-------------------------------+
0 31 63
The nickname credential is represented as follows using XDR notation:
ニックネームの資格情報は、XDR表記を使用して次のように表されます。
struct authdh_nickname {
unsigned int nickname; /* nickname returned by server */
};
The nickname verifier is represented as follows using XDR notation:
ニックネームVerifierは、XDR表記を使用して次のように表されます。
struct authdh_nickname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w[4]; /* Set to zero */
};
The nickname credential may be reject by the server for several reasons. An authentication status of AUTH_BADCRED indicates that the nickname is no longer valid. The client should retry the request using the fullname credential. AUTH_REJECTEDVERF indicates that the nickname verifier is not valid. Again, the client should retry the request using the fullname credential.
ニックネームの資格情報は、いくつかの理由でサーバーによって拒否される場合があります。auth_badcredの認証ステータスは、ニックネームがもはや有効でないことを示します。クライアントは、FullName資格情報を使用してリクエストを再試行する必要があります。auth_rejectedverfは、ニックネームVerifierが無効であることを示します。繰り返しますが、クライアントはFullName資格情報を使用してリクエストを再試行する必要があります。
The server never returns a credential. It returns only one kind of verifier, i.e., the nickname verifier. This has the following XDR representation:
サーバーが資格情報を返すことはありません。1種類の検証者、つまりニックネームの検証者のみを返します。これには次のXDR表現があります。
struct authdh_server_verf {
des_block timestamp_verf; /* timestamp verifier (encrypted) */
unsigned int nickname; /* new client nickname (unencrypted) */
};
The timestamp verifier is constructed in exactly the same way as the client nickname credential. The server sets the timestamp value to the value the client sent minus one second and encrypts it in DES ECB mode using the conversation key. The server also sends the client a nickname to be used in future transactions (unencrypted).
Timestamp Verifierは、クライアントのニックネーム資格情報とまったく同じ方法で構築されます。サーバーは、クライアントが送信した値にタイムスタンプの値をマイナス1秒に設定し、会話キーを使用してDES ECBモードで暗号化します。サーバーはまた、将来のトランザクションで使用されるニックネームをクライアントに送信します（暗号化されていません）。
In this scheme, there are two constants "BASE" and "MODULUS" [3]. The particular values Sun has chosen for these for the DH authentication protocol are:
このスキームには、2つの定数「ベース」と「モジュラス」があります[3]。DH認証プロトコルのために、Sunがこれらのために選択した特定の価値は次のとおりです。
const BASE = 3;
const MODULUS = "d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b";
Note that the modulus is represented above as a hexadecimal string.
モジュラスは、上記の16進列として表されていることに注意してください。
The way this scheme works is best explained by an example. Suppose there are two people "A" and "B" who want to send encrypted messages to each other. So, A and B both generate "secret" keys at random which they do not reveal to anyone. Let these keys be represented as SK(A) and SK(B). They also publish in a public directory their "public" keys. These keys are computed as follows:
このスキームの仕組みは、例で最もよく説明されます。暗号化されたメッセージをお互いに送信したい「A」と「B」が2人いるとします。したがって、AとBはどちらもランダムに「秘密」キーを生成し、誰にも明らかにしません。これらのキーをSK（a）およびSK（b）として表現します。また、公開ディレクトリに「パブリック」キーを公開しています。これらのキーは次のように計算されます。
PK(A) = ( BASE ** SK(A) ) mod MODULUS
PK(B) = ( BASE ** SK(B) ) mod MODULUS
The "**" notation is used here to represent exponentiation. Now, both A and B can arrive at the "common" key between them, represented here as CK(A, B), without revealing their secret keys.
ここでは、「**」表記を使用して指数を表すために使用されます。現在、AとBの両方が、秘密の鍵を明らかにすることなく、ここでCK（A、B）として表される「共通」キーに到達することができます。
A computes:
コンピューター：
CK(A, B) = ( PK(B) ** SK(A)) mod MODULUS
while B computes:
Bが計算されます：
CK(A, B) = ( PK(A) ** SK(B)) mod MODULUS
These two can be shown to be equivalent:
これら2つは同等であることが示されます。
(PK(B) ** SK(A)) mod MODULUS = (PK(A) ** SK(B)) mod MODULUS
We drop the "mod MODULUS" parts and assume modulo arithmetic to simplify things:
「mod modulus」部分をドロップし、モジュロ算術を想定して物事を簡素化します。
PK(B) ** SK(A) = PK(A) ** SK(B)
Then, replace PK(B) by what B computed earlier and likewise for PK(A).
次に、Pk（b）を以前に計算したもので、同様にPk（a）を置き換えます。
(BASE ** SK(B)) ** SK(A) = (BASE ** SK(A)) ** SK(B)
which leads to:
これは次のとおりです。
BASE ** (SK(A) * SK(B)) = BASE ** (SK(A) * SK(B))
This common key CK(A, B) is not used to encrypt the timestamps used in the protocol. Rather, it is used only to encrypt a conversation key which is then used to encrypt the timestamps. The reason for doing this is to use the common key as little as possible, for fear that it could be broken. Breaking the conversation key is a far less damaging, since conversations are relatively short-lived.
この共通のキーCK（A、B）は、プロトコルで使用されるタイムスタンプを暗号化するために使用されません。むしろ、会話キーを暗号化するためにのみ使用され、タイムスタンプの暗号化に使用されます。これを行う理由は、それが壊れる可能性があるのではないかと恐れて、できる限り共通キーを使用することです。会話の鍵を壊すことは、比較的短命であるため、はるかに損害が少なくなります。
The conversation key is encrypted using 56-bit DES keys, yet the common key is 192 bits. To reduce the number of bits, 56 bits are selected from the common key as follows. The middle-most 8-bytes are selected from the common key, and then parity is added to the lower order bit of each byte, producing a 56-bit key with 8 bits of parity.
会話キーは56ビットDESキーを使用して暗号化されますが、共通キーは192ビットです。ビット数を減らすために、次のように共通キーから56ビットが選択されます。中間の8バイトは共通キーから選択され、その後、各バイトの低次ビットにパリティが追加され、8ビットのパリティを備えた56ビットキーが生成されます。
Only 48 bits of the 8-byte conversation key are used in the DH Authentication scheme. The least and most significant bits of each byte of the conversation key are unused.
DH認証スキームでは、8バイトの会話キーのわずか48ビットが使用されています。会話キーの各バイトの最小で最も重要なビットは未使用です。
Conceptually, Kerberos-based authentication is very similar to DH authentication. The major difference is, Kerberos-based authentication takes advantage of the fact that Kerberos tickets have encoded in them the client name and the conversation key. This RFC does not describe Kerberos name syntax, protocols and ticket formats. The reader is referred to [6], [7], and [8].
概念的には、Kerberosベースの認証はDH認証に非常に似ています。大きな違いは、Kerberosに拠点を置く認証は、Kerberosのチケットがクライアント名と会話キーをエンコードしたという事実を利用していることです。このRFCは、Kerberosの名前の構文、プロトコル、チケット形式を説明していません。読者は[6]、[7]、および[8]と呼ばれます。
A Kerberos name contains three parts. The first is the principal name, which is usually a user's or service's name. The second is the instance, which in the case of a user is usually NULL. Some users may have privileged instances, however, such as root or admin. In the case of a service, the instance is the name of the machine on which it runs; that is, there can be an NFS service running on the machine ABC, which is different from the NFS service running on the machine XYZ. The third part of a Kerberos name is the realm. The realm corresponds to the Kerberos service providing authentication for the principal. When writing a Kerberos name, the principal name is separated from the instance (if not NULL) by a period, and the realm (if not the local realm) follows, preceded by an "@" sign. The following are examples of valid Kerberos names:
Kerberosの名前には3つの部分が含まれています。1つ目は主名で、通常はユーザーまたはサービスの名前です。2つ目はインスタンスで、ユーザーの場合は通常nullです。ただし、ルートや管理者など、特権のあるインスタンスがある場合もあります。サービスの場合、インスタンスはそれが実行されるマシンの名前です。つまり、マシンABCで実行されているNFSサービスがある場合があります。これは、マシンXYZで実行されているNFSサービスとは異なります。Kerberosの名前の3番目の部分は領域です。領域は、プリンシパルに認証を提供するKerberosサービスに対応しています。Kerberosの名前を書くとき、主名はインスタンス（nullではないにしても）から期間ごとに分離され、領域（ローカルレルムではないにしても）が「@」記号が続きます。以下は、有効なKerberosの名前の例です。
billb jis.admin srz@lcs.mit.edu treese.root@athena.mit.edu
Billb jis.admin srz@lcs.mit.edu treese.root@athena.mit.edu
The Kerberos-based authentication protocol described is based on Kerberos version 4.
説明されているKerberosベースの認証プロトコルは、Kerberosバージョン4に基づいています。
There are two kinds of credentials: one in which the client uses its full network name, and one in which it uses its "nickname" (just an unsigned integer) given to it by the server. The client must use its fullname in its first transaction with the server, in which the server will return to the client its nickname. The client may use its nickname in all further transactions with the server. There is no requirement to use the nickname, but it is wise to use it for performance reasons.
資格情報には2種類の資格があります。1つは、クライアントが完全なネットワーク名を使用し、1つはサーバーから与えられた「ニックネーム」（署名のない整数だけ）を使用するものです。クライアントは、サーバーとの最初のトランザクションでフルネームを使用する必要があります。サーバーでは、サーバーがクライアントにニックネームを返します。クライアントは、サーバーを使用したすべてのトランザクションでニックネームを使用できます。ニックネームを使用する必要はありませんが、パフォーマンス上の理由で使用することは賢明です。
The following definitions are used for describing the protocol:
次の定義は、プロトコルを説明するために使用されます。
enum authkerb4_namekind { AKN_FULLNAME = 0, AKN_NICKNAME = 1 };
enum authkerb4_namekind {akn_fullname = 0、akn_nickname = 1};
The flavor used for all Kerberos-based authentication credentials and verifiers is "AUTH_KERB4", with numerical value 4. The opaque data constituting the client credential encodes the following structure:
すべてのKerberosベースの認証資格情報と検証剤に使用されるフレーバーは、「auth_kerb4」であり、数値4があります。クライアント資格情報を構成する不透明なデータは、次の構造をエンコードします。
union authkerb4_cred switch (authkerb4_namekind namekind) {
case AKN_FULLNAME:
authkerb4_fullname fullname;
case AKN_NICKNAME:
authkerb4_nickname nickname;
};
The opaque data constituting a verifier that accompanies a client credential encodes the following structure:
クライアントの資格情報に付随する検証剤を構成する不透明データは、次の構造をエンコードします。
union authkerb4_verf switch (authkerb4_namekind namekind) {
case AKN_FULLNAME:
authkerb4_fullname_verf fullname_verf;
case AKN_NICKNAME:
authkerb4_nickname_verf nickname_verf;
};
The opaque data constituting a verifier returned by a server in response to a client request encodes the following structure:
クライアントリクエストに応じてサーバーによって返される検証者を構成する不透明なデータは、次の構造をエンコードします。
struct authkerb4_server_verf;
struct authkerb4_server_verf;
These structures are described in detail below.
これらの構造については、以下で詳しく説明しています。
First, the client must obtain a Kerberos ticket from the Kerberos Server. The ticket contains a Kerberos session key, which will become the conversation key. Next, the client fills out the following structure:
まず、クライアントはKerberosサーバーからKerberosチケットを取得する必要があります。チケットにはKerberosセッションキーが含まれており、会話キーになります。次に、クライアントは次の構造に記入します。
+---------------------------------------------------------------+
| timestamp | timestamp | | |
| seconds | micro seconds | ttl | ttl - 1 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
The fields are stored in XDR (external data representation) format. The timestamp encodes the time since midnight, January 1, 1970. "ttl" is identical in meaning to the corresponding field in Diffie-Hellman authentication: the credential "time-to-live" for the conversation being initiated. These 128 bits of data are then encrypted in the DES CBC mode, using the conversation key, and with an initialization vector of 0. This yields:
フィールドはXDR（外部データ表現）形式に保存されます。タイムスタンプは、1970年1月1日の真夜中からの時間をエンコードします。「TTL」は、Diffie-Hellman認証の対応するフィールドと同一です。これらの128ビットのデータは、会話キーを使用してDES CBCモードで暗号化され、初期化ベクトル0で暗号化されます。
+---------------------------------------------------------------+
| T | | |
| T1 T2 | W1 | W2 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
where T1, T2, W1, and W2 are all 32-bit quantities, and have some correspondence to the original quantities occupying their positions, but are now interdependent on each other for proper decryption. The 64 bit sequence comprising T1 and T2 is denoted by T.
ここで、T1、T2、W1、およびW2はすべて32ビット量であり、その位置を占める元の量にある程度の対応を持っていますが、適切な復号化のために互いに依存しています。T1とT2を含む64ビットシーケンスは、Tで示されます。
The full network name credential is represented as follows using XDR notation:
完全なネットワーク名の資格情報は、XDR表記を使用して次のように表されます。
struct authkerb4_fullname {
opaque ticket<>; /* kerberos ticket for the server */
opaque w1[4]; /* W1 */
};
The verifier is represented as follows:
検証剤は次のように表されます。
struct authkerb4_fullname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w2[4]; /* W2 */
};
Note that all of the client-encrypted quantities (w1, w2, timestamp) in the above structures are opaque. The client does not encrypt the Kerberos ticket for the server.
上記の構造のすべてのクライアント暗号化された量（W1、W2、タイムスタンプ）は不透明であることに注意してください。クライアントは、サーバーのKerberosチケットを暗号化しません。
The fullname credential and its associated verifier together contain the Kerberos ticket (which contains the client name and the conversation key), the ttl, a timestamp, and a ttl verifier that is one less than the ttl. The ttl is actually the lifetime for the credential. The server will accept the credential if the current server time is "within" the time indicated in the timestamp plus the ttl. Otherwise, the server rejects the credential with an authentication status of AUTH_BADCRED. One way to insure that requests are not replayed would be for the server to insist that timestamps are greater than the previous one seen, unless it is the first transaction. If the timestamp is earlier than the previous one seen, the server returns an authentication status of AUTH_REJECTEDCRED.
FullName資格情報とそれに関連する検証剤には、Kerberosチケット（クライアント名と会話キーが含まれています）、TTL、タイムスタンプ、TTLよりも1枚少ないTTL検証が含まれています。TTLは、実際には資格情報の寿命です。現在のサーバー時間がタイムスタンプとTTLに示されている時間の「内」にある場合、サーバーは資格情報を受け入れます。それ以外の場合、サーバーはauth_badcredの認証ステータスで資格情報を拒否します。リクエストが再生されないことを保証する1つの方法は、サーバーが最初のトランザクションでない限り、タイムスタンプが前のものよりも大きいことを主張することです。タイムスタンプが前の見られたものよりも早い場合、サーバーはauth_rejectedcredの認証ステータスを返します。
The server returns a authkerb4_server_verf structure, which is described in detail below. This structure contains a "nickname", which may be used for subsequent requests in the current session.
サーバーは、authkerb4_server_verf構造を返します。これについては、以下で詳しく説明します。この構造には、「ニックネーム」が含まれています。これは、現在のセッションでその後のリクエストに使用される場合があります。
In transactions following the first, the client may use the shorter nickname credential and verifier for efficiency. First, the client fills out the following structure:
最初のトランザクションでは、クライアントは効率のために短いニックネームの資格情報と検証者を使用することができます。まず、クライアントは次の構造に記入します。
+-------------------------------+
| timestamp | timestamp |
| seconds | micro seconds |
| 32 bits | 32 bits |
+-------------------------------+
0 31 63
The fields are stored in XDR (external data representation) format. These 64 bits of data are then encrypted in the DES ECB mode, using the conversation key for the session. This yields:
フィールドはXDR（外部データ表現）形式に保存されます。これらの64ビットのデータは、セッションの会話キーを使用して、DES ECBモードで暗号化されます。これは得られます：
+-------------------------------+
| (T1) | (T2) |
| T |
| 64 bits |
+-------------------------------+
0 31 63
The nickname credential is represented as follows using XDR notation:
ニックネームの資格情報は、XDR表記を使用して次のように表されます。
struct authkerb4_nickname {
unsigned int nickname; /* nickname returned by server */
};
The nickname verifier is represented as follows using XDR notation:
ニックネームVerifierは、XDR表記を使用して次のように表されます。
struct authkerb4_nickname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w[4]; /* Set to zero */
};
The nickname credential may be reject by the server for several reasons. An authentication status of AUTH_BADCRED indicates that the nickname is no longer valid. The client should retry the request using the fullname credential. AUTH_REJECTEDVERF indicates that the nickname verifier is not valid. Again, the client should retry the request using the fullname credential. AUTH_TIMEEXPIRE indicates that the session's Kerberos ticket has expired. The client should initiate a new session by obtaining a new Kerberos ticket.
ニックネームの資格情報は、いくつかの理由でサーバーによって拒否される場合があります。auth_badcredの認証ステータスは、ニックネームがもはや有効でないことを示します。クライアントは、FullName資格情報を使用してリクエストを再試行する必要があります。auth_rejectedverfは、ニックネームVerifierが無効であることを示します。繰り返しますが、クライアントはFullName資格情報を使用してリクエストを再試行する必要があります。auth_timeexpireは、セッションのKerberosチケットの有効期限が切れたことを示しています。クライアントは、新しいKerberosチケットを取得して新しいセッションを開始する必要があります。
The server never returns a credential. It returns only one kind of verifier, i.e., the nickname verifier. This has the following XDR representation:
サーバーが資格情報を返すことはありません。1種類の検証者、つまりニックネームの検証者のみを返します。これには次のXDR表現があります。
struct authkerb4_server_verf {
des_block timestamp_verf; /* timestamp verifier (encrypted) */
unsigned int nickname; /* new client nickname (unencrypted) */
};
The timestamp verifier is constructed in exactly the same way as the client nickname credential. The server sets the timestamp value to the value the client sent minus one second and encrypts it in DES ECB mode using the conversation key. The server also sends the client a nickname to be used in future transactions (unencrypted).
Timestamp Verifierは、クライアントのニックネーム資格情報とまったく同じ方法で構築されます。サーバーは、クライアントが送信した値にタイムスタンプの値をマイナス1秒に設定し、会話キーを使用してDES ECBモードで暗号化します。サーバーはまた、将来のトランザクションで使用されるニックネームをクライアントに送信します（暗号化されていません）。
The server may return to the client one of the following errors in the authentication status field:
サーバーは、認証ステータスフィールドの次のエラーのいずれかをクライアントに戻すことができます。
enum auth_stat {
...
/*
* kerberos errors
*/
AUTH_KERB_GENERIC = 8, /* Any Kerberos-specific error other
than the following */
AUTH_TIMEEXPIRE = 9, /* The client's ticket has expired */
AUTH_TKT_FILE = 10, /* The server was unable to find the
ticket file. The client should
create a new session by obtaining a
new ticket */
AUTH_DECODE = 11, /* The server is unable to decode the
authenticator of the client's ticket */
AUTH_NET_ADDR = 12 /* The network address of the client
does not match the address contained
in the ticket */
/* and more to be defined */
};
The DH authentication mechanism and the Kerberos V4 authentication mechanism are described in this document only for informational purposes.
DH認証メカニズムとKerberos V4認証メカニズムは、このドキュメントでのみ情報目的で説明されています。
In addition to the weakness pointed out earlier in this document (see WARNING on page 1), the two security mechanisms described herein lack the support for integrity and privacy data protection. It is strongly recommended that new applications use more secure mechanisms, and that existing applications migrate to more robust mechanisms.
このドキュメントの前半で指摘されている弱点に加えて（1ページの警告を参照）、ここで説明する2つのセキュリティメカニズムには、整合性とプライバシーデータ保護のサポートがありません。新しいアプリケーションがより安全なメカニズムを使用し、既存のアプリケーションがより堅牢なメカニズムに移行することを強くお勧めします。
The RPCSEC_GSS ONC RPC security flavor, specified in RFC 2203, allows applications built on top of RPC to access security mechanisms that adhere to the GSS-API specification. It provides a GSS-API based security framework that allows for strong security mechanisms. RFC 1964 describes the Kerberos Version 5 GSS-API security mechanism which provides integrity and privacy, in addition to authentication. RFC 2623 [14] describes how Kerberos V5 is pluggued into RPCSEC_GSS, and how the Version 2 and Version 3 of the NFS protocol use Kerberos V5 via RPCSEC_GSS. The RPCSEC_GSS/GSS-API/Kerberos-V5 stack provides a robust security mechanism for applications that require strong protection.
RPCSEC_GSS ONC RPCセキュリティフレーバーは、RFC 2203で指定されているため、RPCの上に構築されたアプリケーションがGSS-API仕様に従うセキュリティメカニズムにアクセスできるようになります。強力なセキュリティメカニズムを可能にするGSS-APIベースのセキュリティフレームワークを提供します。RFC 1964は、認証に加えて、整合性とプライバシーを提供するKerberosバージョン5 GSS-APIセキュリティメカニズムについて説明しています。RFC 2623 [14]は、Kerberos v5がRPCSEC_GSSにどのようにプラグされるか、およびNFSプロトコルのバージョン2とバージョン3がRPCSEC_GSSを介してKerberos V5をどのように使用するかを説明しています。RPCSEC_GSS/GSS-API/Kerberos-V5スタックは、強力な保護を必要とするアプリケーションに堅牢なセキュリティメカニズムを提供します。
[1] Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC 1831, August 1995.
[1] Srinivasan、R。、「リモート手順コールプロトコルバージョン2」、RFC 1831、1995年8月。
[2] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[2] Srinivasan、R。、「XDR：外部データ表現標準」、RFC 1832、1995年8月。
[3] Diffie & Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory IT-22, November 1976.
[3] Diffie and Hellman、「暗号化の新しい方向」、IEEE情報理論IT-22、1976年11月。
[4] Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March 1992.
[4] Mills、D。、「ネットワークタイムプロトコル（バージョン3）」、RFC 1305、1992年3月。
[5] National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standards Publication 46, January 1977.
[5] National Bureau of Standards、「Data Encryption Standard」、連邦情報処理基準出版46、1977年1月。
[6] Miller, S., Neuman, C., Schiller, J. and J. Saltzer, "Section E.2.1: Kerberos Authentication and Authorization System", December 1987.
[6] Miller、S.、Neuman、C.、Schiller、J。and J. Saltzer、「セクションE.2.1：Kerberos認証および認証システム」、1987年12月。
[7] Steiner, J., Neuman, C. and J. Schiller, "Kerberos: An Authentication Service for Open Network Systems", pp. 191-202 in Usenix Conference Proceedings, Dallas, Texas, February, 1988.
[7] Steiner、J.、Neuman、C。and J. Schiller、「Kerberos：Open Network Systemsの認証サービス」、1988年2月、テキサス州ダラスのUsenix Conference Proceedingsの191-202ページ。
[8] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[8] Kohl、J。およびC. Neuman、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。
[9] La Macchia, B.A., and Odlyzko, A.M., "Computation of Discrete Logarithms in Prime Fields", pp. 47-62 in "Designs, Codes and Cryptography", Kluwer Academic Publishers, 1991.
[9] La Macchia、B.A。、およびOdlyzko、A.M。、「プライムフィールドにおける離散対数の計算」、「デザイン、コード、暗号化」の47-62ページ、Kluwer Academic Publishers、1991。
[10] Cheswick, W.R., and Bellovin, S.M., "Firewalls and Internet Security," Addison-Wesley, 1995.
[10] Cheswick、W.R。、およびBellovin、S.M。、「ファイアウォールとインターネットセキュリティ」、Addison-Wesley、1995。
[11] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[11] Linn、J。、「Kerberosバージョン5 GSS-APIメカニズム」、RFC 1964、1996年6月。
[12] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[12] Linn、J。、「ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス、バージョン2」、RFC 2078、1997年1月。
[13] Eisler, M., Chiu, A., and Ling, L., "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[13] Eisler、M.、Chiu、A。、およびLing、L。、「RPCSEC_GSSプロトコル仕様」、RFC 2203、1997年9月。
[14] Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999.
[14] Eisler、M。、「NFSバージョン2およびバージョン3セキュリティの問題とNFSプロトコルのRPCSEC_GSSおよびKerberos V5の使用」、RFC 2623、1999年6月。
Alex Chiu Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
Alex Chiu Sun Microsystems、Inc。901 San Antonio Road Palo Alto、CA 94303
Phone: +1 (650) 786-6465
EMail: alex.chiu@Eng.sun.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。