要約

  • RFC 3520のAUTH_SESSIONは、セッション側の認可文をリソース予約要求へ運ぶ。完全性と発行元を検証できても、その発行元にローカル資源を動かす権限があるか、予約やメディア配送が完了したかは別に立証しなければならない。
  • 実務で残すべき証跡は、トークンの正確なバイト列、認可者の権限範囲、鮮度、フィールド照合、PDPのローカル判断、PEPの実行、RSVP状態、SIP前提条件、観測された通信、認証済みアプリ結果を分けて結ぶ。

公開鍵は、誰の鍵でどのデータが保護されたかを確かめるために強力である。その強さが、別の判断まで済ませたように見せることがある。だが、鍵の所有者が名前どおりであることと、その所有者がこちらの資源を割り当てられることの間には、制度上の橋が必要だ。

RFC 3520は2003年4月にStandards Trackとして発行され、現在はProposed Standardとして記録されている。Session Authorization Policy Elementを定め、ホストがセッション信号から得た要素を変更せずRSVPのPOLICY_DATAへ写せるようにする。信頼されないホストでも、文面を変えず運ぶ役割は果たせる。

ここで標準化されるのは、認可文を渡す形式と処理である。資源管理ドメインが誰を権威として採用するか、そして最終サービスが成立したかまでは、トークン自身が決めない。

認証後にもローカル判断が残る

AUTHENTICATION_DATAは、それより前に置かれた属性を保護する。仕様は当時の共有鍵、Kerberos、公開鍵方式を記述し、公開鍵の場合には証明書パス、失効、署名の検証を含める。これにより完全性とデータ起源を評価できる。

それでも、認可主体のアイデンティティを確立しサービス要求を検証した後、ルータまたはPolicy Decision Pointはローカル方針表を参照する。表の中身はローカル事項であり、補助情報に依存するなら、それも安全に取得しなければならない。

この順序は重要だ。認証成功の後に方針判断がある。したがって、正しい署名を持つ要求がローカルに拒否されても矛盾ではない。逆に、署名成功だけを「認可済み」と表示すると、暗号上の事実が組織上の委任にすり替わる。

2003年の文書に出るアルゴリズムは歴史的な仕様の一部であり、今日の暗号運用を推奨するものとして扱うべきではない。

モデルごとに信頼の置き場所が違う

coupled modelでは、同じポリシーサーバがサービス判断と資源判断に関与するため、SESSION_IDだけが必須になる。識別子は保存済み判断を参照する。形式が実装依存でも、状態の複製、再起動、フェイルオーバーは証跡上の責任である。

associated modelでは認可主体の身元も運ぶ。エッジはそれを使って、メディア判断を保持するポリシーサーバを見つける。ただし、指定された主体が自ドメインの正規サーバだと別経路で分からないなら、偽の認可先へ誘導されないよう認証データが必要になる。

二つのポリシーサーバを使う形では、一方がサービスを知り、他方が資源を管理する。問い合わせの成功、応答内容、それを採用したローカル条件は、いずれも証跡である。non-associated modelでは共有状態を仮定できないため、判断に必要な情報をトークン側が多く持つ。

どのモデルでも同じ「valid」欄を使う監査は、依存関係を隠してしまう。どこに記憶があり、誰が誰を信頼し、障害時に何が失われるかをモデル別に示す必要がある。

フィールドは認可の境界線である

AUTH_SESSIONは一般的な身分証ではない。認可主体、セッション識別子、送信元、宛先、開始・終了時刻、資源、認証データを持ち得る。資源は最大帯域、RSVP flow spec、SDPメディア記述、DSCPなどで表現できる。

non-associated modelでは、全フィールドが資源要求と一致しなければならない。送信元と宛先のアドレスが合い、要求QoSが認可値を超えないことを確認する。不一致なら拒否する。

ポート一覧の省略にも意味がある。ある側に一覧がなければ、その側の全ポートが有効と扱われる。一覧があれば列挙されたポートだけである。監査では、値だけでなく不在も保存しなければ、限定的な許可と広い許可を区別できない。

