ＩＰネットワークの信頼できるドメインにおけるアイデンティティの処理
ユーザーのアイデンティティおよびプライバシの処理方法であって、第1のSIPプロキシが、次のSIPプロキシにSIPリクエストを転送しようとしており、TLSが、次のSIPプロキシへのホップにおいてサポートされているかどうかを判断するステップを含む。該方法は、TLSがサポートされている場合には、次のSIPプロキシへのホップにTLS接続を確立するステップ、次のSIPプロキシへ証明書をリクエストするステップ、証明書を受信するステップ、証明書および次のSIPプロキシのネットワークの信頼性を検証するステップ、証明書およびネットワークの信頼性が検証された場合に、アイデンティティ情報を保持するステップを含む。TLSがサポートされていない場合や証明書が検証されていない場合、ネットワークの信頼性が検証されていない場合には、アイデンティティ情報は取り除かれる。その後、TLS接続を通じてSIPリクエストが転送される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークの一部におけるアイデンティティの処理に関する。本発明はさらに、アサートしたアイデンティティに関して、信頼ドメインの境界を交差させ、ユーザーのプライバシ要件を受け付ける場合の、ユーザーがアサートしたアイデンティティの組み込みまたは除去に関する。
【関連出願の相互参照】
【０００２】
本出願は、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における信頼できる/信頼できないモデルには有用でない。加えて、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）、および少なくとも1つの外部ユーザーのパブリックアイデンティティ（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プロキシは、証明書に可視的なセキュリティパラメータとともに、信頼できるネットワークのリストを含むデータベースを含む。セキュリティパラメータは、認証局、または一般名称、あるいは組織であってよい。
【００２０】
プライバシは、多くの場合、秘匿性と同等であってよい。これには、暗号化および暗号鍵を用いた、情報を解読する許可を与えられた人を除く、すべてのエンティティからの情報の隠蔽が含まれる。IMSネットワークのSIPのプライバシ拡張は、当該の秘匿性を提供しない。この機構の目的は、むしろIMSのサブスクライバに特定のアイデンティティ情報を明かさない可能性を提供することである。IMSネットワークのプライバシ機構が、CSCFに通常のSIP状態以外の状態を発生させないことに対して有用である。
【００２１】
少なくとも1つの実施形態によれば、リリース6のIMSが非IMSネットワークと相互作用している場合、相互作用の同意能力とともに、相互作用に対するセキュリティ機構が適用されているかどうかに基づいて、IMSネットワークのCSCFが信頼関係を決定する。相互作用のネットワークが信頼できない場合、プライバシ情報は、外部のネットワークへのトラフィックから取り除かれる。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のセキュリティアーキテクチャを示す図である。
【図２】本発明の一実施形態に基づいた、プライバシの処理を示すフローチャートである。
【技術分野】
【０００１】
本発明は、ネットワークの一部におけるアイデンティティの処理に関する。本発明はさらに、アサートしたアイデンティティに関して、信頼ドメインの境界を交差させ、ユーザーのプライバシ要件を受け付ける場合の、ユーザーがアサートしたアイデンティティの組み込みまたは除去に関する。
【関連出願の相互参照】
【０００２】
本出願は、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における信頼できる/信頼できないモデルには有用でない。加えて、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）、および少なくとも1つの外部ユーザーのパブリックアイデンティティ（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プロキシは、証明書に可視的なセキュリティパラメータとともに、信頼できるネットワークのリストを含むデータベースを含む。セキュリティパラメータは、認証局、または一般名称、あるいは組織であってよい。
【００２０】
プライバシは、多くの場合、秘匿性と同等であってよい。これには、暗号化および暗号鍵を用いた、情報を解読する許可を与えられた人を除く、すべてのエンティティからの情報の隠蔽が含まれる。IMSネットワークのSIPのプライバシ拡張は、当該の秘匿性を提供しない。この機構の目的は、むしろIMSのサブスクライバに特定のアイデンティティ情報を明かさない可能性を提供することである。IMSネットワークのプライバシ機構が、CSCFに通常のSIP状態以外の状態を発生させないことに対して有用である。
【００２１】
少なくとも1つの実施形態によれば、リリース6のIMSが非IMSネットワークと相互作用している場合、相互作用の同意能力とともに、相互作用に対するセキュリティ機構が適用されているかどうかに基づいて、IMSネットワークのCSCFが信頼関係を決定する。相互作用のネットワークが信頼できない場合、プライバシ情報は、外部のネットワークへのトラフィックから取り除かれる。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のセキュリティアーキテクチャを示す図である。
【図２】本発明の一実施形態に基づいた、プライバシの処理を示すフローチャートである。
【特許請求の範囲】
【請求項１】
第1のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが、次のSIPプロキシにSIPリクエストを転送しようとするときにおける、ユーザーのアイデンティティおよびプライバシの処理方法であって、
次のSIPプロキシへのホップにおいて、TLS（Transport Layer Security；トランスポート層セキュリティ）がサポートされているかどうかを判断するステップを有し、
TLSがサポートされている場合には、
前記次のSIPプロキシへの前記ホップにTLS接続を確立するステップ、
前記次のSIPプロキシへ証明書（certificate）を要求するステップ、
前記証明書を受信するステップ、
前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するステップ、
前記証明書および前記ネットワークの信頼性が検証された場合に、アイデンティティ情報を保持するステップを有し、
TLSがサポートされていない場合、もしくは前記証明書が検証されない場合、または前記ネットワークの信頼性が検証されない場合には、前記アイデンティティ情報を取り除くステップを有し、
さらに前記TLS接続を通じて前記SIPリクエストを転送するステップを有する、
方法。
【請求項２】
前記証明書を検証するステップは、前記証明書が有効であるかどうかを判断するステップを含む、請求項1に記載の方法。
【請求項３】
前記ネットワークの信頼性を検証するステップは、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップを含む、請求項1に記載の方法。
【請求項４】
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するステップを含む、請求項3に記載の方法。
【請求項５】
前記次のSIPプロキシは、以前に先の証明書を送信しており、前記証明書を検証するステップは、前記先の証明書が依然として有効であるどうかを判断するステップを含む、請求項1に記載の方法。
【請求項６】
信頼できる、および信頼できないSIPプロキシに対して別々のCSCF（Call Session Control Function；呼セッション制御機能）を保持するステップをさらに含む、請求項1に記載の方法。
【請求項７】
より高い優先権をTLSに与えるように、DNS（Domain Name Server；ドメインネームサーバー）のNAPTR（Naming Authority Pointer；ネーミング権限ポインタ）を構成するステップをさらに含む、請求項1に記載の方法。
【請求項８】
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが第1のSIPプロキシからSIPリクエストを受信する際、ユーザーのアイデンティティおよびプライバシを処理するために、該第1のSIPプロキシが信頼できるネットワークに属しているかどうかを判断する方法であって、
第1のSIPプロキシからSIPリクエストを受信するステップと、
前記SIPリクエストがTLS（Transport Layer Security；トランスポート層セキュリティ）を介して受信されたかどうかを判断するステップとを有し、
前記SIPリクエストがTLSを介して受信された場合には、
前記第1のSIPプロキシへ証明書（certificate）をリクエストするステップ、
前記証明書を受信するステップ、
前記証明書および前記第1のSIPプロキシのネットワークの信頼性を検証するステップ、
前記証明書および前記ネットワークの信頼性が検証された場合に、アイデンティティ情報を保持するステップを有し、
TLSがサポートされていない場合、または前記証明書が検証されない場合、あるいは前記ネットワークの信頼性が検証されない場合には、前記アイデンティティ情報を取り除くステップを有し、
さらに前記SIPリクエストに応答するステップを有する、
方法。
【請求項９】
前記証明書を検証するステップは、前記証明書が有効であるかどうかを判断するステップを含む、請求項8に記載の方法。
【請求項１０】
前記ネットワークの信頼性を検証するステップは、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップを含む、請求項8に記載の方法。
【請求項１１】
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するステップを含む、請求項10に記載の方法。
【請求項１２】
前記第1のSIPプロキシは、以前に先の証明書を送信しており、前記証明書を検証するステップは、前記先の証明書が依然として有効であるどうかを判断するステップを含む、請求項8に記載の方法。
【請求項１３】
信頼できる、および信頼できないSIPプロキシに対して別々のCSCFを保持するステップをさらに含む、請求項8に記載の方法。
【請求項１４】
より高い優先権をTLSに与えるように、DNSのNAPTRを構成するステップをさらに含む、請求項8に記載の方法。
【請求項１５】
通信装置であって、
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシへのホップにTLS（Transport Layer Security；トランスポート層セキュリティ）接続を確立するための確立手段と、
TLSが前記次のSIPプロキシへの前記ホップにおいてサポートされているかどうかを判断するための判断手段と、
前記次のSIPプロキシへ証明書（certificate）をリクエストするためのリクエスト手段と、
前記証明書を受信するための受信手段と、
前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するための検証手段と、
前記TLS接続を通じて前記SIPリクエストを転送するための転送手段とを備え、
前記通信装置は、前記証明書が検証され、前記ネットワークの信頼性が検証され、およびTLSがサポートされている場合はアイデンティティ情報を保持するように構成され、TLSがサポートされていない場合もしくは前記証明書が検証されない場合または前記ネットワークの信頼性が検証されていない場合は前記アイデンティティ情報を取り除くように構成される、通信装置。
【請求項１６】
前記検証手段は、前記証明書が有効であるかどうかを判断するための手段を備える、請求項15に記載の通信装置。
【請求項１７】
前記検証手段は、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するための手段を備える、請求項15に記載の通信装置。
【請求項１８】
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するための手段は、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するための手段を備える、請求項17に記載の通信装置。
【請求項１９】
前記次のSIPプロキシが以前に先の証明書を送信している場合に、前記検証手段は、前記先の証明書が依然として有効であるどうかを判断するための手段を備える、請求項15に記載の通信装置。
【請求項２０】
信頼できる、および信頼できないSIPプロキシに対して別々のCSCFを保持するための手段を備える、請求項15に記載の通信装置。
【請求項２１】
より高い優先権をTLSに与えるように、DNSのNAPTRを構成するための手段を備える、請求項15に記載の通信装置。
【請求項２２】
通信システムであって、
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシへのホップにTLS（Transport Layer Security；トランスポート層セキュリティ）接続を確立するように構成された、TLS接続確立装置と、
前記次のSIPプロキシへの前記ホップにおいてTLSがサポートされているかどうかを判断するように構成された、TLSサポートアナライザと、
前記次のSIPプロキシへ証明書（certificate）をリクエストし、前記証明書を受信し、前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するように構成された、検証モジュールと、
前記TLS接続を通じて前記SIPリクエストを転送するように構成された、SIPリクエストハンドラとを備え、
前記通信システムは、前記証明書が検証され、前記ネットワークの信頼性が検証され、およびTLSがサポートされている場合はアイデンティティ情報を保持するように構成され、TLSがサポートされていない場合や前記証明書が検証されていない場合、または前記ネットワークの信頼性が検証されていない場合は前記アイデンティティ情報を取り除くように構成される、通信システム。
【請求項２３】
前記検証モジュールは、前記証明書が有効であるかどうかを判断するように構成される、請求項15に記載の通信システム。
【請求項２４】
前記検証モジュールは、前記ネットワークが一群の信頼できるネットワークに属するかどうかを判断するように構成される、請求項15に記載の通信システム。
【請求項２５】
前記検証モジュールは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するように構成される、請求項17に記載の通信システム。
【請求項２６】
前記次のSIPプロキシが以前に先の証明書を送信している場合に、前記検証モジュールは、前記先の証明書が依然として有効であるどうかを判断するように構成される、請求項15に記載の通信装置。
【請求項２７】
第1のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが、次のSIPプロキシにSIPリクエストを転送しようとするときに、ユーザーのアイデンティティおよびプライバシを処理するための、コンピュータ可読の媒体に組み込まれたコンピュータプログラムであって、該コンピュータプログラムはデータ処理装置を制御して、
次のSIPプロキシへのホップにおいて、TLS（Transport Layer Security；トランスポート層セキュリティ）がサポートされているかどうかを判断するステップを実行させ、
TLSがサポートされている場合には、
前記次のSIPプロキシへの前記ホップにTLS接続を確立するステップ、
前記次のSIPプロキシへ証明書をリクエストするステップ、
前記証明書を受信するステップ、
前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するステップ、
前記証明書および前記ネットワークの信頼性が検証された場合に、アイデンティティ情報を保持するステップを実行させ、
TLSがサポートされていない場合、もしくは前記証明書が検証されない場合、または前記ネットワークの信頼性が検証されない場合には、前記アイデンティティ情報を取り除くステップを実行させ、
さらに前記TLS接続を通じて前記SIPリクエストを転送するステップを実行させる、
プログラム。
【請求項２８】
前記証明書を検証するステップは、前記証明書が有効であるかどうかを判断するステップを含む、請求項27に記載のコンピュータプログラム。
【請求項２９】
前記ネットワークの信頼性を検証するステップは、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップを含む、請求項27に記載のコンピュータプログラム。
【請求項３０】
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するステップを含む、請求項29に記載のコンピュータプログラム。
【請求項３１】
前記次のSIPプロキシは、以前に先の証明書を送信しており、前記証明書を検証するステップは、前記先の証明書が依然として有効であるどうかを判断するステップを含む、請求項27に記載のコンピュータプログラム。
【請求項３２】
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが第1のSIPプロキシからSIPリクエストを受信する際、ユーザーのアイデンティティおよびプライバシを処理するために、前記第1のSIPプロキシが信頼できるネットワークに属するかどうかを判断するための、コンピュータ可読の媒体に組み込まれたコンピュータプログラムであって、該コンピュータプログラムはデータ処理装置を制御して、
第1のSIPプロキシからSIPリクエストを受信するステップと、
前記SIPリクエストがTLSを介して受信されたかどうかを判断するステップとを実行させ、
前記SIPリクエストがTLSを介して受信された場合には、
前記第1のSIPプロキシから証明書をリクエストするステップ、
前記証明書を受信するステップ、
前記第1のSIPプロキシのネットワークの証明書および信頼性を検証するステップ、
前記ネットワークの証明書および信頼性が検証された場合に、アイデンティティ情報を保持するステップを実行させ、
TLSがサポートされていない場合、もしくは前記証明書が検証されていない場合、または前記ネットワークの信頼性が検証されていない場合には、前記アイデンティティ情報を取り除くステップを実行させ、
さらに前記SIPリクエストに応答するステップを実行させる、
コンピュータプログラム。
【請求項３３】
前記証明書を検証するステップは、前記証明書が有効であるかどうかを判断するステップを含む、請求項32に記載のコンピュータプログラム。
【請求項３４】
前記ネットワークの信頼性を検証するステップは、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップを含む、請求項32に記載のコンピュータプログラム。
【請求項３５】
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するステップを含む、請求項34に記載のコンピュータプログラム。
【請求項３６】
前記第1のSIPプロキシは、以前に先の証明書を送信しており、前記証明書を検証するステップは、前記先の証明書が依然として有効であるどうかを判断するステップを含む、請求項32に記載のコンピュータプログラム。
【請求項１】
第1のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが、次のSIPプロキシにSIPリクエストを転送しようとするときにおける、ユーザーのアイデンティティおよびプライバシの処理方法であって、
次のSIPプロキシへのホップにおいて、TLS（Transport Layer Security；トランスポート層セキュリティ）がサポートされているかどうかを判断するステップを有し、
TLSがサポートされている場合には、
前記次のSIPプロキシへの前記ホップにTLS接続を確立するステップ、
前記次のSIPプロキシへ証明書（certificate）を要求するステップ、
前記証明書を受信するステップ、
前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するステップ、
前記証明書および前記ネットワークの信頼性が検証された場合に、アイデンティティ情報を保持するステップを有し、
TLSがサポートされていない場合、もしくは前記証明書が検証されない場合、または前記ネットワークの信頼性が検証されない場合には、前記アイデンティティ情報を取り除くステップを有し、
さらに前記TLS接続を通じて前記SIPリクエストを転送するステップを有する、
方法。
【請求項２】
前記証明書を検証するステップは、前記証明書が有効であるかどうかを判断するステップを含む、請求項1に記載の方法。
【請求項３】
前記ネットワークの信頼性を検証するステップは、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップを含む、請求項1に記載の方法。
【請求項４】
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するステップを含む、請求項3に記載の方法。
【請求項５】
前記次のSIPプロキシは、以前に先の証明書を送信しており、前記証明書を検証するステップは、前記先の証明書が依然として有効であるどうかを判断するステップを含む、請求項1に記載の方法。
【請求項６】
信頼できる、および信頼できないSIPプロキシに対して別々のCSCF（Call Session Control Function；呼セッション制御機能）を保持するステップをさらに含む、請求項1に記載の方法。
【請求項７】
より高い優先権をTLSに与えるように、DNS（Domain Name Server；ドメインネームサーバー）のNAPTR（Naming Authority Pointer；ネーミング権限ポインタ）を構成するステップをさらに含む、請求項1に記載の方法。
【請求項８】
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが第1のSIPプロキシからSIPリクエストを受信する際、ユーザーのアイデンティティおよびプライバシを処理するために、該第1のSIPプロキシが信頼できるネットワークに属しているかどうかを判断する方法であって、
第1のSIPプロキシからSIPリクエストを受信するステップと、
前記SIPリクエストがTLS（Transport Layer Security；トランスポート層セキュリティ）を介して受信されたかどうかを判断するステップとを有し、
前記SIPリクエストがTLSを介して受信された場合には、
前記第1のSIPプロキシへ証明書（certificate）をリクエストするステップ、
前記証明書を受信するステップ、
前記証明書および前記第1のSIPプロキシのネットワークの信頼性を検証するステップ、
前記証明書および前記ネットワークの信頼性が検証された場合に、アイデンティティ情報を保持するステップを有し、
TLSがサポートされていない場合、または前記証明書が検証されない場合、あるいは前記ネットワークの信頼性が検証されない場合には、前記アイデンティティ情報を取り除くステップを有し、
さらに前記SIPリクエストに応答するステップを有する、
方法。
【請求項９】
前記証明書を検証するステップは、前記証明書が有効であるかどうかを判断するステップを含む、請求項8に記載の方法。
【請求項１０】
前記ネットワークの信頼性を検証するステップは、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップを含む、請求項8に記載の方法。
【請求項１１】
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するステップを含む、請求項10に記載の方法。
【請求項１２】
前記第1のSIPプロキシは、以前に先の証明書を送信しており、前記証明書を検証するステップは、前記先の証明書が依然として有効であるどうかを判断するステップを含む、請求項8に記載の方法。
【請求項１３】
信頼できる、および信頼できないSIPプロキシに対して別々のCSCFを保持するステップをさらに含む、請求項8に記載の方法。
【請求項１４】
より高い優先権をTLSに与えるように、DNSのNAPTRを構成するステップをさらに含む、請求項8に記載の方法。
【請求項１５】
通信装置であって、
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシへのホップにTLS（Transport Layer Security；トランスポート層セキュリティ）接続を確立するための確立手段と、
TLSが前記次のSIPプロキシへの前記ホップにおいてサポートされているかどうかを判断するための判断手段と、
前記次のSIPプロキシへ証明書（certificate）をリクエストするためのリクエスト手段と、
前記証明書を受信するための受信手段と、
前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するための検証手段と、
前記TLS接続を通じて前記SIPリクエストを転送するための転送手段とを備え、
前記通信装置は、前記証明書が検証され、前記ネットワークの信頼性が検証され、およびTLSがサポートされている場合はアイデンティティ情報を保持するように構成され、TLSがサポートされていない場合もしくは前記証明書が検証されない場合または前記ネットワークの信頼性が検証されていない場合は前記アイデンティティ情報を取り除くように構成される、通信装置。
【請求項１６】
前記検証手段は、前記証明書が有効であるかどうかを判断するための手段を備える、請求項15に記載の通信装置。
【請求項１７】
前記検証手段は、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するための手段を備える、請求項15に記載の通信装置。
【請求項１８】
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するための手段は、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するための手段を備える、請求項17に記載の通信装置。
【請求項１９】
前記次のSIPプロキシが以前に先の証明書を送信している場合に、前記検証手段は、前記先の証明書が依然として有効であるどうかを判断するための手段を備える、請求項15に記載の通信装置。
【請求項２０】
信頼できる、および信頼できないSIPプロキシに対して別々のCSCFを保持するための手段を備える、請求項15に記載の通信装置。
【請求項２１】
より高い優先権をTLSに与えるように、DNSのNAPTRを構成するための手段を備える、請求項15に記載の通信装置。
【請求項２２】
通信システムであって、
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシへのホップにTLS（Transport Layer Security；トランスポート層セキュリティ）接続を確立するように構成された、TLS接続確立装置と、
前記次のSIPプロキシへの前記ホップにおいてTLSがサポートされているかどうかを判断するように構成された、TLSサポートアナライザと、
前記次のSIPプロキシへ証明書（certificate）をリクエストし、前記証明書を受信し、前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するように構成された、検証モジュールと、
前記TLS接続を通じて前記SIPリクエストを転送するように構成された、SIPリクエストハンドラとを備え、
前記通信システムは、前記証明書が検証され、前記ネットワークの信頼性が検証され、およびTLSがサポートされている場合はアイデンティティ情報を保持するように構成され、TLSがサポートされていない場合や前記証明書が検証されていない場合、または前記ネットワークの信頼性が検証されていない場合は前記アイデンティティ情報を取り除くように構成される、通信システム。
【請求項２３】
前記検証モジュールは、前記証明書が有効であるかどうかを判断するように構成される、請求項15に記載の通信システム。
【請求項２４】
前記検証モジュールは、前記ネットワークが一群の信頼できるネットワークに属するかどうかを判断するように構成される、請求項15に記載の通信システム。
【請求項２５】
前記検証モジュールは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するように構成される、請求項17に記載の通信システム。
【請求項２６】
前記次のSIPプロキシが以前に先の証明書を送信している場合に、前記検証モジュールは、前記先の証明書が依然として有効であるどうかを判断するように構成される、請求項15に記載の通信装置。
【請求項２７】
第1のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが、次のSIPプロキシにSIPリクエストを転送しようとするときに、ユーザーのアイデンティティおよびプライバシを処理するための、コンピュータ可読の媒体に組み込まれたコンピュータプログラムであって、該コンピュータプログラムはデータ処理装置を制御して、
次のSIPプロキシへのホップにおいて、TLS（Transport Layer Security；トランスポート層セキュリティ）がサポートされているかどうかを判断するステップを実行させ、
TLSがサポートされている場合には、
前記次のSIPプロキシへの前記ホップにTLS接続を確立するステップ、
前記次のSIPプロキシへ証明書をリクエストするステップ、
前記証明書を受信するステップ、
前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するステップ、
前記証明書および前記ネットワークの信頼性が検証された場合に、アイデンティティ情報を保持するステップを実行させ、
TLSがサポートされていない場合、もしくは前記証明書が検証されない場合、または前記ネットワークの信頼性が検証されない場合には、前記アイデンティティ情報を取り除くステップを実行させ、
さらに前記TLS接続を通じて前記SIPリクエストを転送するステップを実行させる、
プログラム。
【請求項２８】
前記証明書を検証するステップは、前記証明書が有効であるかどうかを判断するステップを含む、請求項27に記載のコンピュータプログラム。
【請求項２９】
前記ネットワークの信頼性を検証するステップは、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップを含む、請求項27に記載のコンピュータプログラム。
【請求項３０】
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するステップを含む、請求項29に記載のコンピュータプログラム。
【請求項３１】
前記次のSIPプロキシは、以前に先の証明書を送信しており、前記証明書を検証するステップは、前記先の証明書が依然として有効であるどうかを判断するステップを含む、請求項27に記載のコンピュータプログラム。
【請求項３２】
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが第1のSIPプロキシからSIPリクエストを受信する際、ユーザーのアイデンティティおよびプライバシを処理するために、前記第1のSIPプロキシが信頼できるネットワークに属するかどうかを判断するための、コンピュータ可読の媒体に組み込まれたコンピュータプログラムであって、該コンピュータプログラムはデータ処理装置を制御して、
第1のSIPプロキシからSIPリクエストを受信するステップと、
前記SIPリクエストがTLSを介して受信されたかどうかを判断するステップとを実行させ、
前記SIPリクエストがTLSを介して受信された場合には、
前記第1のSIPプロキシから証明書をリクエストするステップ、
前記証明書を受信するステップ、
前記第1のSIPプロキシのネットワークの証明書および信頼性を検証するステップ、
前記ネットワークの証明書および信頼性が検証された場合に、アイデンティティ情報を保持するステップを実行させ、
TLSがサポートされていない場合、もしくは前記証明書が検証されていない場合、または前記ネットワークの信頼性が検証されていない場合には、前記アイデンティティ情報を取り除くステップを実行させ、
さらに前記SIPリクエストに応答するステップを実行させる、
コンピュータプログラム。
【請求項３３】
前記証明書を検証するステップは、前記証明書が有効であるかどうかを判断するステップを含む、請求項32に記載のコンピュータプログラム。
【請求項３４】
前記ネットワークの信頼性を検証するステップは、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップを含む、請求項32に記載のコンピュータプログラム。
【請求項３５】
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するステップを含む、請求項34に記載のコンピュータプログラム。
【請求項３６】
前記第1のSIPプロキシは、以前に先の証明書を送信しており、前記証明書を検証するステップは、前記先の証明書が依然として有効であるどうかを判断するステップを含む、請求項32に記載のコンピュータプログラム。
【図１】
【図２】
【図２】
【公表番号】特表２００７−５３８４２６（Ｐ２００７−５３８４２６Ａ）
【公表日】平成１９年１２月２７日（２００７．１２．２７）
【国際特許分類】
【出願番号】特願２００７−５１２５４７（Ｐ２００７−５１２５４７）
【出願日】平成１７年４月２９日（２００５．４．２９）
【国際出願番号】ＰＣＴ／ＩＢ２００５／００１１６８
【国際公開番号】ＷＯ２００５／１０７１４５
【国際公開日】平成１７年１１月１０日（２００５．１１．１０）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
【公表日】平成１９年１２月２７日（２００７．１２．２７）
【国際特許分類】
【出願日】平成１７年４月２９日（２００５．４．２９）
【国際出願番号】ＰＣＴ／ＩＢ２００５／００１１６８
【国際公開番号】ＷＯ２００５／１０７１４５
【国際公開日】平成１７年１１月１０日（２００５．１１．１０）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
[ Back to top ]