メインコンテンツまでスキップ

21. Authentication of DHCP Messages (DHCPメッセージの認証)

21. Authentication of DHCP Messages (DHCPメッセージの認証)​

一部のネットワーク管理者は、DHCPメッセージの送信元と内容の認証を提供したい場合があります。たとえば、クライアントは、偽のDHCPサーバーの使用によるサービス拒否攻撃の対象となる可能性があります。または、意図せずインスタンス化されたDHCPサーバーによって単純に誤って構成される可能性があります。ネットワーク管理者は、「敵対的」環境 (ワイヤレスネットワークや大学の寮など) でのサービス拒否攻撃を回避するために、承認されたホストへのアドレス割り当てを制限したい場合があります。この環境では、ネットワーク媒体が物理的に保護されていません。

DHCP認証メカニズムは、DHCPv4 [4] の認証設計に基づいています。

21.1. Security of Messages Sent Between Servers and Relay Agents (サーバーとリレーエージェント間で送信されるメッセージのセキュリティ)​

メッセージを安全に交換するリレーエージェントとサーバーは、IPv6 [7] のIPsecメカニズムを使用します。クライアントメッセージが複数のリレーエージェントを介してリレーされる場合、各リレーエージェントは独立したペアの信頼関係を確立する必要があります。つまり、クライアントCからのメッセージがリレーエージェントAによってリレーエージェントBにリレーされ、その後サーバーにリレーされる場合、リレーエージェントAとBはIPSecを使用してメッセージを交換するように構成する必要があり、リレーエージェントBとサーバーはIPSecを使用してメッセージを交換するように構成する必要があります。

安全なリレーエージェントからサーバー、またはリレーエージェントからリレーエージェントへの通信をサポートするリレーエージェントとサーバーは、以下の条件下でIPsecを使用します:

セレクター (Selectors)
リレーエージェントは、DHCPメッセージが転送されるリレーエージェントまたはサーバーのアドレスを手動で構成します。DHCPメッセージを保護するためにIPsecを使用する各リレーエージェントとサーバーは、メッセージが返されるリレーエージェントのリストも構成する必要があります。リレーエージェントとサーバーのセレクターは、DHCPv6 UDPポート546と547でDHCPメッセージを交換するリレーエージェントとサーバーを定義するアドレスペアになります。

モード (Mode)
リレーエージェントとサーバーは、トランスポートモードとESPを使用します。DHCPメッセージ内の情報は一般に機密と見なされないため、暗号化を使用する必要はありません (つまり、NULL暗号化を使用できます)。

キー管理 (Key management)
リレーエージェントとサーバーは組織内で使用されるため、公開鍵スキームは必要ありません。リレーエージェントとサーバーは手動で構成する必要があるため、手動で構成されたキー管理で十分な場合がありますが、リプレイメッセージに対する防御は提供しません。したがって、事前共有シークレットを使用するIKEをサポートする必要があります。公開鍵を使用するIKEをサポートできます。

セキュリティポリシー (Security policy)
リレーエージェントとサーバー間のDHCPメッセージは、ローカル構成で識別されたDHCPピアからのメッセージのみを受け入れる必要があります。

認証 (Authentication)
受信したDHCPメッセージの送信元IPアドレスにインデックス付けされた共有キーは、このアプリケーションで十分です。

可用性 (Availability)
適切なIPsec実装は、サーバーと、エンタープライズおよびコアISPネットワークで使用されるより機能豊富なデバイス内のリレーエージェントで利用できる可能性があります。IPsecは、主に家庭または小規模オフィス市場で使用される低エンドデバイス内のリレーエージェントでは利用できない可能性があります。

21.2. Summary of DHCP Authentication (DHCP認証の要約)​

DHCPメッセージの認証は、認証オプション (セクション22.11を参照) の使用を通じて実現されます。認証オプションで運ばれる認証情報は、DHCPメッセージの送信元を信頼性高く識別し、DHCPメッセージの内容が改ざんされていないことを確認するために使用できます。

認証オプションは、複数の認証プロトコルのフレームワークを提供します。ここでは、そのような2つのプロトコルが定義されています。将来定義される他のプロトコルは、別の文書で指定されます。

任意のDHCPメッセージには、複数の認証オプションを含めてはなりません。

認証オプション内のプロトコルフィールドは、オプションで運ばれる認証情報を生成するために使用される特定のプロトコルを識別します。アルゴリズムフィールドは、認証プロトコル内の特定のアルゴリズムを識別します。たとえば、アルゴリズムフィールドは、認証オプション内のメッセージ認証コード (MAC) を生成するために使用されるハッシュアルゴリズムを指定します。リプレイ検出方法 (RDM) フィールドは、リプレイ検出フィールドで使用されるリプレイ検出のタイプを指定します。

