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
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.
著作権（C）インターネット協会（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サーバに誤って構成することができます。ネットワーク管理者は、このような無線ネットワークや大学の寮などのネットワークメディアが物理的に確保されていない「敵対的」環境でサービス拒否（DoS）攻撃を避けるために許可ホストにアドレスの割り当てを制限することを望むかもしれません。
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.
この文書は、エンティティ認証とメッセージ認証の両方を提供することができる技術を定義しています。現在のプロトコルは、ビルArbaughによって開発された「遅延認証」の提案と進行中の以前の研究で定義されたオリジナルのシラー-のHuitema - Droms認証メカニズムを兼ね備えています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHOULD"、 "べきではない" "ないもの" "ものとし"、 "推奨"、 "MAY" と "省略可能" にしています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リレーエージェントは、「のgiaddr」とDHCPメッセージの「ホップ」フィールドの値を変更することができるので、これらの二つのフィールドの内容がメッセージ・ヘッダ上の任意のハッシュ関数の計算のためにゼロに設定しなければなりません。また、リレーエージェントは、サーバーへのメッセージの最後のオプションとして、[7] DHCPリレーエージェント情報オプション82を追加することがあります。サーバーは、受信したメッセージに含まれるオプション82を検出した場合オプションはオプションの順序を変更することなく、メッセージに含まれていなかったかのように、サーバーは、任意のハッシュ関数を計算しなければなりません。サーバがリレーエージェントにオプション82を返信するたびに、サーバーはメッセージを超える任意のハッシュ関数の計算にオプションを含めることはできません。
If the protocol field is 0, the authentication information field holds a simple configuration token:
プロトコルフィールドが0の場合、認証情報フィールドには、簡単な構成トークンを保持しています：
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チケットまたはワンタイムパスワードとして計算トークンを使用して、エンティティ認証の他のタイプは、別個のプロトコルと定義します。
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）としてソースによって生成されたノンス値を含みます。
This document defines the use of a particular technique based on the HMAC protocol [3] using the MD5 hash [2].
この文書では、HMACプロトコルに基づいて、特定の技術の使用を定義する[3] MD5ハッシュを使用して、[2]。
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:
以下の定義は、アルゴリズム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].
リプレイ検出 - RDMフィールドKによって定義されるよう - メッセージの送信元と宛先の間で共有される秘密値。このメッセージにHMAC-MD5のためのMACを生成するために使用される秘密の値の一意の識別子 - - MAC生成関数[3,2]各秘密は、一意の識別子（秘密ID）秘密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生成アルゴリズムを使用してMACを計算し[3]、MD5ハッシュ関数[2]。全体のDHCPメッセージは、DHCPメッセージヘッダとオプションフィールドを含む、（以下に記載される場合を除き）、HMAC-MD5計算関数への入力として使用されます。 「秘密の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サーバ上の各クライアントの共有秘密鍵が必要です。各秘密鍵は、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の計算のためにすべて0に認証オプションの「MAC」フィールドを設定しなければならず、DHCPリレーエージェントは、「のgiaddr」との値を変更することができるので、DHCPメッセージの「ホップ」フィールドの内容これらの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クライアントは鍵を持っている、K.クライアントは、サーバーに送信するすべてのメッセージをエンコードするために、それは、サーバから受信したメッセージを認証し、確認するために、そのキーを使用しています。クライアントの鍵は、最初はいくつかのアウトオブバンドメカニズムを介してクライアントに配布されるべきであり、すべての認証された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サーバーが知っている、または許可されたすべてのクライアントのために、安全な方法で鍵を得ることができなければなりません。すべてのクライアントが同じキーを使用する場合、クライアントはサーバから受信したすべてのメッセージの両方のエンティティとメッセージ認証を行うことができます。不正なクライアントが共有鍵のコピーを取得することによって認証されたクライアントを偽装することができますしかし、鍵の共有が強くお勧めします。個々のクライアントの身元を認証するために、各クライアントは、一意のキーを設定する必要があります。付録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メッセージ内の認証要求オプションを含まなければなりません。
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に記載の検証テストを実行しなければなりません。一つ以上のDHCPOFFERメッセージは、検証テストに合格した場合、クライアントが提供された構成のいずれかを選択します。
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.
クライアントはDHCPOFFERを認証された場合4.それは、クライアントがサーバからのDHCPACKメッセージを検証しなければならない、受け入れました。クライアントは、メッセージが検証に合格するために失敗した場合にDHCPACKを捨てなければなりませんし、検証の失敗を記録することがあります。 DHCPACKが検証に合格しなかった場合、クライアントはINIT状態に戻すと1クライアントの処理に戻るMUST検証に合格し、そのサーバーからのその後のメッセージを破棄することができなかった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仕様[1]のセクション4.4.5にDHCPACKメッセージを受信しなかったかのように、クライアントが動作します。
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].
REBINDING状態で、クライアントはDHCPREQUESTメッセージのための認証情報を生成するために、現在の設定を取得するために、その最初のDHCPREQUESTメッセージで使用される秘密情報を使用する場合。クライアントが何DHCPACKメッセージを受信しないか、DHCPACKメッセージのいずれもが検証に合格しない場合は、DHCP仕様[1]のセクション4.4.5にDHCPACKメッセージを受信しなかったかのように、クライアントが動作します。
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メッセージと同様に、クライアントは、セクション5.5.1を参照して、任意の受信DHCPACKメッセージを扱わなければなりません。
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.
クライアントはBOUND状態に既にあるので、クライアントが既にサーバーに確立されたセキュリティ関連を持つことになります。そのため、クライアントは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メッセージを破棄します。このように、クライアントによって選択された秘密を使用する唯一のサーバーは、その提示された設定情報が選択されていなかったし、提供されたネットワークアドレスが使用可能なアドレスのサーバーのプールに戻すことができることを決定することができるであろう。 DHCP仕様[1]のセクション3.1で説明したようにDHCPREQUESTメッセージを検証することはできませんサーバーは、最終的に利用可能なアドレスの彼らのプールに彼らの提供するネットワークアドレスを返します。
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.
プロトコル、アルゴリズムとRDM：この文書は、IANAによって作成され、維持される認証オプションに関連する3つの新しい名前空間を指定します。
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と1（セクション4で構成トークンプロトコルのための）（セクション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.追加の値があろうセクションで定義されるように、アルゴリズム値1は、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の初期値は、RFC 2434で定義されるようにRDMの名前空間から2.追加の値は、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]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、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.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[4] Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March 1992.
[4]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）"、RFC 1305、1992年3月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2219, March 1997.
[5]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2219、1997年3月を。
[6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[6]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[7] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[7]パトリック、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.
ジェフ・シラーとクリスチャンのHuitemaは、1995年12月編集者の一人（Droms）、ダラスIETF会議の端末室BOFにこの認証プロトコルのオリジナルバージョンを開発し、この文書の基礎を形成し、その議論からノートを、転写しました。編集者は、この文書とその以前のドラフトの見直しでジェフのとキリスト教の忍耐に感謝します。
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で使用される「遅れた認証」メカニズムはビルArbaughによるものです。セクション1.1と1.2での脅威モデルと要件は、ビルの交渉プロトコルの提案から来ます。ピーター・フォード、キム・キニア、グレン・ウォーターズ、ロブ・スティーブンス、ビルArbaugh、Baijuパテル、カール・スミス、トーマスNarten氏、スチュワート・クワン、Munilシャー、オラフルグドムンソンを含む6月、1998年に開催されたDHC WGの中間会合の参加者、ロバート・ワトソン、ラルフDroms、マイク・ドゥーリー、グレッグRabilとアルンカプールは、脅威モデルを開発し、いくつかの代替案を検討しました。
The replay detection method field is due to Vipul Gupta.
リプレイ検出方法フィールドはビパル・グプタによるものです。
Other input from Bill Sommerfield is gratefully acknowledged.
ビルSommerfieldから他方の入力は深く感謝しています。
Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas Narten for reviewing earlier drafts of this document.
また、ジョン・ウィルキンスのおかげで、この文書の以前のドラフトをレビューするためアトキンソン、ショーンMamrosとトーマスNarten氏蘭。
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
ラルフDromsシスコシステムズ300アポロドライブチェルムズフォード、MA 01824
Phone: (978) 244-4733 EMail: rdroms@cisco.com
電話：（978）244-4733 Eメール：rdroms@cisco.com
Bill Arbaugh Department of Computer Science University of Maryland A.V. Williams Building College Park, MD 20742
メリーランド州のコンピュータサイエンス大学のビル・Arbaugh部門A.V.ウィリアムズビルカレッジパーク、MD 20742
Phone: (301) 405-2774 EMail: waa@cs.umd.edu
電話：（301）405-2774 Eメール：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.
各クライアントは、ペア（クライアント識別子[6]、サブネットアドレス、例えばは、192.168.1.0）、そのクライアントに一意でなければならないから生成されるため、ランダムなキーのリストの集中管理を回避するために、Kを考えます。すなわち、MKは、秘密マスタ鍵であり、MACは、HMAC-MD5のようなキー付き一方向関数であるK = MAC（MK、一意のID）です。
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のアプリオリのすべてをキャッシュするように選択することができます。
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は、任意のクライアントによって保存されてはなりません。 MKが侵害された場合、クライアントは唯一のキー、Kを与えられるべきで、新しいMKを選択しなければならないと、すべてのクライアントが新しい個々のキーを与えられました。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。