[要約] RFC 3118は、DHCPメッセージの認証に関する標準仕様であり、メッセージの送信元の正当性を確保するための手法を提供します。このRFCの目的は、DHCPプロトコルのセキュリティを向上させ、不正なメッセージの送信や受信を防止することです。
Network Working Group R. Droms, Editor
Request for Comments: 3118 Cisco Systems
Category: Standards Track W. Arbaugh, Editor
University of Maryland
June 2001
Authentication for DHCP Messages
DHCPメッセージの認証
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 (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This document defines a new Dynamic Host Configuration Protocol (DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. DHCP provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages.
このドキュメントでは、認証チケットを簡単に生成できる新しい動的ホスト構成プロトコル（DHCP）オプションを定義し、適切な承認を備えた新しく添付されたホストを認証されたDHCPサーバーから自動的に構成できます。DHCPは、TCP/IPネットワークでホストに構成情報を渡すためのフレームワークを提供します。状況によっては、ネットワーク管理者は、住所の割り当てを認定ホストに制約したい場合があります。さらに、一部のネットワーク管理者は、DHCPメッセージのソースと内容の認証を提供したい場合があります。
DHCP [1] transports protocol stack configuration parameters from centrally administered servers to TCP/IP hosts. Among those parameters are an IP address. DHCP servers can be configured to dynamically allocate addresses from a pool of addresses, eliminating a manual step in configuration of TCP/IP hosts.
DHCP [1]は、中央に管理されたサーバーからTCP/IPホストにプロトコルスタック構成パラメーターを輸送します。これらのパラメーターの中には、IPアドレスがあります。DHCPサーバーは、アドレスプールからアドレスを動的に割り当てるように構成でき、TCP/IPホストの構成の手動ステップを排除できます。
Some network administrators may wish to provide authentication of the source and contents of DHCP messages. For example, clients may be subject to denial of service attacks through the use of bogus DHCP servers, or may simply be misconfigured due to unintentionally instantiated DHCP servers. Network administrators may wish to constrain the allocation of addresses to authorized hosts to avoid denial of service attacks in "hostile" environments where the network medium is not physically secured, such as wireless networks or college residence halls.
一部のネットワーク管理者は、DHCPメッセージのソースと内容の認証を提供する場合があります。たとえば、クライアントは、偽のDHCPサーバーを使用してサービス攻撃を拒否される場合や、意図しないインスタンス化されたDHCPサーバーのために単に誤解される場合があります。ネットワーク管理者は、ワイヤレスネットワークやカレッジレジデンスホールなど、ネットワーク媒体が物理的に保護されていない「敵対的」環境でのサービス拒否攻撃を回避するために、認定ホストに住所の割り当てを制約したい場合があります。
This document defines a technique that can provide both entity authentication and message authentication. The current protocol combines the original Schiller-Huitema-Droms authentication mechanism defined in a previous work in progress with the "delayed authentication" proposal developed by Bill Arbaugh.
このドキュメントは、エンティティ認証とメッセージ認証の両方を提供できる手法を定義します。現在のプロトコルは、進行中の以前の作業で定義された元のSchiller-Huitema-Droms認証メカニズムと、Bill Arbaughによって開発された「遅延認証」提案を組み合わせています。
The threat to DHCP is inherently an insider threat (assuming a properly configured network where BOOTP ports are blocked on the enterprise's perimeter gateways.) Regardless of the gateway configuration, however, the potential attacks by insiders and outsiders are the same.
DHCPに対する脅威は、本質的にインサイダーの脅威です（BOOTPポートがエンタープライズの境界ゲートウェイでブロックされる適切に構成されたネットワークを想定しています。）ただし、ゲートウェイ構成に関係なく、インサイダーと部外者による潜在的な攻撃は同じです。
The attack specific to a DHCP client is the possibility of the establishment of a "rogue" server with the intent of providing incorrect configuration information to the client. The motivation for doing so may be to establish a "man in the middle" attack or it may be for a "denial of service" attack.
DHCPクライアントに固有の攻撃は、クライアントに誤った構成情報を提供する意図を持つ「不正な」サーバーを確立する可能性です。そうするための動機は、「中間の男」攻撃を確立することであるか、「サービスの拒否」攻撃のためのものかもしれません。
There is another threat to DHCP clients from mistakenly or accidentally configured DHCP servers that answer DHCP client requests with unintentionally incorrect configuration parameters.
意図しない誤った構成パラメーターでDHCPクライアント要求に応答する誤ってまたは誤って構成されたDHCPサーバーからDHCPクライアントに別の脅威があります。
The threat specific to a DHCP server is an invalid client masquerading as a valid client. The motivation for this may be for "theft of service", or to circumvent auditing for any number of nefarious purposes.
DHCPサーバーに固有の脅威は、有効なクライアントを装った無効なクライアントです。これの動機は、「奉仕の盗難」、または任意の多くの邪悪な目的で監査を回避することです。
The threat common to both the client and the server is the resource "denial of service" (DoS) attack. These attacks typically involve the exhaustion of valid addresses, or the exhaustion of CPU or network bandwidth, and are present anytime there is a shared resource. In current practice, redundancy mitigates DoS attacks the best.
クライアントとサーバーの両方に共通する脅威は、リソース「サービス拒否」（DOS）攻撃です。これらの攻撃には通常、有効なアドレスの疲労、またはCPUまたはネットワーク帯域幅の消耗が含まれ、共有リソースがあるときはいつでも存在します。現在の実践では、冗長性がDOS攻撃を緩和します。
These are the goals that were used in the development of the authentication protocol, listed in order of importance:
これらは、重要性の順にリストされている認証プロトコルの開発に使用された目標です。
1. Address the threats presented in Section 1.1. 2. Avoid changing the current protocol.
1. セクション1.1に示されている脅威に対処します。2.現在のプロトコルの変更を避けます。
3. Limit state required by the server. 4. Limit complexity (complexity breeds design and implementation errors).
3. サーバーに必要な状態を制限します。4.複雑さを制限します（複雑さは設計と実装エラーを生み出します）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
キーワード「必須」、「そうしない」、「必須」、「必要」、「しなければ」、「そうしない」、「はそうではない」、「そうでない」、「推奨」、「5月」、「オプション」は、RFC 2119 [5]に記載されているように解釈されます。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています。
o "DHCP client"
o 「DHCPクライアント」
A DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address.
DHCPクライアントまたは「クライアント」は、DHCPを使用してネットワークアドレスなどの構成パラメーターを取得するインターネットホストです。
o "DHCP server"
o 「DHCPサーバー」
A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients.
DHCPサーバーまたは「サーバー」は、DHCPクライアントに構成パラメーターを返すインターネットホストです。
The following diagram defines the format of the DHCP authentication option:
次の図は、DHCP認証オプションの形式を定義しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | |
+-+-+-+-+-+-+-+-+ |
| |
| Authentication Information |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for the authentication option is 90, and the length field contains the length of the protocol, RDM, algorithm, Replay Detection fields and authentication information fields in octets.
認証オプションのコードは90で、長さフィールドには、プロトコル、RDM、アルゴリズム、リプレイ検出フィールド、およびオクテットの認証情報フィールドの長さが含まれています。
The protocol field defines the particular technique for authentication used in the option. New protocols are defined as described in Section 6.
プロトコルフィールドは、オプションで使用される認証の特定の手法を定義します。新しいプロトコルは、セクション6で説明されているように定義されています。
The algorithm field defines the specific algorithm within the technique identified by the protocol field.
アルゴリズムフィールドは、プロトコルフィールドによって識別される手法内の特定のアルゴリズムを定義します。
The Replay Detection field is per the RDM, and the authentication information field is per the protocol in use.
リプレイ検出フィールドはRDMごとで、認証情報フィールドは使用中のプロトコルごとにあります。
The Replay Detection Method (RDM) field determines the type of replay detection used in the Replay Detection field.
リプレイ検出方法（RDM）フィールドは、リプレイ検出フィールドで使用されるリプレイ検出のタイプを決定します。
If the RDM field contains 0x00, the replay detection field MUST be set to the value of a monotonically increasing counter. Using a counter value such as the current time of day (e.g., an NTP-format timestamp [4]) can reduce the danger of replay attacks. This method MUST be supported by all protocols.
RDMフィールドに0x00が含まれている場合、リプレイ検出フィールドは、単調に増加するカウンターの値に設定する必要があります。現在の時刻などのカウンター値（たとえば、NTP形式のタイムスタンプ[4]）を使用すると、リプレイ攻撃の危険性が低下する可能性があります。この方法は、すべてのプロトコルでサポートする必要があります。
Because a DHCP relay agent may alter the values of the 'giaddr' and 'hops' fields in the DHCP message, the contents of those two fields MUST be set to zero for the computation of any hash function over the message header. Additionally, a relay agent may append the DHCP relay agent information option 82 [7] as the last option in a message to servers. If a server finds option 82 included in a received message, the server MUST compute any hash function as if the option were NOT included in the message without changing the order of options. Whenever the server sends back option 82 to a relay agent, the server MUST not include the option in the computation of any hash function over the message.
DHCPリレーエージェントは、DHCPメッセージの「GIADDR」および「HOPS」フィールドの値を変更する可能性があるため、これら2つのフィールドの内容は、メッセージヘッダー上のハッシュ関数の計算のためにゼロに設定する必要があります。さらに、リレーエージェントは、サーバーへのメッセージの最後のオプションとして、DHCPリレーエージェント情報オプション82 [7]を追加する場合があります。サーバーが受信したメッセージに含まれているオプション82を見つけた場合、サーバーはオプションの順序を変更せずにオプションがメッセージに含まれていないかのようにハッシュ関数を計算する必要があります。サーバーがオプション82をリレーエージェントに送信するときはいつでも、サーバーはメッセージ上のハッシュ関数の計算にオプションを含めてはなりません。
If the protocol field is 0, the authentication information field
holds a simple configuration token:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | |
|-+-+-+-+-+-+-+-+ |
| |
| Authentication Information |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The configuration token is an opaque, unencoded value known to both the sender and receiver. The sender inserts the configuration token in the DHCP message and the receiver matches the token from the message to the shared token. If the configuration option is present and the token from the message does not match the shared token, the receiver MUST discard the message.
構成トークンは、送信者と受信機の両方に知られている不透明でエンエンコードされていない値です。送信者はDHCPメッセージに構成トークンを挿入し、受信機はメッセージから共有トークンにトークンを一致させます。構成オプションが存在し、メッセージからのトークンが共有トークンと一致しない場合、レシーバーはメッセージを破棄する必要があります。
Configuration token may be used to pass a plain-text configuration token and provides only weak entity authentication and no message authentication. This protocol is only useful for rudimentary protection against inadvertently instantiated DHCP servers.
構成トークンは、プレーンテキスト構成トークンを渡すために使用される場合があり、弱いエンティティ認証とメッセージ認証のみを提供します。このプロトコルは、不注意にインスタンス化されたDHCPサーバーに対する基本的な保護にのみ役立ちます。
DISCUSSION:
議論：
The intent here is to pass a constant, non-computed token such as a plain-text password. Other types of entity authentication using computed tokens such as Kerberos tickets or one-time passwords will be defined as separate protocols.
ここでの意図は、プレーンテキストパスワードなどの一定の非計算トークンを渡すことです。Kerberosチケットや1回限りのパスワードなどの計算されたトークンを使用した他のタイプのエンティティ認証は、個別のプロトコルとして定義されます。
If the protocol field is 1, the message is using the "delayed authentication" mechanism. In delayed authentication, the client requests authentication in its DHCPDISCOVER message and the server replies with a DHCPOFFER message that includes authentication information. This authentication information contains a nonce value generated by the source as a message authentication code (MAC) to provide message authentication and entity authentication.
プロトコルフィールドが1の場合、メッセージは「遅延認証」メカニズムを使用しています。認証の遅延として、クライアントはDHCPDISCOVERメッセージで認証を要求し、サーバーは認証情報を含むDHCPOFFERメッセージで返信します。この認証情報には、メッセージ認証とエンティティ認証を提供するために、メッセージ認証コード（MAC）としてソースによって生成されたNonCE値が含まれています。
This document defines the use of a particular technique based on the HMAC protocol [3] using the MD5 hash [2].
このドキュメントでは、MD5ハッシュ[2]を使用してHMACプロトコル[3]に基づいた特定の手法の使用を定義しています。
The "delayed authentication" protocol does not attempt to address situations where a client may roam from one administrative domain to another, i.e., interdomain roaming. This protocol is focused on solving the intradomain problem where the out-of-band exchange of a shared secret is feasible.
「遅延認証」プロトコルは、クライアントがある管理ドメインから別のドメイン、つまりドメイン間ローミングにローミングできる状況に対処しようとはしません。このプロトコルは、共有された秘密の帯域外交換が実現可能である場合、ドメイン内の問題を解決することに焦点を当てています。
The format of the authentication request in a DHCPDISCOVER or a DHCPINFORM message for delayed authentication is:
dhcpdiscoverまたはdhcpinformメッセージの認証要求の形式は、次のものです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+
The format of the authentication information in a DHCPOFFER, DHCPREQUEST or DHCPACK message for delayed authentication is:
dhcpoffer、dhcprequest、またはdhcpackメッセージの認証情報の形式は、次のものです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | Secret ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| secret id cont| HMAC-MD5 (128 bits) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following definitions will be used in the description of the authentication information for delayed authentication, algorithm 1: Replay Detection - as defined by the RDM field K - a secret value shared between the source and destination of the message; each secret has a unique identifier (secret ID) secret ID - the unique identifier for the secret value used to generate the MAC for this message HMAC-MD5 - the MAC generating function [3, 2].
次の定義は、遅延認証のための認証情報の説明で使用されます。アルゴリズム1：リプレイ検出 - RDMフィールドkで定義されています - メッセージのソースと宛先の間で共有される秘密の値。各秘密には、このメッセージのMACを生成するために使用されるシークレット値の一意の識別子（Secret ID）Secret IDがあります。
The sender computes the MAC using the HMAC generation algorithm [3] and the MD5 hash function [2]. The entire DHCP message (except as noted below), including the DHCP message header and the options field, is used as input to the HMAC-MD5 computation function. The 'secret ID' field MUST be set to the identifier of the secret used to generate the MAC.
送信者は、HMAC生成アルゴリズム[3]とMD5ハッシュ関数[2]を使用してMACを計算します。DHCPメッセージヘッダーとオプションフィールドを含むDHCPメッセージ全体（以下の場合は除く）は、HMAC-MD5計算関数への入力として使用されます。「Secret ID」フィールドは、MACを生成するために使用されるシークレットの識別子に設定する必要があります。
DISCUSSION:
議論：
Algorithm 1 specifies the use of HMAC-MD5. Use of a different technique, such as HMAC-SHA, will be specified as a separate protocol.
アルゴリズム1 HMAC-MD5の使用を指定します。HMAC-SHAなどの異なる手法の使用は、別のプロトコルとして指定されます。
Delayed authentication requires a shared secret key for each client on each DHCP server with which that client may wish to use the DHCP protocol. Each secret key has a unique identifier that can be used by a receiver to determine which secret was used to generate the MAC in the DHCP message. Therefore, delayed authentication may not scale well in an architecture in which a DHCP client connects to multiple administrative domains.
延期された認証には、各DHCPサーバーの各クライアントの共有シークレットキーが必要です。各シークレットキーには、レシーバーが使用してDHCPメッセージでMACを生成するために使用された秘密を決定するために使用できる一意の識別子があります。したがって、遅延認証は、DHCPクライアントが複数の管理ドメインに接続するアーキテクチャでは十分に拡張されない場合があります。
To validate an incoming message, the receiver first checks that the value in the replay detection field is acceptable according to the replay detection method specified by the RDM field. Next, the receiver computes the MAC as described in [3]. The receiver MUST set the 'MAC' field of the authentication option to all 0s for computation of the MAC, and because a DHCP relay agent may alter the values of the 'giaddr' and 'hops' fields in the DHCP message, the contents of those two fields MUST also be set to zero for the computation of the MAC. If the MAC computed by the receiver does not match the MAC contained in the authentication option, the receiver MUST discard the DHCP message.
着信メッセージを検証するために、受信者は最初に、RDMフィールドによって指定されたリプレイ検出方法に従って、リプレイ検出フィールドの値が許容できることを最初に確認します。次に、[3]で説明されているように、受信機はMACを計算します。受信者は、MACの計算のためにすべての0Sに認証オプションの「MAC」フィールドを設定する必要があり、DHCPリレーエージェントがDHCPメッセージの「GIADDR」および「HOPS」フィールドの値を変更する可能性があるためです。これらの2つのフィールドは、Macの計算のためにゼロに設定する必要があります。受信機によって計算されたMACが認証オプションに含まれるMacと一致しない場合、受信機はDHCPメッセージを破棄する必要があります。
Section 3 provides additional information on handling messages that include option 82 (Relay Agents).
セクション3では、オプション82（リレーエージェント）を含むメッセージの処理に関する追加情報を提供します。
Each DHCP client has a key, K. The client uses its key to encode any messages it sends to the server and to authenticate and verify any messages it receives from the server. The client's key SHOULD be initially distributed to the client through some out-of-band mechanism, and SHOULD be stored locally on the client for use in all authenticated DHCP messages. Once the client has been given its key, it SHOULD use that key for all transactions even if the client's configuration changes; e.g., if the client is assigned a new network address.
各DHCPクライアントにはキーがあります。クライアントは、キーを使用して、サーバーに送信するメッセージをエンコードし、サーバーから受信するメッセージを認証および確認します。クライアントのキーは、最初にバンド外のメカニズムを介してクライアントに配布する必要があり、すべての認証されたDHCPメッセージで使用するためにクライアントにローカルに保存する必要があります。クライアントにキーが与えられたら、クライアントの構成が変更された場合でも、すべてのトランザクションにそのキーを使用する必要があります。たとえば、クライアントに新しいネットワークアドレスが割り当てられている場合。
Each DHCP server MUST know, or be able to obtain in a secure manner, the keys for all authorized clients. If all clients use the same key, clients can perform both entity and message authentication for all messages received from servers. However, the sharing of keys is strongly discouraged as it allows for unauthorized clients to masquerade as authorized clients by obtaining a copy of the shared key. To authenticate the identity of individual clients, each client MUST be configured with a unique key. Appendix A describes a technique for key management.
各DHCPサーバーは、すべての許可されたクライアントのキーを、安全な方法で知るか、取得できる必要があります。すべてのクライアントが同じキーを使用する場合、クライアントはサーバーから受信したすべてのメッセージに対してエンティティとメッセージ認証の両方を実行できます。ただし、キーの共有は、共有キーのコピーを取得することにより、許可されていないクライアントが認定クライアントを装備できるようにするため、強く落胆しています。個々のクライアントのIDを認証するには、各クライアントを一意のキーで構成する必要があります。付録Aでは、主要な管理の手法について説明しています。
This section describes the behavior of a DHCP client using delayed authentication.
このセクションでは、遅延認証を使用したDHCPクライアントの動作について説明します。
When in INIT state, the client uses delayed authentication as follows:
INIT状態では、クライアントは次のように遅延認証を使用します。
1. The client MUST include the authentication request option in its DHCPDISCOVER message along with a client identifier option [6] to identify itself uniquely to the server.
1. クライアントは、サーバーに一意に識別するために、クライアント識別子オプション[6]とともに、DHCPDISCOVERメッセージに認証要求オプションをDHCPDISCOVERメッセージに含める必要があります。
2. The client MUST perform the validation test described in section 5.3 on any DHCPOFFER messages that include authentication information. If one or more DHCPOFFER messages pass the validation test, the client chooses one of the offered configurations.
2. クライアントは、認証情報を含むDHCPOFFERメッセージのセクション5.3で説明されている検証テストを実行する必要があります。1つ以上のDHCPOFFERメッセージが検証テストに合格した場合、クライアントは提供される構成の1つを選択します。
Client behavior if no DHCPOFFER messages include authentication information or pass the validation test is controlled by local policy in the client. According to client policy, the client MAY choose to respond to a DHCPOFFER message that has not been authenticated.
クライアントの動作DHCPOFFERメッセージが含まれていない場合、認証情報が含まれているか、検証テストがクライアントのローカルポリシーによって制御されます。クライアントポリシーによると、クライアントは認証されていないDHCPOFFERメッセージに応答することを選択できます。
The decision to set local policy to accept unauthenticated messages should be made with care. Accepting an unauthenticated DHCPOFFER message can make the client vulnerable to spoofing and other attacks. If local users are not explicitly informed that the client has accepted an unauthenticated DHCPOFFER message, the users may incorrectly assume that the client has received an authenticated address and is not subject to DHCP attacks through unauthenticated messages.
認識されていないメッセージを受け入れるようにローカルポリシーを設定する決定は、注意して行う必要があります。認識されていないDHCPOFFERメッセージを受け入れると、クライアントがスプーフィングやその他の攻撃に対して脆弱になります。ローカルユーザーが、クライアントが認証されていないDHCPOFFERメッセージを受け入れたことを明示的に通知されない場合、ユーザーはクライアントが認証されたアドレスを受け取っており、認証されていないメッセージを介してDHCP攻撃の対象ではないと誤って想定する場合があります。
A client MUST be configurable to decline unauthenticated messages, and SHOULD be configured by default to decline unauthenticated messages. A client MAY choose to differentiate between DHCPOFFER messages with no authentication information and DHCPOFFER messages that do not pass the validation test; for example, a client might accept the former and discard the latter. If a client does accept an unauthenticated message, the client SHOULD inform any local users and SHOULD log the event.
クライアントは、認識されていないメッセージを拒否するように設定可能である必要があり、デフォルトでは認証されていないメッセージを拒否するように設定する必要があります。クライアントは、認証情報なしでDHCPOFFERメッセージと、検証テストに合格しないDHCPOFFERメッセージを区別することを選択できます。たとえば、クライアントは前者を受け入れ、後者を廃棄する場合があります。クライアントが認可されていないメッセージを受け入れる場合、クライアントはローカルユーザーに通知し、イベントをログインする必要があります。
3. The client replies with a DHCPREQUEST message that MUST include authentication information encoded with the same secret used by the server in the selected DHCPOFFER message.
3. クライアントは、選択したDHCPOFFERメッセージでサーバーが使用する同じ秘密でエンコードされた認証情報を含める必要があるDHCPRequestメッセージで返信します。
4. If the client authenticated the DHCPOFFER it accepted, the client MUST validate the DHCPACK message from the server. The client MUST discard the DHCPACK if the message fails to pass validation and MAY log the validation failure. If the DHCPACK fails to pass validation, the client MUST revert to INIT state and returns to step 1. The client MAY choose to remember which server replied with a DHCPACK message that failed to pass validation and discard subsequent messages from that server.
4. クライアントが受け入れたDHCPOFFERを認証した場合、クライアントはサーバーからのDHCPackメッセージを検証する必要があります。メッセージが検証に合格できず、検証障害を記録する場合がある場合、クライアントはDHCPACKを破棄する必要があります。DHCPACKが検証に合格できない場合、クライアントはinit状態に戻り、ステップ1に戻る必要があります。クライアントは、検証に合格しなかったDHCPACKメッセージでどのサーバーが返信し、そのサーバーからの後続のメッセージを破棄したかを覚えておくことができます。
If the client accepted a DHCPOFFER message that did not include authentication information or did not pass the validation test, the client MAY accept an unauthenticated DHCPACK message from the server.
クライアントが認証情報を含めていないDHCPOFFERメッセージを受け入れた場合、または検証テストに合格しなかった場合、クライアントはサーバーからの認証されていないDHCPACKメッセージを受け入れる場合があります。
When in INIT-REBOOT state, the client MUST use the secret it used in its DHCPREQUEST message to obtain its current configuration to generate authentication information for the DHCPREQUEST message. The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages if no authenticated messages were received. The client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK messages as specified in section 3.2 of [1].
Init-Reboot状態では、クライアントはDHCPRequestメッセージで使用した秘密を使用して現在の構成を取得して、DHCPRequestメッセージの認証情報を生成する必要があります。クライアントは、認証されたメッセージが受信されなかった場合、認証されていないDHCPACK/DHCPNAKメッセージを受け入れることを選択できます。クライアントは、[1]のセクション3.2で指定されているように、dhcpack/dhcpnakメッセージの領収書（またはその欠如）を扱う必要があります。
When in RENEWING state, the client uses the secret it used in its initial DHCPREQUEST message to obtain its current configuration to generate authentication information for the DHCPREQUEST message. If client receives no DHCPACK messages or none of the DHCPACK messages pass validation, the client behaves as if it had not received a DHCPACK message in section 4.4.5 of the DHCP specification [1].
状態を更新すると、クライアントは最初のDHCPRequestメッセージで使用した秘密を使用して現在の構成を取得して、DHCPRequestメッセージの認証情報を生成します。クライアントがDHCPACKメッセージを受信しないか、DHCPACKメッセージが検証に合格しない場合、クライアントはDHCP仕様のセクション4.4.5でDHCPackメッセージを受信していないかのように動作します[1]。
When in REBINDING state, the client uses the secret it used in its initial DHCPREQUEST message to obtain its current configuration to generate authentication information for the DHCPREQUEST message. If client receives no DHCPACK messages or none of the DHCPACK messages pass validation, the client behaves as if it had not received a DHCPACK message in section 4.4.5 of the DHCP specification [1].
状態を再調整すると、クライアントは最初のDHCPRequestメッセージで使用した秘密を使用して現在の構成を取得して、DHCPRequestメッセージの認証情報を生成します。クライアントがDHCPACKメッセージを受信しないか、DHCPACKメッセージが検証に合格しない場合、クライアントはDHCP仕様のセクション4.4.5でDHCPackメッセージを受信していないかのように動作します[1]。
Since the client already has some configuration information, the client may also have established a shared secret value, K, with a server. Therefore, the client SHOULD use the authentication request as in a DHCPDISCOVER message when a shared secret value exists. The client MUST treat any received DHCPACK messages as it does DHCPOFFER messages, see section 5.5.1.
クライアントはすでに構成情報を持っているため、クライアントはサーバーを使用して共有秘密の値kを確立している可能性もあります。したがって、共有された秘密値が存在する場合、クライアントはdhcpdiscoverメッセージのように認証要求を使用する必要があります。クライアントは、DHCPOFFERメッセージを実行するように、受信したDHCPACKメッセージを扱う必要があります。セクション5.5.1を参照してください。
Since the client is already in the BOUND state, the client will have a security association already established with the server. Therefore, the client MUST include authentication information with the DHCPRELEASE message.
クライアントはすでにバインドされた状態にあるため、クライアントはサーバーとのセキュリティ協会がすでに確立されています。したがって、クライアントはDHCPreleaseメッセージに認証情報を含める必要があります。
This section describes the behavior of a server in response to client messages using delayed authentication.
このセクションでは、遅延認証を使用したクライアントメッセージに応答したサーバーの動作について説明します。
Each server maintains a list of secrets and identifiers for those secrets that it shares with clients and potential clients. This information must be maintained in such a way that the server can:
各サーバーは、クライアントや潜在的なクライアントと共有する秘密の秘密と識別子のリストを維持しています。この情報は、サーバーが次の方法で維持する必要があります。
* Identify an appropriate secret and the identifier for that secret for use with a client that the server may not have previously communicated with
* サーバーが以前に通信していなかったクライアントで使用するためのその秘密の適切な秘密と識別子を特定します
* Retrieve the secret and identifier used by a client to which the server has provided previous configuration information
* サーバーが以前の構成情報を提供したクライアントが使用する秘密と識別子を取得する
Each server MUST save the counter from the previous authenticated message. A server MUST discard any incoming message which fails the replay detection check as defined by the RDM avoid replay attacks.
各サーバーは、以前の認証されたメッセージからカウンターを保存する必要があります。サーバーは、RDMのリプレイ攻撃を避けることで定義されているように、リプレイ検出チェックに失敗する着信メッセージを破棄する必要があります。
DISCUSSION:
議論：
The authenticated DHCPREQUEST message from a client in INIT-REBOOT state can only be validated by servers that used the same secret in their DHCPOFFER messages. Other servers will discard the DHCPREQUEST messages. Thus, only servers that used the secret selected by the client will be able to determine that their offered configuration information was not selected and the offered network address can be returned to the server's pool of available addresses. The servers that cannot validate the DHCPREQUEST message will eventually return their offered network addresses to their pool of available addresses as described in section 3.1 of the DHCP specification [1].
Init-Reboot状態のクライアントからの認証されたDHCPRequestメッセージは、DHCPofferメッセージで同じ秘密を使用したサーバーによってのみ検証できます。他のサーバーは、DHCPRequestメッセージを破棄します。したがって、クライアントが選択したシークレットを使用したサーバーのみが、提供された構成情報が選択されておらず、提供されたネットワークアドレスを使用可能なアドレスのサーバーのプールに返すことができると判断できます。DHCPRequestメッセージを検証できないサーバーは、DHCP仕様[1]のセクション3.1で説明されているように、提供されたネットワークアドレスを利用可能なアドレスのプールに最終的に返します。
The server selects a secret for the client and includes authentication information in the DHCPOFFER message as specified in section 5, above. The server MUST record the identifier of the secret selected for the client and use that same secret for validating subsequent messages with the client.
サーバーは、クライアントの秘密を選択し、上記のセクション5で指定されているDHCPOFFERメッセージに認証情報を含めます。サーバーは、クライアントに選択された秘密の識別子を記録し、クライアントとの後続のメッセージを検証するために同じ秘密を使用する必要があります。
The server uses the secret identified in the message and validates the message as specified in section 5.3. If the message fails to pass validation or the server does not know the secret identified by the 'secret ID' field, the server MUST discard the message and MAY choose to log the validation failure.
サーバーは、メッセージで識別された秘密を使用し、セクション5.3で指定されているメッセージを検証します。メッセージが検証に合格できない場合、またはサーバーが「シークレットID」フィールドによって識別されたシークレットがわからない場合、サーバーはメッセージを破棄し、検証障害をログインすることを選択する必要があります。
If the message passes the validation procedure, the server responds as described in the DHCP specification. The server MUST include authentication information generated as specified in section 5.2.
メッセージが検証手順に渡すと、DHCP仕様で説明されているようにサーバーが応答します。サーバーには、セクション5.2で指定されているように生成された認証情報を含める必要があります。
The server MAY choose to accept unauthenticated DHCPINFORM messages, or only accept authenticated DHCPINFORM messages based on a site policy.
サーバーは、認証されていないDHCPINFORMメッセージを受け入れるか、サイトポリシーに基づいて認証されたDHCPINFORMメッセージのみを受け入れることを選択できます。
When a client includes the authentication request in a DHCPINFORM message, the server MUST respond with an authenticated DHCPACK message. If the server does not have a shared secret value established with the sender of the DHCPINFORM message, then the server MAY respond with an unauthenticated DHCPACK message, or a DHCPNAK if the server does not accept unauthenticated clients based on the site policy, or the server MAY choose not to respond to the DHCPINFORM message.
クライアントがDHCPINFORMメッセージに認証要求を含める場合、サーバーは認証されたDHCPACKメッセージで応答する必要があります。サーバーがDHCPINFORMメッセージの送信者で共有秘密の値を確立していない場合、サーバーは、未認定のDHCPACKメッセージ、またはサーバーがサイトポリシーに基づいて認可されていないクライアントを受け入れない場合、またはサーバーに基づいてDHCPNAKで応答する場合があります。DHCPINFORMメッセージに応答しないことを選択できます。
Section 2 defines a new DHCP option called the Authentication Option, whose option code is 90.
セクション2では、オプションコードが90である認証オプションと呼ばれる新しいDHCPオプションを定義しています。
This document specifies three new name spaces associated with the Authentication Option, which are to be created and maintained by IANA: Protocol, Algorithm and RDM.
このドキュメントは、認証オプションに関連付けられた3つの新しい名前スペースを指定します。これは、IANA、プロトコル、アルゴリズム、RDMによって作成および維持されます。
Initial values assigned from the Protocol name space are 0 (for the configuration token Protocol in section 4) and 1 (for the delayed authentication Protocol in section 5). Additional values from the Protocol name space will be assigned through IETF Consensus, as defined in RFC 2434 [8].
プロトコル名スペースから割り当てられた初期値は、0（セクション4の構成トークンプロトコルの場合）および1（セクション5の遅延認証プロトコルの場合）です。RFC 2434 [8]で定義されているように、プロトコル名スペースからの追加値は、IETFコンセンサスによって割り当てられます。
The Algorithm name space is specific to individual Protocols. That is, each Protocol has its own Algorithm name space. The guidelines for assigning Algorithm name space values for a particular protocol should be specified along with the definition of a new Protocol.
アルゴリズム名スペースは、個々のプロトコルに固有です。つまり、各プロトコルには独自のアルゴリズム名スペースがあります。特定のプロトコルのアルゴリズム名スペース値を割り当てるためのガイドラインは、新しいプロトコルの定義とともに指定する必要があります。
For the configuration token Protocol, the Algorithm field MUST be 0. For the delayed authentication Protocol, the Algorithm value 1 is assigned to the HMAC-MD5 generating function as defined in section 5. Additional values from the Algorithm name space for Algorithm 1 will be assigned through IETF Consensus, as defined in RFC 2434.
構成トークンプロトコルの場合、アルゴリズムフィールドは0でなければなりません。遅延認証プロトコルの場合、アルゴリズム値1はセクション5で定義されているHMAC-MD5生成関数に割り当てられます。RFC 2434で定義されているように、IETFコンセンサスを通じて割り当てられます。
The initial value of 0 from the RDM name space is assigned to the use of a monotonically increasing value as defined in section 2. Additional values from the RDM name space will be assigned through IETF Consensus, as defined in RFC 2434.
RDM名スペースからの0の初期値は、セクション2で定義されているように単調に増加する値を使用するように割り当てられます。RDM名スペースからの追加値は、RFC 2434で定義されているIETFコンセンサスによって割り当てられます。
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[1] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[2] Rivest、R。、「The Md5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[3] Krawczyk H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[3] Krawczyk H.、Bellare、M。およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1997年2月。
[4] Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March 1992.
[4] Mills、D。、「ネットワークタイムプロトコル（バージョン3）」、RFC 1305、1992年3月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2219, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2219、1997年3月。
[6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[6] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張機能」、RFC 2132、1997年3月。
[7] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[7] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing and IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8] Narten、T。およびH. Alvestrand、「RFCSの執筆およびIANAの考慮事項セクションのガイドライン」、BCP 26、RFC 2434、1998年10月。
Jeff Schiller and Christian Huitema developed the original version of this authentication protocol in a terminal room BOF at the Dallas IETF meeting, December 1995. One of the editors (Droms) transcribed the notes from that discussion, which form the basis for this document. The editors appreciate Jeff's and Christian's patience in reviewing this document and its earlier drafts.
Jeff SchillerとChristian Huitemaは、1995年12月のダラスIETF会議のターミナルルームBOFでこの認証プロトコルのオリジナルバージョンを開発しました。編集者の1人（DROM）は、この文書の基礎を形成する議論からメモを転写しました。編集者は、この文書とその以前のドラフトをレビューする際のジェフとクリスチャンの忍耐を高く評価しています。
The "delayed authentication" mechanism used in section 5 is due to Bill Arbaugh. The threat model and requirements in sections 1.1 and 1.2 come from Bill's negotiation protocol proposal. The attendees of an interim meeting of the DHC WG held in June, 1998, including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike Dooley, Greg Rabil and Arun Kapur, developed the threat model and reviewed several alternative proposals.
セクション5で使用されている「認証の遅延」メカニズムは、Bill Arbaughによるものです。セクション1.1および1.2の脅威モデルと要件は、ビルの交渉プロトコル提案からのものです。1998年6月に開催されたDHC WGの暫定会議の出席者は、ピーターフォード、キムキニア、グレンウォーターズ、ロブスティーブンス、ビルアルボー、バイジュパテル、カールスミス、トーマスナルテン、スチュワートクワン、ミュンミーシャー、オラファーグドマンドソンなどロバート・ワトソン、ラルフ・ドロムズ、マイク・ドゥーリー、グレッグ・ラビル、アルン・カプールは、脅威モデルを開発し、いくつかの代替提案をレビューしました。
The replay detection method field is due to Vipul Gupta.
リプレイ検出方法フィールドは、Vipul Guptaによるものです。
Other input from Bill Sommerfield is gratefully acknowledged.
ビル・ソマーフィールドからのその他の入力は感謝されています。
Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas Narten for reviewing earlier drafts of this document.
この文書の以前のドラフトをレビューしてくれたジョン・ウィルキンス、ラン・アトキンソン、ショーン・マムロス、トーマス・ナルテンにも感謝します。
This document describes authentication and verification mechanisms for DHCP.
このドキュメントでは、DHCPの認証と検証メカニズムについて説明しています。
The configuration token authentication mechanism is vulnerable to interception and provides only the most rudimentary protection against inadvertently instantiated DHCP servers.
構成トークン認証メカニズムは傍受に対して脆弱であり、不注意にインスタンス化されたDHCPサーバーに対する最も基本的な保護のみを提供します。
The delayed authentication mechanism described in this document is vulnerable to a denial of service attack through flooding with DHCPDISCOVER messages, which are not authenticated by this protocol. Such an attack may overwhelm the computer on which the DHCP server is running and may exhaust the addresses available for assignment by the DHCP server.
このドキュメントで説明されている遅延認証メカニズムは、DHCPDISCOVERメッセージによる洪水によるサービス拒否攻撃に対して脆弱であり、このプロトコルでは認証されていません。このような攻撃は、DHCPサーバーが実行されているコンピューターを圧倒する可能性があり、DHCPサーバーが割り当て可能なアドレスを排出する場合があります。
Delayed authentication may also be vulnerable to a denial of service attack through flooding with authenticated messages, which may overwhelm the computer on which the DHCP server is running as the authentication keys for the incoming messages are computed.
遅延認証は、認証されたメッセージでフラッディングすることにより、サービスの拒否攻撃に対して脆弱である可能性があります。これは、着信メッセージの認証キーが計算されるとDHCPサーバーが実行されているコンピューターを圧倒する可能性があります。
Delayed authentication does not support interdomain authentication.
遅延認証は、ドメイン間認証をサポートしません。
A real digital signature mechanism such as RSA, while currently computationally infeasible, would provide better security.
RSAなどの実際のデジタル署名メカニズムは、現在計算上は実行不可能ですが、より良いセキュリティを提供します。
Ralph Droms Cisco Systems 300 Apollo Drive Chelmsford, MA 01824
Ralph Droms Cisco Systems 300 Apollo Drive Chelmsford、MA 01824
Phone: (978) 244-4733 EMail: rdroms@cisco.com
電話：（978）244-4733メール：rdroms@cisco.com
Bill Arbaugh Department of Computer Science University of Maryland A.V. Williams Building College Park, MD 20742
メリーランド州コンピュータサイエンス大学のビル・アーボー局A.V.ウィリアムズビルディングカレッジパーク、メリーランド20742
Phone: (301) 405-2774 EMail: waa@cs.umd.edu
電話：（301）405-2774メール：waa@cs.umd.edu
Appendix A - Key Management Technique
付録A-主要な管理手法
To avoid centralized management of a list of random keys, suppose K for each client is generated from the pair (client identifier [6], subnet address, e.g., 192.168.1.0), which must be unique to that client. That is, K = MAC(MK, unique-id), where MK is a secret master key and MAC is a keyed one-way function such as HMAC-MD5.
ランダムキーのリストの集中管理を回避するために、各クライアントのkがペアから生成されると仮定します（クライアント識別子[6]、サブネットアドレス、192.168.1.0など）。つまり、k = mac（mk、unique-id）で、MKはシークレットマスターキーであり、MacはHMAC-MD5などのキー付き一方向関数です。
Without knowledge of the master key MK, an unauthorized client cannot generate its own key K. The server can quickly validate an incoming message from a new client by regenerating K from the client-id. For known clients, the server can choose to recover the client's K dynamically from the client-id in the DHCP message, or can choose to precompute and cache all of the Ks a priori.
マスターキーMKの知識がなければ、不正なクライアントは独自のキーKを生成することはできません。サーバーは、クライアントIDからKを再生することにより、新しいクライアントからの受信メッセージを迅速に検証できます。既知のクライアントの場合、サーバーは、DHCPメッセージのクライアント-IDからクライアントのKを動的に回復することを選択したり、すべてのKS Aアプリオリをプリピュートしてキャッシュすることを選択できます。
By deriving all keys from a single master key, the DHCP server does not need access to clear text passwords, and can compute and verify the keyed MACs without requiring help from a centralized authentication server.
単一のマスターキーからすべてのキーを導出することにより、DHCPサーバーはテキストパスワードをクリアするためのアクセスを必要とせず、集中認証サーバーのヘルプを必要とせずにキー付きMacを計算および検証できます。
To avoid compromise of this key management system, the master key, MK, MUST NOT be stored by any clients. The client SHOULD only be given its key, K. If MK is compromised, a new MK SHOULD be chosen and all clients given new individual keys.
このキー管理システムの妥協を避けるために、マスターキーであるMKは、クライアントによって保存されてはなりません。クライアントにはキーKを指定する必要があります。MKが侵害された場合、新しいMKを選択し、すべてのクライアントが新しい個別のキーを与えます。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。