JP4866802B2 - セキュリティ最適化システムおよびセキュリティ最適化方法 - Google Patents

セキュリティ最適化システムおよびセキュリティ最適化方法 Download PDF

Info

Publication number
JP4866802B2
JP4866802B2 JP2007173960A JP2007173960A JP4866802B2 JP 4866802 B2 JP4866802 B2 JP 4866802B2 JP 2007173960 A JP2007173960 A JP 2007173960A JP 2007173960 A JP2007173960 A JP 2007173960A JP 4866802 B2 JP4866802 B2 JP 4866802B2
Authority
JP
Japan
Prior art keywords
cscf
new
ipsec
security
ims
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007173960A
Other languages
English (en)
Other versions
JP2008072694A (ja
Inventor
恒彦 千葉
英俊 横田
彰 井戸上
アシュトシュ・デュッタ
アブフラジット・ゴッシュ
スビール・ダス
ジョー・リン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KDDI Corp
Original Assignee
KDDI Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by KDDI Corp filed Critical KDDI Corp
Publication of JP2008072694A publication Critical patent/JP2008072694A/ja
Application granted granted Critical
Publication of JP4866802B2 publication Critical patent/JP4866802B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H04W36/0038Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information of security context information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03Protecting confidentiality, e.g. by encryption
    • H04W12/033Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041Key generation or derivation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272Virtual private networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/164Implementing security features at a particular protocol layer at the network layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、IMS/MMD(IP Multimedia Subsystem/Multimedia Domain)アーキテクチャのためのセキュリティの最適化システムおよび方法に関する。
IMS/MMDセキュリティアーキテクチャの重点は、加入者とIMSとの間のSIP(Session Initiation Protocol)シグナリングの保護である。IMSアーキテクチャは、加入者とIMSとの間の相互認証の手段を定義し、かつIMSネットワーク要素間のドメイン間通信およびドメイン内通信を安全にするためのメカニズムを指定する。
IMSセキュリティアーキテクチャ(図1)は、各種の要素間のセキュリティインタフェースに数字のラベルが付与されたIMS/MMDセキュリティアーキテクチャの高レベルの概観を表わす。IMS AKA(Authentication and Key Agreement)(インタフェース1)は、UE(User Equipment(ユーザ装置))とホームネットワークとの間の認証に用いられ、IMS/MMDにおけるその役割は以下で説明される。IPSecは、UEと第1ホップ(first-hop)のP−CSCF(Proxy Call Session Control Function)との間(インタフェース2)、IMSコアネットワーク要素間(インタフェース3、4、5)、IMSコア要素と外部IPネットワークとの間(インタフェース6、7)のSIPメッセージングを安全にするために用いられる。IPSecは、通信が同じセキュリティドメイン内に存在するとき、または、セキュリティドメインをまたぐときの両方に適用可能である。IMS/MMDにおけるIPSecの役割は、以下で説明される。
3GPP2 X.S0013-002-A v1.0: "All-IP Core Network Multimedia Domain; IP Multimedia Subsystem - Stage 2," November 2005 3GPP2 X.S0013-004-A v1.0: "All-IP Core Network Multimedia Domain: IP Multimedia Call Control based on SIP and SDP - Stage 3," November 2005
現在のIMS/MMDセキュリティアーキテクチャは、なりすましの脅威に取り組む。ここでは、攻撃者は、ネットワーク要素または権限を与えられたユーザのいずれかのふりをすることによって、権限なくサービスへのアクセスを取得することができる。AKAおよびIPSecによる加入者認証の組み込み、および、IPSecを用いたネットワークノード認証は、その発生を防止する。
盗聴の問題も取り組まれている。ここでは、攻撃者は、シグナリングメッセージの機密性を危うくし、または、それらの危険でないトラフィック解析を行うことがありうる。IPSecに基づく暗号は、このカテゴリーの脅威に取り組むために適用される。
セキュリティアーキテクチャは、本来、IMSサービスにアクセスするためのホームネットワークに基づく認証を可能とする。訪問先ネットワークは、UEによって用いられるベアラリソースを制御するが、IMSの権限付与はホームネットワークにおいてS−CSCF(Serving Call Session Control Function)から取得されるのみである。
上記の課題を解決するために、本発明に係るセキュリティ最適化システムは、IMS/MMDアーキテクチャのためのセキュリティ最適化システムであって、モバイルノードがハンドオーバする前の元のP−CSCFと、新たなP−CSCFとを備え、元のP−CSCFは、モバイルノードから新たなP−CSCFのアドレスを受信し、新たなP−CSCFにセキュリティアソシエーション鍵を含むコンテキストを伝送し、新たなP−CSCFは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなPDSNにおいてモバイルノードのためのゲートをオープンすることを特徴とする。
本発明に係るセキュリティ最適化システムは、IMS/MMDアーキテクチャのためのセキュリティ最適化システムであって、モバイルノードがハンドオーバする先の新たなP−CSCFと、S−CSCFとを備え、S−CSCFは、モバイルノードから新たなP−CSCFのアドレスを受信し、新たなP−CSCFにセキュリティアソシエーション鍵を含むコンテキストを伝送し、新たなP−CSCFは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなPDSNにおいてモバイルノードのためのゲートをオープンすることを特徴とする。
本発明に係るセキュリティ最適化方法は、IMS/MMDアーキテクチャのためのセキュリティ最適化方法であって、モバイルノードが、ハンドオーバする前の元のP−CSCFに新たなP−CSCFのアドレスを通知するステップと、元のP−CSCFが、新たなP−CSCFにセキュリティアソシエーション鍵を含むコンテキストを伝送するステップと、新たなP−CSCFが、モバイルノードのためのセキュリティアソシエーションを確立し、新たなPDSNにおいてモバイルノードのためのゲートをオープンするステップとを含むことを特徴とする。
本発明に係るセキュリティ最適化方法は、IMS/MMDアーキテクチャのためのセキュリティ最適化方法であって、モバイルノードが、ハンドオーバする先の新たなP−CSCFのアドレスをS−CSCFに通知するステップと、S−CSCFが、新たなP−CSCFにセキュリティアソシエーション鍵を含むコンテキストを伝送するステップと、新たなP−CSCFが、モバイルノードのためのセキュリティアソシエーションを確立し、新たなPDSNにおいてモバイルノードのためのゲートをオープンするステップとを含むことを特徴とする。
本発明によれば、IMS/MMDアーキテクチャにおいて、モバイルノードがP−CSCFハンドオフする際のセキュリティアソシエーションの再結合の間の遅延を軽減することができ、セキュリティの最適化を図ることができる。
IMS/MMDセキュリティアーキテクチャの重点は、加入者とIMSとの間のSIPシグナリングの保護である。IMSは、加入者とIMSとの間の相互認証の手段を定義し、かつIMSネットワーク要素間のドメイン間通信およびドメイン内通信を安全にするためのメカニズムを指定する。SIPのようなシグナリングトラフィックとRTPのようなメディアトラフィックの両方についてセキュリティアソシエーションを確立することが可能である。IMS/MMDアーキテクチャにおけるハンドオフ動作を最適化するために、セキュリティアソシエーションの設定に寄与する動作を最適化することが重要である。なぜなら、これらの動作の各々はハンドオフ遅延を引き起こすもととなるからである。一連のセキュリティ最適化の方法論は、セキュリティに関する動作に影響を与えるそれらのパラメータを考慮する必要がある。
IPSecは、IPレイヤのトラフィックのセキュリティを保証するために設計された一連のセキュリティプロトコルである。IPSec ESP(Encapsulating Security Payload)プロトコルは、IPパケットペイロードの機密性および完全性の保護をサポートし、一方、IPSec AH(Authentication Header)プロトコルは、IPパケット全体の完全性の保護をサポートする。ESPおよびAHプロトコルサービスは、IPSecが使用可能なネットワークノード間でセキュリティアソシエーション(SA(Security Association))を確立することによって提供される。他のパラメータの中で、SAは、一組のノード間で使用される完全性の保護および暗号化アルゴリズム、および、これらのアルゴリズムによって使用される対称鍵を定義する。また、IPSecは、鍵ネゴシエーションプロトコル(IKE(Internet Key Exchange))を定義し、これはESPまたはAHのSAによって使用される対称鍵を安全に確立するために使用される。
IPSecのESPおよびAHプロトコルは、トンネルモードまたはトランスポートモードのいずれにおいても動作する。トンネルモードにおいてはIPパケット全体が新たなIPパケット内にカプセル化され、一方、トランスポートモードにおいてはIPペイロードに追加または修正が行われる。パケットあたりのオーバーヘッドはトンネルモードにおいて幾分高く、通信ノード間に配置されたIPSecゲートウェイにおいて用いられるとき、トラフィック解析を避けることを第一に意図している。
IPSecプロトコルはインターネットにおいて広く用いられている。プロトコル一式は、システムアーキテクチャを変更することなく新たな機密性および完全性保護アルゴリズムを組み込むことが可能であるという意味でモジュール方式である。IPSecトラフィックは、下位の物理レイヤまたは相互接続トポロジーを変更することなく既存のIPインフラ上で伝送可能である。典型的に、IPSec動作はアプリケーションレイヤのエンティティに透過的である。IMS/MMDフレームワークにおいて、IPSecは、主として、UEとP−CSCFとの間(図1のインタフェース2)で交換されるSIPメッセージに機密性および完全性の保護を提供するために用いられる。IPSec ESPは、トランスポートモードで動作し、このコンテキストでの使用が必須である。UEおよびP−CSCFがお互いに相互認証に成功すると、IPSec ESPトランスポートモードSAが、UEとその対応するP−CSCFとの間で確立される。IPSec SA確立手順はIMS AKAが受け持つ。
以下は、P−CSCFとUEとの間で動作するIPSecの特徴のリストである。
・IPSec ESP処理は、P−CSCFおよびUEにおいてSIPアプリケーションに透過的であり、IPSecモジュールによって実行される。SIPアプリケーションはIPSecモジュール内でSAを設定するが、これらのIPSecモジュールは、SIPアプリケーションの範囲外で動作する。
・IPSecはSIPメッセージのためのデータ認証を提供し、UEにおいて受信されIPSec ESPによって保護されたメッセージは、(P−CSCFおよびUEが危険にさらされていないと仮定して)P−CSCFによって生成されたことが保証され、逆もまた同様である。さらに、メッセージは相手方によってリプレイされなかったことが保証される。
・また、IPSecは、SIPメッセージにデータ機密性を提供する。危険にさらされていないP−CSCFおよびUEを仮定して、IPSecはそれらの間で生成されたメッセージに機密性を提供し、盗聴者は捕捉したどのパケットも復号化することができない。
・IPSec ESPはIPヘッダの完全性を保護しないので、受信側SIPアプリケーションは、保護されたSIPメッセージのコンタクトヘッダがパケットヘッダにおけるソースIPヘッダと合致することを検証する必要がある。
また、IPSecは、単一の通信事業者ドメイン内で(ドメイン内で)、または、2つ以上の通信事業者ドメインにわたって(ドメイン間で)、相互作用するコアIMSネットワーク要素間で用いることが可能である。IPSecの様式は、関係する通信事業者の自由裁量に任されている。ドメイン間のセキュリティの提供は、I−CSCF(Interrogate Call State Control Function)とP−CSCFとの間(図1のインタフェース4)、S−CSCFとP−CSCFとの間(図1のインタフェース4)、S−CSCFとSIPアプリケーションサーバを収容する外部IPネットワークとの間(図1のインタフェース7)のSIPメッセージングを安全にすることを含む。さらに、外部SIPアプリケーションサーバとHSS(Home Subscriber Server)との間(Cxインタフェース)(図1のインタフェース6)のメッセージングを安全にすることも含む。全ての場合において、暗号化とともに完全性の保護を用いる(トランスポートモードまたはトンネルモードのいずれかにおける)IPSecの使用が必須である。さらに、そのようなノード間でセキュリティアソシエーションをネゴシエーションするためのIKEの使用が要求される。IPSecに基づくドメイン間のセキュリティは次のような特徴を有する。
・IKEの使用は、通信ノード間で共有鍵の安全なネゴシエーションを可能とする。IMS AKAによって要求されるような鍵の事前配置は必要ない。
・IKEは、Diffie-Hellman交換を用いた共有鍵の算出のために公開鍵を用いる。Diffie-Hellman交換は中間者(man-in-the-middle)攻撃を受けやすいので、鍵の信憑性を保証するために公開鍵証明書の使用が必須である。
・通信事業者ネットワークをまたがるトンネルモードのセキュリティアソシエーションの使用は、通信事業者ネットワーク間でセキュリティゲートウェイの使用を可能とする。トンネルモードSAはIMSノードにおいて生成されたパケットのIPヘッダを暗号化するので、トラフィック解析攻撃からの通信事業者ネットワークの保護を可能とする。
ドメイン内のセキュリティ(図1のインタフェース3および5)は、ドメインの管理権限に解放されている。特定の鍵配送/ネゴシエーションメカニズムまたはSAモードは必須ではないが、IPSecに基づく機密性および完全性の保護はオプションである。
IMS AKAは、UEとHSSとの間で用いるために定義される認証プロトコルである。これはSIPセキュリティメカニズム合意プロトコルに基づく。全てのセキュリティパラメータがSIPを用いてUEとHSSとの間で交換される。
図2は、UE、P−CSCF、I−CSCF、S−CSCF、HSSを含む、IMS AKAを構成するSIPメッセージフローを表わす。IMS AKAは、対応する鍵配送処理とともにSIP登録/応答メッセージの上に載せられる。2組の登録/応答メッセージが要求される。メッセージの第1の組の最後に、UEとP−CSCFとの間でIPSec SAが確立される。UEは、4xx Auth_Challengeメッセージを受信した後にネットワークを認証し、一方、ネットワークは、第2の登録メッセージを受信した後にUEを認証する。
IMS/AKAの特徴は次の通りである。
・SIPメッセージングがサービング(訪問先ネットワーク)上で伝送されるときでも、認証はUEとそのホームネットワークとの間で実行される。訪問先ネットワークはPDS(Packet Data Service)上のベアラリソースの制御を有するが、これは、IMSリソースへのホームネットワークに基づくアクセス制御を可能とする。
・SIP登録/応答メッセージはIMS/AKAプロトコルペイロードを伝送するために用いられる。これらのメッセージは、UEからS−CSCFに送信され、その逆も同様である。S−CSCFはHSSにUEについてのセキュリティ関連パラメータを取得することを要求する。
・UEおよびHSSはロングターム鍵(K)を共有する。この鍵はIMS/AKAプロトコル動作の間のみ使用され、UEにおけるIPSec処理の間は使用されない。
・IMS/AKAはホームネットワークにUEが真正であることを証明するためにチャレンジレスポンスメカニズムを用いる。P−CSCFを介してS−CSCFによって送信されたチャレンジへの応答を計算するためにKを用いる。P−CSCFは、転送する要素として動作することを除いてチャレンジ生成において何の役割も果たさない。
・UEは、P−CSCFを介してS−CSCFによって送信されたMAC(Message Authentication Code)の検証によって、UEにネットワークが真正であることを証明される。MACはUEにおいてKを用いて検証される。
・IMS AKAに基づく登録処理の間に、UEとその現在のP−CSCFとの間にIPSec ESP SAが確立される。HSSは、IPSec SAにおいて用いられる完全性鍵(IK)および暗号化鍵(CK)を導き出すためにKを用いる。新たなIMS AKA手順がUEとその現在のP−CSCFとの間で発生するときはいつでも、新たなIK、CKの組が新たなIPSec SAを設定するために用いられる。
・ホームネットワークのS−CSCFからのSIP応答メッセージを用いた一連のIMS AKA手順の間に、IK、CKの組が訪問先P−CSCFに伝送される。KはP−CSCFに送信されず、従って、IK、CKが特定のSAについて危険にさらされても、Kは危険にさらされない。
・IPSec SAは、常に、SIP登録の有効期間よりわずかに長い有効期間を有する。これは、新たなSIP登録が、可能ならばいつでも以前から存在するSAの活用を可能とする。
UEとP−CSCFとの間で交換されるSIPパケットは、一方向ESP伝送モードSAの組を用いて保護される。従って、UEは、P−CSCFから受信されるパケットのためのインバウンドSA、および、P−CSCFに送信されるパケットのためのアウトバウンドSAを有する。また、P−CSCFは、通信する各UEのためのSAの類似する組を有する。これらのSAは、IMS AKAプロトコルを用いてUEとP−CSCFとの間で確立される。
IPv4についてのIPSec ESPのトランスポートモードの動作が図3に表わされている。図は、TCPペイロードの場合についてのIPSec ESPの動作を表わし、UDPペイロードについての動作は、パケットにおいてTCPプロトコルの記号をUDPプロトコルの記号に置き換えたものと同一である。SIPメッセージングはUDPまたはTCP上で実行され、従って、SIPヘッダおよびペイロードは図3に表わすパケットのデータ部において伝送される。
SAが確立されると、UEからP−CSCFに送信される全てのSIPパケットはIPSecによって次のように処理される。
1.UDP伝送を仮定すると、UEにおいて生成されるSIPパケットはUDPペイロード内にカプセル化され、次に、IPペイロード内にフレーム化される。このIPパケットは、UEにおいてアウトバウンドSAによって処理される。
2.パッドバイトおよびペイロード情報を含むESPトレーラが(SIPデータグラムを含む)IPペイロードに付加される。IPペイロードおよびESPトレーラは、IMS/MMDに必須のアルゴリズムの1つを用いて暗号化される。必須のアルゴリズムはDES−EDE3−CBCおよびAES−CBCである。
3.SA固有情報を含むESPヘッダは、IPペイロードと元のIPヘッダとの間に挿入される。
4.新たなIPペイロード(ESPヘッダからESPトレーラまで)は、IMS/MMDの必須アルゴリズムの1つによって完全性が保護される。これらは、HMAC−MD5−96またはHMAC−SHA−1−96である。完全性保護情報は、IPデータグラムの最後に付加されたESP認証フィールドに格納される。
5.新たに付加されたESPフィールドとともにIPデータグラムは、ここで、PDSレイヤの上でP−CSCFに送信される。
6.IPデータグラムを受信すると、P−CSCFは、ESPヘッダおよびIPヘッダの宛先IPアドレスを調べることによって、使用するインバウンドSAを決定する。
7.まず、P−CSCFは、ESP認証ヘッダフィールドおよび選択されたSAによって指定された完全性保護鍵を用いることによってパケットの完全性を検査する。
8.完全性が検証されると、P−CSCFは、IPペイロードを復号化するために、SAによって指定された復号鍵を用いる。復号化が完了すると、ESP関連ヘッダは削除され、パケットはようやくSIPアプリケーションに伝送される。
また、P−CSCFからUEに送信されるSIPパケットは、P−CSCFにおける対応するアウトバウンドSA、および、UEにおけるインバウンドSAを用いて、同様な方法で処理される。
P−CSCFは、UEから受信したSIPパケットを他のIMSネットワーク要素に転送し、その逆も同様である。従って、SIPシグナリングパケットは、IMSコアネットワーク内を通過するときは保護される必要がある。これは、ドメイン間のネットワーク要素の間で交換されるシグナリングメッセージのためにドメイン間のセキュリティを実現するための手段としてIPSecを指定する。IPSecが使用可能でない場合には、これはネットワーク要素間でホップ毎のセキュリティを実現する手段としてTLS(Transport Layer Security)の使用を提案する。IMSネットワーク要素が同じネットワーク事業者ドメイン内に存在する場合には、セキュリティメカニズムはネットワーク事業者の自由裁量に任される。
IMS/MMDセキュリティフレームワークは、IMSレイヤにおいてメディアを安全にする手段を指定しない。重点はSIPに基づくシグナリングメッセージを安全にすることにある。メディアセッションは、P−CSCF、I−CSCF、S−CSCFのようなIMSコアネットワーク要素を通して流れないので、範囲外である。IPマルチメディアセッションは、ユーザデータパケットの形式でPDSを移動する。図4に表わされているように、いくつかのセキュリティが、無線アクセス(RA)レベルおよびIPネットワークレベルにおいてデータパケットに提供される。
RAレベルのセキュリティは、ネットワークプロバイダの自由裁量において、機密性の要件をサポートするために、エアインタフェース暗号を組み込む。しかし、これはメディアのエンドエンド間のセキュリティを提供しない。
ネットワーク事業者の自由裁量において、ホームエージェントとフォーリンエージェント(Foreign Agent)との間でIPSecがサポートされる。さらにまた、これはエンドエンド間のセキュリティを提供しない。
エンドエンド間のセキュリティはユーザの要求により追加されるが、これらのメカニズムは3GPP2(3rd Generation Partnership Project 2)標準において指定されていない。エンドエンド間のセキュリティは、ネットワークセキュリティのメカニズムにおいてユーザが有する機密性のレベルまたはメディアコンテンツの特性に基づいて要求される。しかし、ある場合において、エンドエンド間のセキュリティは、適法に認可された電子的監視(Lawfully Authorized Electronic Surveillance)を要求する政府の規制に阻まれる。
エンドエンド間のセキュリティを実行するために代替のメカニズムが利用可能である。
・IPSec:UEにおいて既に存在するIPSecサービスを用いることによってネットワークレイヤのエンドエンド間のセキュリティが提供される。この場合において、SAはUE間で直接に確立され、PDSからのサポートは要求されない。UEにおいてアプリケーションが生成するメディアコンテンツは、IPSecの導入によって影響を受けず、メディアストリーミングプロトコルもIPSecの存在を意識しない。
・SRTP:セキュアリアルタイムトランスポートプロトコルは、リアルタイムトランスポートプロトコル(RTP)の一側面であり、RTPトラフィックおよびRTP制御トラフィックへの機密性、メッセージ認証、リプレイ保護を提供することが可能である。IPSecと同様に、PDSのサポートは要求されない。しかし、アプリケーションが生成するメディアコンテンツは、SRTPをサポートする必要がある。
ここで2つの異なる場合を検討する:それぞれの移動プロトコル(mobility protocol)としてFAモードにおいて、(1)MIPv6(Mobile IP version 6)が用いられる場合、(2)MIPv4(Mobile IP version 4)が用いられる場合である。図5はMIPv6が配置されたシナリオを表わす。そのようなシナリオにおいて、移動ノードから2つのトンネルが要求され、1つはMN(Mobile Node)とHA(Home Agent)との間、他の1つはMNとP−CSCFとの間のMIPv6トンネルである。移動ノードは、ローミングするときにブートストラップするにせよ、P−CSCFを変更するにせよ、ホームP−CSCFとIPSec SAを確立することを要求する。また、どのようにSAが生成されるかに応じて、MNは、新たなPDSN(Packet Data Serving Node)に変更するときに同じP−CSCFと新たなSAを確立することを要求する。従って、(MIPv6トンネルに加えて)MNにおいてより多くのトンネルオーバーヘッドを追加する。課題はそのようなオーバーヘッドを最小化することである。
移動ノードの位置およびアクセスネットワークの状態に応じて、IPSec SAの確立はハンドオフの性能にいくらかの影響を与える。メディアはIPSec SAを介して交換されることを必要としないが、P−CSCFは重要な経路に存在するので、登録を含む全てのSIPシグナリングはIPSec SAを介して交換されることが必要である。また、MNが新たなPDSNに接続している間、セッションが維持されるように、IPSec SAの確立は十分早いことが必要である。従って、ハンドオフの間のいくつかの課題が見られ、そのようないくつかの課題を挙げると次の通りである。
・IPSec SAの確立の遅延
MNが遠隔のネットワークにアクセスしているとき、IPSec SAの確立の遅延は大きい。これは、ブートストラップの間の課題ではないが、この遅延が大き過ぎるとハンドオフの性能に影響を与える。
・PDSNを変更する間の新たなSAの確立
大部分の一般的な場合において、IPSec SAはインタフェースのIPアドレスに結合される。従って、インタフェースのIPアドレスが変更されると(MNが他のPDSNに接続すると)、(SAが恒久的な識別子に結合されていなければ、)新たなIPSec SAの確立が必要である。
・ハンドオフの間のP−CSCFの変更
訪問先ネットワークが異なるP−CSCFを割り当てられているシナリオでは、MNは、ネットワークを変更する間、新たなIPSec SAを生成する必要がある。しかし、これは一般的なケースではない。
これらは、配置の間に適切に計画されなければ、IPSecのためにコアネットワークにおいても(主としてシステムレベルで)いくらかの影響が存在する。
・IPSecトンネルの数
大規模ネットワークにおいて、ホームネットワークとのシグナリング交換、メディア送信、管理データ交換のために、サービスセッションの間に設定されることが必要な多くの通信経路が存在する。注意深い計画なしでは、要求されるIPSecトンネルの数は、装置とともにより多くのアプリケーションが配置されるに従って増加する。従って、システムの性能は、システムにおいてオープンされる過度のIPSecトンネルの数のためにひどく劣化する。
・パケットの断片化
IPレイヤ3におけるデータパケットにIPSecが適用されるとき、IPSecアルゴリズムが起動される必要があることを受信側に知らせるために、ヘッダ、トレーラ、または、その両方がパケットに付加されることが必要である。これはパケットの長さを増大させ、送信のためにパケットが2つのパケットに分割されることを引き起こす(IPの断片化として知られる)。例えば、元のパケットサイズが1490バイトであるならば、ESP(カプセル化されたセキュリティペイロード)ヘッダ、トレーラ情報、MAC(メッセージ認証コード)値が付加された後、1544バイトに増加する。従って、(イーサネット(登録商標)の場合)パケットは2つのパケットに断片化される必要がある。これらの追加のパケットはシステムに追加処理の負荷をかけ、従って、ネットワークの全体の性能を劣化させる。多数の要求が移動ノードから同時に生じるならば、これはかなりの遅延を与える。
一方、図6は、MIPv4の場合に要求されるトンネルを表わす。そのようなシナリオにおいて移動ノードから要求されるトンネルの数はただ1つの、例えば、(MIPトンネルはFAとHAとの間に存在するので、)MNとP−CSCFとの間のIPSecトンネルである。しかし、高速なIPSec SAの確立は、よりよいハンドオフ性能を達成するために必要である。このアーキテクチャは、MIPv6の場合に上述したのと同じタイプのIPSecの課題を有する。
また、ここで2つの異なる場合を検討する:それぞれの移動プロトコルとしてFAモードにおいて、(1)MIPv6が用いられる場合、(2)MIPv4が用いられる場合である。図7はMIPv6が配置されたシナリオを表わす。そのようなシナリオにおいて、移動ノードから2つのトンネルが要求され、1つはMNとHAとの間、他の1つはMNとP−CSCFとの間のMIPv6トンネルである。移動ノードは、ローミングするときにブートストラップするにせよ、P−CSCFを変更するにせよ、訪問先P−CSCFとIPSec SAを確立することを要求する。前述のアーキテクチャとの唯一の相違は、P−CSCFが全て訪問先ドメインに存在することである。
一方、図8は、MIPv4の場合に要求されるトンネルを表わす。そのようなシナリオにおいて移動ノードから要求されるトンネルの数は、前述のようにただ1つである。しかし、高速なIPSec SAの確立は、よりよいハンドオフ性能を達成するために必要である。
ここでも2つの異なる場合を提示する:それぞれの移動プロトコルとしてFAモードにおいて、(1)MIPv6が用いられる場合、(2)MIPv4が用いられる場合である。図9はMIPv6が配置されたシナリオを表わす。前述のように、移動ノードから2つのトンネルが要求され、1つはMNとHAとの間、他の1つはMNとP−CSCFとの間のMIPv6トンネルである。このアーキテクチャは、MNが新たなサブネットに移動するごとに新たなIPSec SAを確立することが必要であるという点で、前述の2つのアーキテクチャと大きな相違を有する。すなわち、PDSNを変更するごとに、新たなP−CSCFに接続する。従って、MNにおいて次のような課題を有する。
・IPSec SAの確立の遅延
MNが新たなサブネットに移動するごとに通常のAKA手順とともにSIP登録を実行しなければならないので、IPSec SAの確立の遅延は大きい。従って、認証が成功し、従って、MNとP−CSCFとの間でSAが確立されなければ、新たなPDSNを通してメディアが流れ始めないので、ハンドオフの性能に影響しうる。
これらは、配置の間に適切に計画されなければ、IPSecのために訪問先ネットワークにおいても(主としてシステムレベルで)いくらかの影響が存在する。それは次の通りである。
・P−CSCFにおけるIPSecトンネルの数
非常に混雑した訪問先ネットワークにおいて、ブートストラップの間またはサービスセッションのハンドオフの間に、IPSec SAを設定する必要がある多数の移動ノードが存在する。注意深い計画なしでは、要求されるIPSecトンネルの数は、加入者数の増加とともに大きな数に増加する。従って、システムの性能は、システムにおいてオープンされる過度のIPSecトンネルの数のためにひどく劣化する。結果として、これはSA初期化の間により大きな遅延を与える。
・パケットの断片化
上述したのと同様である。
図10は、MIPv4の場合に要求されるトンネルを表わす。そのようなシナリオにおいて移動ノードから要求されるトンネルの数は、前述のようにただ1つである。しかし、高速なIPSec SAの確立は、よりよいハンドオフ性能を達成するために必要である。このアーキテクチャは上述したのと同じタイプのIPSecの課題を有する。しかし、wi−fi(Wireless Fidelity)ネットワークからアクセスするときを除いて、ただ1つのトンネルを確立することが必要であるので、MNにおいてトンネルオーバーヘッドに関しての影響はより小さい。
P−CSCFにおけるIPSecトンネルの確立の遅延は、ハンドオフの間のセッション移行におけるシグナリングおよびメディアの両方にかなりのオーバーヘッドを与えうる。特に、アーキテクチャIIbは、各サブネットの変更の間にMNを登録することを要求する。なお、P−CSCFを外部ネットワークに配置し、かつ、それぞれのサブネットワーク毎にP−CSCFを配置した場合のアーキテクチャを「アーキテクチャIIb」と称している。登録のためのシグナリングおよびメディア伝送は移動ノードから同時に生じうるが、P−CSCFとMNとの間でSAが確立されるまで、新たなPDSNを介してメディアを再開することができない。登録が新たな訪問先ネットワークにおいて成功すると、すなわち、MNと新たなP−CSCFとの間でIPSec SAが確立されると、IMS/MMDにより、訪問先ネットワークにおけるアクセス制御ポリシーは、新たなPDSNを介してメディアが流れることを可能とする。従って、メディアはIPSec SAを介して保護されないが、SIP登録とメディア伝送との間に暗黙の依存関係が存在する。しかし、MIPバインディング更新(binding update)手順は、HAの位置に応じてメディアにかなりの遅延を与える。IMS/MMDセキュリティフレームワークは、UE(すなわち、MN)とP−CSCFとの間のセキュリティメカニズムを定義し、IMS AKAと呼ばれる。IMS/MMDフレームワークにおけるIMS AKAの役割を検討する。登録手順の間、P−CSCFは、他のパラメータとともにS−CSCFからMNごとに新たな一組の鍵(例えば、IKおよびCK)を受信する。これらの鍵は、新たなUEとSAを確立するために用いられる。UEは、サブネットを変更するときに同じS−CSCFとともに登録されるが、理想的には新たなS−CSCFのために生成される鍵は異なるべきである。しかし、このネットワークにおいて、これらの鍵は、P−CSCFを危うくするごくわずかの機会が同じく与えられる。
従って、上記手順は時間を要し、P−CSCFのハンドオフの間にかなりの遅延を与えうることが明らかである。さらに、MNにおける複数のトンネルは全体のハンドオフ手順に、より大きなオーバーヘッドを与える。従って、IPSecの最適化が要求され、IPSecの最適化とは、IMS/MMDのセキュリティを危うくすることなく、あるアプリケーションによって要求されるならばメディアを保護する一方で、この遅延が最小化されうるメカニズムを意味する。IPSecの最適化は2つの部分を有する:(1)SAの再結合の間の遅延を軽減する、(2)MNにおけるシグナリングおよびメディアのためのIPSecトンネルのオーバーヘッドを軽減する。以下、そのような課題がどのように軽減されるか検討し、あるアプリケーションにおいてメディアのセキュリティも要求されるならば用いられるいくつかの代替のメカニズムを提供する。
SAの再結合の間の遅延を軽減するために、次の方法が適用される。これらの方法はアーキテクチャIIbに適用可能である。
・元のP−CSCFから新たなP−CSCFにSA鍵を伝送する
この場合のIPSec最適化システム(S100)が図11に表わされている。
MNが1つのサブネットから他のサブネットに移動するときにP−CSCFにおいてMNごとに鍵が変更されないと仮定すると、MNが物理的に新たなサブネットに移動する前にSAが確立されるように、鍵はあるコンテキスト伝送メカニズムを通して元のP−CSCFから新たなP−CSCFに伝送される。しかし、元のネットワークが、移動局が移動していることを認識し、かつ新たなP−CSCFのIPアドレスを元のP−CSCFに通知するメカニズムが必要である。これは移動管理メカニズムに新たな課題をもたらすが、プロアクティブな(proactive)ハンドオーバを行い、新たな宛先を予測することは可能である。鍵が利用可能になると、P−CSCFは通常のSIP登録を並行して実行しながらSAを生成する。従って、SA鍵を取得するために完全なAKA手順への依存を最小化することができる。実際、アクセス制御ポリシーは、新たな訪問先ネットワークを通してMNがパケットを送信するとすぐにメディアが流れることを可能とする。いくつかのメカニズムは、鍵および他の呼状態パラメータを新たなP−CSCFに伝送するために用いることが可能である。例えば、IETF CXTP(Context Transfer Protocol(コンテキスト伝送プロトコル))、SIPメソッド、例えば、MESSAGE、SUBSCRIBE/NOTIFY等は、この目的のために使用することが可能である。
・呼の流れ
図11は、IPSec SA鍵が元のP−CSCFから新たなP−CSCFに伝送される最適化されたIPSecについての呼の流れを表わす。図において、この最適化された部分の間に要求される一連のステップを表わす。これらのメッセージ交換は、プロアクティブな、および、リアクティブな(reactive)ハンドオーバ時間の間に生じうる。MIPバインディング更新は、トロンボーンルーティングとしても知られるルーティングのループを避けるためにSAが確立される前にゲートを通過する必要がある。従って、新たなPDSNは、SIP初期登録およびMIPバインディング更新のポートを常にオープンし続けると仮定する。
図11において、モバイルノード(MN)がハンドオーバする前の元のP−CSCFと、新たなP−CSCFとを備える。元のP−CSCFは、モバイルノードから新たなP−CSCFのアドレスを受信し、新たなP−CSCFにセキュリティアソシエーション(SA)鍵を含むコンテキストを伝送する。新たなP−CSCFは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなPDSNにおいてモバイルノードのためのゲートをオープンする。
・S−CSCFから新たなP−CSCFにSA鍵を伝送する
この場合のIPSec最適化システム(S200)が図12に表わされている。
この場合、MNが物理的に新たなサブネットに移動する前にSAが確立されるように、十分に前もってあるコンテキスト伝送メカニズムを通してS−CSCFによって新たなP−CSCFにSA鍵が伝送される。しかし、(前述の方法と同様に)S−CSCFが(またはある移動管理エージェントを介して)、移動局が移動していることを認識し、新たなP−CSCFのIPアドレスを元のP−CSCFに通知するメカニズムが必要である。これはハンドオーバメカニズムによって可能である。鍵が利用可能になると、P−CSCFはSIP登録を並行して実行しながらSAを生成することが可能である。従って、SA鍵を取得するために完全なAKA手順への依存を最小化することができる。従って、アクセス制御ポリシーは、新たな訪問先ネットワークを通してMNがパケットを送信するとすぐにメディアが流れることを可能とする。前述のように、いくつかのメカニズム、例えば、IETF CXTP、SIP方式、例えば、MESSAGE、SUBSCRIBE/NOTIFY等は、この目的のために使用することが可能である。
・呼の流れ
図12は、SA鍵がS−CSCFから新たなP−CSCFに伝送される最適化されたIPSecについての呼の流れを表わす。図には、この最適化された部分の間に要求される一連のステップを表わす。
これらのメッセージ交換は、プロアクティブな、および、リアクティブなハンドオーバ時間の間に生じうる。しかし、プロアクティブなハンドオーバ技術は、リアクティブなハンドオーバより大きな範囲まで遅延を最小化することに役立ちうる。上述したように、MIPバインディング更新およびSIP初期登録のシグナリングポートが新たなPDSNにおいて常にオープンしていることが必要である。
図12において、モバイルノード(MN)がハンドオーバする先の新たなP−CSCFと、S−CSCFとを備える。S−CSCFは、モバイルノードから新たなP−CSCFのアドレスを受信し、新たなP−CSCFにセキュリティアソシエーション(SA)鍵を含むコンテキストを伝送する。新たなP−CSCFは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなPDSNにおいてモバイルノードのためのゲートをオープンする。
IPSecトンネルのオーバーヘッドは、IMS/MMDアーキテクチャにおける重要な課題である。図13は、IPSecによってエンドエンド間のセキュリティが提供され、MNノードが移動管理のために、特にアーキテクチャIIbのためにMIPv6を用いる場合に要求されるトンネルの数を表わす。実際、これはより小さい組み込み機器についての課題である。
そのようなトンネルのオーバーヘッドを軽減することは容易ではない。しかし、課題を分類し、これに対応してそれらを軽減するいくつかの方法が存在する。
・まず、IMS/MMDアーキテクチャにおいて、IM(Instant Messaging)サービスは、アクセスが許可される前に、移動局とIMSとの間に新たなセキュリティアソシエーションを要求する。従って、MNとP−CSCFとの間のSIPメッセージを保護しないので、MNとP−CSCFとの間の接続を緩和することはできない。IPSecトンネルを無効にすることは可能であるが、(1)相互運用性および標準に非準拠、(2)登録されていないユーザがネットワークリソースを乱用する穴を空ける、等の他の影響を有する。一方、3GPP IMSは、シグナリングを安全にするために、TLSのような代わりのメカニズムを提供することによってそのような制約を緩和することを最近検討している。TLSはIMS/MMD標準として受け入れられ、従って、そのようなトンネルのオーバーヘッドの課題を軽減することに役立ちうると考えられる。従って、トンネルのオーバーヘッドが課題である、より小型の機器についてMNとP−CSCFとの間のシグナリングを保護するためにIPSecの代わりとしてTLSの検討を推奨する。
・次に、MIPv6について、プロトコル動作はMNとHAとの間の最小値においてIP−IPトンネルを確立することを要求し、それによって、トロンボーンルーティングとしても知られるルーティングのループを生成する。PDSNが(MIPv4におけるFAのような)プロキシMIPv6クライアントとして動作するならば、MNからのこのトンネルは軽減することが可能であり、MNに代わってHAとのトンネルを生成する。しかし、PDSNがMNと同じレイヤ2リンクに存在することを要求するので、全ての場合において実現可能とは限らず、相互運用性の問題を有する非標準の解決策である。他の代替は、シームレスな移動性をサポートするために他の移動メカニズム(例えば、SIP)を用いることである。
・一方、エンドエンド間のセキュリティについて、メディアのセキュリティを危うくすることなく、(MNとHAとの間の)IPSecトンネルを、TLS、SRTP、SMIMEのようなアプリケーションレイヤのセキュリティメカニズムと置換可能である。コンテンツのセキュリティのみが重要であるシナリオにおいて、SRTPまたはSMIMEのようなメカニズムがよりよい。そのような場合における鍵管理が課題でありうるが、現在のネットワークアーキテクチャについてこれは管理可能であるべきである(この段階において、プロバイダ間のローミングは要求されない)。また、IPSecがMNとHAとの間のコンテンツのセキュリティのために用いられるならば、IPSecの移動性は、SAがIPアドレスと対応付けられるか否かに応じてもう1つの課題である。
IMSセキュリティアーキテクチャを表わす図である。 IMS AKAのメッセージの流れを表わす図である。 トランスポートモードにおけるESPを表わす図である。 ユーザデータのセキュリティを表わす図である。 (MIPv6の場合に)全てのP−CSCFがホームネットワークに存在する場合に要求されるトンネルを表わす図である。 (MIPv4の場合に)全てのP−CSCFがホームネットワークに存在する場合に要求されるトンネルを表わす図である。 (MIPv6の場合に)全てのP−CSCFが訪問先ネットワークに存在する場合に要求されるトンネルを表わす図である。 (MIPv4の場合に)全てのP−CSCFが訪問先ネットワークに存在する場合に要求されるトンネルを表わす図である。 (MIPv6の場合に)P−CSCFが各サブネットに存在する場合に要求されるトンネルを表わす図である。 (MIPv4の場合に)P−CSCFが各サブネットに存在する場合に要求されるトンネルを表わす図である。 最適化されたIPSecの呼の流れ(鍵はP−CSCFによって伝送される)を表わす図である。 最適化されたIPSecの呼の流れ(鍵はS−CSCFによって伝送される)を表わす図である。 (シグナリングおよびメディアのために)MNから要求されるIPSecトンネルの数を表わす図である。
符号の説明
S100,S200…IPSec最適化システム

Claims (4)

  1. IMS/MMDアーキテクチャのためのセキュリティ最適化システムであって、
    移動プロトコルとして「Mobile IP」を用いるモバイルノードがハンドオーバする前の元のP−CSCFと、新たなP−CSCFとを備え、
    元のP−CSCFは、モバイルノードから新たなP−CSCFのアドレスを受信し、新たなP−CSCFにアプリケーションレイヤのセキュリティアソシエーション鍵を含むコンテキストを伝送し、
    新たなP−CSCFは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなPDSNにおいてモバイルノードのためのゲートをオープンする、
    ことを特徴とするセキュリティ最適化システム。
  2. IMS/MMDアーキテクチャのためのセキュリティ最適化システムであって、
    移動プロトコルとして「Mobile IP」を用いるモバイルノードがハンドオーバする先の新たなP−CSCFと、S−CSCFとを備え、
    S−CSCFは、モバイルノードから新たなP−CSCFのアドレスを受信し、新たなP−CSCFにアプリケーションレイヤのセキュリティアソシエーション鍵を含むコンテキストを伝送し、
    新たなP−CSCFは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなPDSNにおいてモバイルノードのためのゲートをオープンする、
    ことを特徴とするセキュリティ最適化システム。
  3. IMS/MMDアーキテクチャのためのセキュリティ最適化方法であって、
    移動プロトコルとして「Mobile IP」を用いるモバイルノードが、ハンドオーバする前の元のP−CSCFに新たなP−CSCFのアドレスを通知するステップと、
    元のP−CSCFが、新たなP−CSCFにアプリケーションレイヤのセキュリティアソシエーション鍵を含むコンテキストを伝送するステップと、
    新たなP−CSCFが、モバイルノードのためのセキュリティアソシエーションを確立し、新たなPDSNにおいてモバイルノードのためのゲートをオープンするステップと、
    を含むことを特徴とするセキュリティ最適化方法。
  4. IMS/MMDアーキテクチャのためのセキュリティ最適化方法であって、
    移動プロトコルとして「Mobile IP」を用いるモバイルノードが、ハンドオーバする先の新たなP−CSCFのアドレスをS−CSCFに通知するステップと、
    S−CSCFが、新たなP−CSCFにアプリケーションレイヤのセキュリティアソシエーション鍵を含むコンテキストを伝送するステップと、
    新たなP−CSCFが、モバイルノードのためのセキュリティアソシエーションを確立し、新たなPDSNにおいてモバイルノードのためのゲートをオープンするステップと、
    を含むことを特徴とするセキュリティ最適化方法。
JP2007173960A 2006-09-11 2007-07-02 セキュリティ最適化システムおよびセキュリティ最適化方法 Expired - Fee Related JP4866802B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US84364106P 2006-09-11 2006-09-11
US60/843,641 2006-09-11

Publications (2)

Publication Number Publication Date
JP2008072694A JP2008072694A (ja) 2008-03-27
JP4866802B2 true JP4866802B2 (ja) 2012-02-01

Family

ID=39184336

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007173960A Expired - Fee Related JP4866802B2 (ja) 2006-09-11 2007-07-02 セキュリティ最適化システムおよびセキュリティ最適化方法

Country Status (5)

Country Link
US (1) US9025771B2 (ja)
EP (1) EP2067297A4 (ja)
JP (1) JP4866802B2 (ja)
CA (1) CA2663046C (ja)
WO (1) WO2008033434A2 (ja)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2375871T3 (es) * 2007-02-22 2012-03-07 Telefonaktiebolaget Lm Ericsson (Publ) Acceso de grupo a un servicio del subsistema multimedia ip.
JP4909864B2 (ja) * 2007-10-04 2012-04-04 Kddi株式会社 移動体通信システムにおけるハンドオフ方法、無線基地局装置及びゲートウェイ装置
JP4465015B2 (ja) 2008-06-20 2010-05-19 株式会社エヌ・ティ・ティ・ドコモ 移動通信方法
US20100135244A1 (en) * 2008-12-01 2010-06-03 Telefonaktiebolaget Lm Ericsson (Publ) REDUCTION OF HANDOVER DELAYS IN NESTED PROXY MOBILE IPv6/MOBILE IPv6 NETWORKS
GB2486126B (en) * 2009-09-21 2014-01-08 Ericsson Telefon Ab L M Caching in mobile networks
JP5537349B2 (ja) * 2010-02-11 2014-07-02 Kddi株式会社 端末の接続を継続した状態でsipサーバを変更する方法及びシステム
JP5366861B2 (ja) * 2010-03-10 2013-12-11 株式会社Kddi研究所 ゲートウェイとsipサーバとの間のセッションを移行する方法、管理装置及びプログラム
CN102223351B (zh) * 2010-04-15 2014-03-12 中兴通讯股份有限公司 一种实现单接入系统语音连续性安全的方法及系统
CN102006294B (zh) * 2010-11-25 2014-08-20 中兴通讯股份有限公司 Ims多媒体通信方法和系统、终端及ims核心网
US20120239413A1 (en) * 2011-02-16 2012-09-20 Medicity, Inc. Sending Healthcare Information Securely
FR2975252A1 (fr) * 2011-05-09 2012-11-16 France Telecom Procede de traitement d'une requete de basculement d'une communication entre deux reseaux d'acces
US9191985B2 (en) * 2011-11-09 2015-11-17 Verizon Patent And Licensing Inc. Connecting to an evolved packet data gateway
WO2016114842A1 (en) 2014-10-31 2016-07-21 Convida Wireless, Llc End-to-end service layer authentication
KR102240727B1 (ko) * 2015-01-28 2021-04-15 삼성전자주식회사 통신 시스템에서 보안 연계를 설정하기 위한 장치 및 방법
KR102001753B1 (ko) 2015-03-16 2019-10-01 콘비다 와이어리스, 엘엘씨 공개 키잉 메커니즘들을 사용한 서비스 계층에서의 종단간 인증

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7721106B2 (en) * 2002-04-26 2010-05-18 Thomson Licensing Transitive authentication authorization accounting in the interworking between access networks
GB0216000D0 (en) * 2002-07-10 2002-08-21 Nokia Corp A method for setting up a security association
US8027679B2 (en) * 2003-09-12 2011-09-27 Ntt Docomo, Inc. Secure intra- and inter-domain handover
KR100640479B1 (ko) * 2004-06-07 2006-10-30 삼성전자주식회사 이동 광대역 무선접속 시스템에서 핸드오버 절차 최적화 시스템 및 방법
US8042170B2 (en) * 2004-07-15 2011-10-18 Qualcomm Incorporated Bearer control of encrypted data flows in packet data communications
WO2006016839A1 (en) * 2004-08-13 2006-02-16 Telefonaktiebolaget Lm Ericsson (Publ) Servers and methods for handover between two serving call control servers
CN1761359B (zh) * 2004-10-12 2012-02-29 株式会社日立制作所 移动通信控制方法和移动通信控制系统
US7643451B2 (en) * 2004-10-15 2010-01-05 Nortel Networks Limited Method and apparatus for extending a mobile unit data path between access points
US8190124B2 (en) * 2004-10-22 2012-05-29 Broadcom Inc. Authentication in a roaming environment
US7551585B2 (en) 2004-12-03 2009-06-23 Telefonaktiebolaget Lm Ericsson (Publ) Seamless handoff for multimedia services
KR100602260B1 (ko) * 2005-01-05 2006-07-19 삼성전자주식회사 고속 핸드오버 방법
TWI287376B (en) * 2005-12-27 2007-09-21 Ind Tech Res Inst Method and apparatus for mobility management in wireless networks
EP1811736A1 (en) * 2006-01-18 2007-07-25 Matsushita Electric Industrial Co., Ltd. Providing service data of a bidirectional service (IMS, e.g. PoC, conference) by using a downlink multicast service (e.g. MBMS)
US7844728B2 (en) * 2007-07-31 2010-11-30 Alcatel-Lucent Usa Inc. Packet filtering/classification and/or policy control support from both visited and home networks

Also Published As

Publication number Publication date
JP2008072694A (ja) 2008-03-27
US9025771B2 (en) 2015-05-05
CA2663046C (en) 2016-03-29
EP2067297A2 (en) 2009-06-10
WO2008033434A2 (en) 2008-03-20
EP2067297A4 (en) 2011-01-19
CA2663046A1 (en) 2008-03-20
US20080072310A1 (en) 2008-03-20
WO2008033434A3 (en) 2008-06-26

Similar Documents

Publication Publication Date Title
JP4866802B2 (ja) セキュリティ最適化システムおよびセキュリティ最適化方法
Boman et al. UMTS security
EP2338264B1 (en) Optimization of handovers to untrusted non-3gpp networks
JP4284324B2 (ja) 移動無線システムにおける暗号鍵を形成および配布する方法および移動無線システム
US8031672B2 (en) System and method for providing secure mobility and internet protocol security related services to a mobile node roaming in a foreign network
EP2179563A1 (en) Bootstrapping method for setting up a security association
KR20060031813A (ko) Cdma 시스템에서 이동ip 버전 6 서비스 지원하기위한 방법, 시스템 및 장치
WO2009078615A2 (en) Integrated handover authenticating method for next generation network (ngn) with wireless access technologies and mobile ip based mobility control
US20100118774A1 (en) Method for changing radio channels, composed network and access router
Salsano et al. The UPMT solution (Universal Per-application Mobility Management using Tunnels)
Soltwisch et al. A method for authentication and key exchange for seamless inter-domain handovers
WO2009094939A1 (en) Method for protecting mobile ip route optimization signaling, the system, node, and home agent thereof
Namal et al. Securing the backhaul for mobile and multi-homed femtocells
Samoui et al. Improved IPSec tunnel establishment for 3GPP–WLAN interworking
Georgiades et al. Enhancing mobility management protocols to minimise AAA impact on handoff performance
Diab et al. VPN solution for securing voice over third generation networks
Zhang et al. An effective SIP security solution for heterogeneous mobile networks
Said et al. A Comparative Study on Security implementation in EPS/LTE and WLAN/802.11
Chiang et al. Decentralised secure handover in IMS–based networks
Ma Security investigation in 4G LTE wireless networks
Xenakis et al. A network-assisted mobile VPN for securing users data in UMTS
Banescu et al. Security of 3G and LTE
Xenakis et al. Alternative Schemes for Dynamic Secure VPN Deployment in UMTS
Manjaragi et al. Survey of Security Models in Heterogeneous Wireless Networks
Horn et al. Security for the core network of third generation mobile systems

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100201

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110527

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110614

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110912

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20111018

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20111114

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20141118

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4866802

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees