DHCPv6 のセキュリティ (調査と解説)

DHCPv6 を悪用した攻撃と，それに対する対処法などについてのべる．

DHCPv6 を悪用した攻撃

IPv4 と同様に IPv6 においても DHCP の機能を悪用した攻撃が可能である．つぎのような攻撃手段に注意をはらう必要がある [Hag 07]．

外部の未知の DHCP サーバが不正なアドレスを DHCP クライアントにわりあてる．
イントラネット上の誤設定された DHCP サーバまたは悪意で設定された DHCP サーバが不正なアドレスや不正な設定情報を DHCP クライアントにわりあてる．
企業ネットワークに接続した外部の未知の DHCP クライアントが，内部アドレスを取得する．
悪意をもつクライアントが意図的に IP アドレスを枯渇させることによって，正当なクライアントが有効な IP アドレスや設定オプションを入手できなくなる．
悪意をもつクライアントが DHCP サーバが (DDoS 攻撃 (分散サービス妨害攻撃) などの方法によって) 正当な要求を処理できなくなるほどの大量の要求を送信する．

DHCPv6 に関しては DHCPv4 より攻撃をさける手段がゆたかにある．

DHCP メッセージ認証の概要

DHCPv6 メッセージの認証には認証オプション (オプション番号 11) を使用する．認証オプションがはこぶ認証情報から DHCP メッセージの生成元を確実に識別することができる，また DHCP メッセージの内容が改竄されていないことを確認することができる．

認証オプションにおいては各種の認証プロトコルを使用することができる． RFC 3315 においては，つぎのような認証プロトコルを規定している．

遅延型認証プロトコル (Delayed Authentication Protocol)
再設定用鍵認証プロトコル (Reconfigure Key Authentication Protocol)

他にもさまざまなプロトコルが提案されている．

DHCP メッセージ認証の詳細

この節の内容は RFC 3315 による．また，Ishida So による翻訳を参考にした．

ネットワーク管理者は DHCP メッセージの送信元と内容の認証を供給することを望むかもしれない．例えば，クライアントはにせの DHCP サーバによるサービス妨害攻撃の適用を受けているかもしれないし，あるいは悪意なく設置された DHCP サーバのために設定誤りになるかもしれない．無線ネットワークや大学寮のようなネットワーク・メディアが物理的に安全に保たれない「敵対的」環境で，ネットワーク管理者がサービス妨害攻撃を避けるためにアドレスわりあてを認証されたホストに限定することを望むかもしれない．

DHCPv6 の認証機構は DHCPv4 の認証の設計に基づいている．

サーバとリレー・エージェント間で送られるメッセージのセキュリティ

安全にメッセージを交換するリレー・エージェントとサーバが IPv6 の IPsec メカニズムを使用する．もしクライアント・メッセージが多数のリレー・エージェントを通して中継されるなら，リレー・エージェントのそれぞれが独立に，区間ごとの信頼関係の認証をしたに違いない．すなわち，もしクライアント C からのメッセージがリレー・エージェント A とリレー・エージェント B で中継され次にサーバ届くなら，リレー・エージェント A と B がメッセージ交換に IPsec を使うように設定されならならず，そしてリレー・エージェント B とサーバはメッセージ交換に IPsec を使うように設定されなくてはならない．

リレー・エージェントとサーバ間あるいはリレー・エージェントとリレー・エージェント間の安全な通信をサポートするリレー・エージェントとサーバは次の状態で IPsec を使用する．

