要約

  • RFC 9594で認可サーバーが与えるのは、グループメンバーシップ資源へのアクセス許可である。KDCはその後もJoinを検証し、成功して初めてメンバーを登録してアプリケーションプロファイル所定の鍵状態を返す。
  • 有効なトークン、メンバー記録、導入済み鍵バージョン、成功したグループ動作は別の事実であり、上流の承認が下流の状態を代弁してはならない。

ある端末が正しく署名されたアクセストークンを受け取ったとする。スコープも役割も正しく、有効期限も残っている。管理画面がこの時点で「加入済み」と表示すれば、実際には起きていないことまで完了したように見える。

端末はまだKDCにトークンを渡していないかもしれない。安全な関連付けに失敗した可能性もある。Join Requestが拒否されたか、応答を受け取っても鍵を導入できなかったかもしれない。RFC 9594は、これらを単一の緑色表示にしない。

認可は加入を要求する権利である

RFC 9594の鍵プロビジョニングは二段階になっている。最初はClient、Authorization Server、ACE Resource Serverとして動くKDCの間のACE認可である。次がClientとKDCの間の実際の鍵配送であり、これは認可判断そのものではない。

Authorization Serverはポリシーに基づき、どのグループ資源にどの役割でアクセスできるかを決める。Clientは通常、取得したトークンをKDCの/authz-infoへ渡し、選択したACEトランスポートプロファイルに従う安全な通信関連を確立する。RFC 9202はDTLS、RFC 9203はOSCOREのプロファイルを定める。

加入はその後、/ace-group/GROUPNAMEへのPOSTで始まる。KDCは保存したトークンと要求されたグループ、スコープ、役割を照合し、基礎仕様とアプリケーションプロファイルの検証を行う。成功したJoinハンドラーがClientを現在のメンバー一覧へ加え、必要なグループ鍵材料を返す。

したがってトークンは、KDCへの到達、安全な関連、Join送信、受理、ノード資源作成、資格情報の検証、ローカル導入のいずれも証明しない。Authorization Serverが自ら行った判断だけを証明する。

名前の不変性と鍵状態の新しさは別物だ

GROUPNAMEはKDC上のメンバーシップ資源を特定し、確立後は不変である。ノード名とURI中のNODENAMEも不変で、現在のメンバー間で一意である。これは運用上の参照を安定させる。

一方、暗号状態は更新される。numは現在のグループ鍵材料のバージョンを示す。グループ識別子、個別材料、ピア資格情報、ポリシーは、採用したプロファイルと現在のバージョンの中で解釈される。同じ安定したURIを指していても、二つのClientが一時的に異なる鍵時代にいることはあり得る。

RFC Editorの報告済み技術的正誤表8239は、資格情報取得の例に必須のnumが欠けていたとして補う。8864は空の資格情報フィルターの記述を修正する。いずれも特定製品の障害を示すものではない。ただし、資格情報と鍵バージョンを同じ証拠として保存すべきことはよく表している。

アプリケーションプロファイルが安全性を具体化する

RFC 9594は一種類のグループ保護方式を完成品として規定していない。KDCインターフェース、共通CBOR形式、エラー、メディアタイプ、IANAレジストリを定め、具体的な方式はアプリケーションプロファイルに委ねる。

プロファイルは鍵の型と符号化、グループとノードの識別子、資格情報、所持証明、グループポリシー、rekeyメッセージの保護、KDC資源、Client能力を明らかにしなければならない。ace_groupcomm_profileの値はその特殊化を識別するが、実装を代行しない。

よって「RFC 9594対応」だけでは運用証明にならない。どのプロファイルか、どのパラメーターか、どの検証を行い、どの状態を導入したかが必要である。最小初期仕様は、共通にすべきものだけを共通化し、残りを明示的で試験可能なプロファイルへ置く。この境界をUIが隠すと、仕様名が存在しない保証まで引き受けてしまう。

NUMの更新は全員同時の更新ではない

鍵材料は期限切れで更新され、定期更新もあり得る。後方安全性が必要なら新規メンバー加入時、前方安全性が必要なら退出または排除時に新しい材料が必要になる場合がある。

KDCは配布前にNUMを増やし、NUM+1を配布する。対象ごとに複数のメッセージが必要なこともある。RFC 9594は一時的な不整合を明記している。新しい状態を持つメンバーと古い状態のままのメンバーが共存し得る。rekey完了後に旧材料を削除し、新材料を永続化する。

これはRFC 9838について既に掲載されたKEKとTEKの二段階排除論を再掲するものではない。ここでの固有点は、一般KDCインターフェースでも、KDC側のバージョン更新が各Clientの受信、検証、活性化を証明しないことである。

Dispatcherは運ぶが、メンバーを認定しない

加入後の一対多通信はDispatcherを通ることがある。マルチキャストでは暗黙の機能になり、pub-subやリレーでは明示的な仲介者になる。明示的なDispatcherは、保護されたメッセージを見て配送できるが、グループ鍵材料を持たず、平文を読めない経路上の非信頼主体として扱われる。

配送位置はメンバーシップ権限ではない。ブローカーは内容を検証せずに転送でき、リレーは宛先が同じnumか知らずに到達できる。保護されたメッセージがローカル動作になったかという次の境界は、既存のRFC 10020記事が扱う。本稿はその手前、許可が加入になり、加入が導入済み状態になるまでを対象にする。

秘密ではなく遷移の証拠を残す

監査記録には、トークンIDまたはハッシュ、発行者、オーディエンス、スコープ、役割、有効期限、KDC受領結果、トランスポートプロファイル、安全な関連の識別子、Join ID、GROUPNAME、NODENAME、アプリケーションプロファイル、num、資格情報と所持証明の結果、ローカル導入、ポリシーバージョン、rekey開始と完了、回復要求、最後の確認済み利用を残す。鍵そのものは残さない。

ASはポリシー判断、KDCは加入と配布、Clientは検証と導入、Dispatcherは転送、アプリケーションは結果を証明する。Lu Hengの現実階層の観点では、記録は現実を記述できるが次の現実を創造しない。権威の外観ではなく、動いているコードが遷移の実装を証明する。

出典