Network Working Group J. Peterson Request for Comments: 3323 Neustar Category: Standards Track November 2002 セッション開始プロトコル(SIP)のためのプライバシーの仕組み A Privacy Mechanism for the Session Initiation Protocol (SIP) 本文書の位置付け 本文書は、インターネットコミュニティのためのインターネット標準 トラックプロトコルを規定するものであり、改善のための議論や提案を 依頼するものである。標準化の手順や、プロトコルの位置付けについては、 最新版の「Internet Official Protocol Standards」 (STD 1)を参照されたい。 本文書の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 要旨 本文書は、プライバシーに対応するSession Initiation Protocol (SIP)のための新たなメカニズムを定義するものである。特に、個人の身元に 関する情報を隠すメッセージを生成するためにガイドラインが提供される。 ユーザーエージェントが自身では満足できないプライバシー要件に答えるた めに、中継媒体(intermediaries)にとって新たな「プライバシーサービス」の 論理的役割が定義される。最終的に、ユーザーがプライバシーサービスから特 定の機能の要求方法が提示される。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 述語規則 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 様々なプライバシー . . . . . . . . . . . . . . . . . . . . 4 3.1 プライバシーはいつ必要か? . . . . . . . . . . . . . . . . 5 3.2 ユーザー提供のプライバシー . . . . . . . . . . . . . . . . 6 3.3 ネットワーク提供のプライバシー . . . . . . . . . . . . . . 7 4. ユーザーエージェントの動作 . . . . . . . . . . . . . . . . 7 4.1 プライベートメッセージの構築 . . . . . . . . . . . . . . . 8 4.1.1 URI、表示名とプライバシー . . . . . . . . . . . . . . . . 8 4.1.1.1 表示名 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1.2 URIのユーザー名 . . . . . . . . . . . . . . . . . . . . . 9 4.1.1.3 URIのホスト名とIPアドレス . . . . . . . . . . . . . . . . 9 4.2 プライバシープリファレンスの表現 . . . . . . . . . . . . . 11 4.3 リクエストのプライバシーサービスへのルーティング . . . . . 12 4.4 レスポンスのプライバシーサービスへのルーティング . . . . . 13 5. プライバシーサービスの動作 . . . . . . . . . . . . . . . . 14 Peterson Standards Track [Page 1] RFC 3323 Privacy Mechanism for SIP November 2002 5.1 ヘッダーのプライバシー . . . . . . . . . . . . . . . . . . 16 5.2 セッションのプライバシー . . . . . . . . . . . . . . . . . 17 5.3 ユーザーレベルのプライバシー機能の適用 . . . . . . . . . . 18 6. セキュリティの考慮 . . . . . . . . . . . . . . . . . . . . 19 7. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . 19 規範的な参考文献 . . . . . . . . . . . . . . . . . . . . . 20 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . . 20 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . 21 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 完全な著作権表記 . . . . . . . . . . . . . . . . . . . . . 22 1. はじめに 本文書はSession Initiation Protocol (SIP)のためのプライバシー 要件とメカニズムを提供する。 本文書では、プライバシーとは、個人のアイデンティティ(またそれと関連する 個人情報)を、通信の交換時、特にSIPダイアログで、1つ以上のパーティから隠 すこととして定義されている。これらのパーティとは、メッセージの対象とな る送信先(destination)、および(または)、これらのメッセージをハンドリング する中継媒体を潜在的に含んでいる。本文書でアイデンティティが定義される と、ユーザーのアイデンティティを隠すことによって、ダイアログ内の相手は、 特に、カンレントダイアログのコンテキスト外のユーザーへ新規のSIPリクエス トを送信できなくなるだろう。 SIPでは、アイデンティティは、最も一般的な方法では、SIP URIとオプション のディスプレイ名のフォームで運ばれる。SIPのAddress-of-Recordは、SIP URI のスキームについてemailアドレスと似たフォームを持つ(例えば、sip: alice@atlanta.com)。表示名は、識別されたユーザーの名前を含む文字列であ る(例えば「Alice」)。このフォームのSIPのアイデンティティは、一般に、SIP リクエストおよび応答のToおよびFromヘッダーフィールドにある。ユーザーは、 異なるコンテキストで使用する複数のアイデンティティを持っているかもしれ ない。 SIPメッセージには、他にもアイデンティティ関連の情報が明かされている多く の場所がある。例えば、ContactヘッダーフィールドはSIP URIを含むが、それは 一般的に、FromのAddress-of-Recordと同様に情報を明かすものである。いくつ かのヘッダーでは、SIPプロトコルの操作に影響を与えずに、発信元ユーザーエー ジェントはローカルポリシーの問題としてアイデンティティ情報を隠すことが できる。だが、あるヘッダーは、ダイアログで続くメッセージのルーティング 時に使用されるため、機能的なデータとともに組み込まれなければならない。 Peterson Standards Track [Page 2] RFC 3323 Privacy Mechanism for SIP November 2002 プライバシー問題は、自身のヘッダー、例えばRecord-RouteやViaヘッダーを追 加するプロキシサーバー(本文書では「中継媒体」または「ネット ワーク」とも呼ぶ)によって、さらに複雑になる。これらヘッダーの情報は、 メッセージの発信元に関するものを不注意に明かしてしまう可能性がある。 例えば、Viaヘッダーは、ユーザーがリクエストを送信する際に利用したサー ビスプロバイダを明かすかもしれない。それは言い替えると、ある受信者に とって、ユーザーのアイデンティティについての大きなヒントになりうるので ある。これらの理由から、中継媒体が入ることは、SIPにプライバシーを提供す る上で重要である。 このプライバシーの設計に、以下の相補的な2つの原則が導かれる。 ユーザーは、リクエストを発行する際に、アイデンティティと関連する個人情 報を隠す権利がある。だが、中継媒体とリクエストで指定された受信者は発信元 が識別できないリクエストを拒否する権利がある。 既存のまたは作成中の拡張で定義されるヘッダーとは異なり、SIPの基本仕様 ([1])で列挙されている特定のヘッダーに限ったプライバシーの特徴が、本文書 で議論される。だが、拡張に対応するために、このドキュメントドラフトで記 載されるプライバシーのメカニズムを拡張することもできる。 SIPについて、本文書で述べられていない、一般的なプライバシー問 題の側面がある。最も重要なのは、SIPヘッダーとボディの機密性を管理するた めのメカニズムが、セッショントラフィックのセキュリティと同様に、ここで 再考されないことである。これらの問題は基本となるSIP仕様や関連ドキュメン トで十分に述べられているため、新たなメカニズムは必要ない。 本文書は、SIPにおけるプライバシーのための一般的なフレームワー クとアーキテクチャを提供するセクションから始まり(セクション3)、詳細な ユーザーエージェントの動作や(セクション4)、プライバシーサービスの動作 (セクション4)に続く。 2. 述語規則 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、 「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC2119(参考文献 [2])のBCP14に記述されているとおりに解釈され、SIPに準拠した実装のための 要求レベルを示す。 Peterson Standards Track [Page 3] RFC 3323 Privacy Mechanism for SIP November 2002 3. 様々なプライバシー ユーザーは、様々な背景で使用される多くのアイデンティティを保持する可能 性がある。一般的に、アイデンティティはAddresses-of-Recordであり、それは SIPユーザーエージェントが登録する、(ドメインの管理者に操作される)特定の 登録サーバーに結びつく。これらドメインを操作するのは、雇用主やサービス プロバイダ、外部のユーザー自身の可能性がある。 ユーザーが自発的にリクエストでアイデンティティをアサートする場合は、 そのユーザーは、そのドメインにおいて自分のアイデンティティへ送信された リクエストを受信できることを主張しているのである。厳密に言うと、プライ バシーは、特定のパーティまたは潜在的にメッセージの受信者であるパーティ から受け取る特定のアイデンティティと関連する個人情報について、配布の制 限を伴う特に、匿名性を望むパーティが以下のようにできるシナリオがある。 1つ以上の中継媒体とアイデンティティを伝達しながら、メッセージ送信し、 最終送信先からアイデンティティを隠す メッセージを送信し、いくつか、またはすべての中継媒体からアイデンティ ティを隠すが、最終送信先とのエンドツーエンドではアイデン ティティを伝達する 中継媒体、最終送信先の両方からアイデンティティを隠す アイデンティティを隠した結果、問題のパーティは、例えば、後で匿名パー ティとの新規ダイアログを開始することが試行できなくなるかもしれない。 だが、匿名のパーティは、参加しているダイアログ中で、応答や新規のリクエ ストを受信できなければならない。 リクエストと応答の両方についてアイデンティティ情報を制限することが望ま しいかもしれない。まず、応答にプライバシーに対する懸念があると仮定するの は例外的なことだろう。おそらく、リクエストの発信元は誰にコンタクトしよ うとしているかをわかっているため、応答者のアイデンティティが秘密である ことはほとんどありえない。だが、応答中のいくつかの個人情報(例えば受信者 が現在登録されているコンタクトアドレス)は、プライバシーついての懸念の対 象になり、また、これらのメカニズムで扱われる可能性がある。 Peterson Standards Track [Page 4] RFC 3323 Privacy Mechanism for SIP November 2002 3.1 プライバシーはいつ必要か? ユーザーは、以下の例のように様々な理由から、特定のパーティに対してアイ デンティティ情報を隠すことを望むかもしれない。 ユーザーは、仲間に加わりたくないという情報を伝えるために、自分のアイ デンティティを明かさずに、特定のパーティにコンタクトしたいかもしれ ない。 ユーザーは、アイデンティティや個人情報をネットワークや送信先に公開することによって、勝手に送信される広告や法的な検閲、その 他の望まない影響を受ける対象となることを恐れるかもしれない。 ユーザーは、請求処理や課金処理の目的のためにネットワークの中継媒体に 知られているアイデンティティを、セッションの参加者から隠したがって いるかもしれない。 ユーザーエージェントがプロキシサーバーを通してリクエストを送信すると 決めた場合、発信元にとって、メッセージの最終送信先を予測す るのは困難かもしれない。その理由から、ユーザーは、メッセージが行くと予 想する場所に基づいて、自分のプライバシーの必要性に関する推定をしない ようアドバイスされる。例えばユーザーがリクエストを電話番号に送信する と、リクエストの最終送信先は、例えばSIP Contactヘッダーを 調べることのできない公衆交換電話網(public switched telephone network/ PSTN)のステーションだと信じるかもしれない。そのため、そのようなヘッダー を(暗号化せずに)そのままにしても安全であると仮定するかもしれない。だ が、そのようなリクエストは、ネットワークによって、Contactヘッダーが非常 に読みやすいネイティブなSIPのエンドポイントへと改めてターゲットにされる 結果になることはままあるだろう。 本文書は3段階のプライバシーを記述する。 - ユーザー提供のプラ イバシーに関する1レベルと、ネットワーク提供のプライバシーに関する2レベル (ヘッダープライバシーとセッションプライバシー)である。既存のセッショ ンで、どの程度のプライバシーをユーザーは必要としているだろうか? 一般に、ユーザーがプライバシーを求める場合、得られるかぎりの分を必要と するものである。しかし、ユーザーがプライバシーサービスのことを知らない 場合、ユーザー提供のプライバシーのみで満足するに違いない。同様に、 ユーザーがセッションプライバシーを提供することのできる匿名化サービス (anonymization service)を知っている一方で、アノニマイザ(anonymizer)が セッション上の盗聴を防ぐためにセッショントラフィックを保証することが できない場合、ユーザーは、セッションプライバシーの損失の方が、 より害が 少ないと判断するかもしれない。ユーザーはまた、1つ以上のプライバシーの懸 念を取り除くかもしれないユーザーエージェントが配備されるアーキテクチャ という例外的な条件に気付くかもしれない。 Peterson Standards Track [Page 5] RFC 3323 Privacy Mechanism for SIP November 2002 ユーザーは、理想的な条件下においてさえ、いつプライバシーが必要かにつ いて、常に最高の審判になることはできない。そのため、あるアーキテクチャ では、中継媒体によって適用されることで、ユーザーの明示的なメッセージ ごとのリクエストなしに、プライバシーがそうなってもよい。プライバシー の役割を提供することのできる中継媒体を通してリクエストを送信することに よって、ユーザーはプライバシー機能が必要に応じて呼び出されることを 暗に許可している。 中継媒体がユーザーの要求するプライバシー機能を提供できないかもしれない、 ということをユーザーが理解することも重要である。プライバシーに対する リクエストは、法的な制約条件、未実装または誤って設定された機能、または 他の例外的な条件のため、引き受けられないかもしれない。 アイデンティティを隠すのがユーザーの特権であるのと同様に、 識別できないユーザーからのリクエストの処理を拒否することもまた、 プロキシサーバーや他のユーザーの特権でなければならない、ということに 注意。そのため、ユーザーは、すべてのリクエストと応答に対して、単に自動 的にアイデンティティを隠すべきではない。なぜなら、リクエストの発信元の アイデンティティが拒否の材料になることをしばしば確認できないためである。 プライバシーは、ユーザーに必要性があるときのみ、リクエストされるべきで ある。 この点について、さらに、シグナリングにおいて何かの情報を隠すことは、 プライバシーを保証するすべてのユーザーエージェントにとって必要ではない かもしれない。例えば、ユーザーエージェントはIPアドレスとホスト名を動的 に取得するかもしれないし、また、これらの動的アドレスはユーザーに関する どのような情報も明らかにしないかもしれない。これらの場合、ホスト名への アクセスを制限することは(セクション4.1.1.3の記述のように)不要である。 3.2 ユーザー提供のプライバシー ユーザーエージェントが自分自身に提供できる、ある種のプライバシーがある。 例えば、ベースラインSIPの仕様は、ユーザーエージェントがリクエストのFrom ヘッダーフィールドに、匿名の値を組み込むのを許可している。ユーザーは、 関連SIPヘッダーでその他のアイデンティティ情報を不必要に明かすのを防ぐた めに、同様の手段を取ることができる(これについて詳しくはセクション4.1.1で 議論されている)。 メッセージが直接エンドツーエンドではなく中継媒体を通ってトラバースする 場合、ユーザーはメッセージに対して異なるプライバシーのニーズがあるかも しれない。ユーザーは、最終送信先から隠されていない中継媒体 対して、ものごとを隠そうとしてもよいし、また、逆も同様である。例えば、 基本のSIPメカニズムを利用して、中継媒体が検閲できないように、ユーザー エージェントはSIPのボディをエンドツーエンドで暗号化できる。SIPメッセー ジが中継媒体を通らない場合では、この処置は必要ないかもしれない(例: SIP ボディに追加のセキュリティがなければ、低層のセキュリティで十分かもしれ ない)。 Peterson Standards Track [Page 6] RFC 3323 Privacy Mechanism for SIP November 2002 ダイアログが参加者間の直接のエンドツーエンドで行われる場合、参加者の ネットワークアドレスを隠すことは不可能だろう、ということにも注意。 3.3 ネットワーク提供のプライバシー ユーザーが中継媒体を経由してリクエストを送信している場合、ユーザーエー ジェントは、中継媒体の協力なしでは、限られた範囲までしかアイデンティ ティを隠せない。また、中継媒体が削除するように委託された場合、ある情報 は送信先のエンドポイントから隠される。 これらの理由から、中継媒体からのプライバシーを要求する方法、つまり、 望ましいプライバシーサービスを指定する何かをユーザーがシグナルし、かつ、これら のサービスを提供可能な中継媒体へ呼がルートされることを保証する手段を ユーザーは持たなければならない。 ユーザーは、すでに関係のある、ホストを匿名化する特定のサードパーティを 意識してもよい。あるいは、ユーザーは自分のローカルの管理ドメインがプラ イバシーサービスを提供するように要求してもよい。 中継媒体は、発信元のユーザーからの明示的なシグナリングなしに、メッセージ にプライバシーを適用する権限を与えられてもよい。なぜなら、ユーザー エージェントが、必要なときにプライバシーを要求する認識力や能力を常に持 つとは限らない。 4. ユーザーエージェントの動作 ユーザーエージェントがリクエストのプライバシーに貢献できる3つの異なる 方法がある。- プライバシーのリクエストを反映する値をヘッダーを組み 込むことによって、また、ネットワークにこれ以上のプライバシーサービスを 要求することによって、ヘッダーとボディを安全なものにするために暗号の機 密性を使うことによって、である。3つのうち、最後のものは、このドキュメン トの適用範囲外であることに注意。 このセクションで提供されるメカニズムによって、ユーザーエージェントは、 ユーザーがヘッダー値と規定のプライバシーのプリファレンスを選択できるよ うに、十分に構成できるようになる(理想的には呼あたりの)。それ以外の場 合、後述(セクション5参照)される機能のいくつかを提供するために、この ユーザーエージェントからシグナリングを調整するように設定されるプライ バシーサービスを通して、ユーザーは呼をルートすることができる。 Peterson Standards Track [Page 7] RFC 3323 Privacy Mechanism for SIP November 2002 4.1 プライベートメッセージの構築 プライバシーはユーザーエージェントで始まる。メッセージの送信者に関する プライベート情報を隠すように要求される手順の大部分は、適切に言うと、 送信者の責任である。 以下のSIPヘッダーは、ユーザーエージェントに生成される場合、直接的、また は間接的にメッセージの発信元に関するアイデンティティ情報を明かしうるも のである。: From、Contact、Reply-To、Via、Call-Info、User-Agent、 Organization、Server、Subject、Call-ID、In-Reply-To、Warning 認証システム(例えば[1]に記載されるSIPダイジェスト認証)の使用は、 一般的に、1つ以上のパーティにアイデンティティを明かすことも伴う。 より詳しい情報は、セクション6を参照のこと。 最初の、また最も自明の手順は、ユーザーエージェントは個人情報を明かす可 能性のあるいかなるオプションのヘッダーも含むべきではない[SHOULD NOT]と いうことである。確かに、プライバシーを求めるユーザーがCall-Infoを含める という理由は何もない。次に、ユーザーは、セクション4.1.1に記載されるガイ ドラインに沿ったメッセージ全体に、URIを組み込むべきである[SHOULD]。例え ば、ユーザーはリクエストに応じて匿名のFromヘッダーフィールドを生成すべ きである[SHOULD]。最後に、ユーザーはまた、セクション4.2に記載されるよ うに、ネットワークから特定のプライバシー機能を要求する必要があっても良 い[MAY]。 Call-IDヘッダーはしばしば、ある意味では、発信元のクライアントのIPアド レスやホスト名を明かすように構築されているが、特記が必要である。 ユーザーエージェントは、Call-ID値にしばしば付加されるIPアドレスやホスト 名を、適切な長いランダム値に代替させるべきである[SHOULD](リクエストの Fromヘッダーのための「tag」として利用される値は、再利用さえされるかもし れない)。 ユーザーが、メッセージの最終送信先には隠さず、中継媒体のみに対して上記の どのヘッダーも隠したい場合は、[1]のセクション23に記載されるように、ユー ザーは、カプセル化された「message/sip」S/MIMEのボディで、そのヘッダーに 正当な値を設定してもよい[MAY]。 4.1.1 URI、表示名とプライバシー ある程度のプライバシーは、URIとアイデンティティ情報を明かさない表示名 をSIPヘッダーを組み込むのを選択することによって、提供することができる。 あるヘッダーフィールドでは(例えばReply-ToやFromヘッダー)、カレントダイ アログ内で後続のシグナリングでは、URIは使用されない。Contactヘッダーの ような他のものは、不正確なURIはダイアログ内で後続のリクエストをルートす る際に失敗する結果になるだろう。 Peterson Standards Track [Page 8] RFC 3323 Privacy Mechanism for SIP November 2002 4.1.1.1 表示名 電子メールや他のアプリケーションでは、Fromヘッダーフィールドの表示名コ ンポーネントで偽名を使用するのは、比較的一般的に行われる。ビジネス関係 以外では(特にインスタントメッセージやインターネットゲームのようなアプ リケーションでは)、このようなエイリアスの利用は不信を引き起こすようなこ とにはならなだろう。 匿名性を求めるユーザーエージェントは「Anonymous」の表示名を利用することを 推奨する[RECOMMENDED]。 4.1.1.2 URIのユーザー名 URIの構成自体でかなりの範囲の個人情報を明かしたり隠すことができる。 以下の違いを考慮されたい。 sip:jon.peterson@neustar.biz と sip:a0017@anonymous-sip.com 前者からは、問題のパーティのフルネームと雇用主が容易に推測できる。 後者からは、そのパーティが匿名性を求めていること以外はわからない。 ある場合では、あいまいなURIを選択することによって、十分に匿名性を 達成しうる。今日では、SIP仕様はFromヘッダーのユーザー部分で「anonymous」 を持つURIを推奨している。 Contactヘッダーに出てくるように、あるURIでは、以下のように、全体で ユーザー名を省略して、ホスト名だけを提供することでつじつまを合わせて もよい[MAY] sip:anonymous-sip.com 4.1.1.3 URIのホスト名とIPアドレス 本文書では、プライバシーを要求するユーザーは、そのダイアログ 内では今後もリクエストと応答を受信したいが、そのダイアログの範囲外で、 そのユーザーに新規のリクエストを送るために利用される可能性のあるアイデ ンティティを明かすことは望んでいない、と仮定している。その理由から、そ のダイアログとは無関係な新規リクエストをルーティングするのとは対照的に、 ダイアログにおいて後続のリクエストをルーティングするという状況下で使用 されるURIについては、異なる扱いが推奨されるべきである。 今後のセッションでユーザーがどのように接続されたいかを示すヘッダーでは (例えばFromヘッダー)、ホスト名の変更がなぜ必要なのかということは、すぐ に明らかにはならないだろう。- ユーザー名が「anonymous」の場合、リクエス トは匿名ユーザーへルートできないだろう。 Peterson Standards Track [Page 9] RFC 3323 Privacy Mechanism for SIP November 2002 時として、単にユーザー名を変更することはユーザーのアイデンティティを隠 すのに十分とはいえないこともある。ユーザーのSIPサービスプロバイダは、 ちゅうちょせずにユーザーのアイデンティティを明かすかもしれない(小規模の 会社や個人ドメインを考慮すると)。そのため、このような場合では、From ヘッダーのURIが匿名ユーザーへ逆参照しないとしても、人間が容易にユーザー のアイデンティティを推測し、そのaddress-of-recorの正しいフォームを知る 可能性がある。 これらの理由から、ホスト名値「anonymous.invalid」が匿名URIに使用される べきである[SHOULD](予約された「無効な(invalid)」DNSのTLDについて詳しくは [3]を参照のこと)。匿名性のためのFromヘッダーの推奨される完全なフォーム は、以下の通りである(このFromヘッダーは、他と同様に、有効かつユニークな 「tag=」パラメータを含まなければならない[MUST])。 From: "Anonymous" ;tag=1928301774 カレントダイアログで、どの程度までリクエストがルートされるべきかを示す ヘッダーでは(例えば、Contactヘッダー、Viaヘッダーと、SDPのセッション 情報)、ユーザーが既存のURIを偽装するためにできることはほとんどないよう に見える。なぜなら、ユーザーは、今後もリクエストを受信できる値を提供し なければならない[MUST]からである。ある場合では、ユーザー名を偽装したり、 提供に失敗することは、上記のように、ある程度のプライバシーを作り出すか もしれないが、ホスト名はより深刻な障害を提供する。 ホスト名よりもIPアドレスを使用する場合に、別の多くのプライバシーがある だろうか? メッセージを非公式に調べる何者かが、そうしなければ(IPアドレス を使用しなければ)見る可能性のある情報を集めるのを防ぐ。だが、このような アドレスの逆名前解決(reverse-resolving)は一般的に取るに足らないもので あり、IPアドレスを ホスト名で代替させることは、例えばNATとファイア ウォール越え関連の原因で、ある種の複雑さを持ち込むかもしれない。ホスト 名のところにIPアドレスが使用される場合に失われるだろうサービスを提供す るある種のDNSの実行にもまた、ルーティング時に使用されるヘッダーは依存 する。 そのため、本文書では、後続のリクエストをルーティングするために使用され るURIのホスト名部分、例えばContactヘッダーに出てくるURIなどは、プライ バシー考慮のためにユーザーエージェントによって変更されるべきではな い[SHOULD NOT]と、推奨する。これらのヘッダーが匿名性を要求する場合、 ユーザーは、中継媒体にそのサービスを、つまりプライバシーサービスを要求 する。 上記のContactヘッダーに関わる検討事項の多くは、ある種のルーティング用途 でURIよりもホスト名が使用されるSIPヘッダーに同様に当てはまる(例えばVia ヘッダー)。 Peterson Standards Track [Page 10] RFC 3323 Privacy Mechanism for SIP November 2002 4.2 プライバシープリファレンスの表現 ルーティング時に使用されるため、ユーザーエージェントが自身を隠せない が、また、それらは、匿名ユーザーへ、また匿名ユーザーからメッセージを続 けて差し向ける責任を持つ中継媒体によって、隠される可能性がある、いくつ かのヘッダーが存在する。ユーザーエージェントはネットワークからこのよう なプライバシーサービスを要求する何らかの方法を持たなければならない。そ の目的から、このドキュメントは新規のSIPヘッダーであるPrivacyを定義する。 これは、リクエストと応答に対してハンドリングする特定のプライバシーに利 用される。 Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value) priv-value = "header" / "session" / "user" / "none" / "critical" / token ネットワーク提供のプライバシー(セクション3.3記載の通り)が必要とされる 場合、ユーザーエージェントはPrivacyヘッダーを含むべきである[SHOULD]。 ある種の中継媒体はまた、プライバシーサービスを含め、Privacyヘッダーを メッセージに追加するかもしれないということに注意。だが、このような中継 媒体は、例えばこのようなPrivacyヘッダーを追加する中継媒体のオペレー ターと、ユーザーが管理協定を持つ場合などユーザーの命令で操作する場合に のみ、そうすべきである[SHOULD]。中継媒体は、priv-valueに「none」がすで に指定されている場合、いかなる場合でも、Privacyヘッダーを修正してはなら ない[MUST NOT]。 priv-valueの値は、今日では、上記のオプションに限定されているが、必要に 応じて、さらにオプションが定義されうる(セクション7を参照のこと)。 適切な各priv-valueは、0または1回、Privacyヘッダーに出すことができる。 現在の値は以下の通り。 header: ユーザーは、中継媒体の支援なしに情報を識別する、完全に消すこ とのできないヘッダー(例えばViaとContact)を、プライバシーサービスが隠 すことを要求する。また、リクエストの発信元に関する個人情報を明かす 可能性があるサービスによって、不必要なヘッダーが追加されるべきでは ない。 session: ユーザーは、プライバシーサービスが、このメッセージで開始 される1つ以上のセッションの間(例えばSession Description Protocol の[5]に記述されている)、匿名化を提供することを要求する。これは、普 通、セッションのトラフィックが始まるようなところからIPアドレスを隠す だろう。セッションプライバシーが要求される場合、ユーザーエージェント はメッセージ内のSDPボディは暗号化してはならない[MUST NOT]。エンドツー エンドセッションの暗号化がない場合、セッションプライバシーを要求する ことによって、重大なセキュリティ懸案が持ち上がるということに注意(セク ション5.2を参照のこと)。 Peterson Standards Track [Page 11] RFC 3323 Privacy Mechanism for SIP November 2002 user: このプライバシーレベルは、おそらくユーザーエージェントは提供でき ないことから、ユーザーレベルのプライバシー機能は(セクション5.3で議論 される通り)ネットワークによって提供されなければならないということを 伝達するために、一般的に、中継媒体によってのみ設定される。ユーザー エージェントは、REGISTERリクエストのためにこのプライバシーを設定して もよい[MAY]が、その他のリクエストのために「user」レベルプライバシー を設定すべきではない[SHOULD]。 none: ユーザーは、以前に提供されたユーザーのプロフィールまたはサービス のデフォルト動作に関わらず、プライバシーサービスがこのメッセージに プライバシー機能を何も適用しないことを要求する。ユーザーエージェント は、Privacyヘッダーが提示されないと、このメッセージに対してユーザー の望まないなんらかのプライバシー機能を適用するプライバシーサービスを 通して、メッセージをルートするように強制される場合、このオプションを 指定できる。中継媒体はpriv-valueが「none」のPrivacyヘッダーを削除した り、変更してはならない[MUST NOT]。ユーザーエージェントは「none」の値 を含むPrivacyヘッダーに、他のいかなるpriv-values(「critical」を含め) を組み込んではならない[MUST NOT]。 critical: ユーザーは、このメッセージに対して要求されるプライバシーサー ビスは重要であり、したがって、このプライバシーサービスがネットワーク によって提供されない場合、このリクエストは拒否されるべきである、と主 張する。応答については、重要性は適切に管理できない。 Privacyヘッダーが構築される場合、値「none」または、「critical」指定を受 けてもよい[MAY]、1個以上の「user」、「header」、「session」 (各々、出て くるのは最高でも1度のみ出なければならない[MUST]) から構成されなければな らない[MUST]。 以下の表は[1]の表2の拡張を指定するものである。 ヘッダーフィールド where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ Privacy amrd o o o o o o Header field SUB NOT PRK IFO UPD MSG ___________________________________________________________ Privacy o o o o o o 4.3 リクエストのプライバシーサービスへのルーティング ユーザーエージェントがプライバシー機能を呼び出す最も明確な方法は、プラ イバシーサービスとして動作するとわかっている中継媒体を通して、リクエス トを方向付けることである。そうすることは元来、プライバシーサービスを 指定する事前にロードされたRouteヘッダーの設定を伴う。 Peterson Standards Track [Page 12] RFC 3323 Privacy Mechanism for SIP November 2002 サービスプロバイダはプライバシーサービス機能とローカルのアウトバンドプ ロキシを組み合わせることが推奨される[RECOMMENDED]。それによって、通常の アウトバンドルートを通して、ユーザーはプライバシーを要求するメッセージ を送信できる。だが、ユーザーは、リクエストの送信先である管理ドメインが、 ユーザーに代わって、プライバシーサービス機能を進んで行ったり、行うこと ができる、と仮定すべきではない。発信元のユーザーがローカルの管理ドメイ ンを秘密にしておきたい場合、すべてのセッションに関連する主要な管理ドメ イン以外の、サードパーティの匿名化サービスを使用しなければならない。 プライバシーサービスに接続する際は、ネットワークまたはトランスポートレ イヤーのセキュリティ、例えばTLSなどを ユーザーエージェントが使用するこ とが、強く推奨される[RECOMMENDED]。理想的には、ユーザーは、プライバ シーサービスと直接(すなわち、あらかじめロードされた単独のRouteヘッダー) の接続を確立すべきである[SHOULD]。これによって、ユーザーはプライバ シーサービスに提示された証明書(certificate)を調べることができるし、プラ イバシーサービスが、メッセージがプライバシーサービスに到達する前に、隠 す情報が明かされる機会を減らすというリクエストの機密性を提供することが できるだろう。プライバシーサービスへ直接接続を確立することで、ユーザー はまた、中継媒体がプライバシーのためにリクエストを削除できる可能性を推 定できる。直接接続が不可能な場合、ユーザーは、プライバシーサービスまで の間、低層のセキュリティの利用を保証するSIPSのようなメカニズムを使用す べきである[SHOULD]。 プライバシーサービスへ直接リクエストを送信しているとユーザーエージェン トが確信する場合、Privacyヘッダーに「critical」 priv-valueが提示される場 合は特に、新規のオプションタグ「privacy」を持つProxy-Requireヘッダーを含 めるべきである[SHOULD]。そのように、ユーザーエージェントがリクエストを 本文書に記載されている拡張に対応していない中継媒体へ送信する という、あまり発生しないイベントにおいては、リクエストは失敗する。 特別なプライバシーサービスの動作のために(セクション5に記載)、リクエストの シグナリングパスにおいて、後続の中継媒体はすべて、対応に「privacy」オプ ションタグを必要としないことに注意。 - いったんプライバシーサービスが すべての要求されたプライバシー機能を実現するとすぐに、「privacy」オプ ションタグはProxy-Requireヘッダーから削除される。 4.4 レスポンスのプライバシーサービスへのルーティング 応答がプライバシーサービスを通って行くのを確実にするのは、やや用心が必 要である。SIP応答によって通過したパスは、リクエストがたどってきたパスと 同じである。そのため、例えば、ユーザーエージェントに応答することは、 プライバシーサービスにリクエストの受信後の応答パスへ差し込ませることを 強要できない。 Peterson Standards Track [Page 13] RFC 3323 Privacy Mechanism for SIP November 2002 しかしながら、応答ユーザーエージェントができることは、リクエストが到達す るパスがプライバシーサービスを越えるのを確実にすることである。あるアー キテクチャでは、プライバシーサービス機能は、ローカルの管理ドメインに対 するリクエストが送信されるのと同じサーバーで実行されるだろう。したがっ て、それは自動的に入ってくるリクエストのパスに存在するだろう。だが、こ れ以外の場合、ユーザーはサードパーティのプライバシーサービスを通してリ クエストが向けられることを確実にしなければならないだろう。 これを達成する1つの方法は、サードパーティのサービスから「匿名のコール バック(anonymous callback)」のURIを入手し、これをAddress-of-Recordとし て配信することである。プライバシーサービスプロバイダは、一般的なSIPサー ビスプロバイダがaddresses-of-recordを承諾するのと同様の方法で、これらの 匿名のコールバックURIをユーザーへ提供してもよいだろう。それによって、 ユーザーは、サードパーティのサービスについてコンタクトアドレスとして通常 のAddress-of-Recordを登録するだろう。 代わりに、ユーザーエージェントは、「ユーザー」レベルプライバシーのため のリクエストとともに、プライバシーサービスを通してREGISTERリクエストを 送信できる。これによって、プライバシーサービスは匿名のContactヘッダーURI を挿入できるようになるだろう。ユーザーの従来のAddress-of-Recordに送信さ れるリクエストは、利用可能なコンタクトアドレスをどれも明かすことなく、 ユーザーのデバイスに到達するだろう。 最後に、ユーザーは、匿名化サービスへリクエストを方向付けるCPL(参考文 献[7])スクリプトを生成してもよい。 ユーザーには、応答パスにあるトランスポートまたはネットワークレイヤーの セキュリティを利用するように助言する。これは、SIP URIの登録かつ(または)、 ユーザーエージェントがリクエストを受信するための永続的(persistent)なTLS 接続の維持が必要かもしれない。 プライバシーサービスは、他のプライバシーサービスを通してリクエストを順々 にルートしてもよい[MAY]。これは、プライバシーサービスが特定のプライバ シー機能に対応しておらず、その機能を実行するピアを知っている場合に必要 になるだろう。1つのセッションで参加者をさらに偽装するために、相互にセッ ショントラフィックを交換するネットワーク内へ、プライバシーサービスは自身 をクラスタ化してもよい。だが、そうするための特定のアーキテクチャやメソッ ドは本文書に記載されない。 5. プライバシーサービスの動作 本文書は、「プライバシーサービス」と呼ばれる新規のSIPの論理的 役割について定義する。プライバシーサービスの役割は、ネットワークの中継 媒体、しばしば、SIPプロキシサーバーとして動作できるエンティティによっ て、例示される。プライバシーサービスの機能は、ユーザーエージェント自身 が提供できないSIPメッセージのためのプライバシー機能を提供することであ る。 Peterson Standards Track [Page 14] RFC 3323 Privacy Mechanism for SIP November 2002 メッセージがプライバシーサービスとして動作可能なサーバーに到達する場合、 サービスはPrivacyヘッダーで要求されるプライバシーのレベルを評価すべきで ある[SHOULD]。通常、明示的に要求されるサービスのみが適用されるべきで ある。だが、プライバシーサービスはユーザーの好みを確かめるSIP以外の何ら かの手段を持ってもよい[MAY](例えば、所定のユーザープロファイルなど)。 また、そのために、ユーザーは明示的なPrivacyヘッダーなしに、このような他 のプライバシー機能を実行してもよい[MAY]。プライバシーサービスにあるユー ザーレベルのプライバシー機能でさえも実行することは、有用でありうる。例 えば、Privacyヘッダーに対応していないレガシークライアント、あるいは個人 情報を明かす可能性のあるヘッダー値をユーザーが設定できないようになって いるユーザーエージェントから、ユーザーがメッセージを送信している場合で ある。だが、「none」というPrivacyヘッダー値がメッセージに指定される場 合、プライバシーサービスはいかなるプライバシー機能を実行してはならず [MUST NOT]、また、Privacyヘッダーを削除、変更してはならない[MUST NOT]。 プライバシーサービスは「none」と「critical」プライバシートークンに対応 する実装をしなければならない[MUST]。また、本文書に詳しく書かれていない 拡張と同様に、セクション4.2に記載される他のプライバシーレベルのどれでも 実装してもよい[MAY]。時には、プライバシーサービスはプライバシーの要求 されるレベルを満たすことができないだろう。「critical」プライバシー レベルがリクエストのPrivacyヘッダーに提示される場合で、さらにプライバ シーサービスがPrivacyヘッダーに指定されるすべてのプライバシーのレベルを 実行できない場合、リクエストを500(Server Error)応答コードで失敗させなけ ればならない[MUST]。応答のステータス行にある理由フレーズは、プライバシー サービスによって対応されていないpriv-value(複数)の列挙(enumeration)と同 様に、プライバシーの失敗があったことを示す適切なテキストを含むべきであ る[SHOULD](理由フレーズはまた、可能ならばリクエスト内のAccept-Language ヘッダーすべても考慮すべきである[SHOULD])。 プライバシーサービスがPrivacyヘッダーに列挙されるプライバシーレベルに関 連する機能の1つを実行する際は、Privacyヘッダーから対応するpriv-valueを 削除するべきである[SHOULD]。 - そうでなければ、このメッセージのルーティ ングに関わる他のプライバシーサービスのいずれかが、不必要に同じ機能を適 用するかもしれないためである。多くの場合、それは望ましくない。最後の priv-value(「critical」を含めず)がPrivacyヘッダーから削除されると、 Privacyヘッダー全体がメッセージから削除されなければならない[MUST]。 プライバシーサービスがPrivacyヘッダー全体を削除したら、メッセージが リクエストの場合、プライバシーサービスは、リクエストのProxy-Require ヘッダーからすべての「privacy」オプションタグも削除しなければならな い[MUST]。 Peterson Standards Track [Page 15] RFC 3323 Privacy Mechanism for SIP November 2002 5.1 ヘッダーのプライバシー 「header」のプライバシーレベルが要求される場合、ユーザーは、そうしないと リクエストの発信元に関する情報を明かすかもしれないヘッダーについて、隠 すための援助をプライバシーサービスへ要求しているのである。しかし、隠さ れた値は、ダイアログ内のその後のメッセージが発信元のユーザーエージェン トへルートされる必要がある場合、修復可能(recoverable)でなければならな い。これらの機能を提供するために、プライバシーサービスは透過的なバック トゥバック ユーザーエージェント(B2BUA)として頻繁に機能しなければなら ない。 第一に、ヘッダーのプライバシーのためのリクエストは、アイデンティティや 個人情報を明かすすべてのメッセージにサーバーはいかなるヘッダーも追加す べきではない[SHOULD NOT]、ということを課す。これには以下のヘッダーを 含む。Call-Info、Server、Organization。これらすべて、匿名性を要求する ユーザーについての事実を明かす可能性のあるオプション情報を提供するもの である。 リクエスト上で操作するプライバシーサービスは、プライバシーサービスに到 達する前にリクエストに追加されていたViaヘッダーをすべて削除すべきであ り[SHOULD](「Viaの削除(Via stripping)」と呼ばれる実行)、さらに、自分自 身を示す1個のViaヘッダーを追加すべきである[SHOULD]。このような、リクエ スト内の一番最後(the bottommost)のViaヘッダーフィールド値は、発信元のク ライアントを示すIPアドレスまたはホスト名を含み、また、続くViaヘッダー フィールド値は、クライアントと同じ管理ドメイン内のホストを指し示すかも しれない。応答をハンドリングする場合、Viaの削除は必要ない。 Contactヘッダーは、ユーザーによって、リクエストと応答の両方に追加され る。プライバシーサービスは、メッセージ内のContactヘッダー値を、メッセー ジの発信元に逆参照しないURI(セクション4.1.1.3で説明する匿名URIなど)と置 換すべきである[SHOULD]。既存のContactヘッダーフィールド値を置換するURI は、プライバシーサービスへ逆参照しなければならない[MUST]。 Viaの削除に似た手法でもまた、プライバシーサービスはプライバシーサービス へ到達する前にリクエストに追加されたRecord-Routeヘッダーすべてを削除す べきである[SHOULD]。- だが、発信元ユーザーエージェントとプライバシーサー ビスの間に1ホップしかない場合、上記で推奨されるように、このようなヘッ ダーは何も提示されないということに注意。このようなRecord-Routeヘッダー はクライアントの管理ドメインに関する情報もまた明かすかもしれない。 本文書の目的から、プライバシーサービスは、削除された上記のヘッダーのい ずれかの値をローカルで持続していると推定される。また、そのことは、プラ イバシーサービスが、ダイアログごと(per-dialog)のベースで、かなりの量の ステートを保持することを要求するものである。そのダイアログに関わる後続 のリクエストまたは応答がプライバシーサービスに到達した場合、プライバ シー上の利益のために前に削除されていたVia、Record-Route、Contact Peterson Standards Track [Page 16] RFC 3323 Privacy Mechanism for SIP November 2002 ヘッダー値を修復しなければならない[MUST]。(本文書の範囲外で) プライバシーサービスにステートを保持すること(通常、なんらかの方法でシグ ナリング内の値を暗号化したり保持することを意味する)を必要としない、この ような機能を実行する別の方法があるかもしれない。 リクエストと応答のRecord-Routeヘッダーフィールドをハンドリングするた めに、以下の処理が推奨される[RECOMMENDED]。また、これはプライバシーサー ビスへ特別な試行を提供するものである。 プライバシーサービスが1個以上のRecord-Routeヘッダーフィールド値を含むリ クエストを(発信元の代わりに)処理している場合、プライバシーサービスはこ れらの値をリクエストから削除しなければならないし、また、ダイアログの識 別子と命令されたRecord-Routeヘッダーフィールド値の両方を思い出さなけれ ばならない。上記のように、Contactヘッダーフィールドをプライバシーサービ ス自身を指すURIで置換しなければならない。同じダイアログ識別子を持つ応答 がプライバシーサービスに到達した場合、プライバシーサービスは、応答へす べてのRecord-Routeヘッダー値を同じ順に再適用しなければならず、さらに、 応答のRecord-Routeヘッダーフィールドに自身を表すURIを追加しなければなら ない。応答が自分自身のRecord-Routeヘッダーフィールド値を含む場合は、これ らも、プライバシーサービスを表すURIの後に、Record-Routeヘッダーフィール ドに(順に)含めなければならない。 プライバシーサービスがリクエストをハンドリングし、リクエストの送信先の代 わりにプライバシーを提供している場合、プライバシーサービスのダウンスト リームにRecord-Routeヘッダーについてのプライバシーを提供することは、より 深刻な複雑さがある。本文書は、それらのヘッダーが削除される場合、ステート フルにそれらのヘッダーを復元するどのような方法も推奨しない。 5.2 セッションのプライバシー 「session」のプライバシーレベルが要求される場合、ユーザーは、プライバシー サービスがこのダイアログに関わるセッショントラフィック(例: SIP通話では 音声メディア)を匿名化することを要求している。 SIP仕様は、プロキシサーバーのような中継媒体はメッセージボディを調べたり 変更することはできない、と指示している。そのため、プライバシーサービス の論理的役割は、メディアのプライバシーを提供するために、効率的にセッショ ンを開始するメッセージを停止(terminating)したり再発行(re-originating) して、バックトゥバックユーザーエージェントとして動作しなければならな い[MUST](だが、セッションプライバシーに対応する上で、プライバシーサービ スは、リクエストが再発行されるときに発信元と送信先を特徴付けるヘッダー に変える必要はない。)。セッショントラフィックのアノニマイザを導入するた めに、プライバシーサービスは、セッショントラフィックに対する明らかなソー スとシンクを提供できるミドルボックス([8])を制御する必要がある。 アノニマイザの実装に関する詳細と、セッションを開始するメッセージにあ Peterson Standards Track [Page 17] RFC 3323 Privacy Mechanism for SIP November 2002 るSession Description Protocol (SDP[5])のボディに入れなければならない修 正については、本文書の範囲外である。 もちろん、このようなアノニマイザを使用する危険性は、自分の通信に対して、 アノニマイザ自身がパーティであるということである。この理由から、(例え ば、SRTP [4] のように、RTP [6]メディアを持つ)セッショントラフィックに対 する何らかのエンドツーエンドのセキュリティに頼らずに、セッション レベルのプライバシーを要求することは、推奨されない[NOT RECOMMENDED]。 5.3 プライバシーサービスにおけるユーザーレベルのプライバシー機能の適用 「user」のプライバシーレベルが要求される場合、発信元のユーザーはセクショ ン4.1に記載されるユーザーレベルのプライバシー機能を実行することをプライ バシーサービスに要求している。 Subject、Call-Info、Organization、User-Agent、Reply-To、In-Reply-Toを 含め、ユーザーエージェントによって追加された重要ではない通知的なヘッダー を、プライバシーサービスは削除しなければならない[MUST]ということに注意。 重要なことは、ユーザーレベルのプライバシーは、元の値から匿名の値へ変え るというFromヘッダーの修正を伴う可能性があるということである。現在のSIP 仕様の発行物より以前は、中継媒体によるToとFromヘッダー値の修正は許可 されていなかった。また、そのため、エンドポイントによって、不正確なダイ アログマッチングという結果にもなっていた。現在、ダイアログマッチングは、 ヘッダーフィールド全体ではなく、ToとFromヘッダー内のタグのみを使用する。 したがって、新規則の下では、ToとFromヘッダーのURI値は中継媒体によって変 更できる。だが、レガシークライアントのいくつかは、FromヘッダーのURIの値 がリクエストと応答間で変更された場合、エラー状態とみなすかもしれない。 また、ユーザーレベルのプライバシー機能を実行するときに、Call-IDヘッダー の修正を伴ってもよい[MAY]。なぜなら、Call-IDは通常、発信元クライアント を指すホスト名またはIPアドレスを含むためである。このフィールドはダイア ログマッチングに不可欠なものであり、また、中継媒体は変更できない。 そのため、プライバシーサービスが、プライバシー上の理由からダイアログ マッチングに関わるヘッダーのいずれかを修正することを必要とする場合は 常に、透過的なバックトゥバックユーザーエージェントとして動作すべきであり [SHOULD]、以前からのダイアログマッチングのヘッダー値を持続しなければな らない[MUST]。これらの値は発信元のユーザーエージェントに送信されるすべ てのメッセージで修復されなければならない[MUST]。 Peterson Standards Track [Page 18] RFC 3323 Privacy Mechanism for SIP November 2002 6. セキュリティの考慮 プライバシーを要求するメッセージは、機密性と完全性を要求する。完全性が ない場合、要求されたプライバシー機能はダウングレードまたは削除される可 能性がある。機密性がない場合、ネットワーク(またはユーザーとプライバシー サービス間の中継媒体すべて)上の盗聴者は、ユーザーがプライバシーサービス に隠すように依頼した非常に個人的な情報も見ることができるかもしれない。 本文書内の、すべてのネットワーク提供のプライバシー機能は、 プライバシーサービスへの非常に大きな信頼を伴う。ユーザーは、なんらかの 理由で責任を持てるプライバシーサービスのみを信頼すべきである。 プライバシーサービスの操作者は、ダウンストリームのエンティティの視点か らは、プライバシーサービスが、匿名メッセージをトレースできる唯一のソー スであることを意識すべきである。 認証メカニズムは、SIP仕様に記述されるダイジェスト認証メソッドを含めて、 本文書のプライバシー案件の範囲外である点に注意すること。認証を通して アイデンティティを明かすことは選択性が高く、また、プライバシー情報のい ずれかを妥協するような結果にはできない。明確に、認証の試行を実行する サーバーへアイデンティティを明かしたくないユーザーは、このような試行に 応答しないことを選択してもよい[MAY]。 7. IANA条項 本文書は、ユーザーエージェントがメッセージに対して、ある程度ののプライ バシーを要求できる、「Privacy」という新規のSIPヘッダーフィールドを定義 する。このヘッダーに関連する動作は、セクション4.2で指定される。この ヘッダーは、http://www.iana.org/assignments/sip-parameters の下、 ヘッダーのサブレジストリに追加された。 ヘッダー名: Privacy 省略形: 未定義 本文書はまた、Privacyヘッダーに組み込む値についてIANA登録も生 成する。この登録は、priv-valueトークンによってインデックスされるべき であり、新規の値について短いセマンティクス記述を含むべきである。 「Privacy」ヘッダーの現在の値は以下の通り。 o user: プライバシーサービスにユーザーレベルのプライバシー機能を提供す ることを要求。 o header: プライバシーサービスに、ユーザーが勝手に設定できないヘッダー (Contact/Via)を修正することを要求。 Peterson Standards Track [Page 19] RFC 3323 Privacy Mechanism for SIP November 2002 o session: プライバシーサービスがセッションメディアのプライバシーを提供 することを要求。 o none: プライバシーサービスはプライバシー機能を何も実行してはなら ない。 o critical: プライバシーサービスは指定されたサービスを実行するか、 リクエストを失敗させなければならない。 「Privacy」ヘッダーのための新しい値は、RFC発行(RFC2434)を含んだ IETFの承認によってのみ定義されうる。RFC発行とともに、「Privacy」ヘッダー フィールド値のためのIANA登録が要求される。 SIPプロトコルの、セッションの参加者について個人情報を明かすような拡張の 著者は、「Privacy」ヘッダーの拡張に慎重である。 - むしろ、中継媒体の媒 介なしにユーザーエージェントが自身のプライバシーを管理できる、新しいア イデンティティメカニズムを作り出す方が好ましい。 本文書は、新規のSIPのオプションタグ「privacy」もまた定義する。 それは、本文書で定義される拡張への対応を表すものである。 規範的な参考文献 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. [3] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC 2606, June 1999. 有益な参考文献 [4] Baugher, M., McGrew, D., Oran, D., Blom, R., Carrara, E., Naslund, M. and K. Normann, "The Secure Real Time Transport Protocol", Work in Progress. [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. Peterson Standards Track [Page 20] RFC 3323 Privacy Mechanism for SIP November 2002 [6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [7] Lennox, J. and H. Schulzrinne, "CPL: A Language for User Control of Internet Telephony Services", Work in Progress [8] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. 著者の連絡先 Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/ 謝辞 著者は、Allison Mankin、Rohan Mahy、Eric Rescorla、Mark Watson、Cullen Jennings、Robert Sparks、Jonathan Rosenberg、Ben Campbell、Tom Gray、 John Elwellのコメントについて謝辞を述べたい。 Peterson Standards Track [Page 21] RFC 3323 Privacy Mechanism for SIP November 2002 完全な著作権表記 Copyright (c) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、本文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、本文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的な保証は行われ ない。 謝辞 RFC編集者の職務のための資金は、現在、インターネットソサエティによって 提供されている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Peterson Standards Track [Page 22]