(57)【要約】      （修正有）【課題】ネットワークの信頼性を考慮した、ユーザーのアイデンティティおよびプライバシの処理方法を提供する。【解決手段】第１のSIPプロキシが、次のSIPプロキシにSIPリクエストを転送時に、TLSが、次のSIPプロキシへのホップにおいてサポートされているかどうかを判断するステップ、TLSがサポートされている場合には、TLS接続を確立するステップ、証明書をリクエストするステップ、証明書を受信するステップ、証明書および次のSIPプロキシのネットワークの信頼性を検証するステップ、証明書およびネットワークの信頼性が検証された場合に、アイデンティティ情報を保持するステップを含む。TLSがサポートされていない場合や証明書が検証されていない場合、ネットワークの信頼性が検証されていない場合には、アイデンティティ情報は取り除かれて、TLS接続を通じてSIPリクエストが転送される。【選択図】図２
2010081636.tif 000002
【特許請求の範囲】
【請求項１】
SIP（Session Initiation Protocol；セッション開始プロトコル）プロキシによって実行される方法であって、
次のSIPプロキシにSIPリクエストを転送することを含み、ただし前記転送することが、次のSIPプロキシへのホップにおいて、TLS（Transport Layer Security；トランスポート層セキュリティ）がサポートされているかどうかを判断することを含み、
TLSがサポートされている場合には、
前記次のSIPプロキシへの前記ホップにTLS接続を確立すること、
前記次のSIPプロキシへ証明書（certificate）を要求すること、
前記証明書を受信すること、
前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証すること、
前記証明書および前記ネットワークの信頼性が検証された場合に、アイデンティティ情報を保持することを含み、
TLSがサポートされていない場合、もしくは前記証明書が検証されない場合、または前記ネットワークの信頼性が検証されない場合には、前記アイデンティティ情報を取り除くことを含み、
さらに前記TLS接続を通じて前記SIPリクエストを転送することを有する、
方法。
【請求項２】
SIP（Session Initiation Protocol；セッション開始プロトコル）プロキシによって実行される方法であって、
第１のSIPプロキシからSIPリクエストを受信することと、
前記SIPリクエストがTLS（Transport Layer Security；トランスポート層セキュリティ）を介して受信されたかどうかを判断することとを有し、
前記SIPリクエストがTLSを介して受信された場合には、
前記第１のSIPプロキシへ証明書（certificate）をリクエストすること、
前記証明書を受信すること、
前記証明書および前記第１のSIPプロキシのネットワークの信頼性を検証すること、
前記証明書および前記ネットワークの信頼性が検証された場合に、アイデンティティ情報を保持することを含み、
TLSがサポートされていない場合、または前記証明書が検証されない場合、あるいは前記ネットワークの信頼性が検証されない場合には、前記アイデンティティ情報を取り除くことを含み、
さらに前記SIPリクエストに応答することを有する、
方法。
【請求項３】
通信装置であって、
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシへのホップにTLS（Transport Layer Security；トランスポート層セキュリティ）接続を確立する確立手段と、
TLSが前記次のSIPプロキシへの前記ホップにおいてサポートされているかどうかを判断する判断手段と、
前記次のSIPプロキシへ証明書（certificate）をリクエストするためのリクエスト手段と、
前記証明書を受信する受信手段と、
前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証する検証手段と、
前記TLS接続を通じて前記SIPリクエストを転送する転送手段とを備え、
前記通信装置は、前記証明書が検証され、前記ネットワークの信頼性が検証され、およびTLSがサポートされている場合はアイデンティティ情報を保持するように構成され、TLSがサポートされていない場合もしくは前記証明書が検証されない場合または前記ネットワークの信頼性が検証されていない場合は前記アイデンティティ情報を取り除くように構成される、通信装置。
【請求項４】
通信システムであって、
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシへのホップにTLS（Transport Layer Security；トランスポート層セキュリティ）接続を確立するように構成された、TLS接続確立装置と、
前記次のSIPプロキシへの前記ホップにおいてTLSがサポートされているかどうかを判断するように構成された、TLSサポートアナライザと、
前記次のSIPプロキシへ証明書（certificate）をリクエストし、前記証明書を受信し、前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するように構成された、検証モジュールと、
前記TLS接続を通じて前記SIPリクエストを転送するように構成された、SIPリクエストハンドラとを備え、
前記通信システムは、前記証明書が検証され、前記ネットワークの信頼性が検証され、およびTLSがサポートされている場合はアイデンティティ情報を保持するように構成され、TLSがサポートされていない場合や前記証明書が検証されていない場合、または前記ネットワークの信頼性が検証されていない場合は前記アイデンティティ情報を取り除くように構成される、通信システム。
【請求項５】
SIP（Session Initiation Protocol；セッション開始プロトコル）プロキシのデータ処理装置に、請求項１に記載の方法を実行させる、プログラム。
【請求項６】
SIP（Session Initiation Protocol；セッション開始プロトコル）プロキシのデータ処理装置に、請求項２に記載の方法を実行させる、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークの一部におけるアイデンティティの処理に関する。本発明はさらに、アサートしたアイデンティティに関して、信頼ドメインの境界を跨ぎ、ユーザーのプライバシ要件を受け付ける場合の、ユーザーがアサートしたアイデンティティの組み込みまたは除去に関する。
【０００２】
本出願は、2004年5月3日に出願の米国暫定特許出願番号第60/567,760号の優先権を主張するものである。より早期に出願されたこの出願の内容は、参照することにより組み込まれる。
【背景技術】
【０００３】
3GPP（3rd Generation Partnership Project；第三世代パートナーシッププロジェクト）のIMS（IP Multimedia Subsystem；IPマルチメディアサブシステム）、リリース5において、システムは、信頼できるパーティの閉じたネットワークとみなされる。IMSセッションは、IMSネットワークにおいて開始または終了し、すべてのIMSネットワークは互いを信頼する。このモデルは、パブリックインターネットから開始または終了するIMSセッションの確立が生じないようにする。一方では、すべてのIMSネットワークが互いを信頼しているので、SIP（Session Initiation Protocol；セッション開始プロトコル）プロキシ（CSCF（Call Session Control Function；呼セッション制御機能）、BGCF（Breakout Gateway Control Function；ブレークアウトゲートウェイ制御機能）など）は、SIPのリクエストにおいて、アサートされたアイデンティティに関して何もアクションを行う必要がない。別の（信頼できる）IMSネットワークからリクエストを受信した時に、アサートされたアイデンティティが存在する場合、それは信頼されるべきである。SIPプロキシが、他のネットワークにSIPリクエストを送信しようとしている場合、そのアサートされたアイデンティティは、メッセージ内に保持される。
【０００４】
3GPP IMSリリース6によって、IMSセッションを、インターネットSIPのクライアントに/から確立することができる。しかし、特定のネットワークに対して、選択された（IMSまたは非IMS）ネットワークだけが信頼されているものとみなされるので、新たな信頼モデルが必要である。SIPプロキシ（例、CSCF、BGCFなど）は、トラフィックが信頼できないネットワークに送られる場合に、アサートされたアイデンティティにアクション（例、除去）を行えることが必要とされる。SIPプロキシは、信頼できるネットワークからSIPを受信し、アサートされたアイデンティティが存在する場合、それは保持される。しかし、SIPプロキシが信頼できないネットワークからSIPリクエストを受信し、アサートされたアイデンティティが存在する場合、そのリクエストは信頼できないので、SIPプロキシはそのアイデンティティを取り除く。同様に、SIPプロキシは、信頼できるネットワークにリクエストを送信しようとしている場合、あらゆるアサートされたアイデンティティを保持する。しかし、SIPプロキシが、信頼できないネットワークにリクエストを送信しようとしている場合、アサートされたアイデンティティは取り除かれる。
【０００５】
IMSにおける信頼ネットワークの概念は、互いを信頼する2つのネットワークの間に相互接続の同意が存在することによってサポートされる。2つのネットワークが相互接続の同意に署名するとき、それらのネットワークはセキュリティ情報を交換する。3GPP IMSリリース5では、信頼できる、および信頼できないノードが混在するものをサポートしていない。3GPP IMSリリース5では、全てのIMSネットワークが互いを信頼すること、すなわち、非IMSネットワークには接続できないことを規定している。3GPP IMSリリース5は、任意の2つのIMSネットワークの間に、IPsec（Internet Protocol security；インターネットプロトコルセキュリティ）ゲートウェイ、およびIPsecトンネルを提供する。しかし、IPsecゲートウェイは、SIP層ではなくIP層で動作し、SIPプロキシとは物理的および論理的に異なる要素であるため、IPsecゲートウェイは、リリース6における信頼できる/信頼できないモデル（trusted/untrusted model）には有用でない。加えて、2つのIMSオペレータ間のIPsecトンネルの存在は、これらのオペレータ間にSIPレベルで信頼関係があるとするには不十分である。
【０００６】
したがって、SIPリクエストを受信している特定のSIPプロキシに対して、信頼できる、または信頼できないソースから特定のリクエストを受信したかどうかを判断するための方法が必要である。さらに、SIPリクエストを転送する前に、SIPリクエストを別のネットワークに送信しようとしている特定のSIPプロキシに対して、次のSIPプロキシが信頼できる、または信頼できないことを判断することも必要である。
【発明の概要】
【０００７】
本発明は、ユーザーのアイデンティティおよびプライバシの処理方法を開示し、第1のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが、次のSIPプロキシにSIPリクエストを転送しようとしており、TLS（Transport Layer Security；トランスポート層セキュリティ）が、次のSIPプロキシへのホップにおいてサポートされているかどうかを判断するステップを含む。前記方法は、TLSがサポートされている場合には、前記次のSIPプロキシへの前記ホップにTLS接続を確立するステップと、前記次のSIPプロキシから証明書をリクエストするステップと、前記証明書を受信するステップと、前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するステップと、前記証明書および前記ネットワークの信頼性が検証された場合に、アイデンティティ情報を保持するステップとを含む。前記方法はまた、TLSがサポートされていない場合、または前記証明書が検証されていない場合、あるいは前記ネットワークの信頼性が検証されていない場合には、前記アイデンティティ情報を取り除くステップを含む。前記方法はその後、前記TLS接続を通じて前記SIPリクエストを転送するステップをさらに含む。
【０００８】
本発明はまた、第1のSIPプロキシが、ユーザーのアイデンティティおよびプライバシを処理するために、信頼できるネットワークに属するかどうかを判断する方法の提供を目的とし、次のSIPプロキシが前記第1のSIPプロキシからリクエストを受信する。前記方法は、第1のSIPプロキシからSIPリクエストを受信するステップと、前記SIPリクエストがTLSを介して受信されたかどうかを判断するステップとを含む。前記方法はまた、前記SIPリクエストがTLSを介して受信された場合には、前記第1のSIPプロキシから証明書をリクエストするステップと、前記証明書を受信するステップと、前記証明書および前記第1のSIPプロキシのネットワークの信頼性を検証するステップと、前記証明書および前記ネットワークの信頼性が検証された場合に、アイデンティティ情報を保持するステップとを含む。前記方法はまた、TLSがサポートされていない場合、または前記証明書が検証されていない場合、あるいは前記ネットワークの信頼性が検証されていない場合には、前記アイデンティティ情報を取り除くステップを含む。前記方法はその後、前記SIPリクエストに応答するステップをさらに含む。
【０００９】
本発明はまた、通信装置の提供を目的とし、次のSIPプロキシへのホップにTLS接続を確立するための確立手段と、TLSが前記次のSIPプロキシへの前記ホップにおいてサポートされているかどうかを判断するための判断手段と、前記次のSIPプロキシから証明書をリクエストするためのリクエスト手段と、前記証明書を受信するための受信手段と、前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するための検証手段と、前記TLS接続を通じて前記SIPリクエストを転送するための転送手段とを備える。前記通信装置は、前記証明書が検証された場合、前記ネットワークの信頼性が検証された場合、およびTLSがサポートされている場合に、アイデンティティ情報を保持するように構成され、また、TLSがサポートされていない場合、または前記証明書が検証されていない場合、あるいは前記ネットワークの信頼性が検証されていない場合に、前記アイデンティティ情報を取り除くように構成される。
【００１０】
本発明はまた、通信システムの提供を目的とし、次のSIPプロキシへのホップにTLS接続を確立するように構成された、TLS接続確立装置と、TLSが前記次のSIPプロキシへの前記ホップにおいてサポートされているかどうかを判断するように構成された、TLSサポートアナライザと、前記次のSIPプロキシから証明書をリクエストし、前記証明書を受信し、前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するように構成された、検証モジュールと、前記TLS接続を通じて前記SIPリクエストを転送するように構成された、SIPリクエストハンドラとを備える。前記通信システムは、前記証明書が検証された場合、前記ネットワークの信頼性が検証された場合、およびTLSがサポートされている場合に、アイデンティティ情報を保持するように構成され、また、TLSがサポートされていない場合、または前記証明書が検証されていない場合、あるいは前記ネットワークの信頼性が検証されていない場合に、前記アイデンティティ情報を取り除くように構成される。
【００１１】
本発明の実施形態のこれらの、および他の機能、側面、および利点は、添付図とともに以下の説明を参照することによって明らかになろう。しかし、添付図面は、単に例証を目的としたものであり、本発明の範囲を定義するものではないことを理解されたい。
【好適な実施形態の詳細な説明】
【００１２】
本発明のより深い理解に資するための、また本明細書に組み込まれてその一部を構成する添付図は、本発明の原理の説明として用いられる記述とともに、本発明の実施形態を例示する。
【００１３】
PS（Packet-Switched；パケット交換）ドメインでは、モバイル装置とネットワークとの間にセキュリティの関連付けが確立されるまで、サービスは提供されない。IMS（IP Multimedia Core Network Subsystem；IPマルチメディアコアネットワークサブシステム）は、基本的にPSドメインに対するオーバーレイであり、PSドメインへの依存が低い。したがって、マルチメディアサービスへのアクセスを許可する前に、マルチメディアクライアントとIMSとの間には別々のセキュリティの関連付けが必要である。IMSのセキュリティアーキテクチャを、図1に示す。
【００１４】
図1は、ホーム/サービングネットワーク110と、訪問先/ホームネットワーク120と、ユーザー機器102と、HSS（Home Subscriber Server；ホームサブスクライバサーバー）111を有するホーム/サービングネットワークとの関連を示す図である。図1は、モバイル装置（すなわち、UE（User Equipment；ユーザー機器）102、サブスクライバなど）と、S-CSCF（Serving Call Session Control Function；サービング呼セッション制御機能）113、P-CSCF（Proxy Call Session Control Function；プロキシ呼セッション制御機能）121、およびI-CSCF（Interrogating Call Session Control Function；問い合わせ呼セッション制御機能）112などの様々なネットワーク要素との間の呼管理プロトコルを示す図である。
【００１５】
ユーザー側のIMS認証キーおよび機能は、UICC（Universal Integrated Circuit Card；汎用ICカード）に格納される。IMS認証キーおよび機能は、論理的に独立すること、またキーおよび機能をPSドメインの認証に使用することが可能である。しかし、これは、共通の認証キーおよび機能が、IMSおよびPSドメインの認証に使用されることを排除していない。ISIM（IP Multimedia Services Identity Module；IPマルチメディアアイデンティティモジュール）103は、UICCに一群のIMSのセキュリティデータおよび機能を提供する。
【００１６】
図1では、5つの異なるセキュリティの関連付けがあり、IMSのセキュリティの保護に対して異なるニーズがあり、それぞれ番号1、2、3、4、および5を付す。第1の関連付け、番号1は、相互認証を提供する。HSSは、S-CSCFにサブスクライバの認証能力を移譲する。しかし、HSSは、キーおよびチャレンジを発生させる役割を果たす。ISIMおよびHSSの長期的なキーは、IMPIに関連する。サブスクライバは、1つの（ネットワーク内部の）ユーザープライベートアイデンティティ（IMPU）を１つ、外部ユーザーパブリックアイデンティティ（IMPU）を少なくとも１つ有する。第2の関連付け、番号2は、Gm参照点の保護のために、UEとP-CSCFとの間に、安全なリンクおよびセキュリティの関連付けを提供する。データ発信元認証、すなわち受信されるデータのソースが請求されているような裏付けが提供される。
【００１７】
第3の関連付け、番号3は、Cxインターフェースに対してネットワークドメイン内に内部的にセキュリティを提供する。第4の関連付け、番号4は、SIPが可能なノードに対して異なるネットワーク間にセキュリティを提供する。このセキュリティの関連付けは、P-CSCFがVN（Visited Network；訪問先ネットワーク）に存在する場合にのみ適用可能であり、P-CSCFがHN（Home Network；ホームネットワーク）に存在する場合は、番号5を適用する。最後の関連付け、番号5は、SIPが可能なノード間に内部的にセキュリティを提供する。
【００１８】
IMSには、上述されていない、他のインターフェースおよび参照点が存在する。これらのインターフェースおよび参照点は、IMS内、同じセキュリティのドメイン内、または異なるセキュリティドメイン間に存在する。UEとHNとの間には、相互認証が必要である。独立したIMSのセキュリティ機構は、セキュリティ違反に対して更なる保護を提供する。例えば、PSドメインのセキュリティに違反した場合、IMSは、それ自体のセキュリティ機構による保護を継続する。
【００１９】
上述のように、信頼モデルのサポートは、信頼できるネットワーク間に相互接続の同意が存在することによって確保される。すべてのSIPプロキシは、証明書中に可視的なセキュリティパラメータとともに、信頼できるネットワークのリストを含むデータベースを含む。セキュリティパラメータは、認証局、または一般名称、あるいは組織であってよい。
【００２０】
プライバシは、多くの場合、秘匿性（confidentiality）と同等に考えられる。これには、情報を解読する許可を与えられた人を除く、すべてのエンティティから、暗号化および暗号鍵を用いて情報を隠すことが含まれる。これに対してIMSネットワークのSIPのプライバシ拡張は、このような秘匿性を提供しない。この機構の目的は、むしろIMSのサブスクライバに特定のアイデンティティ情報を明かさない可能性を提供することである。これは、IMSネットワークのプライバシ機構が、CSCFに通常のSIP状態以外の状態を発生させないという点で、有用である。
【００２１】
少なくとも1つの実施形態によれば、リリース6のIMSが非IMSネットワークと通信している場合、通信の約束の利用可能性とともに、相互作用に対するセキュリティ機構が適用されているかどうかに基づいて、IMSネットワークのCSCFが信頼関係（trust relation）を決定する。通信するネットワークが信頼できない場合、プライバシ情報は、外部のネットワークへのトラフィックから取り除かれる。SIPのシグナリングを受信するとき、CSCFはまた、何らかプライバシ情報がすでに含まれているかどうかも検証する。相互作用のネットワークが信頼できない場合、その情報はCSCFによって取り除かれ、それ以外ならば保持される。
【００２２】
セキュリティ機構の欠如により、通信するネットワークが信頼できない非IMSネットワークであると示される場合、IMSと非IMSネットワークとの接続には、通常別々のCSCFが必要である。IMSネットワークに接続しているCSCFは、セキュリティを確立するSEGを介して到達可能なすべてのIMSネットワークを暗黙に信頼する。リリース5のCSCFは、常にこの信頼関係およびネットワークの構成を仮定している。リリース6のCSCFに対して、この暗黙的信頼の設定は、オペレータがネットワークおよびインターフェースの構成に基づいて設定することができる構成のオプションである。
【００２３】
図2は、本発明の一実施形態に基づいた、プライバシの処理を示すフローチャートである。SIPリクエストを次のSIPプロキシに転送しようとしているIMS SIPプロキシは、ステップ201で、次のホップへのTLS（Transport Layer Security；トランスポート層セキュリティ）接続を確立する。TLSが次のホップでサポートされていない場合、ステップ203で、ネットワークは信頼されず、プライバシ情報は取り除かれる。判断ステップ202でTLSがサポートされていると判断された場合、IMS SIPプロキシは、ステップ204で、他のSIPプロキシから証明書をリクエストする。証明書の受信に関して、IMS SIPプロキシは、ステップ205で、その証明書が有効であるかどうか、および信頼できるネットワークに属しているかどうかを判断する。信頼できるネットワークに属している場合、IMSプロキシは、アサートされたアイデンティティを保持し、それ以外ならば取り除く。次いで、ステップ206で、IMSプロキシは、TLS接続を通じてSIPリクエストを転送する。また、SIPプロキシが、以前の接続の結果として、他のパーティに対する証明書を予め有することも可能である。その結果、その証明書が依然として有効であることを単に検証するに十分とすることが可能である。
【００２４】
同様に、SIPリクエストを受信するIMS SIPプロキシは、これらの同じルールを適用する。リクエストがTLSを介して受信されない場合、送信SIPプロキシは信頼されない。リクエストがTLSを介して送信される場合、IMS SIPプロキシは、送信SIPプロキシに証明書をリクエストする。次いで、IMS SIPプロキシは、信頼できるネットワークのリストに対して証明書を検証し、送信SIPプロキシが信頼できるかどうかを判断する。また、より早期の接続からの証明書が存在する場合がある。
【００２５】
加えて、各IMSネットワークは、より高い優先権をTLSに与えるために、SIPサービスに対して、UDP（User Datagram Protocol；ユーザーデータグラムプロトコル）、TCP（Transmission Control Protocol；伝送制御プロトコル）、SCTP（Stream Control Transmission Protocol；ストリーム制御伝送プロトコル）（または他のトランスポートプロトコル）を通じて、DNS（Domain Name Server；ドメインネームサーバー）のNAPTR（Naming Authority Pointer；ネーミング権限ポインタ）の記録を構成する。これによって、IMSネットワークは、トランスポートプロトコルとして常にTLSを最初に試みることができる。
【００２６】
リリース5のネットワークとのインターオペラビリティに関して、リリース6のIMSネットワークは、下位互換性のあるソリューション、すなわちSGW（Security Gateway；セキュリティゲートウェイ）を介したIPsec（Internet Protocol security；インターネットプロトコルセキュリティ）を使用する。パケットがIPsecで保護されていることを受信CSCFに示すように、受信SGWは、CSCFの保護されたポートにSIPメッセージのポート番号を変更する必要がある。相互接続の同意がある場合は、ユーザーアイデンティティが転送されるか、または受信時に信頼される。それ以外ならば、ユーザーアイデンティティは取り除かれる。本発明の別の側面は、IMSリリース5のノードとIMSリリース6との間の下位互換性の提供方法を目的とする。
【００２７】
第1の実施例において、IMSリリース5のSIPプロキシは、IMSリリース6のノードにSIPリクエストを送信する。IMSリリース5のSIPプロキシは、IMSリリース6のネットワークが信頼できるとみなすので、アサートされたアイデンティティには何もアクションを行わない。しかし、IMSリリース6のSIPプロキシは、そのリクエストがTLSを使用していないので、アイデンティティを取り除くことになる。
【００２８】
本発明の実施形態によれば、リクエストは、2つのIMSネットワーク間のドメイン間の境界を通り抜けるので、SIPメッセージは、IMSリリース5のネットワークのSGWを通り抜け、次いで、IMSリリース6のネットワークのSGWを通り抜けることになる。このトラフィックは、IPsec ESP（Encapsulated Security Payload；カプセル化セキュリティペイロード）を使用して保護される。IMSリリース6のネットワークのSGWは、（リリース6のネットワークのSIPプロキシの）宛先ポート番号が、保護されたポート番号を再び対象とすることができる。IMSリリース6のネットワークのSIPプロキシは、2つのポート番号を割り当てる。その1つは、標準的なトラフィックが受信される所であり、もう1つは、SGWが（IMSリリース5のネットワークから）IPsecトンネルを介して受信されるトラフィックを送信する所である。IPsecトンネルの存在は、他端がIMSネットワークであること（およびリリース5のガイドラインによって信頼されていること）を示す。
【００２９】
第2の実施例において、IMSリリース5のSIPプロキシは、IMSリリース6のネットワークからSIPリクエストを受信している。IMSリリース5のネットワークは、すべてが信頼できるとみなすので、IMSリリース5のSIPプロキシは、アサートされたアイデンティティに何もアクションを行わない。リリース5のガイドラインによれば、リクエストは、この場合セキュリティゲートウェイを介して届くべきであるが、このアクションには影響を及ぼさない。
【００３０】
第3の実施例では、IMSリリース6のSIPプロキシは、IMSリリース5のネットワークにリクエストを送信している。デフォルトでは、IMSリリース5はTLSをサポートしていないので、IMSリリース6のSIPプロキシは、アサートされたアイデンティティを取り除く。本発明の実施形態によれば、好適なアクションは、何も行われない。何らかの理由でアサートされたアイデンティティを送信する必要がある場合、オペレータは、他のパーティがリリース5であるという理由でTLSの使用を免除するということを含む、相互接続の同意を行わなければならない。次に、送信プロキシは、それ自体のネットワークのセキュリティゲートウェイにIPsec ESPが適用されなければならない旨を、示さなければならない。この指示は、送信プロキシの専用のソースIPアドレスを使用することによって行うことができる。
【００３１】
第4の実施例では、IMSリリース6のSIPプロキシは、IMSリリース5ネットワークからSIPリクエストを受信している。IMSリリース5のネットワークは、TLSをサポートしていないので、IMSリリース6のSIPプロキシは、デフォルトで、信頼できないネットワークから届いたリクエストであるとみなすことになる。この場合、ソリューションは、上述の第1の実施例に関する説明と同じである。
【００３２】
TLSによって保護されるSIPのシグナリングは、IMS CSCFと外部のネットワークに位置するプロキシ/CSCFとのSIPの相互運用の保護に使用することが可能である。CSCFは、SIP、NAPTR/SRV機構を介して分析することができるDNSサーバーのURI、を公開することによって、外部のプロキシとのTLS接続をリクエストすることができる。TLSのハンドシェイク段階の間に、証明書を送受信する場合、CSCFは、相互作用のパートナーのリストに対して証明書上の名前を検証する。TLSセッションは、いずれのネットワークからも開始することができる。TLS接続は、複数のSIPダイアログを搬送することができる。
【００３３】
上述の説明は、本発明の特定の実施形態を対象としたものである。しかし、説明された実施形態の一部又は全ての利点を保持したまま、これらを様々に変形したり修正したりすることができることは明らかである。従って、かかる変形と修正のすべてを本発明の真の精神と範囲内においてカバーすることは、添付の特許請求の範囲の目的とするところである。
【図面の簡単な説明】
【００３４】
【図１】IMSのセキュリティアーキテクチャを示す図である。
【図２】本発明の一実施形態に基づいた、プライバシの処理を示すフローチャートである。
【図１】
2010081636.tif 000003
【図２】
2010081636.tif 000004