要約

  • RFC 3961 はプロトコル鍵と個別操作の鍵を分け、ゼロではない32ビット用途番号を暗号化・チェックサム処理の入力にした。
  • 簡略プロファイルでは Kc、Ke、Ki を別々に導出した。検証成功が示すのはその暗号文脈との整合であり、利用者の権限やサービス結果ではない。

RFC 3961 の用途番号は秘密ではない。攻撃者が知っていることを前提にしていた。それでも重要だったのは、番号が「この鍵で何をするか」を導出結果に反映したからである。

2005年の文書は Kerberos と暗号方式の間に抽象層を置いた。暗号タイプは、鍵形式、string-to-key、random-to-key、鍵導出、暗号状態、暗号化、完全性、PRF を定義しなければ完成しない。etype 番号はその定義への識別子であり、実装、設定、選択、成功を一つで証明する札ではなかった。

以前の材料は RFC 1510 に含まれていた。RFC 4120 は後にその Kerberos V5 仕様を置き換え、暗号処理を独立した枠組みに委ねた。アプリケーションは IV や内部鍵構造を仮定せず、「この鍵と用途でこのバイト列を保護する」と指定できた。

五バイトの文脈

用途番号は公開の符号なし32ビット値で、ゼロは禁止された。簡略プロファイルはその四バイトに識別子を加え、usage | 0x99 からチェックサム用 Kc、usage | 0xAA から暗号化用 Ke、usage | 0x55 から完全性用 Ki を導出した。基底鍵は導出にのみ使う設計だった。

背景には用途混同がある。RFC は、一部実装が Kerberos v4 と v5 で鍵を共有し、v4 の暗号化機能が v5 へのオラクルになり得ると説明した。ランダムな confounder は既知平文の利用を難しくし、用途別導出は別の操作へ能力が移る範囲を狭めた。これは攻撃構造の説明で、特定事件の報告ではない。

復号の成功地点で止まる

復号処理は完全性を検証し、失敗時にはデータを捨てる。成功は暗号文、導出鍵、用途、タグの一致を示す。しかし基底鍵の正当な主体、規定どおりの用途選択、チケットの鮮度、リプレイ防止、アプリケーション認可、サービス提供は別の証拠である。

RFC 6113 は一般化事前認証でこの枠組みを使ったが、事前認証を業務認可には変えなかった。監査には、メッセージ型、提示・選択された etype、秘密でない鍵版参照、用途番号と根拠条項、対象ハッシュ、実装版、完全性、鮮度、リプレイ、チケット、認可、結果を連結する必要がある。

方式が変わっても境界は残った

RFC 3962 は AES 型を定義し、RFC 4537 は対応一覧と実際の選択を分けた。IANA 登録簿 は番号と参照を示すが、配備を示さない。

RFC 6649 は single DES を非推奨とし、RFC 8429 は RFC 3961 を更新して他の旧方式も退けた。RFC 8009 は大枠に従いながら簡略プロファイルを使わず、復号前に暗号文を認証した。構成は変わり、抽象境界は残った。

RFC Editor 情報と Datatracker は文書履歴を示す。正誤表 は確認済み Unicode 修正、更新待ちの DES 問題、却下された提案を区別する。どれも単独では運用障害の証明にならない。

RFC 3961 は鍵そのものより、鍵が担う仕事を明示した。用途番号は権限を作らず、異なる権限文脈が同じ暗号能力に見えることを防いだ。

出典