Network Working Group R. Sparks Request for Comments: 3892 Xten Category: Standards Track September 2004 セッション開始プロトコル(SIP)のReferred-Byの仕組み The Session Initiation Protocol (SIP) Referred-By Mechanism 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 セッション開始プロトコル(Session Initiation Protocol/SIP)のREFERメソッ ドによって、あるパーティ(参照指示端末/referrer)が、第2のパーティ(被参 照端末/referee)へ、参照対象の任意URIを提示する仕組みが実現する。この URIがSIP URIの場合、被参照端末はSIPリクエスト(INVITEのことが多い)をそ のURI(参照先端末/refer target)へ送信する。本文書は、REFERメソッドを拡 張して、参照指示端末が、被参照端末を中継者として利用し、参照先端末へ REFERリクエストに関する情報を提示できるようにする。この情報には、参照 指示端末のアイデンティティと参照指示端末が参照したURIが含まれる。この 仕組みは、悪意のある中継者からこの情報を保護するためにS/MIMEを利用す る。この保護はオプションだが、提示されない場合、受信側はリクエストの受 信を拒否してもよい。 Sparks Standards Track [Page 1] RFC 3892 The SIP Referred-By Mechanism September 2004 目次 1. 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. 要件の表記法 . . . . . . . . . . . . . . . . . . . . . . 3 2. Referred-Byの仕組み . . . . . . . . . . . . . . . . . . . . . 3 2.1. 参照指示端末の動作 . . . . . . . . . . . . . . . . . . . 4 2.2. 被参照端末の動作 . . . . . . . . . . . . . . . . . . . . 4 2.3. 参照先端末の動作 . . . . . . . . . . . . . . . . . . . . 5 3. Referred-Byヘッダーフィールド . . . . . . . . . . . . . . . . 6 4. Referred-Byトークン . . . . . . . . . . . . . . . . . . . . . 7 4.1. 参照先端末によるReferred-Byトークンの検査 . . . . . . . 8 5. 429 Provide Referror Identityエラー応答 . . . . . . . . . . . 8 6. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 8 6.1. Referred-Byトークンでの被参照端末の識別 . . . . . . . . 10 7. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. 基本的なREFER . . . . . . . . . . . . . . . . . . . . . 11 7.2. 保護されていないREFER . . . . . . . . . . . . . . . . . 14 7.3. 参照指示端末のアイデンティティの要求 . . . . . . . . . . 14 7.4. ネストされたREFER . . . . . . . . . . . . . . . . . . . 18 8. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. 寄稿者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . 23 10.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . 24 11. 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . . 25 1. 概要 SIPのREFERメソッド[2]によって、あるパーティ(参照指示端末/referrer)が、 第2のパーティ(被参照端末/referee)へ、参照対象の任意URIを提示する仕組み が提供される。このURIがSIP URIの場合、被参照端末はSIPリクエスト(INVITE のことが多い)をそのURI(参照先端末/refer target)へ送信する。[2]に記載さ れている方法では、この参照されたリクエストと、他のリクエスト(被参照端 末が参照先端末に送信した可能性のあるもの)を区別できない。 参照指示端末 被参照端末 参照先端末 | | | | REFER | | | Refer-To: target | | |----------------->| INVITE target | | |------------------->| Sparks Standards Track [Page 2] RFC 3892 The SIP Referred-By Mechanism September 2004 呼の転送[8]など、REFERの適用例がある。呼の転送では、参照先端末に参照指 示端末およびREFERリクエスト自体に関して、ある程度の情報を提供するのが 望ましい。この情報には、参照指示端末のアイデンティティ、参照先URI、参 照の時間などが含まれる可能性がある。参照先端末は、参照対象リクエストの 受け入れを判断するときに、この情報を利用できる。本文書は、一連の仕組み を定義して、この情報を提供する。 本文書中の仕組みはいずれも、被参照端末が参照対象リクエストにコピーする REFERリクエストに、情報を指定する必要がある。この結果、必然的に、被参 照端末は盗聴者となり、その情報に対してman-in-the-middle(仲介者)攻撃を 実行可能な立場に置かれる。 本文書では、初歩段階として、参照指示端末のアイデンティティを伝達する仕 組みを定義する。このアイデンティティは、新規のヘッダー「Referred-By」 でSIP URIとして示される。参照先端末は、たとえ被参照端末から保護されて いなくても、本文書に記載される危険性と制限を踏まえた上で、この情報を使 用できる。次に、本文書では、参照指示端末のアイデンティティを示し、 REFERリクエストの他の情報を取得する目的で、S/MIMEベースの仕組みを定義 する。これによって、参照先端末が被参照端末による改竄(と他の望ましくな い動作)を検出できるようになる。 1.1. 要件の表記法 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119[1]のBCP 14に記載さ れるとおりに解釈されるべきである。 2. Referred-Byの仕組み 以下の図は、Referred-By情報が参照先端末に伝達される方法をまとめた。参 照指示端末は、自身のSIPのAddresses-of-Recordを含むReferred-Byヘッダー を提示する。また、オプションで、参照指示端末のアイデンティティとREFER リクエストの詳細を反映するS/MIMEで保護されたトークンを関連付ける。被参 照端末は、このヘッダーと(提供された場合は)トークンを、トリガーされるリ クエスト(この図ではINVITE)にコピーする。 Sparks Standards Track [Page 3] RFC 3892 The SIP Referred-By Mechanism September 2004 参照指示端末 被参照端末 参照先端末 | | | | REFER | | | Refer-To: target | | | Referred-By: referrer;cid=X | | | | | | (ボディ部の1つは) | | | Content-ID: X | | | | | |----------------------------->| | | | INVITE target | | | Referred-By: referrer;cid=X | | | | | | (ボディ部の1つは) | | | Content-ID: X | | | | | |---------------------------->| 2.1. 参照指示端末の動作 REFERリクエストを送信するUA(参照指示端末)は、リクエストにReferred-By ヘッダーフィールド値を示してももよい[MAY]。REFERリクエストには、2つ以 上のReferred-Byヘッダーフィールド値を含めてはならない[MUST NOT]。 Sparks Standards Track [Page 4] RFC 3892 The SIP Referred-By Mechanism September 2004 参照指示端末は、REFERリクエストにReferred-Byトークンを含めてもよい [MAY]。Referred-Byトークンを含むREFERリクエストには、このトークンを含 むボディ部のContent-IDと等しいcidパラメータ値を指定した、Referred-By ヘッダーフィールド値を含めなければならない[MUST]。 参照先端末が、リクエストを受け入れるために有効なReferred-Byを要求して いる場合、参照指示端末は、message/sipfrag[4]のボディを含むNOTIFYを受け 取る。このNOTIFYは、参照対象リクエストに対する429 "Provide Referrer Identity"の最終応答を示す。これは、トークンが提示されなかったか、また は提示されたトークンが無効の場合に発生する。 被参照端末が、REFERを受け入れるためにReferred-Byトークンの指定を要求す る場合、参照指示端末は、REFERに対して429(Provide Referror Identity)応 答を受信する。 参照指示端末は、429応答の受信後、または429を含むNOTIFYの受信後に、被参 照端末の参照を再試行したい場合は、Referred-Byトークンを含む新規のREFER リクエストを提示してもよい[MAY]。 2.2. 被参照端末の動作 SIP URI(sip:またはsips:スキームを使用)に対するREFERリクエストを受け入 れるUA(被参照端末)は、すべてのReferred-Byヘッダーフィールド値および トークンを、参照対象リクエストに修正しないでコピーしなければならない [MUST]。 被参照端末は、Referred-Byトークンを含まないREFERリクエストを、429 (ProvideReferrer Identity)応答で拒否してもよい[MAY]。被参照端末は、所 有していないキーに暗号化されたReferred-Byトークンを含むリクエストを、 拒否すべきではない[SHOULD NOT]。これは、被参照端末はトークンを復号でき ないためである。(このような拒否が適切なシナリオは、被参照端末が匿名の まま試行するときである。セクション6.1参照のこと。)それでも、[3]に従っ て、被参照端末は、このような暗号化トークンの署名を検証する機能を持つべ きである。 被参照端末は、参照指示端末と参照先端末に対し、同じアイデンティティを提 示すべきである[SHOULD]。 2.3. 参照先端末の動作 UAがREFER以外のSIPリクエストを受信した場合は、そのリクエストに Referred-Byヘッダーフィールドとトークンがあるかどうか検査してもよい [MAY]。 Referred-Byヘッダーフィールド値が存在しない場合、このUAは、このリクエ ストと、被参照端末として動作するUAが送信した可能性のあるリクエストとを 区別することができない。したがって、UAは、[5]で述べられている承認ポリ シーと承認処理を、厳格にこのリクエストに適用する。 Referred-Byヘッダーフィールド値が存在する場合、受信するUAは自身が参照 先端末であるとみなすことができ、Referred-Byヘッダーフィールドおよび トークンに基づいて、別の承認ポリシーを適用してもよい[MAY]。 被参照端末は、Referred-Byヘッダーフィールド値のコンテンツを修正した り、あるいは、REFERが実際には存在しなくても、不正に提示できる立場にあ る。このような動作が承認ポリシーに影響を与え得る場合(誤解を招くコンテ ンツを表示してエージェントのユーザーに影響を与える場合など)、参照先端 末は、正当なReferred-Byトークンが提示されるように要求するべきである [SHOULD]。 Referred-Byトークンが存在しないか、または、セクション5で定義されている 429(Provide Referror Identity)エラー応答を用いてトークンが無効になった 場合、参照先端末はリクエストを拒否してもよい[MAY]。[7]の428エラー応答 は、この用途には合っていない(参照先端末は、被参照端末からの認証トーク ンを要求する必要があるため)。 Referred-Byトークンが存在しない場合、参照先端末はそのリクエストの処理 を進めてもよい[MAY]。エージェントがリクエスト処理の一部として、その ユーザーにReferred-Byヘッダーから何らかの情報を提供する場合、情報が疑 わしいことをユーザーに通知しなければならない[MUST]。 参照先端末は無効なReferred-Byトークンを持つ整形式(well-formed)ではない リクエスト(セクション4参照)を、429エラー応答で拒否しなければならない [MUST]。 Sparks Standards Track [Page 5] RFC 3892 The SIP Referred-By Mechanism September 2004 3. Referred-Byヘッダーフィールド Referred-Byは[5]で定義されているリクエストヘッダーフィールドである。 Referred-Byはどのリクエストにも出現し得る。Referred-Byは参照指示端末の アイデンティティを表すSIP URIを伝達し、また、そのアイデンティティのよ りセキュアな説明を提供する、ボディ部分のContent-ID(Referred-Byトーク ン)もオプションで伝達する。 Referred-By = ("Referred-By" / "b") HCOLON referrer-uri *( SEMI (referredby-id-param / generic-param) ) referrer-uri = ( name-addr / addr-spec ) referredby-id-param = "cid" EQUAL sip-clean-msg-id sip-clean-msg-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT dot-atom = atom *( "." atom ) atom = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "'" / "`" / "~" ) Content-IDは、[5]で定義されるgen-valueの拡張に準拠しなければならない SIPのヘッダーパラメータ値として出てくるため、この文法では、gen-valueの 拡張と[9]のmsg-idとの間で共通する値を生成する。メッセージのMIMEボディ で使用されるContent-IDを派生させる際に、sip-clean-msg-idを囲む二重引用 符を左と右の三角かっこで置換しなければならない[MUST]。例えば、以下の通 り。 Referred-By: sip:r@ref.example;cid="2UWQFN309shb3@ref.example" は、トークンが、以下を含むボディ部にある、ということを示す。 Content-ID: <2UWQFN309shb3@ref.example> referrer-uri にカンマ、疑問符、またはセミコロンが含まれる場合(たとえ ば、URIのパラメータを含む場合)、URIは山かっこ(<と>)で囲まなければなら ない[MUST]。すべてのURIパラメータは、この山かっこ内に含める。URIを山 かっこで囲まない場合、セミコロンで区切られたパラメータは、URIのパラ メータではなく、ヘッダーパラメータになる。 Referred-ByヘッダーフィールドはどのSIPリクエスト中に出現してもよい [MAY]が、ACKとCANCELでは意味を持たない。プロキシはReferred-Byヘッダー フィールド値を読み取ることができる必要はない、また、それを取り除いた り、修正したりしてはならない[MUST NOT]。 Sparks Standards Track [Page 6] RFC 3892 The SIP Referred-By Mechanism September 2004 以下の行は、RFC 3261の表3と同様に解釈する必要がある。 Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________________ Referred-By R - o - o o o 4. Referred-Byトークン Referred-Byトークンは[3]で定義されているAuthentication IdentityBodyで ある。このボディ部分はMIME[6]のContent-ID: フィールドと同一でなければ ならない[MUST]。 Referred-Byトークン内のsipfragには、REFERリクエストにある、Refer-Toお よびReferred-By、Dateヘッダーフィールドの複写を含めなければならない [MUST]。 情報が参照先端末にとって無用であったり、情報漏洩となる可能性もあるた め、このトークンにはREFERリクエストのCall-IDヘッダーフィールドを含 めるべきではない[SHOULD NOT]。必要とされるアイデンティティはReferred- Byヘッダーフィールドで示されているので、トークンにはREFERリクエストの Fromヘッダーフィールドを含めるべきではない[SHOULD NOT]。 トークンにはREFERリクエストのToヘッダーフィールドを含めてもよい[MAY] が、参照指示端末は被参照端末を暗号化して特定せずに、含めるべきではない [SHOULD NOT]。この認証を達成できる方法の一部は、参照指示端末と被参照端 末間のTLS関係で使用される証明書の検査、あるいは、[5]に詳細が書かれてい るS/MIME暗号化技術を使用してREFERリクエストにあるRefer-Toヘッダーの暗 号化を伴う。 TLSの関連付けを確立するために使用される証明書を検査するときに、トーク ンのToヘッダーフィールドのURIでアサートされたアイデンティティは、被参 照端末の証明書にあるsubjectAltNamesと比較される。sipとsips URIスキーム は、この比較と同等に扱わなければならない[MUST]。URIが完全一致の場合、 認証の信頼度は高いため、Toヘッダーフィールドをトークンに追加してもよい [MAY]。証明書のサブジェクトに、URIのホスト名部分が一致するホスト名のみ が含まれる場合、トークンにToヘッダーフィールドを含める前に、そのユー ザーからの承認を求めている参照指示端末のユーザーに対して、アプリケー ションレベルの警告を発行すべきである[SHOULD]。 Toヘッダーフィールドをトークンに含めることによって、トークンがアサート する要求は非常に強化されるが、セクション6.1に記載されるように、プライ バシに影響を及ぼす可能性がある。 新規のヘッダーフィールドとボディ部をトークンに含めてもよい[MAY]。 Sparks Standards Track [Page 7] RFC 3892 The SIP Referred-By Mechanism September 2004 [3]に記載されているように、Referred-Byトークンは署名と同様に、暗号化し てもよい[MAY]。これらの操作に使用される証明書のsubjectAltNameは、トー クン内のReferred-Byヘッダーフィールドにあるreferrer-uriで述べられてい るアイデンティティと完全一致すべきである[SHOULD]。 4.1. 参照先端末によるReferred-Byトークンの検査 参照先端末は、無効な署名を持つReferred-Byトークンを、無効なトークンと して扱わなければならない[MUST]。参照先端末は古い(aged)Dateヘッダー フィールド値を持つトークンを無効と扱うべきである[SHOULD]。 参照先端末は、受け取るリクエストが、トークン内のRefer-Toヘッダーフィー ルドにある参照(reference)にマッチすることを検証すべきである[SHOULD]。 この検証には、少なくとも、そのリクエストメソッドと、指定された端末間 (end-to-end)のヘッダーフィールド値すべてを含めるべきである[SHOULD]。こ のRefer-ToヘッダーフィールドにあるURIは、被参照端末と参照先端末間でリ クエストの再対象になることから、受け取ったリクエストにあるリクエスト URIにマッチしない可能性があるということに注意。 参照先端末は、トークン内のReferred-Byヘッダーフィールドにあるアイデン ティティが、署名証明書(signing certificate)のSubjectAltNameと完全一致 する、ということを検証し、また、また[3]に記載されているようにユーザー へ矛盾を報告すべきである[SHOULD]。 トークンがToヘッダーフィールドを含む場合、参照先端末は、示されているア イデンティティが参照指示端末とマッチすることを検証すべきである [SHOULD]。これを検証する方法のひとつは、トークンのToヘッダーフィールド のアイデンティティと、リクエスト自体を保護するaibを署名する被参照端末 が使用する証明書のsubjectAltNameとを完全一致させることである。このよう なaibを要求するために、[7]で定義される428応答を(まだ存在しなければ)使 用できる。 5. 429 Provide Referror Identityエラー応答 429のクライアントエラー応答コードは、被参照端末が有効なReferred-Byトー クンを提供しなければならない、ということを示すために、参照先端末が使用 する。動作のセクションで議論されるように、被参照端末は、REFERの結果と してNOTIFYで、このエラーコードを参照指示端末へ転送(forward)する。 エラー応答に提案される文字フレーズは、「Provide Referrer Identity(参照 指示端末のアイデンティティを提示せよ)」である。 6. セキュリティの考慮事項 本仕様で定義される仕組みは、参照指示端末から参照先端末に情報を転送 (forward)するために、中継者(被参照端末)に依存する。これは必然的に、被 参照端末を、その情報の盗聴者とし、この仕組みを使用してman-in-the- middle攻撃を開始する最適な立場に置く。 Sparks Standards Track [Page 8] RFC 3892 The SIP Referred-By Mechanism September 2004 SIPプロキシも同様な立場に置かれる。悪意のあるプロキシ実装からSIPメッ セージングを保護することについては[1]で議論されている。プロキシとは対 照的に、被参照端末のエージェントはエンドポイントである。プロキシは通 常、サービスプロバイダによって管理され、監視されている。プロキシによる 悪意のある動作は、気付かれる可能性が高く、エンドポイントによる動作の場 合よりも批判的な反応をもたらすことになる。エンドポイントの動作は、完全 に単一ユーザーの制御下に置くことができる。したがって、サービスプロバイ ダによって運用されているプロキシよりも、被参照端末として動作するエンド ポイントのほうが、悪意を持って動作するのに適している。 本仕様では、参照先端末が被参照端末によるReferred-By情報の操作を検知す ることを可能にするために、S/MIMEに基づく仕組みを使用する。この防御の使 用はオプションである。コミュニティは、この情報の妥当性の信頼性が重要で ないか、あるいは他の手段で確立できるシステムがあることを主張している。 このオプションの仕組みを使用しないことを選択するいかなる実装も、以下の リスクに対する独自の防御手段を提供する必要がある。 o Referred-By情報は、リクエストアドミッションポリシーに影響を与える 可能性が極めて高い。例えば、それはエージェントのユーザーに「この通 話はXによって転送されました。受け入れますか？」プロンプトとともに表 示される可能性がある。悪意のある被参照端末は、変造したReferred-By情 報を提示してポリシーの決定に不当に影響を与えることができる。 これには、参照されたことを最初に不当に主張することも含まれる。(S/ MIME仕組みは、署名で情報を保護し、その署名に使用されているキーを知 ることなしに情報を挿入または改変する被参照端末の能力を妨げる。) o 定義によれば被参照端末は、Referred-By情報の盗聴者である。情報の一部 は機密事項の可能性がある。(S/MIME仕組みは暗号化を可能にする。) o 被参照端末は、それが見たいかなるReferred-By情報でも保存し、将来の関 係ないリクエストにペーストする可能性がある。(S/MIME仕組みは、署名を 使ってタイムスタンプを変換することで古くなったアサーションを検知す ることを可能にし、Refer-Toヘッダーフィールドを署名で保護することで 関係ないリクエストの使用を検知可能にする。) 本仕様の仕組みは、被参照端末が参照対象リクエストからすべて[ALL]の Referred-By情報を削除することを防がない[NOT]。参照先端末はそのような削 除を検知できない。参照対象リクエストからすべてのReferred-By情報を削除 することによって、[5]に記載される普通のSIPリクエストに変わるため、これ によって新たな問題が起こることはない。したがって、被参照端末は、 Referred-By情報を削除することによって参照先端末でロジックを処理するこ とで新たな影響力を得ることはない。 Sparks Standards Track [Page 9] RFC 3892 The SIP Referred-By Mechanism September 2004 参照先端末は、429エラー応答を使用して、悪意ある被参照端末がトークンを (安全ではないアイデンティティReferred-Byヘッダーフィールドに残して)削 除する可能性から自分自身を保護することができる。 本文書の仕組みを使用するアプリケーションは、それの使用によるリスクを軽 減するために、参加者間に既に存在するリレーションシップを利用できる可能 性がある。一部の転送シナリオにおいて、AはBをCにreferするか、あるいはC をBにreferするかの選択肢がある。Bは悪意を持って動作しないというより大 きな自信をAが持てる、既存の信頼関係がA-B間にある場合(例えば、BがAの管 理アシスタント)、BをCにreferすることがより理にかなっている。 この仕組みには3つのエンドポイント間の2つのSIPリクエストが関与する。そ れは、REFERと参照対象リクエストである。これらのメッセージのコンテンツ (Referred-By情報も含む)は、[5]に記述されているセキュリティの考慮と防御 仕組みに従う。 参加者間のプロキシは、Referred-By情報を収集し、それを後々のリクエスト に再挿入するか、敵対的なエンドポイントが利用できるようにしてもよい。 [5]で議論されているエンドツーエンドの機密性を得る能力は、これらのプロ キシに対して重要なReferred-By情報を暴露するリスクを軽減する役に立つ。 被参照端末と参照先端末間のプロキシ(または情報を漏洩する可能性のあるエ ンドポイント)によるそれ以降のリクエスト中での悪用の可能性は、被参照端 末による悪用および悪意のある被参照端末に当てはまる議論で考慮する事項と 同一である。参照指示端末と被参照端末間のプロキシ(または情報を漏洩する 可能性のあるエンドポイント)によるそれ以降のリクエスト中での悪用の可能 性は、[7]でAuthenticated Identity Bodiesの提示のために議論されているも のと似ている。 6.1. Referred-Byトークンでの被参照端末の識別 参照先端末に対し、Referred-Byトークンは、最小限の「このDateヘッダー フィールドで示される時間に、このRefer-Toヘッダーフィールドが示すリクエ ストを送信することが望まれる、このReferred-Byヘッダーフィールドが示す アイデンティティ」をアサートする。このアサートは、誰がリクエストを送 信するよう要求されているについては何も主張しない。これによって、 「Aliceに参照されるすべてのリクエストを受け入れる」というようなポリ シーが可能になるが、「AliceがBobに我々を参照させた、とBobが証明できる 場合にのみ、Bobからのリクエストを受け入れる」ということはできない。そ のため、カット&ペースト攻撃の可能性がある。Malloryが最小限のトークンを 使用して、AliceがCarolに我々を参照させるのが見えると、Malloryは、(組み 込まれたRefer-Toヘッダーで示されているものにマッチしている限りは、)そ のトークンを自分のリクエストをコピーでき、また、それによって、こちらに は、AliceがMalloryに参照させたように見える。[5]に詳細のあるTLSまたはS/ MIMEの仕組みを利用して、AliceがCarolに送信するREFERが盗聴されるのを 防ぐことで、この危険性を最も軽減することができる。 Sparks Standards Track [Page 10] RFC 3892 The SIP Referred-By Mechanism September 2004 トークンごとに、Referred-ByのREFERリクエストからToヘッダーフィールドを 含めることによって、「AliceがBobに我々を参照させた、とBobが証明できる 場合にのみ、Bobからのリクエストを受け入れる」ということが可能になる。 AliceがREFERリクエストをBobへ送信していることをわかっている場合にの み、Aliceは、このヘッダーをトークンに追加する、という制限を受ける。こ れによって、我々も、トークンのAliceの署名を認証することに加え、参照さ れたリクエストを送信したのがBobだということがわかる。Malloryの初期の攻 撃は、このトークンには効果がない。 一方で、Referred-ByトークンにToヘッダーフィールドを含めることは、プラ イバシに関連がある。上記のCarolは、匿名でのコンタクトを望んでいる可能 性がある。Aliceが作成したトークンにCarolのアイデンティティがあれば、こ の望みは絶たれてしまう。Aliceがトークンを暗号化すると、Carolはこの情報 漏洩に気づきもしない。匿名性を望むCarolを保護するには、Carolは自分が検 査(inspect)できないReferred-Byトークンを含むREFERリクエストをすべて拒 否しなければならない。 7. 例 7.1. 基本的なREFER この例は、SIP INVITE URIに対するREFERに適用されるセキュアなReferred-By 仕組みを示す。 本文書で定義された仕組みの実行に関するメッセージについてのみ、詳細を示 す。 参照指示端末 被参照端末 参照先端末 | F1 REFER | | |-------------------------->| | | 202 Accepted | | |<--------------------------| | | NOTIFY | | |<--------------------------| F2 INVITE | | 200 OK |--------------------------->| |-------------------------->| 200 OK | | |<---------------------------| | | ACK | | NOTIFY |--------------------------->| |<--------------------------| | | 200 OK | | |-------------------------->| | | | | Sparks Standards Track [Page 11] RFC 3892 The SIP Referred-By Mechanism September 2004 F1 REFER sip:referee@referee.example SIP/2.0 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842 To: sip:referee@referee.example From: sip:referrer@referrer.example;tag=39092342 Call-ID: 2203900ef0299349d9209f023a CSeq: 1239930 REFER Max-Forwards: 70 Contact: Refer-To: Referred-By: ;cid="20398823.2UWQFN309shb3@referrer.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (適切な値) --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=dragons39 Content-ID: <20398823.2UWQFN309shb3@referrer.example> Content-Length: (適切な値) --dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: Referred-By: ;cid="20398823.2UWQFN309shb3@referrer.example" --dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (適切な署名がここに入る) --dragons39-- --unique-boundary-1-- F2 INVITE sip:refertarget@target.example SIP/2.0 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac To: From: ;tag=2909034023 Call-ID: fe9023940-a3465@referee.example CSeq: 889823409 INVITE Max-Forwards: 70 Sparks Standards Track [Page 12] RFC 3892 The SIP Referred-By Mechanism September 2004 Contact: Referred-By: ;cid="20398823.2UWQFN309shb3@referrer.example" Content-Type: multipart/mixed; boundary=my-boundary-9 Content-Length: (適切な値) --my-boundary-9 Content-Type: application/sdp Content-Length: (適切な値) v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --my-boundary-9 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=dragons39 Content-ID: <20398823.2UWQFN309shb3@referrer.example> Content-Length: (適切な値) --dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: Referred-By: ;cid="20398823.2UWQFN309shb3@referrer.example" --dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (適切な署名がここに入る) --dragons39-- --my-boundary-9-- Sparks Standards Track [Page 13] RFC 3892 The SIP Referred-By Mechanism September 2004 7.2. 保護されていないREFER このフロー例は、セクション7.1と同じである。ここでは、参照指示端末が Referred-Byトークンを含めないことを選択し、参照先端末はReferred-Byトー クンなしの参照されたリクエストを受け入れる意思がある。 F1 REFER sip:referee@referee.example SIP/2.0 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842 To: From: ;tag=39092342 Call-ID: 2203900ef0299349d9209f023a CSeq: 1239930 REFER Max-Forwards: 70 Contact: Refer-To: Referred-By: Content-Length: 0 F2 INVITE sip:refertarget@target.example SIP/2.0 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac To: From: ;tag=2909034023 Call-ID: fe9023940-a3465@referee.example CSeq: 889823409 INVITE Max-Forwards: 70 Contact: Referred-By: Content-Type: application/sdp Content-Length: (適切な値) v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 7.3. 参照指示端末のアイデンティティの要求 セクション7.2の例とは対照的に、参照先端末は参照対象リクエストを受け入 れるためにReferred-Byトークンを要求する。参照指示端末は暗号化された トークンを提示することを選択する(アスタリスクに囲まれたブロックは暗号 化されたコンテンツを表すことに注意すること)。F1およびF2はセクション8.2 で詳述されているメッセージと同一である。 Sparks Standards Track [Page 14] RFC 3892 The SIP Referred-By Mechanism September 2004 参照指示端末 被参照端末 参照先端末 | F1 REFER | | |-------------------------->| | | 202 Accepted | | |<--------------------------| | | NOTIFY | | |<--------------------------| F2 INVITE | | 200 OK |--------------------------->| |-------------------------->| F3 429 Provide Referrer Identity | |<---------------------------| | | ACK | | F4 NOTIFY |--------------------------->| |<--------------------------| | | 200 OK | | |-------------------------->| | | F5 REFER | | |-------------------------->| | | 202 Accepted | | |<--------------------------| | | NOTIFY | | |<--------------------------| F6 INVITE | | 200 OK |--------------------------->| |-------------------------->| 200 OK | | |<---------------------------| | | ACK | | NOTIFY |--------------------------->| |<--------------------------| | | 200 OK | | |-------------------------->| | | | | F3 SIP/2.0 429 Provide Referrer Identity Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac To: ;tag=392093422302334 From: ;tag=2909034023 Call-ID: fe9023940-a3465@referee.example CSeq: 889823409 INVITE Content-Length: 0 Sparks Standards Track [Page 15] RFC 3892 The SIP Referred-By Mechanism September 2004 F4 NOTIFY sip:referrer@referrer.example SIP/2.0 Via: SIP/2.0/UDP referee.example;branch=z9hG4bK2934209da390 To: ;tag=39092342 From: ;tag=199949923 Call-ID: 2203900ef0299349d9209f023a CSeq: 3920390 NOTIFY Event: refer;id=1239930 Subscription-State: terminated Content-Type: message/sipfrag Content-Length: (適切な値) SIP/2.0 429 Provide Referrer Identity F5 REFER sip:referee@referee.example SIP/2.0 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK98823423 To: From: ;tag=39092342 Call-ID: 2203900ef0299349d9209f023a CSeq: 1239931 REFER Max-Forwards: 70 Contact: Refer-To: Referred-By: ;cid="20342EFXEI.390sdefn2@referrer.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (適切な値) --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 Content-ID: <20342EFXEI.390sdefn2@referrer.example> Content-Length: (適切な値) --boundary42 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m; handling=required Content-Length: (適切な値) Sparks Standards Track [Page 16] RFC 3892 The SIP Referred-By Mechanism September 2004 *********************************************************** * Content-Type: message/sipfrag * * Content-Disposition: aib; handling=optional * * * * Date: Thu, 21 Feb 2002 13:02:03 GMT * * Refer-To: * * Referred-By: * * ;cid="20342EFXEI.390sdefn2@referrer.example" * *********************************************************** --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (適切な署名) --boundary42-- F6 INVITE sip:refertarget@target.example SIP/2.0 Via: SIP/2.0/UDP referee.example;branch=z9hG4bK3920390423 To: From: ;tag=1342093482342 Call-ID: 23499234-9239842993@referee.example CSeq: 19309423 INVITE Max-Forwards: 70 Referred-By: ;cid="20342EFXEI.390sdefn2@referrer.example" Contact: Content-Type: multipart/mixed; boundary=my-boundary-9 Content-Length: (適切な値) --my-boundary-9 Content-Type: application/sdp Content-Length: (適切な値) v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Sparks Standards Track [Page 17] RFC 3892 The SIP Referred-By Mechanism September 2004 --my-boundary-9 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 Content-ID: <20342EFXEI.390sdefn2@referrer.example> Content-Length: (適切な値) --boundary42 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m; handling=required Content-Length: (適切な値) *********************************************************** * Content-Type: message/sipfrag * * Content-Disposition: aib; handling=optional * * * * Date: Thu, 21 Feb 2002 13:02:03 GMT * * Refer-To: * * Referred-By: * * ;cid="20342EFXEI.390sdefn2@referrer.example" * *********************************************************** --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (適切な署名) --boundary42-- --my-boundary-9-- 7.4. ネストされたREFER Refer-To URIは、REFERメソッドを示すSIP URIでもよい。CがDにINVITEを送信 するために参照するCへのREFERリクエストをBが送信するために、AがBを参照 するために使用する以下のURIを考えてみる。 Aは、BとCを通ってDに渡されるReferred-Byトークンを提供するということに 注意すること。特に、BはCに独自のReferred-Byトークンを提供しない。ま た、Aは、Cで引き起こされたリクエスト(INVITE)ではなく、Bで引き起こされ たリクエスト(REFER)の結果を通知されるということにも注意すること。 Refer-To: "> この参照の結果、以下のようなフローになる。 A B C D | F1 REFER | | | |------------------>| | | | 202 Accepted | | | |<------------------| | | | NOTIFY | | | |<------------------| F2 REFER | | | 200 OK |------------------>| | |------------------>| 202 Accepted | | | F3 NOTIFY |<------------------| | |<------------------| NOTIFY | | | 200 OK |<------------------| F4 INVITE | |------------------>| 200 OK |------------------>| | |------------------>| 200 OK | | | NOTIFY |<------------------| | |<------------------| ACK | | | 200 OK |------------------>| | |------------------>| | | | | | F1 REFER sip:B SIP/2.0 Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232 To: From: ;tag=23490234 Call-ID: 2304098023@A.example CSeq: 2342093 REFER Max-Forwards: 70 Contact: Refer-To: .example"> Referred-By: ; cid="23094202342.10123091233@A.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (適切な値) --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=dragons39 Content-ID: <23094202342.10123091233@A.example> Content-Length: (適切な値) --dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional Sparks Standards Track [Page 19] RFC 3892 The SIP Referred-By Mechanism September 2004 Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: "> Referred-By: ; cid="23094202342.10123091233@A.example" --dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (適切な署名がここに入る) --dragons39-- --unique-boundary-1-- F2 REFER sip:C.example SIP/2.0 Via: SIP/2.0/UDP B.example;branch=z9hG4bK00239842 To: From: ;tag=2934u23 Call-ID: 203942834@B.example CSeq: 8321039 REFER Max-Forwards: 70 Contact: Refer-To: Referred-By: ; cid="23094202342.10123091233@A.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (適切な値) --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=dragons39 Content-ID: <23094202342.10123091233@A.example> Content-Length: (適切な値) --dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: "> Referred-By: ;cid="23094202342.1012309123@A.example" Sparks Standards Track [Page 20] RFC 3892 The SIP Referred-By Mechanism September 2004 --dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (適切な署名がここに入る) --dragons39-- --unique-boundary-1-- F3 NOTIFY sip:A.example SIP/2.0 Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232 To: ;tag=23490234 From: ;tag=5923020 Call-ID: 2304098023@A.example CSeq: 29420342 NOTIFY Event: refer;id=2342093 Subscription-State: terminated Max-Forwards: 70 Contact: Content-Type: message/sipfrag Content-Length: (適切な値) SIP/2.0 202 Accepted F4 INVITE sip:D.example SIP/2.0 Via: SIP/2.0/UDP C.example;branch=z9hG4bK29348234 To: From: ;tag=023942334 Call-ID: 23489020352@C.example CSeq: 1230934 INVITE Max-Forwards: 70 Contact: Referred-By: ; cid="23094202342.10123091233@A.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (適切な値) --unique-boundary-1 Content-Type: application/sdp Content-Length: (適切な値) Sparks Standards Track [Page 21] RFC 3892 The SIP Referred-By Mechanism September 2004 v=0 o=C 2890844526 2890844526 IN IP4 C.example s=Session SDP c=IN IP4 C.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=dragons39 Content-ID: <23094202342.10123091233@A.example> Content-Length: (適切な値) --dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: "> Referred-By: ; cid="23094202342.1012309123@A.example" --dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (適切な署名がここに入る) --dragons39-- --unique-boundary-1-- Sparks Standards Track [Page 22] RFC 3892 The SIP Referred-By Mechanism September 2004 8. IANA条項 本文書は新規SIPヘッダーフィールド名とそのコンパクトフォーム(それぞれReferred-By、b)を定義する。また、新規SIPクライアントエラー応答コード(429)も定義する。 http:///www.iana.org/assignments/sip-parametersに以下の変更が反映される。 以下の行がヘッダーフィールドセクションに追加される(Referred-Byに対して既に存在するすべての行を置き換える)。 ヘッダー名 短縮形 参考文献 Referred-By b [RFC3892] 以下の行が、 Request Failure 4xxの見出しの下にある応答コードセクションに追加される。 429 Provide Referrer Identity [RFC3892] 9. 寄稿者 Rohan MahyはRFC 2822のmsg-idを抜粋し、本文書のsip-clean-msg-idの定義 とした。 10. 参考文献 10.1. 規範となる参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [3] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004. [4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. [5] 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. Sparks Standards Track [Page 23] RFC 3892 The SIP Referred-By Mechanism September 2004 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 10.2. Informative References [7] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, March 2003. [8] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", Work in Progress, February 2003. [9] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 11. 著者の連絡先 Robert J. Sparks Xten 5100 Tennyson Parkway Suite 1000 Plano, TX 75024 EMail: RjS@xten.com Sparks Standards Track [Page 24] RFC 3892 The SIP Referred-By Mechanism September 2004 12. 完全な著作権表示 Copyright (C) The Internet Society (2004). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78に 記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿 者が代表となる組織、または寄稿者を後援する組織(存在する場合)、インター ネット協会およびIETFは、この情報がいかなる権利も侵害していないという保 証、商用利用および特定目的への適合性への保証を含め、また、これらだけに 限らずすべての保証について、明示的もしくは暗黙的の保証は行われない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知的 所有権または他の諸権利の有効性または範囲に関して、またはこのような権利 下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解 を持たない。このような権利を確認する独自の取り組みを行ったことも示さな い。RFC文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記 載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者ま たはユーザーが一般的なライセンスまたは許可の取得を試みた結果について は、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能であ る。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性があ る、すべての著作権、特許または特許アプリケーション、あるいは他の所有権 について、すべての関連団体に対して配慮するよう依頼している。情報につい ては、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供されて いる。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Sparks Standards Track [Page 25]