ＩＭＳシステムにおけるエンド・ツー・エッジのメディア保護のための方法および装置
ＩＭＳシステムが、ＩＭＳ開始者ユーザエンティティを有する。システムは、開始者ユーザエンティティからの呼が着信するＩＭＳ応答者ユーザエンティティを有する。システムは、発信者エンティティと通信する発側Ｓ−ＣＳＣＦを有しており、発側Ｓ−ＣＳＣＦは、発側エンティティから第１の保護提案と鍵確立のためのパラメータとを有するＩＮＶＩＴＥを受信し、第１の保護提案をＩＮＶＩＴＥから削除し、そして、第１の保護提案のないＩＮＶＩＴＥを転送する。システムは、応答者ユーザエンティティおよび発側Ｓ−ＣＳＣＦと通信する受信端Ｓ−ＣＳＣＦを有しており、受信端Ｓ−ＣＳＣＦは、第１の保護提案のないＩＮＶＩＴＥを受信し、応答者ユーザエンティティが保護をサポートすることをチェックし、第２の保護提案をＩＮＶＩＴＥに挿入し、そしてＩＮＶＩＴＥを応答者ユーザエンティティへ転送する。ここで、応答者ユーザエンティティは、第２の保護提案を有するＩＮＶＩＴＥを受け入れ、そして、第１の保護受入れを有する確認応答を使って応答する。通信ノードによって呼をサポートするための方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セッション制御招待メッセージに関するメディア保護制御に関連する。（本書では、「本発明」または「発明」への言及は、例示的な実施形態に関するものであり、必ずしも添付の請求項によって包含されるあらゆる実施形態に関するものではない。）より詳細には、本発明は、適切なメディア保護、例えば、ＩＭＳシステムにおける開始者ユーザエンティティと応答者ユーザエンティティとの間のＳＩＰ ＩＮＶＩＴＥメッセージに関するエンド・ツー・エッジのメディア保護を選択することに関する。
【背景技術】
【０００２】
本章では、本発明の各種の態様に関連しうる技術の各種の態様を読者に紹介することが意図されている。下記の議論では、本発明のよりよい理解を助ける情報を提供することが意図されている。従って、理解されるべきだが、下記の議論の中の記述は、この観点から読まれるべきであり、先行技術の承認として読まれるべきではない。
【０００３】
多くのネットワークアクセス技術（ＧＳＭ、ＷＣＤＭＡ、ＷＬＡＮ、ＷｉＭＡＸ）は、「第１のホップ」のための何らかの基本的なセキュリティを提供する。しかし、ネットワークアクセス技術がすべて十分にセキュアであるとみなしうるわけではなく、一部のアクセス（例えばＩＥＥＥ８０２．３）は組み込みセキュリティを全く提供していない。特に、固定回線のアクセスには、ユーザトラヒックの論理的な保護は通常はまったく存在せず、従って、保護は、トラヒックを搬送している物理的メディアにアクセスする難度だけに依存している。従って、「固定移動体融合」（Ｆｉｘｅｄ−Ｍｏｂｉｌｅ Ｃｏｎｖｅｒｇｅｎｃｅ：ＦＭＣ）というシナリオにおいては、少なくともＩＭＳ制御によるエンド・ツー・アクセスエッジ（ｅ２ａｅ）セキュリティ、すなわち、アクセスネットワークを横断するメディアトランスポートのためのセキュリティを提供する必要性がある。これは、多様なネットワークタイプにおいてトラヒックの均一な保護を提供できるようにするために必要なのである。ＭＭＴＥＬは、ユーザの信用を獲得するためにセキュアにされる必要があるそのようなアプリケーションの１つである。ＳＲＴＰ（ＲＦＣ３７１１）とＭＩＫＥＹ（ＲＦＣ３８３０）とは、この目的で提案されているメディアセキュリティおよび鍵管理のためのプロトコルの例である。ＩＭ、ＰｏＣおよびＰｒｅｓｅｎｃｅのようなその他のアプリケーションまたはイネーブラ、例えばＯｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ（ＯＭＡ）によって仕様を定められたアプリケーションまたはイネーブラも、ｅ２ａｅセキュリティ解決策によって恩恵を被るであろう。
【０００４】
一部のアプリケーションについて場合によっては必要となりうるもう１つのタイプのメディア保護は、エンド・ツー・エンド（ｅ２ｅ）の、すなわち、端末から端末への（あるいは、サーバに基づくアプリケーションについては端末からアプリケーションサーバへの）保護である。しかし、忠実なｅ２ｅ保護は、例えばトランスコーディングのためのネットワークサポートの提供を不可能にするであろう。以下の記述においては、端末からアクセスエッジまでの解決策に焦点を当てる。メディアのｅ２ｅ保護については、忠実なｅ２ｅ保護も、ＰｏＣのようなネットワークによってサポートされる機能にとって利用可能なプレーンテキストを伴うものも、特許出願ＰＣＴ／ＳＥ２００７／０５０９２７に記述されており、それを参照により本願に援用する。
【０００５】
３ＧＰＰ標準に従うＩＭＳでは、セッション制御／セットアップシグナリングは、ＩＰＳｅｃとＴＬＳとのいずれか一方を用いて、Ｐ−ＣＳＣＦと端末との間で保護される。従って、端末からアクセスエッジまで保護することが本当に必要なのは、メディアトラヒックについてのみである。
【０００６】
既存のプロトコル上に構築された、端末からアクセスエッジまでのメディアの保護についての見込まれる解決策の１つは、端末と、信頼されたＩＭＳコア領域（あるいは、他の何らかのセキュアな場所）のエッジのセキュリティゲートウェイ（ＳＧＷ）との間で、ＩＰＳｅｃトンネルを用いることであろう。そのようなトンネルであれば、セキュアなネットワークのＵＥからエッジまでのすべてのメディアトラヒックを保護できるであろう。しかし、ＩＰｓｅｃトンネルを用いると、メッセージの著しい拡大が生じ、トラヒックの管理が難しくなる。
【０００７】
もちろん、ＵＥと例えばＳＧＳＮまたはＣ−ＢＧＦとの間のメディアパスを保護するために、メディア保護のためのＳＲＴＰや鍵管理のためのＭＩＫＥＹ（またはＳＤＥＳ）のような既存のプロトコルを用いることも可能であろう。しかし、現状のままでそれを適用することには、端末からアクセスエッジまでの解決策が、
・可能なエンド・ツー・エンドの解決策をユーザが一部のシナリオにおいて用いる場合に、その解決策と干渉し合い、
・ローミング状況下で、ホームネットワークと在圏ネットワークとの間のセキュリティポリシーに関連する問題を引き起こし、
・鍵管理とユーザ／ネットワークの認証に関する問題を有し、
・セッション確立以前に、ＵＥがそもそもメディアセキュリティをサポートするかどうか、そして、そうであるならば、どのタイプのメディア保護をＵＥがサポートするのかをＵＥがネットワークに示す手段に欠ける
ことがありうるという点で、問題がある。
【発明の概要】
【課題を解決するための手段】
【０００８】
本発明は、本書ではＩＭＳシステムを使って例示される、ＳＩＰ／ＩＰ Ｃｏｒｅ Ｓｙｓｔｅｍに関する。システムは、ＩＭＳ開始者ユーザエンティティを備える。システムは、開始者ユーザエンティティからの呼が着信する（あるいは一般に、メディア交換に参加するよう招待される）ＩＭＳ応答者ユーザエンティティを有する。システムは、開始者エンティティと通信する開始者側Ｓ−ＣＳＣＦを備えており、開始者側Ｓ−ＣＳＣＦは、開始者エンティティから第１の保護提案と鍵確立のためのパラメータとを有するＩＮＶＩＴＥを受信し、第１の保護提案をＩＮＶＩＴＥから削除し、そして、第１の保護提案のないＩＮＶＩＴＥを転送する。システムは、応答者ユーザエンティティおよび開始者側Ｓ−ＣＳＣＦと通信する応答者側Ｓ−ＣＳＣＦを備えており、応答者側Ｓ−ＣＳＣＦは、第１の保護提案のないＩＮＶＩＴＥを受信し、応答者ユーザエンティティがメディア保護をサポートすることをチェックし、第２の保護提案をＩＮＶＩＴＥに挿入し、そしてＩＮＶＩＴＥを応答者ユーザエンティティへ転送し、ここで応答者ユーザエンティティは、第２の保護提案を有するＩＮＶＩＴＥを受け入れ、そして、第１の保護受入れを有する確認応答を使って応答する。
【０００９】
本発明は、保護されたメディアセッションを、例えばＳ−ＣＳＣＦのような通信ノードによってサポートするための方法に関する。方法には、メディア保護のための提案を有する、開始者ユーザエンティティから応答者ユーザエンティティへのセッション制御招待メッセージを受信する各ステップが含まれる。ネットワークポリシーに従って招待メッセージからの提案に関して動作するステップがある。修正された提案を伴うメッセージを応答者当事者へ転送するステップがある。応答者ユーザエンティティから返信される確認応答を受信するステップがある。メディア保護エンドポートとなるように選択されたエッジエンティティにメディアトラヒックを向けるためのパラメータと、対応するＳＡを確立するための情報とを含むように、確認応答を修正するステップがある。
【００１０】
また本発明は、保護されるメディアセッションを、例えば応答者側Ｓ−ＣＳＣＦのような通信ノードによってサポートするための方法に関する。方法には、メディア保護のための提案を有していない、開始者側Ｓ−ＣＳＣＦユーザエンティティから応答者ユーザエンティティへのセッション制御招待メッセージを受信する各ステップが含まれる。応答者ユーザエンティティの登録されたセキュリティ能力に従って招待メッセージからの提案に関して動作するステップがある。修正された提案を伴うメッセージを応答者ユーザエンティティへ転送するステップがある。応答者当事者から返信される、第１の保護受入れを備えた確認応答を受信するステップがある。確認応答の中の第１の保護受入れを削除するステップがある。受入れのない確認応答を開始者側Ｓ−ＣＳＣＦへ転送するステップがある。
【００１１】
本発明は、通信ネットワークにおいて開始者ユーザエンティティと応答者ユーザエンティティとの間のメディア制御シグナリングメッセージを処理して転送することによって動作する、メディア制御シグナリングエンティティに関する。メディア制御シグナリングエンティティは、第１の招待メッセージを開始者ユーザエンティティから受信するための第１のネットワークインタフェースを備える。メディア制御シグナリングエンティティは、第２の招待メッセージを応答者ユーザエンティティへ転送するための第２のネットワークインタフェースを備える。メディア制御シグナリングエンティティは、前記第１および第２のネットワークインタフェースと通信する処理ユニットを備える。処理ユニットは、第１の招待メッセージから以下によって第２の招待メッセージを作成するよう動作可能であり、すなわち、
第１の招待メッセージがメディア保護のための第１の提案を有するかどうか判定し、
第１の招待メッセージの中に含まれる場合には第１のメディア保護提案を少なくとも削除して、
第１の招待メッセージには第１の保護提案がなく、かつ、前記応答者ユーザエンティティが少なくとも１つのメディアセキュリティ能力を前記通信ネットワークに登録している場合には、前記登録されたメディアセキュリティ能力に対応するような第２のメディア保護提案を少なくとも挿入することによって、
第１の招待メッセージから第２の招待メッセージを作成する。
【図面の簡単な説明】
【００１２】
添付の図面で、本発明の好適実施形態および本発明を実施する好適な方法を図解する。
【図１】ｅ２ａｅ保護の使用を制御するための簡略化したシグナリング図である。
【図２】ＩＭＳネットワーク参照モデルの図である。
【図３】本発明によって提供される３つの異なるタイプのセキュリティの表現である。
【図４】本発明の一実施形態によるもう１つのシグナリング図である。
【図５】メディア制御シグナリングエンティティのブロック図である。
【発明を実施するための形態】
【００１３】
ネットワーク内での所望のセキュリティレベルとメディアについて動作を行う必要性（例えばトランスコーディング）とに応じて、エンドポイント（ユーザ端末）とネットワーク内の適切な終端ポイントとの間にメディアセキュリティを提供する必要がある。
【００１４】
セキュリティの観点からは、プレーンテキストのメディアと鍵とがエンドポイント（端末）においてのみ利用可能であるような「忠実な」エンド・ツー・エンドの解決策が、明らかに望ましい。しかし、それは、トランスコーディングや合法的なインターセプトのようなネットワーク機能を困難にする。本発明は、メディア保護を下記のタイプに分類する。
【００１５】
エンド・ツー・アクセス・エッジ（ｅ２ａｅ）
この場合、メディアは、ＵＥと何らかのエッジエンティティ（Ｅｄｇｅ Ｅｎｔｉｔｙ：ＥＥ）との間で保護される。この解決策は、アクセス技術固有のいかなる脅威に関するセキュリティ問題をも解決するものであり、そして、この解決策はメディアを「できるだけ早期に」復号することから、それによって、コアネットワークおよびＩＭＳネットワークの内側であれば、どこにあるメディアであってもトランスコーディング／適応が可能になる。
【００１６】
エンド・ツー・ミドル（ｅ２ｍ）
この場合、トラヒックは、ＵＥと何らかの「ミドルボックス」（例えばボーダエンティティ（Ｂｏｒｄｅｒ Ｅｎｔｉｔｙ：ＢＥ）または何らかのアプリケーションサーバ（ＡＳ）もしくはイネーブラ）との間で保護される。ＡＳ／ＢＥから発信される着側トラヒックは、それが出て行く際に再暗号化されると想定される。これによって、より強固なセキュリティが提供される（唯一の脅威は、基本的に、ＢＥ／ＡＳ自身の中でのインターセプトである）が、同時に、メディア操作が（好都合なことに）１つの場所でしか可能でないことも意味する。留意すべきだが、ｅ２ｍとｅ２ａｅとの主な違いは、セキュリティを終端させるエンティティが、ネットワーク内でわずかに「アップストリーム」にあり、かつ、それが、発信されるトラヒックを再暗号化することに責任を持つということである。それゆえ、主な違いは、どのノードがメディア保護鍵へのアクセスを与えられているか（ＢＥ／ＡＳまたはＥＥ）ということにあり、従って、ｅ２ａｅの場合とｅ２ｍの場合とは非常に良く似ていると考えてよい。従って、理解されるべきだが、ｅ２ａｅ手順が論じられる場合にはいつでも、ｅ２ｍ手順を同様に扱うことができる。ｅ２ａｅまたはｅ２ｍセキュリティのエンドポイントとしてＢＥ、ＥＥ、ＳＧＷ、またはＡＳを総称的に呼ぶ場合には、メディアプレーン・ハンドラという表記法が用いられる。
【００１７】
エンド・ツー・エンド（ｅ２ｅ）
これは最も良好なセキュリティを提供するが、また、他のメディア操作に対して引き起こす問題も最も多い。合法的なインターセプトは、この場合、鍵がネットワーク内で知られていて、メディアを鍵と共に司法当局（Ｌａｗ Ｅｎｆｏｒｃｅｍｅｎｔ Ａｇｅｎｃｙ：ＬＥＡ）へ配信することによってかまたは、復号されたメディアストリームをＬＥＡへ配信することによって行われる限り、可能である。これは、「ネットワークサポートを伴うエンド・ツー・エンド」（ｅ２ｎ２ｅ）と呼ばれる。
【００１８】
従って、ｅ２ｅ、ｅ２ｎ２ｅ、ｅ２ｍ、ｅ２ａｅというこれら４つのシナリオ全てについて、サポートを動機付ける理由が存在する。図３は３つのオプションを示す。
【００１９】
ここで、複数の図の全体に渡って類似の参照番号は類似または同一の部分を指すことを特徴とする各図面を参照すると、そして、より詳細にはそのうちの図１を参照すると、図はＩＭＳシステム１０を示す。システム１０は、ＩＭＳ開始者ユーザエンティティ１２を備える。システム１０は、開始者ユーザエンティティ１２からの呼が着信するＩＭＳ応答者ユーザエンティティ１４を備える。システム１０は、開始者エンティティと通信する開始者側Ｓ−ＣＳＣＦ１６を備えており、Ｓ−ＣＳＣＦ１６は、開始者エンティティからの第１の保護提案と鍵確立のためのパラメータとを有するＩＮＶＩＴＥを受信し、第１の保護提案をＩＮＶＩＴＥから削除し、そして、第１の保護提案のないＩＮＶＩＴＥを転送する。システム１０は、応答者ユーザエンティティ１４および開始者側Ｓ−ＣＳＣＦ１６と通信する応答者側Ｓ−ＣＳＣＦ１８を備えており、応答者側Ｓ−ＣＳＣＦ１８は、第１の保護提案のないＩＮＶＩＴＥを受信し、応答者ユーザエンティティ１４がメディア保護をサポートすることをチェックし、第２の保護提案をＩＮＶＩＴＥに挿入し、そしてＩＮＶＩＴＥを応答者ユーザエンティティ１４へ転送し、ここで応答者ユーザエンティティ１４は、第２の保護提案を有するＩＮＶＩＴＥを受け入れ、そして、第１の保護受入れを有する確認応答を使って応答する。
【００２０】
システム１０は、ユーザエンティティ・メディアプレーン・ハンドラ２０を有し、そして、応答者ユーザエンティティ１４は、鍵材料を導出して、ユーザエンティティ・メディアプレーン・ハンドラ２０への信号と一緒にＳＡを確立し、ＳＡに基づく即時保護を可能にするよう、ユーザエンティティ・メディアプレーン・ハンドラ２０に命令することが好ましい。システム１０は、応答者ユーザエンティティ１４と通信する応答者側Ｐ−ＣＳＣＦ２２を有し、応答者側Ｐ−ＣＳＣＦ２２は、応答者ユーザエンティティ１４から確認応答を受信して確認応答を受信端Ｓ−ＣＳＣＦ１８へ転送することが好ましい。応答者側Ｓ−ＣＳＣＦ１８は、確認応答の中の第１の保護受入れを削除して、受入れのない確認応答を開始者側Ｓ−ＣＳＣＦ１６へ転送することが好ましい。ＳＡを確立することには、例えば、ユーザエンティティとメディアプレーン・ハンドラとが鍵の交換を行うこと、あるいは、他のやり方でＳＡをメディアプレーン・ハンドラに伝えることが含まれてもよいだろう。
【００２１】
開始者側Ｓ−ＣＳＣＦ１６は、保護が用いられるべきであるという第２の保護受入れを有するように、確認応答を修正することが好ましい。システム１０は、開始者側Ｓ−ＣＳＣＦ１６および開始者側ユーザエンティティと通信する開始者側Ｐ−ＣＳＣＦ２４を有することが好ましく、そして、開始者側Ｓ−ＣＳＣＦ１６は、第２の保護受入れを備えた確認応答を開始者側Ｐ−ＣＳＣＦ２４へ転送することが好ましい。開始者側Ｐ−ＣＳＣＦ２４は、第２の保護受入れを備えた確認応答を開始者ユーザエンティティ１４へ転送することが好ましい。
【００２２】
開始者側ユーザエンティティは第２の保護受入れを備えた確認応答をＰ−ＣＳＣＦから受信し、鍵材料を導出し、そして、ユーザエンティティ・メディアプレーン・ハンドラ２０への信号と共にＳＡを確立し、ＳＡに基づくメディア保護を可能にするようメディアプレーン・ハンドラ２０に命令することが好ましい。ＳＡを確立することには、例えば、ユーザエンティティとメディアプレーン・ハンドラとが鍵の交換を行うこと、あるいは、他のやり方でＳＡをメディアプレーン・ハンドラに伝えることが含まれてもよいだろう。
【００２３】
本発明は、保護されたメディアセッションを通信ノードによってサポートするための方法に関する。方法には、保護のための提案を有する、ユーザエンティティから応答者ユーザエンティティへのセッション制御招待メッセージを受信する各ステップが含まれる。ネットワークポリシーに従って招待メッセージからの提案に関して動作するステップがある。修正された提案を備えたメッセージを応答者当事者へ転送するステップがある。応答者当事者から返信される確認応答を受信するステップがある。保護エンドポートとなるように選択されたメディアプレーン・ハンドラにメディアトラヒックを向けるためのパラメータと、対応するＳＡを確立するための情報とを含むように、確認応答を修正するステップがある。
【００２４】
セッション制御招待メッセージを受信することには、ＳＩＰ ＩＮＶＩＴＥメッセージを受信するステップが含まれることが好ましい。動作するステップには、ＩＮＶＩＴＥメッセージから提案を削除するステップが含まれることが好ましい。ネットワークポリシーは、例えばトランスコーディング等を行う必要性によって示された、エンド・ツー・エンド対エンド・ツー・アクセスエッジ保護の適合性についての情報を備えることが好ましい。ＩＮＶＩＴＥメッセージを受信するステップには、開始者ユーザエンティティから応答者ＩＭＳユーザエンティティへの保護のための提案を有するＩＮＶＩＴＥメッセージを受信するステップが含まれることが好ましい。ＩＮＶＩＴＥメッセージを受信するステップには、鍵確立のためのパラメータを含む提案を有するＩＮＶＩＴＥメッセージを受信するステップが含まれることが好ましい。
【００２５】
ＳＡと共に用いられることになる保護のための鍵を導出するステップがあることが好ましい。ＩＭＳ開始者および／または応答者ユーザエンティティが端末のメディアセキュリティ能力を登録するステップがあることが好ましい。メディアセキュリティ能力には、エンド・ツー・アクセスエッジ保護と、ネットワークサポート機能が可能なエンド・ツー・エンド保護と、あるいは、忠実なエンド・ツー・エンド保護とのうち、少なくとも１つが含まれることが好ましい。導出するステップには、ＳＩＰシグナリングを保護するのに用いられる既存のセキュリティアソシエーション（セキュリティ関係付け）（ＳＡ）から、あるいは、鍵管理システムを使って、あるいは、公開鍵の解決策に基づく端末でのオンライン鍵生成によって、鍵を導出するステップが含まれることが好ましい。
【００２６】
鍵を導出してそれをメディア保護が用いられるべきであるという命令と一緒にメディアプレーン・ハンドラへ送信するようにＰ−ＣＳＣＦに命令するステップがあることが好ましい。Ｐ−ＣＳＣＦとＳ−ＣＳＣＦとのいずれか一方からＳＡを検索し、鍵を導出し、そして鍵をメディア保護が用いられるべきであるという命令と一緒にメディアプレーン・ハンドラへ送信するステップがあることが好ましい。メディア保護が適用されることをメディアプレーン・ハンドラに命令し、そして、メディアプレーン・ハンドラがＰ−ＣＳＣＦに鍵を要求するステップがあることが好ましい。
【００２７】
また、本発明は、保護されたメディアセッションを、例えば応答者側Ｓ−ＣＳＣＦのような通信ノードによってサポートするための方法に関する。方法には、メディア保護のための提案を有していない、開始者側Ｓ−ＣＳＣＦユーザエンティティから応答者ユーザエンティティへのセッション制御招待メッセージを受信する各ステップが含まれる。応答者ユーザエンティティの登録されたセキュリティ能力に従って招待メッセージからの提案に関して動作するステップがある。修正された提案を備えたメッセージを応答者ユーザエンティティへ転送するステップがある。第１の保護受入れを備えた、応答者当事者から返信される確認応答を受信するステップがある。確認応答の中の第１の保護受入れを削除するステップがある。受入れを有していない確認応答を開始者側Ｓ−ＣＳＣＦへ転送するステップがある。
【００２８】
図５を参照すると、本発明は、通信ネットワークにおいて開始者ユーザエンティティと応答者ユーザエンティティとの間のメディア制御シグナリングメッセージを処理して転送することによって動作する、メディア制御シグナリングエンティティに関する。メディア制御シグナリングエンティティは、第１の招待メッセージを開始者ユーザエンティティから受信するための第１のネットワークインタフェースを備える。メディア制御シグナリングエンティティは、第２の招待メッセージを応答者ユーザエンティティへ転送するための第２のネットワークインタフェースを備える。メディア制御シグナリングエンティティは、前記第１および第２のネットワークインタフェースと通信する処理ユニットを備える。処理ユニットは、第１の招待メッセージから以下によって第２の招待メッセージを作成するよう動作可能であり、すなわち、
第１の招待メッセージがメディア保護のための第１の提案を有するかどうか判定し、
第１の招待メッセージの中に含まれる場合には第１のメディア保護提案を少なくとも削除して、
第１の招待メッセージには第１の保護提案がなく、かつ、前記応答者ユーザエンティティが少なくとも１つのメディアセキュリティ能力を前記通信ネットワークに登録している場合には、前記登録されたメディアセキュリティ能力に対応するような第２のメディア保護提案を少なくとも挿入することによって、
第１の招待メッセージから第２の招待メッセージを作成する。
【００２９】
第２のメディア保護提案は、エンド・ツー・アクセスエッジのメディア保護についての提案であってもよい。第１および第２の招待メッセージは、ＳＩＰメッセージであってもよい。メディア制御シグナリングエンティティは、さらにＳ−ＣＳＣＦ機能を備えてもよい。
【００３０】
本発明の動作において、本発明は、ＩＭＳの枠組みの中で記述される。第１に、留意されることだが、ＩＭＳユーザはＩＭＳシステム１０に「登録」しなければならず、かつ、登録の際、エンドユーザは端末のメディアセキュリティ能力も登録すべきである。本発明は、上記のとおり、３つの新たなメディアセキュリティ能力、すなわち、エンド・ツー・アクセスエッジ（ｅ２ａｅ）、ネットワークサポート機能が可能なエンド・ツー・エンド（ｅ２ｎ２ｅ）、または忠実なエンド・ツー・エンド（ｅ２ｅ）保護を導入する。ここで留意すべきだが、これらのセキュリティ能力は、鍵管理のタイプの指標と、端末がサポートするセキュリティプロトコルの指標とを伴う必要がある。本記述では、端末は少なくともｅ２ａｅ保護についてのサポートを登録すると想定されている。鍵管理については、３つの異なる使用例がある。第１は、ＳＩＰシグナリングを保護するのに用いられる既存のセキュリティアソシエーション（ＳＡ）から鍵が導出されることであり、第２の例は、別個の鍵管理システムが用いられる場合であり、特にＰＣＴ／ＳＥ２００７／０５０９２７に記述された鍵管理がそうだが、事前に配布された鍵を伴うこともあり、そして、最後に、第３の鍵管理システム１０は、例えばＭＩＫＥＹまたはＩＫＥｖ２による、例えばＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ（ＤＨ）またはその他のＰｕｂｌｉｃ Ｋｅｙ（ＰＫ）解決策に基づく端末でのオンライン鍵生成に依存することである。セキュリティプロトコルはＳＲＴＰであることが好ましいが、その他のプロトコル、例えばＴＬＳ、ＩＰｓｅｃ等も可能である。
【００３１】
ｅ２ａｅメディア保護については、原則として、開始者と応答者ユーザエンティティとが独立して扱われることが認められている。例えば、開始者には、或るタイプのメディア保護が行われ、そして、応答者には別のタイプ（保護なしもありうる）が行われてもよい。以下の記述では、開始者側の手順について最初に記述し、次いで、応答者側の手順について記述する。
【００３２】
ＩＭＳにおいて１人のユーザが呼を開始し、ＩＮＶＩＴＥメッセージを応答者当事者へ送信する。ＩＮＶＩＴＥメッセージには、ｅ２ａｅ保護についての提案が含まれてもよい。この提案は、開始者側Ｓ−ＣＳＣＦによって検出されて処理されるが、開始者側Ｓ−ＣＳＣＦは、ＩＮＶＩＴＥが応答者当事者へ転送される前にＩＮＶＩＴＥからそれを削除するであろう。応答者当事者が「２００ ＯＫ」を返すと、Ｓ−ＣＳＣＦは、保護提案が受け入れられたことを示すようにＯＫを修正するであろう。修正されたＯＫメッセージには、端末がそのメディアトラヒックを、保護エンドポイントとして選択されたエッジエンティティへ向けるのに必要なすべてのパラメータと、対応するＳＡを確立するのに必要なすべての情報とが含まれるであろう。すでに述べたように、使用されることになる鍵は、端末とネットワークとで共有される既存のＳＡから導出されてもよいし、別個の鍵管理システム１０の助けで確立されてもよいし、あるいは、保護エンドポイントによってオンザフライ（Ｄ−Ｈ、ＰＫ）で生成されてもよいだろう。エンドポイントにおける鍵生成に基づく保護メカニズムの一例として、ＩＥＴＦにおいて開発された解決策があり、ＲＴＰＳＥＣと呼ばれている。
【００３３】
ここで、図４を参照すると、開始者端末がｅ２ａｅ保護提案を除外しているのに開始者側Ｓ−ＣＳＣＦは依然としてｅ２ａｅ保護の使用を実行することを望んでいる場合には、開始者側Ｓ−ＣＳＣＦは、ＩＮＶＩＴＥの中のサービス、すなわち保護のないこと、は利用可能でないということを示すＳＩＰエラーメッセージ（例えば「４８８ ＮＯＴ ＡＣＣＥＰＴＡＢＬＥ ＨＥＲＥ」）を送信することによって、それに関して動作してもよく、そして、例えばネットワーク（セキュリティ）ポリシーに起因して、端末はエンド・ツー・エッジ保護を用いるべきであるということを端末に対して示してもよい。もちろん、これを行う前に、開始者側Ｓ−ＣＳＣＦは、開始者端末がｅ２ａｅ能力をサポートしていることを開始者端末がすでに登録していることをチェックすべきである。応答者側でのアクセスエッジ・ツー・エンド保護の適用は、純粋にネットワークポリシーに基づく決定であってもよいだろう。しかし、好ましくは開始者側がこのタイプの保護を適用する場合に呼が応答者側でも同レベルの保護が与えられるべきであるということを応答者側に知らせることを目的として、これがＳＩＰシグナリング中に示されることは、検討されてもよいだろう。
【００３４】
応答者側では、応答者端末がｅ２ａｅ暗号化をサポートするかどうかを、応答者当事者のＳ−ＣＳＣＦがチェックする。そうであれば、応答者当事者のＳ−ＣＳＣＦはそれに関して動作し、そして、ｅ２ａｅメディア保護の提案をＩＮＶＩＴＥメッセージに挿入する。端末は、保護提案を受け入れる。鍵生成／管理は、開始者側と同じやり方で機能する。
【００３５】
ｅ２ａｅ保護を用いるという提案は、例えばＭＩＫＥＹ［ＲＦＣ３８３０、ＲＦＣ４５６７］またはＳＤＥＳ［ＲＦＣ４５６８］に従ってＳＩＰメッセージのＳＤＰ部分の中で搬送することができる。メッセージのＳＤＰ部分に提供されているキーイング情報は、後でＳＲＴＰをセットアップするために用いることができる。他のメディア、例えばＭＳＲＰについては、提供されるキーイング情報に基づいて、ＰＳＫ−ＴＬＳを用いてもよいだろう。また、ＭＥＳＳＡＧＥによってＳＩＰの中で搬送されるコンテンツ／メッセージを保護するため、他のメディア保護プロトコルが用いられてもよい。
【００３６】
メディア保護のために用いられることになる鍵は、開始者／応答者端末と開始者／応答者側Ｐ−ＣＳＣＦとの間のＳＩＰシグナリングを保護するのに用いられる鍵から導出されてもよい。鍵は、保護が適用されるべきだということをＳＩＰメッセージの検査からＰ−ＣＳＣＦが判断する場合にＰ−ＣＳＣＦからメディアプレーン・ハンドラ（例えばＳＧＷ、ＡＳ、ＢＥ、またはＥＥ）へプッシュされてもよいだろうし、あるいは、開始者（もしくは応答者）側Ｓ−ＣＳＣＦが、開始者（もしくは応答者）側Ｐ−ＣＳＣＦにそれらを配信するように命令することもできるし、あるいは、Ｓ−ＣＳＣＦ自身がキーイング情報を転送することもできる。キーイング材料が別のＳＡから来る場合、それに応じて鍵配布メカニズムが構成される必要がある。
【００３７】
ＰＣ／ＳＥ２００７／０５０９２７に記述された鍵管理解決策が用いられる場合、発信端末は、Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ（ＫＭＳ）に鍵とバウチャーとを要求し、そして、バウチャーをＩＮＶＩＴＥの中に含める。Ｓ−ＣＳＣＦは、バウチャーを取り出して、それをＫＭＳに提示し、ＫＭＳは、使用されることになる鍵を返信する。応答者側では、Ｓ−ＣＳＣＦは、ＫＭＳに鍵と（新たな）バウチャーとを要求し、そしてそれをＩＮＶＩＴＥの中に含めるであろう。次いで、応答者は、それをＫＭＳに提示し、対応する鍵を要求するであろう。
【００３８】
Ｅ２ｎ２ｅとｅ２ｍ
Ｅ２ｎ２ｅとｅ２ｍとの場合は、上記の記述の若干の変形とみなすことが容易にできる。
【００３９】
この場合の主な違いは、着信するメディアが保護されるだけでなく、発信するメディアも保護されることを、制御エンティティ（例えばＳ−ＣＳＣＦ／ＭＲＦＣ）が保証する必要があることである。保護が同一ノード内で終了し、かつ、開始される場合（典型的にはｅ２ｎ２ｅについて）、これは大きな問題ではないが、保護が１つのノード内で終了し、そして別のノードで開始される場合（ｅ２ｍ）、何らかの種類の指標が、第１のノードから第２のノードへ信号で伝えられる必要がある。
【００４０】
（忠実な）ｅ２ｅの場合は、どのネットワークエンティティも保護能力のシグナリングにおいてアクティブな役割を持たないという点が異なる。この場合、発信者／着信者のＳ−ＣＳＣＦは、（ネットワークポリシーがｅ２ｅ保護を認めていると想定して）単純に招待の中の保護提案に自分の中を通過させるであろう。
【００４１】
非常に高いレベルの簡略化されたシグナリング図を図１に示す。シグナリングフローの説明を以下に記す。図は、ＳＩＰシグナリングを保護するために用いられる既存のＳＡに鍵が基づいている場合のｅ２ａｅ保護を対象としている。
【００４２】
１ａ／ｂ 開始者ＵＥが、少なくともｅ２ａｅ保護に関する自分の能力を含むＲＥＧＩＳＴＥＲを送信することによって、ＩＭＳシステム１０に登録する。
【００４３】
２ａ／ｂ 開始者ＵＥが、登録を有効にするために認証される。
【００４４】
３ａ／ｂ 開始者ＵＥが、登録を確認する２００ ＯＫを入手する。そして、登録されたｅ２ａｅ能力のサポートを確認応答してもよい。
【００４５】
４ 開始者ＵＥが、鍵確立のためのパラメータを含めて、ｅ２ａｅ保護を用いるための提案を有するＩＮＶＩＴＥを送信する。
【００４６】
開始者側Ｓ−ＣＳＣＦ１６が、ＩＮＶＩＴＥを検査して、ｅ２ａｅ保護が提案されていることに気付く。ネットワークはｅ２ａｅ保護が可能なので、ネットワークは提案を暗黙のうちに受け入れて、決定を記憶する。
【００４７】
ここで留意すべきだが、開始者側Ｐ−ＣＳＣＦは、この段階では何もしない。
【００４８】
開始者側Ｓ−ＣＳＣＦは、Ｓ−ＣＳＣＦにおいて行われるのならば、ＳＡの導出をすでにここで開始してもよく、そして、導出された鍵をＭＲＦＣへ送信してもよい。鍵の導出が開始者側Ｐ−ＣＳＣＦで行われるのならば、導出は延期される。
【００４９】
５ 開始者側Ｓ−ＣＳＣＦ１６は、ＩＮＶＩＴＥからｅ２ａｅ保護提案を削除し、それを応答者側Ｓ−ＣＳＣＦ１８へ転送する。
【００５０】
応答者側Ｓ−ＣＳＣＦ１８が、ＩＮＶＩＴＥを検査し、応答者当事者がｅ２ａｅ保護をサポートするかどうかをチェックする（応答者はこれをすでに登録していると想定されている）。
【００５１】
６ 応答者側Ｓ−ＣＳＣＦ１８が、ＩＮＶＩＴＥが応答者ＵＥへ転送される前にｅ２ａｅ保護提案を挿入する。提案には、共有ＳＡを確立するのに必要なパラメータが含まれる。また、ＳＤＰ部分は、メディアプレーン・ハンドラが通常のメディア経路に含まれない別個のエンティティである場合、メディアを（ここではＳＧＷであると想定される）メディアプレーン・ハンドラを介してルーティングするよう変更されなければならない。
【００５２】
応答者ＵＥは、ｅ２ａｅ提案を含むＩＮＶＩＴＥを受け入れる。応答者ＵＥは、使用されることになる鍵を導出して、ＵＥメディアプレーン・ハンドラ２０への信号と一緒にＳＡを確立し、そのＳＡに基づいてメディア保護を可能にするようメディアプレーン・ハンドラ２０に命令する。
【００５３】
７ 応答者ＵＥは、２００ ＯＫを使って応答し、ｅ２ａｅ提案を受け入れる。応答者側のＰ−ＣＳＣＦ２２が２００ ＯＫを受信し、かつ、ｅ２ａｅ保護についてのＳＡを生成することがＰ−ＣＳＣＦの責任である場合には、Ｐ−ＣＳＣＦは２００ ＯＫを検査してＳＡを導出する。次いで、応答者側Ｐ−ＣＳＣＦは、ＳＡと必要なその他の情報とをＳＧＷにプッシュして、メディア保護を可能にするように要求するであろう。
【００５４】
８ 応答者側Ｐ−ＣＳＣＦは、２００ ＯＫを応答者側Ｓ−ＣＳＣＦ１８へ転送する。
【００５５】
ＳＡを生成することが応答者側Ｓ−ＣＳＣＦの責任である場合、応答者側Ｓ−ＣＳＣＦはそれを行って、その情報をＳＧＷへプッシュするであろう（Ｐ−ＣＳＣＦについて述べたのと同じ手順）。
【００５６】
９ 応答者側Ｓ−ＣＳＣＦ１８は、２００ ＯＫの中のｅ２ａｅ保護受入れを削除し、修正された２００ ＯＫを開始者側Ｓ−ＣＳＣＦ１６へ転送する。
【００５７】
開始者側Ｓ−ＣＳＣＦ１６は、ｅ２ａｅ保護が用いられるべきであることを記憶しており、これを示すために２００ ＯＫを修正する。
【００５８】
使用されることになるＳＡを生成することが開始者側Ｓ−ＣＳＣＦの責任である場合、開始者側Ｓ−ＣＳＣＦはこれを行って、それをＳＧＷによって必要とされる他の情報と一緒にプッシュし、そして、メディア保護を可能にするようＳＧＷに要求する。
【００５９】
１０ 開始者側Ｓ−ＣＳＣＦは、ｅ２ａｅ保護を用いることの受入れを伴う２００ ＯＫを開始者側Ｐ−ＣＳＣＦへ転送する。
【００６０】
ｅ２ａｅ保護のためのＳＡを生成することが開始者側Ｐ−ＣＳＣＦの責任である場合、開始者側Ｐ−ＣＳＣＦは２００ ＯＫを検査して、ｅ２ａｅ保護が合意されたことに気付き、従ってＳＡを導出する。次いで、開始者側Ｐ−ＣＳＣＦは、ＳＡとＳＧＷによって必要とされるその他の情報とをプッシュして、ＳＧＷがメディア保護を可能にするよう要求する。
【００６１】
１１ 開始者側Ｐ−ＣＳＣＦは、２００ ＯＫを開始者ＵＥへ転送する。ＵＥは、ｅ２ａｅ保護提案が受け入れられたことに気付き、使用されることになる鍵を導出する。ＵＥは、ＵＥメディアプレーン・ハンドラ２０への信号と一緒にＳＡを確立し、提供されたＳＡに基づいてメディア保護を可能にするようメディアプレーン・ハンドラ２０に命令する。
【００６２】
上述したように、ＳＤＥＳもしくはＭＩＫＥＹを用いてＳＤＰの中で提案と応答とを搬送することができるであろうが、その他の符号化を考えることも可能である。
【００６３】
実際には、メディアセキュリティは、ＩＭＳについては異なるエッジデバイス（メディアプレーン・ハンドラ）に終端されてもよい。また、これは、メディアプレーン・ハンドラが標準的にメディア経路に含まれているのかどうか、あるいは、メディアプレーン・ハンドラの存在は、例えばｅ２ａｅ保護のためのエンドポイントとして動作する必要性に起因するだけなのかにも依存する。前者の場合はセキュリティデータのメディアプレーン・ハンドラへのシグナリングが既存のセットアップシグナリングの中に「抱き合わせ」られてもよいのに対し、第２の場合、（そのトラヒックをリダイレクトするためのＵＥへの信号を含めて）明確なシグナリングが必要となる可能性がある。上記の記述は、メディアが終端される場所によって若干異なる。保護がＭＲＦＰで終わる場合、ＭＲＦＣが、導出された鍵をＳ−ＣＳＣＦから受信して、これをＭＲＦＰまでプッシュする必要があるエンティティとなるであろう。
【００６４】
メディアセキュリティ能力の利用は以下のとおりである。
【００６５】
・端末が、サポートされた能力を登録する。これは、ネットワークによって開始される保護を可能にするためであり、これは、ｅ２ａｅもしくはｅ２ｎ２ｅだけである可能性が非常に高いであろう。
【００６６】
・ネットワークは、例えばポリシーに従って、一定のメディアセキュリティモードはサポートされないことを決定してもよく、従って、メディアセキュリティモードがサポートされないことをＵＥに示してもよい。
【００６７】
・２つ以上の能力が登録された場合、使用すべき最も良いメディアセキュリティ解決策とは何か、すなわち、ｅ２ｅ、ｅ２ｎ２ｅ、またはｅ２ａｅを使用するかどうかを発見するために、後でネットワークによって、または別の端末によって、これが用いられてもよい。
【００６８】
・ＵＥがＩＮＶＩＴＥを、例えばｅ２ｅ提案とｅ２ａｅ提案とを両方添えて別のＵＥへ送信する場合、２つのエンドポイントの中間にある各エンティティは、それらがこれらをサポートするということ、および／または、ネットワークポリシーがそれらを許可するということを検証する必要がある。例えば、これらのうちの１つがサポートされない場合、ネットワークは、例えばネットワークがサポートしない能力を削除することによって、これを示すことができるであろうし、従って、着信ＵＥが要求を受信する場合、着信ＵＥは、発信ＵＥと中間のすべてのネットワークエンティティとの両方がサポートする残った選択肢だけを持つであろう。これを処理するもう１つのやり方は、特定のメディアセキュリティ能力をサポートしないいずれかのネットワークエンティティに、これを示すエラーを返信させることである。そうすれば、その後、ＵＥは、その能力を用いずに再試行しなければならなくなるであろう。
【００６９】
既存のＳＡに基づくｅ２ａｅ保護のための鍵
Ｐ−ＣＳＣＦと端末との間のＳＩＰシグナリングを保護するためにＩＰｓｅｃが用いられる場合、用いられる鍵は、Ｐ−ＣＳＣＦにおいて利用可能であろうし、Ｓ−ＣＳＣＦにおいても場合によっては利用可能であろう。ｈｔｔｐダイジェストによるサーバ証明書およびクライアント認証に基づくＴＬＳが用いられる場合には、ＴＬＳ ＳＡはＰ−ＣＳＣＦにおいてのみ利用可能であろう。
【００７０】
いずれにせよ、Ｓ−ＣＳＣＦまたは関連のＭＲＦは、ポリシー制御を行うことと鍵の導出および配信を開始することとに責任を有するであろう。既存のシステムにおいて行われる実装の選択に応じて、どうすればこの機能が最も良く実装されるかに関して、多様な選択肢がある。主要な観点から、以下の選択肢がありうる。
【００７１】
１．Ｓ−ＣＳＣＦ／ＭＲＦがＰ−ＣＳＣＦに、メディア保護鍵を導出し、それをメディア保護が用いられるべきだという命令と一緒にメディアプレーン・ハンドラへ送信するよう、命令するであろう。
【００７２】
２．Ｓ−ＣＳＣＦ／ＭＲＦが、Ｐ−ＣＳＣＦ（もしくはＳ−ＣＳＣＦ）からＳＡを取り出して鍵を導出し、それをメディア保護が用いられるべきだという命令と一緒にメディアプレーン・ハンドラへ送信するであろう。
【００７３】
３．Ｓ−ＣＳＣＦ／ＭＲＦがメディアプレーン・ハンドラに、メディア保護が適用されるべきだと命令し、メディアプレーン・ハンドラが、導出された鍵をＰ−ＣＳＣＦに要求するであろう。
【００７４】
４．Ｓ−ＣＳＣＦ／ＭＲＦがメディアプレーン・ハンドラに、例えば上記の１乃至３のいずれかに従って導出された鍵に基づいて、または、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵技術を用いて、ＵＥとのＳＡを明確に確立すべきだと命令するであろう。
【００７５】
バウチャーに基づく鍵
この場合、Ｓ−ＣＳＣＦ／ＭＲＦは、受信したバウチャーをＫＭＳへ送信して、対応する鍵を要求するであろう。次いで、メディア保護が用いられるべきだという命令と一緒に鍵をＳＧＷへ送信するであろう。これについては、特許出願ＰＣＴ／ＳＥ２００７／０５０９２７に詳細に記述されている。
【００７６】
保護を開始する際に、Ｓ−ＣＳＣＦ／ＭＲＦは、ＫＭＳに鍵とバウチャーを要求するであろう。
【００７７】
図２に、本書で用いられる参照アーキテクチャを示す。
【００７８】
ユーザ／メディアプレーンノードをボックス１１に示し、ＳＩＰ制御プレーンノードをボックス１５に示す。ＥＥは、固定コアネットワークの端にある（何らかの）エッジエンティティである。ＢＥは、２つのネットワーク間の境界にある何らかのボーダエンティティである。ＡＳは、何らかのＩＭＳアプリケーションかまたはＯＭＡイネーブラ、例えばＰｏＣサーバまたはＩｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇサーバである。（上記で用いた表記法では、ＡＳ、ＥＥ、およびＢＥはすべてメディアプレーン・ハンドラである。）
【００７９】
図２は、ＡとＢが両方共ＩＳＩＭ対応のユーザであると想定しているが、ＩＭＳは多くの異なるアクセス技術に共通であることが想定されているため、（ハードトークン）ＵＩＣＣの使用を必要とすることは、特に非ＩＳＩＭに基づくメカニズムがすでにＩＭＳ認証用に存在することから、制限的すぎるかもしれない。
【００８０】
直接的な解決策は、ソフトＩＳＩＭの利用も可能にすることである。しかし、これでさえ、他の形のユーザ信用保証情報、例えばハードウェアもしくはソフトウェアとして配信される公開鍵／秘密鍵の配置も存在することから、制限である可能性がある。
【００８１】
従って、ＩＳＩＭのサポートは第一に取り組むべき関心事ではあるものの、目標とする解決策は、何らかの形の暗号による（秘密鍵をベースにした）ユーザ信用保証情報が用いられることと、この信用保証情報は、ユーザを認証して一般的な共有の（ベースとなる）セッション鍵を確立するために用いられうることとを想定するに留まるであろう。このカテゴリに入る解決策は、ＩＳＩＭ、ＰＫＩ、ＩＢＣ（アイデンティティに基づく暗号化）、ユーザ名／パスワード等である。
【００８２】
以下は、本発明によってサポートすることができるＩＭＳサービスの例である。
【００８３】
ＭＭＴＥＬ
これは、従来型のピア・ツー・ピア（Ｐ２Ｐ）マルチメディア電話もしくは小規模グループでの電話会議を意味する。グループの場合には、「会議ブリッジ」がＩＭＳ ＡＳまたはＯＭＡイネーブラとして実装されると想定される。セットアップは、通常のＳＩＰメカニズムを介してシグナリングされ、そして、メディアは、ＲＴＰによって搬送される。グループの場合には、ＳＩＰサーバ（ＣＳＣＦ）は、例えば、セキュリティが、各ユーザとＡＳまたはイネーブラとの間でｅ２ｍで提供されるように、ＳＩＰ提案の中のセキュリティを修正してもよいだろう。
【００８４】
プッシュ・トゥー・トーク
ここで、ＰｏＣサービスとは、ＳＩＰシグナリングを用いて設定され、ＰｏＣサーバがアプリケーションサーバ（ＡＳ）としてかまたは、ＲＴＰトランスポートされたメディアを各受信器に配信するためのイネーブラとして用いられるようなサービスのことを言う。実際の製品の中の「ＰｏＣサーバ」は、通常は制御プレーン部分のことを言うが、本書では、制御プレーン部分とメディアプレーン（ＭＲＦ）部分との両方のことを総称して「ＰｏＣサーバ」と言う。この場合も、上記の電話会議と同様に処理することができるであろう。
【００８５】
メッセージング
これは、ＳＩＰ本体の中で直接搬送されるかまたは、ＳＩＰによってセットアップされてＭＳＲＰ上を搬送されるかいずれか一方のメッセージであってもよい。ＡＳ／イネーブラは、メッセージングサーバとして動作する。また本書では、メッセージは、Ｐ２Ｐであってもよいし、グループに向けられてもよい。
【００８６】
インスタントサービス対延期サービス
メッセージングサービスは典型的には、受信者がオンラインではない場合、メッセージが自動的に延期メッセージに変換されて、受信者が登録するまでＡＳの中に記憶されるように実装される。実際、ＭＭＴＥＬおよびＰｏＣも、「留守電マシン」として動作するサーバとの延期配信をサポートすることができる。
【００８７】
ＨＳＳ、ＣＳＣＦ、ＭＲＦ等といった周知のＩＭＳ関連用語以外に、本書では下記の略語が用いられる。
【００８８】
ＡＳ （ＩＭＳ）アプリケーションサーバ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）
ＢＥ ボーダエンティティ（Ｂｏｒｄｅｒ Ｅｎｔｉｔｙ）
ＢＳＦ ブートストラッピングサーバ機能（Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ）
ＥＥ エッジエンティティ（Ｅｄｇｅ Ｅｎｔｉｔｙ）
ＥＰＳ 進化型パケットシステム（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）
ＧＢＡ 汎用ブートストラッピングアーキテクチャ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）
ＬＥＡ 司法当局（Ｌａｗ Ｅｎｆｏｒｃｅｍｅｎｔ Ａｇｅｎｃｙ）
ＬＩ 合法的なインターセプト（Ｌａｗｆｕｌ Ｉｎｔｅｒｃｅｐｔ）
ＮＡＦ ネットワークアプリケーション機能（Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）
ＮＳＰＳ （Ｎａｔｉｏｎａｌ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｕｂｌｉｃ Ｓａｆｅｔｙ）
Ｐ２Ｐ ピア・ツー・ピア（Ｐｅｅｒ−ｔｏ−ｐｅｅｒ）
ＣＢＧＦ コア・ボーダ・ゲートウェイ機能（Ｃｏｒｅ Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｆｕｎｃｔｉｏｎ）
ＣＳＣＦ 呼状態制御機能（Ｃａｌｌ Ｓｔａｔｅ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）
ＤＨ （Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）
ｅ２ａｅ エンド・ツー・アクセス・エッジ（Ｅｎｄ−ｔｏ−Ａｃｃｅｓｓ−Ｅｄｇｅ）
ｅ２ｅ エンド・ツー・エンド（Ｅｎｄ−ｔｏ−ｅｎｄ）
ＦＭＣ 固定移動体融合（Ｆｉｘｅｄ−Ｍｏｂｉｌｅ Ｃｏｎｖｅｒｇｅｎｃｅ）
ＧＳＭ （Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）
ＩＫＥ インターネット鍵交換（Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ）（ＲＦＣ ４３０６）
ＩＭ インスタント・メッセージング（Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ）
ＩＭＳ ＩＰマルチメディア・サブシステム（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）（３ＧＰＰ標準）
ＩＰＳｅｃ （ＩＰ Ｓｅｃｕｒｉｔｙ ｐｒｏｔｏｃｏｌ）（ＲＦＣ ４３０１）
ＫＭＳ 鍵管理サーバ（Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ）
ＭＩＫＥＹ （Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｎｅｔ ＫＥＹｉｎｇ）（ＲＦＣ ３８３０）
ＭＭＴＥＬ （Ｍｕｌｔｉｍｅｄｉａ ＴＥＬｅｐｈｏｎｙ）
ＭＲＦ マルチメディアリソース機能（Ｍｕｌｔｉｍｅｄｉａ Ｒｅｓｏｕｒｃｅ Ｆｕｎｃｔｉｏｎ）
ＭＲＦＣ ＭＲＦ制御（ＭＲＦ Ｃｏｎｔｒｏｌ）
ＭＲＦＰ ＭＲＦプロセッサ（ＭＲＦ Ｐｒｏｃｅｓｓｏｒ）
ＭＳＲＰ メッセージ・セッション・リレー・プロトコル（Ｍｅｓｓａｇｅ Ｓｅｓｓｉｏｎ Ｒｅｌａｙ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ ４９７５）
Ｐ−ＣＳＣＦ プロキシＣＳＣＦ（Ｐｒｏｘｙ−ＣＳＣＦ）
ＰＫ 公開鍵（Ｐｕｂｌｉｃ Ｋｅｙ）
ＰｏＣ セルラーを用いたプッシュ・トゥー・トーク（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ）
ＰＳＫ−ＴＬＳ （Ｐｒｅ−ｓｈａｒｅｄ Ｋｅｙ ＴＬＳ）
ＲＴＰ リアルタイム伝送プロトコル（Ｒｅａｌ ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ ３５５０）
ＲＴＰＳＥＣ （ＲＴＰ Ｓｅｃｕｒｅ Ｋｅｙｉｎｇ）
ＳＡ セキュリティアソシエーション（Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ）
Ｓ−ＣＳＣＦ サービングＣＳＣＦ（Ｓｅｒｖｉｎｇ−ＣＳＣＦ）
ＳＤＥＳ セッション記述プロトコルのセキュリティ記述（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ Ｄｅｓｃｒｉｐｔｉｏｎｓ）（ＲＦＣ ４５６８）
ＳＤＰ セッション記述プロトコル（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ ４５６６）
ＳＧＷ セキュリティゲートウェイ（Ｓｅｃｕｒｉｔｙ Ｇａｔｅｗａｙ）
ＳＩＰ セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ ３２６１）
ＳＲＴＰ （Ｓｅｃｕｒｅ Ｒｅａｌ ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ ３７１１）
ＴＬＳ （Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）（ＲＦＣ ５２４６）
ＵＥ ユーザ装置（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）
ＷＣＤＭＡ 広帯域符号分割多元接続（Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）
ＷｉＭＡＸ （Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）（ＩＥＥＥ ８０２．１６）
ＷＬＡＮ 無線ローカルアクセスネットワーク（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）（ＩＥＥＥ ８０２．１１）
【００８９】
本発明について前記の諸実施形態において例示する目的で詳細に記述してきたが、理解されるべきだが、そのような詳細は、そのことだけを目的にしており、そして、下記の請求項で記述されることを除いて、本発明の精神と範囲とから逸脱することなく、当業者によって変形形態がこの中に作られうる。
【技術分野】
【０００１】
本発明は、セッション制御招待メッセージに関するメディア保護制御に関連する。（本書では、「本発明」または「発明」への言及は、例示的な実施形態に関するものであり、必ずしも添付の請求項によって包含されるあらゆる実施形態に関するものではない。）より詳細には、本発明は、適切なメディア保護、例えば、ＩＭＳシステムにおける開始者ユーザエンティティと応答者ユーザエンティティとの間のＳＩＰ ＩＮＶＩＴＥメッセージに関するエンド・ツー・エッジのメディア保護を選択することに関する。
【背景技術】
【０００２】
本章では、本発明の各種の態様に関連しうる技術の各種の態様を読者に紹介することが意図されている。下記の議論では、本発明のよりよい理解を助ける情報を提供することが意図されている。従って、理解されるべきだが、下記の議論の中の記述は、この観点から読まれるべきであり、先行技術の承認として読まれるべきではない。
【０００３】
多くのネットワークアクセス技術（ＧＳＭ、ＷＣＤＭＡ、ＷＬＡＮ、ＷｉＭＡＸ）は、「第１のホップ」のための何らかの基本的なセキュリティを提供する。しかし、ネットワークアクセス技術がすべて十分にセキュアであるとみなしうるわけではなく、一部のアクセス（例えばＩＥＥＥ８０２．３）は組み込みセキュリティを全く提供していない。特に、固定回線のアクセスには、ユーザトラヒックの論理的な保護は通常はまったく存在せず、従って、保護は、トラヒックを搬送している物理的メディアにアクセスする難度だけに依存している。従って、「固定移動体融合」（Ｆｉｘｅｄ−Ｍｏｂｉｌｅ Ｃｏｎｖｅｒｇｅｎｃｅ：ＦＭＣ）というシナリオにおいては、少なくともＩＭＳ制御によるエンド・ツー・アクセスエッジ（ｅ２ａｅ）セキュリティ、すなわち、アクセスネットワークを横断するメディアトランスポートのためのセキュリティを提供する必要性がある。これは、多様なネットワークタイプにおいてトラヒックの均一な保護を提供できるようにするために必要なのである。ＭＭＴＥＬは、ユーザの信用を獲得するためにセキュアにされる必要があるそのようなアプリケーションの１つである。ＳＲＴＰ（ＲＦＣ３７１１）とＭＩＫＥＹ（ＲＦＣ３８３０）とは、この目的で提案されているメディアセキュリティおよび鍵管理のためのプロトコルの例である。ＩＭ、ＰｏＣおよびＰｒｅｓｅｎｃｅのようなその他のアプリケーションまたはイネーブラ、例えばＯｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ（ＯＭＡ）によって仕様を定められたアプリケーションまたはイネーブラも、ｅ２ａｅセキュリティ解決策によって恩恵を被るであろう。
【０００４】
一部のアプリケーションについて場合によっては必要となりうるもう１つのタイプのメディア保護は、エンド・ツー・エンド（ｅ２ｅ）の、すなわち、端末から端末への（あるいは、サーバに基づくアプリケーションについては端末からアプリケーションサーバへの）保護である。しかし、忠実なｅ２ｅ保護は、例えばトランスコーディングのためのネットワークサポートの提供を不可能にするであろう。以下の記述においては、端末からアクセスエッジまでの解決策に焦点を当てる。メディアのｅ２ｅ保護については、忠実なｅ２ｅ保護も、ＰｏＣのようなネットワークによってサポートされる機能にとって利用可能なプレーンテキストを伴うものも、特許出願ＰＣＴ／ＳＥ２００７／０５０９２７に記述されており、それを参照により本願に援用する。
【０００５】
３ＧＰＰ標準に従うＩＭＳでは、セッション制御／セットアップシグナリングは、ＩＰＳｅｃとＴＬＳとのいずれか一方を用いて、Ｐ−ＣＳＣＦと端末との間で保護される。従って、端末からアクセスエッジまで保護することが本当に必要なのは、メディアトラヒックについてのみである。
【０００６】
既存のプロトコル上に構築された、端末からアクセスエッジまでのメディアの保護についての見込まれる解決策の１つは、端末と、信頼されたＩＭＳコア領域（あるいは、他の何らかのセキュアな場所）のエッジのセキュリティゲートウェイ（ＳＧＷ）との間で、ＩＰＳｅｃトンネルを用いることであろう。そのようなトンネルであれば、セキュアなネットワークのＵＥからエッジまでのすべてのメディアトラヒックを保護できるであろう。しかし、ＩＰｓｅｃトンネルを用いると、メッセージの著しい拡大が生じ、トラヒックの管理が難しくなる。
【０００７】
もちろん、ＵＥと例えばＳＧＳＮまたはＣ−ＢＧＦとの間のメディアパスを保護するために、メディア保護のためのＳＲＴＰや鍵管理のためのＭＩＫＥＹ（またはＳＤＥＳ）のような既存のプロトコルを用いることも可能であろう。しかし、現状のままでそれを適用することには、端末からアクセスエッジまでの解決策が、
・可能なエンド・ツー・エンドの解決策をユーザが一部のシナリオにおいて用いる場合に、その解決策と干渉し合い、
・ローミング状況下で、ホームネットワークと在圏ネットワークとの間のセキュリティポリシーに関連する問題を引き起こし、
・鍵管理とユーザ／ネットワークの認証に関する問題を有し、
・セッション確立以前に、ＵＥがそもそもメディアセキュリティをサポートするかどうか、そして、そうであるならば、どのタイプのメディア保護をＵＥがサポートするのかをＵＥがネットワークに示す手段に欠ける
ことがありうるという点で、問題がある。
【発明の概要】
【課題を解決するための手段】
【０００８】
本発明は、本書ではＩＭＳシステムを使って例示される、ＳＩＰ／ＩＰ Ｃｏｒｅ Ｓｙｓｔｅｍに関する。システムは、ＩＭＳ開始者ユーザエンティティを備える。システムは、開始者ユーザエンティティからの呼が着信する（あるいは一般に、メディア交換に参加するよう招待される）ＩＭＳ応答者ユーザエンティティを有する。システムは、開始者エンティティと通信する開始者側Ｓ−ＣＳＣＦを備えており、開始者側Ｓ−ＣＳＣＦは、開始者エンティティから第１の保護提案と鍵確立のためのパラメータとを有するＩＮＶＩＴＥを受信し、第１の保護提案をＩＮＶＩＴＥから削除し、そして、第１の保護提案のないＩＮＶＩＴＥを転送する。システムは、応答者ユーザエンティティおよび開始者側Ｓ−ＣＳＣＦと通信する応答者側Ｓ−ＣＳＣＦを備えており、応答者側Ｓ−ＣＳＣＦは、第１の保護提案のないＩＮＶＩＴＥを受信し、応答者ユーザエンティティがメディア保護をサポートすることをチェックし、第２の保護提案をＩＮＶＩＴＥに挿入し、そしてＩＮＶＩＴＥを応答者ユーザエンティティへ転送し、ここで応答者ユーザエンティティは、第２の保護提案を有するＩＮＶＩＴＥを受け入れ、そして、第１の保護受入れを有する確認応答を使って応答する。
【０００９】
本発明は、保護されたメディアセッションを、例えばＳ−ＣＳＣＦのような通信ノードによってサポートするための方法に関する。方法には、メディア保護のための提案を有する、開始者ユーザエンティティから応答者ユーザエンティティへのセッション制御招待メッセージを受信する各ステップが含まれる。ネットワークポリシーに従って招待メッセージからの提案に関して動作するステップがある。修正された提案を伴うメッセージを応答者当事者へ転送するステップがある。応答者ユーザエンティティから返信される確認応答を受信するステップがある。メディア保護エンドポートとなるように選択されたエッジエンティティにメディアトラヒックを向けるためのパラメータと、対応するＳＡを確立するための情報とを含むように、確認応答を修正するステップがある。
【００１０】
また本発明は、保護されるメディアセッションを、例えば応答者側Ｓ−ＣＳＣＦのような通信ノードによってサポートするための方法に関する。方法には、メディア保護のための提案を有していない、開始者側Ｓ−ＣＳＣＦユーザエンティティから応答者ユーザエンティティへのセッション制御招待メッセージを受信する各ステップが含まれる。応答者ユーザエンティティの登録されたセキュリティ能力に従って招待メッセージからの提案に関して動作するステップがある。修正された提案を伴うメッセージを応答者ユーザエンティティへ転送するステップがある。応答者当事者から返信される、第１の保護受入れを備えた確認応答を受信するステップがある。確認応答の中の第１の保護受入れを削除するステップがある。受入れのない確認応答を開始者側Ｓ−ＣＳＣＦへ転送するステップがある。
【００１１】
本発明は、通信ネットワークにおいて開始者ユーザエンティティと応答者ユーザエンティティとの間のメディア制御シグナリングメッセージを処理して転送することによって動作する、メディア制御シグナリングエンティティに関する。メディア制御シグナリングエンティティは、第１の招待メッセージを開始者ユーザエンティティから受信するための第１のネットワークインタフェースを備える。メディア制御シグナリングエンティティは、第２の招待メッセージを応答者ユーザエンティティへ転送するための第２のネットワークインタフェースを備える。メディア制御シグナリングエンティティは、前記第１および第２のネットワークインタフェースと通信する処理ユニットを備える。処理ユニットは、第１の招待メッセージから以下によって第２の招待メッセージを作成するよう動作可能であり、すなわち、
第１の招待メッセージがメディア保護のための第１の提案を有するかどうか判定し、
第１の招待メッセージの中に含まれる場合には第１のメディア保護提案を少なくとも削除して、
第１の招待メッセージには第１の保護提案がなく、かつ、前記応答者ユーザエンティティが少なくとも１つのメディアセキュリティ能力を前記通信ネットワークに登録している場合には、前記登録されたメディアセキュリティ能力に対応するような第２のメディア保護提案を少なくとも挿入することによって、
第１の招待メッセージから第２の招待メッセージを作成する。
【図面の簡単な説明】
【００１２】
添付の図面で、本発明の好適実施形態および本発明を実施する好適な方法を図解する。
【図１】ｅ２ａｅ保護の使用を制御するための簡略化したシグナリング図である。
【図２】ＩＭＳネットワーク参照モデルの図である。
【図３】本発明によって提供される３つの異なるタイプのセキュリティの表現である。
【図４】本発明の一実施形態によるもう１つのシグナリング図である。
【図５】メディア制御シグナリングエンティティのブロック図である。
【発明を実施するための形態】
【００１３】
ネットワーク内での所望のセキュリティレベルとメディアについて動作を行う必要性（例えばトランスコーディング）とに応じて、エンドポイント（ユーザ端末）とネットワーク内の適切な終端ポイントとの間にメディアセキュリティを提供する必要がある。
【００１４】
セキュリティの観点からは、プレーンテキストのメディアと鍵とがエンドポイント（端末）においてのみ利用可能であるような「忠実な」エンド・ツー・エンドの解決策が、明らかに望ましい。しかし、それは、トランスコーディングや合法的なインターセプトのようなネットワーク機能を困難にする。本発明は、メディア保護を下記のタイプに分類する。
【００１５】
エンド・ツー・アクセス・エッジ（ｅ２ａｅ）
この場合、メディアは、ＵＥと何らかのエッジエンティティ（Ｅｄｇｅ Ｅｎｔｉｔｙ：ＥＥ）との間で保護される。この解決策は、アクセス技術固有のいかなる脅威に関するセキュリティ問題をも解決するものであり、そして、この解決策はメディアを「できるだけ早期に」復号することから、それによって、コアネットワークおよびＩＭＳネットワークの内側であれば、どこにあるメディアであってもトランスコーディング／適応が可能になる。
【００１６】
エンド・ツー・ミドル（ｅ２ｍ）
この場合、トラヒックは、ＵＥと何らかの「ミドルボックス」（例えばボーダエンティティ（Ｂｏｒｄｅｒ Ｅｎｔｉｔｙ：ＢＥ）または何らかのアプリケーションサーバ（ＡＳ）もしくはイネーブラ）との間で保護される。ＡＳ／ＢＥから発信される着側トラヒックは、それが出て行く際に再暗号化されると想定される。これによって、より強固なセキュリティが提供される（唯一の脅威は、基本的に、ＢＥ／ＡＳ自身の中でのインターセプトである）が、同時に、メディア操作が（好都合なことに）１つの場所でしか可能でないことも意味する。留意すべきだが、ｅ２ｍとｅ２ａｅとの主な違いは、セキュリティを終端させるエンティティが、ネットワーク内でわずかに「アップストリーム」にあり、かつ、それが、発信されるトラヒックを再暗号化することに責任を持つということである。それゆえ、主な違いは、どのノードがメディア保護鍵へのアクセスを与えられているか（ＢＥ／ＡＳまたはＥＥ）ということにあり、従って、ｅ２ａｅの場合とｅ２ｍの場合とは非常に良く似ていると考えてよい。従って、理解されるべきだが、ｅ２ａｅ手順が論じられる場合にはいつでも、ｅ２ｍ手順を同様に扱うことができる。ｅ２ａｅまたはｅ２ｍセキュリティのエンドポイントとしてＢＥ、ＥＥ、ＳＧＷ、またはＡＳを総称的に呼ぶ場合には、メディアプレーン・ハンドラという表記法が用いられる。
【００１７】
エンド・ツー・エンド（ｅ２ｅ）
これは最も良好なセキュリティを提供するが、また、他のメディア操作に対して引き起こす問題も最も多い。合法的なインターセプトは、この場合、鍵がネットワーク内で知られていて、メディアを鍵と共に司法当局（Ｌａｗ Ｅｎｆｏｒｃｅｍｅｎｔ Ａｇｅｎｃｙ：ＬＥＡ）へ配信することによってかまたは、復号されたメディアストリームをＬＥＡへ配信することによって行われる限り、可能である。これは、「ネットワークサポートを伴うエンド・ツー・エンド」（ｅ２ｎ２ｅ）と呼ばれる。
【００１８】
従って、ｅ２ｅ、ｅ２ｎ２ｅ、ｅ２ｍ、ｅ２ａｅというこれら４つのシナリオ全てについて、サポートを動機付ける理由が存在する。図３は３つのオプションを示す。
【００１９】
ここで、複数の図の全体に渡って類似の参照番号は類似または同一の部分を指すことを特徴とする各図面を参照すると、そして、より詳細にはそのうちの図１を参照すると、図はＩＭＳシステム１０を示す。システム１０は、ＩＭＳ開始者ユーザエンティティ１２を備える。システム１０は、開始者ユーザエンティティ１２からの呼が着信するＩＭＳ応答者ユーザエンティティ１４を備える。システム１０は、開始者エンティティと通信する開始者側Ｓ−ＣＳＣＦ１６を備えており、Ｓ−ＣＳＣＦ１６は、開始者エンティティからの第１の保護提案と鍵確立のためのパラメータとを有するＩＮＶＩＴＥを受信し、第１の保護提案をＩＮＶＩＴＥから削除し、そして、第１の保護提案のないＩＮＶＩＴＥを転送する。システム１０は、応答者ユーザエンティティ１４および開始者側Ｓ−ＣＳＣＦ１６と通信する応答者側Ｓ−ＣＳＣＦ１８を備えており、応答者側Ｓ−ＣＳＣＦ１８は、第１の保護提案のないＩＮＶＩＴＥを受信し、応答者ユーザエンティティ１４がメディア保護をサポートすることをチェックし、第２の保護提案をＩＮＶＩＴＥに挿入し、そしてＩＮＶＩＴＥを応答者ユーザエンティティ１４へ転送し、ここで応答者ユーザエンティティ１４は、第２の保護提案を有するＩＮＶＩＴＥを受け入れ、そして、第１の保護受入れを有する確認応答を使って応答する。
【００２０】
システム１０は、ユーザエンティティ・メディアプレーン・ハンドラ２０を有し、そして、応答者ユーザエンティティ１４は、鍵材料を導出して、ユーザエンティティ・メディアプレーン・ハンドラ２０への信号と一緒にＳＡを確立し、ＳＡに基づく即時保護を可能にするよう、ユーザエンティティ・メディアプレーン・ハンドラ２０に命令することが好ましい。システム１０は、応答者ユーザエンティティ１４と通信する応答者側Ｐ−ＣＳＣＦ２２を有し、応答者側Ｐ−ＣＳＣＦ２２は、応答者ユーザエンティティ１４から確認応答を受信して確認応答を受信端Ｓ−ＣＳＣＦ１８へ転送することが好ましい。応答者側Ｓ−ＣＳＣＦ１８は、確認応答の中の第１の保護受入れを削除して、受入れのない確認応答を開始者側Ｓ−ＣＳＣＦ１６へ転送することが好ましい。ＳＡを確立することには、例えば、ユーザエンティティとメディアプレーン・ハンドラとが鍵の交換を行うこと、あるいは、他のやり方でＳＡをメディアプレーン・ハンドラに伝えることが含まれてもよいだろう。
【００２１】
開始者側Ｓ−ＣＳＣＦ１６は、保護が用いられるべきであるという第２の保護受入れを有するように、確認応答を修正することが好ましい。システム１０は、開始者側Ｓ−ＣＳＣＦ１６および開始者側ユーザエンティティと通信する開始者側Ｐ−ＣＳＣＦ２４を有することが好ましく、そして、開始者側Ｓ−ＣＳＣＦ１６は、第２の保護受入れを備えた確認応答を開始者側Ｐ−ＣＳＣＦ２４へ転送することが好ましい。開始者側Ｐ−ＣＳＣＦ２４は、第２の保護受入れを備えた確認応答を開始者ユーザエンティティ１４へ転送することが好ましい。
【００２２】
開始者側ユーザエンティティは第２の保護受入れを備えた確認応答をＰ−ＣＳＣＦから受信し、鍵材料を導出し、そして、ユーザエンティティ・メディアプレーン・ハンドラ２０への信号と共にＳＡを確立し、ＳＡに基づくメディア保護を可能にするようメディアプレーン・ハンドラ２０に命令することが好ましい。ＳＡを確立することには、例えば、ユーザエンティティとメディアプレーン・ハンドラとが鍵の交換を行うこと、あるいは、他のやり方でＳＡをメディアプレーン・ハンドラに伝えることが含まれてもよいだろう。
【００２３】
本発明は、保護されたメディアセッションを通信ノードによってサポートするための方法に関する。方法には、保護のための提案を有する、ユーザエンティティから応答者ユーザエンティティへのセッション制御招待メッセージを受信する各ステップが含まれる。ネットワークポリシーに従って招待メッセージからの提案に関して動作するステップがある。修正された提案を備えたメッセージを応答者当事者へ転送するステップがある。応答者当事者から返信される確認応答を受信するステップがある。保護エンドポートとなるように選択されたメディアプレーン・ハンドラにメディアトラヒックを向けるためのパラメータと、対応するＳＡを確立するための情報とを含むように、確認応答を修正するステップがある。
【００２４】
セッション制御招待メッセージを受信することには、ＳＩＰ ＩＮＶＩＴＥメッセージを受信するステップが含まれることが好ましい。動作するステップには、ＩＮＶＩＴＥメッセージから提案を削除するステップが含まれることが好ましい。ネットワークポリシーは、例えばトランスコーディング等を行う必要性によって示された、エンド・ツー・エンド対エンド・ツー・アクセスエッジ保護の適合性についての情報を備えることが好ましい。ＩＮＶＩＴＥメッセージを受信するステップには、開始者ユーザエンティティから応答者ＩＭＳユーザエンティティへの保護のための提案を有するＩＮＶＩＴＥメッセージを受信するステップが含まれることが好ましい。ＩＮＶＩＴＥメッセージを受信するステップには、鍵確立のためのパラメータを含む提案を有するＩＮＶＩＴＥメッセージを受信するステップが含まれることが好ましい。
【００２５】
ＳＡと共に用いられることになる保護のための鍵を導出するステップがあることが好ましい。ＩＭＳ開始者および／または応答者ユーザエンティティが端末のメディアセキュリティ能力を登録するステップがあることが好ましい。メディアセキュリティ能力には、エンド・ツー・アクセスエッジ保護と、ネットワークサポート機能が可能なエンド・ツー・エンド保護と、あるいは、忠実なエンド・ツー・エンド保護とのうち、少なくとも１つが含まれることが好ましい。導出するステップには、ＳＩＰシグナリングを保護するのに用いられる既存のセキュリティアソシエーション（セキュリティ関係付け）（ＳＡ）から、あるいは、鍵管理システムを使って、あるいは、公開鍵の解決策に基づく端末でのオンライン鍵生成によって、鍵を導出するステップが含まれることが好ましい。
【００２６】
鍵を導出してそれをメディア保護が用いられるべきであるという命令と一緒にメディアプレーン・ハンドラへ送信するようにＰ−ＣＳＣＦに命令するステップがあることが好ましい。Ｐ−ＣＳＣＦとＳ−ＣＳＣＦとのいずれか一方からＳＡを検索し、鍵を導出し、そして鍵をメディア保護が用いられるべきであるという命令と一緒にメディアプレーン・ハンドラへ送信するステップがあることが好ましい。メディア保護が適用されることをメディアプレーン・ハンドラに命令し、そして、メディアプレーン・ハンドラがＰ−ＣＳＣＦに鍵を要求するステップがあることが好ましい。
【００２７】
また、本発明は、保護されたメディアセッションを、例えば応答者側Ｓ−ＣＳＣＦのような通信ノードによってサポートするための方法に関する。方法には、メディア保護のための提案を有していない、開始者側Ｓ−ＣＳＣＦユーザエンティティから応答者ユーザエンティティへのセッション制御招待メッセージを受信する各ステップが含まれる。応答者ユーザエンティティの登録されたセキュリティ能力に従って招待メッセージからの提案に関して動作するステップがある。修正された提案を備えたメッセージを応答者ユーザエンティティへ転送するステップがある。第１の保護受入れを備えた、応答者当事者から返信される確認応答を受信するステップがある。確認応答の中の第１の保護受入れを削除するステップがある。受入れを有していない確認応答を開始者側Ｓ−ＣＳＣＦへ転送するステップがある。
【００２８】
図５を参照すると、本発明は、通信ネットワークにおいて開始者ユーザエンティティと応答者ユーザエンティティとの間のメディア制御シグナリングメッセージを処理して転送することによって動作する、メディア制御シグナリングエンティティに関する。メディア制御シグナリングエンティティは、第１の招待メッセージを開始者ユーザエンティティから受信するための第１のネットワークインタフェースを備える。メディア制御シグナリングエンティティは、第２の招待メッセージを応答者ユーザエンティティへ転送するための第２のネットワークインタフェースを備える。メディア制御シグナリングエンティティは、前記第１および第２のネットワークインタフェースと通信する処理ユニットを備える。処理ユニットは、第１の招待メッセージから以下によって第２の招待メッセージを作成するよう動作可能であり、すなわち、
第１の招待メッセージがメディア保護のための第１の提案を有するかどうか判定し、
第１の招待メッセージの中に含まれる場合には第１のメディア保護提案を少なくとも削除して、
第１の招待メッセージには第１の保護提案がなく、かつ、前記応答者ユーザエンティティが少なくとも１つのメディアセキュリティ能力を前記通信ネットワークに登録している場合には、前記登録されたメディアセキュリティ能力に対応するような第２のメディア保護提案を少なくとも挿入することによって、
第１の招待メッセージから第２の招待メッセージを作成する。
【００２９】
第２のメディア保護提案は、エンド・ツー・アクセスエッジのメディア保護についての提案であってもよい。第１および第２の招待メッセージは、ＳＩＰメッセージであってもよい。メディア制御シグナリングエンティティは、さらにＳ−ＣＳＣＦ機能を備えてもよい。
【００３０】
本発明の動作において、本発明は、ＩＭＳの枠組みの中で記述される。第１に、留意されることだが、ＩＭＳユーザはＩＭＳシステム１０に「登録」しなければならず、かつ、登録の際、エンドユーザは端末のメディアセキュリティ能力も登録すべきである。本発明は、上記のとおり、３つの新たなメディアセキュリティ能力、すなわち、エンド・ツー・アクセスエッジ（ｅ２ａｅ）、ネットワークサポート機能が可能なエンド・ツー・エンド（ｅ２ｎ２ｅ）、または忠実なエンド・ツー・エンド（ｅ２ｅ）保護を導入する。ここで留意すべきだが、これらのセキュリティ能力は、鍵管理のタイプの指標と、端末がサポートするセキュリティプロトコルの指標とを伴う必要がある。本記述では、端末は少なくともｅ２ａｅ保護についてのサポートを登録すると想定されている。鍵管理については、３つの異なる使用例がある。第１は、ＳＩＰシグナリングを保護するのに用いられる既存のセキュリティアソシエーション（ＳＡ）から鍵が導出されることであり、第２の例は、別個の鍵管理システムが用いられる場合であり、特にＰＣＴ／ＳＥ２００７／０５０９２７に記述された鍵管理がそうだが、事前に配布された鍵を伴うこともあり、そして、最後に、第３の鍵管理システム１０は、例えばＭＩＫＥＹまたはＩＫＥｖ２による、例えばＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ（ＤＨ）またはその他のＰｕｂｌｉｃ Ｋｅｙ（ＰＫ）解決策に基づく端末でのオンライン鍵生成に依存することである。セキュリティプロトコルはＳＲＴＰであることが好ましいが、その他のプロトコル、例えばＴＬＳ、ＩＰｓｅｃ等も可能である。
【００３１】
ｅ２ａｅメディア保護については、原則として、開始者と応答者ユーザエンティティとが独立して扱われることが認められている。例えば、開始者には、或るタイプのメディア保護が行われ、そして、応答者には別のタイプ（保護なしもありうる）が行われてもよい。以下の記述では、開始者側の手順について最初に記述し、次いで、応答者側の手順について記述する。
【００３２】
ＩＭＳにおいて１人のユーザが呼を開始し、ＩＮＶＩＴＥメッセージを応答者当事者へ送信する。ＩＮＶＩＴＥメッセージには、ｅ２ａｅ保護についての提案が含まれてもよい。この提案は、開始者側Ｓ−ＣＳＣＦによって検出されて処理されるが、開始者側Ｓ−ＣＳＣＦは、ＩＮＶＩＴＥが応答者当事者へ転送される前にＩＮＶＩＴＥからそれを削除するであろう。応答者当事者が「２００ ＯＫ」を返すと、Ｓ−ＣＳＣＦは、保護提案が受け入れられたことを示すようにＯＫを修正するであろう。修正されたＯＫメッセージには、端末がそのメディアトラヒックを、保護エンドポイントとして選択されたエッジエンティティへ向けるのに必要なすべてのパラメータと、対応するＳＡを確立するのに必要なすべての情報とが含まれるであろう。すでに述べたように、使用されることになる鍵は、端末とネットワークとで共有される既存のＳＡから導出されてもよいし、別個の鍵管理システム１０の助けで確立されてもよいし、あるいは、保護エンドポイントによってオンザフライ（Ｄ−Ｈ、ＰＫ）で生成されてもよいだろう。エンドポイントにおける鍵生成に基づく保護メカニズムの一例として、ＩＥＴＦにおいて開発された解決策があり、ＲＴＰＳＥＣと呼ばれている。
【００３３】
ここで、図４を参照すると、開始者端末がｅ２ａｅ保護提案を除外しているのに開始者側Ｓ−ＣＳＣＦは依然としてｅ２ａｅ保護の使用を実行することを望んでいる場合には、開始者側Ｓ−ＣＳＣＦは、ＩＮＶＩＴＥの中のサービス、すなわち保護のないこと、は利用可能でないということを示すＳＩＰエラーメッセージ（例えば「４８８ ＮＯＴ ＡＣＣＥＰＴＡＢＬＥ ＨＥＲＥ」）を送信することによって、それに関して動作してもよく、そして、例えばネットワーク（セキュリティ）ポリシーに起因して、端末はエンド・ツー・エッジ保護を用いるべきであるということを端末に対して示してもよい。もちろん、これを行う前に、開始者側Ｓ−ＣＳＣＦは、開始者端末がｅ２ａｅ能力をサポートしていることを開始者端末がすでに登録していることをチェックすべきである。応答者側でのアクセスエッジ・ツー・エンド保護の適用は、純粋にネットワークポリシーに基づく決定であってもよいだろう。しかし、好ましくは開始者側がこのタイプの保護を適用する場合に呼が応答者側でも同レベルの保護が与えられるべきであるということを応答者側に知らせることを目的として、これがＳＩＰシグナリング中に示されることは、検討されてもよいだろう。
【００３４】
応答者側では、応答者端末がｅ２ａｅ暗号化をサポートするかどうかを、応答者当事者のＳ−ＣＳＣＦがチェックする。そうであれば、応答者当事者のＳ−ＣＳＣＦはそれに関して動作し、そして、ｅ２ａｅメディア保護の提案をＩＮＶＩＴＥメッセージに挿入する。端末は、保護提案を受け入れる。鍵生成／管理は、開始者側と同じやり方で機能する。
【００３５】
ｅ２ａｅ保護を用いるという提案は、例えばＭＩＫＥＹ［ＲＦＣ３８３０、ＲＦＣ４５６７］またはＳＤＥＳ［ＲＦＣ４５６８］に従ってＳＩＰメッセージのＳＤＰ部分の中で搬送することができる。メッセージのＳＤＰ部分に提供されているキーイング情報は、後でＳＲＴＰをセットアップするために用いることができる。他のメディア、例えばＭＳＲＰについては、提供されるキーイング情報に基づいて、ＰＳＫ−ＴＬＳを用いてもよいだろう。また、ＭＥＳＳＡＧＥによってＳＩＰの中で搬送されるコンテンツ／メッセージを保護するため、他のメディア保護プロトコルが用いられてもよい。
【００３６】
メディア保護のために用いられることになる鍵は、開始者／応答者端末と開始者／応答者側Ｐ−ＣＳＣＦとの間のＳＩＰシグナリングを保護するのに用いられる鍵から導出されてもよい。鍵は、保護が適用されるべきだということをＳＩＰメッセージの検査からＰ−ＣＳＣＦが判断する場合にＰ−ＣＳＣＦからメディアプレーン・ハンドラ（例えばＳＧＷ、ＡＳ、ＢＥ、またはＥＥ）へプッシュされてもよいだろうし、あるいは、開始者（もしくは応答者）側Ｓ−ＣＳＣＦが、開始者（もしくは応答者）側Ｐ−ＣＳＣＦにそれらを配信するように命令することもできるし、あるいは、Ｓ−ＣＳＣＦ自身がキーイング情報を転送することもできる。キーイング材料が別のＳＡから来る場合、それに応じて鍵配布メカニズムが構成される必要がある。
【００３７】
ＰＣ／ＳＥ２００７／０５０９２７に記述された鍵管理解決策が用いられる場合、発信端末は、Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ（ＫＭＳ）に鍵とバウチャーとを要求し、そして、バウチャーをＩＮＶＩＴＥの中に含める。Ｓ−ＣＳＣＦは、バウチャーを取り出して、それをＫＭＳに提示し、ＫＭＳは、使用されることになる鍵を返信する。応答者側では、Ｓ−ＣＳＣＦは、ＫＭＳに鍵と（新たな）バウチャーとを要求し、そしてそれをＩＮＶＩＴＥの中に含めるであろう。次いで、応答者は、それをＫＭＳに提示し、対応する鍵を要求するであろう。
【００３８】
Ｅ２ｎ２ｅとｅ２ｍ
Ｅ２ｎ２ｅとｅ２ｍとの場合は、上記の記述の若干の変形とみなすことが容易にできる。
【００３９】
この場合の主な違いは、着信するメディアが保護されるだけでなく、発信するメディアも保護されることを、制御エンティティ（例えばＳ−ＣＳＣＦ／ＭＲＦＣ）が保証する必要があることである。保護が同一ノード内で終了し、かつ、開始される場合（典型的にはｅ２ｎ２ｅについて）、これは大きな問題ではないが、保護が１つのノード内で終了し、そして別のノードで開始される場合（ｅ２ｍ）、何らかの種類の指標が、第１のノードから第２のノードへ信号で伝えられる必要がある。
【００４０】
（忠実な）ｅ２ｅの場合は、どのネットワークエンティティも保護能力のシグナリングにおいてアクティブな役割を持たないという点が異なる。この場合、発信者／着信者のＳ−ＣＳＣＦは、（ネットワークポリシーがｅ２ｅ保護を認めていると想定して）単純に招待の中の保護提案に自分の中を通過させるであろう。
【００４１】
非常に高いレベルの簡略化されたシグナリング図を図１に示す。シグナリングフローの説明を以下に記す。図は、ＳＩＰシグナリングを保護するために用いられる既存のＳＡに鍵が基づいている場合のｅ２ａｅ保護を対象としている。
【００４２】
１ａ／ｂ 開始者ＵＥが、少なくともｅ２ａｅ保護に関する自分の能力を含むＲＥＧＩＳＴＥＲを送信することによって、ＩＭＳシステム１０に登録する。
【００４３】
２ａ／ｂ 開始者ＵＥが、登録を有効にするために認証される。
【００４４】
３ａ／ｂ 開始者ＵＥが、登録を確認する２００ ＯＫを入手する。そして、登録されたｅ２ａｅ能力のサポートを確認応答してもよい。
【００４５】
４ 開始者ＵＥが、鍵確立のためのパラメータを含めて、ｅ２ａｅ保護を用いるための提案を有するＩＮＶＩＴＥを送信する。
【００４６】
開始者側Ｓ−ＣＳＣＦ１６が、ＩＮＶＩＴＥを検査して、ｅ２ａｅ保護が提案されていることに気付く。ネットワークはｅ２ａｅ保護が可能なので、ネットワークは提案を暗黙のうちに受け入れて、決定を記憶する。
【００４７】
ここで留意すべきだが、開始者側Ｐ−ＣＳＣＦは、この段階では何もしない。
【００４８】
開始者側Ｓ−ＣＳＣＦは、Ｓ−ＣＳＣＦにおいて行われるのならば、ＳＡの導出をすでにここで開始してもよく、そして、導出された鍵をＭＲＦＣへ送信してもよい。鍵の導出が開始者側Ｐ−ＣＳＣＦで行われるのならば、導出は延期される。
【００４９】
５ 開始者側Ｓ−ＣＳＣＦ１６は、ＩＮＶＩＴＥからｅ２ａｅ保護提案を削除し、それを応答者側Ｓ−ＣＳＣＦ１８へ転送する。
【００５０】
応答者側Ｓ−ＣＳＣＦ１８が、ＩＮＶＩＴＥを検査し、応答者当事者がｅ２ａｅ保護をサポートするかどうかをチェックする（応答者はこれをすでに登録していると想定されている）。
【００５１】
６ 応答者側Ｓ−ＣＳＣＦ１８が、ＩＮＶＩＴＥが応答者ＵＥへ転送される前にｅ２ａｅ保護提案を挿入する。提案には、共有ＳＡを確立するのに必要なパラメータが含まれる。また、ＳＤＰ部分は、メディアプレーン・ハンドラが通常のメディア経路に含まれない別個のエンティティである場合、メディアを（ここではＳＧＷであると想定される）メディアプレーン・ハンドラを介してルーティングするよう変更されなければならない。
【００５２】
応答者ＵＥは、ｅ２ａｅ提案を含むＩＮＶＩＴＥを受け入れる。応答者ＵＥは、使用されることになる鍵を導出して、ＵＥメディアプレーン・ハンドラ２０への信号と一緒にＳＡを確立し、そのＳＡに基づいてメディア保護を可能にするようメディアプレーン・ハンドラ２０に命令する。
【００５３】
７ 応答者ＵＥは、２００ ＯＫを使って応答し、ｅ２ａｅ提案を受け入れる。応答者側のＰ−ＣＳＣＦ２２が２００ ＯＫを受信し、かつ、ｅ２ａｅ保護についてのＳＡを生成することがＰ−ＣＳＣＦの責任である場合には、Ｐ−ＣＳＣＦは２００ ＯＫを検査してＳＡを導出する。次いで、応答者側Ｐ−ＣＳＣＦは、ＳＡと必要なその他の情報とをＳＧＷにプッシュして、メディア保護を可能にするように要求するであろう。
【００５４】
８ 応答者側Ｐ−ＣＳＣＦは、２００ ＯＫを応答者側Ｓ−ＣＳＣＦ１８へ転送する。
【００５５】
ＳＡを生成することが応答者側Ｓ−ＣＳＣＦの責任である場合、応答者側Ｓ−ＣＳＣＦはそれを行って、その情報をＳＧＷへプッシュするであろう（Ｐ−ＣＳＣＦについて述べたのと同じ手順）。
【００５６】
９ 応答者側Ｓ−ＣＳＣＦ１８は、２００ ＯＫの中のｅ２ａｅ保護受入れを削除し、修正された２００ ＯＫを開始者側Ｓ−ＣＳＣＦ１６へ転送する。
【００５７】
開始者側Ｓ−ＣＳＣＦ１６は、ｅ２ａｅ保護が用いられるべきであることを記憶しており、これを示すために２００ ＯＫを修正する。
【００５８】
使用されることになるＳＡを生成することが開始者側Ｓ−ＣＳＣＦの責任である場合、開始者側Ｓ−ＣＳＣＦはこれを行って、それをＳＧＷによって必要とされる他の情報と一緒にプッシュし、そして、メディア保護を可能にするようＳＧＷに要求する。
【００５９】
１０ 開始者側Ｓ−ＣＳＣＦは、ｅ２ａｅ保護を用いることの受入れを伴う２００ ＯＫを開始者側Ｐ−ＣＳＣＦへ転送する。
【００６０】
ｅ２ａｅ保護のためのＳＡを生成することが開始者側Ｐ−ＣＳＣＦの責任である場合、開始者側Ｐ−ＣＳＣＦは２００ ＯＫを検査して、ｅ２ａｅ保護が合意されたことに気付き、従ってＳＡを導出する。次いで、開始者側Ｐ−ＣＳＣＦは、ＳＡとＳＧＷによって必要とされるその他の情報とをプッシュして、ＳＧＷがメディア保護を可能にするよう要求する。
【００６１】
１１ 開始者側Ｐ−ＣＳＣＦは、２００ ＯＫを開始者ＵＥへ転送する。ＵＥは、ｅ２ａｅ保護提案が受け入れられたことに気付き、使用されることになる鍵を導出する。ＵＥは、ＵＥメディアプレーン・ハンドラ２０への信号と一緒にＳＡを確立し、提供されたＳＡに基づいてメディア保護を可能にするようメディアプレーン・ハンドラ２０に命令する。
【００６２】
上述したように、ＳＤＥＳもしくはＭＩＫＥＹを用いてＳＤＰの中で提案と応答とを搬送することができるであろうが、その他の符号化を考えることも可能である。
【００６３】
実際には、メディアセキュリティは、ＩＭＳについては異なるエッジデバイス（メディアプレーン・ハンドラ）に終端されてもよい。また、これは、メディアプレーン・ハンドラが標準的にメディア経路に含まれているのかどうか、あるいは、メディアプレーン・ハンドラの存在は、例えばｅ２ａｅ保護のためのエンドポイントとして動作する必要性に起因するだけなのかにも依存する。前者の場合はセキュリティデータのメディアプレーン・ハンドラへのシグナリングが既存のセットアップシグナリングの中に「抱き合わせ」られてもよいのに対し、第２の場合、（そのトラヒックをリダイレクトするためのＵＥへの信号を含めて）明確なシグナリングが必要となる可能性がある。上記の記述は、メディアが終端される場所によって若干異なる。保護がＭＲＦＰで終わる場合、ＭＲＦＣが、導出された鍵をＳ−ＣＳＣＦから受信して、これをＭＲＦＰまでプッシュする必要があるエンティティとなるであろう。
【００６４】
メディアセキュリティ能力の利用は以下のとおりである。
【００６５】
・端末が、サポートされた能力を登録する。これは、ネットワークによって開始される保護を可能にするためであり、これは、ｅ２ａｅもしくはｅ２ｎ２ｅだけである可能性が非常に高いであろう。
【００６６】
・ネットワークは、例えばポリシーに従って、一定のメディアセキュリティモードはサポートされないことを決定してもよく、従って、メディアセキュリティモードがサポートされないことをＵＥに示してもよい。
【００６７】
・２つ以上の能力が登録された場合、使用すべき最も良いメディアセキュリティ解決策とは何か、すなわち、ｅ２ｅ、ｅ２ｎ２ｅ、またはｅ２ａｅを使用するかどうかを発見するために、後でネットワークによって、または別の端末によって、これが用いられてもよい。
【００６８】
・ＵＥがＩＮＶＩＴＥを、例えばｅ２ｅ提案とｅ２ａｅ提案とを両方添えて別のＵＥへ送信する場合、２つのエンドポイントの中間にある各エンティティは、それらがこれらをサポートするということ、および／または、ネットワークポリシーがそれらを許可するということを検証する必要がある。例えば、これらのうちの１つがサポートされない場合、ネットワークは、例えばネットワークがサポートしない能力を削除することによって、これを示すことができるであろうし、従って、着信ＵＥが要求を受信する場合、着信ＵＥは、発信ＵＥと中間のすべてのネットワークエンティティとの両方がサポートする残った選択肢だけを持つであろう。これを処理するもう１つのやり方は、特定のメディアセキュリティ能力をサポートしないいずれかのネットワークエンティティに、これを示すエラーを返信させることである。そうすれば、その後、ＵＥは、その能力を用いずに再試行しなければならなくなるであろう。
【００６９】
既存のＳＡに基づくｅ２ａｅ保護のための鍵
Ｐ−ＣＳＣＦと端末との間のＳＩＰシグナリングを保護するためにＩＰｓｅｃが用いられる場合、用いられる鍵は、Ｐ−ＣＳＣＦにおいて利用可能であろうし、Ｓ−ＣＳＣＦにおいても場合によっては利用可能であろう。ｈｔｔｐダイジェストによるサーバ証明書およびクライアント認証に基づくＴＬＳが用いられる場合には、ＴＬＳ ＳＡはＰ−ＣＳＣＦにおいてのみ利用可能であろう。
【００７０】
いずれにせよ、Ｓ−ＣＳＣＦまたは関連のＭＲＦは、ポリシー制御を行うことと鍵の導出および配信を開始することとに責任を有するであろう。既存のシステムにおいて行われる実装の選択に応じて、どうすればこの機能が最も良く実装されるかに関して、多様な選択肢がある。主要な観点から、以下の選択肢がありうる。
【００７１】
１．Ｓ−ＣＳＣＦ／ＭＲＦがＰ−ＣＳＣＦに、メディア保護鍵を導出し、それをメディア保護が用いられるべきだという命令と一緒にメディアプレーン・ハンドラへ送信するよう、命令するであろう。
【００７２】
２．Ｓ−ＣＳＣＦ／ＭＲＦが、Ｐ−ＣＳＣＦ（もしくはＳ−ＣＳＣＦ）からＳＡを取り出して鍵を導出し、それをメディア保護が用いられるべきだという命令と一緒にメディアプレーン・ハンドラへ送信するであろう。
【００７３】
３．Ｓ−ＣＳＣＦ／ＭＲＦがメディアプレーン・ハンドラに、メディア保護が適用されるべきだと命令し、メディアプレーン・ハンドラが、導出された鍵をＰ−ＣＳＣＦに要求するであろう。
【００７４】
４．Ｓ−ＣＳＣＦ／ＭＲＦがメディアプレーン・ハンドラに、例えば上記の１乃至３のいずれかに従って導出された鍵に基づいて、または、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵技術を用いて、ＵＥとのＳＡを明確に確立すべきだと命令するであろう。
【００７５】
バウチャーに基づく鍵
この場合、Ｓ−ＣＳＣＦ／ＭＲＦは、受信したバウチャーをＫＭＳへ送信して、対応する鍵を要求するであろう。次いで、メディア保護が用いられるべきだという命令と一緒に鍵をＳＧＷへ送信するであろう。これについては、特許出願ＰＣＴ／ＳＥ２００７／０５０９２７に詳細に記述されている。
【００７６】
保護を開始する際に、Ｓ−ＣＳＣＦ／ＭＲＦは、ＫＭＳに鍵とバウチャーを要求するであろう。
【００７７】
図２に、本書で用いられる参照アーキテクチャを示す。
【００７８】
ユーザ／メディアプレーンノードをボックス１１に示し、ＳＩＰ制御プレーンノードをボックス１５に示す。ＥＥは、固定コアネットワークの端にある（何らかの）エッジエンティティである。ＢＥは、２つのネットワーク間の境界にある何らかのボーダエンティティである。ＡＳは、何らかのＩＭＳアプリケーションかまたはＯＭＡイネーブラ、例えばＰｏＣサーバまたはＩｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇサーバである。（上記で用いた表記法では、ＡＳ、ＥＥ、およびＢＥはすべてメディアプレーン・ハンドラである。）
【００７９】
図２は、ＡとＢが両方共ＩＳＩＭ対応のユーザであると想定しているが、ＩＭＳは多くの異なるアクセス技術に共通であることが想定されているため、（ハードトークン）ＵＩＣＣの使用を必要とすることは、特に非ＩＳＩＭに基づくメカニズムがすでにＩＭＳ認証用に存在することから、制限的すぎるかもしれない。
【００８０】
直接的な解決策は、ソフトＩＳＩＭの利用も可能にすることである。しかし、これでさえ、他の形のユーザ信用保証情報、例えばハードウェアもしくはソフトウェアとして配信される公開鍵／秘密鍵の配置も存在することから、制限である可能性がある。
【００８１】
従って、ＩＳＩＭのサポートは第一に取り組むべき関心事ではあるものの、目標とする解決策は、何らかの形の暗号による（秘密鍵をベースにした）ユーザ信用保証情報が用いられることと、この信用保証情報は、ユーザを認証して一般的な共有の（ベースとなる）セッション鍵を確立するために用いられうることとを想定するに留まるであろう。このカテゴリに入る解決策は、ＩＳＩＭ、ＰＫＩ、ＩＢＣ（アイデンティティに基づく暗号化）、ユーザ名／パスワード等である。
【００８２】
以下は、本発明によってサポートすることができるＩＭＳサービスの例である。
【００８３】
ＭＭＴＥＬ
これは、従来型のピア・ツー・ピア（Ｐ２Ｐ）マルチメディア電話もしくは小規模グループでの電話会議を意味する。グループの場合には、「会議ブリッジ」がＩＭＳ ＡＳまたはＯＭＡイネーブラとして実装されると想定される。セットアップは、通常のＳＩＰメカニズムを介してシグナリングされ、そして、メディアは、ＲＴＰによって搬送される。グループの場合には、ＳＩＰサーバ（ＣＳＣＦ）は、例えば、セキュリティが、各ユーザとＡＳまたはイネーブラとの間でｅ２ｍで提供されるように、ＳＩＰ提案の中のセキュリティを修正してもよいだろう。
【００８４】
プッシュ・トゥー・トーク
ここで、ＰｏＣサービスとは、ＳＩＰシグナリングを用いて設定され、ＰｏＣサーバがアプリケーションサーバ（ＡＳ）としてかまたは、ＲＴＰトランスポートされたメディアを各受信器に配信するためのイネーブラとして用いられるようなサービスのことを言う。実際の製品の中の「ＰｏＣサーバ」は、通常は制御プレーン部分のことを言うが、本書では、制御プレーン部分とメディアプレーン（ＭＲＦ）部分との両方のことを総称して「ＰｏＣサーバ」と言う。この場合も、上記の電話会議と同様に処理することができるであろう。
【００８５】
メッセージング
これは、ＳＩＰ本体の中で直接搬送されるかまたは、ＳＩＰによってセットアップされてＭＳＲＰ上を搬送されるかいずれか一方のメッセージであってもよい。ＡＳ／イネーブラは、メッセージングサーバとして動作する。また本書では、メッセージは、Ｐ２Ｐであってもよいし、グループに向けられてもよい。
【００８６】
インスタントサービス対延期サービス
メッセージングサービスは典型的には、受信者がオンラインではない場合、メッセージが自動的に延期メッセージに変換されて、受信者が登録するまでＡＳの中に記憶されるように実装される。実際、ＭＭＴＥＬおよびＰｏＣも、「留守電マシン」として動作するサーバとの延期配信をサポートすることができる。
【００８７】
ＨＳＳ、ＣＳＣＦ、ＭＲＦ等といった周知のＩＭＳ関連用語以外に、本書では下記の略語が用いられる。
【００８８】
ＡＳ （ＩＭＳ）アプリケーションサーバ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）
ＢＥ ボーダエンティティ（Ｂｏｒｄｅｒ Ｅｎｔｉｔｙ）
ＢＳＦ ブートストラッピングサーバ機能（Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ）
ＥＥ エッジエンティティ（Ｅｄｇｅ Ｅｎｔｉｔｙ）
ＥＰＳ 進化型パケットシステム（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）
ＧＢＡ 汎用ブートストラッピングアーキテクチャ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）
ＬＥＡ 司法当局（Ｌａｗ Ｅｎｆｏｒｃｅｍｅｎｔ Ａｇｅｎｃｙ）
ＬＩ 合法的なインターセプト（Ｌａｗｆｕｌ Ｉｎｔｅｒｃｅｐｔ）
ＮＡＦ ネットワークアプリケーション機能（Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）
ＮＳＰＳ （Ｎａｔｉｏｎａｌ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｕｂｌｉｃ Ｓａｆｅｔｙ）
Ｐ２Ｐ ピア・ツー・ピア（Ｐｅｅｒ−ｔｏ−ｐｅｅｒ）
ＣＢＧＦ コア・ボーダ・ゲートウェイ機能（Ｃｏｒｅ Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｆｕｎｃｔｉｏｎ）
ＣＳＣＦ 呼状態制御機能（Ｃａｌｌ Ｓｔａｔｅ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）
ＤＨ （Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）
ｅ２ａｅ エンド・ツー・アクセス・エッジ（Ｅｎｄ−ｔｏ−Ａｃｃｅｓｓ−Ｅｄｇｅ）
ｅ２ｅ エンド・ツー・エンド（Ｅｎｄ−ｔｏ−ｅｎｄ）
ＦＭＣ 固定移動体融合（Ｆｉｘｅｄ−Ｍｏｂｉｌｅ Ｃｏｎｖｅｒｇｅｎｃｅ）
ＧＳＭ （Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）
ＩＫＥ インターネット鍵交換（Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ）（ＲＦＣ ４３０６）
ＩＭ インスタント・メッセージング（Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ）
ＩＭＳ ＩＰマルチメディア・サブシステム（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）（３ＧＰＰ標準）
ＩＰＳｅｃ （ＩＰ Ｓｅｃｕｒｉｔｙ ｐｒｏｔｏｃｏｌ）（ＲＦＣ ４３０１）
ＫＭＳ 鍵管理サーバ（Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ）
ＭＩＫＥＹ （Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｎｅｔ ＫＥＹｉｎｇ）（ＲＦＣ ３８３０）
ＭＭＴＥＬ （Ｍｕｌｔｉｍｅｄｉａ ＴＥＬｅｐｈｏｎｙ）
ＭＲＦ マルチメディアリソース機能（Ｍｕｌｔｉｍｅｄｉａ Ｒｅｓｏｕｒｃｅ Ｆｕｎｃｔｉｏｎ）
ＭＲＦＣ ＭＲＦ制御（ＭＲＦ Ｃｏｎｔｒｏｌ）
ＭＲＦＰ ＭＲＦプロセッサ（ＭＲＦ Ｐｒｏｃｅｓｓｏｒ）
ＭＳＲＰ メッセージ・セッション・リレー・プロトコル（Ｍｅｓｓａｇｅ Ｓｅｓｓｉｏｎ Ｒｅｌａｙ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ ４９７５）
Ｐ−ＣＳＣＦ プロキシＣＳＣＦ（Ｐｒｏｘｙ−ＣＳＣＦ）
ＰＫ 公開鍵（Ｐｕｂｌｉｃ Ｋｅｙ）
ＰｏＣ セルラーを用いたプッシュ・トゥー・トーク（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ）
ＰＳＫ−ＴＬＳ （Ｐｒｅ−ｓｈａｒｅｄ Ｋｅｙ ＴＬＳ）
ＲＴＰ リアルタイム伝送プロトコル（Ｒｅａｌ ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ ３５５０）
ＲＴＰＳＥＣ （ＲＴＰ Ｓｅｃｕｒｅ Ｋｅｙｉｎｇ）
ＳＡ セキュリティアソシエーション（Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ）
Ｓ−ＣＳＣＦ サービングＣＳＣＦ（Ｓｅｒｖｉｎｇ−ＣＳＣＦ）
ＳＤＥＳ セッション記述プロトコルのセキュリティ記述（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ Ｄｅｓｃｒｉｐｔｉｏｎｓ）（ＲＦＣ ４５６８）
ＳＤＰ セッション記述プロトコル（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ ４５６６）
ＳＧＷ セキュリティゲートウェイ（Ｓｅｃｕｒｉｔｙ Ｇａｔｅｗａｙ）
ＳＩＰ セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ ３２６１）
ＳＲＴＰ （Ｓｅｃｕｒｅ Ｒｅａｌ ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ ３７１１）
ＴＬＳ （Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）（ＲＦＣ ５２４６）
ＵＥ ユーザ装置（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）
ＷＣＤＭＡ 広帯域符号分割多元接続（Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）
ＷｉＭＡＸ （Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）（ＩＥＥＥ ８０２．１６）
ＷＬＡＮ 無線ローカルアクセスネットワーク（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）（ＩＥＥＥ ８０２．１１）
【００８９】
本発明について前記の諸実施形態において例示する目的で詳細に記述してきたが、理解されるべきだが、そのような詳細は、そのことだけを目的にしており、そして、下記の請求項で記述されることを除いて、本発明の精神と範囲とから逸脱することなく、当業者によって変形形態がこの中に作られうる。
【特許請求の範囲】
【請求項１】
保護されたメディアセッションを通信ノードによってサポートする方法であって、
保護のための第１の提案を有する、開始者ユーザエンティティから応答者ユーザエンティティへのセッション制御招待メッセージを受信するステップと、
ネットワークポリシーに従って前記招待メッセージからの前記提案に関して動作するステップと、
修正された提案を伴う前記メッセージを前記応答者ユーザエンティティへ転送するステップと、
前記応答者ユーザエンティティから返信される確認応答を受信するステップと、
保護エンドポートとなるように選択されたメディアプレーン・ハンドラとの対応するＳＡ（セキュリティアソシエーション）を確立するための情報を含むように、前記確認応答を修正するステップと、
を備えることを特徴とする方法。
【請求項２】
前記確認応答を修正する前記ステップは、前記開始者ユーザエンティティが前記メディアプレーン・ハンドラにメディアトラヒックを向けるためのパラメータを含めるステップを更に備える
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記セッション制御招待メッセージを受信する前記ステップは、ＳＩＰ（セッション開始プロトコル） ＩＮＶＩＴＥメッセージを受信するステップを備える
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記動作するステップは、前記第１の提案を前記ＩＮＶＩＴＥメッセージから削除するステップを備え、
前記修正された提案は空である
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記ＩＮＶＩＴＥメッセージを受信する前記ステップは、保護のための前記第１の提案を有する、ＩＭＳ（ＩＰマルチメディア・システム）ユーザエンティティから応答者ＩＭＳユーザエンティティへの前記ＩＮＶＩＴＥメッセージを受信するステップを備える
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記ＩＮＶＩＴＥメッセージを受信する前記ステップは、鍵確立のためのパラメータを含んだ前記第１の提案を有する前記ＩＮＶＩＴＥメッセージを受信するステップを備える
ことを特徴とする請求項５に記載の方法。
【請求項７】
メディア保護のためのＳＡと共に使用される保護のための鍵を導出するステップ
を備えることを特徴とする請求項６に記載の方法。
【請求項８】
前記ＩＮＶＩＴＥを送信する前に、前記開始者ＩＭＳユーザエンティティおよび前記応答者ＩＭＳユーザエンティティのうちの少なくとも一方が端末のメディアセキュリティ能力を登録するステップ
を備えることを特徴とする請求項７に記載の方法。
【請求項９】
前記メディアセキュリティ能力は、エンド・ツー・アクセスエッジ、エンド・ツー・ミドル、ネットワークサポート機能が許可されたエンド・ツー・エンド、又は忠実なエンド・ツー・エンドの保護のうちの少なくとも１つを含む
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記導出するステップは、ＳＩＰシグナリングを保護するために使用される既に存在するセキュリティアソシエーションから鍵を導出するステップ、又は、鍵管理システムを用いて鍵を導出するステップ、又は、公開鍵の解決策に基づく前記端末でのオンライン鍵生成から鍵を導出するステップを備える
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記鍵を導出するようにＰ−ＣＳＣＦ（プロキシ呼状態制御機能）に命令し、その鍵をメディア保護が使用されるようにという命令と共に前記メディアプレーン・ハンドラへ送信するステップ
を備えることを特徴とする請求項１０に記載の方法。
【請求項１２】
Ｐ−ＣＳＣＦ又はＳ−ＣＳＣＦ（サービング呼状態制御機能）から前記ＳＡを取り出すステップと、
前記鍵を導出し、前記鍵をメディア保護が使用されるようにという命令と共に前記メディアプレーン・ハンドラへ送信するステップと、
を備えることを特徴とする請求項１１に記載の方法。
【請求項１３】
メディア保護が適用されるようにということを前記メディアプレーン・ハンドラに命令するステップと、
前記メディアプレーン・ハンドラがＰ−ＣＳＣＦに前記鍵を要求するステップと、
を備えることを特徴とする請求項１２に記載の方法。
【請求項１４】
ＩＭＳ（ＩＰマルチメディア・システム）システムであって、
ＩＭＳ開始者ユーザエンティティと、
前記開始者ユーザエンティティからの呼が着信するＩＭＳ応答者ユーザエンティティと、
前記開始者ユーザエンティティと通信する開始者側Ｓ−ＣＳＣＦ（サービング呼状態制御）と、
を備え、
前記開始者側Ｓ−ＣＳＣＦは、前記開始者ユーザエンティティから第１の保護提案と鍵確立のためのパラメータとを有するＩＮＶＩＴＥを受信し、前記第１の保護提案を前記ＩＮＶＩＴＥから削除し、そして、前記第１の保護提案のない前記ＩＮＶＩＴＥを転送するものであり、
前記システムは、
前記応答者ユーザエンティティおよび前記開始者側Ｓ−ＣＳＣＦと通信する応答者側Ｓ−ＣＳＣＦを備え、
前記応答者側Ｓ−ＣＳＣＦは、前記第１の保護提案のない前記ＩＮＶＩＴＥを受信し、前記応答者ユーザエンティティがメディア保護をサポートすることをチェックし、前記サポートされるメディア保護に対応する第２の保護提案を前記ＩＮＶＩＴＥに挿入し、そして、前記ＩＮＶＩＴＥを前記応答者ユーザエンティティへ転送するものであり、
前記応答者ユーザエンティティは、前記第２の保護提案を有する前記ＩＮＶＩＴＥを受け入れ、そして、第１の保護受入れを有する確認応答を使って応答する
ことを特徴とするシステム。
【請求項１５】
ユーザエンティティ・メディアプレーン・ハンドラを備え、
前記応答者ユーザエンティティは、前記ユーザエンティティ・メディアプレーン・ハンドラへの信号と一緒にＳＡを確立し、前記ＳＡ（セキュリティアソシエーション）に基づく即時保護を可能にするよう、前記ユーザエンティティ・メディアプレーン・ハンドラに命令する
ことを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記メディアプレーン・ハンドラは、セキュリティゲートウェイ（ＳＧＷ）、アプリケーションサーバ（ＡＳ）、エッジエンティティ（ＥＥ）、又はボーダエンティティ（ＢＥ）のうちのいずれかである
ことを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記応答者ユーザエンティティと通信する応答者側Ｐ−ＣＳＣＦ（プロキシ呼状態制御機能）を備え、
前記応答者側Ｐ−ＣＳＣＦは、前記応答者ユーザエンティティから前記確認応答を受信して前記確認応答を前記応答者側Ｓ−ＣＳＣＦへ転送する
ことを特徴とする請求項１５に記載のシステム。
【請求項１８】
前記応答者側Ｓ−ＣＳＣＦは、前記確認応答の中の前記第１の保護受入れを削除して、前記受入れのない前記確認応答を前記開始者側Ｓ−ＣＳＣＦへ転送する
ことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記開始者側Ｓ−ＣＳＣＦは、保護が用いられるべきであるという第２の保護受入れを含むように、前記確認応答を修正する
ことを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記開始者側Ｓ−ＣＳＣＦおよび前記開始者ユーザエンティティと通信する開始者側Ｐ−ＣＳＣＦを備え、
前記開始者側Ｓ−ＣＳＣＦは、前記第２の保護受入れを有する前記確認応答を前記開始者側Ｐ−ＣＳＣＦへ転送する
ことを特徴とする請求項１９に記載のシステム。
【請求項２１】
前記開始者側Ｐ−ＣＳＣＦは、前記第２の保護受入れを有する前記確認応答を前記開始者ユーザエンティティへ転送する
ことを特徴とする請求項２０に記載のシステム。
【請求項２２】
前記開始者ユーザエンティティは前記第２の保護受入れを有する前記確認応答を前記開始者側Ｐ−ＣＳＣＦから受信し、鍵を導出し、そして、前記ユーザエンティティ・メディアプレーン・ハンドラへの信号と共にＳＡを確立し、ＳＡに基づくメディア保護を可能にするよう前記メディアプレーン・ハンドラに命令する
ことを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記第１の提案は空であり、
前記動作するステップは、前記応答者ユーザエンティティの登録されたセキュリティ能力に更に依存し、
前記方法は、第２の空でない提案を前記ＩＮＶＩＴＥメッセージに挿入するステップを備える
ことを特徴とする請求項１に記載の方法。
【請求項２４】
前記挿入される第２の空でない提案は、前記応答者ユーザエンティティの登録されたセキュリティ能力に従って生成され、エンド・ツー・アクセスエッジのメディア保護を含む
ことを特徴とする請求項２３に記載の方法。
【請求項２５】
通信ネットワークにおいて開始者ユーザエンティティと応答者ユーザエンティティとの間のメディア制御シグナリングメッセージを処理して転送することによって動作する、メディア制御シグナリングエンティティであって、
第１の招待メッセージを前記開始者ユーザエンティティから受信するための第１のネットワークインタフェースと、
第２の招待メッセージを前記応答者ユーザエンティティへ転送するための第２のネットワークインタフェースと、
前記第１および第２のネットワークインタフェースと通信する処理ユニットと、
を備え、
前記処理ユニットは、前記第１の招待メッセージから前記第２の招待メッセージを作成するよう動作可能であり、そのために、
前記第１の招待メッセージがメディア保護のための第１の提案を有するかどうか判定し、
前記第１の招待メッセージの中に含まれる場合には前記第１のメディア保護提案を少なくとも削除して、
前記第１の招待メッセージには第１の保護提案がなく、かつ、前記応答者ユーザエンティティが少なくとも１つのメディアセキュリティ能力を前記通信ネットワークに登録している場合には、前記登録されたメディアセキュリティ能力に対応するような第２のメディア保護提案を少なくとも挿入することによって、
前記第１の招待メッセージから前記第２の招待メッセージを作成する
ことを特徴とするメディア制御シグナリングエンティティ。
【請求項２６】
前記第２のメディア保護提案は、エンド・ツー・アクセスエッジのメディア保護の提案である
ことを特徴とする請求項２５に記載のメディア制御シグナリングエンティティ。
【請求項２７】
前記第１および第２の招待メッセージはＳＩＰメッセージである
ことを特徴とする請求項２５に記載のメディア制御シグナリングエンティティ。
【請求項２８】
Ｓ−ＣＳＣＦ機能を更に備える
ことを特徴とする請求項２７に記載のメディア制御シグナリングエンティティ。
【請求項１】
保護されたメディアセッションを通信ノードによってサポートする方法であって、
保護のための第１の提案を有する、開始者ユーザエンティティから応答者ユーザエンティティへのセッション制御招待メッセージを受信するステップと、
ネットワークポリシーに従って前記招待メッセージからの前記提案に関して動作するステップと、
修正された提案を伴う前記メッセージを前記応答者ユーザエンティティへ転送するステップと、
前記応答者ユーザエンティティから返信される確認応答を受信するステップと、
保護エンドポートとなるように選択されたメディアプレーン・ハンドラとの対応するＳＡ（セキュリティアソシエーション）を確立するための情報を含むように、前記確認応答を修正するステップと、
を備えることを特徴とする方法。
【請求項２】
前記確認応答を修正する前記ステップは、前記開始者ユーザエンティティが前記メディアプレーン・ハンドラにメディアトラヒックを向けるためのパラメータを含めるステップを更に備える
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記セッション制御招待メッセージを受信する前記ステップは、ＳＩＰ（セッション開始プロトコル） ＩＮＶＩＴＥメッセージを受信するステップを備える
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記動作するステップは、前記第１の提案を前記ＩＮＶＩＴＥメッセージから削除するステップを備え、
前記修正された提案は空である
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記ＩＮＶＩＴＥメッセージを受信する前記ステップは、保護のための前記第１の提案を有する、ＩＭＳ（ＩＰマルチメディア・システム）ユーザエンティティから応答者ＩＭＳユーザエンティティへの前記ＩＮＶＩＴＥメッセージを受信するステップを備える
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記ＩＮＶＩＴＥメッセージを受信する前記ステップは、鍵確立のためのパラメータを含んだ前記第１の提案を有する前記ＩＮＶＩＴＥメッセージを受信するステップを備える
ことを特徴とする請求項５に記載の方法。
【請求項７】
メディア保護のためのＳＡと共に使用される保護のための鍵を導出するステップ
を備えることを特徴とする請求項６に記載の方法。
【請求項８】
前記ＩＮＶＩＴＥを送信する前に、前記開始者ＩＭＳユーザエンティティおよび前記応答者ＩＭＳユーザエンティティのうちの少なくとも一方が端末のメディアセキュリティ能力を登録するステップ
を備えることを特徴とする請求項７に記載の方法。
【請求項９】
前記メディアセキュリティ能力は、エンド・ツー・アクセスエッジ、エンド・ツー・ミドル、ネットワークサポート機能が許可されたエンド・ツー・エンド、又は忠実なエンド・ツー・エンドの保護のうちの少なくとも１つを含む
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記導出するステップは、ＳＩＰシグナリングを保護するために使用される既に存在するセキュリティアソシエーションから鍵を導出するステップ、又は、鍵管理システムを用いて鍵を導出するステップ、又は、公開鍵の解決策に基づく前記端末でのオンライン鍵生成から鍵を導出するステップを備える
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記鍵を導出するようにＰ−ＣＳＣＦ（プロキシ呼状態制御機能）に命令し、その鍵をメディア保護が使用されるようにという命令と共に前記メディアプレーン・ハンドラへ送信するステップ
を備えることを特徴とする請求項１０に記載の方法。
【請求項１２】
Ｐ−ＣＳＣＦ又はＳ−ＣＳＣＦ（サービング呼状態制御機能）から前記ＳＡを取り出すステップと、
前記鍵を導出し、前記鍵をメディア保護が使用されるようにという命令と共に前記メディアプレーン・ハンドラへ送信するステップと、
を備えることを特徴とする請求項１１に記載の方法。
【請求項１３】
メディア保護が適用されるようにということを前記メディアプレーン・ハンドラに命令するステップと、
前記メディアプレーン・ハンドラがＰ−ＣＳＣＦに前記鍵を要求するステップと、
を備えることを特徴とする請求項１２に記載の方法。
【請求項１４】
ＩＭＳ（ＩＰマルチメディア・システム）システムであって、
ＩＭＳ開始者ユーザエンティティと、
前記開始者ユーザエンティティからの呼が着信するＩＭＳ応答者ユーザエンティティと、
前記開始者ユーザエンティティと通信する開始者側Ｓ−ＣＳＣＦ（サービング呼状態制御）と、
を備え、
前記開始者側Ｓ−ＣＳＣＦは、前記開始者ユーザエンティティから第１の保護提案と鍵確立のためのパラメータとを有するＩＮＶＩＴＥを受信し、前記第１の保護提案を前記ＩＮＶＩＴＥから削除し、そして、前記第１の保護提案のない前記ＩＮＶＩＴＥを転送するものであり、
前記システムは、
前記応答者ユーザエンティティおよび前記開始者側Ｓ−ＣＳＣＦと通信する応答者側Ｓ−ＣＳＣＦを備え、
前記応答者側Ｓ−ＣＳＣＦは、前記第１の保護提案のない前記ＩＮＶＩＴＥを受信し、前記応答者ユーザエンティティがメディア保護をサポートすることをチェックし、前記サポートされるメディア保護に対応する第２の保護提案を前記ＩＮＶＩＴＥに挿入し、そして、前記ＩＮＶＩＴＥを前記応答者ユーザエンティティへ転送するものであり、
前記応答者ユーザエンティティは、前記第２の保護提案を有する前記ＩＮＶＩＴＥを受け入れ、そして、第１の保護受入れを有する確認応答を使って応答する
ことを特徴とするシステム。
【請求項１５】
ユーザエンティティ・メディアプレーン・ハンドラを備え、
前記応答者ユーザエンティティは、前記ユーザエンティティ・メディアプレーン・ハンドラへの信号と一緒にＳＡを確立し、前記ＳＡ（セキュリティアソシエーション）に基づく即時保護を可能にするよう、前記ユーザエンティティ・メディアプレーン・ハンドラに命令する
ことを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記メディアプレーン・ハンドラは、セキュリティゲートウェイ（ＳＧＷ）、アプリケーションサーバ（ＡＳ）、エッジエンティティ（ＥＥ）、又はボーダエンティティ（ＢＥ）のうちのいずれかである
ことを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記応答者ユーザエンティティと通信する応答者側Ｐ−ＣＳＣＦ（プロキシ呼状態制御機能）を備え、
前記応答者側Ｐ−ＣＳＣＦは、前記応答者ユーザエンティティから前記確認応答を受信して前記確認応答を前記応答者側Ｓ−ＣＳＣＦへ転送する
ことを特徴とする請求項１５に記載のシステム。
【請求項１８】
前記応答者側Ｓ−ＣＳＣＦは、前記確認応答の中の前記第１の保護受入れを削除して、前記受入れのない前記確認応答を前記開始者側Ｓ−ＣＳＣＦへ転送する
ことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記開始者側Ｓ−ＣＳＣＦは、保護が用いられるべきであるという第２の保護受入れを含むように、前記確認応答を修正する
ことを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記開始者側Ｓ−ＣＳＣＦおよび前記開始者ユーザエンティティと通信する開始者側Ｐ−ＣＳＣＦを備え、
前記開始者側Ｓ−ＣＳＣＦは、前記第２の保護受入れを有する前記確認応答を前記開始者側Ｐ−ＣＳＣＦへ転送する
ことを特徴とする請求項１９に記載のシステム。
【請求項２１】
前記開始者側Ｐ−ＣＳＣＦは、前記第２の保護受入れを有する前記確認応答を前記開始者ユーザエンティティへ転送する
ことを特徴とする請求項２０に記載のシステム。
【請求項２２】
前記開始者ユーザエンティティは前記第２の保護受入れを有する前記確認応答を前記開始者側Ｐ−ＣＳＣＦから受信し、鍵を導出し、そして、前記ユーザエンティティ・メディアプレーン・ハンドラへの信号と共にＳＡを確立し、ＳＡに基づくメディア保護を可能にするよう前記メディアプレーン・ハンドラに命令する
ことを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記第１の提案は空であり、
前記動作するステップは、前記応答者ユーザエンティティの登録されたセキュリティ能力に更に依存し、
前記方法は、第２の空でない提案を前記ＩＮＶＩＴＥメッセージに挿入するステップを備える
ことを特徴とする請求項１に記載の方法。
【請求項２４】
前記挿入される第２の空でない提案は、前記応答者ユーザエンティティの登録されたセキュリティ能力に従って生成され、エンド・ツー・アクセスエッジのメディア保護を含む
ことを特徴とする請求項２３に記載の方法。
【請求項２５】
通信ネットワークにおいて開始者ユーザエンティティと応答者ユーザエンティティとの間のメディア制御シグナリングメッセージを処理して転送することによって動作する、メディア制御シグナリングエンティティであって、
第１の招待メッセージを前記開始者ユーザエンティティから受信するための第１のネットワークインタフェースと、
第２の招待メッセージを前記応答者ユーザエンティティへ転送するための第２のネットワークインタフェースと、
前記第１および第２のネットワークインタフェースと通信する処理ユニットと、
を備え、
前記処理ユニットは、前記第１の招待メッセージから前記第２の招待メッセージを作成するよう動作可能であり、そのために、
前記第１の招待メッセージがメディア保護のための第１の提案を有するかどうか判定し、
前記第１の招待メッセージの中に含まれる場合には前記第１のメディア保護提案を少なくとも削除して、
前記第１の招待メッセージには第１の保護提案がなく、かつ、前記応答者ユーザエンティティが少なくとも１つのメディアセキュリティ能力を前記通信ネットワークに登録している場合には、前記登録されたメディアセキュリティ能力に対応するような第２のメディア保護提案を少なくとも挿入することによって、
前記第１の招待メッセージから前記第２の招待メッセージを作成する
ことを特徴とするメディア制御シグナリングエンティティ。
【請求項２６】
前記第２のメディア保護提案は、エンド・ツー・アクセスエッジのメディア保護の提案である
ことを特徴とする請求項２５に記載のメディア制御シグナリングエンティティ。
【請求項２７】
前記第１および第２の招待メッセージはＳＩＰメッセージである
ことを特徴とする請求項２５に記載のメディア制御シグナリングエンティティ。
【請求項２８】
Ｓ−ＣＳＣＦ機能を更に備える
ことを特徴とする請求項２７に記載のメディア制御シグナリングエンティティ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１１−５０５７３６（Ｐ２０１１−５０５７３６Ａ）
【公表日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願番号】特願２０１０−５３５４６７（Ｐ２０１０−５３５４６７）
【出願日】平成２０年１２月１日（２００８．１２．１）
【国際出願番号】ＰＣＴ／ＩＢ２００８／００３２８８
【国際公開番号】ＷＯ２００９／０６８９８５
【国際公開日】平成２１年６月４日（２００９．６．４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願日】平成２０年１２月１日（２００８．１２．１）
【国際出願番号】ＰＣＴ／ＩＢ２００８／００３２８８
【国際公開番号】ＷＯ２００９／０６８９８５
【国際公開日】平成２１年６月４日（２００９．６．４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]