要約

  • RFC 2412の3メッセージによるAggressiveな例では、署名を検証してKEYIDを認証済みにした後も、Diffie–Hellman鍵素材をuncomputedとして保持できた。
  • 通信の証明は計算の証明ではなく、計算も両端のSA導入、保護パケット、アプリケーション成果を自動的には証明しなかった。

セキュリティ装置の画面に「認証済み」と表示されると、私たちはその先まで終わったと考えがちだ。RFC 2412は、その推測を許さない文章を残している。

1998年11月にInformationalとして発行された同文書は、Diffie–Hellmanを基礎に、認証された二者が秘密の鍵素材に合意するOAKLEYを記述した。前方秘匿性、ISAKMPとの互換性、補助アルゴリズムの選択、独自グループ、鍵更新、帯域外鍵まで扱う一方、状態を一つの「完了」に押し込まなかった。

Aggressiveな例では、イニシエーターがcookie、グループ、公開半鍵g^x、アルゴリズム候補、双方のID、nonceを送り、署名する。レスポンダーは自らのcookie、g^y、選択結果、nonceと署名を返す。最後にイニシエーターが全体を結ぶ署名を送る。

RFCは、この署名によって記録・提示可能な「通信の証明」が得られると説明する。その直後、グループ指数から導かれる鍵素材は交換完了に不要だと書く。

実装は秘密指数xと相手の公開値g^yを保存し、鍵素材をuncomputedと印付けし、後で計算してよい。

処理手順も同じ境界を示す。イニシエーターはレスポンダーの署名を検証し、g^yと選択されたアルゴリズムを状態へ追加する。(g^y)^x = g^xyの計算は、その場で行っても、最後の返信を送った後まで遅らせてもよい。それでもKEYIDは認証済みになる。レスポンダーも最終署名を検証すると鍵を認証済みにし、その後g^xyを計算してKEYIDへ結び付けるべきだとされる。

認証という境界は越えた。計算という境界は、まだ越えていないかもしれない。

KEYIDの構造を見ると違いはさらに明瞭だ。両者のcookieは、弱い送信元確認とDoS耐性の役割を持つと同時に、鍵素材の再利用可能な名前になる。sKEYIDはその名前が指す秘密素材であり、ネットワークを流れず、この例ではg^xy、nonce、cookieから導かれる。名前は内容より先に存在できる。名前の認証は内容の生成ではない。

運用システムはこの差を消しやすい。ログが“authenticated”と一語だけ記し、ダッシュボードが緑になり、上位層が「利用可能」と読む。そこから「両端にSAが入った」「通信が保護された」まで推論が延びる。しかし署名は、それらの後続事実に署名していない。

計算の延期には合理性があった。1990年代末のモジュラー指数演算は重かった。最終メッセージのクリティカルパスから外せば、見かけの待ち時間やCPU集中を抑えられる。相手が受け取る署名済みフィールドは変わらず、ローカルな実行時点を一律にする必要はなかった。

ただし、先送りした計算は状態保管の債務になる。正しい秘密指数、相手の公開値、グループ、cookie、nonce、ID、アルゴリズムを保持し、別セッションと混同せず、検証、計算、導出、結合、導入まで完了させなければならない。クラッシュ、期限切れ、ハンドル再利用、再起動による消失が起これば、署名済みtranscriptだけが残り、使える鍵は生まれない。

したがって証拠も分ける必要がある。transcript受領は、想定したフィールドの署名検証を示す。入力検証は、公開グループ要素が適用中の検査を通ったことを示す。計算受領は、g^xyと導出素材が実在することを示す。結合受領は、それらを正しいID、アルゴリズム、KEYIDへ結ぶ。導入受領はSAに入ったことを示し、パケット受領は保護通信を、成果受領はサービスの成功を示す。

前段の真実は、後段の代筆者にはなれない。

RFC 2412自体も、退化した指数値の拒否や、cookie、nonce、指数のための良質な乱数を求めた。公開errataはsafe primeとSophie Germain primeの用語を訂正しているが、計算延期の仕組みは変えていない。

後年のRFC 6989は、IKEv2におけるDiffie–Hellman公開鍵検証をより厳密にした。小部分群への対策を含み、不正なKE payloadをSA作成に使ってはならないとする。2013年の要件から1998年の製品実装を推測することはできない。しかし「受信」と「検証」と「導出」が別工程であることは、より明確になった。

RFC 2409はISAKMPとOAKLEYの要素をIKEv1へまとめた。Aggressive Modeでは最終payloadをISAKMP SAで保護せず、交換終了まで指数演算を延期する余地も残した。それでも鍵導出には現実の共有値が必要だった。「メッセージ終了」という表示から鍵ビットは生成されない。

IKEv2は設計を組み替えた。RFC 4306、5996、7296へと世代が進み、RFC 7296ではnonceと一時的なDiffie–Hellman共有秘密からSKEYSEEDを計算し、暗号化、完全性、認証、再導出の鍵を分ける。また、IKE SAの認証が成功してもChild SAや設定要求は失敗し得ると区別する。

これはOAKLEYと同一の状態機械ではない。むしろ、制御面の成功が従属するデータ面の完成を保証しないという、別の明示例である。

文書の履歴も実装の履歴とは異なる。RFC 2412はInformationalであり、IKEv1は標準化され、IKEv2に置き換えられ、アルゴリズム要件も更新された。RFC 9395はIKEv1と旧式アルゴリズムを非推奨にした。しかし文書上の非推奨化が、稼働中の装置からコードを消すわけではない。

Lu HengのRunning-Code Primacyは、この事例を読むための規律になる。文書は遷移の意味を定義できるが、その遷移を実行した証拠は稼働系にしかない。現実の層を順番に見る必要がある。メッセージ受信、署名検証、公開値検証、秘密計算、鍵結合、SA導入、パケット受理、アプリケーション成功である。

Minimum Initial Specificationは、共有すべき境界も示す。独立実装は署名対象、導出規則、パラメータの意味を共通化しなければならない。一方、安全性と相互運用性を壊さない限り、各CPUがいつ指数演算を行うかまで中央仕様で固定する必要はない。

ローカルな選択にはローカルな説明責任が伴う。延期を選んだ実装は、認証済みと計算済みの間の不可視区間を支配する。入力を保持し、状態を正確に公開し、計算失敗時にはその先の強い状態を撤回しなければならない。結果を負担するアプリケーションに、緑色のランプから推測させてはならない。

RFC 2412が残した最も誠実な語は、uncomputedなのかもしれない。署名の価値を否定せず、まだ起きていない計算まで証明したふりをしない。

交換は認証された。共有秘密はなお計算が必要だった。SAは結合・導入が必要だった。パケットとサービスは、その後に確かめる必要があった。

信頼できる仕組みは、それぞれを正しい動詞で記録する。

情報源