要約

  • RFC 1964 の認証器チェックサムは、呼び出し側が与えたチャネル・バインディングの MD5 要約、要求され利用可能なサービス・フラグ、任意の KRB_CRED を運ぶ。
  • Bnd の全ゼロはバインディングなしを示すだけであり、一方向の KRB_AP_REQ、委任 TGT、MIC/Wrap、シーケンス検査はいずれも相互認証や下流認可、アプリケーション受理の代わりにならない。

運用画面に「Kerberos 認証成功」と一行だけ表示されると、長い交換が一つの事実に見える。RFC 1964 のワイヤ形式を読むと、その一行の内側には少なくとも六つの別の問いがある。どの機構か。どの種類のトークンか。外側のチャネルを結び付けたか。相手から確認が戻ったか。資格情報は委任されたか。アプリケーションはメッセージを受理したか。

1996 年 6 月の RFC 1964 は Kerberos V5 GSS-API 機構に OID 1.2.840.113554.1.2.2 を与えた。初期 KRB_AP_REQ の TOK_ID は 01 00、KRB_AP_REP は 02 00、KRB_ERROR は 03 00 である。MIC は 01 01、Wrap は 02 01。番号は構文の選択を安全にするが、暗号検証、時刻、対象プリンシパル、コンテキストの一致までは保証しない。

全ゼロが語るのは「入力なし」

KRB_AP_REQ の認証器では、型 0x8003 のチェックサムが GSS-API 固有情報を保持する。最初の四バイトは Bnd の長さ 16、続く 16 バイトはチャネル・バインディング構造の非 null 要素から計算した MD5 である。整数と長さの小端表現も計算対象になる。

呼び出し側が GSS_C_NO_BINDINGS を渡すと、Bnd は 16 個のゼロになる。これは既定チャネルの識別子ではない。TLS、ソケット、アドレス、ホストを指してもいない。「比較すべきチャネル情報が提供されなかった」という負の記録である。後年の RFC 5056 が示すように、どのバインディングを用いるかはアプリケーション側で事前に合意する必要がある。

続く Flags には委任、相互認証、リプレイ検出、順序検出、機密性、完全性が入る。最初の四つは要求と利用可能性の論理積で、後二つはメッセージ保護機能の利用可能性を示す。利用可能性は利用実績ではない。相互認証フラグは相手の返答を要求するが、返答そのものではない。

往復しなければ相互確認ではない

mutual_req がなければ、RFC 1964 のコンテキスト確立は一方向である。受容側は KRB_AP_REQ への確認トークンを返さない。受容側が開始側を検証できても、開始側は受容側から成功確認を得ていない。

相互認証を要求すると、KRB_AP_REQ の APOptions に mutual-required が入り、チェックサムにもフラグが立つ。受容側は KRB_AP_REP または KRB_ERROR を返す。有効な KRB_AP_REP は成功した相互交換を閉じる。KRB_ERROR は失敗である。単に「戻りトークンあり」と数える監査では、この分岐を見失う。

KRB_AP_REP もアプリケーションの代理人ではない。コンテキストは確立しても、次の要求が権限不足や内容エラーで拒否されることはある。

委任された TGT の先に認可がある

委任が有効なら、チェックサムは 24 バイトを超え、委任オプション 1、長さ、KRB_CRED を含む。移送される TGT には FORWARDABLE フラグが付く。受容側は別サービスのチケットを得るために使える資格材料を持ち得る。

ただし、KRB_CRED の到着から実行までは連続した一個の権限ではない。復号と検証、資格キャッシュ、期限、KDC へのサービス・チケット要求、対象サービスの認可が続く。委任は能力を移す。下流サービスの判断を先取りしない。

MIC と Wrap の決算範囲

MIC は別送データの完全性を守り、Wrap はデータを完全性と任意の暗号化で包む。保護されたシーケンス番号には方向も組み込まれる。ただしリプレイと順序の検出は任意で、呼び出し側の要求によって無効にできる。

したがって、MIC 検証は特定コンテキスト内のバイト列についての証拠である。Unwrap 成功は保護トークンの処理についての証拠である。アプリケーションが意味を解釈し、権限を確認し、状態を変更したかは別の記録で確かめる。

RFC 4121 は後に形式を更新し、RFC 6649 は当時の弱い暗号を非推奨にした。RFC 1964 を現在の暗号選択として読むべきではない。それでも歴史的設計から得られる原則は残る。共通仕様は相互運用に必要な境界を厳密にし、その後の判断は実行する当事者に残す。Running-Code Primacy はここで編集上の物差しとして働く。記号の権威ではなく、実際に起きた状態遷移だけを数える。

出典