自動検証は、トークン値、実要求値、正規化規則、照合結果、方針上の帰結を一組で残すべきだ。署名テストだけでは、署名対象と実行対象が同じだったことを証明できない。

鮮度は時計か記憶に依存する

リプレイを防ぐため、要素の構築にはSTART_TIMEまたはSESSION_IDが必要になる。開始時刻を使えば、時間源、クロック差、許容窓が安全性を左右する。non-associated modelのポリシーサーバはNTP同期を支援する必要があり、非同期の時計がリプレイを許す可能性をRFCは警告する。

識別子を使えば、作成時刻、既使用かどうか、状態が複製・再起動を越えたかが重要になる。同じバイト列を再送しても署名は正しいままである。暗号は最初の使用を記憶しない。

証跡には、時間源、観測オフセット、窓、リプレイキャッシュの判断、または識別子の生成と既使用状態を含める。後年のRFC 5905はNTPの比較資料であり、特定システムの時刻管理を証明しない。

経路上の全装置が方針を理解するとは限らない

policy-awareなRSVPルータはメッセージをPDPへ送り応答を待つ。policy-unawareなルータはpolicy-dataオブジェクトを無視し、RSVP処理を続ける。入口でトークンがあり出口でも見えたからといって、全ホップで実行されたとは言えない。

どの装置がPEPで、どのPDPへ問い合わせ、どの装置がオブジェクトを無視し、実際に何を予約したかを記録する必要がある。伝播した範囲と執行した範囲は異なる。

PDPが要素を検証できない場合、RFC 3520はPEPへのPolicy Control Failure、Error Code 02を求め、詳細なAUTH_DATAを推奨する。このエラーは検証失敗を表す。それがないことは、ローカル許可、資源の可用性、経路予約、アプリ成功の証明にはならない。

予約はメディアの受領書ではない

RFC 3521の流れは段階的だ。セッション管理は設定完了または進行中を伝え、トークンを渡す。ホストはPATHを送り、エッジはポリシーサーバへ照会し、サーバは資源を変更することもある。RESVも予約完了または進行中を示す。

RFC 3312では、SIPのQoS前提条件にdesired statusとcurrent statusがある。必須条件を満たさない間、セッション確立は保留され、メディアは流すべきでない。予約イベントがcurrent statusを更新しても、通信の観測やアプリ結果は残る。

キューの確保は音声の復号ではない。方針上の許可は利用者の同意ではない。SIP応答は継続した品質の証明ではない。事業上「完了」と呼ぶ地点は、実際の約束に対応する最後の受領書へ結び付けるべきだ。

争いに耐える連鎖を残す

最初のセッション要求、認証された行為者、その背後の運用・法的主体を保存する。認可者の身元、権限範囲、判断版、保持状態を記録し、トークンの正確なバイト列をハッシュする。各フィールド、鍵や資格情報の参照、失効結果、リプレイ判断を残す。

トークンと予約要求の送信元、宛先、ポート、資源上限、有効期間を照合し、PDPによる変更を記録する。判断したPDP、執行したPEP、無視したノードを示し、PATH、RESV、エラーを同じ取引に結ぶ。

最後にSIPのdesired/current状態、観測通信、認証済みアプリ確認を加える。フェイルオーバーでも連鎖を失わず、時計ジャンプや経路変更が「admitted」という表示だけを残さないようにする。

証拠の境界

本稿は製品、事業者、ルータ、ポリシーサーバ、顧客、利用者、セッション、メディア、事故、導入を特定しない。現実のシステムについて採用、適合、安全性、性能、QoS、事業結果を主張しない。

RFC 3520は2003年4月のStandards Track文書で、現在Proposed Standardとして扱う。RFC 3521、3313、5866はそれぞれの地位と範囲を保つ。RFC 3313の限定的な管理ドメイン前提を公共インターネット全体へ広げない。後年のNTPとDiameter文書は比較に限る。

Heng Luの権威とrunning codeに関する文章は、形式的な主張と観測可能な支配を分ける編集上の視点であり、IETFの意図を示す資料ではない。

結論は狭い。署名が正しく、鮮度とフィールドが通り、ローカルに受け入れられても、セッションの結果はまだ別の証拠を必要とする。

出典