[要約] RFC 4030は、DHCPリレーエージェントオプションの認証サブオプションに関する仕様です。このRFCの目的は、DHCPリレーエントエージェントが認証情報を提供するための方法を定義することです。
Network Working Group M. Stapp
Request for Comments: 4030 Cisco Systems, Inc.
Category: Standards Track T. Lemon
Nominum, Inc.
March 2005
The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
動的ホスト構成プロトコル（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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
The Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages.
動的ホスト構成プロトコル（DHCP）リレーエージェント情報オプション（RFC 3046）は、DHCPリレーエージェントとDHCPサーバーの間で情報を伝えます。この仕様は、ペイロードにキー付きハッシュを含む、そのオプションの認証サブオプションを定義します。サブオプションは、リレーしたDHCPメッセージのデータの整合性とリプレイ保護をサポートします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3
3. DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 4
4. Suboption Format . . . . . . . . . . . . . . . . . . . . . . 4
5. Replay Detection . . . . . . . . . . . . . . . . . . . . . . 5
6. The Relay Identifier Field . . . . . . . . . . . . . . . . . 5
7. Computing Authentication Information . . . . . . . . . . . . 6
7.1. The HMAC-SHA1 Algorithm . . . . . . . . . . . . . . . 6
8. Procedures for Sending Messages . . . . . . . . . . . . . . 7
8.1. Replay Detection . . . . . . . . . . . . . . . . . . . 7
8.2. Packet Preparation . . . . . . . . . . . . . . . . . . 8
8.3. Checksum Computation . . . . . . . . . . . . . . . . . 8
8.4. Sending the Message . . . . . . . . . . . . . . . . . 8
9. Procedures for Processing Incoming Messages . . . . . . . . 8
9.1. Initial Examination . . . . . . . . . . . . . . . . . 8
9.2. Replay Detection Check . . . . . . . . . . . . . . . . 9
9.3. Testing the Checksum . . . . . . . . . . . . . . . . . 9
10. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 9
10.1. Receiving Messages from Other Relay Agents . . . . . . 10
10.2. Sending Messages to Servers . . . . . . . . . . . . . 10
10.3. Receiving Messages from Servers . . . . . . . . . . . 10
11. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 10
11.1. Receiving Messages from Relay Agents . . . . . . . . . 10
11.2. Sending Reply Messages to Relay Agents . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
13. Security Considerations . . . . . . . . . . . . . . . . . . 11
13.1. The Key ID Field . . . . . . . . . . . . . . . . . . . 12
13.2. Protocol Vulnerabilities . . . . . . . . . . . . . . . 12
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15
DHCP (RFC 2131 [6]) provides IP addresses and configuration information for IPv4 clients. It includes a relay-agent capability (RFC 951 [7], RFC 1542 [8]) in which processes within the network infrastructure receive broadcast messages from clients and forward them to servers as unicast messages. In network environments such as DOCSIS data-over-cable and xDSL, for example, it has proven useful for the relay agent to add information to the DHCP message before forwarding it, by using the relay-agent information option (RFC 3046 [1]). The kind of information that relays add is often used in the server's decision-making about the addresses and configuration parameters that the client should receive. The way that the relay-agent data is used in server decision-making tends to make that data very important, and it highlights the importance of the trust relationship between the relay agent and the server.
DHCP（RFC 2131 [6]）は、IPv4クライアントにIPアドレスと構成情報を提供します。ネットワークインフラストラクチャ内のプロセスがクライアントからブロードキャストメッセージを受信し、ユニキャストメッセージとしてサーバーに転送するリレーエージェント機能（RFC 951 [7]、RFC 1542 [8]）が含まれています。たとえば、DOCSIS Data-Over-CableやXDSLなどのネットワーク環境では、リレーエージェントがリレーエージェント情報オプション（RFC 3046 [1]を使用して、転送する前にDHCPメッセージに情報を追加するのに役立つことが証明されています。）。リレー追加の情報の種類は、クライアントが受信するアドレスと構成パラメーターに関するサーバーの意思決定でよく使用されます。サーバーの意思決定でリレーエージェントデータが使用される方法は、そのデータを非常に重要にする傾向があり、リレーエージェントとサーバーの間の信頼関係の重要性を強調しています。
The existing DHCP Authentication specification (RFC 3118) [9] only covers communication between the DHCP client and server. Because relay-agent information is added after the client has sent its message, the DHCP Authentication specification explicitly excludes relay-agent data from that authentication.
既存のDHCP認証仕様（RFC 3118）[9]は、DHCPクライアントとサーバー間の通信のみをカバーしています。クライアントがメッセージを送信した後にリレーエージェント情報が追加されるため、DHCP認証仕様はその認証からリレーエージェントデータを明示的に除外します。
The goal of this specification is to define methods that a relay agent can use to
この仕様の目標は、リレーエージェントが使用できる方法を定義することです
1. protect the integrity of relayed DHCP messages, 2. provide replay protection for those messages, and 3. leverage existing mechanisms, such as DHCP Authentication.
1. リレーしたDHCPメッセージの整合性を保護します。2。これらのメッセージにリプレイ保護を提供し、3。DHCP認証などの既存のメカニズムを活用します。
In order to meet these goals, we specify a new relay-agent suboption, the Authentication suboption. The format of this suboption is very similar to the format of the DHCP Authentication option, and the specification of its cryptographic methods and hash computation is also similar.
これらの目標を達成するために、新しいリレーエージェントサブオプションである認証サブオプションを指定します。このサブオプションの形式は、DHCP認証オプションの形式に非常に似ており、その暗号化方法とハッシュ計算の仕様も同様です。
The Authentication suboption is included by relay agents that seek to ensure the integrity of the data they include in the Relay Agent option. These relay agents are configured with the parameters necessary for generating cryptographic checksums of the data in the DHCP messages that they forward to DHCP servers. A DHCP server configured to process the Authentication suboption uses the information in the suboption to verify the checksum in the suboption and continues processing the relay agent information option only if the checksum is valid. If the DHCP server sends a response, it includes an Authentication suboption in its response message. Relay agents test the checksums in DHCP server responses to decide whether to forward the responses.
認証サブオプションは、リレーエージェントオプションに含まれるデータの整合性を確保しようとするリレーエージェントによって含まれます。これらのリレーエージェントは、DHCPサーバーに転送するDHCPメッセージ内のデータの暗号化チェックサムを生成するために必要なパラメーターで構成されています。認証サブオプションを処理するように構成されたDHCPサーバーは、Suboptionの情報を使用してSuboptionのチェックサムを検証し、チェックサムが有効な場合にのみ、リレーエージェント情報オプションの処理を継続します。DHCPサーバーが応答を送信する場合、応答メッセージに認証サブオプションが含まれます。リレーエージェントは、DHCPサーバーの応答でチェックサムをテストして、応答を転送するかどうかを決定します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2].
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"RFC 2119 [2]に記載されているように解釈されるべきです。
This document uses the terms "DHCP server" (or "server") and "DHCP client" (or "client") as defined in RFC 2131 [6]. The term "DHCP relay agent" refers to a "BOOTP relay agent" as defined in RFC 2131.
このドキュメントでは、RFC 2131 [6]で定義されているように、「DHCPサーバー」（または「サーバー」）および「DHCPクライアント」（または「クライアント」）という用語を使用します。「DHCPリレーエージェント」という用語は、RFC 2131で定義されている「BOOTPリレーエージェント」を指します。
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 | Algorithm | MBZ | RDM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Authentication Information |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for the suboption is 8. The length field includes the lengths of the algorithm, the RDM, and all subsequent suboption fields in octets.
サブオプションのコードは8です。長さフィールドには、オクテット内のアルゴリズム、RDM、およびその後のすべてのサブオプションフィールドの長さが含まれます。
The Algorithm field defines the algorithm used to generate the authentication information.
アルゴリズムフィールドは、認証情報を生成するために使用されるアルゴリズムを定義します。
Four bits are reserved for future use. These bits SHOULD be set to zero and MUST NOT be used when the suboption is processed.
4つのビットは、将来の使用のために予約されています。これらのビットはゼロに設定する必要があり、サブオプションが処理されたときに使用しないでください。
The Replay Detection Method (RDM) field defines the method used to generate the Replay Detection Data.
リプレイ検出方法（RDM）フィールドは、リプレイ検出データを生成するために使用される方法を定義します。
The Replay Detection field contains a value used to detect replayed messages, which are interpreted according to the RDM.
リプレイ検出フィールドには、RDMに従って解釈される再生メッセージの検出に使用される値が含まれています。
The Relay Identifier field is used by relay agents that do not set giaddr, as described in RFC 3046 [1], section 2.1.
RFC 3046 [1]、セクション2.1に記載されているように、リレー識別子フィールドは、GIADDRを設定しないリレーエージェントによって使用されます。
The Authentication Information field contains the data required to communicate algorithm-specific parameters, as well as the checksum. The checksum is usually a digest of the data in the DHCP packet computed by using the method specified by the Algorithm field.
認証情報フィールドには、アルゴリズム固有のパラメーターとチェックサムを通信するために必要なデータが含まれています。チェックサムは通常、アルゴリズムフィールドで指定されたメソッドを使用して計算されたDHCPパケットのデータのダイジェストです。
The replay-detection mechanism is designed on the notion that a receiver can determine whether a message has a valid replay token value. The default RDM, with value 1, specifies that the Replay Detection field contains an increasing counter value. The receiver associates a replay counter with each sender and rejects any message containing an authentication suboption with a Replay Detection counter value less than or equal to the last valid value. DHCP servers MAY identify relay agents by giaddr value or by other data in the message (e.g., data in other relay agent suboptions). Relay agents identify DHCP servers by source IP address. If the message's replay detection value, and the checksum are valid, the receiver updates its notion of the last valid replay counter value associated with the sender.
リプレイ検出メカニズムは、受信者がメッセージに有効なリプレイトークン値があるかどうかを判断できるという概念に基づいて設計されています。値1のデフォルトのRDMは、リプレイ検出フィールドにカウンター値の増加が含まれていることを指定します。受信者は、リプレイカウンターを各送信者と関連付け、リプレイ検出カウンター値を含む認証サブオプションを含むメッセージを拒否し、最後の有効な値以下に拒否します。DHCPサーバーは、GIADDR値またはメッセージ内の他のデータ（他のリレーエージェントサブオプションのデータなど）によってリレーエージェントを識別できます。リレーエージェントは、ソースIPアドレスでDHCPサーバーを識別します。メッセージのリプレイ検出値とチェックサムが有効な場合、受信者は送信者に関連付けられた最後の有効なリプレイカウンター値の概念を更新します。
All implementations MUST support the default RDM. Additional methods may be defined in the future, following the process described in section 12.
すべての実装は、デフォルトのRDMをサポートする必要があります。セクション12で説明したプロセスに従って、追加の方法は将来定義される場合があります。
Receivers SHOULD perform the replay-detection check before testing the checksum. The keyed hash calculation is likely to be much more expensive than the replay-detection value check.
レシーバーは、チェックサムをテストする前に、リプレイ検出チェックを実行する必要があります。キー付きハッシュ計算は、リプレイ検出値チェックよりもはるかに高価になる可能性があります。
DISCUSSION: This places a burden on the receiver to maintain some run-time state (the most-recent valid counter value) for each sender, but the number of members in a DHCP agent-server system is unlikely to be unmanageably large.
議論：これにより、受信者に各送信者の実行時間状態（最も優れた有効なカウンター値）を維持する負担がありますが、DHCPエージェントサーバーシステムのメンバーの数は、見た目が広いことはありません。
The Relay Agent Information Option [1] specification permits a relay agent to add a relay agent option to relayed messages without setting the giaddr field. In this case, the eventual receiver of the message needs a stable identifier to use in order to associate per-sender state such as Key ID and replay-detection counters.
リレーエージェント情報オプション[1]仕様により、リレーエージェントは、GIADDRフィールドを設定せずにリレーしたメッセージにリレーエージェントオプションを追加できます。この場合、メッセージの最終的な受信機には、キーIDやリプレイ検出カウンターなどのセンダーごとの状態を関連付けるために、使用する安定した識別子が必要です。
A relay agent that adds a relay agent information option and sets giaddr MUST NOT set the Relay ID field. A relay agent that does not set giaddr MAY be configured to place a value in the Relay ID field. If the relay agent is configured to use the Relay ID field, it MAY be configured with a value to use, or it MAY be configured to generate a value based on some other data, such as its MAC or IP addresses. If a relay generates a Relay ID value, it SHOULD select a value that it can regenerate reliably; e.g., across reboots.
リレーエージェント情報オプションを追加し、GIADDRを設定するリレーエージェントは、リレーIDフィールドを設定してはなりません。GIADDRを設定しないリレーエージェントは、リレーIDフィールドに値を配置するように構成できます。リレーエージェントがリレーIDフィールドを使用するように構成されている場合、使用する値で構成されているか、MACやIPアドレスなどの他のデータに基づいて値を生成するように構成されている場合があります。リレーがリレーID値を生成する場合、確実に再生できる値を選択する必要があります。たとえば、再起動全体。
Servers that process an Authentication Suboption SHOULD use the giaddr value to identify the sender if the giaddr field is set. Servers MAY be configured to use some other data in the message to identify the sender. If giaddr is not set, the server SHOULD use the Relay ID field if it is nonzero. If neither the giaddr nor the Relay ID field is set, the server MAY be configured to use some other data in the message, or it MAY increment an error counter.
認証サブオプションを処理するサーバーGIADDR値を使用して、GIADDRフィールドが設定されている場合は送信者を識別する必要があります。サーバーは、メッセージ内の他のデータを使用して送信者を識別するように構成されている場合があります。GIADDRが設定されていない場合、サーバーはゼロ以外の場合はリレーIDフィールドを使用する必要があります。GIADDRもリレーIDフィールドも設定されていない場合、サーバーはメッセージ内の他のデータを使用するように構成されているか、エラーカウンターを増やすことができます。
The Authentication Information field contains a keyed hash generated by the sender. All algorithms are defined to process the data in the DHCP messages in the same way. The sender and receiver compute a hash across a buffer containing all of the bytes in the DHCP message, including the fixed DHCP message header, the DHCP options, and the relay agent suboptions, with the following exceptions. The value of the 'hops' field MUST be set to zero for the computation because its value may be changed in transmission. The value of the 'giaddr' field MUST also be set to zero for the computation because it may be modified in networks where one relay agent adds the relay agent option but another relay agent sets 'giaddr' (see RFC 3046, section 2.1). In addition, because the relay agent option is itself included in the computation, the 'authentication information' field in the Authentication suboption is set to all zeros. The relay agent option length, the Authentication suboption length and other Authentication suboption fields are all included in the computation.
認証情報フィールドには、送信者が生成するキー付きハッシュが含まれています。すべてのアルゴリズムは、同じ方法でDHCPメッセージのデータを処理するために定義されています。送信者と受信機は、固定DHCPメッセージヘッダー、DHCPオプション、リレーエージェントサブオプションなど、DHCPメッセージのすべてのバイトを含むバッファーを横切るハッシュを計算します。「ホップ」フィールドの値は、その値が送信で変更される可能性があるため、計算でゼロに設定する必要があります。「Giaddr」フィールドの値は、1つのリレーエージェントがリレーエージェントオプションを追加し、別のリレーエージェントが「Giaddr」を設定するネットワークで変更される可能性があるため、計算のためにゼロに設定する必要があります（RFC 3046、セクション2.1を参照）。さらに、リレーエージェントオプション自体が計算に含まれているため、認証サブオプションの「認証情報」フィールドはすべてのゼロに設定されます。リレーエージェントオプションの長さ、認証サブオプション長、およびその他の認証サブオプションフィールドはすべて計算に含まれています。
All implementations MUST support Algorithm 1, the HMAC-SHA1 algorithm. Additional algorithms may be defined in the future, following the process described in section 12.
すべての実装は、HMAC-SHA1アルゴリズムであるアルゴリズム1をサポートする必要があります。セクション12で説明したプロセスに従って、追加のアルゴリズムは将来定義される場合があります。
Algorithm 1 is assigned to the HMAC [3] protocol by using the SHA-1 [4] hash function. This algorithm requires that a shared secret key be configured at the relay agent and the DHCP server. A 32-bit Key Identifier is associated with each shared key, and this identifier is carried in the first 4 bytes of the Authentication Information field of the Authentication suboption. The HMAC-SHA1 computation generates a 20-byte hash value, which is placed in the Authentication Information field after the Key ID.
アルゴリズム1は、SHA-1 [4]ハッシュ関数を使用して、HMAC [3]プロトコルに割り当てられます。このアルゴリズムでは、リレーエージェントとDHCPサーバーで共有されたシークレットキーを構成する必要があります。32ビットキー識別子は各共有キーに関連付けられており、この識別子は、認証サブオプションの認証情報フィールドの最初の4バイトに配置されます。HMAC-SHA1計算は、キーIDの後に認証情報フィールドに配置された20バイトのハッシュ値を生成します。
When Algorithm 1 is used, the format of the Authentication suboption is as follows:
アルゴリズム1を使用する場合、認証サブオプションの形式は次のとおりです。
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 | 38 |0 0 0 0 0 0 0 1| MBZ | RDM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-SHA1 (160 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The suboption length is 38. The RDM and Replay Detection fields are as specified in section 5. The Relay ID field is set as specified in section 6. The Key ID is set by the sender to the ID of the key used in computing the checksum, as an integer value in network byte order. The HMAC result follows the Key ID.
サブオプションの長さは38です。RDMおよびリプレイ検出フィールドはセクション5で指定されています。リレーIDフィールドはセクション6で指定されています。キーIDは、チェックサムの計算で使用されるキーのIDに送信者によって設定されています。、ネットワークバイト順序の整数値として。HMACの結果は、キーIDに従います。
The Key ID exists only to allow the sender and receiver to specify a shared secret in cases where more than one secret is in use among a network's relays and DHCP servers. The Key ID values are entirely a matter of local configuration; they only have to be unique locally. This specification does not define any semantics or impose any requirements on this algorithm's Key ID values.
キーIDは、ネットワークのリレーとDHCPサーバーの間で複数の秘密が使用されている場合、送信者とレシーバーが共有秘密を指定できるようにするためにのみ存在します。キーID値は、完全にローカル構成の問題です。彼らは地元でユニークである必要があります。この仕様では、セマンティクスを定義したり、このアルゴリズムのキーID値に要件を課したりしません。
The sender obtains a replay-detection counter value to use based on the RDM it is using. If the sender is using RDM 1, the default RDM, the value MUST be greater than any previously sent value.
送信者は、使用しているRDMに基づいて使用するリプレイ検出カウンター値を取得します。送信者がデフォルトのRDMであるRDM 1を使用している場合、値は以前に送信された値よりも大きくなければなりません。
The sender sets the 'giaddr' field and the 'hops' field to all zeros. The sender appends the relay agent information option to the client's packet, including the Authentication suboption. The sender selects an appropriate Replay Detection value. The sender places its identifier into the Relay ID field, if necessary, or sets the field to all zeros. The sender sets the suboption length, places the Replay Detection value into the Replay Detection field of the suboption, and sets the algorithm to the algorithm number that it is using. If the sender is using HMAC-SHA1, it sets the Key ID field to the appropriate value. The sender sets the field that will contain the checksum to all zeros. Other algorithms may specify additional preparation steps.
送信者は、すべてのゼロに「giaddr」フィールドと「ホップ」フィールドを設定します。送信者は、認証サブオプションを含む、クライアントのパケットにリレーエージェント情報オプションを追加します。送信者は、適切なリプレイ検出値を選択します。送信者は、必要に応じてその識別子をリレーIDフィールドに配置するか、すべてのゼロにフィールドを設定します。送信者は、サブオプションの長さを設定し、リプレイ検出値をサブオプションのリプレイ検出フィールドに配置し、使用しているアルゴリズム番号にアルゴリズムを設定します。送信者がHMAC-SHA1を使用している場合、キーIDフィールドを適切な値に設定します。送信者は、すべてのゼロにチェックサムを含むフィールドを設定します。他のアルゴリズムは、追加の準備手順を指定する場合があります。
The sender computes the checksum across the entire DHCP message, using the algorithm it has selected. The sender places the result of the computation into the Authentication Information field of the Authentication suboption.
送信者は、選択したアルゴリズムを使用して、DHCPメッセージ全体にチェックサムを計算します。送信者は、計算の結果を認証サブオプションの認証情報フィールドに配置します。
The sender restores the values of the 'hops' and 'giaddr' fields and sends the message.
送信者は、「ホップ」および「Giaddr」フィールドの値を復元し、メッセージを送信します。
The receiver examines the message for the value of the giaddr field and determines whether the packet includes the relay agent information option. The receiver uses its configuration to determine whether it should expect an Authentication suboption. The receiver MUST support a configuration that allows it to drop incoming messages that do not contain a valid relay agent information option and Authentication suboption.
受信機は、GIADDRフィールドの値のメッセージを調べ、パケットにリレーエージェント情報オプションが含まれているかどうかを判断します。受信者は、その構成を使用して、認証サブオプションを期待するかどうかを判断します。受信者は、有効なリレーエージェント情報オプションと認証サブオプションを含まない受信メッセージを削除できるようにする構成をサポートする必要があります。
If the receiver determines that the Authentication suboption is present and that it should process the suboption, it uses the data in the message to determine which algorithm, key, and RDM to use in validating the message. If the receiver cannot determine which algorithm, key, and RDM to use, or if it does not support the value indicated in the message, it SHOULD drop the message. Because this situation could indicate a misconfiguration that could deny service to clients, receivers MAY attempt to notify their administrators or to log an error message.
受信者が認証サブオプションが存在し、サブオプションを処理する必要があると判断した場合、メッセージのデータを使用して、メッセージの検証に使用するアルゴリズム、キー、およびRDMを決定します。受信者が使用するアルゴリズム、キー、およびRDMを決定できない場合、またはメッセージに示されている値をサポートしていない場合は、メッセージをドロップする必要があります。この状況は、クライアントへのサービスを拒否する可能性のある誤解を示す可能性があるため、受信者は管理者に通知したり、エラーメッセージを記録しようとする場合があります。
The receiver examines the RDM field. Receivers MUST discard messages containing RDM values that they do not support. Because this may indicate a misconfiguration at the sender, an attempt SHOULD be made to indicate this condition to the administrator by incrementing an error counter or writing a log message. If the receiver supports the RDM, it examines the value in the Replay Detection field by using the procedures in the RDM and in section 5. If the Replay value is not valid, the receiver MUST drop the message.
レシーバーはRDMフィールドを調べます。受信者は、サポートしていないRDM値を含むメッセージを破棄する必要があります。これは、送信者での誤解を示している可能性があるため、エラーカウンターを増やしたり、ログメッセージを書いたりすることにより、この状態を管理者に示す試みを行う必要があります。レシーバーがRDMをサポートする場合、RDMの手順とセクション5の手順を使用して、リプレイ検出フィールドの値を調べます。リプレイ値が有効でない場合、受信機はメッセージをドロップする必要があります。
Note that at this point the receiver MUST NOT update its notion of the last valid Replay Detection value for the sender. Until the checksum has been tested, the Replay Detection field cannot be trusted. If the receiver trusts the Replay Detection value without testing the checksum, a malicious host could send a replayed message with a Replay Detection value that was very high, tricking the receiver into rejecting legitimate values from the sender.
この時点で、受信者は送信者の最後の有効なリプレイ検出値の概念を更新してはなりません。チェックサムがテストされるまで、リプレイ検出フィールドを信頼できません。レシーバーがチェックサムをテストせずにリプレイ検出値を信頼している場合、悪意のあるホストは、非常に高いリプレイ検出値を持つリプレイメッセージを送信することができ、受信者が送信者からの正当な値を拒否するようにトリックすることができます。
The receiver prepares the packet in order to test the checksum by setting the 'giaddr' and 'hops' fields to zero, and by setting the Authentication Information field of the suboption to all zeros. Using the algorithm and key associated with the sender, the receiver computes a hash of the message. The receiver compares the result of its computation with the value sent. If the checksums do not match, the receiver MUST drop the message. Otherwise, the receiver updates its notion of the last valid Replay Detection value associated with the sender and processes the message.
レシーバーは、「GIADDR」と「HOPS」フィールドをゼロに設定し、サブオプションの認証情報フィールドをすべてのゼロに設定することにより、チェックサムをテストするためにパケットを準備します。送信者に関連付けられたアルゴリズムとキーを使用して、レシーバーはメッセージのハッシュを計算します。受信機は、計算の結果を送信された値と比較します。チェックサムが一致しない場合、受信者はメッセージをドロップする必要があります。それ以外の場合、受信者は、送信者に関連付けられた最後の有効なリプレイ検出値の概念を更新し、メッセージを処理します。
DHCP Relay agents are typically configured with the addresses of one or more DHCP servers. A relay agent that implements this suboption requires an algorithm number for each server, as well as appropriate credentials (i.e., keys). Relay implementations SHOULD support a configuration that indicates that all relayed messages should include the authentication suboption. Use of the authentication suboption SHOULD be disabled by default. Relay agents MAY support configuration that indicates that certain destination servers support the authentication suboption and that other servers do not. Relay agents MAY support configuration of a single algorithm number and key to be used with all DHCP servers, or they MAY support configuration of different algorithms and keys for each server.
DHCPリレーエージェントは通常、1つ以上のDHCPサーバーのアドレスで構成されます。このサブオプションを実装するリレーエージェントには、各サーバーのアルゴリズム番号と、適切な資格情報（つまり、キー）が必要です。リレーの実装は、すべてのリレーメッセージには認証サブオプションを含める必要があることを示す構成をサポートする必要があります。認証サブオプションの使用は、デフォルトで無効にする必要があります。リレーエージェントは、特定の宛先サーバーが認証サブオプションをサポートし、他のサーバーがそうでないことを示す構成をサポートする場合があります。リレーエージェントは、すべてのDHCPサーバーで使用する単一のアルゴリズム番号とキーの構成をサポートする場合があります。また、各サーバーの異なるアルゴリズムとキーの構成をサポートする場合があります。
There are network configurations in which one relay agent adds the relay agent option and then forwards the DHCP message to another relay agent. For example, a layer-2 switch might be directly connected to a client, and it might forward messages to an aggregating router, which sets giaddr and then forwards the message to a DHCP server. When a DHCP relay that implements the Authentication suboption receives a message, it MAY use the procedures in section 9 to verify the source of the message before forwarding it.
1つのリレーエージェントがリレーエージェントオプションを追加し、DHCPメッセージを別のリレーエージェントに転送するネットワーク構成があります。たとえば、レイヤー2スイッチがクライアントに直接接続されている場合があり、メッセージを集約するルーターに転送し、GIADDRを設定し、メッセージをDHCPサーバーに転送する場合があります。認証サブオプションを実装するDHCPリレーがメッセージを受信すると、セクション9の手順を使用して、メッセージのソースを確認する前に検証できます。
When the relay agent receives a broadcast packet from a client, it determines which DHCP servers (or other relay agents) should receive copies of the message. If the relay agent is configured to include the Authentication suboption, it determines which Algorithm and RDM to use, and then it performs the steps in section 8.
リレーエージェントがクライアントからブロードキャストパケットを受信すると、どのDHCPサーバー（または他のリレーエージェント）がメッセージのコピーを受信するかを決定します。リレーエージェントが認証サブオプションを含めるように構成されている場合、使用するアルゴリズムとRDMを決定し、セクション8の手順を実行します。
When the relay agent receives a message, it determines from its configuration whether it expects the message to contain a relay agent information option and an Authentication suboption. The relay agent MAY be configured to drop response messages that do not contain the Authentication suboption. The relay agent then follows the procedures in section 9.
リレーエージェントがメッセージを受信すると、メッセージにリレーエージェント情報オプションと認証サブオプションが含まれることを期待するかどうかを構成から決定します。リレーエージェントは、認証サブオプションを含まない応答メッセージをドロップするように構成されている場合があります。次に、リレーエージェントはセクション9の手順に従います。
DHCP servers may interact with multiple relay agents. Server implementations MAY support a configuration that associates the same algorithm and key with all relay agents. Servers MAY support a configuration that specifies the algorithm and key to use with each relay agent individually.
DHCPサーバーは、複数のリレーエージェントと対話する場合があります。サーバーの実装は、同じアルゴリズムとキーをすべてのリレーエージェントと関連付ける構成をサポートする場合があります。サーバーは、各リレーエージェントで個別に使用するアルゴリズムとキーを指定する構成をサポートする場合があります。
When a DHCP server that implements the Authentication suboption receives a message, it performs the steps in section 9.
認証サブオプションを実装するDHCPサーバーがメッセージを受信すると、セクション9の手順を実行します。
When the server has prepared a reply message, it uses the incoming request message and its configuration to determine whether it should include a relay agent information option and an Authentication suboption. If the server is configured to include the Authentication suboption, it determines which Algorithm and RDM to use and then performs the steps in section 8.
サーバーが返信メッセージを作成すると、着信要求メッセージとその構成を使用して、リレーエージェント情報オプションと認証サブオプションを含める必要があるかどうかを判断します。サーバーが認証サブオプションを含めるように構成されている場合、使用するアルゴリズムとRDMを決定し、セクション8の手順を実行します。
DISCUSSION: This server behavior represents a slight variance from RFC 3046 [1], section 2.2. The Authentication suboption is not echoed back from the server to the relay; the server generates its own suboption.
ディスカッション：このサーバーの動作は、RFC 3046 [1]、セクション2.2からのわずかなばらつきを表しています。認証サブオプションは、サーバーからリレーに反映されていません。サーバーは独自のサブオプションを生成します。
Section 4 defines a new suboption for the DHCP relay agent option called the Authentication Suboption. IANA has allocated a new suboption code from the relay agent option suboption number space.
セクション4では、認証サブオプションと呼ばれるDHCPリレーエージェントオプションの新しいサブオプションを定義します。IANAは、リレーエージェントオプションサブオプション番号スペースから新しいサブオプションコードを割り当てました。
This specification introduces two new number spaces for the Authentication suboption's 'Algorithm' and 'Replay Detection Method' fields. These number spaces have been created and will be maintained by IANA.
この仕様では、認証サブオプションの「アルゴリズム」と「リプレイ検出方法」フィールドに2つの新しい数値スペースを紹介します。これらの数字スペースは作成されており、IANAによって維持されます。
The Algorithm identifier is a one-byte value. The Algorithm value 0 is reserved. The Algorithm value 1 is assigned to the HMAC-SHA1 keyed hash, as defined in section 7.1. Additional algorithm values will be allocated and assigned through IETF consensus, as defined in RFC 2434 [5].
アルゴリズム識別子は1バイト値です。アルゴリズム値0は予約されています。アルゴリズム値1は、セクション7.1で定義されているように、HMAC-SHA1キー付きハッシュに割り当てられます。RFC 2434 [5]で定義されているように、追加のアルゴリズム値はIETFコンセンサスを通じて割り当てられ、割り当てられます。
The RDM identifier is a four-bit value. The RDM value 0 is reserved. The RDM value 1 is assigned to the use of a monotonically increasing counter value, as defined in section 5. Additional RDM values will be allocated and assigned through IETF consensus, as defined in RFC 2434 [5].
RDM識別子は4ビット値です。RDM値0は予約されています。RDM値1は、セクション5で定義されているように、単調に増加するカウンター値の使用に割り当てられます。RFC2434[5]で定義されているように、追加のRDM値はIETFコンセンサスによって割り当てられ、割り当てられます。
This specification describes a protocol that adds source authentication and message integrity protection to the messages between DHCP relay agents and DHCP servers.
この仕様は、DHCPリレーエージェントとDHCPサーバー間のメッセージにソース認証とメッセージの整合性保護を追加するプロトコルについて説明します。
The use of this protocol imposes a new computational burden on relay agents and servers, because they must perform cryptographic hash calculations when they send and receive messages. This burden may add latency to DHCP message exchanges. Because relay agents are involved when clients reboot, periods of very high reboot activity will result in the largest number of messages that have to be processed. During a cable MSO head-end reboot event, for example, the time required for all clients to be served may increase.
このプロトコルを使用すると、リレーエージェントとサーバーに新しい計算負担が課されます。これは、メッセージを送信および受信するときに暗号化ハッシュ計算を実行する必要があるためです。この負担は、DHCPメッセージ交換に遅延を追加する可能性があります。クライアントが再起動するとリレーエージェントが関与するため、非常に高い再起動アクティビティの期間は、処理する必要があるメッセージの数が最も多くなります。たとえば、ケーブルMSOヘッドエンドの再起動イベントでは、すべてのクライアントにサービスを提供するのに必要な時間が増える可能性があります。
The Authentication suboption contains a four-byte Key ID, following the example of the DHCP Authentication RFC. Other authentication protocols, such as DNS TSIG [10], use a key name. A key name is more flexible and potentially more human readable than a key id. DHCP servers may well be configured to use key names for DNS updates using TSIG, so it might simplify DHCP server configuration if some of the key management for both protocols could be shared.
認証サブオプションには、DHCP認証RFCの例に従って、4バイトキーIDが含まれています。DNS TSIG [10]などの他の認証プロトコルは、キー名を使用します。キー名は、キーIDよりも柔軟で潜在的に人間の読み取り可能です。DHCPサーバーは、TSIGを使用してDNSアップデートにキー名を使用するように設定される場合があります。そのため、両方のプロトコルのキー管理の一部を共有できる場合、DHCPサーバー構成を簡素化する可能性があります。
On the other hand, it is crucial to minimize the size expansion caused by the introduction of the relay agent information option. Named keys would require more physical space and would entail more complex suboption encoding and parsing implementations. These considerations have led us to specify a fixed-length Key ID instead of a variable-length key name.
一方、リレーエージェント情報オプションの導入によって引き起こされるサイズの拡張を最小限に抑えることが重要です。名前のキーには、より多くの物理的なスペースが必要であり、より複雑なサブオプションエンコードと解析の実装が必要です。これらの考慮事項により、可変長キー名の代わりに、固定長のキーIDを指定するようになりました。
Because DHCP is a UDP protocol, messages between relays and servers may be delivered in an order different from that in which they were generated. The replay-detection mechanism will cause receivers to drop packets that are delivered 'late', leading to client retries. The retry mechanisms that most clients implement should not cause this to be an enormous issue, but it will cause senders to do computational work which will be wasted if their messages are re-ordered.
DHCPはUDPプロトコルであるため、リレーとサーバーの間のメッセージは、生成されたものとは異なる順序で配信される場合があります。リプレイ検出メカニズムにより、受信機は「遅く」提供されるパケットをドロップし、クライアントの再試行につながります。ほとんどのクライアントが実装する再試行メカニズムは、これを大きな問題にするべきではありませんが、送信者にメッセージが再注文された場合に無駄になる計算作業を行うことになります。
The DHC WG has developed two documents describing authentication of DHCP relay agent options to accommodate the requirements of different deployment scenarios: this document and "Authentication of Relay Agent Options Using IPsec" [11]. As we note in section 11, the Authentication suboption can be used without pairwise keys between each relay and each DHCP server. In deployments where IPsec is readily available and pairwise keys can be managed efficiently, the use of IPsec as described in that document may be appropriate. If IPsec is not available or there are multiple relay agents for which multiple keys must be managed, the protocol described in this document may be appropriate. As is the case whenever two alternatives are available, local network administration can choose whichever is more appropriate. Because the relay agents and the DHCP server are all in the same administrative domain, the appropriate mechanism can be configured on all interoperating DHCP server elements.
DHC WGは、さまざまな展開シナリオの要件に対応するためのDHCPリレーエージェントオプションの認証を説明する2つのドキュメントを開発しました。このドキュメントと「IPSECを使用したリレーエージェントオプションの認証」[11]。セクション11で注意するように、認証サブオプションは、各リレーと各DHCPサーバーの間にペアワイズキーなしで使用できます。IPSECが容易に利用可能で、ペアワイズキーを効率的に管理できる展開では、そのドキュメントで説明されているようにIPSECの使用が適切かもしれません。IPSECが利用できない場合、または複数のキーを管理する必要がある複数のリレーエージェントがある場合、このドキュメントで説明されているプロトコルが適切な場合があります。2つの選択肢が利用可能な場合はいつでも、ローカルネットワーク管理がより適切なものを選択できます。リレーエージェントとDHCPサーバーはすべて同じ管理ドメインにあるため、適切なメカニズムはすべての挿入DHCPサーバー要素で構成できます。
The need for this specification was made clear by comments made by Thomas Narten and John Schnizlein, and the use of the DHCP Authentication option format was suggested by Josh Littlefield, at IETF 53.
この仕様の必要性は、Thomas NartenとJohn Schnizleinが行ったコメントによって明らかにされ、DHCP認証オプション形式の使用がIETF 53でJosh Littlefieldによって提案されました。
[1] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[1] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[4] Eastlake 3rd、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[6] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[7] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[7] Croft、W。およびJ. Gilmore、「Bootstrap Protocol」、RFC 951、1985年9月。
[8] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993.
[8] Wimer、W。、「ブートストラッププロトコルの説明と拡張」、RFC 1542、1993年10月。
[9] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[9] Droms、R。およびW. Arbaugh、「DHCPメッセージの認証」、RFC 3118、2001年6月。
[10] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[10] Vixie、P.、Gudmundsson、O.、Eastlake 3rd、D。、およびB. Wellington、「DNSのシークレットキートランザクション認証」、RFC 2845、2000年5月。
[11] Droms, R., "Authentication of Relay Agent Options Using IPsec", Work in Progress, February 2004.
[11] DROMS、R。、「IPSECを使用したリレーエージェントオプションの認証」、2004年2月、進行中の作業。
Authors' Addresses
著者のアドレス
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Mark Stapp Cisco Systems、Inc。1414 Massachusetts Ave. Boxborough、MA 01719 USA
Phone: 978.936.0000 EMail: mjs@cisco.com
電話：978.936.0000メール：mjs@cisco.com
Ted Lemon Nominum, Inc. 950 Charter St. Redwood City, CA 94063 USA
Ted Lemon Nominum、Inc。950 Charter St. Redwood City、CA 94063 USA
EMail: Ted.Lemon@nominum.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。