セレクタ: リレー・エージェントが DHCP メッセージが転送されるはずのリレー・エージェントあるいはサーバのアドレスに手動設定される． IPsec を DHCP メッセージの安全に使っているそれぞれのリレー・エージェントとサーバは，メッセージを返すリレー・エージェントのリストで設定されなくてはならない．リレー・エージェントとサーバのセレクタは，DHCPv6 UDPポート 546 と 547 上で DHCP メッセージを交換するリレー・エージェントとサーバを定義する対のアドレスとなるだろう．
モード: リレー・エージェントとサーバがトランスポート・モードと ESP を使用する． DHCP メッセージの情報は通常は秘密だとはかんがえられないので，暗号をつかう必要はない (すなわち，NULL 暗号を使うことができる)．
鍵管理: リレー・エージェントとサーバが組織の中で使われるので，公開鍵は不要である．リレー・エージェントとサーバが手作業で構成されなくてはならないから，手作業で構成された鍵管理で十分かもしれないが，メッセージ再送攻撃に対して防御されない．したがって，事前共有秘密鍵の IKE がサポートされるべきである (SHOULD)．公開鍵の IKE がサポートされるかもしれない (MAY)．
セキュリティ・ポリシー: リレー・エージェントとサーバ間の DHCP メッセージが，ローカル設定で識別される DHCP の相手からだけ受け入れられるべきである．
認証: 共有鍵は受信 DHCP メッセージの送信元 IP アドレスで識別され，このアプリケーションに適切である．
利用可能性: 適切な IPsec 実装は，企業とコア ISP ネットワークで使う装置において使用する高機能のサーバとリレー・エージェントにおいて利用できる可能性が高い． IPsec がホームや小オフィスの市場で主に使われる低レベル装置におけるリレー・エージェントに利用できる可能性は低い．

DHCP 認証の要約

DHCP メッセージ認証は認証オプションの使用を通して達成される．認証オプションによって運ばれる認証情報は信頼できるように DHCP メッセージの送信元を識別し，DHCP メッセージの内容が不法に変更されなかったことを確認するために使うことができる．

認証オプションは多数の認証プロトコルに枠組みを提供する． 2 つのプロトコルがここで定義される．将来定義される他のプロトコルが別の文書で指定されるだろう．

DHCP メッセージは 2 つ以上の認証オプションを含んではならない (MUST NOT)．

認証オプションにおいて，

プロトコル・フィールドはオプションで運んだ認証情報を生成するために使われた特定のプロトコルを識別する．
アルゴリズム・フィールドは認証プロトコルの中で特定のアルゴリズムを識別する．たとえば，アルゴリズム・フィールドは認証オプションのメッセージ認証コード (MAC) を生成するために使われたハッシュ・アルゴリズムを指定する．
リプレイ検知方法 (RDM, replay detection method) フィールドはリプレイ検知フィールドで使われたリプレイ攻撃発見の種別を指定する．

リプレイ検知

リプレイ検知方法 (RDM) フィールドはリプレイ検知フィールドで使われたリプレイ検知の発見の型を決定する．

もし RDM フィールドの値が 0x00 なら，リプレイ検知フィールドは一様に増加するカウンター値が設定されなくてはならない (MUST)．現在の時刻のようなカウンター値 (たとえば NTP フォーマット時刻スタンプ) を使うことはリプレイ攻撃の危険を減らすことができる．この方法はすべてのプロトコルでサポート支援されなくてはならない (MUST)．

遅延型認証プロトコル

もしプロトコル・フィールドが 2 であるなら，メッセージは「遅延型認証」メカニズムを使っている．遅延型認証においては，クライアントはその要請メッセージによって認証を求め，サーバは認証情報を含む広告メッセージによって応答する．この認証情報はメッセージ認証とエンティティー認証を供給するためにメッセージ認証コード (MAC) として送信元によって生成された一時的な値を含んでいる．

MD5 ハッシュを使用する HMAC プロトコルに基づく特定の技法の使用法はここで定義される．

遅延型認証プロトコルにおける認証オプションの使用法

要請メッセージにおいて，クライアントはクライアントの好みにしたがって認証オプションのプロトコルとアルゴリズムと 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: HMAC-MD5 値を生成するために使われた鍵を識別する DHCP 領域．
Key ID: HMAC-MD5 値を生み出した鍵を識別するために使われる鍵識別子．
HMAC-MD5: MD5 において，DHCP 領域よクライアント DUID と鍵識別子で識別された鍵を，DHCP メッセージに適用して生成されたメッセージ認証コード．

