RFC 3087：留守番電話URIは認証ではなかった

要約

RFC 3087では、SIPクライアントやプロキシが異なるRequest-URIを選び、伝言の預かり、特定の応答メッセージ、取り出し、暗証番号の入力といった最初の状態をアプリケーションに伝えられた。
URIが選ぶのはローカルに設定された動作である。発信者の身元、メールボックスへの権限、転送理由の真偽、録音や再生の完了までは証明しない。

呼は届いても、昔の手掛かりは届かなかった

従来のボイスメールは、着信番号、発信番号、転送理由から開始位置を決められた。話中なら話中用の案内、無応答なら別の案内を再生する。契約者が自席の電話から録音を聞くときは、ボックス番号の入力を省くこともできた。便利さは、交換網が渡す各信号をサービスが信じられることに依存していた。

SIPの経路はもっと可変だった。要求は複数のプロキシで別の宛先へ向け直される。一方、Toは最初の論理的な相手を保持し得る。RFC 3087の例では、AがBを呼び、BがCへ全転送し、Cが自分の留守番電話へ転送する。そこでTo: Bだけをボックス選択に使えば、CのサービスがBの情報を探してしまう。

2001年4月にInformationalとして公開されたRFC 3087は、新しいSIPメソッドもヘッダーも定義しなかった。RFC 2543に既にあった差を使った。Toとは異なり、Request-URIはプロキシが現在の利用者やサービスに合わせて書き換えられる。その宛先をサービス固有の識別子にすれば、アプリケーションの開始状態も選べる。

小さな用法に見えて、責任の置き場所は変わった。到着したアプリケーションが壊れやすい履歴から文脈を推測するのではなく、上流の経路選択が明示的な結果を渡すことになった。

一つのサービスに複数の入口を設ける

文書は、一人の契約者に複数のSIP識別子を用意する。通常の案内で伝言を預かる入口、話中用の案内を出す入口、特別な案内を出す入口がある。録音を聞く場合も、SIP認証済みの要求を受ける入口と、音声で暗証番号を求める入口を分けられる。汎用入口は、まず対象のボックスを利用者に尋ねる。

find-meプロキシは状況に応じて入口を選べる。連絡先を試しても応答がなければ通常の預かり先へ、すべて話中なら話中用の宛先へ、着信拒否の設定なら別の案内へ送る。留守番電話側はToやFromから上流の判断を復元せず、既に選ばれた現在の宛先を受け取る。

ただし、URIに読める単語が入っていても、標準化された命令語ではない。RFC 3087は、アプリケーションが覚えやすい文字列に固有の意味を課さないよう求めた。運用者はdeposit、番号、パラメータ付きの名前、その他の有効なSIP URIを設定できる。識別子を動作へ結び付ける辞書は、そのシステムが管理する。

したがって、パケット記録にbusyが見えても、実際に話中だった証拠にはならない。そのホップで文字列が宛先になったことは示せる。意味と選択理由を確かめるには、当時の設定とプロキシの書き換え記録が要る。

入口を知ることと、鍵を持つことは違う

取り出しの例は、サービス選択と入場許可をはっきり分ける。安全な関係を持つ保護プロキシに認証を委ねてもよい。SIP認証が成功した要求だけを受け入れてもよい。認証に失敗したり認証情報がなかったりすれば、暗証番号入力用のURIへ送り直せる。

契約者専用に見える取り出しURIは、処理の入口を選ぶだけで、録音への権限を自動で与えない。信頼関係、SIP資格情報、または暗証番号が次の門を開く。PSTNの発信番号をゲートウェイが認識しても、それは事業者が採用した推定であり、話している人の暗号学的証明ではない。

RFC 3087の詳細なフローは、留守番電話を保護するプロキシと、両者の信頼関係を前提にする。セキュリティ節は新しい防御を追加せず、SIPの考慮事項へ戻している。

よって観測記録から言えることは段階ごとに限られる。INVITEを受けた、プロキシがあるRequest-URIを選んだ、アプリケーションが受理した、認証の分岐を通った、RTPが成立した。どれも単独では、人がボックスの所有者であること、転送理由が正しいこと、録音が永続化されたこと、後に誰かが聞いたことを証明しない。

ローカル設定から相互運用の語彙へ

RFC 3261は初期SIP仕様を置き換えたが、Request-URIが現在の利用者またはサービスを示し、プロキシが対象を選ぶ際に置き換える仕組みは残った。後のHistory-Infoは、方向転換の履歴を運ぶ方法を整えた。これらは層の違いを理解する資料であり、特定のRFC 3087実装が利用した証拠ではない。

2006年のRFC 4458は別の不足を示す。留守番電話や音声応答向けにtargetとcauseというURIパラメータを定めた。各ベンダーが任意の対応表を設定可能にしても、異なる呼制御、ゲートウェイ、統合メッセージ製品の間では共通表現にならない、という問題意識だった。

RFC 3087は、URIをサービス文脈の制御面に使う構造を示した。RFC 4458は、ボックスと理由を実装間で共有する語彙を与えた。後者の存在だけから、前者の普及や失敗を推定することはできない。

残る教訓は、証拠を一列に潰さないことだ。元の相手、現在のRequest-URI、書き換え理由、ローカル対応表、認証結果、最初のメニュー、メディア、保存記録は関係しているが別の事実である。経路に文脈を載せれば推測は減る。それでも経路は身元にはならない。

URIは留守番電話のメニューを選んだ。それでも発信者を認証してはいない――RFC 3087

なぜ重要か

要約

呼は届いても、昔の手掛かりは届かなかった

一つのサービスに複数の入口を設ける

入口を知ることと、鍵を持つことは違う

ローカル設定から相互運用の語彙へ

情報源

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説