要約

  • P-Preferred-Identity は、認証された利用者に有効な複数の身元から一つを選ぶための希望にすぎず、プロキシは転送前に必ずその希望を取り除く必要があった。
  • 信頼されていない側から届いた P-Asserted-Identity は、正しい名前のヘッダーでも証拠にはならない。プロキシが認証結果から作り直すか、完全に削除しなければならなかった。

身元を選ぶ者と、身元を保証する者

SIP の From は、会話の相手に見せたい名前や別名を利用者が提示できるようにしていた。しかし、電話サービスの運用者が発信者番号通知、追跡、認可などに必要とする値は、それと同じではない。さらに、運用者が内部で知る身元を受信者には見せたくない場合もある。RFC 3325 は一つの「強い From」を作らず、提示、選好、表明を別々の行為として扱った。

P-Preferred-Identity を書くのはユーザーエージェントである。認証された加入者に複数の有効な番号や URI が割り当てられていれば、そのうちどれを使いたいかを最初の信頼済みプロキシへ知らせられる。だが、それは候補の指定であって、所有権や本人性の証明ではない。P-Asserted-Identity を作るのはネットワークであり、認証した結果、または信頼済みの隣接ノードから受け入れた結果を表す。

信頼されていない端点から希望が届いたとき、プロキシはまず発信者を認証し、その人物に有効な身元の集合と値を比較する。一致すれば選択に利用できる。一致しなければ別の有効な身元を選ぶか、要求を拒否できる。利用者の入力をそのままネットワークの表明へ昇格させることはできない。

そして判断が終わると、プロキシは転送するすべてのメッセージから P-Preferred-Identity を削除する。ここが仕様の核心である。希望と表明が並んで残れば、後のログ解析や業務システムは、同じ入力を「利用者の申告」と「ネットワークの確認」という二つの証拠として数えかねない。削除は、判断に使った材料と判断の結果を混同させないための来歴管理だった。

偽の権威は注釈せず、壊して作り直す

信頼されていないメッセージに P-Asserted-Identity がすでに含まれる場合、問題はさらに明確になる。ヘッダー名を知っていることは、信頼域を代表して発言する資格ではない。プロキシが表明を加えるなら、発信者を認証し、その手続きから得た身元を使わなければならない。

入力に SIP または SIPS の表明値があれば、プロキシは自ら構成した一つの SIP または SIPS 身元に置き換えるか、ヘッダーを削除する。電話 URI にも同じ規則が適用される。古い値を残して「未検証」と印を付ける方式ではない。信頼チャネルへ入る前に、偽の権威そのものを消す必要があった。

一方、信頼済みノードから受けた P-Asserted-Identity は、自分で利用者を認証した場合と同様に扱える。ただし、その短縮は RFC 3324 が描いた Trust Domain の条件に依存する。安全な接続、設定されたメンバー、認証方式、チャネル保護、プライバシー既定値、順守条件を記す Spec(T) があって初めて成立する。

このヘッダー自体は暗号学的な証明書ではない。仕様の適用範囲は、どの個別ノードが表明したかを暗号的に示さず、信頼域全体がその値を表明したものと仮定すると説明している。前提を満たさない環境では偽造、再送、改変が可能であり、一般のインターネット全体に通用する身元証明ではなかった。

外へ出す直前に、もう一度消す

入口で身元を再構成しても仕事は終わらない。各プロキシは次のホップを信頼できるか判断する。信頼できる相手なら、自分が作った表明または信頼済み上流から受けた表明を保持できる。信頼できない相手へ送るときは Privacy を確認する。

id トークンは、未信頼要素へ転送する前にすべての P-Asserted-Identity 値を削除するよう要求した。反対に none は、プライバシーを理由に表明を削除しないよう要求する。Privacy がなければ、Spec(T) の域内方針が決める。RFC はサービス破壊を避けるため保持を推奨しつつ、適切なプライバシーサービスを利用できない人には、望んでいない情報開示を防ぐ手段がない危険も明記した。

表明値は一つの場合もあれば、SIP または SIPS の身元と電話の身元を一つずつ持つ場合もある。プライバシーが適用されれば全値を削除しなければならない。一方だけを消すと、同じ主体の別表現が境界を越える。

受信側にも対称的な規則がある。直前の要素が信頼できなければ、ユーザーエージェントは P-Asserted-Identity をいかなる用途にも使ってはならない。適切な信頼域内で受けた場合のみ、実装やサービス方針が表示や利用を決められる。複数形式の値をどう見せるかまで RFC は決めていない。

RFC 5876 は後に RFC 3325 の細部を更新した。RFC 4474、RFC 8224、RFC 8225 は認証済み身元や PASSporT の異なる仕組みを進め、RFC 4916 はダイアログ中の接続先身元を扱った。それでも初期設計の教訓は残る。権威は特別そうな文字列に宿らない。認証し、有効集合を限定し、選び、再構成し、希望を削除し、次ホップを分類し、必要なら表明まで削除する一連の操作によって生まれる。

RFC 3325 は、正当な利用者入力でさえ証拠として保存すべきでない場合があることを示した。プロキシは希望を聞いたから信頼されたのではない。その希望を自分の出力と混同させず、消す責任を引き受けたからこそ、表明に責任を持てたのである。

出典