送信者は HMAC 生成アルゴリズムと MD5 ハッシュ関数を使って MAC を計算する． (認証オプションの MAC フィールドをゼロに設定している) 全部の DHCP メッセージは，DHCP メッセージヘッダとオプションフィールドを含めて，HMAC-MD5 計算関数への入力として用いられる．

論議：

アルゴリズム 1 が HMAC-MD5 の使用を指定する． HMAC-SHA のような他の技法の使用は別のプロトコルとして定義されるであろう．

認証鍵を識別するために使われた DHCP 領域は管理ドメイン間で一意になるように選択される． DHCP 領域の使用は鍵識別子の使用で DHCP 管理者の対立を避けることを許し，そして DHCP を使うホストが，DHCP 間で管理ドメインを歩き回る間に，本物と証明された DHCP を使うことを許す．

メッセージ検証

2 つ以上の認証オプションを含む DHCP メッセージは捨てられなくてはならない (MUST)．

入りメッセージを有効にするために，受信者は最初にリプレイ検知フィールドの中の値が RDM フィールドによって指定されるリプレイ検知方法によって許容できるかどうかを調べる．つぎに，受信者は RFC 2104 に記述されているようにして，MAC を計算する． (認証オプションの MAC フィールドを 0 に設定している) 全部の DHCP メッセージは，HMAC-MD5 計算関数の入力として用いられる．もし受信者が計算した MAC が認証オプションに含まれる MAC と一致しないなら，受信者は DHCP メッセージを捨てなくてはならない (MUST)．

鍵使用

それぞれの DHCP クライアントが鍵集合を持っている．それぞれの鍵がつぎの形式のデータによって識別される．

＜DHCP 領域，クライアント DUID，鍵識別子＞

それぞれの鍵は同じ寿命を持つ．鍵はその寿命の終わりを過ぎたら使われなくなるかもしれない．クライアントの鍵は何らかの外部メカニズムを通してはじめにクライアントに配布される．それぞれの鍵のための寿命は鍵と共に配布される．鍵配布と寿命仕様のメカニズムについてはここでは記述しない．

クライアントとサーバは (クライアントが次の要請メッセージを送信するまで) セッションの間に DHCP メッセージを本物と証明するためにクライアントの鍵の 1 つを使用する．

遅延型認証プロトコルに対するクライアント考慮

クライアントは要請メッセージに認証オプションを含めることによって DHCP 認証を使う意向を示す．サーバはクライアントの DUID に基づいてクライアントの鍵を選択する．クライアントとサーバはすべてのセッションの間に交換された DHCP メッセージが本物であることを証明するためにその鍵を使用する．

