要約

  • 応答トークンを伴う交換では、RFC 2025は開始側のrandSrcと相手側のrandTargを連結してContext IDを作る。両方が入って初めて、双方が古いコンテキストとの分離に寄与したと読める。
  • 一方向SPKM-2はSPKM-REQだけで終わる。相手側は乱数を加えられないため、開始側の鮮度を信頼するか、コンテキストを拒否するしかない。key-src-bindは要求と鍵の結び付きを強めるが、相手側の寄与にはならない。
  • コンテキスト確立時のリプレイ対策と、確立後のメッセージに対する任意のreplay/sequenceサービスは別物である。Context IDは認可、配送、業務完了の証拠でもない。

二つの部品を持つ受領証

RFC 2025はSimple Public-Key GSS-API Mechanism（SPKM）を規定した。コンテキスト確立用トークンには多くの情報があるが、証跡として際立つのはContext IDの組み立て方だ。開始側はrandSrcを提示する。応答がある交換なら、相手側がrandTargを加える。その後は二つを順に連結した値が同じコンテキストを識別する。

この構造なら寄与者を数えられる。開始側は新しいrandTargによって、古い応答をそのまま見ているのではないと判断できる。相手側も、自分が今作った値が開始側の値とともに識別子へ入ったことを知る。randSrc || randTargは、コンテキスト間の鮮度に限っていえば、双方が作った受領証である。

ただし、ここでいう乱数に秘密性は要らない。RFC 2025が求めるのは、過去に使った値と再び一致する可能性を十分低くすることだ。予測困難性ではなく非再利用が目的であり、乱数の品質を強調しても証明範囲は広がらない。

応答が消えると、寄与者も一人消える

SPKM-1には常に相手側の応答がある。一方向認証はSPKM-REQとSPKM-REP-TI、相互認証はさらにSPKM-REP-ITを使う。相互SPKM-2にも応答があるため、相手側はrandTargを提示できる。

例外は一方向SPKM-2だ。交換はSPKM-REQ一つで完結し、randTargを運ぶ返信はない。Context IDは開始側の値だけになる。RFC 2025は、相手側が開始側による乱数の鮮度を信頼するか、そうでなければコンテキストを拒否しなければならないと説明する。

これは往復回数だけの差ではない。応答付きの方式では、受け入れる側が自分の非再利用値を識別子へ入れられる。一方向SPKM-2では、その側に同じ手段がない。Context IDはコンテキストを区別できても、双方が鮮度を作った証拠にはならない。

key-src-bindが埋める穴は別の穴

一方向SPKM-2には追加の防護がある。鍵確立アルゴリズム自身が送信元名をコンテキスト鍵へ結び付けない場合、要求にはkey-src-bindが必須となる。これは符号化した送信元名と提案されたコンテキスト鍵に対するMD5ダイジェストだ。

この値は、名乗られた送信元、受信した要求、提案された鍵を同じ案件として評価する助けになる。RFCは、トークンと鍵の鮮度を相手側が信頼するうえで役立つとも述べる。しかし値は依然として開始側の要求内にある。応答を追加せず、randTargを生まず、相手側が新しい材料を作ったことも示さない。

送信元と鍵のbinding、鮮度への寄与、相互認証は三つの異なる事実だ。「context established」という一項目にまとめると、その境界が失われる。

リプレイを扱う二つの場所

SPKMは確立後の保護メッセージについてもリプレイ検出と順序検査を提供できる。これはアプリケーションが要求した場合にシーケンス番号を使う機能で、Context IDの乱数構成から自動的に導かれるものではない。

GSS-APIの一般仕様であるRFC 2743では、per-messageのreplayとsequenceを選択可能なコンテキスト・フラグとして扱う。呼び出し側が要求し、受け入れ側が利用可能なサービスを返す。実装は重複や順序違反を補足ステータスで示しながら、疑わしいメッセージを呼び出し側へ渡す場合さえある。トークンを運ぶ経路もアプリケーションの責任だ。

監査では、古い確立交換から今回のコンテキストを分離できたか、そして受理後の各メッセージで重複・順序検査を実施したかを分けて問う必要がある。前者にはContext ID、後者には要求・受理されたフラグ、シーケンス状態、検証結果が必要になる。

仕様史と運用実績を混同しない

RFC EditorはRFC 2025を1996年10月のProposed Standardとして掲載している。今回の確認時点で公開済みの正誤表は見当たらない。IANAのSMIレジストリにはSPKM-1、SPKM-2、SPKM-3およびSPKM GSS tokenのオブジェクト識別子が残る。これは規格と番号割り当ての履歴であり、現在の導入状況を示す資料ではない。

後発のRFC 2847はSPKM-3を、列挙した変更点を除けばSPKM-1と等価だと定義した。機構群の系譜は追えるが、RFC 2025の証拠境界は変わらない。Context IDは、それを生んだ交換パターンと一緒に読まなければならない。

結論は明快だ。二部構成のrandSrc || randTargは双方の鮮度寄与を記録する。一方向SPKM-2のContext IDは開始側の寄与しか記録せず、key-src-bindがあっても同じである。どちらも証明書に基づく認可、アルゴリズム選択、メッセージ到達、業務上の完了までは証明しない。

出典