要約

  • RFC 5360 の permission は relay の translation logic に結び付く。管理者の追加要求が HTTP 202 で受理されても、候補 URI は pending であり、最終受信者の許可はまだない。
  • permission document は sender、target URI、final recipient と grant/deny capability を結ぶ。capability を使った主体の認証、状態への導入、後の要求との一致はそれぞれ別の証拠である。
  • 一取引一受信者、470 Consent Needed、更新、削除、Trigger-Consent は増幅と古い権限を抑える。ただし正しい fan-out、端末到達、人の認知、取消し後の停止を単独では証明しない。

取消しは意思ではなく状態変更で終わる

最初の permission document には grant と deny のための URI が含まれる。受信者が deny URI を保持していれば、relay に拒否を送れる。しかし長期間の利用では、メール、端末、履歴や保存先が変わり、その capability を失うことがある。

その場合、relay が後の要求に Trigger-Consent と target URI を付ける。受信者は trigger へ PUBLISH し、新しい permission document を受け取り、そこから deny を実行する。

この連鎖には複数の境界がある。最初の PUBLISH に対する 200 は回復要求の受理であり、古い permission の削除ではない。MESSAGE の到着は新しい文書の配送であり、拒否ではない。最後の deny を認証し、active translation state を更新して初めて権限が変わる。

証跡には取消し意思、trigger capability、target、recipient、新文書、認証方法、deny、状態版、cutover 時刻、旧権限で最後に出た要求を残す。同時進行中の要求をどちらの状態で扱うかも定義する。

回復経路があることは、いつでも即座に取消せた証明ではない。

translation logic が権限の実行面である

relay は入力 Request-URI、つまり target URI を、一つ以上の recipient URI に変換して出力要求を作る。proxy、B2BUA、hybrid のいずれでもよい。

一対多は小さな入力を多くの出力に増幅し、一対一でも望まない相手へ向けることができる。そこで RFC 5360 は permission を relay の translation logic と一緒に保持する。

未許可の recipient は変換時に無視される。管理画面の list entry や申請ログだけでは足りない。出力を作るコンポーネントが、実際に参照した permission set とその版を示す必要がある。

運用証拠は sender scope、target、recipient、permission document、状態版、出力 request ID を結ぶ。DB に grant が存在しただけでは、古い cache や別 tenant の mapping を読まなかったことを示せない。

proxy と B2BUA では識別子や対話の保管も異なる。relay の役割と終端境界を具体的に記録する。

管理権限は他人の同意を包含しない

list を変更する client の認証と認可は必要である。しかし正規の管理者でも、受け取りたくない人を追加できる。

管理者は membership を提案する権限を持つ。final recipient は、その target から自分へ relay が変換することを許す権限を持つ。この二つは同じ principal である必要がない。

監査では、誰がどの policy で追加を提案したかと、誰がどの permission tuple を grant/deny したかを分離する。「authorized admin が追加した」という一行は受信者の判断を消してしまう。

group name の所有権、設定ファイルの編集権、個々の address が受け取ることへの同意を混ぜない。

HTTP 202 は pending を作る

典型例で A は XCAP を使って B を追加する。relay は HTTP 202 を返し、B を pending に置く。その後 permission document を含む MESSAGE を送り、B が offline なら store-and-forward が保管する。

202 が証明するのは、relay が操作を処理対象として受け付けたことだけである。B が読んだ、許可した、translation が install された、後の要求が送られた、という意味ではない。

Pending Additions event package は pending、waiting、error、denied、granted を知らせる。offline で保管サービスがない場合は delivery error になり得るため、client は初期応答とは別に結果を受け取る。

操作 ID、target、候補 recipient、202、各 NOTIFY、状態版を保存し、granted を文書 hash と認証された行為へ結び付ける。

permission document は汎用の「はい」ではない

文書は sender identity、original recipient または target、final recipient、grant/deny URI を持つ。sender や target は条件により wildcard になり得るが、final recipient は wildcard にしてはならない。

この tuple により、受信者は特定の変換関係を選べる。しかし UI が wildcard を隠したり、human-readable part と machine part が違えば、正しく click しても別の権限になる。

原文 byte、hash、format version、relay、sender、target、recipient、capability hash、表示文を保存する。表示前に二つの表現を比較し、後の runtime match も同じ tuple に対して行う。

alias の付け替えや sender 集合の拡大で、過去の grant が無言で新しい意味を得てはならない。

空の PUBLISH にも認証範囲がある

受信者は grant/deny URI へ body のない SIP PUBLISH または HTTP GET を送る。body が空なのは capability 自体が permission を指すためであり、行為が context-free だからではない。

relay は final recipient の owner が生成したことを確認する。SIP Identity、trusted domain 内の P-Asserted-Identity、shared secret を使う Digest、return routability が示される。

