RFC3118 日本語訳
3118 Authentication for DHCP Messages. R. Droms, W. Arbaugh, Eds.. June 2001. (Format: TXT=35536 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Droms, Editor
Request for Comments: 3118 Cisco Systems
Category: Standards Track W. Arbaugh, Editor
University of Maryland
June 2001
ワーキンググループR.Droms、コメントを求めるエディタ要求をネットワークでつないでください: 3118年のシスコシステムズカテゴリ: 標準化過程W.Arbaugh、エディタメリーランド大学2001年6月
Authentication for DHCP Messages
DHCPメッセージのための認証
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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サーバから適切な承認をもっている新たに添付のホストを自動的に構成できる新しいDynamic Host Configuration Protocol(DHCP)オプションを定義します。DHCPはTCP/IPネットワークで設定情報をホストに渡すのにフレームワークを提供します。 いくつかの状況で、ネットワーク管理者は認可されたホストにアドレスの配分を抑制したがっているかもしれません。 さらに、何人かのネットワーク管理者がソースの認証とDHCPメッセージのコンテンツに備えたがっているかもしれません。
1. Introduction
1. 序論
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
ネットワーク管理者の中にはソースの認証とDHCPメッセージのコンテンツを提供したがっているかもしれない人もいます。 例えば、クライアントは、にせのDHCPサーバの使用でサービス不能攻撃を受けることがあるかもしれないか、または何気なく例示されたDHCPサーバのため単にmisconfiguredされるかもしれません。 管理者が、認可されたホストへのアドレスの配分がサービスの否定を避けるのを抑制したがっているかもしれないネットワークが「敵対的な」環境でどこを攻撃するか、ネットワーク
Droms & Arbaugh Standards Track [Page 1] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[1ページ]。
medium is not physically secured, such as wireless networks or college residence halls.
媒体はワイヤレス・ネットワークや大学の学校の寄宿舎のように物理的に保証されません。
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認証機構を結合します。
1.1 DHCP threat model
1.1 DHCP脅威モデル
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攻撃を最もよく緩和します。
1.2 Design goals
1.2 デザイン目標
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. 現在のプロトコルを変えるのを避けてください。
Droms & Arbaugh Standards Track [Page 2] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[2ページ]。
3. Limit state required by the server.
4. Limit complexity (complexity breeds design and implementation
errors).
3. 限界州はサーバで. 4を必要としました。 複雑さを制限してください(複雑さは設計と実装誤りを飼育します)。
1.3 Requirements Terminology
1.3 要件用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[5]で説明されるように本書では解釈されることであるべきですか?
1.4 DHCP Terminology
1.4 DHCP用語
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クライアントに設定パラメータを返すインターネット・ホストです。
2. Format of the authentication option
2. 認証オプションの形式
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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 長さ| プロトコル| アルゴリズム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDM| 再生Detection(64ビット)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contを再演してください。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contを再演してください。 | | +-+-+-+-+-+-+-+-+ | | | | 認証情報| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、アルゴリズム、Replay Detection分野、および認証情報分野の長さを含んでいます。
Droms & Arbaugh Standards Track [Page 3] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[3ページ]。
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.
Replay Detection分野がRDM単位であります、そして、認証情報フィールドが使用中のプロトコル単位であります。
The Replay Detection Method (RDM) field determines the type of replay detection used in the Replay Detection field.
Replay Detection Method(RDM)分野はReplay Detection分野で使用される再生検出のタイプを決定します。
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分野が0×00を含んでいるなら、単調に増加するカウンタの値に再生検出分野を設定しなければなりません。 現在の時刻などの対価を使用する、(例えば、NTP-形式タイムスタンプ[4])は反射攻撃という危険を減少させることができます。 すべてのプロトコルでこのメソッドをサポートしなければなりません。
3. Interaction with Relay Agents
3. 中継エージェントとの相互作用
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メッセージ、それらの2つの分野のコンテンツにおける分野を設定しなければならないゼロ'ホップ'の値はメッセージヘッダーの上に機能します。 さらに、中継エージェントは最終としての82[7]がメッセージでサーバにゆだねるDHCP中継エージェント情報オプションを追加するかもしれません。 サーバが受信されたメッセージに含まれていたオプション82を見つけるなら、まるでオプションがメッセージにオプションの注文を変えないで含まれていないかのようにサーバはどんなハッシュ関数も計算しなければなりません。 オプション82を中継エージェントに返送するときはいつも、サーバはメッセージの上にどんなハッシュ関数の計算におけるオプションも含んではいけません。
4. Configuration token
4. 構成トークン
If the protocol field is 0, the authentication information field holds a simple configuration token:
プロトコル分野が0であるなら、認証情報フィールドは簡単な構成トークンを保持します:
Droms & Arbaugh Standards Track [Page 4] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[4ページ]。
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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 長さ|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0| 再生Detection(64ビット)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contを再演してください。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contを再演してください。 | | |-+-+-+-+-+-+-+-+ | | | | 認証情報| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
ここの意図はプレーンテキストパスワードなどの一定の、そして、非計算されたトークンを通過することです。 ケルベロスチケットかワンタイムパスワードなどの計算されたトークンを使用する他のタイプの実体認証が別々のプロトコルと定義されるでしょう。
5. Delayed authentication
5. 遅れた認証
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であるなら、メッセージは「遅れた認証」メカニズムを使用しています。 遅れた認証では、クライアントは認証情報を含んでいるDHCPOFFERメッセージでDHCPDISCOVERメッセージとサーバ回答における認証を要求します。 この認証情報は通報認証と実体認証を提供するためにメッセージ確認コード(MAC)としてソースによって生成された一回だけの値を含んでいます。
This document defines the use of a particular technique based on the HMAC protocol [3] using the MD5 hash [2].
このドキュメントは[3] MD5ハッシュ[2]を使用することでHMACプロトコルに基づく特定のテクニックの使用を定義します。
Droms & Arbaugh Standards Track [Page 5] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[5ページ]。
5.1 Management Issues
5.1 管理問題
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.
「遅れた認証」プロトコルは、別のもの(すなわち、interdomainローミング)にクライアントが1つの管理ドメインから歩き回るかもしれない状況を扱うのを試みません。 このプロトコルは共有秘密キーのバンドで出ている交換が可能であるintradomain問題を解決するのに焦点を合わせられます。
5.2 Format
5.2 形式
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. | +-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 長さ|0 0 0 0 0 0 0 1| アルゴリズム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDM| 再生Detection(64ビット)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contを再演してください。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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) .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 長さ|0 0 0 0 0 0 0 1| アルゴリズム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDM| 再生Detection(64ビット)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contを再演してください。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contを再演してください。 | 秘密のID(32ビット)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 秘密のイドcont| HMAC-MD5(128ビット)… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following definitions will be used in the description of the authentication information for delayed authentication, algorithm 1:
以下の定義は遅れた認証、アルゴリズム1に認証情報の記述に使用されるでしょう:
Droms & Arbaugh Standards Track [Page 6] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[6ページ]。
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によって定義されるようにDetectionを再演してください--秘密の値はメッセージのソースと目的地を平等に割り当てました。 各秘密には、ユニークな識別子(秘密のID)の秘密のIDがあります--秘密の値のためのユニークな識別子はこのメッセージHMAC-MD5のために以前はよくMACを生成していました--MAC母関数[3、2]。
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計算機能に入力されるように使用されています。 MACを生成するのに使用される秘密に関する識別子に'秘密のID'分野を設定しなければなりません。
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クライアントが複数の管理ドメインに接続するアーキテクチャを計量しないかもしれません。
5.3 Message validation
5.3 メッセージ合法化
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の計算のために認証オプションの'MAC'分野をすべての0に設定しなければならなくて、また、DHCP中継エージェントが'giaddr'の値を変更するかもしれなくて、DHCPメッセージの分野を'飛び越す'ので、MACの計算のためにそれらの2つの分野のコンテンツをゼロに設定しなければなりません。 受信機によって計算されたMACが認証オプションに含まれたMACに合っていないなら、受信機はDHCPメッセージを捨てなければなりません。
Section 3 provides additional information on handling messages that include option 82 (Relay Agents).
セクション3はオプション82(リレーエージェント)を含んでいる取り扱いメッセージに関する追加情報を提供します。
Droms & Arbaugh Standards Track [Page 7] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[7ページ]。
5.4 Key utilization
5.4 主要な利用
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. クライアントはそれがサーバに送るどんなメッセージもコード化するのにキーを使用して、それが. クライアントのサーバの主要なSHOULDから受け取るどんなメッセージも認証して、確かめるために、初めは、いくらかのバンドで出ているメカニズム、およびSHOULDを通してクライアントに分配されてください。すべての認証されたDHCPメッセージにおける使用のためにクライアントの上に局所的に保存されてください。 かつて、キーをクライアントに与えて、それはクライアントの構成が変化してもそれがすべてのトランザクションのために合わせるSHOULD使用です。 例えば、新しいネットワーク・アドレスがクライアントに割り当てられるなら。
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はかぎ管理のためのテクニックについて説明します。
5.5 Client considerations
5.5 クライアント問題
This section describes the behavior of a DHCP client using delayed authentication.
このセクションは、遅れた認証を使用することでDHCPクライアントの振舞いについて説明します。
5.5.1 INIT state
5.5.1 INIT状態
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で説明された合法化テストを実行しなければなりません。 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メッセージに応じるのを選ぶかもしれません。
Droms & Arbaugh Standards Track [Page 8] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[8ページ]。
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.
慎重に、ローカルの方針に非認証されたメッセージを受け入れるように設定するという決定をするべきです。 unauthenticated DHCPOFFERメッセージを受け入れるのに、クライアントはスプーフィングと他の攻撃に被害を受け易くなる場合があります。 地元のユーザにクライアントがunauthenticated 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.
デフォルトで衰退の非認証されたメッセージに構成されていて、クライアントは非認証されたメッセージ、およびSHOULDを傾けるのにおいて構成可能であるに違いありません。 クライアントは、合法化テストに合格しない認証情報とDHCPOFFERメッセージなしでDHCPOFFERメッセージを区別するのを選ぶかもしれません。 例えば、クライアントは、前者を受け入れて、後者を捨てるかもしれません。 クライアントが非認証されたメッセージを受け入れるなら、クライアントSHOULDはどんな地元のユーザにも知らせます、そして、SHOULDはイベントを登録します。
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メッセージを受け入れたなら、クライアントはサーバからunauthenticated DHCPACKメッセージを受け入れるかもしれません。
5.5.2 INIT-REBOOT state
5.5.2 INIT-REBOOT状態
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メッセージで使用した秘密を使用しなければならないと。 認証されたメッセージを全く受け取らなかったなら、クライアントは、unauthenticated DHCPACK/DHCPNAKメッセージを受け入れるのを選ぶかもしれません。 クライアントは[1]のセクション3.2の指定されるとしてのどんなDHCPACK/DHCPNAKメッセージの領収書(または、それの不足)も扱わなければなりません。
Droms & Arbaugh Standards Track [Page 9] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[9ページ]。
5.5.3 RENEWING state
5.5.3 RENEWING状態
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].
クライアントがRENEWING状態でそれがDHCPREQUESTメッセージに認証情報を生成するために現在の構成を得る初期のDHCPREQUESTメッセージで使用した秘密を使用すると。 クライアントがDHCPACKメッセージを全く受け取らないか、またはDHCPACKメッセージのいずれも合法化を通過しないなら、まるで.5のセクション4.4DHCP仕様[1]によるDHCPACKメッセージを受け取っていないかのようにクライアントは振る舞います。
5.5.4 REBINDING state
5.5.4 REBINDING状態
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メッセージのいずれも合法化を通過しないなら、まるで.5のセクション4.4DHCP仕様[1]によるDHCPACKメッセージを受け取っていないかのようにクライアントは振る舞います。
5.5.5 DHCPINFORM message
5.5.5 DHCPINFORMメッセージ
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、サーバで。したがって、共有秘密キー値が存在していると、クライアントSHOULDはDHCPDISCOVERメッセージのように認証要求を使用します。 セクション5.5.1は、DHCPOFFERにメッセージをするときクライアントがどんな受信されたDHCPACKメッセージも扱わなければならないのを見ます。
5.5.6 DHCPRELEASE message
5.5.6 DHCPRELEASEメッセージ
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メッセージがある認証情報を入れなければなりません。
5.6 Server considerations
5.6 サーバ問題
This section describes the behavior of a server in response to client messages using delayed authentication.
このセクションは、遅れた認証を使用することでクライアントメッセージに対応してサーバの働きについて説明します。
5.6.1 General considerations
5.6.1 一般問題
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
* サーバが以前にコミュニケートしていないかもしれないクライアントと共に使用のためのその秘密のための適切な秘密と識別子を特定してください。
Droms & Arbaugh Standards Track [Page 10] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[10ページ]。
* 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].
それらのDHCPOFFERメッセージの同じ秘密を使用したサーバはINIT-REBOOT状態のクライアントからの認証されたDHCPREQUESTメッセージを有効にすることができるだけです。 他のサーバはDHCPREQUESTメッセージを捨てるでしょう。 クライアントによって選択された秘密を使用したサーバだけがそれらの提供された設定情報を選択しないで、サーバの利用可能なアドレスのプールに提供されたネットワーク・アドレスを返すことができることを決定できるでしょう。 DHCPREQUESTメッセージを有効にすることができないサーバは結局、DHCP仕様[1]のセクション3.1で説明されるようにそれらの利用可能なアドレスのプールにそれらの提供されたネットワーク・アドレスを返すでしょう。
5.6.2 After receiving a DHCPDISCOVER message
5.6.2 DHCPDISCOVERメッセージを受け取った後に
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メッセージに認証情報を含んでいます、上です。 サーバは、クライアントのために選択された秘密に関する識別子を記録して、クライアントがいるその後のメッセージを有効にするのにその同じ秘密を使用しなければなりません。
5.6.3 After receiving a DHCPREQUEST message
5.6.3 DHCPREQUESTメッセージを受け取った後に
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で指定されるように生成された認証情報を含まなければなりません。
5.6.4 After receiving a DHCPINFORM message
5.6.4 DHCPINFORMメッセージを受け取った後に
The server MAY choose to accept unauthenticated DHCPINFORM messages, or only accept authenticated DHCPINFORM messages based on a site policy.
サーバは、unauthenticated DHCPINFORMメッセージを受け入れるのを選ぶか、またはサイト方針に基づく認証されたDHCPINFORMメッセージを受け入れるだけであるかもしれません。
Droms & Arbaugh Standards Track [Page 11] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[11ページ]。
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メッセージの送付者と共にサーバで共有秘密キー値を確立しないなら、サーバがunauthenticated DHCPACKメッセージで反応するかもしれませんか、サーバが受け入れないなら、DHCPNAKがサイト方針に基づくクライアントを非認証したか、またはサーバは、DHCPINFORMメッセージに応じないのを選ぶかもしれません。
6. IANA Considerations
6. IANA問題
Section 2 defines a new DHCP option called the Authentication Option, whose option code is 90.
セクション2はオプションコードが90であるAuthentication Optionと呼ばれる新しい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.
このドキュメントはIANAによって作成されて、維持されることになっているAuthentication Optionに関連している3つの新しい名前空間を指定します: アルゴリズムと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の遅れた認証プロトコルのための)のために。 スペースというプロトコル名からの加算値はRFC2434[8]で定義されるようにIETF Consensusを通して割り当てられるでしょう。
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.
スペースというAlgorithm名は個々のプロトコルに特定です。 すなわち各プロトコルには、それ自身のAlgorithm名前スペースがあります。 特定のプロトコルのために名前スペース値をAlgorithmに割り当てるためのガイドラインは新しいプロトコルの定義と共に指定されるべきです。
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.
構成トークンプロトコルのために、Algorithm分野は0でなければなりません。 遅れた認証プロトコルにおいて、Algorithm値1はセクション5で定義されるようにHMAC-MD5母関数に割り当てられます。 Algorithm1のためのスペースというAlgorithm名からの加算値はIETF Consensusを通して割り当てられるでしょう、RFC2434で定義されるように。
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名からの加算値はRFC2434で定義されるようにIETF Consensusを通して割り当てられるでしょう。
7. References
7. 参照
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[1]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[2] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
Droms & Arbaugh Standards Track [Page 12] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[12ページ]。
[3] Krawczyk H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997.
[3] Krawczyk H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[4] Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March
1992.
[4] 工場、D.、「ネットワーク時間プロトコル(バージョン3)」、RFC1305、1992年3月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2219, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2219、1997年3月。
[6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[6] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、1997年3月。
[7] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001.
[7] パトリック、M.、「DHCP中継エージェント情報オプション」、RFC3046、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問題部のためのガイドライン」BCP26、RFC2434(1998年10月)。
8. Acknowledgments
8. 承認
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はダラスIETFミーティング(1995年12月)で端末の余地のBOFでこの認証プロトコルのオリジナルバージョンを開発しました。 エディタ(Droms)のひとりはその議論からの注意を転写しました。(注意はこのドキュメントの基礎を形成します)。 エディタはこのドキュメントとその以前の草稿を再検討する際にジェフとクリスチャンの忍耐に感謝します。
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の脅威モデルと要件はビルの交渉プロトコル提案から来ます。 ピーター・フォードを含んでいて、1998年6月に持たれていたDHC WGの当座のミーティングの出席者(キム・キネア、グレンWaters、ロブ・スティーブンス、ビルArbaugh、Baijuパテル、カール・スミス、トーマスNarten、スチュワート・クワン、Munilシャー、Olafurグドムンソン、ロバート・ワトソン、ラルフDroms、マイク・ドゥーリー、グレッグRabil、およびアルンカプール)は、脅威モデルを開発して、いくつかの代案を再検討しました。
The replay detection method field is due to Vipul Gupta.
再生検出メソッド分野はVipulグプタのためです。
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.
また、ジョン・ウィルキンズ、Ranアトキンソン、ショーンMamros、およびトーマスNartenにこのドキュメントの以前の草稿を見直してくださってありがとうございます。
Droms & Arbaugh Standards Track [Page 13] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[13ページ]。
9. Security Considerations
9. セキュリティ問題
This document describes authentication and verification mechanisms for DHCP.
このドキュメントはDHCPのために認証と検証メカニズムについて説明します。
9.1 Protocol vulnerabilities
9.1 プロトコル脆弱性
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サーバが稼働しているコンピュータを圧倒するかもしれません)。
9.2 Protocol limitations
9.2 プロトコル制限
Delayed authentication does not support interdomain authentication.
遅れた認証は、interdomainが認証であるとサポートしません。
A real digital signature mechanism such as RSA, while currently computationally infeasible, would provide better security.
RSAなどの本当のデジタル署名メカニズムは現在計算上実行不可能である間、より良いセキュリティを提供するでしょう。
Droms & Arbaugh Standards Track [Page 14] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[14ページ]。
10. Editors' Addresses
10. エディタのアドレス
Ralph Droms Cisco Systems 300 Apollo Drive Chelmsford, MA 01824
ラルフDromsシスコシステムズ300アポロDriveチェルムズフォード、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
カレッジパーク、MD 20742を築き上げるビル・Arbaughコンピュータサイエンス学部のメリーランド大学のA.V.ウィリアムズ
Phone: (301) 405-2774 EMail: waa@cs.umd.edu
以下に電話をしてください。 (301) 405-2774 メールしてください: waa@cs.umd.edu
Droms & Arbaugh Standards Track [Page 15] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[15ページ]。
Appendix A - Key Management Technique
付録A--Key Managementのテクニック
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、ユニークなイド)と等しいです。そこでは、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.にクライアントイドからのKを作り直すことによって、新しいクライアントからの入力メッセージを生成することができません。 知られているクライアントに関しては、サーバは、ダイナミックにDHCPメッセージのクライアントイドからクライアントのKを取り戻すのを選ぶことができるか、precomputeに選んで、または先験的に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サーバは、合わせられたMACsをテキストパスワードをクリアするためにアクセスを必要としないで、計算して、確かめることができます。
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)はどんなクライアントによっても保存されてはいけません。 クライアントSHOULDにキーを与えるだけであって、選ばれてクライアント当然のことの新しい個人がキーであったなら、K.If MKは感染していて、a新しいMK SHOULDです。
Droms & Arbaugh Standards Track [Page 16] RFC 3118 Authentication for DHCP Messages June 2001
Droms&Arbaugh規格はメッセージ2001年6月にDHCPのためにRFC3118認証を追跡します[16ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Droms & Arbaugh Standards Track [Page 17]
Droms&Arbaugh標準化過程[17ページ]
一覧
スポンサーリンク
