要約

  • RFC 5365 は、平坦な URI リストとインスタントメッセージのペイロードを一つの MESSAGE で受け取り、専門化された B2BUA として受信者ごとに新しい MESSAGE を生成する pager-mode サービスを定義する。
  • P-Asserted-Identity は、信頼できる入口から信頼できる次ホップへ進む場合に伝搬される。次ホップが信頼されずプライバシーが要求される場合は送ってはならない。表示上の From を保つことと、識別主張を運ぶことは別の判断である。
  • 管理は、入力認証、マッピング、Privacy、入口と出口の信頼分類、PAI 判断、認証 realm、暗号本文の受信者、新規トランザクション、下流応答、配送を別々の証拠として残す必要がある。同じ文章は同じ権限を意味しない。

識別情報には移動可能範囲があった

P-Asserted-Identity は、名前を表示するための一般的なラベルではない。RFC 3325 のモデルでは、信頼ドメイン内部で責任を持つノードが扱う識別主張である。値だけを切り出して別の経路へ置けば、見た目は同じでも証拠の条件が失われる。

RFC 5365 の MESSAGE URI リストサービスは、一件の入力を複数の出力へ展開する。クライアントは RFC 4826 の平坦なリストと本文を multipart に含め、recipient-list-message の対応を要求する。サービスは各宛先へ新しい要求を発行する。

入口で PAI が信頼できる送信元から届き、最初の出力ホップも信頼できるなら、サービスはその主張を伝搬しなければならない。反対に、次ホップが信頼されず Privacy が要求されていれば、主張を含めてはならない。

宛先 URI が同じでも、ルーティング変更だけで判断は変わり得る。セッションの負荷分散先、ピアリング、境界プロキシの設定変更は、ペイロードに一バイトも触れずにアイデンティティの許容範囲を変える。

サービス自身が主張者になる場合もあった

サービスは、ユーザーを認証し、その認証を SIP または SIPS URI に対応付けられる場合、PAI を生成できる。ここで起きるのは不変な証明書の転送ではない。サービスが自らの判断と信頼関係を使って主張を作る行為である。

したがって、「PAI がある」という一項目では監査にならない。必要なのは、誰がユーザーを認証したか、どの方式だったか、どの規則で URI に対応付けたか、入力主張を受け入れた根拠、Privacy の値、出力第一ホップの分類、最終的な生成・伝搬・抑止の決定である。

その記録がなければ、表示上正しいアドレスが偶然出た場合と、権限ある主張が正しい経路に出た場合を区別できない。アイデンティティは文字列の正しさだけではなく、その文字列を誰がどの範囲で保証したかで成立する。

From は会話上の著者を残した

出力 From の値は、プライバシー要件に従う限り入力と一致すべきである。受信者はリストサービスではなく Alice を会話の著者として認識できる。一方、From tag は同じ dialog endpoint が続くかのようにはコピーされない。

同居するプライバシーサービスがあれば、その処理がリストサービスより優先する。つまり From の見え方も単純な保存ではなく、ポリシー判断の結果である。

From、認証済み principal、PAI は異なる主張を表す。From は要求上の送信者表現、認証はサービスが確認した主体、PAI は信頼ドメイン内の主張である。受信者の画面に Alice と出たことだけで、この三つを一つにまとめてはならない。

事故調査では、入力 From、認証結果、Privacy、適用したルール、出力 From、PAI の扱いを連結する。そうして初めて、人間向けの連続性を安全上の連続性と誤認せずに済む。

認証情報は realm の境界で止まった

Authorization と Proxy-Authorization は、特定 realm の challenge に答える。MESSAGE リストサービス自身の realm に属する認証情報は、出力要求へコピーすべきではない。入口を開けた秘密は、Bob のサーバーに提示する秘密ではない。

入力ヘッダーが別 realm を指す場合、RFC 5365 は対応する値をコピーするよう求める。重要なのは、本文をコピーするから認証情報もコピーするという論理ではなく、どの権威の challenge に答えたかである。

監査ログへ生の credential を残す必要はない。種類、realm 分類、不可逆な参照、コピーまたは抑止の判断、出力側の信頼状況を残せばよい。秘密を観測可能にして安全を証明しようとすれば、観測系が新たな漏えい源になる。

この realm 判断も、入力受付と下流成功を分離する。サービスは正しい credential で Alice を受け入れても、下流では別の認証が必要になり、別の結果を生む。

ペイロードの周囲には新しいトランザクションが作られた