21.3. Replay Detection (リプレイ検出)​

リプレイ検出方法 (RDM) フィールドは、リプレイ検出フィールドで使用されるリプレイ検出のタイプを決定します。

RDMフィールドに0x00が含まれている場合、リプレイ検出フィールドは単調に増加するカウンターの値に設定する必要があります。カウンター値 (たとえば、現在の時刻 (NTP形式のタイムスタンプ [9])) の使用は、リプレイ攻撃の危険性を減らすことができます。すべてのプロトコルは、この方法をサポートする必要があります。

21.4. Delayed Authentication Protocol (遅延認証プロトコル)​

プロトコルフィールドが2の場合、メッセージは「遅延認証」メカニズムを使用します。遅延認証では、クライアントがリクエストメッセージで認証を要求し、サーバーが認証情報を含むアドバタイズメッセージで応答します。この認証情報には、メッセージ認証コード (MAC) として送信元によって生成されたランダム値が含まれ、メッセージ認証とエンティティ認証を提供します。

ここでは、MD5ハッシュ [16] を使用するHMACプロトコル [8] に基づく特定の技術の使用が定義されています。

21.4.1. Use of the Authentication Option in the Delayed Authentication Protocol (遅延認証プロトコルでの認証オプションの使用)​

ソリシットメッセージでは、クライアントは認証オプションにプロトコル、アルゴリズム、およびRDMフィールドを入力し、クライアントの好みを使用します。クライアントはリプレイ検出フィールドをゼロに設定し、認証情報フィールドを省略します。クライアントはオプション長フィールドを11に設定します。

他のすべてのメッセージでは、プロトコルとアルゴリズムフィールドは、認証情報フィールドの内容を構築するために使用される方法を識別します。RDMフィールドは、リプレイ検出フィールドの内容を構築するために使用される方法を識別します。

認証情報の形式は次のとおりです:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          DHCP realm                           |
    |                      (variable length)                        |
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            key ID                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                           HMAC-MD5                            |
    |                          (128 bits)                           |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DHCP realm (DHCPレルム)
HMAC-MD5値を生成するために使用されるキーを識別するDHCPレルム。

key ID (キーID)
HMAC-MD5値を生成するために使用されるキーを識別するキー識別子。

HMAC-MD5
DHCPレルム、クライアントDUID、およびキーIDによって識別されるキーを使用して、DHCPメッセージにMD5を適用することによって生成されるメッセージ認証コード。

送信者は、HMAC生成アルゴリズム [8] とMD5ハッシュ関数 [16] を使用してMACを計算します。DHCPメッセージ全体 (認証オプションのMACフィールドをゼロに設定) は、HMAC-MD5計算関数への入力として使用されます。

討論 (DISCUSSION):

アルゴリズム1は、HMAC-MD5の使用を指定します。異なる技術 (たとえば、HMAC-SHA) の使用は、別のプロトコルとして指定されます。

認証キーを識別するために使用されるDHCPレルムは、管理ドメイン内で一意になるように選択されます。DHCPレルムの使用により、DHCP管理者はキー識別子の使用における衝突を回避でき、DHCPを使用するホストがDHCP管理ドメイン間をローミングする際に認証されたDHCPを使用できるようになります。

21.4.2. Message Validation (メッセージ検証)​

複数の認証オプションを含む任意のDHCPメッセージは破棄する必要があります。

受信メッセージを検証するために、受信者はまず、RDMフィールドで指定されたリプレイ検出方法に従って、リプレイ検出フィールド内の値が許容可能かどうかを確認します。次に、受信者は [8] で説明されている方法に従ってMACを計算します。DHCPメッセージ全体 (認証オプションのMACフィールドを0に設定) は、HMAC-MD5計算関数への入力として使用されます。受信者が計算したMACが認証オプションに含まれるMACと一致しない場合、受信者はDHCPメッセージを破棄する必要があります。

21.4.3. Key Utilization (キー利用)​

各DHCPクライアントには、キーのセットがあります。各キーは、<DHCPレルム、クライアントDUID、キーid>によって識別されます。各キーには有効期間もあります。キーは、その有効期間が終了した後は使用できません。クライアントのキーは、最初に何らかの帯域外メカニズムを通じてクライアントに配布されます。各キーの有効期間は、キーと共に配布されます。キー配布と有効期間仕様のメカニズムは、この文書の範囲を超えています。

クライアントとサーバーは、クライアントの1つのキーを使用して、セッション中 (クライアントが次のリクエストメッセージを送信するまで) のDHCPメッセージを認証します。

