Network Working Group J. Rosenberg Request for Comments: 3856 dynamicsoft Category: Standards Track August 2004 セッション開始プロトコル(SIP)のプレゼンスイベントパッケージ A Presence Event Package for the Session Initiation Protocol (SIP) 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラック プロトコルを規定するものであり、改善のための議論や提案を依頼するものであ る。標準化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。この文書の配布は無制 限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 本文書では、プレゼンスのサブスクリプションと通知に関するセッション開始 プロトコル(Session Initiation Protocol/SIP)の用法を説明する。プレゼンス は、ネットワーク上にいる他のユーザーと通信するユーザーの意思と能力と定 義される。従来、プレゼンスは、「オンライン」と「オフライン」を示すもの と限定されてきたが、本書で使用するプレゼンスの概念は、より広い。プレゼ ンスのサブスクリプションと通知は、通常のSIPイベント通知の枠組み内でイベ ントパッケージを定義することによって対応される。このプロトコルは、CPP (Common Presence Profile)の枠組みにも準拠している。 目次 1. はじめに .................................................... 2 2. 用語 ....................................................... 3 3. 定義 ....................................................... 3 4. 操作の概要 ................................................. 4 5. プレゼンスURIの用法 ........................................ 6 6. プレゼンスイベントパッケージ ............................... 7 6.1. パッケージ名 ........................................ 8 6.2. イベントパッケージパラメータ ......................... 8 6.3. SUBSCRIBEのボディ ..................................... 8 6.4. サブスクリプションの有効期間 . ...................... 9 6.5. NOTIFYのボディ ........................................ 9 6.6. SUBSCRIBEリクエストのノーティファイア処理 ............. 9 6.6.1. 認証 ........................................... 10 6.6.2. 認可 ........................................... 10 6.7. NOTIFYリクエストのノーティファイア生成 ................ 11 Rosenberg Standards Track [Page 1] RFC 3856 SIP Presence August 2004 6.8. NOTIFYリクエストのサブスクライバ処理 .................. 13 6.9. フォークされたリクエストの操作 ...................... 13 6.10. 通知の頻度 ........................................... 14 6.11. ステートエージェント .................................. 14 6.11.1. 収集、認証、認可 ............................ 14 6.11.2. 移行 ........................................ 15 7. プレゼンスステートの取得..................................... 16 7.1. 同居 ................................................. 16 7.2. REGISTER .............................................. 16 7.3. プレゼンスドキュメントのアップロード .................. 17 8. メッセージフロー例 ........................................ 17 9. セキュリティの考慮 ........................................ 20 9.1. 機密性 .............................................. 20 9.2. メッセージの整合性と信頼性 ............................ 21 9.3. アウトバウンド認証 .................................... 22 9.4. リプレイ攻撃の回避 .................................... 22 9.5. サードパーティに対するDoS攻撃 ......................... 22 9.6. サーバーに対するDoS攻撃 ............................... 23 10. IANA条項 .................................................... 23 11. 寄稿者 ...................................................... 24 12. 謝辞 ....................................................... 25 13. 規範となる参考文献 ........................................ 25 14. 有益な参考文献 .............................................. 26 15. 著者の連絡先 .............................................. 26 16. 完全な著作権表示 ........................................... 27 1. はじめに プレゼンス(プレゼンス情報とも)は、デバイス間で通信するユーザーの能力と 意思を伝達する。RFC2778(参考文献[10])では、プレゼンス情報を提示する記述 システムのモデルと用語を定義している。このモデルでは、プレゼンスサービ スとは、プレゼンス情報を受け入れ、格納し、関係者(ウォッチャーと呼ばれ る)に配信するシステムである。プレゼンスプロトコルは、インターネットまた は任意のIPネットワーク上で、プレゼンスサービスを提供するプロトコルであ る。 本文書では、プレゼンスプロトコルとしてセッション開始プロトコル(Session Initiation Protocol/SIP/参考文献[1])を使用することを提案する。このため に、一般的なSIPのイベント通知の枠組み(参考文献[2])を具体的に例示し、[2] で定義されるSUBSCRIBEメソッドとNOTIFYメソッドを利用する。本文書では、 RFC 3265(参考文献[2])で説明されているとおりに、明確にイベントパッケージ を定義する。特に、SIPはプレゼンスプロトコルに適している。SIPのロケー ションサービスには、登録の書式という形でプレゼンス情報がすでに含まれて いる。さらに、SIPネットワークでは、ネットワーク上の任意のユーザーから送 信されるリクエストを、そのユーザーの登録ステートを保持するサーバーに ルーティングできる。このステートはユーザープレゼンスの重要なコンポーネ Rosenberg Standards Track [Page 2] RFC 3856 SIP Presence August 2004 ントであるため、このSIPネットワークで、SUBSCRIBEリクエストを同じサー バーにルーティングすることができる。つまり、SIPネットワークを再利用し て、プレゼンスのサブスクリプションと通知用にグローバルな接続性を確立で きる。 このイベントパッケージは、プレゼンスエージェントの概念に基づいている。 プレゼンスエージェントとは、サブスクリプションの受け入れ、サブスクリプ ションステートの格納、プレゼンスの変更時に通知の生成、という機能を持 つ、新しい論理エンティティである。このエンティティは、通常は別のエン ティティと同居しているため、論理的なものと定義される。 このイベントパッケージは、参考文献[3]で定義されたCPP(Common Presence Profile)の枠組みにも準拠している。そのため、プレゼンス用のSIPと、他の CPP準拠のプレゼンスシステムを容易に相互運用できる。 2. 用語 本文書では、以下のキーワードはRFC2119(参考文献[4])に記述されている通り に解釈されるべきであり、準拠する実装に対する要求レベルを示すものであ る。「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」 3. 定義 本文書は、RFC2778(参考文献[10])の定義どおりに用語を使用する。さらに、以 下の用語について、新たに定義したり、より明確に説明を加える。 プレゼンスユーザーエージェント(Presence User Agent/PUA): プレゼンス ユーザーエージェントは、プレゼンティティのプレゼンス情報を操作す る。この操作は、他の何らかのアクション(新規のContactを追加するSIP REGISTERリクエストの送信など)によって引き起こされたり、プレゼン スドキュメントの発行によって明示的に実行される可能性がある。本文 書では、1つのプレゼンティティに付き複数のPUAということを明示的に 許容する。つまり、1人のユーザーは、多くのデバイス(携帯電話、PDA (Personal Digital Assistant)など)を持つことができ、それぞれのデ バイスが、別々にプレゼンティティのプレゼンス情報全体のコンポーネ ントを生成している、ということを意味する。PUAは、プレゼンスシス テムにデータをプッシュするが、システムの外部にあり、SUBSCRIBE メッセージの受信やNOTIFYメッセージの送信はシステム内で行わない。 プレゼンスエージェント(Presence Agent/PA): プレゼンスエージェント は、SUBSCRIBEリクエストの受信、SUBSCRIBEリクエストへの応答、プレ ゼンスステートの変更時に通知の生成、という機能を持つSIPユーザー エージェントである。プレゼンスエージェントは、プレゼンティティの プレゼンスステートを知っている必要がある。つまり、プレゼンスエー ジェントは、プレゼンティティのPUAが操作するプレゼンスデータに対し て、アクセス権を持つ必要がある。一例として、PAをプロキシ/レジスト ラと同じ場所に置くという方法がある。他にも、PAをプレゼンティティ Rosenberg Standards Track [Page 3] RFC 3856 SIP Presence August 2004 のプレゼンスユーザーエージェントと同じ場所に置く方法がある。ただ し、実現方法はこの2つだけではない。また、本仕様では、PA機能を配置 する場所に関して何ら推奨しない。PAは、プレゼンティティをユニーク に識別するSIP URIで常にアドレス指定できる(言い換えると、sip: joe@example.com)。1つのプレゼンティティに対して複数のPAが存在する 可能性がある。また、各PAは、プレゼンティティの現在アクティブなサ ブスクリプション全体のうち、一部を操作する。また、PAは、プレゼン スイベントパッケージに対応するノーティファイア(RFC 3265(参考文献 [2])で定義)でもある。 プレゼンスサーバー(Presence Server): プレゼンサーバーは、SUBSCRIBEリ クエストに対して、プレゼンスエージェントまたはプロキシサーバーと して動作することができる物理エンティティである。PAとして動作する 場合、何らかのプロトコルを使用してプレゼンティティのプレゼンス情 報を認識している。プロキシとして動作する場合、SUBSCRIBEリクエスト は、PAとして動作している可能性がある別のエンティティにプロキシさ れる。 エッジプレゼンスサーバー(Edge Presence Server): PUAと同じ場所にある プレゼンスエージェント。プレゼンス情報を操作するエンティティと同 居しているため、プレゼンティティのプレゼンス情報を認識している。 4. 操作の概要 このセクションでは、このイベントパッケージの操作概要を説明する。SIPイベ ントパッケージ(参考文献[2])とSIP仕様(参考文献[1])について、あまり知識の ない読者向けでもこのパッケージを理解しやすいように、本文書、SIPイベント パッケージフレームワーク、SIP仕様の一部で記載されている動作の概要を説明 する。ただし、このパッケージの詳細なセマンティクスについては、SIPイベン トとSIP仕様を理解する必要がある。 エンティティ(サブスクライバ)があるユーザーのプレゼンス情報を知りたい場 合、SUBSCRIBEリクエストを作成する。このリクエストでは、SIP URI、SIPS URI(参考文献[1])、またはプレゼンス(pres) URI(参考文献[3])を使用して、 Request-URIにある目的のプレゼンティティが特定される。SUBSCRIBEリクエス トは、他のSIPリクエストと同様に、SIPプロキシ間を伝達される。ほとんどの 場合、このリクエストは最終的にプレゼンスサーバーへ到達し、そこからリク エストへの応答を生成するか(この場合、プレゼンティティのプレゼンスエー ジェントとして動作する)、エッジプレゼンスサーバーへプロキシする。エッジ プレゼンスサーバーは、サブスクリプションを処理する場合、プレゼンティ ティのプレゼンスエージェントとして動作している。プレゼンスサーバーで行 われるSUBSCRIBEをプロキシするか終了するかの決定は、ローカルの問題だが、 本書では、REGISTERでこのような構成を達成する1つの方法を説明する。 Rosenberg Standards Track [Page 4] RFC 3856 SIP Presence August 2004 プレゼンスエージェント(プレゼンスサーバーでもエッジプレゼンスサーバーで も)は、まずサブスクリプションを認証してから、認可する。認可方法はこのプ ロトコルの範囲外であり、多くの方法が使用されると予想している。認可され ると、200 OK応答が返される。この時点で認可されないと、サブスクリプショ ンは「保留(pending)」と見なされ、202応答が返される。どちらの場合でも、 PAは、プレゼンティティとサブスクリプションのステートを含むNOTIFYメッ セージをすぐに送信する。サブスクリプションが保留された場合、プレゼン ティティのステートは偽造されている可能性がある。たとえば、プレゼンティ ティの実際のステートにかかわらず、オフラインを示すなど。これは、プレゼ ンティティのプライバシを保護するためのものである。プレゼンティティは、 認可を付与していないサブスクライバに対して、プライバシを公開することを 望まない場合がある。プレゼンティティのステートが変わると、PAは、サブス クリプションが認可済みの全サブスクライバに対して、ステートの変更内容を 含むNOTIFYを生成する。サブスクリプション自体のステート変更によって、 NOTIFYリクエストのトリガとなる場合もある。このステートはNOTIFYの Subscription-Stateヘッダーフィールドで伝達され、通常、サブスクリプショ ンがアクティブか保留中かを示す。 SUBSCRIBEメッセージによって、プレゼンスエージェントで「ダイアログ」が確 立する。ダイアログは、RFC 3261(参考文献[1])で定義されているが、ピアツー ピアメッセージを容易に交換するためのエンティティペア間のSIPステートを示 す。このステートには、ルートセットとリモートターゲットURIだけでなく、双 方向メッセージ(サブスクライバからのSUBSCRIBE、プレゼンスエージェントか らのNOTIFY)のシーケンス番号が含まれる。ルートセットは、SUBSCRIBEの更新 またはNOTIFYリクエストのパスに沿って到達するSIPプレゼンスサーバーを特定 するSIP(SIPS) URIのリストである。リモートターゲットURIは、メッセージの ターゲットを特定するSIPまたはSIPS URIである。たとえば、NOTIFYの場合はサ ブスクライバ、SUBSCRIBE更新の場合はプレゼンスエージェントである。 SIPには、NOTIFYメッセージとSUBSCRIBE更新のパス上にあるようにプレゼンス サーバーがリクエストすることを許容する、レコードルートという手順があ る。最初のSUBSCRIBEリクエストのRecord-RouteヘッダーフィールドにURIを入 力することで、これを実行できる。 最初のSUBSCRIBEの一部で交渉された有効期間に従って、サブスクリプションは 継続する。サブスクライバが、その後もサブスクリプションを保持する場合 は、期限切れ前にサブスクリプションを更新する必要がある。これは、最初の SUBSCRIBEで確立した同じダイアログ内で、SUBSCRIBE更新を送信することで実 行できる。このSUBSCRIBEは、最初のSUBSCRIBEとほぼ同一だが、Toヘッダー フィールドのタグ、高いCSeqヘッダーフィールド値、場合によってはRouteヘッ ダーフィールド値セット(リクエストが取るべきプロキシパスが指定されたも の)が含まれる。 Rosenberg Standards Track [Page 5] RFC 3856 SIP Presence August 2004 サブスクライバは、ダイアログ内で値がゼロのExpiresヘッダーフィールド(サ ブスクリプションの有効期間を指定)が指定されたSUBSCRIBEを送信すること で、サブスクリプションを終了することができる。この結果、サブスクリプ ションは直ちに終了する。次に、プレゼンスエージェントによって、最新のス テートを含むNOTIFYリクエストが生成される。実際は、Expiresがゼロの SUBSCRIBEリクエストを処理するプレゼンスエージェントの動作は、他の期限切 れ値の場合とは異なる。SUBSCRIBEリクエストの保留や認可によって、最新のプ レゼンティティステートとサブスクリプションステートでNOTIFYがトリガされ る結果になる。 プレゼンスエージェントは、サブスクリプションを任意のタイミングで終了で きる。この場合、サブスクリプションが終了したことを示すSubscription- Stateヘッダーフィールドを含んだNOTIFYリクエストを送信する。理由を示すた めに、reasonパラメータを指定することもできる。 また、最新のプレゼンスステートをフェッチして、現在のステートを含むワン タイム通知を実行することもできる。この場合、すぐに期限切れになる SUBSCRIBEリクエストを送信する。 5. プレゼンスURIの用法 プレゼンティティは、pres:user@domainという形式を持つ、プレゼンスURI(参 考文献[3])を使用する最も一般的な方法で特定される。このURIは、サーバーで 管理されているドメイン固有のマッピングポリシーによって、プロトコル固有 のURI(SIP URIまたはSIPS URI)に解決される。 ユーザーが、自分または他のユーザー達を特定するときに、SIP URI(とSIPS URIのいずれかまたは両方)とpres URIの両方を持っている可能性は高い。この 場合、このようなURIを関連付ける方法と、どちらを使用すべきか、という問題 が出てくる。 状況によって、ユーザーが、pres URIなどのURI形式で開始し、何らかのプロト コル手段で異なる形式のURIを認識する場合がある。たとえば、pres URIに送信 されたSUBSCRIBEリクエストによって、結果的に、SUBSCRIBEリクエストに対す る200 OKのContactヘッダーフィールドに含まれるプレゼンティティのSIP URI またはSIPS URIがわかる場合がある。別の例では、pres URIを検索してSIP URI またはSIPS URIを取得するDNSメカニズムが定義される可能性がある。何らかの プロトコル手段で、あるURIが別のURIから取得される場合、この手段は、取得 したURIのライフタイムを制限する何らかの範囲指定になる場合が多い。たとえ ば、DNSには、URIの範囲を制限するTTL機能がある。この範囲は、同じリソース を特定する場合にURIが古くなったり競合したりするのを防ぐ場合に、非常に有 効である。取得したURIがまだ有効かどうかをユーザーが常に判断できるように するには、プレゼンスURIの検索サービスを備えるシステムが、何らかの範囲指 定メカニズムを持つことを推奨する[RECOMMENDED]。 Rosenberg Standards Track [Page 6] RFC 3856 SIP Presence August 2004 サブスクライバが、プロトコルに依存しないプレゼンティティのpres URIのみ を取得した場合、参考文献[5]で定義される手順に従う。この手順では、SIPリ クエストのRequest-URIにpres URIを設定し、参考文献[5]で定義されるDNS手順 を使用して、SIPリクエストを送信するホストを決定する。当然ながら、RFC 3261(参考文献[1])で指定されるように、ローカルのアウトバウンドプロキシを 代わりに使用してもよい。サブスクライバが、同じプレゼンティティに関し て、プロトコルに依存しないpres URIとSIP URI(またはSIP URI)を取得し、ど ちらも有効(上記参照)な場合、pres URI形式を使用すべきである[SHOULD]。当 然ながら、サブスクライバがプレゼンティティのSIP URIしか知らない場合、そ のURIが使用れさ、標準的なRFC 3261のプロセスが発生する。pres URIが使用さ れると、SUBSCRIBEリクエストのパス上にあるプロキシで、pres URIスキームを 理解しないものは、リクエストを拒否する。したがって、最初のうちは、ユー ザーへSIP URIのみを提供するシステムが多く展開されることが予想される。 SUBSCRIBEメッセージには、サブスクリプションの発信元と着呼側を定義する論 理識別子(ToおよびFromヘッダーフィールド)も含まれる。これらのヘッダーで は、pres URIとSIP URIのどちらも使用できる。サブスクライバは、pres URIと SIP URIの両方を自分のIDと認識する場合、Fromヘッダーフィールドにはpres URIを使用すべきである[SHOULD]。同様に、サブスクライバは、pres URIとSIP URIの両方を相手側のIDと認識する場合、Toヘッダーフィールドにはpres URIを 使用すべきである[SHOULD]。 SIPメッセージにSIP URIではなくpres URIを使用することで、他のCPP準拠シス テムへのゲートウェイとの相互運用が可能になる。システム間で渡すことが可 能な、プロトコルに依存しないID形式が実現する。このようなIDがない場合、 ゲートウェイでは、SIP URIを他のプロトコルのアドレス形式にマッピングせざ るを得ない。一般的に、これはSIP URIを : @ という形式に変換することで実行される。これ は、電子メールシステムでよく実行され、既知の問題も多くある。pres URIの 使用は、強い推奨(SHOULD)であり、必須(MUST)ではない。これは、ゲートウェ イがない場合、またはpres URIを使用するとpres URIをサポートしないSIPコン ポーネントと相互運用性の問題が発生する場合を想定しているためである。 Contact、Record-Route、Routeヘッダーフィールドでは、論理エンティティを 特定しないが、SIPメッセージングで使用する具体的なエンティティを特定す る。SIP(参考文献[1])で、その構築規則が規定されている。 6. プレゼンスイベントパッケージ SIPイベントフレームワーク(参考文献[2])では、イベントに対するサブスクラ イブ、イベントの通知受信に関するSIP拡張が定義されている。このフレーム ワークでは、イベントパッケージという具体的な拡張に対する、このようなイ Rosenberg Standards Track [Page 7] RFC 3856 SIP Presence August 2004 ベントの側面の定義はあまりされていない。本文書は、イベントパッケージと しての資格を持つ。このセクションは、RFC 3265(参考文献[2])ですべてのイベ ントパッケージに必須とされる情報をすべて満たしている。 6.1. パッケージ名 このパッケージの名称は「presence」である。RFC 3265(参考文献[2])で規定さ れているが、この値は、SUBSCRIBEおよびNOTIFYリクエストで指定されるEvent ヘッダーフィールドで使用される。 例: Event: presence 6.2. イベントパッケージパラメータ SIPイベントフレームワークでは、イベントパッケージで、Eventヘッダー フィールドで伝達する追加のパラメータ定義を許容している。本パッケージ(プ レゼンス)では、追加のパラメータは定義しない。 6.3. SUBSCRIBEのボディ SUBSCRIBEリクエストにはボディを含めてもよい[MAY]。ボディの目的は、タイ プによって異なる。通常、サブスクリプションにはボディを含まない。 プレゼンティティを特定するRequest-URIは、イベントパッケージ名と組み合わ せると、プレゼンスに適している。 SUBSCRIBEリクエストに含むことができるボディの種類のひとつは、フィルタド キュメントである。このようなフィルタでは、特定のプレゼンスイベントのみ が通知を生成するように要求したり、NOTIFYリクエストで返されるデータセッ トに関する制限を要求したりする。たとえば、ユーザーのインスタント受信ト レイのステータス(参考文献[10])が変わったときにのみ、通知を生成すべきで あると規定するプレゼンスフィルタがある。また、通知のコンテンツには、イ ンスタント受信トレイのステータスのみを含めるべきである、と規定する場合 も考えられる。フィルタに関する文書は本文書では規定されていないが、執筆 時の段階では、将来的に、標準化作業時の課題になると予想されている。 このようなフィルタを支持することは、PAのポリシーによって自由である。 SUBSCRIBEリクエストにフィルタが含まれない場合、PAはフィルタが適用されな いことを理解する。PAは、自身のポリシー範囲で、NOTIFYリクエストを送信す べきである[SHOULD]。 Rosenberg Standards Track [Page 8] RFC 3856 SIP Presence August 2004 6.4. サブスクリプションの有効期間 . 多くのイベントの結果を受けて、ユーザープレゼンスは変化する。以下にいく つか例を挙げる。 o 携帯電話の電源オンまたは電源オフ o ソフトフォンから登録の変更 o インスタントメッセージングツールでステータスの変更 通常、これらのイベントはユーザーの操作によってトリガされ、秒単位から数 時間単位の頻度で発生する。したがって、サブスクリプションには、この範囲 の中間に当たる有効期限(約1時間)を設定する必要がある。そこで、このパッ ケージ内では、サブスクリプションのデフォルト有効期間は3600秒とする。RFC 3265(参考文献[2])に従って、サブスクライバは、異なるExchangeヘッダー フィールドの有効期限を指定してもよい[MAY]。 6.5. NOTIFYのボディ RFC 3265(参考文献[2])に記述されているように、NOTIFYメッセージには、サブ スクライブされたリソースのステートが記述されているボディを含める。この ボディは、SUBSCRIBEのAcceptヘッダーフィールドに列挙される書式か、 SUBSCRIBEがAcceptヘッダーフィールドで省略された場合はパッケージ独自のデ フォルトの書式で記述される。 本イベントパッケージでは、通知のボディにはプレゼンスドキュメントが含ま れる。本文書では、サブスクライブ対象のプレゼンティティのプレゼンスを記 載する。すべてのサブスクライバとノーティファイアは、参考文献[6]に記載さ れる「application/pidf+xml」プレゼンスデータ形式に対応しなければならな い[MUST]。SUBSCRIBEリクエストには、Acceptヘッダーフィールドを含めてもよ い[MAY]。このようなヘッダーフィールドがない場合、デフォルト値は 「application/pidf+xml」である。Acceptヘッダーフィールドを提示する場 合、「application/pidf+xml」を含めなければならず[MUST]、また、他にユー ザープライバシーを表現可能なタイプを含めてもよい[MAY]。 6.6. SUBSCRIBEリクエストのノーティファイア処理 SIP仕様で定義されるプロキシのルーティング手順に基づいて、SUBSCRIBEリク エストはプレゼンスエージェント(PA)に到達する。ここでは、SUBSCRIBEリクエ ストPAで行われるパッケージ固有の処理方法を定義する。リクエストの一般的 な処理規則は、RFC 3261(参考文献[1])のセクション8.2で説明されている。そ の他に、RFC 3265(参考文献[2])でも、一般的なSUBSCRIBE処理が説明されてい る。 Rosenberg Standards Track [Page 9] RFC 3856 SIP Presence August 2004 ユーザープレゼンスは、高度な機密情報である。プレゼンス情報の漏洩によっ て深刻な事態になる可能性があるため、PAのサブスクリプション処理(特に認証 と認可に関するもの)には、強固な要件が課せられる。 6.6.1. 認証 プレゼンスエージェントは、すべてのサブスクリプションリクエストを認証し なければならない[MUST]。この認証は、RFC 3261(参考文献[1])で定義されてい るメカニズムのいずれかを使用して実行できる。RFC 3261で規定されているよ うに、ダイジェスト認証は実装が必須であることに注意。 シングルドメインシステムで、サブスクライバすべてがPAと共有秘密(shared secret)を持っている場合、ダイジェスト認証とTLS(Transport Layer Security /参考文献[7])を組み合わせると、安全で機能性の高い認証ソリューションが実 現する。この使用例は、RFC 3261(参考文献[1])のセクション26.3.2.1に記載さ れている。 複数ドメインシナリオの場合、サブスクライバの認証済みIDを確立すること は、より困難である。認証は、推移的信頼関係によって確立される場合が多い と予想される。ネットワークでアサートされたアイデンティティのSIPメカニズ ムは、サブスクライバのアイデンティティを確立するときに適用できる(参考文 献[11])。 プレゼンティティは、自分自身をSIPS URIで表現してもよい[MAY]。「自分自身 を表現する」とは、プレゼンティティによって表現されるユーザーが、名刺や Webページなどに自分のプレゼンティティのSIPS URIを記載して示すことであ る。このURIと関連付けられるセマンティクスでは、RFC 3261(参考文献[1])に 記載されているように、そのURIのドメインで、サブスクライバとサーバー間の 各ホップごとにTLSを使用する必要がある。これによって、アイデンティティが ホップごとに検証されたという新たな保証が実現する(ただし、絶対てきな保証 ではない)。 別の認証メカニズムとして、S/MIMEがある。SIPと組み合わせて使用する方法 は、RFC 3261(参考文献[1])で詳しく説明されている。S/MIMEによって、PAがサ ブスクライバのアイデンティティを確立するときに使用できる、エンドツーエ ンドの認証が実現する。 6.6.2. 認可 認証された後、PAは認可を判断する。PAは、プレゼンティティから認可される まで、サブスクリプションを受け入れてはならない[MUST NOT]。使用する認可 方法は、本文書の範囲外である。認可は、前もってアクセスリスト(Webページ で指定など)で提供される場合がある。何らかの標準化されたアクセス制御リス トドキュメントをアップロードすることで、認可が提供される場合もある。 DIAMETER(参考文献[12])サーバーなど、バックエンドの認可サーバーも使用で Rosenberg Standards Track [Page 10] RFC 3856 SIP Presence August 2004 きる。認可情報が提供されていないサブスクリプションリクエストの受信した 後に、ユーザーへ認可を問い合わせることができるようにするのも有効であ る。SIPの「watcherinfo」イベントテンプレートパッケージ(参考文献[8])で は、プレゼンティティが、自分に誰かかサブスクライブしようとしたことを認 識できる手段が提供されている。これによって、プレゼンティティは認可を判 断できる。 認可の判断は、非常に複雑になる可能性がある。最終的に、認可の判断は、す べて拒否(rejected)、成功(successful)、保留(pending)という3つのステート のいずれかにマッピングできる。ある時点におけるプレゼンスステートの何ら かのサブセットについて、クライアントが情報を受信する認可を受けてたサブ スクリプションは、いずれも成功したサブスクリプションである。プレゼンス ステートの何らかのサブセットについて、クライアントが情報をまったく受信 しないサブスクリプションは、いずれも拒否されたサブスクリプションであ る。成功か許可かがまだわからないサブスクリプションは、保留である。一般 的に、保留のサブスクリプションは、サーバーがサブスクリプションの時点で 認可を取得できず、後で(おそらく、プレゼンティティが使用可能になったとき に)取得できる可能性がある場合に発生する。 成功、拒否、保留のサブスクリプションを伝達するための適切な応答コード は、RFC 3265(参考文献[2])で説明されている。 リソースが不明なステートにある場合、RFC 3265(参考文献[2])では、最初の NOTIFYのボディを空にすることを許容している。プレゼンティティの場合、こ のNOTIFYにはプレゼンスドキュメントを含めてもよい[MAY]。このドキュメント では、サブスクライバが参照を認可されたプレゼンスステートが何であって も、そのステートが示される。サブスクライバは、このステートを、プレゼン ティティの最新プレゼンスステートと解釈する。サブスクリプションが保留の 場合、プレゼンティティのステートには、保留ステータスを示す、何らかのテ キストのメモを含めるべきである[SHOULD]。 丁寧な拒否(plite blocking)は、参考文献[13]に記載されているが、サブスク リプションを拒否する場合(または保留の場合)でも、サブスクリプションに対 して200 OKを生成することで実行できる。当然ながら、この場合も、NOTIFYは 直ちに送信される。このNOTIFYに含めるプレゼンスドキュメントのコンテンツ は、実装者の判断に委ねられるが、サブスクライバに対して、リクエストが実 際は拒否されたことがわからないように構築すべきである[SHOULD]。この場 合、通常は、1つのコンタクトアドレスのステータスとして、「オフライン (offline)」または同様のステータスが示される。 6.7. NOTIFYリクエストのノーティファイア生成 RFC 3265には、NOTIFYメッセージの書式と構造が詳しく説明されている。ただ し、NOTIFYを送信するタイミング、リソースのステートを算出する方法、中立 または偽のステート情報を生成する方法、ステート情報が完全か部分的か、と Rosenberg Standards Track [Page 11] RFC 3856 SIP Presence August 2004 いう情報について、パッケージで詳細を説明することが必須とされている。こ のセクションでは、この必須とされているプレゼンスイベントパッケージの詳 細について説明する。 PAは、NOTIFYをどのタイミングで送信してもよい[MAY]。通常は、プレゼンティ ティのステートが変更されたときに送信される。NOTIFYリクエストには、プレ ゼンティティのステートを示すボディを含めてもよい[MAY]。NOTIFYが特定のサ ブスクライバに送信されるタイミングと、通知に含まれるボディのコンテンツ は、サブスクリプションを管理する認可ポリシーで規定される任意の規則に従 う。このプロトコルでは、このポリシーの範囲について一切の制限を指定しな い。適切なポリシーは、基本的に、何らかのプレゼンスタプルのステートが変 化したときに通知を生成することである。このような通知には、プレゼンティ ティ(プレゼンスエージェントとも呼ばれる)の完全な最新プレゼンスステート が含まれる。今後、プレゼンス情報の完全なステートではなく、変化した部分 のみを通知に含めるように、サブスクライバがリクエスト可能な拡張が定義さ れる可能性がある。 サブスクリプションが保留の場合、最終的な認可が決定された時点で、NOTIFY を送信できる。認可の決定結果が成功の場合、NOTIFYを送信すべきであり [SHOULD]、プレゼンティティの最新ステートが指定されたプレゼンスドキュメ ントを含めるべきである[SHOULD]。サブスクリプションが拒否された場合、 NOTIFYを送信してもよい[MAY]。RFC 3265(参考文献[2])にも記載されている ように、Subscription-Stateヘッダーフィールドは、サブスクリプションのス テートを示す。 NOTIFYのボディを送信するには、最新のSUBSCRIBEリクエストのAcceptヘッダー フィールドに列挙されているタイプのいずれか、Acceptヘッダーフィールドが ない場合は「application/pidf+xml」のタイプを使用しなければならない [MUST]。 PAがプレゼンティティのステートを知る手段も、本文書の範囲外である。登録 によって、プレゼンティティステートのコンポーネントを提供できる。ただ し、PAがプレゼンスドキュメントを構築するときに登録を使用する手段につい ては、実装上の判断に委ねられる。PUAが、プレゼンスエージェントに対して 明示的に自分のプレゼンスステートを通知する場合、望みどおりの結果を得る には、自分の登録を操作するのではなく、プレゼンスドキュメント(またはその 一部)を明示的に発行すべきである。 プライバシの理由から、多くの場合、通知のコンテンツは暗号化する必要があ る。この場合、S/MIMEで実行できる。暗号化は、SUBSCRIBEリクエストのFrom フィールドで特定されるように、サブスクライバの鍵を使用して実行できる。 同様に、通知の整合性はもサブスクライバにとって重要である。したがって、 通知のコンテンツで、S/MIMEを使用して信頼性とメッセージの整合性を実現し てもよい[MAY]。NOTIFYはプレゼンスサーバー(プレゼンティティから提示され Rosenberg Standards Track [Page 12] RFC 3856 SIP Presence August 2004 るユーザーの鍵にアクセス権を持っていない可能性がある)によって生成される ため、NOTIFYがサードパーティによって署名される場合がよくある。プレゼン ティティのドメイン上にいる認可担当者(authority)によって署名されることが 推奨される[RECOMMENDED]。つまり、ユーザーが「pres:user@example.com」の 場合、NOTIFYの署名は、example.comの認可担当者によるものにすべきである [SHOULD]。 6.8. NOTIFYリクエストのサブスクライバ処理 RFC3265(参考文献[2])で、NOTIFYリクエストの受信時にサブスクライバが従う 処理(整合の取れたリソースステートを構築する場合に必要な論理など)は、イ ベントパッケージに任されている。 本仕様では、すべてのNOTIFYに、プレゼンスドキュメント(つまり、完全で整合 性の取れたプレゼンティティステートを示すドキュメント)は含まれない。1つ のダイアログ内で、最も高いCSeqヘッダーフィールド値を持つNOTIFYリクエス トのプレゼンスドキュメントが最新のものである。そのNOTIFYにドキュメント が含まれない場合、次に高いCSeqヘッダーフィールド値を持つNOTIFYにあるプ レゼンスドキュメントが使用される。プレゼンティティの部分的なステートを 使用することを規定する拡張を発行する場合、整合性の取れたステートの達成 方法を解説する必要がある。 6.9. フォークされたリクエストの処理 RFC 3265(参考文献[2])では、すべてのパッケージで、SUBSCRIBEリクエストが フォークされた場合の処理について説明することを必須としている。 本仕様では、最初のSUBSCRIBEリクエストを発行した結果として、構築できるの は1つのダイアログのみと規定している。これによって、特定のプレゼンティ ティに対する特定のサブスクリプションについて、1つのPAのみが通知を生成す ることが保証される。この結果、プレゼンティティはアクティブな複数のPAを 持つことはできるが、プレゼンティティに対してすべてのPAが同じ通知を生成 できるように、すべてのPAを一様(homogeneous)にすべきである。各PAがプレゼ ンスデータのサブセットに通知を生成するような、一様ではないPAに対応する と、管理が複雑で困難になる。一様ではないPAに対応するには、サブスクライ バがプレゼンスデータを統合する役割を果たす必要がある。この統合機能は、 プレゼンティティに相当するエージェントによって実行される場合にのみ、適 切である。したがって、統合が必要な場合、プレゼンティティに相当するPAが 実行しなければならない[MUST]。 RFC 3265(参考文献[2])のセクション4.4.9には、1つのSUBSCRIBEリクエストに 対する応答で1つのダイアログ作成を保証することが必要な処理について説明さ れている。 Rosenberg Standards Track [Page 13] RFC 3856 SIP Presence August 2004 6.10. 通知の頻度 RFC 3265(参考文献[2])では、通知を送信可能な最高頻度を各パッケージで規定 することを必須としている。 PAは、5秒に1度を超える頻度で、1つのプレゼンティティに対して通知を生成す べきではない[SHOULD NOT]。 6.11. ステートエージェント RFC 3265(参考文献[5])では、各パッケージでパッケージ内でステートエージェ ントが持つ役割を考慮し、ステートエージェントが使用される場合の認証方法 と認可方法を規定することを必須としている。 ステートエージェントは、本パッケージの中心である。PAがプレゼンティティ のPUAと同居しない場合、PAは常にステートエージェントとして動作する。PA は、PUAのプレゼンスステートを収集し、プレゼンスドキュメントに統合する。 複数のPUAが存在する可能性があるため、中央のステートエージェントがこのよ うな統合を実行する必要がある。これが、ステートエージェントはプレゼンス に重要な部分であるという理由である。実際のところ、ステートエージェント には、「プレゼンスサーバー」という、特徴を示す用語がある。 6.11.1. 収集、認証、認可 ステートエージェントで収集を実行する手段は、純粋にポリシーの問題であ る。ポリシーは、プレゼンティティの希望とプロバイダの希望とを組み合わせ る場合が多い。本文書では、適用できるポリシーについて一切の制限を指定し ない。 ただし、ステートエージェントはプレゼンティティのステートにアクセス権を 持つ、という条件が必要なのは確かである。このステートは、PUAによって処理 される。ステートエージェントがこのステートを取得できる方法のひとつは、 ステートにサブスクライブすることである。結果的に、1つのプレゼンティティ に対してプレゼンスステートを処理する5つのPUAがある場合、ステートエー ジェントは、5つのサブスクリプション(1つのPUAに付き1つのサブスクリプショ ン)を生成する。このメカニズムを実行するには、プレゼンティティのドメイン から送信されるときに認証される可能性のあるサブスクリプションについて、 処理および認可するステートのPAとして動作する機能を、すべてのPUAに持たせ るべきである[SHOULD]。 ステートエージェントの用法は、PAが使用する認証方法によって大幅に変わ る。ステートエージェントでは、任意のSIP認証メカニズムを使用できる。ただ し、ダイジェスト認証では、プレゼンティティとサブスクライバ間の共有秘密 をステートエージェントが認識している必要がある。この場合、プレゼンティ ティからステートエージェントへ共有秘密を安全に伝送する何らかの手段が必 要になる。 Rosenberg Standards Track [Page 14] RFC 3856 SIP Presence August 2004 一方で、ステートエージェントの使用は、認可に大きな影響がある。セクショ ン6.6に記載されているように、PAはすべてのサブスクリプションを認可する必 要がある。明示的な認可ポリシーが定義されていない場合、PAはユーザーへ認 可について問い合わせる必要がある。エッジプレゼンスサーバーの場合(PUAが PAと同居するエージェント[※訳注])、これは簡単に実現する[訳注: 原文ミス を修正。原文では"(where the PUA is co-located with the PUA)"。]。ただ し、ステートエージェントを使用する場合(つまり、プレゼンスサーバー)、認 可を判断する必要があることをユーザーに警告する手段が必要である。これ が、ウォッチャー情報イベントテンプレートパッケージ(参考文献[8])の理由で ある。すべてのステートエージェントは、ウォッチャー情報テンプレートパッ ケージに対応すべきである[SHOULD]。 6.11.2. 移行 場合によっては、あるサーバーから別のサーバーへPA機能を移行することは理 にかなっている。たとえば、スケールの理由から、PAは実行されていないがPUA はネットに接続しているときに、PA機能はプレゼンスサーバーと同じ場所に置 かれる可能性がある。PAは、ネットワーク内のステートを減らすためにサブス クリプションを移行する。移行の実行メカニズムは、RFC 3265(参考文献[2])の セクション3.3.5に記載されている。ただし、パッケージでは、このような移行 が実行される条件を定義する必要がある。 PAは、任意のタイミングで、構成または動的な手段でサブスクリプションを移 行してもよい[MAY]。REGISTERリクエストは、プレゼンスサーバーが機能をPUA に移行できることを検出できる、動的な方法として働く。特に、PUAがPA機能へ の対応を示す場合、着呼側能力仕様(参考文献[9])を使用して、SUBSCRIBEリク エストメソッドとプレゼンスイベントパッケージに対応することを示すべきで ある[SHOULD]。これら2つを組み合わせて、PAが定義される。当然ながら、この ような明示的なヒントがなくても、プレゼンスサーバーは常に移行を試行でき る。405または489応答コードで失敗した場合、サーバーは、PUAがPA機能に対応 していないことがわかる。この場合、サーバー自身が、そのサブスクリプショ ンリクエストに対してPAとして動作する必要がある。このようなエラーが発生 した場合、サーバーは、登録の有効期間中にPUAへ移行する試みを続けるべきで はない[SHOULD NOT]。ただし、このようなエラーのリクエストによって余計な トラフィックが発生しないようにするには、プレゼンスサーバーは着呼側能力 拡張に対応すべきである[SHOULD]。 さらに、SUBSCRIBEリクエストとプレゼンスイベントパッケージへの対応を示す ことは、サブスクリプションを移行する場合の十分条件ではない。PAは、複数 のPUAから受信した統合のプレゼンスドキュメントを構築している場合、サブス クリプションを移行すべきではない[SHOULD NOT]。 Rosenberg Standards Track [Page 15] RFC 3856 SIP Presence August 2004 7. プレゼンスステートの取得 PAは、プレゼンス情報をさまざまな方法で取得できる。本仕様では具体的なメ カニズムを必須としない。このセクションでは、参考目的でのみ、いくつかの 選択肢を概説する。 7.1. 同居 PA機能がPUAと同居すると、プレゼンスはPAに直接認識される。 7.2. REGISTER UAは、SIP REGISTERメソッドを使用して、SIPネットワークに最新の通信アドレ ス(つまりContactアドレス)を通知する。複数のUAは、同じAddresses-of- Recordに対して個々にContactアドレスを登録できる。この登録ステートは、プ レゼンティティのプレゼンス情報全体のうち、重要な部分を占める。これは、 通信の基本的な送信先を示す。 プレゼンスを構築するときにREGISTER情報を使用することは、PAが登録データ ベースにアクセス権を持ち、そのデータベースに変更内容を通知できる場合に のみ可能である。実行方法のひとつは、PAをレジストラと同居させる方法であ る。 登録ステートをプレゼンスステートに伝達する手段は、ローカルポリシーの問 題であり、本仕様の範囲外である。ただし、一定の一般的なガイドラインは提 供可能である。登録のAddresses-of-Record(Toヘッダーフィールド)によってプ レゼンティティが特定される。各登録済みContactヘッダーフィールドによっ て、プレゼンティティの通信ポイント(タプルで構築可能)が特定される。タプ ルのContactアドレスは、登録済みのContactアドレスと同一である必要はな い。代わりにAddresses-of-Recordを使用することで、ウォッチャーからの以降 の通信は、プロキシを通過することできる。これは、プレゼンティティとプロ バイダの代わりに処理するポリシーの場合に有効である。 登録を使用してプレゼンスステートを操作するPUAは、SIPの着呼側能力拡張(参 考文献[9])を利用すべきである[SHOULD]。これによって、PUAは、自身に関する より豊かな情報を持つPA機能を備えることができる。たとえば、メソッド 「MESSAGE」が列挙されたメソッドパラメータが存在する場合、インスタント メッセージングに対応することを示す。 Contactヘッダーフィールドのq値(参考文献[1])は、Contactヘッダーフィール ドにある多様な通信アドレスの中で相対的な優先度を設定するときに使用でき る。 Rosenberg Standards Track [Page 16] RFC 3856 SIP Presence August 2004 プレゼンス情報を取得するときに登録を使用すると、登録の信頼性と整合性の 要件が強化される。したがって、プレゼンスユーザーエージェントが使用する REGISTERリクエストは、認証されなければならない[MUST]。 7.3. プレゼンスドキュメントのアップロード PUAからPAへプレゼンスドキュメントをアップロードする手段が存在する場合、 PAは、そのようなドキュメントを統合する機能と再配布する機能を備えること ができる。この場合、PAは、同じプレゼンティティの各PUAから受信したプレゼ ンスドキュメントを取得して、全PUAのタプルを1つのプレゼンスドキュメント にマージする。通常、この統合は、管理者またはユーザーが統合方法を定義し たポリシーによって実行される。 プレゼンスドキュメントがプレゼンスエージェントにアップロードされる具体 的な手段は、本仕様の範囲外である。サブスクライバに配布されるプレゼンス をPUAが直接操作する場合、プレゼンスドキュメントを直接アップロードするこ とが推奨される[RECOMMENDED]。 8. メッセージフロー例 このメッセージフローでは、プレゼンスサーバーがプレゼンティティに通知を 送信する役割を担う方法について図示する。このフローでは、サーバーにおい てこのリソースにサブスクライブする権限がウォッチャーに付与されていると 仮定している。 このフローでは、PUAは、サーバーに対し、何らかのSIP以外の手段でアップ ロードしたプレゼンス情報について通知する。 Content-Lengthヘッダーフィールドの値が「...」の場合、この値は、任意の長 さを持つボディであることを示す。 Rosenberg Standards Track [Page 17] RFC 3856 SIP Presence August 2004 ウォッチャー プレゼンスサーバー PUA | F1 SUBSCRIBE | | |------------------>| | | F2 200 OK | | |<------------------| | | F3 NOTIFY | | |<------------------| | | F4 200 OK | | |------------------>| | | | | | | プレゼンスの更新 | | |<------------------ | | | | | F5 NOTIFY | | |<------------------| | | F6 200 OK | | |------------------>| | メッセージ詳細 F1 SUBSCRIBE ウォッチャー -> example.comサーバー SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 To: From: ;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 17766 SUBSCRIBE Max-Forwards: 70 Event: presence Accept: application/pidf+xml Contact: Expires: 600 Content-Length: 0 Rosenberg Standards Track [Page 18] RFC 3856 SIP Presence August 2004 F2 200 OK example.com サーバー -> ウォッチャー SIP/2.0 200 OK Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 ;received=192.0.2.1 To: ;tag=ffd2 From: ;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 17766 SUBSCRIBE Expires: 600 Contact: sip:server.example.com Content-Length: 0 F3 NOTIFY example.com サーバー -> ウォッチャー NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk From: ;tag=ffd2 To: ;tag=xfg9 Call-ID: 2010@watcherhost.example.com Event: presence Subscription-State: active;expires=599 Max-Forwards: 70 CSeq: 8775 NOTIFY Contact: sip:server.example.com Content-Type: application/pidf+xml Content-Length: ... [PIDF ドキュメント] F4 200 OK ウォッチャー -> example.comサーバー SIP/2.0 200 OK Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk ;received=192.0.2.2 From: ;tag=ffd2 To: ;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 8775 NOTIFY Content-Length: 0 Rosenberg Standards Track [Page 19] RFC 3856 SIP Presence August 2004 F5 NOTIFY example.com サーバー -> ウォッチャー NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl From: ;tag=ffd2 To: ;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 8776 NOTIFY Event: presence Subscription-State: active;expires=543 Max-Forwards: 70 Contact: sip:server.example.com Content-Type: application/pidf+xml Content-Length: ... [新しいPIDF ドキュメント] F6 200 OK SIP/2.0 200 OK Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl ;received=192.0.2.2 From: ;tag=ffd2 To: ;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 8776 NOTIFY Content-Length: 0 9. セキュリティの考慮 プレゼンスには、セキュリティの考慮事項が多数ある。RFC 2779(参考文献 [13])には、多くの事項が概説されており、本文書でもすでに論じている。この セクションでは、各問題を検討する。 9.1. 機密性 機密性は、プレゼンスシステムの多くの側面を網羅している。 o サブスクライバは、特定のユーザーにサブスクライバしたことを公表 したくない場合がある。 o ユーザーは、特定のユーザーからサブスクリプションを受けたことを 公表したくない場合がある。 o 通知(およびフェッチ結果)には、サブスクライバ以外の第三者に公表 すべきではない機密データが含まれる可能性がある。 Rosenberg Standards Track [Page 20] RFC 3856 SIP Presence August 2004 機密性は、ホップバイホップの暗号化とエンドツーエンドの暗号化を組み合わ せることで実現する。ホップバイホップのメカニズムによって、スケーラブル な機密性サービスを実現し、トラフィック解析などの攻撃を無効にし、プレゼ ンスメッセージのすべての側面を隠すことができる。ただし、このメカニズム は信頼関係の推移性に基づいて運用されるため、結果的に、メッセージのコン テンツはプロキシに公開される。エンドツーエンドのメカニズムでは、信頼関 係の推移性は必須ではなく、所定の受信者にのみ情報が公表される。ただし、 エンドツーエンドの暗号化では、すべての情報を隠すことができず、トラ フィック解析を受ける可能性がある。強力なエンドツーエンド認証および暗号 化は、公開鍵を使用して実行可能であり、エンドツーエンドの暗号化は、秘密 鍵を使用して実行できる(参考文献[14])。ホップバイホップおよびエンドツー エンドのメカニズムのどちらも、完全なプライバシサービスには必要になる可 能性が高い。 SIPでは、任意のホップバイホップ暗号化スキームを使用できるが、サーバーで はTLSの実装が必須である。したがって、要素間でTLS(参考文献[7])を使用して この機能を実現することが推奨される[RECOMMENDED]。サーバー間、クライアン トとサーバー間のセキュリティのためにTLSを使用する場合の詳細については、 RFC 3261(参考文献[1])のセクション26.3.2を参照のこと。 S/MIMEによって、SUBSCRIBEとNOTIFYリクエストの両方の伝送時に、エンドツー エンドでSIPの暗号化を使用してもよい[MAY]。 9.2. メッセージの整合性と信頼性 メッセージのコンテンツが実際に発信元から送信されたものと一致することを メッセージの受信者が確認できること、本当の発信元がだれかをメッセージの 受信者が判断できることは重要である。この条件は、SUBSCRIBEおよびNOTIFYの リクエストおよび応答のどちらにも当てはまる。NOTIFYリクエストは特に重要 である。認証と整合性がなければ、プレゼンスドキュメントが偽造や修正され たり、ウォッチャーが不正なプレゼンス情報にだまされたりする可能性があ る。 RFC 3261には、認証と整合性を実現できる多くのメカニズムが紹介されてい る。PAがウォッチャーを認証する場合、HTTPダイジェスト(RFC3261のセクショ ン22)を使用してもよい[MAY]。結果的に、全ウォッチャーがHTTPダイジェスト に対応しなければならない[MUST]。これは冗長な要件ではあるが、RFC3261で、 すべてのSIPユーザーエージェントは対応が義務づけられているためである。信 頼性と整合性があるサービスにするために、ウォッチャーは、プレゼンティ ティにサブスクライブするときにSIPSスキームを使用してもよい[MAY]。SIPに 対応するには、すべてのPAは、プロキシと同様に、TLSとSIPSに対応しなければ ならない[MUST](RFC3261のセクション26.3.1を参照)。 さらに、SUBSCRIBEおよびNOTIFYリクエストの整合性と信頼性のために、SMIME を使用してもよい[MAY]。SMIMEは、RFC3261のセクション23に記載されている。 Rosenberg Standards Track [Page 21] RFC 3856 SIP Presence August 2004 9.3. アウトバウンド認証 アウトバウンドメッセージの伝送にローカルプロキシを使用する場合、プロキ シ認証が推奨される[RECOMMENDED]。これは、元のネットワークで発信元の身元 を検証し、なりすましやスパムを防ぐ場合に有効である。 9.4. リプレイ攻撃の回避 リプレイ攻撃は、プレゼンティティの古いプレゼンスステートでウォッチャー をだますときに使用される可能性がある。たとえば、プレゼンティティが「オ フライン」であると記述しているドキュメントが再生されると、ウォッチャー はだまされて、そのユーザーがオンラインになっていないと思う。これによっ て、そのプレゼンティティとの通信は実質的にブロックされる。 SIP S/MIMEは、SIPリクエストボディで、メッセージの整合性と信頼性を実現で きる。ウォッチャーとPAは、S/MIME署名を実装してこのリプレイ攻撃を防ぐこ とができる。整合性と信頼性のためにS/MIMEを使用する場合、NOTIFYリクエス トで伝達するプレゼンスドキュメントには、タイムスタンプを含めなければな らない[MUST]。PIDFの場合、timestamp要素を使用して実現できる。参考文献 [6]のセクション6を参照のこと。最も新しく受信したプレゼンスドキュメント のタイムスタンプよりも古いタイムスタンプのタプルは、古いものと扱い、破 棄すべきである[SHOULD]。 最後に、HTTPダイジェスト認証(ウォッチャーとPAは実装しなければならない [MUST])は、PAとウォッチャー間に共有秘密がある場合、リプレイ攻撃を防ぐた めに使用してもよい[MAY]。この場合、ウォッチャーは、信頼性と整合性を保護 して、NOTIFYリクエストを変更することができる。 9.5. サードパーティに対するDoS攻撃 サービス否定(DoS/Denial of Service)攻撃は、オープンでドメイン間のプレゼ ンスプロトコルにとって重大な問題である。残念ながら、プレゼンスは、増幅 する特徴があるため、分散型DoS(DDoS/Distributed DoS)攻撃の対象になりやす い。プレゼンスデータの適切な動的ソースが検出される限り、1つのSUBSCRIBE メッセージによって、ほとんどの無限の通知ストリームが生成される可能性が ある。したがって、対象に攻撃をしかけるための簡単な方法は、サブスクリプ ションを大量のユーザーに送信してContactヘッダーフィールド(通知の送信先) に対象のアドレスを指定することである。RFC 3265には、このような攻撃に対 処できる多くのメカニズムが紹介されている(参考文献[2])。NOTIFYがAckされ ない場合、または望まれない場合、NOTIFYを生成したサブスクリプションは削 除される。これによって、偽のContactアドレスを提示する増幅の特性は排除さ れる。 Rosenberg Standards Track [Page 22] RFC 3856 SIP Presence August 2004 PAにおける認証と認可でも、このような攻撃を防ぐことができる。通常、認可 ポリシーでは、未知のウォッチャーからのサブスクリプションを許可しない。 プレゼンティティへの攻撃が未知のウォッチャーから実行された場合(一般的な 場合)、その攻撃は軽減される。 9.6. サーバーに対するDoS攻撃 DoS攻撃は、ユーザーコミュニティへのサービスを妨害する目的で、プレゼンス エージェント自体に仕掛けられる可能性もある。SIPでは、RFC 3265(参考文献 [2])に従って、このような攻撃に対処できるメカニズムがいくつか紹介されて いる。 サーバーは、ダイジェスト認証(参考文献[1])を使用した4ウェイハンドシェイ クによって、SYN攻撃型の攻撃を防ぐことができる。サーバーがクライアントと の間に共有秘密を持っていない場合でも、RFC3261(参考文献[1])のセクション 22.1に記載されている「anonymous」ユーザーメカニズムを使用して、リクエス トのソースIPアドレスを検証できる。また、SIPでは、サーバーからクライアン トに対し、503応答コードを使用して、リクエストの送信を控えるように指示で きる(RFC3261(参考文献[1])のセクション21.5.4)。これは、分散型DoS攻撃の結 果、生成される大量のSUBSCRIBEリクエストを回避するときに使用できる。 10. IANA条項 本仕様では、RFC3265(参考文献[2])で定義されている登録手順に基づいて、イ ベントパッケージを登録する。登録に必要とされる情報は以下の通り。 パッケージ名: presence パッケージまたはテンプレートパッケージ: これはパッケージである。 公開されている文書: RFC 3856 連絡先: Jonathan Rosenberg, jdrosen@jdrosen.net。 Rosenberg Standards Track [Page 23] RFC 3856 SIP Presence August 2004 11. 寄稿者 以下の寄稿者は、本仕様の技術設計時に初期チームの一員だった。 Jonathan Lennox Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 EMail: lennox@cs.columbia.edu Robert Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 EMail: rsparks@dynamicsoft.com Ben Campbell EMail: ben@nostrum.com Dean Willis dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 EMail: dwillis@dynamicsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 EMail: schulzrinne@cs.columbia.edu Rosenberg Standards Track [Page 24] RFC 3856 SIP Presence August 2004 Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: huitema@microsoft.com Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: bernarda@microsoft.com David Gurle Reuters Corporation EMail: David.Gurle@reuters.com David Oran Cisco Systems 170 West Tasman Dr. San Jose, CA 95134 EMail: oran@cisco.com 12. 謝辞 Rick Workman、Adam Roach、Sean Olson、Billy Biggs、Stuart Barkley、 Mauricio Arango、Richard Shockey、Jorgen Bjorkner、Henry Sinnreich、 Ronald Akers、Paul Kyzivat、Ya-Ching Tan、Patrik Faltstrom、Allison Mankin、Hisham Khartabilの各氏に、本仕様への助言と助力をいただいたこと に謝辞を述べたい。 13. 規範となる参考文献 [1] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004. [4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Rosenberg Standards Track [Page 25] RFC 3856 SIP Presence August 2004 [5] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004. [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [8] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004. [9] Schulzrinne, H. Rosenberg, J., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. 14. 有益な参考文献 [10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [11] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, May 2004. [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [13] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [14] Gutmann, P., "Password-Based Encryption for CMS", RFC 3211, December 2001. 15. 著者の連絡先 Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 EMail: jdrosen@dynamicsoft.com Rosenberg Standards Track [Page 26] RFC 3856 SIP Presence August 2004 16. 完全な著作権表示 Copyright (C) The Internet Society (2004). 本文書は、BCP78に含まれる権 利、ライセンス、制限の対象となり、BCP78に記載されている例外に従い、著者 はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿者 が代表となる組織、または寄稿者を後援する組織(存在する場合)、インター ネットソサエティおよびIETFは、この情報がいかなる権利も侵害していないと いう保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われな い。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知的 所有権または他の諸権利の有効性または範囲に関して、またはこのような権利 下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解 を持たない。このような権利を確認する独自の取り組みを行ったことも示さな い。RFC文書に関する手順の情報は、BCP78とBCP79を参照のこと。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセンス の保証すべて、またはこのような所有権の使用に関して、本仕様の実装者また はユーザーが一般的なライセンスまたは許可の取得を試みた結果については、 IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能である。 IETFは、本規格の実装に必要になる可能性がある技術の範囲に及ぶ可能性があ る、任意の著作権、特許、特許アプリケーション、その他の所有権への配慮 を、関係者に依頼している。情報については、IETFの ietf-ipr@ietf.org まで 連絡されたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供されて いる。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Rosenberg Standards Track [Page 27]