証明範囲は異なる。asserted identity は行政境界、Digest は secret と challenge、署名 identity は owner 比較、return routability は秘密 URI の受領に依存する。

単一の authenticated flag ではなく、method、principal、recipient URI、trust context、capability hash、policy version、結果を記録する。

別人の正しい credential は、対象 recipient の同意にはならない。

return routability は capability の到達を測る

relay は推測困難な URI を permission request に入れる。受信者がそれを使えば、少なくともその capability を得たことが分かる。

仕様は MESSAGE を SIPS URI へ送ること、grant/deny も SIPS または HTTPS にすること、random part に少なくとも 32 bit の暗号学的乱数を持たせることを要求する。

それでも永続的な本人性、理解、継続支配までは証明しない。store-and-forward の copy や履歴が漏れれば、予定外の主体が形式上有効な操作を行える。

generator、entropy、capability hash、protected route、redeem time、replay handling を保持し、再利用可能な平文を普通の log に残さない。

後に SIP Identity を必須にするなら acceptance policy が変わる。古い証拠を新しい強度へ格上げしない。

一取引一 recipient は帯域の credit である

一回の list edit で大量 URI を追加できると、relay は各 URI へ permission MESSAGE を送り、攻撃者の小さな入力を大きく増幅する。

RFC 5360 は XCAP の一 HTTP transaction につき一 recipient、REGISTER では一 contact に制限する。追加者の入力量を relay の出力に近付ける仕組みである。

これは全体 rate limit ではない。多数の transaction、account、低速 campaign は残る。瞬間的な倍率を抑えるが、善意を証明しない。

client identity、target、recipient、byte、rate、409/403、retry を監視し、必要なら account・target・destination の aggregate budget を追加する。

store-and-forward が同じ request を繰り返して遅延増幅を作らないことも確認する。

一つ足りなければ 470 で全体を止める

request-contained URI list は通信時に recipients を選ぶ。relay は permission を取得済みの URI 全体を保持し、今回の list がその部分集合かを調べる。

一つでも permission がなければ、translation を実行してはならず、470 Consent Needed と Permission-Missing を返すべきである。

許可済みだけに先に送る partial fan-out は、error を返す前に不可逆の効果を起こす。結果差から member 構成が漏れる可能性もある。

入力 list hash、permission set version、各 match、470、missing set を記録する。missing set 自体も sensitive である。

取得した errata page は Permission-Missing の URI punctuation と angle brackets に関する一件の Reported 技術報告を表示する。これは dated snapshot であり verified correction ではない。

context が消えれば permission も消える

recipient を translation logic から外すなら、その permission も削除すべきである。登録 contact が expire または terminate した場合も同様である。

relay は periodic refresh を要求することが推奨され、一定期間更新がなければ削除すべきとされる。ただし interval は application ごとに違うため RFC は一つの値を決めない。

したがって「deny が来ていない」は永続 grant の証拠ではない。service existence、membership、registration、refresh policy と last confirmation を同時に評価する。

復旧や backup でも permission だけを古い context へ戻してはならない。state restore は target、recipient、policy version と一体で検証する。

third-party REGISTER は別人への変換を作る

通常、同じ UA が contact を登録し、その connection で受信するなら binding と利用許可の主体が一致する。third-party REGISTER では攻撃者の AoR を victim contact に結び付けられる。

この場合 202 は contact を pending にし、registrar が permission を求める。Pending Additions が後の grant/deny を知らせる。

AoR、contact、registrant principal、connection、third-party 判定、permission tuple、forwarding decision を保存する。

すべての REGISTER に追加手順が必要という主張ではない。same-connection case や third-party registration を許さない policy は別である。どの前提を使ったかを明示する。

channel security と consent semantics を分ける

permission document は関係と capability を含むため sensitive であり、改変されれば user が別の translation を承認し得る。

RFC 5360 は強い integrity/confidentiality、可能なら end-to-end S/MIME、そうでなければ TLS/SIPS を述べる。store-and-forward の client interface が SIP でなくても protected delivery が必要である。

しかし暗号は readable part と machine part の一致、wildcard の表示、正しい principal の理解、同じ tuple の install と runtime enforcement を証明しない。

表示と原文 hash を結び、transport、content integrity、identity、interpretation、execution の receipt を分ける。mutation、replay、leak、stale state を試験する。

RFC 8217 は syntax context を更新する

RFC 8217 は RFC 5360 を含む SIP 文書に対し、name-addr production を使う条件を明確化した。現在の parser test はこの normative set と software version を示すべきである。

update relation は製品が採用した証拠ではない。Proposed Standard であることも、現在の deployment、interoperability、incident を証明しない。