要約

  • RFC 5201と後継のRFC 7401では、応答側はI1の後に事前計算済みR1を選び、関連固有の状態を持たないまま返信できる。署名は過去の生成主体を示すが、現在の生存や資源確保を示さない。
  • 有効I2による状態生成、R2検証によるベース交換完了、ペイロード関連の導入、アプリケーション応答は、それぞれ別の到達点である。

R1を返す理由は「まだ覚えない」ため

HIPのベース交換はI1、R1、I2、R2の四つで進む。I1は開始の合図であり、R1はパズル、応答側のDiffie–Hellman材料、選択肢、署名を運ぶ。I2は解答と開始側の認証材料を返し、R2が交換を完了させる。

ここで重要なのは、最初の返信が最初の状態生成とは限らないことだ。応答側は複数のR1を先に作っておき、I1の情報から一つを選べる。図中でも、R1を選んだ後の応答側は「stateless」のままである。HIPv2のRFC 7401にも同じ設計が残る。

狙いはDoS耐性である。送信元を偽装したI1ごとにメモリを確保し、公開鍵署名を検証し、共有秘密を計算すれば、攻撃者は小さな要求で大きな費用を押しつけられる。事前計算R1は、高価な処理を有効I2の後へ送る。

したがって、R1が短時間で返った事実は、応答経路が機能した可能性を示すにすぎない。個別セッションの存在を示さないことこそ、この経路の正しい動作である。

署名の時刻を勝手に作らない

R1署名は、応答側Host Identityの秘密鍵が対象部分を生成したことを検証可能にする。RFCの表現は慎重で、R1が応答側によって「一度生成された」ことを示す。事前計算され、I1固有の全情報を覆わないため、署名だけではリプレイを防げない。

測定点が持つ確かな時刻は、自分がそのバイト列を受信した時刻である。それはR1作成時刻でも、相手が今回のI1を処理した時刻でも、状態を予約した時刻でもない。

R1 generation counterは、より新しいパズル世代を選ぶための座標である。壁時計ではない。RFC 7401は再起動や状態喪失、カウンタの扱いを論じ、世界時刻同期を避けるためR1にtimestampを入れない選択も維持する。カウンタを秒に換算して「現在性」と表示してはならない。

受領記録には、HIT、署名検証、アルゴリズム、generation counter、パズルの寿命と難度、opaque値、本地の単調時刻を分けて残すべきだ。推定した鮮度には、推定規則と不確実性を付ける。

パズルが示すのは計算支出だけ

開始側は、挑戦値I、双方のHIT、候補Jを結合したハッシュが指定数のゼロ下位ビットを持つまで探索する。応答側は一回のハッシュで解答を検査できる。無効I2を、署名検証やDiffie–Hellmanの前に安く捨てられる。

RFC 5201はCPUサイクルを費やした開始側を狭い意味で「sincere」と呼ぶ。しかし、それは善意、契約上の権利、利用資格、容量予約、背後のアプリケーションの存在を保証しない。proof of workはproof of entitlementではない。

さらに、HITとの結合が防ぐ攻撃も限定される。一回のやり取りから多数の異なるHITを偽装する手法には効くが、固定HITを使う攻撃者には完全ではない。失敗を覚える局所状態を持つ実装も可能である。運用記録は、メモリと計算のどちらを選んだかを明示する必要がある。

I2受理で初めて応答側の決定が見える

I2にはパズル解答、開始側のDH値、署名された認証材料が入る。応答側はまず安い解答検査を行い、成功時に署名とDHを処理する。有効と判断すれば共有鍵材料を作り、対応するHIP associationを生成する。

応答側のI2 acceptedは、特定の実装と方針が状態生成境界を越えた証拠になる。それでもR2が開始側へ届いたとは限らない。開始側がR2を検証して初めて、共有結果を持つ応答側とのベース交換完了を自分の視点で確認する。

この区別により、「キャプチャには正しいR1があるが、相手のセッション表に何もない」という状況を正しく読める。I2が未着、期限切れ、解答不正、署名不正なら、状態がないのが期待結果である。

R2の先にも別の境界がある

ベース交換はHIP状態と鍵材料を確立するが、ユーザーデータの実際の転送形式を定義しない。RFC 7401は別文書へ委ね、最低限RFC 7402のESP transportを実装するよう求める。再起動説明でも、ベース交換後に新しいpayload associationを作り、その後データ送信を始める。

R2検証済みは、両端のESP Security Association導入済みを意味しない。片側のSAは対称性を示さない。保護パケット送信は到達を示さず、到達はアプリケーション受理を示さない。

経路可用を主張するなら、交渉したtransport、suite、locator、鍵epoch、保護したSPI相当値、両端の導入結果、各方向の最初の認証済みパケットを残す。サービス可用なら、安全なアプリケーション応答も必要である。

ダッシュボードに必要な証拠の段階

観測 言えること まだ言えないこと
I1送信 開始側がトリガーを出した 応答側が受信した
R1署名検証 応答鍵が対象材料を過去に生成した 現在生存、個別状態、予約
パズル解答 必要な計算を実施した 応答側が受理した
I2受理 応答側で検証とHIP状態生成が成功した 開始側がR2を受信した
R2検証 開始側視点でベース交換が完了した ペイロード経路が動く
ペイロードSA導入 指定transport状態が存在する 双方向アプリ成功
保護された要求と応答 限定されたサービス効果が起きた 継続可用性

各段階には実装版、方針版、プロトコル座標、局所単調時刻、失敗理由が必要だ。単一の成功フラグは調査に必要な因果を消す。

RFC 5201を現行標準と呼ばない

RFC 5201は2008年4月のExperimental文書で、Internet Standardを定めないと明記する。IESG NoteはSHA-1、MACの俊敏性、RSA方式、IPアドレス依存方針などの懸念を挙げた。RFC 6253が証明書機能を更新した。

2015年のRFC 7401はRFC 5201をobsoleteとし、実装経験と暗号俊敏性を取り込んだHIPv2をProposed Standardとして公開した。その後RFC 8002とRFC 9374も関連部分を更新している。2008年の暗号選択を現在向けに推奨する記事ではない。

一方、事前計算R1と無状態応答という証拠境界はHIPv2にも残る。運用画面の最小仕様は、実際に起きた遷移だけを表示することだ。記号を効果へ昇格させないことが、動くコードを優先する最初の条件になる。

情報源

  1. RFC 5201 HTML
  2. RFC 5201 テキスト
  3. RFC 5201 情報ページ
  4. RFC 5201 Datatracker
  5. RFC 5201 履歴
  6. RFC 5201 参照関係
  7. RFC 5201 errata
  8. RFC 7401 — HIPv2
  9. RFC 7401 テキスト
  10. RFC 7401 情報ページ
  11. RFC 7401 errata
  12. RFC 7402 — HIP向けESP transport
  13. RFC 4423 — HIP architecture
  14. RFC 4987 — TCP SYN flood対策
  15. RFC 6253 — HIP certificates
  16. RFC 8002 — HIPv2 certificates
  17. RFC 9374 — DRIP Entity Tag
  18. Heng Lu — reality layersとsymbolic power
  19. Heng Lu — minimum initial specification
  20. Heng Lu — running-code primacy