Network Working Group E. Burger, Ed. Request for Comments: 4483 Cantata Technolgy, Inc. Category: Standards Track May 2006 セッション開始プロトコル(SIP)メッセージにおける コンテンツ間接化のメカニズム A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準ト ラックプロトコルを規定するものであり、改善のための議論や提案を依頼す るものである。標準化の段階や、プロトコルの位置付けについては、最新版 の"Internet Official Protocol Standards" (STD 1)を参照されたい。この 文書の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2006). 概要 本文書は、URL MIME External-Body Access-Typeの拡張を定義する。これ は、セッション開始プロトコル(Session Initiation Protocol/SIP)のコン テンツ間接化(content indirection)要件を満たす拡張である。この拡張の 目的は、SIPメッセージのMIME部をURI経由で間接的に参照できるようにする ことである。 目次 1. はじめに ...................................................... 2 2. 用語 .......................................................... 3 3. 使用例 ........................................................ 3 3.1. プレゼンスの通知 ........................................ 4 3.2. 文書の共有 .............................................. 4 4. 要件 .......................................................... 5 5. コンテンツ間接化問題に対するRFC 2017の適用 .................... 6 5.1. コンテンツ間接化のサポートを指定する .................... 6 5.2. HTTP URIの必須サポート .................................. 7 5.3. コンテンツ間接化を拒否する .............................. 7 5.4. URI経由でコンテンツの場所を指定する ...................... 7 5.5. 間接的なコンテンツをオプションを印を付ける .............. 7 5.6. URIのバージョン情報を指定する ............................ 8 5.7. URIの有効期間を指定する .................................. 8 5.8. 間接的なコンテンツのタイプを指定する .................... 8 5.9. 間接的なコンテンツのサイズを指定する .................... 9 5.10. 間接的なコンテンツの目的を指定する ...................... 9 5.11. コンテンツ間接化に複数のURIを指定する ................. 10 Burger Standards Track [Page 1] RFC 4483 Content Indirection in SIP Messages May 2006 5.12. 間接的コンテンツのハッシュ値を指定する ................. 10 5.13. 間接的コンテンツについて追加コメントを 指定する ............................................... 11 5.14. Call-Info、Error-Info、Alert-Infoの各ヘッダー との関係 ............................................... 11 6. 例 ........................................................... 12 6.1. 単独のコンテンツ間接化 ................................. 12 6.2. マルチパートMIMEとコンテンツ間接化 ..................... 12 7. セキュリティの考慮事項 ....................................... 13 8. 寄稿 ......................................................... 15 9. 謝辞 ......................................................... 15 10. 参考文献 ..................................................... 15 10.1. 規範となる参考文献 ..................................... 15 10.2. 有益な参考文献 ......................................... 16 1. はじめに セッション開始プロトコル(Session Initiation Protocol/SIP) [9]の目的 は、1人または複数人の参加者とのセッションを作成、修正、または終了す ることである。 SIPメッセージの構文は、HTTPと同様に、開始行、1つまたは複数のヘッ ダー、およびオプションのボディで構成される。HTTPと異なる点は、SIPが 汎用データのトランスポートプロトコルとして設計されていないことであ る。 場合によってはSIPメッセージボディのコンテンツを間接的に指定する方が 望ましいという理由は多数ある。携帯電話など、帯域幅が制限されたアプ リケーションの場合、間接化は、メタデータを含む(間接的な)コンテンツに 注釈を付ける手段として機能する。また、間接化は、リソースが制限された リンク上のコンテンツを取得するかどうかを、受信側が判断するときに使用 することができる。 また、送信されるコンテンツサイズのために仲介のシグナリングプロキシに 負担がかかり、結果として不必要なネットワーク待機時間が増加する可能性 もある。時間の影響を受けやすいSIPアプリケーションの場合、この問題は 受け入れられない可能性がある。間接コンテンツは、SIPシグナリングネッ トワークからコンテンツを取り出し、場合によっては別のデータ送信チャネ ルに移行することで、この問題を改善することができる。 伝送する必要があるセッション関連データ(ボディ)が、エンドポイントまた はユーザーエージェントに直接格納されていないシナリオもある。このよう なシナリオの場合、SIPメッセージに、目的のコンテンツに対する間接参照 を含めることができるメカニズムを用意することが望ましい。この場合、受 信側パーティは、この間接参照を使用して、SIP以外の送信チャネル(HTTP、 FTP、LDAPなど)経由でコンテンツを取得する。 コンテンツ間接化の目的は、純粋にSIP MIMEボディ部に代替のトランスポー トメカニズムを提供することである。トランスポートメカニズムを例外と Burger Standards Track [Page 2] RFC 4483 Content Indirection in SIP Messages May 2006 して、間接のボディ部はインラインのボディ部と同一であり、同様に扱うべ きである。 コンテンツ間接化問題を解決するときに、従来はtext/uri-list [6] MIMEタ イプを利用していた。これは単純な点が魅力的だが(行末マーカーで区切ら れたURI一覧)、SIPで、より汎用的なコンテンツ間接化メカニズムの要件の 多くを満たしていなかった。特に欠けている点は、1つのURI当たりのベース に対して、多様な属性を指定する機能である。 このような属性には、バージョン情報、被参照コンテンツのMIMEタイプなど が含まれる可能性がある。 RFC 2017は、text/uri-list MIMEタイプを置き換える強力な候補を定義して いる。RFC 2017 [1]は、元々RFC 2046 [3]で定義されていた message/external-body MIMEタイプの拡張を定義している。 RFC 2017の拡張は、RFC 2046で元々定義されていたFTPなどのプロトコル固 有のパラメータではなく、汎用的なURIでコンテンツの場所を指定すること を許容している。RFC 2017にはSIPのコンテンツ間接化メカニズムに必要な 機能のほとんどが備わっているが、RFC 2017だけでは完全なソリューション にならない。本文書は、コンテンツ間接化用にまとめられた要件を満たすた めに、必要なRFC 2017の使用方法を規定する。 目的のコンテンツを間接的に参照するURIに適用すること、またはコンテン ツ自体に適用することと要件を分類することができる。可能な場合、既存 のMIMEパラメータとエンティティヘッダーを使用してこれらの要件を満たす ことができる。MIME (コンテンツタイプ)パラメータはURIを記述するために 望ましい方法だが、エンティティヘッダーは(間接的な)コンテンツを記述す るために望ましい方法である。このようなエンティティヘッダーとMIMEパ ラメータのほとんどの説明については、RFC 2045 [2]を参照。 2. 用語 RFC 2119 [5]は、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」について定義している。 3. 使用例 コンテンツ間接化メカニズムを使用する例はいくつかある。ここに記載する のは単に例であり、このメカニズムの範囲や適用可能性を制限する意図は ない。 Burger Standards Track [Page 3] RFC 4483 Content Indirection in SIP Messages May 2006 3.1. プレゼンスの通知 プレゼンスドキュメントで伝送される情報は、特に複数のエンドポイントか ら集約した情報を伝送している場合、SIP (NOTIFY)リクエストの推奨サイズ を超過する可能性がある。このような場合、プレゼンスドキュメントに対す る間接的なポインタを指定したNOTIFYリクエストを送信するのが望ましい。 こうすると、ドキュメントをたとえばHTTPによって取得することができる。 ウォッチャー プレゼンスサーバー | | | SUBSCRIBE | |-------------------------->| | 200 OK | |<--------------------------| | | | NOTIFY | |<--------------------------| | 200 OK | |-------------------------->| | | | NOTIFY (w/URI) | |<--------------------------| | 200 | |-------------------------->| | | | HTTP GET | |-------------------------->| | | | application/cpim-pidf+xml | |<--------------------------| | | この例で、プレゼンスサーバーは、プレゼンスサーバー上にあるプレゼンス ドキュメントを示すHTTP URIを返す。このドキュメントは、ウォッチャー がHTTP GETを使用して取得することができる。 3.2. 文書の共有 インスタントメッセージの会話中に、役に立つサービスの1つは文書の共有 である。この場合、一方のパーティは、相手側パーティに表示されることを 意図したドキュメントを示す、間接的なポインタが指定されたIM (MESSAGE リクエスト)を送信する。このような文書をMESSAGEリクエストで直接伝送す ることは、シグナリングチャネルの適切な使用方法ではない。 さらに、共有される文書は、発信元パーティのサーバーとは完全に関係がな いサーバーに格納されている。 Burger Standards Track [Page 4] RFC 4483 Content Indirection in SIP Messages May 2006 UAC UAS Webサーバー (ユーザー (ユーザー | エージェント エージェント | クライアント) サーバー) | | | | | MESSAGE w/URI | | |------------------->| | | 200 | | |<-------------------| | | | | | | HTTP GET | | |--------------->| | | image/jpeg | | |<---------------| | | | この例で、ユーザーのUACは、自分のWebサーバーに格納したJPEG画像を、IM の会話相手であるユーザーのUASとの間で交換しようとしている。彼女は、 IM会話中にインラインでJPEGを提供しようとしている。MESSAGEリクエスト の受信者は、Webサーバーに対してHTTP GETリクエストを実行し、JPEG画像 を取得する。 4. 要件 o コンテンツの場所をURI経由で指定することが可能でなければならな い[MUST]。 このようなURIはRFC 2396 [7]に準拠しなければならない[MUST]。 o 間接的コンテンツの長さを指定することが可能でなければならな い[MUST]。 o 間接的コンテンツのタイプを指定することが可能でなければならな い[MUST]。 o 各URIの特性を独立して指定することが可能でなければならない[MUST]。 o 各URIにラベルを付け、そのURIで参照されるコンテンツが変更されたか どうか、および変更のタイミングを識別することが可能でなければなら ない[MUST]。このメカニズムを持つアプリケーションは、複数回、同じ URIを送信することができる。この要件の目的は、受信側パーティが、コ ンテンツを取得することなく、そのURIで参照されるコンテンツが変更さ れたかどうかを判断できるようにすることである。URIにラベルを付ける 方法の例として、シーケンス番号、タイムスタンプ、バージョン番号が ある。HTTPと併用する場合、RFC 2068 [4]に定義されているエンティ ティタグ(ETAG)メカニズムが適している可能性がある。ラベルを付ける 対象はURI自体ではなくURIが参照するコンテンツなので、そのラベルは 実質的にコンテンツ自体の「メタデータ」であることに注意が必要で ある。 Burger Standards Track [Page 5] RFC 4483 Content Indirection in SIP Messages May 2006 o 特定のURIが有効な期間を指定することが可能でなければならない [MUST]。これは、コンテンツ自体の有効期限と同じの場合もあるし異な る場合もある。 o UACとUASは、このコンテンツ間接化メカニズムのサポートを示すことが 可能でなければならない[MUST]。一方のパーティがコンテンツ間接化を サポートできない場合の代替メカニズムを指定すべきである[SHOULD]。 o UACとUASは、コンテンツ間接化メカニズムを使用する場合、間接的コン テンツのタイプをネゴシエートすることが可能でなければならない [MUST]。 o UACとUASは、コンテンツ間接化メカニズムで使用する任意のURIスキーム のサポートをネゴシエートすることが可能でなければならない[MUST]。 これは、コンテンツタイプをネゴシエートする機能とは別である。 o リモートパーティがURIを受信するときに、URIの完全性と機密性を確保 できるべきである[SHOULD]。 o ユーザーの操作なしで、コンテンツ間接化を処理できなければならな い[MUST]。 o 任意のSIPメッセージでコンテンツの間接的な移動を許容しなければなら ない[MUST]。許容しなければ、コンテンツはボディとして伝送される。 5. コンテンツ間接化問題に対するRFC 2017の適用 以下の文章では、コンテンツ間接化の要件に対してRFC 2017を適用すること について説明している。 5.1. コンテンツ間接化のサポートを指定する UAC/UASは、message/external-body MIMEタイプをAcceptヘッダーフィール ドに含めることで、コンテンツ間接化のサポートを示す。UAC/UASは、Accept ヘッダーフィールドに追加の値を指定して、受け入れる意志があるコンテン ツタイプを、直接またはコンテンツ間接化によって指定してもよい[MAY]。 コンテンツ間接化をサポートするユーザーエージェントは、application/sdp MIMEタイプのコンテンツ間接化もサポートしなければならない[MUST]。 例: Accept: message/external-body, image/*, application/sdp Burger Standards Track [Page 6] RFC 4483 Content Indirection in SIP Messages May 2006 5.2. HTTP URIの必須サポート このコンテンツ間接化メカニズムを使用するアプリケーションは、HTTP URI スキームをサポートしなければならない[MUST]。追加のURIスキームを使用 してもよいが[MAY]、UAC/UASは、コンテンツ間接化のサポートを公表する場 合に、間接的コンテンツに関するHTTP URIの受信をサポートしなければなら ない[MUST]。 UASは、UACのセッション確立リクエスト(INVITE、SUBSCRIBEなど)に対する UAS応答のContactヘッダーフィールドのスキームパラメータで、代替のアク セススキームを公表してもよい[MAY](RFC 3840 [11]参照)。 5.3. コンテンツ間接化を拒否する UASがコンテンツ間接化のペイロードを含むSIPリクエストを受信し、そのよ うなコンテンツタイプをそのUASがサポートできないかサポートしたくない 場合、SIP [9]のセクション21.4.13に定義されているように、415 Unsupported Media Type応答でリクエストを拒否しなければならない [MUST]。特に、UACは、この応答のAcceptヘッダーフィールドに message/external-body MIME タイプがないことに注意する必要がある。こ れは、UASがコンテンツ間接化をサポートしていないことを示す。また、要 求したコメントの特定のMIMEタイプがない場合、UASがそのメディアタイプ をサポートしていないことを示す。 5.4. URI経由でコンテンツの場所を指定する 間接的コンテンツのURIは、message/external-body MIMEタイプの「URI」 パラメータに指定する。access-typeパラメータは、外部コンテンツがURIか ら参照されていることを示す。HTTP URIの指定は、RFC 2396 [7]に準拠しな ければならない[MUST]。 例: Content-Type: message/external-body; access-type="URL"; URL="http://www.example.com/the-indirect-content" 5.5. 間接的コンテンツをオプションを印を付ける 取得エラーまたは変換エラーが発生した場合に、通信の状況にはあまり影響 がないコンテンツもある。コンテンツ間接化メカニズムは、RFC 3459 [10] で説明されているCritical-Contentメカニズムを使用している。特に、UAS がオプションのボディ部を取得または表示できない場合、サーバーはUACに エラーを返してはならない[MUST NOT]。 Burger Standards Track [Page 7] RFC 4483 Content Indirection in SIP Messages May 2006 5.6. URIのバージョン情報を指定する URIから間接的に参照されるコンテンツが変更されたかどうかを判断する には、Content-IDエンティティヘッダーを使用する。このヘッダーの構文 は、RFC 2045 [2]で定義されている。URIから参照される基礎となるコンテ ンツに変更があると、そのURIに関連付けられたContent-IDも変更されなけ ればならない[MUST]。同じコンテンツを参照するURIを含む複数のSIPメッ セージは、同じContent-IDを再利用すべきである[SHOULD]。これによって、 受信側はそのコンテンツをキャッシュし、不要な取得を回避することがで きる。Content-IDはグローバルに一意であることを目的としている。また、 Content-IDはSIPダイアログの中で一時的に一意にすべきである[SHOULD]。 例: Content-ID: <4232423424@www.example.com> 5.7. URIの有効期間を指定する Content-Typeヘッダーが提供するURIは、永続的にアクセス可能にしたり、 有効にしたりする必要はない。URIの提供者は、そのURIが有効でアクセス可 能な期間を指定しなければならない[MUST]。これは、Content-Typeの 「EXPIRATION」パラメータで実現する。この有効期限パラメータの形式は、 RFC 1123 [12]のdate-time値である。SIPのDateヘッダーと整合性があるGMT 時間のみを使用するこのアプリケーションでは、さらに制限される。これは 必須パラメータである。date-time値は、数分から数日、さらには数年の範 囲にまでなる可能性があることに注意。 例: Content-Type: message/external-body; expiration="Mon, 24 June 2002 09:00:00 GMT" 5.8. 間接的コンテンツのタイプを指定する コンテンツタイプのネゴシエーションのために既存のSIPメカニズムをサ ポートするには、Content-Typeエンティティヘッダーをエンティティ(ペイ ロード)自体に提示すべきである[SHOULD]。URIのプロトコル(スキーム)が独 自のコンテンツネゴシエーションメカニズム(HTTPなど)をサポートする場 合、このヘッダーは省略することができる。ただし、受信側がURIスキーム の基礎となるプロトコルを使用して適切なMIMEタイプをネゴシエートでき ず、受信側パーティがコンテンツ間接化を拒否した場合に送信側は備えなけ ればならない[MUST]。 Burger Standards Track [Page 8] RFC 4483 Content Indirection in SIP Messages May 2006 例: Content-Type: message/external-body; access-type="URL"; expiration="Mon, 24 June 2002 09:00:00 GMT"; URL="http://www.example.com/the-indirect-content" Content-Type: application/sdp Content-Disposition: session 5.9. 間接的コンテンツのサイズを指定する 前もってわかっている場合、間接的コンテンツのサイズ(バイト単位)は Content-Typeヘッダーのsizeパラメータで指定すべきである[SHOULD]。 これはRFC 2017の拡張だが、RFC 2049でmessage/external-body MIMEタイプ 用に定義されている他のアクセスタイプとも整合性がとれる。 コンテンツサイズは、受信側パーティがコンテンツを取得するかどうかにつ いて判断するときに有効である。直接指定されたコンテンツと同様に、コン テンツサイズが大きすぎる場合、UASは513エラー応答を返すことができる。 sizeはオプションのパラメータである。 例: Content-Type: message/external-body; access-type="URL"; expiration="Mon, 24 June 2002 09:00:00 GMT"; URL="http://www.example.com/the-indirect-content"; size=4123 5.10. 間接的コンテンツの目的を指定する Content-Dispositionエンティティヘッダーは、すべての間接的コンテンツ で提示されなければならない[MUST]。 例: Content-Type: message/external-body; access-type="URL"; expiration="Mon, 24 June 2002 09:00:00 GMT"; URL="http://www.example.com/the-indirect-content" Content-Type: image/jpeg Content-Disposition: render Burger Standards Track [Page 9] RFC 4483 Content Indirection in SIP Messages May 2006 5.11. コンテンツ間接化に複数のURIを指定する コンテンツ間接化のために複数のURIを送信する必要がある場合、適切なマ ルチパートMIMEタイプ[3]を使用すべきである。各URIは単一のエンティティ に含まれなければならない[MUST]。間接的コンテンツは、直接指定されたコ ンテンツと併用することができる。これは、multipart/alternative MIMEタ イプには特に有効である。 注意: 本仕様は、多様なマルチパートの特性(特にRFC 2387 [13]で説明され ているmultipart/related)の意味を変更しない。 例: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=boundary42 --boundary42 Content-Type: text/plain; charset=us-ascii The company announcement for June, 2002 follows: --boundary42 Content-Type: message/external-body; access-type="URL"; expiration="Mon, 24 June 2002 09:00:00 GMT"; URL="http://www.example.com/announcements/07242002"; size=4123 Content-Type: text/html Content-Disposition: render --boundary42-- 5.12. 間接的コンテンツのハッシュ値を指定する 送信者が特定のコンテンツが間接化によって参照されていることを認識し、 送信者が意図した内容からコンテンツが変わっていないことを受信者が検証 できることを送信者が望んでいる場合、送信者はコンテンツのSHA-1 [8]の ハッシュ値を含める。ハッシュ値を含める場合、MIME構文[3]を拡張してコ ンテンツタイプ「message/ external-body」(この値はハッシュの16進エン コーディング)の「hash」パラメータを含めることで、ハッシュ値はエン コードされる。 Burger Standards Track [Page 10] RFC 4483 Content Indirection in SIP Messages May 2006 例: Content-Type: message/external-body; access-type="URL"; expiration="Mon, 24 June 2002 09:00:00 GMT"; URL="http://www.example.com/the-indirect-content.au"; size=52723; hash=10AB568E91245681AC1B Content-Disposition: render 5.13. 間接的コンテンツについて追加コメントを指定する Content-Descriptionエンティティヘッダーを使用して、オプションの自由 形式テキストを間接的コンテンツのコメントに指定してもよい[MAY]。この テキストはエンドユーザーに表示してもよいが[MAY]、他の要素がボディの 特性を判断するときに使用してはならない[MUST NOT]。 例: Content-Type: message/external-body; access-type="URL"; expiration="Mon, 24 June 2002 09:00:00 GMT"; URL="http://www.example.com/the-indirect-content"; size=52723 Content-Description: Multicast gaming session Content-Disposition: render 5.14. Call-Info、Error-Info、Alert-Infoの各ヘッダーとの関係 SIP [9]は、セッションに関する追加情報(特にエラー応答または警告)を指 定する3つのヘッダーを定義している。これら3つのヘッダーはいずれも、UAC またはUASが追加情報をURIで示すことを許容している。これらは、コンテン ツ間接化の形式と考えることができる。本文書で定義されるコンテンツ間接 化メカニズムは、これらのヘッダーを置き換えるためのものではない。そう ではなく、SIPに定義されているヘッダーは、適用可能な場合、このメカニ ズムよりも優先して使用されなければならない[MUST]。というのも、これら のヘッダーはセマンティクスが定義済みのためである。 Burger Standards Track [Page 11] RFC 4483 Content Indirection in SIP Messages May 2006 6. 例 6.1. 単独のコンテンツ間接化 INVITE sip:boromir@example.com SIP/2.0 From: ;tag=347242 To: Call-ID: 3573853342923422@example.net CSeq: 2131 INVITE Accept: message/external-body application/sdp Content-Type: message/external-body; ACCESS-TYPE=URL; URL="http://www.example.net/party/06/2002/announcement"; EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT"; size=231 Content-Length: 105 Content-Type: application/sdp Content-Disposition: session Content-ID: <4e5562cd1214427d@example.net> 6.2. マルチパートMIMEとコンテンツ間接化 MESSAGE sip:boromir@example.com SIP/2.0 From: ;tag=34589882 To: Call-ID: 9242892442211117@example.net CSeq: 388 MESSAGE Accept: message/external-body, text/html, text/plain, image/*, text/x-emoticon MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=zz993453 --zz993453 Content-Type: message/external-body; access-type="URL"; expiration="Mon, 24 June 2002 09:00:00 GMT"; URL="http://www.example.net/company_picnic/image1.png"; size=234422 Content-Type: image/png Content-ID: <9535035333@example.net> Content-Disposition: render Content-Description: Kevin getting dunked in the wading pool --zz993453 Burger Standards Track [Page 12] RFC 4483 Content Indirection in SIP Messages May 2006 Content-Type: message/external-body; access-type="URL"; expiration="Mon, 24 June 2002 09:00:00 GMT"; URL="http://www.example.net/company_picnic/image2.png"; size=233811 Content-Type: image/png Content-ID: <1134299224244@example.net> Content-Disposition: render Content-Description: Peter on his tricycle --zz993453-- 7. セキュリティの考慮事項 どのようなコンテンツ間接化メカニズムでも、新規のセキュリティ問題を引 き起こす。本質的に、コンテンツ間接化には追加の処理手順と情報の送信が 必要である。コンテンツ間接化メカニズムには不正使用の可能性が多数あ る。 o コンテンツ間接化によって、イニシエータは、セキュリティが低い、ま たはコンテンツ送信に対する脆弱性が知られている代替プロトコルを選 択する可能性がある(たとえば、受信者にHTTPリクエストを発行し、結果 として基本認証チャレンジが行われる場合)。 o コンテンツ間接化によって、イニシエータは、DoS攻撃の手段を与える可 能性がある情報の送信やコンテンツの処理(たとえば、すべての間接的コ ンテンツ/について2接続を使用するアクティブなFTP URL)に対して、追 加リソースを使用するように受信者へ依頼できるようになる。 o コンテンツ間接化は、間接的コンテンツのURLが受信者の内部リソースを 指す偽のURL である形式のポートスキャン攻撃に使用される可能性が ある。コンテンツ間接化リクエストへの応答によって、内部リソースに ついて開いている(また脆弱な)ポートに関する情報がわかる可能性が ある。 o コンテンツ間接化のURLによって、内部ユーザー名や場合によっては地理 的位置情報などイニシエータに関する機密情報が公開される可能性が ある。 幸運なことに、受信する間接的コンテンツURIと送信する間接的コンテンツ URIの両方を慎重に審査することで、このような潜在的脅威はいずれも緩和 することができる。間接的コンテンツURIの完全性と機密性の保護によって、 新規の攻撃が回避される可能性がある。 機密性、完全性、認証について、このコンテンツ間接化メカニズムはRFC 3261に概説されているセキュリティメカニズムに依存している。特に、RFC Burger Standards Track [Page 13] RFC 4483 Content Indirection in SIP Messages May 2006 3261のセクション23に定義されているように、S/MIMEの使用によって、間接 的コンテンツURIと関連パラメータの完全性、保護、および機密性を確保し ている。 間接的コンテンツの送信をセキュリティで保護することは、この送信に使用 される基礎のプロトコルの責任である。HTTPを使用する場合、このコンテン ツ間接化方法を実装するアプリケーションは、コンテンツの安全な送信のた めにHTTPS URIスキームをサポートすべきである[SHOULD]。また、starttls を使用してTLSへの接続のアップグレードをサポートしなければならな い[MUST]。SIPリクエストで間接的コンテンツを承認した後に、完全なHTTPS またはstarttlsに失敗すること(たとえば、証明書または暗号化の不一致な どによる)は、SIPリクエストを拒否する場合と同じではない。また、修正の ためにユーザー間で追加の通信が必要になる可能性もある。 本文書は遷移的信頼の使用を支持していないことに注意。つまり、UASが信 頼しているUACからURIを受信したというだけで、UASは、URIプロバイダとの 間で独自の信頼関係を確立せずに、URIから参照されるオブジェクトを暗黙 的に信頼すべきではない[SHOULD NOT]。 URIから参照されるコンテンツに対するアクセス制御は、本仕様で定義し ない。アクセス制御メカニズムは、間接的コンテンツ URIのスキームに関す るプロトコルで定義される可能性がある。 UACがコンテンツをあらかじめわかっている場合、UACはコンテンツ間接化 にhashパラメータを含めるべきである[SHOULD]。hashパラメータは、間接的 コンテンツを16進でエンコードしたSHA-1 [8]ハッシュである。ハッシュ値 を含める場合、受信者はそのハッシュに対して間接的コンテンツを確認し、 すべての不一致をユーザーに示さなければならない[MUST]。 さらに、hashパラメータが含まれ、対象URIが証明書を使用したセキュリティ コンテキストの確立を伴う場合、UASは証明書の検証手順の結果を無視し、 (正規化された)受信コンテンツのハッシュが、コンテンツ間接化のhashパ ラメータに提示されているハッシュと一致することを検証しなければならな い[MUST]。 hashパラメータが含まれない場合、送信者はメッセージの完全性をオファー するスキーム(https:など)のみを使用すべきである[SHOULD]。hashパラメー タが含まれず、証明書を使用するセキュリティが使用される場合、UASは、 信頼するトップレベルの証明書機関に関するUAS側の一覧を使用して、送信 側の証明書を検証しなければならない[MUST]。 間接的コンテンツのハッシュ化を使用しない場合、間接化の実行によって受 信者に返されるコンテンツは、送信者が意図した内容からは変わっている可 能性がある。 Burger Standards Track [Page 14] RFC 4483 Content Indirection in SIP Messages May 2006 8. 寄稿 Sean Olson (seanol@microsoft.com)は、最初のIESGレビューによる編集を 含め、本文書の大部分の内容を提供した。Dean Willisはそれを次の段階に 移行した。 Eric Burgerは文書を編集し、アクセスプロトコルのネゴシエーションメカ ニズムを含め、IESGのコメントに対処した。 9. 謝辞 Cullen JenningsとNancy Greeneからは、全体のレビュー、貴重なコメント と提案をいただいた。 10. 参考文献 10.1. 規範となる参考文献 [1] Freed, N. and K. Moore, "Definition of the URL MIME External- Body Access-Type", RFC 2017, October 1996. [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997. [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [8] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. Burger Standards Track [Page 15] RFC 4483 Content Indirection in SIP Messages May 2006 [9] 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. [10] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003. [11] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [12] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. 10.2. 有益な参考文献 [13] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. 著者の連絡先 Eric Burger (editor) Cantata Technolgy, Inc. EMail: eburger@cantata.com URI: http://www.cantata.com Burger Standards Track [Page 16] RFC 4483 Content Indirection in SIP Messages May 2006 完全な著作権表示 Copyright (C) The Internet Society (2006). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄 稿者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン ターネット協会およびIETFは、この情報がいかなる権利も侵害していないと いう保証、商用利用および特定目的への適合性への保証を含め、また、これ らだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行わ れない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79 に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装 者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能 である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情報 については、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集職務のための資金は、IETF Administrative Support Activity (IASA)によって提供されている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2007年 ----------------------------------------------------------------------- Burger Standards Track [Page 17]