要請メッセージ送信: クライアントが要請メッセージを送り，認証を使うことを望む時，遅延型認証プロトコルの節において記述された望ましいプロトコルとアルゴリズムと RDM を含む認証オプションを含める．クライアントは認証オプションにリプレイ検知あるいは認証情報を含めない．
広告メッセージ受信: クライアントはメッセージ検証の節において記述した検証テストを使用して，遅延型認証プロトコルを指定する認証オプションを含んでいる広告メッセージを検証する．
広告メッセージが認証情報を含まないかまたは承認テストに合格する場合のクライアント動作はクライアントの局所ポリシーによって制御される．クライアント・ポリシーによっては，クライアントは本物と証明されなかった広告メッセージに返答することに決めてもよい (MAY)．
局所ポリシーで本物と証明されていないメッセージを受け入れることにきめる決断は注意ぶかくなされるべきである．本物と証明されていない広告メッセージを受け入れると，クライアントはなりすましと他の攻撃をうけやすくなる．もしローカル・ユーザが明示的にクライアントが本物と証明されていない広告メッセージ受け入れたということを知らせられないなら，ユーザはまちがってクライアントが本物と証明されたアドレスを受け取り，そして本物と証明されていないメッセージを通して DHCP 攻撃の適用を受けていないと想定してもよい．
クライアントが本物と証明されていないメッセージを捨てる設定が可能でなければならず (MUST)，そして既定ではもしクライアントが認証鍵や他の認証情報で構成されたなら，本物と証明されていないメッセージを捨てるように設定されるべきである (SHOULD)．クライアントが認証情報がない広告メッセージと承認テストに合格しない広告メッセージをを区別することに決めてもよい(MAY)．たとえば，クライアントが前者を受け入れて後者を捨てるかもしれない．もしクライアントが本物と証明されていないメッセージを受け入れるなら，クライアントはローカル・ユーザに知らせるべきであって (SHOULD)，そしてイベントをログ・ファイルに書くべきである (SHOULD)．
要求，確認，更新，再結合，辞退，解放メッセージの送信: もしクライアントが選んだサーバの広告メッセージをクライアントが本物と証明したなら，クライアントはサーバへ送る次の要求か確認か更新か再結合か辞退か解放メッセージのために，遅延型認証プロトコルの節において記述されるように，認証情報を生成しなくてはならない (MUST)．クライアントが次のメッセージを送る時，認証情報を生み出すためにサーバによって使われたのと同じ鍵を使わなくてはならない (MUST)．
情報要求メッセージ送信: もしサーバが前のメッセージ交換でクライアントの鍵を選択したなら (要請メッセージ受信と広告メッセージ送信の節を参照)，クライアントはセッションを通じて認証情報を生成するために同じ鍵を使わなくてはならない (MUST)．
応答メッセージ受信: もしクライアントが受信した広告を認証したなら，クライアントはサーバからの関連した応答メッセージを有効にしなくてはならない (MUST)．もしメッセージが検証試験に失敗したらクライアントは応答を捨てなければならず (MUST)，検証が失敗したことをログ・ファイルに書いてもよい (MAY)．もし応答が検証試験に失敗するなら，クライアントは要請メッセージを送ることによって DHCP 設定処理を再開しなくてはならない (MUST)．
もしクライアントが認証情報を含まない広告メッセージを受信するかまたは検証試験に合格しなかったなら，クライアントはサーバからの本物と証明されていない応答メッセージを受け入れてもよい (MAY)．
再設定メッセージ受信: クライアントは，もしメッセージが認証試験に失敗したら再設定メッセージを捨てなくてはならない (MUST)．そして認証が失敗したことをログ・ファイルに書いてもよい (MAY)．

遅延型認証プロトコルに対するサーバの考慮

認証オプションを含んでいる要請メッセージを受け取った後で，サーバはクライアントの DUID と鍵選択ポリシーに基づいて，サーバに設定されたクライアントの鍵を選択する．サーバは広告メッセージで選択された鍵を識別し，そしてクライアントとサーバの間の次のメッセージを有効にするために鍵を使用する．

要請メッセージ受信と広告メッセージ送信: サーバはクライアントのために鍵を選択して，遅延型認証プロトコルの節において指定されるように，クライアントに返す広告メッセージに認証情報を含める．サーバはクライアントのために選択した鍵の識別子を記録し (MUST)，同じ鍵をクライアントとの後続のメッセージの検証に使用する．
要求と確認と更新と再結合と解放メッセージの受信と応答メッセージの送信: サーバはメッセージ検証の節において指定されるようにメッセージで識別鍵を使用し，メッセージを有効にする．もしメッセージが認証試験に失敗するかサーバが「鍵識別子 (ID)」フィールドで識別された鍵を知らないなら，サーバはメッセージを捨てなくてはならず (MUST)，認証障害をログ・ファイルに書くことに決めてもよい (MAY)．
もしメッセージが認証試験に合格するなら，サーバは特定のメッセージで返答する．遅延型認証プロトコルの節において指定されるように，サーバは鍵を使って生成された認証情報を，受信メッセージに含めなくてはならない (MUST)．