21.4.4. Client Considerations for Delayed Authentication Protocol (遅延認証プロトコルのクライアント考慮事項)​

クライアントは、ソリシットメッセージに認証オプションを含めることにより、DHCP認証を使用する意図を発表します。サーバーは、クライアントのDUIDに基づいてクライアントのキーを選択します。クライアントとサーバーは、そのキーを使用して、セッション中に交換されるすべてのDHCPメッセージを認証します。

21.4.4.1. Sending Solicit Messages (ソリシットメッセージの送信)​

クライアントがソリシットメッセージを送信し、認証を使用することを希望する場合、クライアントは、セクション21.4で説明されているように、必要なプロトコル、アルゴリズム、およびRDMを含む認証オプションを含めます。クライアントは、認証オプションにリプレイ検出または認証情報を含めません。

21.4.4.2. Receiving Advertise Messages (アドバタイズメッセージの受信)​

クライアントは、セクション21.4.2で説明されている検証テストを使用して、指定された遅延認証プロトコルの認証オプションを含む任意のアドバタイズメッセージを検証します。

認証情報を含まない、または検証テストに合格しないアドバタイズメッセージがない場合、クライアントの動作はクライアント上のローカルポリシーによって制御されます。クライアントポリシーに従って、クライアントは認証されていないアドバタイズメッセージに応答することを選択できます。

ローカルポリシーを設定して認証されていないメッセージを受け入れる決定は、慎重に行う必要があります。認証されていないアドバタイズメッセージを受け入れると、クライアントがスプーフィングやその他の攻撃に対して脆弱になる可能性があります。ローカルユーザーがクライアントが認証されていないアドバタイズメッセージを受け入れたことを明確に通知されていない場合、ユーザーはクライアントが認証されたアドレスを受信したと誤って想定し、認証されていないメッセージを通じたDHCP攻撃に対して脆弱でないと想定する可能性があります。

クライアントは、認証されていないメッセージを破棄するように構成可能である必要があり、クライアントが認証キーまたはその他の認証情報で構成されている場合、デフォルトで認証されていないメッセージを破棄するように構成する必要があります。クライアントは、認証情報のないアドバタイズメッセージと検証テストに合格しないアドバタイズメッセージを区別することを選択できます。たとえば、クライアントは前者を受け入れ、後者を破棄する場合があります。クライアントが認証されていないメッセージを受け入れる場合、クライアントは任意のローカルユーザーに通知し、イベントをログに記録する必要があります。

21.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release Messages (リクエスト、確認、更新、リバド、拒否、またはリリースメッセージの送信)​

クライアントがクライアントが選択したサーバーのアドバタイズメッセージを認証した場合、クライアントは、セクション21.4で説明されているように、サーバーに送信される後続のリクエスト、確認、更新、リバド、またはリリースメッセージの認証情報を生成する必要があります。クライアントが後続のメッセージを送信する場合、クライアントは、サーバーが認証情報を生成するために使用したのと同じキーを使用する必要があります。

21.4.4.4. Sending Information-request Messages (情報要求メッセージの送信)​

サーバーが以前のメッセージ交換でクライアントのキーを選択した場合 (セクション21.4.5.1を参照)、クライアントは、セッション全体で同じキーを使用して認証情報を生成する必要があります。

21.4.4.5. Receiving Reply Messages (リプライメッセージの受信)​

クライアントが受け入れたアドバタイズを認証した場合、クライアントはサーバーからの関連するリプライメッセージを検証する必要があります。メッセージが検証テストに合格しない場合、クライアントはリプライを破棄し、検証失敗をログに記録できます。リプライが検証テストに合格しない場合、クライアントはリクエストメッセージを送信することにより、DHCP構成プロセスを再開する必要があります。

クライアントが認証情報を含まない、または検証テストに合格しないアドバタイズメッセージを受け入れた場合、クライアントはサーバーからの認証されていないリプライメッセージを受け入れる場合があります。

21.4.4.6. Receiving Reconfigure Messages (再構成メッセージの受信)​

メッセージが検証テストに合格しない場合、クライアントは再構成を破棄し、検証失敗をログに記録できます。

21.4.5. Server Considerations for Delayed Authentication Protocol (遅延認証プロトコルのサーバー考慮事項)​

認証オプションを含むソリシットメッセージを受信すると、サーバーはクライアントのDUIDとサーバーが構成したキー選択ポリシーに基づいてクライアントのキーを選択します。サーバーは、クライアントに返されるアドバタイズメッセージでクライアントに選択されたキーを識別し、そのキーを使用してクライアントとサーバー間の後続のメッセージを検証します。

