Network Working Group F. Andreasen Request for Comments: 4568 M. Baugher Category: Standards Track D. Wing Cisco Systems July 2006 セッション記述プロトコル(SDP)の メディアストリーム用セキュリティ記述 Session Description Protocol (SDP) Security Descriptions for Media Streams 本文書の位置付け 本文書は、インターネットコミュニティのためのインターネット標準化過程 プロトコルを規定し、改善のための議論や提案を依頼するものである。標準 化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。本文書の配信は無 制限である。 著作権表記 Copyright (C) The Internet Society (2006). 概要 本文書は、ユニキャストメディアストリーム用のセッション記述プロトコル (Session Description Protocol/SDP)の暗号化属性を定義する。この属性に は、単一のメッセージまたは往復の交換のユニキャストメディアストリーム でセキュリティを構成するときに役立つ、暗号化キーと他のパラメータを記 述する。この属性は多様なSDPメディアトランスポートに使用することができ る。また、本文書は、Secure Real-time Transport Protocol (SRTP)ユニ キャストメディアストリームに使用する場合の方法について定義している。 SDPのcrypto属性には、SDPメッセージのセキュリティを保護するデータセ キュリティプロトコルのサービスが必要である。 目次 1. はじめに ...................................................... 3 2. 表記規則 ...................................................... 5 3. 適用可能性 .................................................... 5 4. SDP「crypto」属性とパラメータ .................................. 5 4.1. tag ...................................................... 6 4.2. crypto-suite .............................................. 6 4.3. key-params ................................................ 7 4.4. セッションパラメータ ...................................... 8 4.5. 例 ........................................................ 8 5. crypto属性の一般的な用法 ...................................... 9 5.1. オファー/アンサーとの併用 ................................ 9 5.1.1. 最初のオファーを生成する - ユニキャストストリーム .. 9 Andreasen, et al. Standards Track [Page 1] RFC 4568 SDP Security Descriptions July 2006 5.1.2. 最初のアンサーを生成する - ユニキャストストリーム . 10 5.1.3. 最初のアンサーを処理する - ユニキャストストリーム . 11 5.1.4. セッションの修正 ................................. 11 5.2. オファー/アンサー以外 ................................... 11 5.3. 一般的な下位互換性の考慮事項 ............................. 12 6. SRTPセキュリティ記述 ......................................... 12 6.1. SRTP keyパラメータ ....................................... 13 6.2. crypto-suite ............................................. 16 6.2.1. AES_CM_128_HMAC_SHA1_80 ........................... 16 6.2.2. AES_CM_128_HMAC_SHA1_32 ........................... 17 6.2.3. F8_128_HMAC_SHA1_80 ............................... 17 6.2.4. 新しいcrypto-suite定義の追加 ..................... 17 6.3. セッションパラメータ ..................................... 17 6.3.1. KDR=n ............................................. 18 6.3.2. UNENCRYPTED_SRTCPとUNENCRYPTED_SRTP ............... 18 6.3.3. UNAUTHENTICATED_SRTP ............................. 18 6.3.4. FEC_ORDER=order ................................... 19 6.3.5. FEC_KEY=key-params ............................... 19 6.3.6. ウィンドウサイズヒント(Window Size Hint/WSH) ..... 19 6.3.7. 新しいSRTPセッションパラメータの定義 ............. 20 6.4. SRTP cryptoコンテキストの初期化 ......................... 20 6.4.1. 1つまたは複数のSSRCのcryptoコンテキストへのレイト バインディング ....................................... 21 6.4.2. 複数のセッションまたはSSRCでの暗号コンテキストの 共有 ................................................... 22 6.5. cryptoコンテキストの削除 ................................. 23 7. crypto属性のSRTP固有の用法 ................................... 23 7.1. オファー/アンサーとの併用 ............................... 23 7.1.1. 最初のオファーを生成する - ユニキャストストリーム . 23 7.1.2. 最初のアンサーを生成する - ユニキャストストリーム . 24 7.1.3. 最初のアンサーを処理する - ユニキャストストリーム . 25 7.1.4. セッションの修正 ................................. 25 7.1.5. オファー/アンサーの例 ............................. 27 7.2. オファー/アンサー以外のSRTP固有の用法 ................... 28 7.3. SIP分岐処理への対応 ..................................... 28 7.4. SRTP固有の下位互換性に関する考慮事項 ..................... 29 7.5. KEYMGT=行とk=行の操作 ................................... 29 8. セキュリティの考慮事項 ....................................... 29 8.1. パケットの認証 ........................................... 30 8.2. キーストリームの再利用 ................................... 30 8.3. 認証のシグナリングと暗号化のシグナリング ................. 31 9. 文法 ......................................................... 32 9.1. 一般的な「crypto」属性の文法 ............................. 32 9.2. SRTPの「crypto」属性の文法 ............................... 32 10. IANA条項 ..................................................... 34 10.1. 「crypto」属性の登録 ................................... 34 Andreasen, et al. Standards Track [Page 2] RFC 4568 SDP Security Descriptions July 2006 10.2. 新しいIANA登録と登録手順 ............................... 34 10.2.1. keyメソッドの登録項目と登録 ..................... 34 10.2.2. メディアストリームトランスポートの登録項目と登録 . 35 10.3. 初期登録 ............................................... 35 10.3.1. keyメソッド ..................................... 35 10.3.2. SRTPメディアストリームトランスポート ............. 35 10.3.2.1. SRTP crypto-suiteの登録項目と 登録 ................................... 35 10.3.2.2. SRTPセッションパラメータの登録 ......... 36 11. 謝辞 ......................................................... 36 12. 規範となる参考文献 ........................................... 36 13. 有益な参考文献 ............................................... 37 付録A - キーイング要素の方向性に関する論拠 ....................... 40 1. はじめに セッション記述プロトコル(Session Description Protocol/SDP) [RFC4566] では、マルチメディアセッション(たとえば、音声、ビデオ、ホワイトボード、 Fax、モデムなどのメディアストリーム)について説明している。多くの場合、 このようなストリームには、データ送信元の認証、完全性、機密性などのセ キュリティサービスが必要である。Secure Real-time Transport Protocol (SRTP) [RFC3711]は、RTPメディアにセキュリティサービスを提供する。また、 セキュリティで保護されたRTPトランスポート(たとえば、「RTP/SAVP」また は「RTP/SAVPF」)を利用して、SDPメディア(m=)行でシグナリングされる。た だし、SDP自体には、デフォルト値の使用を越えてSRTPを構成する手段がない。 本文書では、「crypto」という新しいSDP属性を規定する。この属性は、一般 的に、メディアストリームの暗号化パラメータをシグナリングおよびネゴシ エートするために使用される。特にSRTPに使用される。本文書における crypto属性の定義は、各ソースが一意の暗号化キーを持っている2パーティの ユニキャストメディアストリームに限定されている。マルチキャストメディ アストリーム、または多パーティのユニキャストストリームへの対応は、今 後の研究が必要である。 crypto属性は、SRTPや他のセキュリティで保護されたトランスポート(単一の メッセージのみ、またはオファー/アンサーモデル[RFC3264]を使用して単一 の往復交換で、暗号化パラメータを確立することができるトランスポート)と 併用できる汎用的な方法で定義されている。 ただし、SRTP以外のトランスポートの拡張は、本文書の範囲外である。セ キュリティで保護されたメディアトランスポートの各タイプは、crypto属性 パラメータに固有の規定が必要である。これらの定義は、特定タイプのトラ ンスポートに固有の場合が多く、標準化過程のRFCで規定し、セクション10に 定義されている手順に従ってIANAに登録する必要がある。本文書では、SRTP についてのみ、セキュリティパラメータとキーイング要素(keying material) を定義する。 Andreasen, et al. Standards Track [Page 3] RFC 4568 SDP Security Descriptions July 2006 データのセキュリティ保護と同様に、暗号化キーや他のパラメータのセキュ リティを保護しないことは自滅的である。SRTPなどのデータセキュリティプ ロトコルは、個別のキー管理システムに依存して、暗号化キーや認証キーを 安全に確立している。キー管理プロトコルには、認証済みキーの確立 (authenticated key establishment/AKE)手順が用意されており、各エンドポ イントの身元を認証し、仲介者攻撃(man-in-the-middle)、反射/再生攻撃、 接続のハイジャック攻撃、DoS攻撃から保護する[skeme]。キーとともに、 MIKEY [mikey]、GDOI [GDOI]、KINK [kink]、IKE [ike]、Secure Multiparts [s/mime、pgp/mime]、またはTLS [TLS]などのAKEプロトコルを使用すると、 キーおよびデータセキュリティセッションの両方を記述した情報を安全に広 めることができる。AKEが必要な理由は、攻撃者がキーを探ること、キーの定 義を変更して無意味に表示すること、またはセキュリティセッションのパラ メータを変更してセッション関連情報に不正アクセスすることが可能な場合、 メディアにキーを提供することは意味がないためである。 一方、SDPはAKEサービスを提供するように設計されなかった。また、本文書 に定義されているメディアセキュリティ記述は、AKEサービスをSDPに追加し ていない。本仕様は、キー管理プロトコル、またはSDPのキー管理メッセージ の伝達の代わりとなるものではない[keymgt]。本文書に定義されているSDPセ キュリティ記述は、IPsec、TLS、その他のデータセキュリティのカプセル化 プロトコル(たとえば、SIP S/MIME)がSDPメッセージを保護するという限定さ れた場合にのみ適している。本文書では、新しいSDP「crypto」属性を使用し て、暗号化または認証されたSDPメッセージにセキュリティの記述を追加する。 この属性は、メディアストリームの暗号化パラメータとして機能する。 「crypto」属性は任意のメディアトランスポートに適用できるが、正確な定 義は特定のトランスポートに固有である。 セクション2では表記上の規約について説明し、セクション3ではcrypto属性 の適用可能性について記載する。セクション4ではSDP crypto属性の概要につ いて紹介し、セクション5ではオファー/アンサーモデルを使用する場合と使 用しない場合の使用方法について定義する。セクション6ではSRTPに必要な crypto属性の詳細を定義し、セクション7ではオファー/アンサーモデルを使 用する場合と使用しない場合に分けて属性のSRTP固有の用法について定義す る。セクション8ではセキュリティの考慮事項について列挙し、セクション9 では一般的なcrypto属性について拡張BNFの文法と、crypto属性のSRTP固有の 用法について記載する。セクション10にはIANA条項を記載する。 Andreasen, et al. Standards Track [Page 4] RFC 4568 SDP Security Descriptions July 2006 2. 表記規則 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、 [RFC2119]に記載されるとおりに解釈されるべきである。本文書の用語は、 [RFC2828]の「Internet Security Glossary (インターネットセキュリティ用 語集)」に準拠する。 n^rは累乗であり、nはr回累乗されることを示す。nとrは整数である。0..kは、 0以上k以下のすべての整数を含む整数の範囲である。 「トランスポート」および「メディアトランスポート」という用語は、RFC 4566に定義されている「トランスポートプロトコル」の意味で使用されてい る。 注記が本文書の各所に記載されているが、注記は周囲の文章よりもスペース3 個分字下げされている。 3. 適用可能性 RFC 4567は類似の暗号化キー配布機能を提供しており、シグナリングを機密 にすべきときや、キーイング要素とは別に完全性を保護すべきときに使用す ることを目的としている。 対照的に、本仕様はSDPメッセージ内でキーイング要素を伝達する。また、 キーイング要素をシグナリングとともに保護するときに使用することを目的 としている。実装では、キーイング要素の機密性と完全性を実現するセキュ リティメカニズムを採用しなければならない[MUST]。本仕様をSIP [RFC3261] の環境で使用する場合、アプリケーションはSIPS URIまたはS/MIMEを採用し て、含まれるSDPメッセージとキーイング要素を保護すべきである[SHOULD]。 SIPS URIまたはS/MIMEの保護の代わりに、トランスポートレイヤーまたは IPsecレイヤーのセキュリティを使用することは推奨されない[NOT RECOMMENDED]。その理由は、SDPメッセージとそれに含まれるキーイング要素 の保護は、SIPプロキシなどのすべての中間エンティティを通して確保するこ とはできないためである。 4. SDP「crypto」属性とパラメータ 「crypto」という新しいメディアレベルSDP属性には、前のユニキャストメ ディア行の暗号化スイート、keyパラメータ、およびセッションパラメータを 記述する。「crypto」属性が出現するのはSDPメディアレベルのみである [MUST](セッションレベルには出現しない)。「crypto」属性は以下の書式に 従う(正式なABNF文法についてはセクション9.1参照)。 a=crypto: [] Andreasen, et al. Standards Track [Page 5] RFC 4568 SDP Security Descriptions July 2006 tag、crypto-suite、key-params、およびsession-paramsの各フィールドにつ いては、以降のサブセクションで説明する。各フィールドの値は特記がない 限り、大文字と小文字を区別しない。ただし、実装する場合、本文書および 本文書の拡張に記載される実際の大文字/小文字表記を使用することが推奨さ れる。通常のSDP規則に従い、「crypto」属性名自体は大文字と小文字を区別 する。以下に、「RTP/SAVP」トランスポートのcrypto属性の例を示す。つま り、Audio/Video プロファイルのセキュアRTP拡張である[RFC3711]。 以下の例では、書式を整える理由でのみ、改行を入れている。 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32 crypto-suiteはAES_CM_128_HMAC_SHA1_80であり、key-paramsは"inline:"で 始まるテキストで定義され、session-paramsは省略されている。 4.1. tag tagは、特定のcrypto属性の識別子として使用される十進数である(詳細につ いてはセクション9.1参照)。先頭にゼロを使用してはならない[MUST NOT]。 tagは、特定のメディア行について全crypto属性の中で一意でなければならな い[MUST]。これはオファー/アンサーモデルとともに使用して、オファー済み crypto属性の中からアンサー側が選択した属性を決定する(セクション5.1参 照)。 オファー/アンサーモデルでは、tagはnegotiated (ネゴシエート済み型)パラ メータである。 4.2. crypto-suite crypto-suiteフィールドは、当該トランスポートの暗号化アルゴリズムおよ び認証アルゴリズム(たとえばAES_CM_128_HMAC_SHA1_80)を記述する識別子で ある(詳細についてはセクション9.1参照)。crypto-suiteパラメータに使用で きる値は、トランスポートのコンテキスト内に定義されている。つまり、各 トランスポートは、crypto-suiteセットについて個別の名前空間を定義して いる。たとえば、コンテキスト「RTP/SAVP」トランスポート内に定義されて いるcrypto-suite「AES_CM_128_HMAC_SHA1_80」は、セキュアRTPにのみ適用 される。文字列を他のトランスポート(たとえば、「RTP/SAVPF」[srtpf])に 再利用することもできるが、個別の定義が必要である。 オファー/アンサーモデルでは、crypto-suiteはnegotiatedパラメータである。 Andreasen, et al. Standards Track [Page 6] RFC 4568 SDP Security Descriptions July 2006 4.3. key-params key-paramsフィールドは、当該のcrypto-suite用にキーイング要素を1セット または複数セット提供する。以下のように、このフィールドは、メソッドイ ンジケータ、続けてコロン、実際のキーとなる情報から構成される(正式な文 法についてはセクション9.1参照)。 key-params = ":" キーイング要素は、key-paramsとは異なる方法で提供できるが、その方法は 本文書の範囲外である。本文書では、1つのメソッドのみ、つまり「inline」 を定義している。これは、実際のキーイング要素をkey-infoフィールド自体 に提示することを示している。 key-methodには単一の名前空間がある。つまり、key-methodはトランスポー ト非依存である。将来的に、新しいkey-method (たとえばURLの使用)が標準 化過程のRFCで定義される可能性がある。key-method自体は汎用的に使用でき るが、付随するkey-info定義は、key-methodのみでなく当該トランスポート に固有である。key-infoは、キーイング要素を定義するcryptoスイートにつ いて、そのキーイング要素をエンコーディングしている。新しいkeyメソッド は、セクション10.2.1に定義されている手順に従ってIANAに登録しなければ ならない[MUST]。 key-infoは、汎用的なオクテット文字列と定義される(詳細についてはセク ション9.1参照)。新たなトランスポートおよびkey-method固有の構文および セマンティクスは、使用するトランスポートとkeyメソッドの組み合わせごと に、標準化過程のRFC で提示しなければならない[MUST]。SRTPの定義につい てはセクション6を参照のこと。こうした定義は、特定のトランスポート (「RTP/SAVP」など)および具体的なkey-method (「inline」など)の両方があ るコンテキストで提示されているとに注意。IANAは、トランスポートごとに 対応のkeyメソッド一覧を登録する。 複数のキーがkeyパラメータに含まれる場合、受信したメディアパケットを簡 単に調べるだけで、あるメディアパケットに使用されているキーを判断でき るようにしなければならない[MUST]。キー候補に試行錯誤法を実行してはな らない。 SRTPの場合、Master Key Identifiers (MKI) [RFC3711]を使用することで この処理を達成することができる。セクション6.1で説明する理由から、 SRTPセキュリティ記述に<"From, "To">値を使用しても対応されない。 オファー/アンサーモデルでは、keyパラメータはdeclarative (宣言型)パラ メータである。 Andreasen, et al. Standards Track [Page 7] RFC 4568 SDP Security Descriptions July 2006 4.4. セッションパラメータ セッションパラメータは、あるトランスポートに固有のものであり、パラ メータを使用することは、セキュリティ記述フレームワーク内でオプション である[OPTIONAL]。セッションパラメータは、一般的な特性の文字列として のみ定義されている。セッションパラメータを特定のトランスポートに使用 する場合、トランスポート固有の構文とセマンティクスは、標準化過程のRFC で提供しなければならない[MUST]。SRTPの定義はセクション6を参照のこと。 オファー/アンサーモデルの場合、セッションパラメータはnegotiatedまたは declarativeの可能性がある。各セッションパラメータの定義には、 negotiatedまたはdeclarativeを示さなければならない[MUST]。 negotiatedパラメータは、両方向で送信されるデータに適用される。一方、 declarativeパラメータは、SDPを生成したエンティティが送信したメディア のみを適用する。したがって、あるオファーに含まれるdeclarativeパラメー タは、オファー側が送信したメディア指し、一方、アンサーのdeclarativeパ ラメータは、アンサー側が送信するメディアにも適用される。 4.5. 例 これは、「RTP/SAVP」メディアトランスポートタイプにcrypto属性の使用例 である(セクション5の定義参照)。「a=crypto」行は実際には長い1行だが、 ページの書式に合わせて2行になっている。 v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 161.44.17.12/127 t=2873397496 2873404696 m=video 51372 RTP/SAVP 31 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 m=audio 49170 RTP/SAVP 0 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 m=application 32416 udp wb a=orient:portrait このSDPメッセージでは、3つのメディアストリームを記述しており、そのう ちの2つは「RTP/SAVP」トランスポートを使用している。それぞれ、 「RTP/SAVP」トランスポートにはcrypto属性がある。これらのセキュアRTP固 有の記述がセクション6に定義されている。 Andreasen, et al. Standards Track [Page 8] RFC 4568 SDP Security Descriptions July 2006 5. crypto属性の一般的な用法 このセクションでは、トランスポートまたはkeyメソッド固有の規則以外の、 crypto属性の一般的な用法について説明する。 5.1. オファー/アンサーとの併用 RFC 3264に規定されている規則の他に、crypto属性の一般的なオファー/アン サー規則がある。なお、RFC 3264には特記がない限り従わなければならない [MUST]。RFC 3264では、ユニキャストおよびマルチキャストストリームの両 方について操作を定義している。以降のセクションでは、2パーティのユニ キャストストリームの操作についてのみ説明している。マルチキャストスト リーム(および多パーティのユニキャストストリーム)の対応はまだ研究中の ためである。 5.1.1. 最初のオファーを生成する - ユニキャストストリーム ユニキャストストリームで最初のオファーを生成する場合、希望するセキュ リティのために、メディアストリームごとに1つまたは複数のcrypto属性を指 定しなければならない[MUST]。あるメディアストリームの各crypto属性には、 一意のタグを含めなければならない[MUST]。 複数の「a=crypto」行がある場合、その順序は重要である。最優先のcrypto 行は最初に記載する。各crypto属性には、そのメディアストリームに関して オファーするcrypto-suite、キー(複数もあり)、その他のセッションパラ メータを記述する。一般的に、「優先度が高い」crypto-suiteは、「優先度 が低い」crypto-suiteよりも暗号処理が強力なものであるべきである。 crypto-suiteは、メディアストリームが対応する記述のメディアに常に適用 される。一方、キーは、SDPを生成したのと同じパーティが送信するデータパ ケット(たとえば、SRTPやSRTCPパケット)に適用される。つまり、各エンドポ イントは自分の送信キーを決定し、そのキーをSDPで相手側エンドポイントに 送信する。 この処理は一貫性を保つために実行される。また、SRTPの場合、たとえば、 一方向ストリームの送信方向と受信方向のどちらでも、セキュアRTCPのフ ローは続く。 inlineパラメータは、エンドポイントが送信するメディアストリームを暗号 化するために、エンドポイントが使用するキーイング要素を伝達する。受信 者は同じキーイング要素を使用してそのストリームを復号する。 オファーにはセッションパラメータを含めることができる。セッションパラ メータに一般的なオファー規則はない。その代わりに、任意のセッションパ ラメータについて、トランスポート固有の定義の一部として詳しい規則を指 定することができる。 Andreasen, et al. Standards Track [Page 9] RFC 4568 SDP Security Descriptions July 2006 オファーを発行する際、オファー側は、オファーに含める任意のcrypto属性 に従ってメディアセキュリティに対応するように準備を整えなければならな い[MUST]。ただし、そのためには関連する問題が2つある。 第1に、オファー側は、アンサー側がオファー側へのメディア送信に使用する キーを知らない。第2に、オファー側は、オファーしたcrypto属性のうち、ど の属性が受け入れられたかを推測することができない。メディアはアンサー の前に到達する場合があるため、遅延または省略が発生する可能性がある。 オファー側がこの問題を許容できない場合、オファー側は本文書に記載され ていないメカニズムを使用して、問題を回避すべきである[SHOULD]。 たとえば、SIP [RFC3261]の場合、[sprecon]に定義されている 「security」前提条件を使用すると、この問題を解決することができる。 5.1.2. 最初のアンサーを生成する - ユニキャストストリーム アンサー側が、あるユニキャストメディアストリームで1つまたは複数の crypto属性を含む最初のオファーを受信した場合、アンサー側はオファーさ れたcrypto属性の1つのみを受け入れなければならない[MUST]。またはオ ファーされたストリームを拒否しなければならない[MUST]。 アンサー側が他のcrypto属性への対応を示したい場合、SDP Simple Capability Declaration [RFC3407]拡張を利用して列挙することができる。 受け入れることができるのは有効なcrypto属性のみである。有効な属性とは、 セキュリティ記述に定義されている一般的な規則のいずれにも違反せず、当 該のトランスポートおよびkeyメソッド用に定義されている固有の規則のいず れにも違反していない属性である。有効なcrypto属性の1つを選択するとき、 アンサー側は、対応可能なcrypto属性のうち、最も優先度が高いものを選択 すべきである[SHOULD]。つまり、アンサー側の能力とセキュリティポリシー に従って対応する有効なcrypto属性のうち、一覧で最初の属性である。 オファーに1つまたは複数のcrypto属性があるが、有効な属性がない場合、ま たは有効な属性のいずれにも対応していない場合、オファーされたメディア ストリームを拒否しなければならない[MUST]。 オファーされたcrypto属性を受け入れるとき、アンサーのcrypto属性には以 下を含めなければならない[MUST]。 * オファーの受け入れたcrypto属性のtagとcrypto-suite (送信方向と受信 方向には同じcrypto-suiteを使用しなければならない[MUST])。 * アンサー側がオファー側に送信するメディアに使用するキー。オファー またはアンサーの方向属性に関係なく、キーを提示しなければならな い[MUST]点に注意。 Andreasen, et al. Standards Track [Page 10] RFC 4568 SDP Security Descriptions July 2006 さらに、negotiatedのセッションパラメータは、アンサーに含めなければな らない[MUST]。オファー側が提示したdeclarativeセッションパラメータは、 アンサーに含めない。ただし、アンサー側は独自のdeclarativeセッションパ ラメータセットを提示してもよい。 オファーされたcrypto属性の1つをアンサー側が受け入れるとき、アンサー側 は選択したcrypto属性に従ってオファー側にメディアの送信を開始してもよ い。ただし、オファー側は、アンサーを受信するまで、こうしたメディアパ ケットを正しく処理できない可能性がある点に注意。 5.1.3. 最初のアンサーを処理する - ユニキャストストリーム オファー側がアンサーを受信した場合、オファー側は最初にオファーされた cryptoスイートの1つとそのtagが受け入れられ、アンサーでエコーされてい ることを検証しなければならない[MUST]。また、アンサーには、アンサー側 からオファー側へのメディア送信に使用する1つまたは複数のキーを含めなけ ればならない[MUST]。 オファーに必須のnegotiatedセッションパラメータのいずれかを含めた場合 (セクション6.3.7)、オファー側は、指定したパラメータがアンサーに含まれ ていることを検証し、対応しなければならない[MUST]。アンサーに必須の declarativeセッションパラメータのいずれかが含まれる場合、オファー側は それらに対応できなければならない[MUST]。 上記のいずれかに失敗した場合、ネゴシエーションは失敗しなければならな い[MUST]。 5.1.4. セッションの修正 メッセージメディアストリームの確立後は、RFC 3264セクション8に従って、 任意のタイミングで修正してもよい[MAY]。こうした修正は、たとえば再キー イングの実行やcrypto-suiteの変更などのために、セキュリティサービスが トリガしてもよい[MAY]。それでも、本文書に定義されている一般的なセキュ リティ記述を使用したメディアストリームのセキュリティが望ましい場合、 crypto属性は、新しいオファー/アンサー交換に含めなければならない[MUST]。 その手順は、本文書のセクション5.1.1、5.1.2、5.1.3に定義されているもの と似ており、RFC 3264セクション8に記載されている考慮事項に従う。 5.2. オファー/アンサー以外 cryptoスイート、暗号化キー、またはセッションパラメータのネゴシエー ションがないオファー/アンサーのコンテキスト以外でも、crypto属性を使用 することができる。この場合、送信者がストリームのセキュリティパラメー タを決定する。ネゴシエーションメカニズムはないため、送信者はcrypto属 性を1つのみ含めなければならない[MUST]。また、受信者は関連するストリー ムを受け入れなければならない[MUST]。または関連するストリームを受信す べきではない[SHOULD NOT]。送信者は、目的に合わせて最も安全と思われる Andreasen, et al. Standards Track [Page 11] RFC 4568 SDP Security Descriptions July 2006 セキュリティ記述を選択すべきである[SHOULD]。 5.3. 一般的な下位互換性の考慮事項 オファー/アンサーモデルでは、アンサー側があるセキュアトランスポート (「RTP/SAVP」など)に対応し、オファーされたメディアストリームを受け入 れ可能性があるが、アンサー側は本文書に定義されているcrypto属性には対 応しないため無視する可能性もある。オファー側は、アンサーの受け入れ済 みメディアストリームにcrypto行が含まれないことを確認することで、この 状況を認識することができる。この場合、本文書に定義されているセキュリ ティネゴシエーションは失敗しなければならない[MUST]。 オファーモデル以外のセキュリティ記述が使用される場合、同様の問題が存 在する。ただし、ネゴシエート以外のセキュリティ記述のソースには、受信 者がcrypto属性を無視したことを示すものはない。 6. SRTPセキュリティ記述 このセクションでは、SRTPメディアストリームのセキュリティ記述について 定義する。次のセクションでは、オファー/アンサーモデルを使用する場合と 使用しない場合のSRTPセキュリティ記述について使用方法を定義している。 SRTPセキュリティ記述は、SRTPトランスポート(たとえば、「RTP/SAVP」や 「RTP/SAVPF」)でのみ使用しなければならない[MUST]。[RFC3711]に定義され ている「RTP/SAVP」プロファイルのセキュリティ記述について、以下に規定 する。 ただし、SRTPプロトコル仕様[RFC3711]に従う他のセキュアRTPプロファイル (たとえば、「RTP/SAVPF」)も同じ記述を使用できると期待されている。 エンドポイントが特定のcrypto属性パラメータでSRTPサービスを設定するこ とができる、という保証はないが、SRTPは、デフォルトのSRTPパラメータ [RFC3711]によってSRTPエンドポイント間の最低限の相互運用性を保証してい る。より高機能なSRTPエンドポイントであれば、SRTPのデフォルト以外の多 様なパラメータ値に対応しており、その値は、本文書で定義されているSRTP セキュリティ記述で設定することができる。crypto属性に対応していないエ ンドポイントは、SDPに従ってそれを無視する。この場合、エンドポイントは そのメディアストリームを正しく処理できない。オファー側とアンサー側は オファー/アンサーモデルを使用することで、マルチメディアセッションの開 始前に、使用するcryptoパラメータをネゴシエートすることができる(セク ション7.1参照)。 SRTP仕様には20を超える暗号化パラメータがある。その多くは、特定の暗号 化変換用の固定値を持っている。ただし、一般的には、セッションの確立時 点で、SRTPパラメータ(ソルト(salt)の長さや疑似ランダム関数 (pseudo-random function/PRF)など)の多くについて一意の設定を提供する必 Andreasen, et al. Standards Track [Page 12] RFC 4568 SDP Security Descriptions July 2006 要はない。したがって、セキュリティセッションのSRTPパラメータ値セット を固定する「暗号化スイート」を定義することで、パラメータ一覧を単純化 することができる。SRTPセキュリティ記述はこのアプローチに従い、以下の ような一般的なセキュリティ記述を使用する。 * crypto-suite: 暗号化および認証の変換を指定する。 * key parameter: SRTPのキーイング要素とパラメータ * session parameters: 以下のパラメータが定義される。 - KDR: SRTPキー導出レート(Key Derivation Rate)。疑似ラ ンダム関数をマスターキーに適用するレート。 - UNENCRYPTED_SRTP: SRTPメッセージは暗号化されない。 - UNENCRYPTED_SRTCP: SRTCPメッセージは暗号化されない。 - UNAUTHENTICATED_SRTP: SRTPメッセージは認証されない。 - FEC_ORDER: SRTPサービスに対する回送エラー修正(forward error correction/FEC)の順序。 - FEC_KEY: FECストリームを別のアドレス/ポートに送信す るときのFECのマスターキー。 - WSH: ウィンドウサイズヒント(Window Size Hint)。 - Extensions: 拡張のパラメータを定義することができる。 パラメータとその記述の詳細な一覧については、SRTP仕様を参照のこと[セク ション8.2、srtp]。UNENCRYPTED_SRTCPパラメータに関して、SDPセキュリ ティ記述のオファー側とアンサー側は、UNENCRYPTED_SRTCPまたはデフォルト 値を上書きするためにSRTCP E-bitを使用してはならない[MUST NOT]。使用す ると、すべてのSRTCPメッセージが暗号化される(セクション6.3.2参照)。上 記のkeyパラメータ、crypto-suite、およびセッションパラメータの詳細につ いては、以下のサブセクションで説明する。 6.1. SRTP keyパラメータ SRTPセキュリティ記述は、以下の説明に従って、「inline」keyメソッドの用 法を定義する。SRTPセキュリティ記述に他のキーイングメソッドを使用する ことは、今後の研究対象である。 keyの「inline」タイプには、キーイング要素(マスターキーとマスターソル ト)とそのマスターキーに関連するすべてのポリシーが含まれる。たとえば、 使用できる期間(有効期間)や、受信SRTPパケットを特定のマスターキーに関 連付けるマスターキー識別子(master key identifier/MKI)を使用するかどう か、などである。準拠する実装は、マスターキーに関連付けれたポリシーに 従う。また、ポリシーに違反する受信パケットを受け入れてはならない[MUST NOT](たとえば、マスターキーの有効期限が切れた後など)。 keyパラメータには1つまたは複数の暗号化マスターキーが含まれる。また、 SDPメッセージ全体(つまり、他のストリームのマスターキーを含む)の他のマ Andreasen, et al. Standards Track [Page 13] RFC 4568 SDP Security Descriptions July 2006 スターキーに関して、その各マスターキーは暗号的にランダムな一意の値 [RFC1750]にしなければならない[MUST]。各キーは、以下の書式に従う(正式 な定義はセクション9.2を参照)。 "inline:" ["|" lifetime] ["|" MKI ":" length] key||salt マスターキーとマスターソルトを連結、base64エンコー ディング([RFC3548]、セクション3) lifetime マスターキーの有効期限(このマスターキーを使用す るSRTPまたはSRTCPパケットの最大数) MKI:length SRTPパケットのMKIとMKIフィールドの長さ 以下の定義は、AES_CM_128_HMAC_SHA1_80の一例である。 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4 パラメータの最初のフィールド (「d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj」)は、暗号化マスターキー にマスターソルトを付加したものである。これら2つを連結してから、base64 エンコーディングされる。連結したキーとソルトの長さは、キーを適用する crypto-suiteによって決まる。(base64からデコーディングした後の)長さが、 crypto-suite用に指定された値と一致しない場合、当該のcrypto属性は無効 と見なさなければならない[MUST]。各マスターキーおよびマスターソルトは 暗号的にランダム数にしなければならない[MUST]。また、そのSDPメッセージ 全体で一意にしなければならない[MUST]。キーとソルトをbase64デコーディ ングする場合、パディング文字(つまりbase64エンコーディング済みデータの 末尾に付く1つまたは2つの「=」)は破棄される(詳細については[RFC3548]参 照)。 base64エンコーディングでは、base64エンコーディングの入力が整数のオク テットであると仮定する。あるcrypto-suiteが、整数のオクテットではない 長さを持つキーとソルトの連結値を使用することを必須とする場合、その crypto-suiteは、base64入力が整数のオクテットになるようなパディングス キームを定義しなければならない[MUST]。たとえば、定義されている長さが 250ビットの場合、6パディングビットが必要である。これは、256ビットの入 力で末尾の6ビットになるように定義することができる。 2番目のフィールドは、マスターキーを使用するSRTPまたはSRTCPパケットの 最大数で測定される、マスターキーのオプション[OPTIONAL]の有効期限であ る。有効期限値は、ゼロ以外の10進で正の整数、または2の累乗として記述し てもよい(詳細についてはセクション9.2の文法を参照のこと)。先頭にゼロを 使用してはならない[MUST NOT]。「lifetime」値は、crypto-suiteの最大パ ケット有効期限を超えてはならない[MUST NOT]。有効期限が大きすぎる場合、 または無効な場合、crypto属性全体を無効と見なさなければならない[MUST]。 lifetimeを省略することで、暗黙的にデフォルト値をシグナリングしてもよ い[MAY] (lifetimeフィールドにはコロンを含めてはならないが、3番目の Andreasen, et al. Standards Track [Page 14] RFC 4568 SDP Security Descriptions July 2006 フィールドは常にコロンを含むことに注意)。これは、SRTP暗号化キーの有効 期限がデフォルト値の場合に便利である。長い10進値を回避するショート カットとして、有効期限の構文では、リテラル「2^」を使用することができ る。これは、「2の累乗」を示す。 上記の例は、有効期限が2^20と指定されている場合である。以下の例は、 AES_CM_128_HMAC_SHA1_80のcrypto-suiteで、lifetimeフィールドのデフォル トがある場合である。つまり、SRTPおよびSRTCPのデフォルト値が使用される ([RFC3711]参照)。 inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2|1066:4 この例は、base64エンコーディングされる30オクテットのキーと連結された ソルトである。30オクテットのキー/ソルトの連結は、base64の3/4エンコー ディングによって40文字(オクテット)まで拡張される。 3番目のフィールドは、オプション[OPTIONAL]であり、マスターキー識別子 (MKI)とそのバイト長である。 「MKI」はSRTPマスターキーに関連付けられているマスターキー識別子である。 本文書では、MKIを、実際のSRTPパケットのビッグエンディアン整数としてエ ンコーディングされる10進の正の整数と定義している。整数表記の先頭にゼ ロを使用してはならない[MUST NOT]。MKIを指定する場合、MKIの長さも指定 し、コロン(「:」)でMKIと区別しなければならない[MUST]。MKIの長さは、 SRTPパケットのMKIフィールドのサイズであり、10進整数としてバイト単位で 指定される。 先頭にゼロを使用してはならない[MUST NOT]。MKIの長さが指定されない場合、 またはその値が128 (バイト)を超える場合、crypto属性全体を無効と見なさ なければならない[MUST]。最初の例のサブ文字列「1:4」は、キーに1のマス ターキー識別子(4バイト長)を割り当て、2バン名の例では、1066の4バイトマ スターキー識別子をキーに割り当てる。MKIに関連付けられた1つまたは複数 のマスターキーを最初に定義してから、後で更新したり、削除して新しい キーを定義することができる。 SRTPは、「From」と「To」という2つの値に関して、マスターキーの有効期限 を指定する2つ目の機能を提供している。これら2つの値はSRTPシーケンス番 号空間[RFC3711]に基づいて定義されている。ただし、AESマスターキーの有 効期限は2^48 SRTPパケットの有効期限なので、このSRTPセキュリティ記述仕 様は<"From", "To">機能に対応していない。つまり、実用的なポイント トゥーポイントアプリケーションのマスターキーを置き換えるような暗号上 の理由はない。そのため、キーの更新をシグナリングするために2つの手法に 対応する必要はない。本仕様は、<"From", "To">を必要とする非常にわずか なアプリケーションのために、<"From", "To">ではなくMKIを選択した。それ は、MKI機能の方が単純なためである(ただし、MKIは付加的なバイトを各パ ケットに追加するが、<"From", "To">は追加しない)。 Andreasen, et al. Standards Track [Page 15] RFC 4568 SDP Security Descriptions July 2006 前述のように、keyパラメータには1つまたは複数のマスターキーを含めるこ とができる。keyパラメータに複数のマスターキーを含める場合、そのkeyパ ラメータのすべてのマスターキーにはMKI値を含めなければならない[MUST]。 MKIを使用する場合、MKIの長さは、そのcrypto属性のすべてのキーの長さと 同じにしなければならない[MUST]。 6.2. crypto-suite SRTPのcrypto-suiteは、SRTPメディアストリームに使用する暗号化と認証の 変換を定義している。SRTP仕様は3つのcrypto-suiteを定義した。各 crypto-suiteの詳細については、SRTPセキュリティ記述を説明するサブセク ションで後述する。以下の表は、crypto-suiteとそのパラメータの概要であ る。 +---------------------+-------------+--------------+---------------+ | |AES_CM_128_ | AES_CM_128_ | F8_128_ | | |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 | +---------------------+-------------+--------------+---------------+ | Master key length | 128 bits | 128 bits | 128 bits | | Master salt length | 112 bits | 112 bits | 112 bits | | SRTP lifetime | 2^48 packets| 2^48 packets | 2^48 packets | | SRTCP lifetime | 2^31 packets| 2^31 packets | 2^31 packets | | Cipher | AES Counter | AES Counter | AES F8 Mode | | | Mode | Mode | | | Encryption key | 128 bits | 128 bits | 128 bits | | MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 | | SRTP auth. tag | 80 bits | 32 bits | 80 bits | | SRTCP auth. tag | 80 bits | 80 bits | 80 bits | | SRTP auth. key len. | 160 bits | 160 bits | 160 bits | | SRTCP auth. key len.| 160 bits | 160 bits | 160 bits | +---------------------+-------------+--------------+---------------+ 6.2.1. AES_CM_128_HMAC_SHA1_80 AES_CM_128_HMAC_SHA1_80は、SRTPのデフォルトのAES Counter Mode暗号およ びHMAC-SHA1メッセージ認証(80ビット認証タグ付き)である。マスターキーの 長さは128ビットであり、デフォルトの有効期限は、最高の2^48 SRTPパケッ トまたは2^31 SRTCPパケットである(どちらか先に来る方)[ページ39、srtp]。 SRTPは、2^48 SRTPパケットまたは2^31 SRTCPパケット(どちらか先に来る 方)を許容している。ただし、自動的なキー管理によって、現在のメディ アレートに与えられている2^31パケットよりもはるかに短い間隔、または HDTVメディアレートと同じ間隔で、再キーイングを簡易かつ効率的にする ことが推奨される[RECOMMENDED]。 Andreasen, et al. Standards Track [Page 16] RFC 4568 SDP Security Descriptions July 2006 SRTPおよびSRTCPの暗号化キーの長さは128ビットである。SRTPおよびRTCP認 証キーの長さは160ビットである(セクション8「セキュリティの考慮事項」参 照)。マスターソルト値の長さは112ビットであり、セッションソルト値の長 さは112ビットである。この疑似ランダム関数(PRF)は、12ビット長のキー付 きAES Counter Modeを使用するデフォルトのSRTP疑似ランダム関数である。 このcrypto-suiteのbase64デコーディングされたキーとソルト値の長さは30 文字(つまり、240ビット)にしなければならない[MUST]。それ以外の長さの場 合、crypto属性は無効と見なされる。 6.2.2. AES_CM_128_HMAC_SHA1_32 このcrypto-suiteは、認証タグが32ビットであるという点を除き、 AES_CM_128_HMAC_SHA1_80と同じである。 このcrypto-suiteのbase64デコーディングされたキーとソルト値の長さは30 オクテット(つまり、240ビット)にしなければならない[MUST]。それ以外の長 さの場合、crypto属性は無効と見なされる。 6.2.3. F8_128_HMAC_SHA1_80 このcrypto-suiteは、暗号がF8 [RFC3711]であるという点を除き、 AES_CM_128_HMAC_SHA1_80と同じである。 このcrypto-suiteのbase64デコーディングされたキーとソルト値の長さは30 オクテット(つまり、240ビット)にしなければならない[MUST]。それ以外の長 さの場合、crypto属性は無効と見なされる。 6.2.4. 新しいcrypto-suite定義の追加 新しい変換をSRTPに追加する場合、SRTPセキュリティ記述に合わせてその変 換の新しい定義を加え、標準化過程のRFCで発行すべきである[SHOULD]。セク ション6.2.1〜6.2.3で、詳しい暗号変換のcrypto-suite値を定義する方法に ついて説明する。新しいcrypto-suiteは、セクション10の手順に従って、 IANAに登録しなければならない[MUST]。 6.3. セッションパラメータ SRTPセキュリティ記述は、「セッション」パラメータのセットを定義する。 これらのパラメータは、SRTPおよびSRTCPストリームについて、SRTPセッショ ンのデフォルト値を上書きするためにオプション[OPTIONALLY]で使用するこ とができる。これらのパラメータは、SRTPサービス用にRTPセッションを設定 する。セッションパラメータは、セッション固有の情報を提供してSRTP暗号 化のコンテキストを確立する。 Andreasen, et al. Standards Track [Page 17] RFC 4568 SDP Security Descriptions July 2006 6.3.1. KDR=n KDRは、[RFC3711]のセクション4.3.1に従って、キー導出レート(Key Derivation Rate)を指定する。 値nは、集合{1,2,...,24}の10進の整数でなければならない[MUST]。これは、 2^1以上2^24以下の2の累乗を意味する。先頭にゼロを使用してはならない [MUST NOT]。SRTPキー導出レートは、宣言に指定されたSRTPマスターキー(複 数もあり) [RFC3711]から新しいセッションキーを導出する頻度を制御する。 キー導出レートが指定されていない場合(つまりKDRパラメータが省略された 場合)、最初のキー導出が実行される[RFC3711]。 オファー/アンサーモデルの場合、KDRはdeclarativeパラメータである。 6.3.2. UNENCRYPTED_SRTCPとUNENCRYPTED_SRTP デフォルトで、SRTPとSRTCPパケットのペイロードは暗号化される。 UNENCRYPTED_SRTCPおよびUNENCRYPTED_SRTPセッションパラメータは、併用す るcrypto-suiteのデフォルト動作を変更する。 * UNENCRYPTED_SRTCPは、SRTCPパケットのペイロードを暗号化しないよう にシグナリングする。 * UNENCRYPTED_SRTPは、SRTPパケットのペイロードを暗号化しないように シグナリングする。 オファー/アンサーモデルの場合、これらのパラメータはネゴシエートされる。 そのセッションでUNENCRYPTED_SRTCPがシグナリングされた場合、すべての SRTCPメッセージでSRTCP Eビットをクリア(0)しなければならない[MUST]。デ フォルトを使用する場合、すべてのSRTCPメッセージを暗号化する。さらにす べてのSRTCPメッセージでEビットを設定(1)しなければならない[MUST]。 6.3.3. UNAUTHENTICATED_SRTP デフォルトで、SRTPとSRTCPパケットのペイロードは認証される。 UNAUTHENTICATED_SRTPセッションパラメータは、SRTPメッセージが認証され ないことをシグナリングする。UNAUTHENTICATED_SRTPの使用は推奨されない [NOT RECOMMENDED](「セキュリティの考慮事項」参照)。 SRTP仕様ではSRTCPにメッセージ認証を使用することを必須としているが、 SRTPは必須ではない[RFC3711]。 オファー/アンサーモデルの場合、このパラメータはネゴシエートされる。 Andreasen, et al. Standards Track [Page 18] RFC 4568 SDP Security Descriptions July 2006 6.3.4. FEC_ORDER=order FEC_ORDERは、RTPパケットの回送エラー修正の使用をシグナリングする [RFC2733]。「order」の回送エラー修正値はFEC_SRTPまたはSRTP_FECである。 FEC_SRTPは、SRTPメディアの送信者によるSRTP処理前、かつSRTPメディアの 受信者によるSRTP処理後に、FECが適用されることをシグナリングする。 FEC_SRTPがデフォルトである。SRTP_FECは逆の処理である。 オファー/アンサーモデルの場合、FEC_ORDERはdeclarativeパラメータである。 6.3.5. FEC_KEY=key-params FEC_KEYは、回送エラー修正(Forward Error Correction/FEC)ストリームの個 別のマスターキー(複数もあり)の使用をシグナリングする。マスターキーは、 セクション6.1に定義されているSRTP keyパラメータとまったく同じ書式で指 定する。また、構文規則も同じである。具体的には、マスターキーは、SDPに 含まれる他のマスターキーすべてと異なるようにしなければならない[MUST]。 たとえばRFC 2733のセクション11.1のように、適用するメディアストリーム (つまり、「m=」行)とは異なるIPアドレスやポートにFECストリームを送信す る場合は、FEC_KEYを指定しなければならない[MUST]。 適用するメディアストリームと同じIPアドレスかつポートにFECストリームを 送信する場合、FEC_KEYを指定してはならない[MUST NOT]。 後者の場合にFEC_KEYが指定された場合、当該のcrypto属性を無効と見なさな ければならない[MUST]。 オファー/アンサーモデルの場合、FEC_KEYはdeclarativeパラメータである。 6.3.6. ウィンドウサイズヒント(Window Size Hint/WSH) SRTPは、リプレイ攻撃から保護するために、SRTP-WINDOW-SIZE [RFC3711のセ クション3.3.2]パラメータを定義する。最小値は64 [RFC3711]だが、アプリ ケーションによっては(ビデオなど)、この値は低すぎると考えられる。 ウィンドウサイズヒント(Window Size Hint/WSH)セッションパラメータは、 (たとえば、パケット数/秒に関する送信者の情報に基づいて)適切に動作する ために必要なウィンドウサイズのヒントを提供する。ただし、 「a=maxprate」[maxprate]や帯域幅修飾子など、受信者がパラメータを適切 に導出できる十分な情報がSDP属性に指定されている可能性がある。結果とし て、この値はSDP受信者に対する単なるヒントとして見なされるため、この提 示された値は無視してもよい[MAY]。この値は10進の整数である。 先頭にゼロを使用してはならない[MUST NOT]。 オファー/アンサーモデルの場合、WSHはdeclarativeパラメータである。 Andreasen, et al. Standards Track [Page 19] RFC 4568 SDP Security Descriptions July 2006 6.3.7. 新しいSRTPセッションパラメータの定義 SRTPセキュリティ記述の新しいSRTPセッションパラメータは、セクション10 に定義されている登録手順に従って、標準化過程のRFCで定義し、IANAに登録 することができる。 新しいSRTPセッションパラメータはデフォルトで必須である。ただし、新し く定義されたSRTPパラメータの先頭にダッシュ文字(「-」)を付いている場合、 オプションと扱われるため、無視してもよい[MAY]。 「-」文字が先頭に付いていない不明なセッションパラメータが指定された SDP crypto属性を受信した場合、そのcrypto属性は無効と見なさなければな らない[MUST]。 6.4. SRTP cryptoコンテキストの初期化 これまでに定義した多様なSRTPパラメータの他に、デフォルトのSRTP暗号の 操作に不可欠な情報が3つある。 * SSRC: 同期ソース * ROC: そのSSRCのロールオーバーカウンタ * SEQ: そのSSRCのシーケンス番号 ユニキャストセッションの場合、本文書で定義しているように、上記の値に は3つの制限がある。 最初の制限はSSRCに関するもので、SRTPキーストリームを他の参加者と区別 して一意にすることである。SRTPで説明されているように、複数のプレーン テキストにキーストリームを再利用してはならない[MUST NOT]。 キーストリームを再利用すると、暗号解読に対して脆弱な暗号文になる。 脆弱性の例を挙げると、あるストリームで既知のプレーンテキストフィール ドがある場合、再利用されたキーストリームの部分が露呈する可能性があり、 結果として、他のストリームのプレーンテキストも露呈する可能性がある。 現在のSRTP暗号化変換はいずれもキーストリームを使用しているため、キー の共有は全般的な問題である[RFC3711]。SRTPは、キーストリームに送信者の SSRCを含めることで、この問題を緩和している。ただし、全体としては、 SRTPでこの問題は解決しない。というのも、リアルタイムトランスポートプ ロトコルにはSSRCの衝突があるためである(この可能性は非常に稀[RFC 3550] ではある)。 衝突の場合、マスターキーを共有する複数のSSRCが、RTPシーケンス番号空間 の重複する部分について同じキーストリームを持つことになる。SRTPセキュ リティ記述は、セキュリティ記述の送信者および受信者に対してマスター キーを一意にすることを必須[REQUIRED]にして、でキーストリームの再利用 を回避している。この結果、第1の制限は満たされる。 また、SSRCの衝突には第2の問題があることにも注意。cryptoコンテキス トを識別し、そこから暗号、キー、ROCなどを識別することで、受信パ ケットを処理するために、SSRCは使用される。SSRCの衝突が発生した場合、 Andreasen, et al. Standards Track [Page 20] RFC 4568 SDP Security Descriptions July 2006 cryptoコンテキストの識別があいまいになり、正しいパケット処理が実行 されない可能性がある。さらに、RTCP BYEパケットを衝突しているSSRCに 送信する場合、状況によってはそのパケットのセキュリティも保護する必 要がある。(ユニキャストの)1地点対多地点の場合、これは同じ理由で問 題になる可能性がある(つまり、使用する可能性があるcryptoコンテキス トが不明)。これはSDPセキュリティ記述に固有の問題ではない点に注意。 SRTPのすべての用法はこれ らの問題を考慮する必要がある。 第2の制限は、各SSRCがパケットの送信を開始するときに、ROCをゼロにしな ければならない[MUST]ことである。したがって、SRTPセキュリティ記述には、 「遅れてくる参加者(late joiner)」という概念はない。SRTPセキュリティ記 述はユニキャストの1対(pairwise)であると制限されている。ROCとSEQは、デ フォルトのSRTP変換に含まれる「パケットインデックス」を構成する。また、 本文書に従って、セッションの開始時にROCは必ずゼロに設定される。 第3の制限は、SEQの初期値は、0..2^15-1の範囲内で選択すべきである [SHOULD]ということである。これによって、セッションの開始時にパケット が失われた場合のあいまいさを回避することができる。セッションの開始時 の場合、SSRCソースは、高いシーケンス番号値をランダムに選択し、受信者 をあいまいな状況に置く可能性がある。 シーケンス番号がラップする(つまり、2^16-1を超える)時点まで、伝送中の 初期パケットが失われた場合、受信者は、ROCをインクリメントする必要があ ると認識しない可能性がある。最初のSEQを0..2^15-1の範囲に制限すること で、SRTPパケットインデックスの決定によって、正しいROC値が見つかる。た だし、最初の2^15パケットすべてが失われた場合は除く(これは不可能ではな いにしても、可能性が低いと考えられる)。パケットインデックスの決定につ いては、SRTP仕様のセクション3.3.1を参照のこと[RFC3711]。 6.4.1. 1つまたは複数のSSRCのcryptoコンテキストへのレイトバインディング パケットインデックスは、SSRC、受信パケットのSEQ、およびROC (SRTP cryptoコンテキストの変数)に依存している。したがって、セキュリティ上、 SRTPはSSRCの一意性に大きく依存している。 前述の制限を前提とすると、SRTPセキュリティ記述でSSRC値をネゴシエート しなくても、ユニキャストSRTP cryptoコンテキストを確立することができる。 ただし、本仕様ではその代わりに「レイトバインディング(late binding)」 というアプローチを推奨する[RECOMMENDED]。パケットを受信した場合、セッ ションのシグナリング時(つまり、SRTPの受信時)ではなくセッション開始時 に、パケットに含まれるSSRCをcryptoコンテキストにバインドすることがで きる。SSRCを含むパケットを受信した場合、SRTP cryptoコンテキストに必要 なすべてのデータ項目を受信者が持つことなる(定義によってROC値はゼロで あることに注意。ゼロ以外の値に対応する場合、追加のシグナリングが必要 Andreasen, et al. Standards Track [Page 21] RFC 4568 SDP Security Descriptions July 2006 である)。言い換えると、レイトバインディングを使用するセキュアRTPセッ ションの場合、cryptoコンテキストは最初に以下のようにSDPで示される。 <*, address, port> 「*」はワイルドカードのSSRC、「address」は「c=」行のローカル受信アド レス、「port」は「m=」行のローカル受信ポートである。SSRCフィールドに ssrcXが指定された最初のパケットを受信した場合、以下のcryptoコンテキス ト は、以下の制限に従ってインスタンス化される。 * メディアパケットは認証される。認証は成功しなければならない[MUST]。 それ以外の場合、cryptoコンテキストはインスタンス化されない。 * メディアパケットは認証されない。cryptoコンテキストは自動的にイン スタンス化される。 SRTPメディアパケットの認証がない場合にレイトバインディングを使用する と、多数の攻撃を受けやすくなることに注意。したがって、これは推奨され ない[NOT RECOMMENDED] (当然ながら、認証されないSRTP全般にこの問題は該 当する)。 認証なしでレイトバインディングを使用すると、不明なSSRCからパケット を受信してローカルステートが作成される結果になることに注意。つまり、 DoS攻撃を受けやすくなるため、UNAUTHENTICATED_SRTPは推奨されない [NOT RECOMMENDED]。対照的に、認証を使用したレイトバインディングの 場合、このような弱点に苦しむことはない。 6.4.2. 複数のセッションまたはSSRCでの暗号コンテキストの共有 前述の制限および手順を使用する場合、ユニキャストRTPセッションでSSRC、 ROC、およびSEQを明示的にシグナリングする必要はない。そのため、SSRC、 ROC、またはSEQをシグナリングするためのa=cryptoパラメータはない。した がって、レイトバインディングを使用する場合、同じエンティティからの複 数のSSRCはa=cryptoパラメータを共有する。複数のソース(マイク、カメラな ど)があるため、または同じセッション内でSSRCの多重化を必要とするRTPペ イロードがあるために、同じエンティティから複数のSSRCが発生する。また、 SDPも、複数のRTPセッションが同じメディア記述(「m=」)に定義されること を許容している。これらのRTPセッションも、「a=crypto」パラメータを共有 する。このようにa=cryptoを使用するアプリケーションは、RTPセッションま たはSSRC感でマスターキーを連続して共有する。また、このようなアプリ ケーションは、すべてのSSRCのパケット合計が2^31パケットに達した場合、 マスターキーを置換しなければならない[MUST]。マスターキーを共有する SSRCは、他と区別して一意にしなければならない[MUST]。 Andreasen, et al. Standards Track [Page 22] RFC 4568 SDP Security Descriptions July 2006 6.5. cryptoコンテキストの削除 これまでに定義したメカニズムは、cryptoコンテキストを作成する際の問題 に対処している。ただし、実際には、セッションを終了する前に、セッショ ンの参加者がcryptoコンテキストを削除したい場合がある。cryptoコンテキ ストに、自動的に回復ではない情報(ROCなど)が含まれる場合、「コンテキス トを削除してもよい」場合と、おそらくさらに重要な「コンテキストを削除 してはならない」場合について、送信者と受信者が合意することが重要であ る。 ユニキャストストリームにレイトバインディングを使用する場合でも、 cryptoコンテキストが削除されると、ROCが失われ、自動的に削除できな い(ゼロの場合は除く)。 この問題は以下のように解決する。SRTPセキュリティ記述を使用している場 合、crypto-contextの削除は、メンバーテーブルからSSRCを削除する場合 [RFC3550]と同じ規則に従わなければならない[MUST]。この状況は、SRTCP BYEパケットの結果、または非アクティブによる単純なタイムアウトの結果と して発生する可能性がある点に注意。cryptoコンテキストがタイムアウトし ないように確保したい非アクティブなセッション参加者は、定期的にSRTCPパ ケットを送信しなければならない[MUST]。 7. crypto属性のSRTP固有の用法 セクション5では、crypto属性の一般的な用法について説明した。このセク ションでは、SRTP固有の用法を説明する。 7.1. オファー/アンサーとの併用 このセクションでは、SRTPセキュリティ記述をオファー/アンサーモデルと併 用して、暗号機能をネゴシエートし、SRTPマスターキーを通信する方法につ いて説明する。以下に定義する規則は、特記がない限り、セクション5.1に定 義されている一般的なオファー/アンサー規則の補足である(セクション5.1の 規則には従わなければならない[MUST])。以下の規則では、ユニキャスト操作 のみを定義している点に注意。マスターキーおよび多地点間ユニキャストス トリームについては今後の研究が必要である。 7.1.1. 最初のオファーを生成する - ユニキャストストリーム 最初のオファーを生成するとき、オファー側は、セクション5.1.1の手順と、 以下の手順に従わなければならない[MUST]。 オファー側が暗号パラメータを指定したい場合、セキュアRTPトランスポート を使用する核ユニキャストメディア行(m=)について、オファー側は、セク ション6の定義に従い、有効なSRTPセキュリティ記述を1つ以上提示しなけれ Andreasen, et al. Standards Track [Page 23] RFC 4568 SDP Security Descriptions July 2006 ばならない[MUST]。メディアストリームに、メディアストリーム自体とは異 なるIPアドレスやポートが指定された回送エラー修正が含まれる場合、セク ション6.3.5に従って、FEC_KEYパラメータを含めなければならない[MUST]。 inlineパラメータは、エンドポイントが送信するSRTPおよびSRTCPストリーム を暗号化するために使用する、SRTPマスターキーを伝達する。 受信者は同じキーを使用してそのストリームを復号する。 ただし、受信者は、セッションに送信するSRTPまたはSRTCPパケットに同じ キーを使用してはならない[MUST NOT]。なぜなら、異なるSRTPストリームに マスターキーを再利用すると、デフォルトのSRTP暗号およびモードが安全で はなくなるためである。 オファー側は、セクション6.3の定義に従って、他のSRTPセッションパラメー タを1つまたは複数含めてもよい[MAY]。ただし、アンサー側は認識していな いが必須のSRTPセッションパラメータを含めた場合(セクション6.3.6参照)、 アンサー側がそれらのパラメータに対応していなければネゴシエーションは 失敗する。 7.1.2. 最初のアンサーを生成する - ユニキャストストリーム 最初のアンサーを生成するとき、アンサー側は、セクション5.1.2の手順と、 以下の手順に従わなければならない[MUST]。 セキュアRTPトランスポートを使用し、オファーに1行または複数行の 「a=crypto」を含むユニキャストメディア行ごとに、アンサー側はそのメ ディアストリームのcrypto行の1つのみを受け入れなければならない[MUST]。 または、そのメディアストリームを拒否しなければならない[MUST]。セク ション6に定義されているように、有効なSRTPセキュリティ記述と見なされる 「a=crypto」行のみを受け入れることができる。さらに、オファーしたメ ディアストリームが受け入れられるようにするには、アンサー側がすべての パラメータ(crypto-suite、keyパラメータ、必須のセッションパラメータ)を 受け入れられるようにしなければならない[MUST]。メディアストリームに、 メディアストリーム自体とは異なるIPアドレスやポートが指定された回送エ ラー修正が含まれる場合、セクション6.3.5に従って、FEC_KEYパラメータを 含めなければならない[MUST]。 アンサー側は、crypto行を含むSRTPユニキャストメディアストリームを受け 入れる場合、選択したcrypto属性に適したマスターキーを1つまたは複数含め なければならない[MUST]。アンサーに含めるマスターキーは、オファーと違 うものにしなければならない[MUST]。 マスターキーをオファー側とアンサー側で共有しない場合、オファー側と アンサー側間のSSRCの衝突は、キーストリームの再利用を引き起こさない。 さらに、SSRCの衝突を回避する必要がなくなる。 Andreasen, et al. Standards Track [Page 24] RFC 4568 SDP Security Descriptions July 2006 別のIPアドレスやポートに対する回送エラー修正が含まれる場合、アンサー には、セクション6.3.5に従ってFEC_KEYパラメータを含めなければならない [MUST]。 通常通り、declarativeセッションパラメータはアンサーに追加することがで きる。ただし、アンサー側は、オファー側が認識できない可能性がある必須 のセッションパラメータ(セクション6.3.6参照)を追加すべきではない [SHOULD NOT]。 アンサー側は、対応可能で有効なcrypto行を見つけられない場合、または設 定済みのポリシーによって任意の暗号キーパラメータ(たとえば、キーの長 さ)または暗号セッションパラメータ(たとえば、KDR、FEC_ORDER)が禁じられ ている場合、そのメディアストリームを拒否しなければならない[MUST] (た だし、本文書の範囲外の手段でSRTPの使用を正常にネゴシエートできる場合 は除く)。 7.1.3. 最初のアンサーを処理する - ユニキャストストリーム オファー側がアンサーを受信した場合、1行または複数行のcryptoを含めてオ ファーした各SRTPメディアストリームについて、セクション5.1.3の手順と以 下の手順を実行しなければならない[MUST]。 メディアストリームが受け入れられ、crypto行が含まれる場合、セクション6 に規定されている制限に従って、crypto行が有効であることをチェックしな ければならない[MUST](FECの制限を含む)。 オファー側が、アンサーに含まれるSRTPパラメータの1つまたは複数に対応し ていないか、支持したくない場合、オファー側は、そのcrypto行を無効と見 なさなければならない[MUST]。 crypto属性行が有効ではない場合、またはオファー側が任意の暗号キーパラ メータ(たとえば、キーの長さ)または暗号セッションパラメータを禁じるポ リシーを設定した場合、SRTPのセキュリティネゴシエーションは失敗と見な さなければならない[MUST]。 7.1.4. セッションの修正 SRTPセキュリティ記述を使用するメディアストリームが確立され、新しいオ ファー/アンサー交換が実行される場合、オファー側とアンサー側は、セク ション5.1.4の手順と以下の手順に従わなければならない[MUST]。 セッションを修正する場合、SRTPメディアストリームについてネゴシエート されたすべての側面が修正される可能性がある。たとえば、新しい crypto-suiteが使用されたり、新しいマスターキーが確立する可能性がある。 RFC 3264に記載されているように、新しいオファー/アンサー交換が実行され る場合、新旧両方のオファー/アンサー交換に従って、オファー側とアンサー 側がメディアの受信を準備する必要がある時間のウィンドウが存在する。 Andreasen, et al. Standards Track [Page 25] RFC 4568 SDP Security Descriptions July 2006 この要件がこのセクションにも適用される。ただし、以下の点に注意が必要 である。 * 認証が使用されていない場合、あるパケットが古いオファー/アンサー交 換と新しいオファー/アンサー交換のどちらに従って暗号化されているか について、オファー側またはアンサー側が判断できない可能性がある。 RFC 3264は、この問題に対処するためにいくつかの技術を定義している。 たとえば、使用するペイロードタイプやトランスポートアドレスを変更す る方法である。 ただし、トランスポートアドレスの変更は、サービス品質だけでなく、 ファイアウォールやNATトラバーサルにも影響が及ぶ可能性がある点に注 意。SRTPセキュリティ記述は、セクション6.1に従い、MKIを使用して、こ の問題に対処している(この処理で各SRTPパケットに数バイトが付加され る)。MKIの詳細については、[RFC3711]を参照のこと。 * アンサー側がマスターキーを変更すると、オファー側はアンサーを受信 するまで、このマスターキーによって保護されているパケットを処理でき なくなる。この問題は、セキュリティの「前提条件(precondition)」 [sprecon]を使用して対処できる可能性がある。 オファー側が、メディアストリーム(またはFECストリーム)のために以前に使 用したものとは異なるIPアドレスやポートを含めた場合、オファー側は、オ ファーに新しいマスターキーを含めなければならない[MUST](また、この処理 で、ROCがゼロに設定された新しいcryptoコンテキストが作成される)。 同様に、アンサー側が、メディアストリーム(またはFECストリーム)のために 以前に使用したものとは異なるIPアドレスやポートを含めた場合、アンサー 側は、新しいマスターキーをアンサーに含めなければならない[MUST](また、 ROCがゼロに設定された新しいcryptoコンテキストを作成しなければならな い)。この処理の理由は、アンサー側がオファーを受信するとき、またはオ ファー側が更新されたIPアドレス/ポートを含むアンサーを受信するとき、相 手側が古いcryptoコンテキストパラメータ(特にROCの場合)にアクセス権を 持っているかどうかを判断することは不可能である。たとえば、一方が分解 メディアゲートウェイ(decomposed media gateway)の場合、またはSIPバック トゥーバックユーザーエージェントが関与している場合、メディアのエンド ポイントが変化したために、古いcryptoコンテキストへのアクセス権がなく なる可能性がある。この場合、新しいマスターキーを常に必須とすることで、 アンサー側/オファー側は、そのオファー/アンサーのROCがゼロであり、(自 明だが)キーの有効期限制限も満たされることを認識する。もう1つの考慮事 項はメディアのリレーに適用される。リレーによって一方のメディアエンド ポイントが変化し、それがもう一方には知られない場合、単一のパケット反 射処理ではリレーを操作できないが、SRTPパケット処理および変換(つまり、 復号や再暗号化など)に積極的に従事する必要がある。 最後に、新しいオファーを拒否する場合、古いcryptoパラメータの配置を残 すことに注意。 Andreasen, et al. Standards Track [Page 26] RFC 4568 SDP Security Descriptions July 2006 7.1.5. オファー/アンサーの例 この例では、オファー側が2つのcrypto-suiteに対応している(f8とAES)。 「a=crypto」行は実際には長い1行だが、本文書ではページの書式に合わせて 2行にしている。f8の例は、2つのinlineパラメータを示している。セクショ ン6.1で説明したように、crypto属性には1つまたは複数のkeyパラメータ(つ まりinline)を指定してもよい。 このように、複数をキーをオファーして、マスターキー識別子(MKI)を使用す るキーローテーションに対応する。 オファー側の送信内容: v=0 o=sam 2890844526 2890842807 IN IP4 10.47.16.5 s=SRTP Discussion i=A discussion of Secure RTP u=http://www.example.com/seminars/srtp.pdf e=marge@example.com (Marge Simpson) c=IN IP4 168.2.17.12 t=2873397496 2873404696 m=audio 49170 RTP/SAVP 0 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 FEC_ORDER=FEC_SRTP a=crypto:2 F8_128_HMAC_SHA1_80 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 FEC_ORDER=FEC_SRTP アンサー側の応答内容: v=0 o=jill 25690844 8070842634 IN IP4 10.47.16.5 s=SRTP Discussion i=A discussion of Secure RTP u=http://www.example.com/seminars/srtp.pdf e=homer@example.com (Homer Simpson) c=IN IP4 168.2.17.11 t=2873397526 2873405696 m=audio 32640 RTP/SAVP 0 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 この場合、セッションはRTPおよびRTCPトラフィックに AES_CM_128_HMAC_SHA1_80 crypto-suiteを使用する。アンサー側が F8_128_HMAC_SHA1_80を選択した場合、SRTP暗号コンテキストに関連付けられ たinlineキーは2つになる。1つのキーは1のMKI値で、2つ目のキーは2のMKI値 である。 Andreasen, et al. Standards Track [Page 27] RFC 4568 SDP Security Descriptions July 2006 7.2. オファー/アンサー以外のSRTP固有の用法 オファー/アンサーモデル以外のSRTPセキュリティ記述の用法は定義されてい ない。 オファー/アンサーモデル以外のSRTPセキュリティ記述の用法は、2番目の メディアストリーム用に定義されていた可能性がある。ただし、特定のメ ディアストリームの受信者がSRTPのために使用するキーを示す方法はない。 7.3. SIP分岐処理への対応 前述のように、本文書で定義しているセキュリティ記述は、マルチキャスト メディアストリームまたは多地点間ユニキャストストリームには対応してい ない。 一方、SIPプロトコルでは、分岐処理を使用した場合、単一のオファーに対し て複数のアンサーを受信する可能性がある([SIP]参照)。 SRTPセキュリティ記述の場合、複数のアンサーを受信すると、いくつかの問 題が発生する。 * アンサーによって異なる暗号、キーなどを選択する可能性がある。 ただし、オファー側が、特定の受信メディアパケットを特定のアンサーに 関連付ける方法はない。 * 複数のアンサーが同じSSRCを選択する可能性がある。結果として、前述 したSSRCの衝突問題が発生する可能性がある。 前述のように、1地点対多地点の場合は、SDPセキュリティ記述の範囲外であ る。ただし、SIPの分岐処理に対応する方法はある。たとえば、SIPの分岐処 理の結果として生じる多地点のシナリオを、複数の2パーティユニキャストの シナリオに変換する方法である。この処理は以下の手順で実行することがで きる。 最初のアンサー以外に受信した各アンサーについて、新しい受信トランス ポートアドレス(IPアドレスとポート)を使用してそのアンサー側に新しいオ ファーを発行する。この場合、SIP UPDATEメソッド[RFC3311]への対応が必要 になる点に注意。また、アンサーのいずれかがUPDATEを処理する前に、誤っ て2つのメディアセッションが確立しないように確保するには、セキュリティ の前提条件[sprecon]を使用する。 最終的に、オファーを受信したすべてのSIPユーザーエージェントは、最初の オファーで提案されたキー(複数もあり)を認識する。オファー側は、オ ファーを受信した可能性があるすべてのユーザーエージェントに関してセ キュリティを確保したい場合、新しいキーを指定した新しいオファー/アン サー交換を実行する必要がある。アンサー側も同様である。オファー側は、 オファーを受信したSIPユーザーエージェントが1つか複数かを判断できない 点に注意。これは、中間の分岐処理プロキシが、単一のアンサーのみをオ ファー側に回送する可能性があるためである。 Andreasen, et al. Standards Track [Page 28] RFC 4568 SDP Security Descriptions July 2006 上記の説明の目的は、SIPの分岐処理に対応する方法の1つを提案することで ある。省略している詳細事項が多数あるため、これを規範の仕様と見なすべ きではない。別のアプローチも可能である。 7.4. SRTP固有の下位互換性に関する考慮事項 アンサー側がSRTPトランスポートに対応していてオファーしたメディアスト リームを受け入れるが、本文書に定義されているcrypto属性に対応しない可 能性がある。オファー側は、アンサーの受け入れ済みSRTPメディアストリー ムにcrypto行が含まれないことを確認することで、この状況を認識すること ができる。この場合、ここで定義しているセキュリティネゴシエーションは 失敗したと見なさなければならない[MUST]。 また、あるSRTPトランスポート(「RTP/SAVP」など)を指定したメディアスト リームを、SRTPに対応しないデバイスに送信する場合、メディアストリーム は拒否される。 7.5. KEYMGT=行とk=行の操作 オファーには、「a=crypto」行と「a=keymgt」行[keymgt]の両方を含めても よい[MAY]。 SDPの規則に従って、アンサー側は、理解できない属性行を無視する。アン サー側が「a=crypto」と「a=keymgt」の両方に対応する場合、アンサーには 「a=crypto」または「a=keymgt」を含めなければならない[MUST](ただし、両 方を含めることは未定義なので、両方ではない)。 オファーには、「a=crypto」行と「k=」行[RFC4566]の両方を含めてもよい [MAY]。SDPの規則に従って、アンサー側は、理解できない属性行を無視する。 アンサー側が「a=crypto」と「k=」の両方に対応する場合、アンサーには 「a=crypto」または「k=」を含めなければならない[MUST](ただし、両方を含 めることは未定義なので、両方ではない)。 8. セキュリティの考慮事項 すべてのSDPメッセージと同様に、セキュリティ記述を含むSDPメッセージは、 カプセル化アプリケーションプロトコル(SIP、MGCPなど)で伝達される。SDP セキュリティ記述の保護を保証するのは、カプセル化プロトコルの責任であ る。したがって、アプリケーションは独自のセキュリティメカニズム(S/MIME [smime]などの安全なマルチパート)を呼び出すか、低レイヤーのセキュリ ティサービス(TLSやIPsecなど)を利用する必要がある[REQUIRED]。このセ キュリティサービスは、強力なメッセージ認証およびパケットペイロード暗 号化だけでなく、効率的なリプレイ保護を実施する必要がある。 「リプレイ保護」は、通信チャネルに対する十分なアクセス権を持っている ため、メッセージを傍受し、コピーを宛先に配信することができる攻撃者に 対抗するために必要である。リプレイ攻撃が成功すると、受信者は1つのメッ Andreasen, et al. Standards Track [Page 29] RFC 4568 SDP Security Descriptions July 2006 セージに対して重複の処理を実行する。だまされた受信者が重複した応答を 送信者に送信した場合、攻撃は悪化する。S/MIMEや、もう1つのセキュアマル チパート規格であるPGP/MIMEには、リプレイ保護機能がない。したがって、 S/MIMEおよびPGP/MIMEは、カプセル化アプリケーションプロトコル(SIP、 MGCP)に適切な何らかのリプレイ保護メカニズムで拡張する必要がある。リプ レイ保護を実施する一般的な方法が3つある。メッセージにシーケンス番号を 指定する方法、タイムスタンプを使用する方法、または受信者がメッセージ のハッシュを維持して、受信メッセージと比較する方法である。一般的に、 「リプレイテーブル」または一覧に前のメッセージのステート情報を維持す るには、リプレイの「ウィンドウ」や何らかのポリシーが必要である。 以下の議論では、SRTP [RFC3711]に準拠する意味で、「メッセージの認証」 および「メッセージの機密性」という語を使用する。 「メッセージの機密性」とは、秘密の復号化キーの保有者のみが、プレーン テキストのメッセージ内容にアクセスできる、という意味である。復号化 キーは、暗号化キーと同じキーであり、SRTPカウンタモードおよびf8暗号化 変換を使用する。これは、メッセージの改ざんに対して脆弱であり、改ざん を検出するにはSRTPメッセージ認証が必要である。「メッセージの認証」お よび「メッセージの完全性の検証」とは、全般的に、IETFのセキュリティ規 格に記載されているものと同じ意味である。正常なHMAC完全性チェック [RFC3711]に従って、SRTPメッセージは認証される。これによって、メッセー ジがSRTPマスターキーの保有者から送信され、配送中に変更されていないこ とを保証する。 ただし、こうした「本物の」メッセージが攻撃者にキャプチャされ、攻撃者 がそのパケットをチャネルに再挿入して「リプレイ」される可能性がある。 リプレイされたパケットは、セッションに多様な悪影響を与える可能性があ る。SRTPはリレーされたSRTPパケットを検出するために拡張したシーケンス 番号を使用している[RFC 3711]。 SRTP仕様は、規定で実装するデフォルト値(AES_CM_128_80など)と、規定で使 用するデフォルト値(AES_CM_128_32など)であるサービスおよびフィーチャー を指定する。 8.1. パケットの認証 本文書で定義しているように、セキュリティ記述はRTPパケットに関するセ キュリティサービスをシグナリングする。RTPメッセージは、リプレイや偽造 など、多様な攻撃を受けやすい。このような攻撃を制限するために、SRTPの メッセージ完全性メカニズムを使用すべきである[SHOULD](SRTPリプレイ保護 は常に有効である)。 8.2. キーストリームの再利用 SRTPセキュリティ記述は、SRTPセッションに関する設定パラメータをシグナ リングする。SRTPセッションを誤って設定すると、セッション6.2.1、6.2.2、 および6.2.3に定義されているcrypto-suiteを実行するとき、暗号化サービス Andreasen, et al. Standards Track [Page 30] RFC 4568 SDP Security Descriptions July 2006 に対する攻撃を受けやすくなる。AESブロックの同じキーストリームを使用し て複数のメディアストリームを暗号化すると、SRTP暗号化サービスは「誤設 定される」。送信者と受信者がセッションキーを導出する場合、SRTPは、 セッション参加者のSSRCによって対応するキーストリームを一意になるよう に要求する(これは、SSRCの衝突の場合には違反ではない)。SRTP SSRCが衝突 すると、同じキーストリームが使用されたときに、SRTPまたはSRTCPペイロー ド暗号化が大幅に弱くなる[RFC3711]。たとえば、攻撃者は、SRTPおよび SRTCPメッセージを収集し、衝突を待つ可能性がある。 AES-CMおよびAES-f8暗号化に対するこの攻撃は、送信方向と受信方向の両方 で、各メディアストリームに一意なマスターキーを持たせることで完全に回 避できる。本仕様は、ユニキャストのポイント間ストリームにSDPセキュリ ティ記述を使用することを制限している。これは、SRTPホスト間でキーを共 有しないため、および、あるメディアストリームの送信方向および受信方向 で使用するマスターキーが一意になるようにするためである。 8.3. 認証のシグナリングと暗号化のシグナリング ただし、SRTPキーの確立を権限を持たないパーティに公開するときに、複雑 さとSRTPの計算上の犠牲が生じるという理由はない。ほとんどの場合、SRTP のcrypto属性とそのパラメータを未認証のSDPメッセージで伝達する場合、 DoS攻撃を受けやすい。場合によっては、RTPストリームの完全性と機密性が 危うくなる可能性もある。 たとえば、攻撃者がオファーのSRTPストリームにUNENCRYPTEDを設定した場合、 アンサー側が暗号化されたSRTPメッセージを復号しない結果になる可能性が ある。最悪の場合、アンサー側は暗号化されていないSRTPを送信し、データ が傍受にさらされたままになる可能性がある。 したがって、MIMEセキュアマルチパート、IPsec、TLS、または他のデータセ キュリティサービスを使用して、crypto属性を含むSDPを伝達するカプセル化 プロトコルのメッセージ認証を実行する必要がある[REQUIRED]。さらに、マ スターキーパラメータ(inline)がメッセージに出現したときは常に、ペイ ロードのカプセル化の暗号化を使用する必要がある[REQUIRED]。inlineの SRTPマスターキーを含むSDPメッセージを暗号化できなかった場合、実質的に すべての環境で、SRTP認証または暗号化サービスは無駄になる。SRTPパラ メータを伝達するSDPメッセージを認証できない場合、実質的にほとんどの環 境で、SRTP認証または暗号化サービスは無駄になる。 SDPメッセージの通信パスが、SDPメッセージの一部を調査する中間システム を経由してルーティングされる場合、セキュリティの復号を暗号化または認 証するために、[IPsec]やTLSなどのセキュリティプロトコルを使用すべきで はない[SHOULD NOT]。SDPセキュリティ記述を含むメッセージを中間システム が処理する場合、「a=crypto」属性をエンドトゥーエンドで保護すべきであ る[SHOULD]。これは、中間システムがセキュリティ記述を修正しないためと、 キーイング要素にアクセスできないようにするためである。従って、SDPセ Andreasen, et al. Standards Track [Page 31] RFC 4568 SDP Security Descriptions July 2006 キュリティ記述を保護するには、各中間システムで終端するネットワークま たはトランスポートセキュリティプロトコルを使用すべきではない[SHOULD NOT]。セキュリティプロトコルは、中間システムが修正または調査するSDP メッセージの部分とは独立して、セキュリティ記述をエンドトゥーエンドで 暗号化および認証できるようにすべきである[SHOULD]。つまり、中間システ ムが処理するSDPメッセージを保護するために、MIMEセキュアマルチパートが 推奨される[RECOMMENDED]。 9. 文法 このセクションでは、一般的なcrypto属性のABNF文法を提示してから、 crypto属性のSRTP固有の用法を示すABNFを提示する。 9.1. 一般的な「crypto」属性の文法 crypto属性のABNF文法は以下のように定義される。 "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params *(1*WSP session-param) tag = 1*9DIGIT crypto-suite = 1*(ALPHA / DIGIT / "_") key-params = key-param *(";" key-param) key-param = key-method ":" key-info key-method = "inline" / key-method-ext key-method-ext = 1*(ALPHA / DIGIT / "_") key-info = 1*(%x21-3A / %x3C-7E) ; 可視(印刷)文字 ; セミコロンを除く session-param = 1*(VCHAR) ; 可視(印刷)文字 WSP、ALPHA、DIGIT、VCHARについては、[RFC4234]に定義されている。 9.2. SRTPの「crypto」属性の文法 このセクションでは、SDP crypto属性のSRTP固有の用法について、拡張BNF [RFC4234]文法を提示する。 crypto-suite = srtp-crypto-suite key-method = srtp-key-method key-info = srtp-key-info session-param = srtp-session-param srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / "F8_128_HMAC_SHA1_32" / Andreasen, et al. Standards Track [Page 32] RFC 4568 SDP Security Descriptions July 2006 "AES_CM_128_HMAC_SHA1_80" / srtp-crypto-suite-ext srtp-key-method = "inline" srtp-key-info = key-salt ["|" lifetime] ["|" mki] key-salt = 1*(base64) ; バイナリキーとソルト値 ; を連結してから、 ; base64エンコーディング ; [RFC3548のセクション3] lifetime = ["2^"] 1*(DIGIT) ; セクション6.1の"2^"参照 mki = mki-value ":" mki-length mki-value = 1*DIGIT mki-length = 1*3DIGIT ; 範囲1..128. srtp-session-param = kdr / "UNENCRYPTED_SRTP" / "UNENCRYPTED_SRTCP" / "UNAUTHENTICATED_SRTP" / fec-order / fec-key / wsh / srtp-session-extension kdr = "KDR=" 1*2(DIGIT) ; 範囲0..24, ; 2の累乗 fec-order = "FEC_ORDER=" fec-type fec-type = "FEC_SRTP" / "SRTP_FEC" fec-key = "FEC_KEY=" key-params wsh = "WSH=" 2*DIGIT ; 最小値は64 base64 = ALPHA / DIGIT / "+" / "/" / "=" srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_") srtp-session-extension = ["-"] 1*(VCHAR) ;可視文字[RFC4234] ; 最初の文字をダッシュ("-")にしてはなら ; ない Andreasen, et al. Standards Track [Page 33] RFC 4568 SDP Security Descriptions July 2006 10. IANA条項 10.1. 「crypto」属性の登録 IANAは、以下のように新しいSDP属性を登録した。 属性名: crypto 長い形式の名前: Security description cryptographic attribute for media streams (メディアストリーム用セキュリティ 記述暗号属性) 属性のタイプ: メディアレベル 文字セットの条件: なし 目的: セキュリティ記述 適切な値: セクション4参照 10.2. 新しいIANA登録と登録手順 以下のサブセクションでは、SDPセキュリティ記述に使用する下位登録項目に 関連する、新しいIANA登録を定義する。IANAは、下記のようにSDPのSecurity Description (セキュリティ記述)の登録項目を作成した。詳細については後 述する。 SDP Security Descriptions | +- Key Methods (described in 10.2.1) | +- Media Stream Transports (described in 10.2.2) | +- Transport1 (e.g., SRTP) | | | +- Supported Key Methods (e.g., inline) | | | +- crypto suites | | | +- session parameters | +- Transport2 : : 10.2.1. keyメソッドの登録項目と登録 IANAは、SDPセキュリティ記述のkeyメソッドについて、新しい下位登録項目 を作成した。IANAのkeyメソッド登録は、[RFC2434]の標準化行動に従って、 RFCに文書化しなければならない[MUST]。また、セクション9.1に定義されて いるkey-method-extの文法に従って、keyメソッド名を指定しなければならな い[MUST]。 Andreasen, et al. Standards Track [Page 34] RFC 4568 SDP Security Descriptions July 2006 10.2.2. メディアストリームトランスポートの登録項目と登録 IANAは、SDPセキュリティ記述のメディアストリームトランスポートについて、 新しい下位登録項目を作成した。IANAメディアストリームトランスポート登 録は、RFC 2434の標準化行動と、本文書のセクション4および5に定義されて いる手順に従ってRFCに文書化しなければならない[MUST]。登録では、トラン スポート名と、対応するkeyメソッドの一覧を提示しなければならない[MUST]。 さらに、新しい各メディアストリームトランスポートの登録には、 crypto-suite登録項目とセッションパラメータ登録項目だけでなく、それら の登録項目を設定する方法を示したIANAの指導も含めなければならない。 10.3. 初期登録 10.3.1. keyメソッド 以下のセキュリティ記述のkeyメソッドを登録する。 inline 10.3.2. SRTPメディアストリームトランスポート IANAは、「SRTP」用にSDPセキュリティ記述のメディアストリームトランス ポートの下位登録項目を作成した。対応するkeyメソッドは「inline」である。 SRTP用SDPセキュリティ記述の参考文献は本文書である。 10.3.2.1. SRTP crypto-suiteの登録項目と登録 IANAは、SDPセキュリティ記述のSRTPトランスポートの下に、SRTP crypto-suiteの下位登録項目を作成した。IANA SRTP crypto-suiteの登録で は、セクション9.2に定義されているsrtp-crypto-suite-extの文法に従って、 crypto-suite名を示さなければならない[MUST]。 SRTP crypto-suiteのセマンティクスは、「inline」keyメソッドのセマン ティクスやパラメータの特殊なセマンティクスなどについて、RFC 2434の標 準化行動に従ってRFCに記載しなければならない[MUST]。 以下のSRTP crypto-suiteが登録される。 AES_CM_128_HMAC_SHA1_80 AES_CM_128_HMAC_SHA1_32 F8_128_HMAC_SHA1_80 Andreasen, et al. Standards Track [Page 35] RFC 4568 SDP Security Descriptions July 2006 これらのcrypto-suiteの参考文献は、本文書に記載している。 10.3.2.2. SRTPセッションパラメータの登録 IANAは、SDPセキュリティ記述のSRTPトランスポートの下に、SRTPセッション パラメータの下位登録項目を作成した。IANAのセッションパラメータ登録は、 セッションパラメータ名を示さなければならない[MUST](セクション9.2の定 義に従って、srtp-session-extension)。 名前の先頭をダッシュ文字(「-」)にしてはならない[MUST NOT]。 パラメータのセマンティクスは、RFC 2434の標準化行動に従って、RFCに記載 しなければならない[MUST]。値をパラメータに割り当てる場合、RFC 2434の 標準化行動に従って、書式と割り当てることができる値もRFCに記載しなけれ ばならない[MUST]。また、オファー/アンサーモデルの場合、パラメータが declarativeかnegotiatedかを指定しなければならない[MUST]。 以下のSRTPセッションパラメータが登録される。 KDR UNENCRYPTED_SRTP UNENCRYPTED_SRTCP UNAUTHENTICATED_SRTP FEC_ORDER FEC_KEY WSH これらのパラメータの参考文献は本文書である。 11. 謝辞 本文書は、IETF MMUSICワークグループの成果であり、ワークグループの参加 者によるコメントを利用している。本文書は、Elisabetta Cararra、Earl Carter、Per Cederqvist、Bill Foster、Matt Hammer、Cullen Jennings、 Paul Kyzivat、David McGrew、Mats Naslund、Dave Oran、Jonathan Rosenberg、Dave Singer、Mike Thomas、Brian Weis、およびMagnus Westerlundとの議論も利用している。 12. 規範となる参考文献 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Andreasen, et al. Standards Track [Page 36] RFC 4568 SDP Security Descriptions July 2006 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 13. 有益な参考文献 [sprecon] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol Media Streams", Work in Progress, October 2005. [RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002. [Bellovin] Bellovin, S., "Problem Areas for the IP Security Protocols," in Proceedings of the Sixth Usenix Unix Security Symposium, pp. 1-16, San Jose, CA, July 1996. [GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [kink] Sakane, S., Kamada, K., Thomas, M. and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006. Andreasen, et al. Standards Track [Page 37] RFC 4568 SDP Security Descriptions July 2006 [ike] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [ipsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [maxprate] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004. [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999. [s/mime] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [pgp/mime] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [keymgt] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006. [mikey] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [skeme] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for the Internet", ISOC Secure Networks and Distributed Systems Symposium, San Diego, 1996. [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. Andreasen, et al. Standards Track [Page 38] RFC 4568 SDP Security Descriptions July 2006 [srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003. [RFC3261] 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. [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002. Andreasen, et al. Standards Track [Page 39] RFC 4568 SDP Security Descriptions July 2006 付録A - キーイング要素の方向性に関する論拠 SDPセキュリティ記述は、送信方向のキーイング要素を定義している。これは SDPに含まれる。したがって、SDPメッセージで伝達されるキーは、SDPメッ セージ受信者のための復号化キーである。これは、受信(または受信と送信) 方向の情報が記述されている、SDPに含まれる情報の大部分とは対照的である。 この逆転した情報の方向性は、オファー/アンサーモデルでメカニズムを使用 する際に課題となる。特に、初期メディアや分岐処理に特殊な考慮事項が必 要なSIPの場合はそうである(セクション7.3参照)。ただし、この処理を実行 するための理由はある。概要を説明する。 まず、トラフィックを送信するエンティティに、保護するために使用する キーを決定させるという、一般的なセキュリティ哲学がある。 SRTPはカウンタモードを使用する。この方法は、マスターキーを共有する送 信者間でカウンタが重複しない場合に安全である。カウンタの重複を確実に 防ぐには、各エンドポイントが独自のマスターキーを生成する方法がある。 第2に、通常のSDP情報の方向性を維持するSDPセキュリティ記述を設計した場 合、初期メディアとSIP分岐処理に対応する際に問題が発生する。オファーが 複数のアンサーを生成し、キーイング要素が受信方向用の場合、パラメータ 値の一部(lifetimeなど)をすべてのアンサー側(メディアの送信者)で共有す る必要がある。これによって、複雑さが大幅に増し、SRTPを変更または拡張 する必要が出てくる可能性がある。他の問題についても見つかった。詳細を 以下に説明する。 以下のシナリオでは、(キーイング要素が送信キーイング要素である実際の設 計ではなく)キーイング要素が受信キーイング要素であるように、SDPセキュ リティ記述を設計した場合に生じる結果について分析する。 Andreasen, et al. Standards Track [Page 40] RFC 4568 SDP Security Descriptions July 2006 シナリオA: 分岐しない場合 このシナリオでは、オファーが受信キーイング要素を含め、アンサー側が それを受信してオファー側に対してデータパケットの送信を開始する。オ ファーに1つのcrypto属性があった場合、使用されているcrypto-suiteに 関してあいまいさはないため、受信パケットを処理することができる。 ただし、オファーが複数のcrypto属性案を含めた場合、オファー側は受信 側が選択したものがわからない。オファー側がアンサーの受信前にパケッ トを受信すると、オファー側はそのパケットを処理できない(問題1)(MKI の用法は、この問題の解決案の1つとして提案されたが、パケットごとの オーバーヘッドが発生する)。 シナリオB: 連続的な分岐処理の場合 このシナリオでは、AliceがBobに対してオファーを生成する。Bobは(初 期)メディアをAliceに対して送信する(アンサーはまだ返されていない)。 このシナリオでは、シナリオAも発生していないと仮定する(たとえば、オ ファーには1つのcrypto属性のみが含まれる)。また、BobはSRTPパケット およびSRTCPパケットに1の同期ソース(SSRC)値を使用していると仮定する。 したがって、Aliceは、関連するROC (ロールオーバーカウンタ)とSEQ (RTPシーケンス番号)を含め、SSRC 1のcrypto-contextを持っている。こ の状況で、Bobは呼をCarolに回送する(Bobはまだアンサーを生成していな い)。この時点で、BobはAliceのキーを持っている。これは、セキュリ ティ上の弱点になりうる。交換が進むにつれ、Carolは、オファーされた crypto属性などの元のオファーを取得して、Aliceに対してメディアパ ケットの送信を開始する。 このとき、Carolは偶然、Bobと同様に、1のSSRC値を選択する。Carolがパ ケットの生成を開始すると、RFC 3711で「two-time pad」と呼ばれる問題 が発生する可能性がある(問題2)。それだけでなく、ROCがAliceとCarol間 のシンクから外れる可能性もある(問題3)。BobとCarolは(推定上)異なる ソーストランスポートアドレスを使用しているため、SSRCの再利用が原因 でSSRCの衝突が発生することはない(ただし、Aliceがそのように解釈する 可能性はある)。この場合、RFC 3711に従って、BobとCarol間でマスター キーを共有するため、two-time pad問題を回避するには、Aliceがその時 点でセッションから離れることが推奨される[RECOMMENDED]。RFC 3711は SRTPマスターキーの共有を推奨している点にも注意が必要である。キーイ ング要素が受信方向の場合、誤って分岐処理が発生する可能性がある。 上記のシナリオを改めて考慮し、今回は、オファー(およびアンサー)の キーイング要素が送信キーイング要素であると仮定すると、シナリオは以 下のように変わる。Bobは今回もSSRC 1を選択する。Bobはアンサーを Aliceに返信する必要がある。これは、AliceがBobの送信キーを知る必要 Andreasen, et al. Standards Track [Page 41] RFC 4568 SDP Security Descriptions July 2006 があるためである。BobはAliceに対してメディアの送信を開始する(Alice がBobのアンサーを受信するまで、省略が発生する可能性がある)。Bobは また呼をCarolに回送する。CarolはSSRC 1を使用して初期メディアの送信 を開始する。ただし、AliceがCarolのパケットを処理するには、Carolが 新しいアンサーを生成する必要がある(AliceのCarolのダイアログのため)。 このアンサーを受信すると、Aliceが新しいオファー/アンサー交換を開始 することができる(その結果、セクション7.3に従って、セッションを別の トランスポートアドレスに移動することができる)。この場合、SSRCが衝 突するかどうかに関係なく、1つのセッションにつき1つのマスターキーが あり、一意のキーストリームがある。 シナリオC: 並行分岐処理の場合 このシナリオでは、Aliceがオファーを生成し(受信キーイング要素を含 む)、そのオファーは並行してBobとCarolに分岐する。BobとCarolの両方 がAliceに対してパケット(初期メディア)の送信を開始する。BobとCarol が異なるSSRCを選択した場合、最初からすべてが問題なく動作する。 ただし、cryptoコンテキストパラメータの1つがマスターキーの有効期限 であり、BobとCarolが同じマスターキー(どちらも知らない)を共有してい るため、両者は再キー処理を実行する必要があるタイミングがわからない (問題4)。両者が同じSSRCを選択した場合も、two-time pad問題が発生す る(問題2)。 まとめると、キーイング要素が受信方向の場合、以下の問題がある。 - 問題1: オファー側は、オファーした複数のcryptoのうち、アンサー側 が選択したものがわからない。 - 問題2: 複数のアンサー側間(連続的分岐処理または並列的分岐処理) でSSRCを再利用することで、two-time pad問題が発生する可能 性がある。 - 問題3: cryptoコンテキストパラメータの一部(特にROC)は通信しれな いが導出される。また、複数のエンティティが同じSSRCを(連続 して)使用することを許容する場合、誤ったROCになる可能性が ある。 - 問題4: マスターキーを共有するすべてのcryptoコンテキストは、共有 するカウンタのセット(マスターキーの有効期限)を保守する必 要がある。また、異なるプラットフォームにいる複数のエン ティティがマスターキーを共有することを許容する場合、その カウンタを同期するメカニズムが必要である。 問題1は、MKIを別の提案として使用することで対処することができる。ただ し、各SRTPメディアパケットに追加の帯域幅を使用する結果になる。問題2を 解決するということは、アンサー側とSSRC値を同期できるようにする必要が Andreasen, et al. Standards Track [Page 42] RFC 4568 SDP Security Descriptions July 2006 あることを意味する(または、SSRCの再利用またはSSRCの衝突が発生した場合、 セッションを放棄する)。 問題3は、各SSRCベースでROC値を同期できるようにする必要があることを意 味する(または、SSRCの再利用が発生した場合、セッションを放棄する)。問 題4を解決するには、送信者からAliceへ送信された合計によって実際に生成 されたパケットをオファー側(Alice、つまりメディアを受信するエンティ ティ)に決定させ、再キー処理を開始させる。パケットロスなどの場合、これ は誰でもできる処理ではないが、適度な安全マージンを使用して、おそらく 実際に対処することができる。 まとめると、オファー/アンサーおよびSIPの観点からは、オファー(およびア ンサー)に受信キーイング要素であるキーイング要素を持たせることが期待さ れる。ただし、この対処方法は、SIPになじんだセキュリティが引き替えにな る(たとえば、two-time padやキーの有効期限の問題など)。また、複数の SRTPセッション間でSRTPマスターキーを共有するため、RFC 3711の規則に違 反する。 著者の連絡先 Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, New Jersey 08837 USA EMail: fandreas@cisco.com Mark Baugher 5510 SW Orchid Street Portland, Oregon 97219 USA EMail: mbaugher@cisco.com Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: dwing@cisco.com Andreasen, et al. Standards Track [Page 43] RFC 4568 SDP Security Descriptions July 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の原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2008年 ----------------------------------------------------------------------- Andreasen, et al. Standards Track [Page 44]