再設定鍵認証プロトコル

再設定鍵認証プロトコルは悪意がある DHCP サーバが送った再設定メッセージによって発生したクライアントの設定誤りからクライアントを保護する．このプロトコルによって DHCP サーバが DHCP メッセージの最初の交換でクライアントに再設定鍵を送信する．クライアントはそのサーバからのつぎの再設定メッセージの確認のために再設定鍵を記録する．サーバはつぎの再設定メッセージに再設定鍵から計算された HMAC を含める．

サーバからクライアントに送られた再設定鍵と後続の再設定メッセージの HMAC の両方が認証情報として認証オプションによって運ばれる．認証情報の形式は次節において定義される．

クライアントとサーバが (サーバによって始められた) 他のいかなる認証プロトコルも使っていなければ，再設定鍵プロトコルが使用される．クライアントとサーバは再設定メッセージを使うために交渉する．

再設定鍵認証プロトコルでの認証オプションの使用

次のフィールドは認証オプションで再設定鍵認証プロトコルを設定する：

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

フィールドで定義されたデータ．

再設定鍵プロトコルに対するサーバの考慮

サーバは要求 / 応答や要請 / 応答や情報要求 / 応答メッセージ交換の間にクライアントのために再設定鍵を選択する．サーバは再設定鍵を記録し，応答メッセージの認証オプションでクライアントにその鍵を伝達する．

再設定鍵としては，長さ 128 ビットで容易に予測されない暗号的に強い乱数あるいは疑似乱数を使用しなければならない (MUST)．

再設定メッセージの認証を提供するために，サーバが選択する RDM に従ってサーバはリプレイ検知値を選択し，クライアントの再設定鍵を使用して再設定メッセージの HMAC-MD5 を計算する．サーバは全部の DHCP 再設定メッセージ上で，認証オプションを含めて HMAC-MD5 を計算する．認証オプションにおける HMAC-MD5 フィールドは HMAC-MD5 計算の際にはゼロに設定される．サーバはクライアントに送った再設定メッセージが含む認証オプションの認証情報フィールドに HMAC-MD5 を含める．

再設定鍵プロトコルに対するクライアントの考慮

クライアントはサーバからの最初の応答メッセージで再設定鍵を受け取る．クライアントはつぎの再設定メッセージを本物と証明する際に使用するために再設定鍵を記録する．

再設定メッセージを本物と証明するために，クライアントはサーバから受け取った再設定鍵を使っている DHCP 再設定メッセージ上の HMAC-MD5 を計算する．もし HMAC-MD5 が認証オプション値に一致すると計算したなら，クライアントは再設定メッセージを受け入れる．

リレー・エージェント - DHCP サーバ間通信のセキュリティ

リレー・エージェントと DHCP サーバとのあいだのメッセージ交換をセキュアにおこなうには，IPsec (ESP をもちいたトランスポート・モード) を使用する．リレー・エージェントとその通信相手とのあいだには，独立な双方向の信頼関係を樹立する必要がある．メッセージ内容が守秘性を必要としなければ暗号化は必要ない．リレー・エージェントと DHCP サーバは信頼できるネットワーク内に設置されるものなので，秘密鍵を使用してもよい．

さらに，DHCP サーバとリレー・エージェントは信頼された通信ピアのアドレスを使用する．これによって未知の DHCP サーバやリレー・エージェントによる通信へのわりこみが不可能になる．

参考文献

[Hag 07] Silvia Hagen, “IPv6Essentials, Second Edition”, O'Reilly, 2007. (邦訳: 市原英也監訳, “IPv6 エッセンシャルズ第 2 版”, オライリー・ジャパン, 2007).

Keywords: 再送攻撃, 再生攻撃, 再送検知, 再生検知, 再送検出, 再生検出, リプレイ検知, リプレイ検出

調査と解説