Network Working Group R. Sparks Request for Comments: 3420 dynamicsoft Category: Standards Track November 2002 インターネットメディアタイプ message/sipfrag Internet Media Type message/sipfrag 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 概要 本文書は、MIME(Multipurpose Internet Mail Extensions)メディアタイプ 「message/sipfrag」を登録する。このタイプは、message/sipに似ているが、 完全なセッション開始プロトコル(Session Initiation Protocol/SIP)メッ セージを要求する代わりに、整形済みのSIPメッセージの特定サブセットを表 すことができる。エンドツーエンドのセキュリティ用途の他に、message/ sipfragは、REFERメソッドで使用で参照されるリクエストのステータス情報を 伝達するときに使用される。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 定義: message/sipfrag . . . . . . . . . . . . . . . . . . . . . 2 3. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 有効なmessage/sipfragパート . . . . . . . . . . . . . . . . 3 3.2 無効なmessage/sipfragパート . . . . . . . . . . . . . . . . 4 4. 議論 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. セキュリティの考慮 . . . . . . . . . . . . . . . . . . . . . . 6 規範となる参考文献 . . . . . . . . . . . . . . . . . . . . . . 7 規範ではない参考文献 . . . . . . . . . . . . . . . . . . . . . 7 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . 7 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . . 8 Sparks Standards Track [Page 1] RFC 3420 Internet Media Type message/ipfrag November 2002 1. はじめに 参考文献[1]で定義されているmessage/sip MIMEメディアタイプは、整形済み SIPメッセージ全体を伝達する。参考文献[1]のセクション23.4では、S/MIMEと 連携してmessage/sipを使用して、エンドツーエンドのセキュリティを向上す る方法が説明されている。SIPメッセージのサブセットに関してSIPエンティ ティがアサートするように、セクション23.4の概念を拡張することができる (たとえば、参考文献[6]参照)。本文書で定義されるmessage/sipfragタイプ は、このサブセットを表すために使用される。 SIPメッセージのサブセットは、参考文献[5]で定義されるREFERメソッドで も、参照されるリクエストのステータスを伝達するために使用される。SIP メッセージの一部分のみを伝達することを許可することで、プライバシや機密 性のセキュリティを危うくする情報が削除され、保護が可能になる。 本文書は、別個のトランスポートや後の再構築のために、SIPメッセージを複 数の部品にセグメント化する仕組みは提供しない[NOT]。参考文献[2]で定義さ れるmessage/partialタイプは、この問題の解決策を提供している。 本文書中のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、 「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、 「OPTIONAL」は、参考文献[4]で記述されている通りに解釈される。 2. 定義: message/sipfrag 有効なmessage/sipfragパートは、何らかの有効なSIPメッセージで開始され、 以下のいずれかを削除することで取得できるものである。 o 開始行(start line)全体 o 1つ以上のヘッダーフィールド全体 o ボディ 次のABNF(Augmented Backus-Naur Form/参考文献[3])規則では、参考文献[1] で定義されているSIP文法要素を使用して、message/sipfragパートを記述して いる。要素のいずれかを拡張するには、定義済みの有効なSIPメッセージの制 限に従う。 sipfrag = [ start-line ] *message-header [ CRLF [ message-body ] ] Sparks Standards Track [Page 2] RFC 3420 Internet Media Type message/ipfrag November 2002 message/sipfragパートにボディが含まれる場合、参考文献[1]のセクション 7.4で必須とされる、ボディの記述に適切なヘッダーフィールド(Content- Length)と、ヘッダーとボディを区別するnull行も含めなければならない [MUST]。 3. 例 3.1 有効なmessage/sipfragパート ここでは、例の範囲がわかりやすいように、例の左に縦線とスペースを入れ る。message/sipfrag要素の各行は、"|"ペアの最初の文字から始まる。 最初の2つの例では、message/sipfragパートが開始行でのみ構成できることを 示す。 | INVITE sip:alice@atlanta.com SIP/2.0 または | SIP/2.0 603 Declined 次の2つは、完全SIPメッセージのサブセットを示すことが可能な例である。 | REGISTER sip:atlanta.com SIP/2.0 | To: sip:alice@atlanta.com | Contact: ;q=0.9, | ;q=0.1 | SIP/2.0 400 Bad Request | Warning: 399 atlanta.com Your Event header field was malformed message/sipfragパートには、開始行を含める必要はない。この例では、特定 メッセージに関するアサートを行うために署名された可能性のあるパートを示 す。(参考文献[6]を参照) | From: Alice | To: Bob | Contact: | Date: Thu, 21 Feb 2002 13:02:03 GMT | Call-ID: a84b4c76e66710 | Cseq: 314159 INVITE Sparks Standards Track [Page 3] RFC 3420 Internet Media Type message/ipfrag November 2002 次の2つの例は、ボディを含むmessage/sipfragパートを示す。 | SIP/2.0 200 OK | Content-Type: application/sdp | Content-Length: 247 | | v=0 | o=alice 2890844526 2890844526 IN IP4 host.anywhere.com | s= | c=IN IP4 host.anywhere.com | t=0 0 | m=audio 49170 RTP/AVP 0 | a=rtpmap:0 PCMU/8000 | m=video 51372 RTP/AVP 31 | a=rtpmap:31 H261/90000 | m=video 53000 RTP/AVP 32 | a=rtpmap:32 MPV/90000 | Content-Type: text/plain | Content-Length: 11 | | Hi There! 3.2 無効なmessage/sipfragパート ここでは、例の範囲がわかりやすいように、例の左に"X"とスペースを入れ る。message/sipfrag要素の各行は、"X"ペアの最初の文字から始まる。 開始行がある場合、参考文献[1]に従って完全で有効なものにする必要があ る。 X INVITE X INVITE sip:alice@atlanta.com SIP/1.09 X SIP/2.0 X 404 Not Found すべてのヘッダーフィールドは参考文献[1]に従って有効にする必要がある。 X INVITE sip:alice@atlanta.com SIP/2.0 X Via: SIP/2.0/UDP ;branch=z9hG4bK29342a X To: <>;tag=39234 X To: sip:alice@atlanta.com X From: sip:bob@biloxi.com;tag=1992312 Sparks Standards Track [Page 4] RFC 3420 Internet Media Type message/ipfrag November 2002 X Call-ID: this is invalid X INVITE sip:alice@atlanta.com SIP/2.0 X From: ;tag=z9hG4bK2912;tag=z9hG4bK99234 ボディがmessage/sipfragパートにある場合、参考文献[1]のセクション7.4で 必須とされるヘッダーと、ヘッダーとボディを区分するnull行。 X MESSAGE sip:alice@atlanta.com SIP/2.0 X Hi There! 4. 議論 参考文献[1]のセクション23、メモ(参考文献[5]、[6])には、MIMEパートでSIP メッセージの全部または一部を伝達する場合の動機付けと詳細な例が記載され ている。簡単に言うと、S/MIMEとともにこの表記を使用することで、SIPメッ セージヘッダーの一部に関して、保護し、アサートすることが可能になる。ま た、アプリケーションで、メッセージ自体の一部を使用して、SIPトランザク ションにかかわるメッセージを記述することもできるようになる。 たとえば、SIP REFERメソッド(参考文献[5])ではこれを利用して、SIPリク エストの結果を認可済みのサードパーティにレポートしている。ただし、参 考文献[5]で詳しく書かれているように、message/sip MIMEパートとして、 このレポートにSIP応答メッセージ全体を含めるのは、ほとんどの場合は望ま しくない。この場合、セキュリティ上、多大な悪影響が出る。一方、message/ sipfragタイプを使用すると、送信側は、どの情報を公開するかを選択でき る。さらに、そのメッセージの記述に不適切である、完全なSIPメッセージで 必須とされる情報を省略して、メッセージサイズを減らすことができる。たと えば、これによって、REFERに応答するSIP要素で、完全なSIPメッセージでは 必須であるヘッダーフィールドのVia、To、From、Call-ID、CSeq、Content- Lengthを含めなくても、「このWarning ヘッダーフィールドで400 Bad Requestを受信」と示すことができるようになる。 参考文献[1]のセクション23に記載されているメッセージの保護メカニズムに よって、SIPメッセージ全体を保護できる。ただし、完全なSIPメッセージに は、伝送中に変える必要のあるヘッダーフィールドがいくつかある。参考文献 [1]では、このような変更を検出し、無視する方法が説明されている。この概 念は、参考文献[6]で洗練され、でメッセージ全体のサブセットを保護できる ようになった。余計な作業もなく、伝送で正当に変更された可能性のあるメッ セージ部分を無視したことによるエラーも回避される。この文書では、完全な SIPメッセージヘッダー(ホップバイホップの伝送固有の情報など)が使用でき る前に、SIPメッセージヘッダーの適切なサブセットに関して、暗号化のア サートを構築する方法についても説明されている。 Sparks Standards Track [Page 5] RFC 3420 Internet Media Type message/ipfrag November 2002 5. IANA条項 message/sipfragメディアタイプは、次の情報で定義される。 メッセージタイプ名: message メディアのサブタイプ名: sipfrag 必要なパラメータ: なし オプションのパラメータ: version バージョン: 引用符で囲まれたメッセージのSIPバージョン番号(例 "2.0") 存在しない場合、デフォルトのバージョンは"2.0"。 エンコーディングスキーム: SIPメッセージは、8ビットのヘッダーと、オプ ションで続くバイナリのMIMEデータオブジェクトで構成される。したがっ て、SIPメッセージはバイナリとして扱う必要がある。通常の状況では、SIP メッセージは、バイナリを使用可能な伝送方法で伝送され、特殊なエンコー ディングは不要である。 セキュリティの考慮: 以下を参照 6. セキュリティの考慮 message/sipfrag MIMEパートには、機密情報や、受信側の判断に影響を及ぼす 情報が含まれる可能性がある。伝送時に、この情報を公開または修正すること で損害が出る場合、保護のレベルは、参考文献[1]のセクション23に記述され ているS/MIMEメカニズムを使用することで改善できる。ただし、参考文献[1] のセクション26に記載される制限と、参考文献[6]に記載されているメカニズ ムが必要である。 SIPメッセージのヘッダーフィールドのサブセットを表すために、message/ sipfragを使用するアプリケーションは、message/sipfragが取得されることと 再生されることを考慮に入れ、その危険性に対処するための情報も検討する必 要がある。message/sipfragを使用するSIP拡張は、拡張に固有のリプレイ攻撃 やカット&ペースト攻撃について記述しなければならない[MUST]。たとえば、 参考文献[6]では、SIPメッセージのサブセットが、SIPリクエストを作成した エンティティのIDをアサートするときに利用する方法が議論されている。この ドラフトには、アサートとリクエストを結合するために、サブセットに含める 必要のある情報について詳しく書かれている。 Sparks Standards Track [Page 6] RFC 3420 Internet Media Type message/ipfrag November 2002 規範となる参考文献 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3265, June 2002. [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 規範ではない参考文献 [5] Sparks, R., "The SIP Refer Method", Work in Progress. [6] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress. 著者の連絡先 Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: rsparks@dynamicsoft.com Sparks Standards Track [Page 7] RFC 3420 Internet Media Type message/ipfrag November 2002 完全な著作権表示 Copyright (C) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳はコピーし他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著作 権表示およびこの節を付加するものはすべて、全体であってもその一部であっ ても、いっさいの制約を課されること無く、準備、複製、発表、配布すること ができる。しかし、この文書自体にはいかなる方法にせよ、著作権表示やイン ターネットソサエティもしくは他のインターネット関連団体への参照を取り除 くなどの変更を加えてはならない。インターネット標準を開発するために必要 な場合は例外とされるが、その場合はインターネット標準化過程で定義されて いる著作権のための手続きに従わなければならない。またRFCを英語以外の言 語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネット協会もしくは その継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないという 保証、商用利用および特定目的への適合性への保証を含め、また、これらだけ に限らずすべての保証について、明示的もしくは暗黙的の保証は行われない。 謝辞 RFC編集者職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Sparks Standards Track [Page 8]