JP4806400B2

JP4806400B2 - Ｉｐネットワークの信頼できるドメインにおけるアイデンティティの処理

Info

Publication number: JP4806400B2
Application number: JP2007512547A
Authority: JP
Inventors: ガボルバイコ; エーミグエルガルシア−マルティン; バルッテリニエミ; タオハウッカ
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2004-05-03
Filing date: 2005-04-29
Publication date: 2011-11-02
Anticipated expiration: 2025-04-29
Also published as: US20050249219A1; KR20070006933A; PL1743449T3; CN1951061A; EP1743449A1; JP2007538426A; EP1743449B1; US8045540B2; TW200620949A; KR100884314B1; JP2010081636A; WO2005107145A1; TWI295135B

Description

本発明は、ネットワークの一部におけるアイデンティティの処理に関する。本発明はさらに、アサートしたアイデンティティに関して、信頼ドメインの境界を跨ぎ、ユーザーのプライバシ要件を受け付ける場合の、ユーザーがアサートしたアイデンティティの組み込みまたは除去に関する。

関連技術の説明

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のセキュリティアーキテクチャを示す図である。本発明の一実施形態に基づいた、プライバシの処理を示すフローチャートである。

Claims

第１のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが、次のSIPプロキシにSIPリクエストを転送しようとするときにおける、ユーザーのアイデンティティおよびプライバシの処理方法であって、
次のSIPプロキシへのホップにおいて、TLS（Transport Layer Security；トランスポート層セキュリティ）がサポートされているかどうかを判断するステップを有し、
TLSがサポートされている場合には、
前記次のSIPプロキシへの前記ホップにTLS接続を確立するステップ、
前記次のSIPプロキシへ証明書（certificate）を要求するステップ、
前記証明書を受信するステップ、
前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するステップ、
前記証明書および前記ネットワークの信頼性が検証された場合に、プライバシ情報を保持するステップを有し、
TLSがサポートされていない場合、もしくは前記証明書が検証されない場合、または前記ネットワークの信頼性が検証されない場合には、前記プライバシ情報を取り除くステップを有し、
さらに前記TLS接続を通じて前記SIPリクエストを転送するステップを有する、
方法。
前記証明書を検証するステップは、前記証明書が有効であるかどうかを判断するステップを含む、請求項１に記載の方法。
前記ネットワークの信頼性を検証するステップは、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップを含む、請求項１または２に記載の方法。
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するステップを含む、請求項3に記載の方法。
前記次のSIPプロキシは、以前に先の証明書を送信しており、前記証明書を検証するステップは、前記先の証明書が依然として有効であるどうかを判断するステップを含む、請求項１から４のいずれかに記載の方法。
信頼できる、および信頼できないSIPプロキシに対して別々のCSCF（Call Session Control Function；呼セッション制御機能）を保持するステップをさらに含む、請求項１から５のいずれかに記載の方法。
より高い優先権をTLSに与えるように、DNS（Domain Name Server；ドメインネームサーバー）のNAPTR（Naming Authority Pointer；ネーミング権限ポインタ）を構成するステップをさらに含む、請求項１から６のいずれかに記載の方法。
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが第１のSIPプロキシからSIPリクエストを受信する際、ユーザーのアイデンティティおよびプライバシを処理するために、該第１のSIPプロキシが信頼できるネットワークに属しているかどうかを判断する方法であって、
第１のSIPプロキシからSIPリクエストを受信するステップと、
前記SIPリクエストがTLS（Transport Layer Security；トランスポート層セキュリティ）を介して受信されたかどうかを判断するステップとを有し、
前記SIPリクエストがTLSを介して受信された場合には、
前記第１のSIPプロキシへ証明書（certificate）をリクエストするステップ、
前記証明書を受信するステップ、
前記証明書および前記第１のSIPプロキシのネットワークの信頼性を検証するステップ、
前記証明書および前記ネットワークの信頼性が検証された場合に、プライバシ情報を保持するステップを有し、
TLSがサポートされていない場合、または前記証明書が検証されない場合、あるいは前記ネットワークの信頼性が検証されない場合には、前記プライバシ情報を取り除くステップを有し、
さらに前記SIPリクエストに応答するステップを有する、
方法。
前記証明書を検証するステップは、前記証明書が有効であるかどうかを判断するステップを含む、請求項８に記載の方法。
前記ネットワークの信頼性を検証するステップは、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップを含む、請求項８または９に記載の方法。
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するステップを含む、請求項10に記載の方法。
前記第１のSIPプロキシは、以前に先の証明書を送信しており、前記証明書を検証するステップは、前記先の証明書が依然として有効であるどうかを判断するステップを含む、請求項８から１１のいずれかに記載の方法。
信頼できる、および信頼できないSIPプロキシに対して別々のCSCFを保持するステップをさらに含む、請求項８から１２のいずれかに記載の方法。
より高い優先権をTLSに与えるように、DNSのNAPTRを構成するステップをさらに含む、請求項８から１３のいずれかに記載の方法。
通信装置であって、
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシへのホップにTLS（Transport Layer Security；トランスポート層セキュリティ）接続を確立するための確立手段と、
TLSが前記次のSIPプロキシへの前記ホップにおいてサポートされているかどうかを判断するための判断手段と、
前記次のSIPプロキシへ証明書（certificate）をリクエストするためのリクエスト手段と、
前記証明書を受信するための受信手段と、
前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するための検証手段と、
前記TLS接続を通じて前記SIPリクエストを転送するための転送手段とを備え、
前記通信装置は、前記証明書が検証され、前記ネットワークの信頼性が検証され、およびTLSがサポートされている場合はプライバシ情報を保持するように構成され、TLSがサポートされていない場合もしくは前記証明書が検証されない場合または前記ネットワークの信頼性が検証されていない場合は前記プライバシ情報を取り除くように構成される、通信装置。
前記検証手段は、前記証明書が有効であるかどうかを判断するための手段を備える、請求項１５に記載の通信装置。
前記検証手段は、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するための手段を備える、請求項１５または１６に記載の通信装置。
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するための手段は、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するための手段を備える、請求項17に記載の通信装置。
前記次のSIPプロキシが以前に先の証明書を送信している場合に、前記検証手段は、前記先の証明書が依然として有効であるどうかを判断するための手段を備える、請求項１５から１８のいずれかに記載の通信装置。
信頼できる、および信頼できないSIPプロキシに対して別々のCSCFを保持するための手段を備える、請求項１５から１９のいずれかに記載の通信装置。
より高い優先権をTLSに与えるように、DNSのNAPTRを構成するための手段を備える、請求項１５から２０のいずれかに記載の通信装置。
通信システムであって、
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシへのホップにTLS（Transport Layer Security；トランスポート層セキュリティ）接続を確立するように構成された、TLS接続確立装置と、
前記次のSIPプロキシへの前記ホップにおいてTLSがサポートされているかどうかを判断するように構成された、TLSサポートアナライザと、
前記次のSIPプロキシへ証明書（certificate）をリクエストし、前記証明書を受信し、前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するように構成された、検証モジュールと、
前記TLS接続を通じて前記SIPリクエストを転送するように構成された、SIPリクエストハンドラとを備え、
前記通信システムは、前記証明書が検証され、前記ネットワークの信頼性が検証され、およびTLSがサポートされている場合はプライバシ情報を保持するように構成され、TLSがサポートされていない場合や前記証明書が検証されていない場合、または前記ネットワークの信頼性が検証されていない場合は前記プライバシ情報を取り除くように構成される、通信システム。
前記検証モジュールは、前記証明書が有効であるかどうかを判断するように構成される、請求項２２に記載の通信システム。
前記検証モジュールは、前記ネットワークが一群の信頼できるネットワークに属するかどうかを判断するように構成される、請求項２２または２３に記載の通信システム。
前記検証モジュールは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するように構成される、請求項２４に記載の通信システム。
前記次のSIPプロキシが以前に先の証明書を送信している場合に、前記検証モジュールは、前記先の証明書が依然として有効であるどうかを判断するように構成される、請求項２２から２５のいずれかに記載のシステム。
第１のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが、次のSIPプロキシにSIPリクエストを転送しようとするときに、ユーザーのアイデンティティおよびプライバシを処理するための、コンピュータ可読の媒体に組み込まれたコンピュータプログラムであって、該コンピュータプログラムはデータ処理装置を制御して、
次のSIPプロキシへのホップにおいて、TLS（Transport Layer Security；トランスポート層セキュリティ）がサポートされているかどうかを判断するステップを実行させ、
TLSがサポートされている場合には、
前記次のSIPプロキシへの前記ホップにTLS接続を確立するステップ、
前記次のSIPプロキシへ証明書をリクエストするステップ、
前記証明書を受信するステップ、
前記証明書および前記次のSIPプロキシのネットワークの信頼性を検証するステップ、
前記証明書および前記ネットワークの信頼性が検証された場合に、プライバシ情報を保持するステップを実行させ、
TLSがサポートされていない場合、もしくは前記証明書が検証されない場合、または前記ネットワークの信頼性が検証されない場合には、前記プライバシ情報を取り除くステップを実行させ、
さらに前記TLS接続を通じて前記SIPリクエストを転送するステップを実行させる、
プログラム。
前記証明書を検証するステップは、前記証明書が有効であるかどうかを判断するステップを含む、請求項２７に記載のコンピュータプログラム。
前記ネットワークの信頼性を検証するステップは、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップを含む、請求項２７または２８に記載のコンピュータプログラム。
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するステップを含む、請求項29に記載のコンピュータプログラム。
前記次のSIPプロキシは、以前に先の証明書を送信しており、前記証明書を検証するステップは、前記先の証明書が依然として有効であるどうかを判断するステップを含む、請求項２７から３０のいずれかに記載のコンピュータプログラム。
次のSIP（Session Initiation Protocol；セッション開始プロトコル）プロキシが第１のSIPプロキシからSIPリクエストを受信する際、ユーザーのアイデンティティおよびプライバシを処理するために、前記第１のSIPプロキシが信頼できるネットワークに属するかどうかを判断するための、コンピュータ可読の媒体に組み込まれたコンピュータプログラムであって、該コンピュータプログラムはデータ処理装置を制御して、
第１のSIPプロキシからSIPリクエストを受信するステップと、
前記SIPリクエストがTLSを介して受信されたかどうかを判断するステップとを実行させ、
前記SIPリクエストがTLSを介して受信された場合には、
前記第１のSIPプロキシから証明書をリクエストするステップ、
前記証明書を受信するステップ、
前記第１のSIPプロキシのネットワークの証明書および信頼性を検証するステップ、
前記ネットワークの証明書および信頼性が検証された場合に、プライバシ情報を保持するステップを実行させ、
TLSがサポートされていない場合、もしくは前記証明書が検証されていない場合、または前記ネットワークの信頼性が検証されていない場合には、前記プライバシ情報を取り除くステップを実行させ、
さらに前記SIPリクエストに応答するステップを実行させる、
コンピュータプログラム。
前記証明書を検証するステップは、前記証明書が有効であるかどうかを判断するステップを含む、請求項３２に記載のコンピュータプログラム。
前記ネットワークの信頼性を検証するステップは、前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップを含む、請求項３２または３３に記載のコンピュータプログラム。
前記ネットワークが一群の信頼できるネットワークに属しているかどうかを判断するステップは、前記ネットワークが信頼できるネットワークのリストにあるかどうかを判断するステップを含む、請求項34に記載のコンピュータプログラム。
前記第１のSIPプロキシは、以前に先の証明書を送信しており、前記証明書を検証するステップは、前記先の証明書が依然として有効であるどうかを判断するステップを含む、請求項３２から３５のいずれかに記載のコンピュータプログラム。
前記プライバシ情報はサブスクライバのアイデンティティ情報を含む、請求項１に記載の方法。
前記プライバシ情報はサブスクライバのアイデンティティ情報を含む、請求項８に記載の方法。
前記プライバシ情報はサブスクライバのアイデンティティ情報を含む、請求項１５に記載の通信装置。
前記プライバシ情報はサブスクライバのアイデンティティ情報を含む、請求項２２に記載の通信システム。
前記プライバシ情報はサブスクライバのアイデンティティ情報を含む、請求項２７に記載のコンピュータプログラム。
前記プライバシ情報はサブスクライバのアイデンティティ情報を含む、請求項３２に記載のコンピュータプログラム。