要約

  • RFC 3329はSIPユーザーエージェントと次ホップの間で機構を交渉し、共通する既知の選択肢を有効化した後、サーバーの完全な静的一覧を Security-Verify として保護下で返す。
  • その照合で削除、並べ替え、パラメーター変更を見つけられるが、最初の交換を遡って保護するものではない。許容する中で最も弱い機構の完全性・リプレイ耐性が安全性の床になる。

何を選ぶかより、選ぶ前に誰が触れるか

導入時期の異なるSIP機器が混在すれば、対応機構の一覧は便利な出発点に見える。ところが、まだ何の機構も有効でない時点で一覧を交換する以上、経路上の中間者は応答から一つの項目を消せる。TLSとDigestの両方を使える二者がいても、強い方を消してDigestだけを残せば、二者は自分たちの能力を互いに見誤ったまま、より弱い共通項へ進みうる。

単に「最も強い方式を選ぶ」だけでは解決しない。クライアントが知るのは自分の能力、サーバーが示すのは自らの優先順位だが、その応答自体がまだ守られていない。最初から安全なチャネルを要求すれば、そのチャネルを選び確立するための交渉ができなくなる。RFC 3329はこの循環を消したのではなく、検証の時点を後へ移した。

ユーザーエージェントは次ホップのSIPエンティティへ Security-Client を送る。サーバーは、クライアント入力に左右されない Security-Server の静的一覧と、機構を始動させる情報を返す。クライアントはサーバーが示した優先度のうち、自分も知っていて共通する最上位のものを起動する。その後の要求には Security-Verify を入れ、以前に受け取ったサーバー一覧をそのまま含める。

サーバーに届くのは「強い方式があった」という説明ではなく、具体的な値の並びだ。サーバーは自分の対象インターフェース用一覧と、返された機構名、順序、パラメーターを照合する。応答から四つ目の項目が消えていれば、三項目の照合結果は四項目の基準と一致しない。サーバーは不一致を受け入れず、交渉をやり直させる。

重要なのは、最初のメッセージが後から暗号化されたことにするのではないという点だ。初期の削除は依然として起こりうる。ただし、削られた一覧をサーバーにも受理させるには、選ばれた機構の下で戻りの証拠を改変する必要がある。単純な削除は、稼働中の保護を破って回収値を偽造する試みに変わる。

照合の基準はクライアントの提案から独立する

もしサーバーがクライアントの Security-Client を見てから一覧を作れば、攻撃者はその一覧を先に縮められる。サーバーは攻撃後の提案に合わせ、クライアントは受け取ったものを返すので、すべてがきれいに一致してしまう。だからRFC 3329はサーバー一覧をクライアント内容に依存させない。あるノードはインターフェースごとに別の静的一覧を持てるが、適用範囲ごとの基準は入力を見る前から存在しなければならない。

この基準は優先順位を定める。機構ごとの q 値は異なり、クライアントは知っている共通候補からサーバー優先度の高いものを選ぶ。クライアント一覧の改変も無害ではない。起動に必要な情報がサーバーから返らなくなったり、両者が別の機構を選んだりして通信が失敗する可能性がある。ただし失敗は攻撃と整合する証拠であって、攻撃の証明ではない。古い構成や互換性のずれでも同じ結果が出る。

サーバー側に新たなSIP交渉状態を持たせないのも設計上の選択だった。保護付き要求が戻れば、その時点で Security-Verify を静的一覧と比較できる。これは基礎機構に状態がないという意味ではない。TLS接続、IKEセキュリティーアソシエーション、Digestの再認証にはそれぞれの状態と寿命がある。RFCが不要にしたのは一覧照合用の個別チャレンジ台帳だ。

応答コードに犯人の名前はない

クライアント主導のとき、初回の保護されていない要求は Security-Client と Require、Proxy-Require の sec-agree を含む。サーバーは 494 Security Agreement Required と Security-Server 一覧を返す。共通する機構がなくても、サーバーの一覧は返す。要求を本当に出した政策と、交渉を進められる共通能力を区別できるからだ。

サーバーはローカルポリシーで交渉を要求することもできる。クライアントが対応を示さない場合は 421 Extension Required、対応を示しているが保護をまだ確立していない場合は 494 が使われる。どちらも処理状態を伝えるコードであり、悪意ある中間者を認定するコードではない。古いUA、消された拡張タグ、誤ったポリシー、失われた始動資料、実際の改ざんは、別の証拠をそろえて区別する必要がある。

適用範囲も狭い。これはUAと次ホップ、通常は最初のプロキシ間の手順だ。サーバーが開始する側なら Via が一件だけであることを確認し、複数あれば自分が先頭ホップではないので使わない。従って、SIP全体、メッセージ本文、呼の相手側までのエンドツーエンド保証ではない。

機構ごとの始動も違う。TLSはSIPのサーバー位置特定規則を使って保護接続を確立する。Digestではチャレンジや検証値を使い、サーバー一覧が検証対象に含まれる。ipsec-ike はIKEを試み、手動設定IPsecは帯域外の鍵配布とポリシーに依存する。RFC 3310のAKA拡張はDigest周辺の選択肢を増やしたが、戻された一覧の照合を置き換えない。

成功は強さや機密性の証明ではない

RFC 3329の安全性に関する条件は率直だ。提案されうる機構のうち最も弱いものでも、Security-Verify に対して少なくとも完全性とリプレイ保護を与えなければならない。破れる機構を許容し続ければ、交渉成功は強度の保証にならない。相互運用のために旧機構を残す決定が、そのまま攻撃者にとっての安全性の下限を決める。

照合一致も機密性とは別である。Digestは検証値を保護してもSIP本文を暗号化しない。TLSは一つのホップを保護するが、その先のすべてを暗号化しない。IPsecも実際の関連付けと選択条件次第だ。レシートが証明するのは比較時点で一覧がサーバーの一覧と対応したことまでで、列挙された全方式が起動したこと、相手の全プロキシが認証済みであること、あるいは現代的強度を満たすことではない。

規範の時間軸も記録に含める必要がある。RFC 3329は2003年1月に発行された。後のRFC 8996はTLS 1.0と1.1の交渉を禁止し、RFC 8446はTLS 1.3を定めた。IANAの機構名登録は名前空間を調整するためのもので、ある名前が実運用されている証明にはならない。

RFC 3329には例と規範表の食い違いを示す保留中の勘誤もある。二つの例はACKに Security-Verify を載せる一方、ヘッダー使用表はACKに適用しない。別の確認済み勘誤は ipsec-3gpp のSPI長をちょうど十桁から一〜十桁へ直した。例示と規範を分けて読むこと自体が、この方式の境界を保つ。

最初の交換を守れない場合、後の保護された経路で原提案を返し、独立した基準と照合する。RFC 3329の成果はそこに限られる。返却証拠の整合性と、弱い選択肢をなお許す政策判断とは、最後まで別問題だった。

出典