要約

  • RFC 5344はPresenceとインスタントメッセージのピアリング利用例を整理した情報文書であり、新しいプロトコルや実装済みの安全性を規定しない。
  • 個人、公開、一時リストへの購読は一つの要求を複数の判断へ展開する。リストを使える権限と、各presentityが各watcherに情報を開示する権限は別物である。
  • 監査可能な運用には、展開時点の構成、各メンバーの承認、適用したprivacy変換、通知結果を結びつける証跡が要る。

一つの宛先が多数の当事者になった

RFC 5344は単純なドメイン間購読に加え、URIで表されたリストへの購読を扱う。個人リストはwatcher自身が管理する。公開リストは管理者が共通属性を持つ人々をまとめる。一時リストは会議やゲームなど特定活動の間だけ使われる。

どの型でも、入力は一つでも結果は複数である。RFC 5363はURIリストサービスを、一つの要求を受け取り複数の類似要求を送る機能として扱い、リストの完全性、機密性、許可、増幅攻撃に注意を求める。RFC 5360も、一つのtarget URIを複数のrecipient URIへ変換するrelayを同意の問題として捉える。

ここで最初の境界が生まれる。Aliceが自分のwatch listを作れることは、そこに入れた全員がAliceへPresenceを開示したことを意味しない。公開グループの管理者は構成を決められても、各メンバーのprivacy ruleを代行できない。一時リストの参加資格も、現在の位置や活動を全員に見せる許可とは限らない。

したがって承認は展開後に行う必要がある。リストサービスは「このURIは許可済み」と一回判断して終われない。展開された各presentityとwatcherの関係を、当該時点の規則で評価しなければならない。

構成はアドレスではなく状態である

URIが変わらなくても、リストの意味は変わる。会議参加者が追加され、退席者が削除され、管理者が交代し、外部ドメインのアカウントが別名に置き換わる。購読開始時の構成とNOTIFY生成時の構成が同じとは限らない。

記録にリストURIしかなければ、後日どのメンバーを対象にしたか再現できない。必要なのは、展開時のversionまたはmembership digest、変更主体、展開時刻、各宛先の処理結果である。拒否されたURIを応答に含める場合、その応答自体がメンバー情報を漏らし得る点も考慮する。

一つの要求が大量の出力を生むため、入力側だけのrate limitも不十分である。展開数、ドメイン数、再試行、同時購読数を観測しなければならない。小さな正規要求が大きな負荷を作ることは、RFC 5363が示す設計上の性質であり、障害が起きた証拠ではない。

Presenceの許可はフィールドごとに違う

Presence文書は単なるonline/offlineではない。RFC 5025の変換はperson、device、service、activity、mood、place、relationship、noteなどの可視性を制御する。RFC 4745ではruleがcondition、action、transformationから成り、認証済みrequestor identityが条件になり得る。

そのため、一人のメンバーに購読を許可しても、全フィールドを許可したことにはならない。同じリスト内でも、同僚にはavailabilityだけ、家族にはplaceも、ブロック対象には情報を含まないviewを返す、といった差が成立する。

リスト型購読で効率を優先すると、この差をどこで作るかが問題になる。発信側が各viewを生成すれば通信量が増える。RFC 5344のauthorization migrationでは、完全なPresence文書とprivacy情報を相手ネットワークへ渡し、相手がwatcherごとにviewを作る。別案では、異なる文書をそれぞれ対象watcherのリストと結びつける。

どちらもリストを証拠化しなければならない。委託型なら、相手が用いたwatcher identity、policy version、変換結果が要る。viewとwatcher-listを送る型なら、両者が同じ版として原子的に扱われた証明が要る。文書だけ正しくても、対象集合がずれれば開示は誤る。

ピアの認証はメンバーの本人確認ではない

RFC 5344のsecurity considerationsは、相手が名乗るPeer Network本人であること、通信の真正性と機密性、相手が第三者へ漏らしたり改ざんしたりしないこと、Clearing Houseも安全であることを問題にする。

これはネットワーク間で不可欠だが、個人の同一性までは証明しない。TLS証明書は接続先を示し、federation membershipは管理規則への参加を示す。どちらもリスト内のAliceの外部識別子がローカル規則のAliceと同一であることを自動的には示さない。

別名、SIP URIとtel URI、アカウント統合、複数のasserted identityにより、正しいドメインから間違ったprincipalが届くことは設計上あり得る。証跡にはidentity assertionの発行者、検証方式、正規化前後の値、policy matchingに用いた値を残す必要がある。

RFC 6271はprivacy設定の共有には本人の明示的同意が必要だとする。その同意も、リストの将来の全メンバーへ無期限に開示する許可ではない。委託先、目的、期間、取消方法を限定しなければならない。

Clearing Houseはリストの目撃者にすぎない

中央型federationは接続を簡素化し、ログ、多人数chat、法的interceptionなどを提供できる。だがhubが記録したリストURIは、展開後の全処理を証明しない。hubが展開したのか、宛先Peerが展開したのかで観測範囲も変わる。

ログは、受信要求、構成snapshot、出力要求、拒否、再試行、変換、宛先応答を区別すべきである。中心ログを完全と呼ぶ前に、発信Peer、hub、受信Peerの件数を照合し、差をdeduplication、expiry、policy rejection、障害で説明する必要がある。

また、hubが完全なPresence文書やprivacy ruleを保持すれば、通常のwatcherより豊富な情報を集める。暗号化通信は経路を守っても、内部保管や正しいfilteringを保証しない。保存期間、アクセス、削除、監査をデータ種別ごとに分けるべきである。

MESSAGEの成功は読了ではない

リストサービスは複数宛先のSIP MESSAGEにも使われる。RFC 5365がFromやPrivacy、P-Asserted-Identityの扱いを細かくするのは、サービスが受信要求から新しい送信要求を作るからである。identityのコピーや抑制は単純な配線ではない。

SIP responseは、あるcomponentがrequestを受け付けた、拒否した、または処理したことを示す。人が読んだことまでは示さない。RFC 5344が挙げるMSRP sessionは別のtransaction/reportモデルを持つ。pager modeとsession modeを一つの「配信済み」にまとめてはならない。

運用表示は、Peerへrouting、remote serviceでaccept、recipientへ展開、clientへ到達、表示またはacknowledge、応答という段階を分ける。欠けた段階はunknownのまま残す。

形式が同じでも意味は変わる

RFC 6271は、ある独自システムの「Do Not Disturb」が別システムで「Busy」にmappingされる例を挙げる。標準PIDFを使っても、元の意味が保存されたとは限らない。

監査には入力値、mapping tableの版、出力値、処理componentが必要である。値がない場合も、元からない、privacyで削除、未知属性、stale dataを区別する。リスト型通知が大量になるほど、この意味のずれは同じmappingで広く複製される。

証拠の限界

ここで参照した文書は標準のモデル、要求、仕組みを示す。特定の製品、federation、Clearing House、アカウントが現在どう動くかは証明しない。本文の場面は制御を考えるためのscenarioであり、報告済みincidentではない。RFC 5344はInformationalで、安全解決策を範囲外としている。

文書が示すのは分離すべき証拠であり、実装済みという事実ではない。