サービスは専門化された B2BUA である。入力側ではサーバーとして応答し、出力側ではクライアントとして新しい MESSAGE を発行する。透明なプロキシとして一つのトランザクションを延長するのではない。

各受信者に新しい To、Call-ID、独立した CSeq を作り、Max-Forwards を初期化し、自身の Via を加えるべきである。Request-URI もリストサービスから個別宛先へ変わる。

Call-ID が変わることは、単なるプライバシー配慮ではない。入力識別子を出力側に広げる必要がなく、各要求が独立して応答・再試行されることを示す。Via と Max-Forwards も新しい経路責任を可視化する。

内部では、親実行 ID、正規化された受信者、意図した操作、個々の試行を結ぶ。入力 Call-ID を万能相関キーにせず、出力 Call-ID だけで原因関係も捨てない。プロトコル識別子と業務上の系譜を分けることが重要である。

暗号本文は本来の受信者にだけ属した

multipart 入力には、リストサービス向けに暗号化された S/MIME 等の security body が含まれ得る。サービスが復号できても、個々の受信者が同じ鍵を持つとは限らない。RFC 5365 は、そのような本文を出力へコピーしてはならないとする。

残るテキストや画像の本文は通常コピーされる。リストとサービス向け部分を除いた結果、一つの本文だけなら multipart/mixed の wrapper も外す。意味が保たれても、要求全体のバイト列は変わる。

検証は本文部品ごとに行う。媒体型、ハッシュ、Content-Disposition、想定受信者、許可された変換、削除または追加理由を記録する。全体ハッシュの一致は正しい変換と両立せず、画面の文字だけの一致は添付や構造の変更を見逃す。

履歴は原リストではなく開示ビューだった

サービスは reply-to-all のために recipient-list-history を作成できる。RFC 5364 の To、Cc、Bcc、匿名化の規則を適用するため、これは原リストのコピーではない。受信者別に構成された開示ビューである。

その履歴は受信者の公開鍵で暗号化することが推奨される。Bob の履歴が正しいことは Carol の履歴を証明せず、本文の配送成功は Bcc が守られたことも証明しない。

入力リスト版、適用規則、含有・除外項目、ビューのハッシュ、暗号受信者を個別に記録する必要がある。アイデンティティ信頼境界と参加者開示境界は別だが、どちらも B2BUA が出力を新しく構成した結果である。

URI の method はサービス権限を上書きできなかった

SIP URI は疑問符以降に header component を含められる。サービスは Accept-Contact などを項目ごとに採用できるが、特別な body hname は代替本文として使ってはならず、破棄できる。

URI の method parameter が別のメソッドを要求しても、MESSAGE リストサービスは MESSAGE だけを生成し、その parameter を無視しなければならない。リスト中のデータがサービスを INVITE 発行者などへ変える権限はない。

どの component を採用、拒否、無視したかを記録すれば、入力ヒントとサービスポリシーを区別できる。最終要求だけを見て、呼び出し側の全希望が実行されたと推定してはならない。

202 は配送より前の証拠だった

サービスは入力 MESSAGE に 202 Accepted を返す。RFC は、この応答が生成された MESSAGE の成功した配送について何も知らせないと明記する。受信して試行するという限定された事実である。

非同期応答としてそれは正しい。問題はダッシュボードが「受付」を「送信」、さらに「配送」へ名称変更するときに起きる。後続の SIP 応答、アプリケーション受領証、端末上の効果が必要なら、それぞれ別の観測を得なければならない。

RFC 5363 は結果の複数性を広く扱う。本稿の焦点は、それに先立つアイデンティティと信頼の再構成である。同じ本文を運ぶ新規要求が、どの識別主張を伴えるかは出力側で改めて決まる。

登録名は実行の正しさを保証しなかった

IANA は recipient-list-message と関連 disposition を登録する。共有名は能力交渉と構文解析を可能にするが、特定サーバーが PAI、Privacy、realm、暗号本文、配送を正しく扱ったことは証明しない。

RFC 5365 は 2008 年 10 月に Standards Track として公開された。RFC 3851 は RFC 8551 を含む S/MIME の系譜で後に obsolete となった。現行実装は新しい暗号仕様を選びつつ、受信者と信頼境界の原則を保持すべきである。

Lu Heng の Minimum Initial Specification は、最小の共有契約だけを標準化し、将来の判断を現地情報を持つ主体へ残すという分析視点を与える。Reality Layers は、同じ値という象徴的証拠を同じ現実と取り違えないよう促す。プロトコル事実の根拠は RFC と IANA であり、二つのノートは明示された解釈枠である。