21.4.5.1. Receiving Solicit Messages and Sending Advertise Messages (ソリシットメッセージの受信とアドバタイズメッセージの送信)​

サーバーはクライアントのキーを選択し、セクション21.4で指定された方法でクライアントに返されるアドバタイズメッセージに認証情報を含めます。サーバーは、クライアントに選択されたキーの識別子を記録し、その同じキーを使用してクライアントとの後続のメッセージを検証する必要があります。

21.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages and Sending Reply Messages (リクエスト、確認、更新、リバド、またはリリースメッセージの受信とリプライメッセージの送信)​

サーバーは、メッセージで識別されたキーを使用し、セクション21.4.2で指定された方法でメッセージを検証します。メッセージが検証テストに合格しない場合、またはサーバーが「キーID」フィールドによって識別されるキーを知らない場合、サーバーはメッセージを破棄し、検証失敗をログに記録する場合があります。

メッセージが検証テストに合格した場合、サーバーはセクション18.2で説明されているように特定のメッセージに応答します。サーバーは、セクション21.4で指定されているように、受信メッセージで識別されたキーを使用して生成された認証情報を含める必要があります。

21.5. Reconfigure Key Authentication Protocol (再構成キー認証プロトコル)​

再構成キー認証プロトコルは、悪意のあるDHCPサーバーによって送信された再構成メッセージによるクライアントの誤構成に対する保護を提供します。このプロトコルでは、DHCPサーバーがDHCPメッセージの初期交換でクライアントに再構成キーを送信します。クライアントは再構成キーを記録し、そのサーバーからの後続の再構成メッセージを認証するために使用します。次に、サーバーは後続の再構成メッセージに再構成キーから計算されたHMACを含めます。

サーバーからクライアントに送信される再構成キーと後続の再構成メッセージ内のHMACは、どちらも認証オプション内の認証情報として運ばれます。認証情報の形式は、以下のセクションで定義されています。

再構成キープロトコルは、クライアントとサーバーが他の認証プロトコルを使用しておらず、クライアントとサーバーが再構成メッセージの使用を交渉した場合にのみ使用されます (サーバーによって開始)。

21.5.1. Use of the Authentication Option in the Reconfigure Key Authentication Protocol (再構成キー認証プロトコルでの認証オプションの使用)​

再構成キー認証プロトコルの認証オプションで以下のフィールドが設定されます:

  • protocol: 3
  • algorithm: 1
  • RDM: 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |                 Value (128 bits)              |
    +-+-+-+-+-+-+-+-+                                               |
    .                                                               .
    .                                                               .
    .                                               +-+-+-+-+-+-+-+-+
    |                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type (タイプ)
このオプションの値フィールドで運ばれるデータのタイプ:

  • 1: 再構成キー値 (リプライメッセージで使用)。
  • 2: メッセージのHMAC-MD5ダイジェスト (再構成メッセージで使用)。

Value (値)
フィールドによって定義されるデータ。

21.5.2. Server considerations for Reconfigure Key protocol (再構成キープロトコルのサーバー考慮事項)​

サーバーは、リクエスト/リプライ、リクエスト/リプライ、または情報要求/リプライメッセージ交換中にクライアントの再構成キーを選択します。サーバーは再構成キーを記録し、リプライメッセージの認証オプションでそのキーをクライアントに送信します。

再構成キーは128ビット長で、予測が容易でない、暗号学的に強力な乱数または疑似乱数である必要があります。

再構成メッセージの認証を提供するために、サーバーはサーバーが選択したRDMに従ってリプレイ検出値を選択し、クライアントの再構成キーを使用して再構成メッセージのHMAC-MD5を計算します。サーバーは、認証オプションを含むDHCP再構成メッセージ全体でHMAC-MD5を計算します。認証オプション内のHMAC-MD5フィールドは、HMAC-MD5計算でゼロに設定されます。サーバーは、クライアントに送信される再構成メッセージに含まれる認証オプションの認証情報フィールドにHMAC-MD5を含めます。

21.5.3. Client considerations for Reconfigure Key protocol (再構成キープロトコルのクライアント考慮事項)​

クライアントは、サーバーからの初期リプライメッセージからサーバーから再構成キーを受信します。クライアントは再構成キーを記録し、後続の再構成メッセージを認証するために使用します。

再構成メッセージを認証するために、クライアントはサーバーから受信した再構成キーを使用してDHCP再構成メッセージでHMAC-MD5を計算します。この計算されたHMAC-MD5が認証オプション内の値と一致する場合、クライアントは再構成メッセージを受け入れます。

に最終更新