JP3831331B2 - モバイルｉｐネットワークへのアクセスを安全にする方法 - Google Patents
モバイルｉｐネットワークへのアクセスを安全にする方法 Download PDFInfo
- Publication number
- JP3831331B2 JP3831331B2 JP2002325168A JP2002325168A JP3831331B2 JP 3831331 B2 JP3831331 B2 JP 3831331B2 JP 2002325168 A JP2002325168 A JP 2002325168A JP 2002325168 A JP2002325168 A JP 2002325168A JP 3831331 B2 JP3831331 B2 JP 3831331B2
- Authority
- JP
- Japan
- Prior art keywords
- communication terminal
- management server
- agent
- registration process
- advertisement
- 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
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、モバイルノードに接続を提供するネットワークの認証の為のプロトコルに関する。本発明によるセキュリティプロトコルは、ＡＡＡフレームワークに基づいているとともに、認証メカニズムに公開鍵方式の暗号化方式を使用する。
【０００２】
【従来の技術】
パーソナルコミュニケーションデバイスへの依存が急速に進んでいるので、世界中で無線通信への需要が拡大している。無線の役割が、ほんの数年前の音声と呼び出し無線サービス以上に大きくなっている。世界的データネットワークの標準化の為に認められた機関であるインターネット協会の国際電気通信連合（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ（ＩＴＵ））は最近、国際移動体通信２０００規格（ＩＭＴ−２０００）を発表した。この規格では、いわゆる第３世代とそれ以降（すなわち第３．５世代、第４世代）のデータネットワークを提案しているが、このデータネットワークには、セルラ方式電話、携帯情報端末（ＰＤＡ）、ハンドヘルドコンピュータなどの無線式移動体端末による広範囲にわたるモバイルアクセスが含まれている。第３世代とそれ以降の世代のネットワークでは、モバイルノードは、ネットワークリソースへの接続を維持しながら、あるネットワークから他のネットワークへとネットワークへの接続点を変更しながら移動することができる。このために、このようなデータネットワークは、ローミングしているモバイルノードをアドレス指定するモビリティサポートと、ネットワークを越えてローミングをしているモバイルノードにデータパケットをダイナミックに再ルーティングすることと、一番重要なのだが、そのようなローミングしているモバイルノードとモバイルノードが訪れたネットワークの間の認証とを提供するように設計されていなければならない。
【０００３】
インターネットアーキテクチャの発展とインターネットのスムーズな運営に関心を有している、ネットワーク設計者、事業者、ベンダー、さらに研究者の国際的なコミュニティである、インターネット技術標準化委員会（ＩＥＴＦ：ＴｈｅＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｎｅｒｉｎｇ Ｔａｓｋ ｆｏｒｃｅ）は、モビリティへの対応に関するいくつかの基準を提案した。これらには、モバイルＩＰバージョン４（ＩＰｖ４）とも呼ばれているＩＥＴＦによるＲＦＣ２００２や、モバイルＩＰバージョン６と呼ばれている「ＩＰｖ６におけるモビリティサポート」と言う題の文書「ドラフト−ｉｅｔｆ−モバイルＩＰｖ６−１３：ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｉｐｖ６−１３」などのＩＰモビリティサポートの為に提案中標準が含まれている。両文書は、参照として本明細書に組み込む。
【０００４】
モバイルＩＰｖ４とＩＰｖ６で決められたプロトコル処理によれば、モバイルノードは、ネットワークリソースへの接続を保ちながら、あるネットワークから他のネットワークに接続ポイントを変更しながら移動することができる。この処理は、「レイヤ３（Ｌ３）ハンドオフ」と呼ばれ、レイヤ２（Ｌ２）ハンドオフとは区別されるべきである。ここでレイヤ２ハンドオフとは、モバイルノードが同一のネットワーク内で、リンク層の接続をあるアクセスポイントから他のアクセスポイントに変更することを言う。Ｌ３ハンドオフでは必ずＬ２ハンドオフが伴うが、逆は必ずしもそうでない。モバイルＩＰｖ４とＩＰｖ６は、Ｌ３ハンドオフの処理に使用されるメカニズムを提供している。モバイルＩＰｖ４とＩＰｖ６両方において、ハンドオフ処理はモバイルノードがハンドオフされる次のエージェントやルータを探す処理から始まる。モバイルＩＰｖ４において、この処理は、「エージェントディスカバリ」と呼ばれ、接続を提供するモビリティエージェントをモバイルノードが探す処理である。
【０００５】
モビリティエージェントは定期的に自分自身の存在を示す広告（ａｄｖｅｒｔｉｓｅ）をしている。モバイルノードは、近くのモビリティエージェントからの広告メッセージを受信して、自分自身が接続しているエージェントや自分自身がハンドオフされうるエージェント候補を見つけることができる。モバイルノードは、エージェントソリシテーションを送信することで、近くのエージェントにエージェント広告（Ａｄｖｅｒｔｉｓｅｍｅｎｔ）を要求しても良い。モバイルＩＰｖ６では、同じ処理が「近隣ディスカバリー：Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ」と呼ばれている。近隣ディスカバリーでは、ルータがルータ広告（Ａｄｖｅｒｔｉｓｅｍｅｎｔ）を使って接続を提供している。モバイルノードは、ルータソリシテーションを送信することで、近くのルータにルータ広告（Ａｄｖｅｒｔｉｓｅｍｅｎｔ）を要求しても良い。
【０００６】
Ｌ３ハンドオフの処理で一番重要なのは登録である。モバイルノードは常に、「ホームアドレス」によりそのアドレスを指定することができる。このホームアドレスとは、ホームリンク上のホームエージェントによってモバイルノードに割り当てられたＩＰアドレスか、またはモバイルノード自身で決めたＩＰアドレスである。ホームリンクから離れたフォーリンリンク上にモバイルノードがある時は、モバイルノードは、モバイルノードがその時点でインターネットに接続しているポイントを示す気付アドレスによって、アドレス設定されている。モバイルＩＰｖ４では、気付アドレスはフォーリンエージェントのアドレスであり、ホームから離れたところにあるモバイルノードは、気付アドレスをホームエージェントに登録する。登録要求を受けたホームエージェントは、モバイルノード宛のパケットを調べて、そのパケットをモバイルノードの気付アドレス宛に転送する。モバイルＩＰｖ６では、ホームから離れたモバイルノードは、ホームルータと通信相手ノードとにバインディング更新要求を送る。バインディング更新要求を受けた通信相手ノードは、ホームルータを通すルートでなく、モバイルノードに直接パケットを送信する。
【０００７】
【非特許文献】
シー・パーキンス（Ｃ．Ｐｅｒｋｉｎｓ）編、「ＲＦＣ２００２」、インターネット技術標準化委員会（ＩＥＴＦ：Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｎｅｒｉｎｇ Ｔａｓｋ ｆｏｒｃｅ）、１９９６年１０月
【０００８】
【発明が解決しようとする課題】
ここで、モバイルノードが、第１のネットワークから第２のネットワークへとハンドオフしようとする時に、重大なセキュリティの問題が出てくる。つまり、第２のネットワークは、モバイルノードに対して安全であると認証されなければならないのである。これによりモバイルノードが悪意のある環境で動作することのないようにしなければならない。例えば、モバイルノードがあるネットワークから他のネットワークに移動する時に、連続した良好なサービスをユーザに提供する為に、素早いハンドオフが必要である。しかし、問題のあるフォーリンエージェントやルータがあって、問題のある広告メッセージを送信することで、モバイルノードが素早いハンドオフを行うのを妨げようとしていると言われている。問題のある広告メッセージとして、モバイルノードをだますための誤った情報を入れたものがあり、これにより、モバイルノードは、その広告を出しているフォーリンエージェントを他のエージェントよりも接続すべき相手だ（実際はそうではないのだが）と誤って判断してしまう。悪意のあるエージェントやルータに登録するように誘い込まれたモバイルノードは、何度も登録を試みようとしても登録できないという結果になるだろう。もしモバイルノードが、そのようなフォーリンエージェントやルータに登録できても、モバイルノードは貧弱な接続性やサービスを受けることになるであろう。
【０００９】
現在、多くの認証方法が実施され、様々なアクセス技術のために導入されている。これには、例えばＰＰＰと８０２．１ネットワーク（無線ＬＡＮ）の認証がある。しかし、これらはリンク層の方法であり、特定のアクセス技術にしか適用できないので、万能な解決方法ではない。この点で、ネットワーク層の解決法が好ましいのは明らかである。ネットワーク層の解決法は、その下のリンク層でどんなアクセス技術が使われていようが有効であろう。ＩＰｓｅｃ認証サービスはＬ３の方法であるが、Ｌ３ハンドオフの場合は、ネットワークとモバイルノードがお互いに認証するための、実行可能な解決法にはなりえない。ＩＰｓｅｃ認証は、２つの要素間で前もって存在するセキュリティアソシエーションを前提にしている。あるフォーリンエージェントやルータが、広告を受信した各モバイルノードとセキュリティアソシエーションをするだろうと仮定することは出来ないし、あるいは、モバイルノードが、広告を送信している近くのフォーリンエージェントやルータ全てとセキュリティアソシエーションをするだろうと仮定することも出来ない。
【００１０】
【課題を解決するための手段】
本発明において、接続を提供するモビリティエージェントは、モバイルノードが認証できる形式で広告メッセージを送信する。本発明によれば、ネットワークは管理ドメインを有していて、この管理ドメインの各々は、管理サーバと最低１つのモビリティエージェントを有している。モビリティエージェントは、信頼されたエンティティが認証した広告メッセージを用いて接続を提供し、これにより、モバイルノードがメッセージの正当性を確かめることができる。
【００１１】
信頼されたエンティティは、広告を送信しているモビリティエージェントが属するドメインにサービスを提供している管理サーバでも良い。広告メッセージは、広告を送信しているモビリティエージェントのプライベートキーによって署名されていて、証明書（広告を送信しているモビリティエージェントの公開鍵を含んでいて、信頼された管理サーバのプライベートキーによって署名されている）を同封していても良い。このように、モバイルノードが信頼された管理サーバの公開鍵を持っていれば、モバイルノードは、メッセージの正当性を確かめることができる。
【００１２】
モバイルノードが広告メッセージを受信し、その広告の認証に成功したら、モバイルノードは、認証した広告から１つを選択し、選択した広告を送信したモビリティエージェントに登録する。モビリティエージェントの選択は、広告を送信しているモビリティエージェントの接続性による。
【００１３】
モバイルノードが、広告を送信しているモビリティエージェントのどれも認証できない場合でも、モバイルノードは、広告を送信しているモビリティエージェントから１つを選択し、その選択された１つに登録を進める。この登録プロセスを通して、モバイルノードは、信頼された管理サーバの公開鍵を取得する。信頼された管理サーバの公開鍵は、モバイルノードの認証に責任を有するホーム管理サーバによって認証される。モバイルノードが信頼するホーム管理サーバによって認証されたので、信頼された管理サーバの公開鍵の正しさも、モバイルノードは信頼することができる。
【００１４】
本発明は、受信した広告メッセージのどれもモバイルノードが認証できない場合に、１つのモビリティエージェントを選択する独特な方法を提供する。モバイルノードは、始め、ある期間内に受信した広告メッセージをグループに並べ替える。この並び替えは、メッセージ内に含まれているパラメータの一貫性の順にしても良い。モバイルノードは、次に、広告メッセージのグループのうち１つを選択する、そしてその選択したグループから１つの広告メッセージを選択する。このプロセスの間、パラメータの一貫性が高い順に、グループの選択を行っても良い。そして、広告メッセージの選択は、メッセージを送信しているモビリティエージェントへの接続性に基づいて行われる。そして、モバイルノードは、選択されたメッセージを送信しているモビリティエージェントに登録する。選択された広告を送信しているモビリティエージェントへの登録が失敗した場合、モバイルノードは、選択したグループの広告を全て廃棄し、次に高い一貫性を有する他のグループを選択する。モバイルノードは、モビリティエージェントに登録できるまで、このプロセスを繰り返す。
【００１５】
【発明の実施の形態】
以下に図面を参照しながら、本発明による好適な実施形態を説明する。ここで同一の要素は同一の符号で表される。ここでの実施例の記載は、例示を意図したものであり、発明の範囲を限定するものではない。
【００１６】
図１は、本発明の用途として意図している第３世代無線モバイルアクセスＩＰネットワーク１００を例示している図である。説明上、データネットワーク１００は、無線モバイルアクセスネットワークの為のＩＴＵのＩＭＴ−２０００基準と仕様に準拠していると仮定する。更に、データネットワーク１００は、ＩＥＴＦの提案されたモバイルＩＰｖ４とＩＰｖ６に拠ったモバイルＩＰサポートを実装していると仮定する。無線モバイルアクセスＩＰネットワーク１００は、固定接続点またはリンクなどの多くの固定ノード（図示せず）を有するＩＰデータネットワーク１２０をそのコアとして有している。
【００１７】
インターネットのプロトコルに従って、デジタルデータはネットワーク内やネットワークを越えて伝送される。コアネットワーク１２０上には、ゲートルータ１３０の集合がある。このゲートルータ１３０の集合は、ＩＰモバイルバックボーン１４０を形成し、インターネット標準のアドレス・ルーティングプロトコルに従って、このネットワークに接続している出所元ノードと宛先ノードの間でのデータパケット伝送をする。ＩＰモバイルバックボーン１４０を形成しているゲートルータ１３０は、それ自身がコアネットワーク１２０のノードであり、コアネットワーク１２０を超えて通信をするために、他と重複しないＩＰアドレスを有している。
【００１８】
ゲートルータ１３０の各々にはサーバ１４５が接続されている。このサーバ１４５も他と重複しないＩＰアドレスを有していて、ホームエージェント（ＨＡ）やフォーリンエージェント（ＦＡ）として機能することができ、モバイルＩＰｖ４で規定されているように、モバイルノード１３５のコアネットワーク１２０へのインターフェースとして働き結びつける。モバイルＩＰｖ６では、これらのサーバ１４５は、モバイルノード１３５にＩＰ接続を提供するホームルータやフォーリンルータとして働く。ネットワーク１２０には、モバイルＩＰｖ４かモバイルＩＰｖ６かのどちらかを実装するネットワークがあっても良い。よって、本出願の全般にわたり、「エージェント」と言う語は、「アクセスルータ」または「ルータ」と言う語と交換して使われうる。同じように、「エージェントディスカバリ」は「近隣ディスカバリ」と、「エージェントソリシテーション」は「ルータソリシテーション」と、「登録要求」は「バインディング更新要求」と、交換して使われうる。
【００１９】
モバイルノードは、セル式ハンドセット、セル式電話、ハンドヘルドコンピュータ、パーソナル情報機器、無線データターミナルのような通信端末であり、無線を使用していても良い。モバイルノード１３５の各々にはホームサブネットワークが割り当てられている。各モバイルノードはホームエージェントルータを有していて、このホームエージェントルータは、実際はホームサブネットワークのセンタサーバである。各モバイルノード１３５にとっては、ホームエージェントがネットワーク１２０への元々の接続点であり、各モバイルノードは、ホームサブネットワークにおいて、ホームエージェントから割り当てられたホームアドレスかモバイルノード自身で選んだホームアドレスにより、アドレス指定される。他のエージェント１４５はフォーリンエージェントかルータとして機能することができる。モバイルノード１３５がフォーリンエージェントのサブネットワークに入って来た時は、フォーリンエージェント１４５はモバイルノード１３５にネットワークアクセスを提供しても良い。モバイルノードがホームから離れてフォーリンサブネットワーク上にある時は、モバイルノードは、気付アドレスによってアドレス設定されている。この気付アドレスは、そのモバイルノードがいるフォーリンサブネットワークのアドレスであり、モバイルノードがその時点でインターネットに接続しているポイントを示している。モバイルノード１３５がホームサブネットワークから離れて稼動している時、モバイルノードのホームエージェント１４５は、登録プロセスを通してモバイルノード１３５の現在地情報を保持している。
【００２０】
各エージェント１４５は基地局ネットワーク１５０を有している。この基地局ネットワーク１５０を通して、モバイルノード１３５はエージェントやルータ１４５と通信を行う。基地局ネットワーク１５０の各々には複数の基地局すなわちアクセスポイント（ＡＰ）１５５がある。モバイルノード１３５とＡＰはＣＤＭＡやＷ−ＣＤＭＡまたは他の公知のデジタルデータ通信技術を使用して、お互いに通信を行う。ＡＰネットワーク１５０やＡＰ１５５の構成と設備と機能とは従来のものであり標準のものである。同様に、無線モバイルノード機器１３５とＡＰ１５５が使用するＣＤＭＡやＷ−ＣＤＭＡまたは他のデジタルデータ通信技術は標準のものである。本発明の理解には、これらの詳細な説明は必要ないので、省略する。
【００２１】
データネットワーク１００全体の中で、２種類のモビリティハンドオフが考慮されている。レイヤ２（Ｌ２）ハンドオフとはモバイルノードが同一のＡＰネットワーク１５０内で位置を変更することを言い、モバイルノードのネットワークリンクは変わらず、モバイルノードの接続点が、あるＡＰ１５５から他のＡＰ１５５に変わる。Ｌ２ハンドオフは無線セル方式通信ネットワークにおいてよく知られている。例えば、モバイルノード１３５がＡＰネットワーク１５０内を移動する間のＡＰ間の通信ハンドオフを見つけたり処理したりする為に、レイヤ２信号やビーコンシグナルをモニターすることは良く知られている。レイヤ３（Ｌ３）ハンドオフは、あるサブネットワークから他のサブネットワークへ接続点を変更することを言う。言い換えれば、モバイルノードは、あるサブネットワークを離れ、他のエージェント１４５配下の他のサブネットワークへと入る。Ｌ３ハンドオフにおいて、モバイルノードは、サブネットサーバ間でネットワークへの接続点を変更する時期を知るために、近くのエージェントからの信号をモニターしている。
【００２２】
図２は、第３世代無線モバイルアクセスデータネットワークにおけるモバイルノードのＬ３ハンドオフを簡単に示した図である。図２において、ネットワーク１００は、コアネットワーク１２０と、コアネットワーク１２０に接続されたエージェント１４５とを有している。エージェント１４５にはホームエージェントＨＡとフォーリンエージェントＦＡ１、ＦＡ２、ＦＡ３とが含まれる。モバイルノード（ＭＮ）１３５にとって、ホームエージェントＨＡがネットワーク１２０への元々の接続点である。フォーリンエージェントＦＡ１、ＦＡ２、ＦＡ３は、モバイルノードＭＮ１３５が各々のサブネットワークに入って来た時に、ＭＮ１３５に各々のネットワークアクセスポイントを提供しても良い。図２に示される例において、ＭＮ１３５は元々開始位置Ａにいて中間位置Ｂを経由して位置Ｃに移動する。開始位置Ａにおいて、ＭＮ１３５はＦＡ１配下のフォーリンサブネットワークで動作していて、ＦＡ１を経由してネットワーク１２０に接続している。一方、位置ＣはＦＡ２配下のフォーリンサブネットワーク内に位置ある。このとき、ＭＮ１３５がＦＡ１配下のサブネットワークを横切って、ＦＡ２配下のサブネットワークに入ると、Ｌ３ハンドオフがＭＮ１３５に発生して、ＭＮ１３５はネットワーク接続をＦＡ１経由からＦＡ２経由へと変更する。
【００２３】
ＭＮ１３５の移動はディスカバリメカニズムにより検出される。このメカニズムは、モバイルＩＰｖ４でのエージェントディスカバリかモバイルＩＰｖ６の近隣ディスカバリでも良い。ディスカバリメカニズムに従って、ＦＡ１、ＦＡ２、ＦＡ３は、モバイルＩＰｖ４の場合はエージェント広告で、モバイルＩＰｖ６の場合はルータ広告を用いて、定期的に存在を広告する。ＭＮ１３５は、モバイルＩＰｖ４の場合エージェントソリシテーションを、モバイルＩＰｖ６の場合ルータソリシテーションを送信することで、これらの広告メッセージをフォーリンエージェント１４５に要求しても良い。ＭＮ１３５は受信部を使用して、これらの広告を受信すれば、ＭＮ１３５は現在どのサブネットワーク内にいるか決定できる。開始位置Ａにおいて、ＭＮ１３５はエージェント広告をＦＡ１だけから受信するが、このエージェント広告は、ＦＡ１配下のフォーリンサブネットワーク上にＭＮ１３５がいると伝えている。ＭＮ１３５が中間位置Ｂに到達し、位置Ｃへと移動するにつれて、ＦＡ２からの広告がＭＮ１３５に着きはじめる。従って、ＭＮ１３５は、自身がＦＡ１のサブネットワークを離れ、ＦＡ２配下のサブネットワークに入りつつあるとわかる。
【００２４】
ＭＮ１３５が中間位置Ｂを通った後に、Ｌ２ハンドオフが発生する時がきて、ＭＮ１３５は、ＦＡ１によるサブネットワーク内のＡＰ１５５のうちの１つから、ＦＡ２によるサブネットワーク内のＡＰ１５５のうちの１つへと、Ｌ２接続を変更する。Ｌ２ハンドオフが終了した後、ＦＡ２からの広告メッセージのみがＭＮ１３５に届く。ＭＮ１３５に届く広告メッセージに基いて、ＭＮ１３５はＦＡ２配下のサブネットワーク内で動作しているのだとわかる。ＭＮ１３５は次に、ＦＡ２を通してＨＡに登録要求またはバインディング更新を送ることで、登録プロセスを始める。登録要求またはバインディング更新には、気付アドレスが含まれている。この気付アドレスは、ＭＮ１３５がＦＡ２からの広告メッセージから得たＦＡ２のサブネットワークのアドレスである。ＨＡにおいて、ＭＮ１３５の身元が証明されたら、ＨＡはＭＮ１３５の気付アドレスを記憶し、ＦＡ２に返事を出す。ＦＡ２はこの返事を処理して、ＭＮ１３５に送る。この返事は、ＭＮ１３５が本物であるとＦＡ２に証明し、ＭＮ１３５とＦＡ２の間の接続確立に許可を与える。この登録プロセスの後、ＭＮ１３５はＦＡ１からＦＡ２へのＬ３ハンドオフを終える。
【００２５】
モバイルデータ通信の人気が上がるにつれ、モバイルノードを誘導し登録をさせようとする好ましくないモビリティエージェントが増えてくる。しかし、これらのエージェントは、実際のところは、質の低い接続性やサービスを提供し、モバイルノードが素早いハンドオフを行うのを邪魔しているだけである。これらの好ましくないモビリティエージェントが増えるにつれ、モバイルＩＰ登録プロセスがこれらの好ましくないエージェントで始まる前に、このような悪意のあるエージェントを特定しようとする必要性が出てきた。本発明によれば、モビリティエージェントを認証するためのセキュリティプロトコルを提供され、モバイルノードは、このような悪意のあるエージェントを特定できるようになり、それらにハンドオフするよう誘導されないようになる。
【００２６】
本発明のセキュリティメカニズムは、ＡＡＡプロトコルに基づいている。ＲＡＤＩＵＳやＤＩＡＭＥＴＥＲのようなＡＡＡプロトコルは、現在インターネットにおいて使用されていて、認証、許可、アカウンティングサービスをダイアルアップユーザに提供している。このようなＡＡＡ管理サービス、特にＡＡＡサーバによって提供されている認証サービスは、モバイルＩＰを使用したモバイルノードにとって重要である。モバイルＩＰとは、モバイルノードがあるネットワークから他のネットワークに移動できるようにしている技術である。ＡＡＡプロトコルでは、ある共通の管理のもとで動作している１つまたは複数のネットワークからなる管理ドメインを定義している。この様に、ＡＡＡ管理ドメインの定義のされ方によって、モバイルノードの移動が、あるネットワークから同じ管理ドメイン内のネットワークへのものになったり、異なった管理ドメインのネットワークへのものになったりする。
【００２７】
しかし、モバイルノードのモバイルＩＰの移動をＡＡＡ管理ドメインにマッピングすることで、モバイルＩＰを実装しているモバイルノードにとって、ＡＡＡ管理サービスが利用可能になる。実際、モバイルＩＰはＡＡＡインフラストラクチャ上に、基礎的フレームワークにほとんど変更を加えずに実装できる。例えば、ＡＡＡプロトコルのクライアントは、モバイルＩＰのモバイルノードであるとみなされる。モバイルＩＰのモビリティエージェントは、ＡＡＡプロトコルのアテンダントにぴったり当てはまる。ＡＡＡメッセージを理解できる様に、モバイルノード、モビリティエージェントやルータのようなモバイルエンティティの機能を増やすことで、ＡＡＡインフラストラクチャ上にモバイルＩＰを実装することが可能となる。
【００２８】
普通、ＡＡＡ認証メカニズムは次のように働く。まず、第１のＡＡＡエンティティが通信相手としたい第２のエンティティに証明書を送る、そして第２のエンティティが第１のエンティティの証明書を正しいと確認したら、通信が認められる。ＡＡＡサーバは鍵配布センタとして働き、ＡＡＡエンティティの要求により、２つのＡＡＡエンティティ間の証明書の正しさを証明するのに使われる鍵を生成し配布する。ＡＡＡプロトコルは、他の鍵アルゴリズムと一緒に動くように設計されている。鍵アルゴリズムの中には、公開鍵インフラストラクチャがあることを前提にしているものもあり、また他方には共通鍵の配布によっているものもある。本発明の説明では、公開鍵インフラストラクチャを採用しているネットワークを使う。しかしながら、当業者は本発明の実装には他の鍵アルゴリズムでも良いと理解するであろう。
【００２９】
本発明の登録プロセスを、図３を参照してさらに説明する。図３は、ＡＡＡプロトコルに基づいた本発明による第３世代とそれ以降の無線モバイルアクセスデータネットワークを簡単に示した図である。このネットワーク内で、本発明による登録プロセスが実施される。図２に示すネットワークと同様に、図３のネットワークはモバイルＩＰｖ４かＩＰｖ６を実装している。本実施形態のネットワークは、ＡＡＡプロトコルを使用していて、それゆえに複数の管理サーバを有している。これら管理サーバはそれぞれ管理ドメインを作っている。ＡＡＡプロトコルに応じて、各管理サーバは、モバイルノードへのサービスのために、認証をし、許可をし、そしてアカウンティング情報を集める。
【００３０】
簡略化の為に、図３には３つの管理サーバＡＡＡ＿ＨＡ、ＡＡＡ＿ＦＡ１、ＡＡＡ＿ＦＡ２、のみが示されている。サーバＡＡＡ＿ＨＡは、ホーム管理サーバであり、モバイルノードＭＮの認証をになっている。多くの場合、サーバＡＡＡ＿ＨＡによる管理ドメインからモバイルノードが発呼し、そしてホーム管理ドメインはホームエージェントＨＡとＨＡによるサブネットワークを含む。言い換えると、多くの場合、ＭＮへの認証サービスと登録サービスは同一のドメインで行われる。しかしながら、認証サービスと登録サービスは同一のドメインで行われなくてもよいことに注意すべきである。すなわち、ホームエージェントＨＡは、ホームドメインとは違う管理ドメイン内にあっても良い。このような状況は次のようなばあいに起こる。つまり、ＭＮが、ある管理ドメイン内にあるＩＳＰに登録されていて、クレジットカード会社が他のドメインでＭＮの認証を行う場合である。サーバＡＡＡ＿ＦＡ１はフォーリン管理サーバであり、フォーリンエージェントＦＡ１とＦＡ２によるサブネットワークを含む管理ドメインを作っている。言い換えると、フォーリンエージェントＦＡ１とＦＡ２は共通の管理下にある。サーバＡＡＡ＿ＦＡ２もフォーリン管理サーバであり、フォーリンエージェントＦＡ３によるサブネットワークを含む管理ドメインを作っている。
【００３１】
図３に示すネットワークにはセキュリティモデルが内在する。図４は、そのような内在するセキュリティモデルを示していて、点線でエンティティ間のセキュリティアソシエーション（ＳＡ）を示している。第１に、ＨＡ、ＦＡ１、ＦＡ２、ＦＡ３はそれぞれ、それらの管理サーバとセキュリティアソシエーションを確立していると仮定する。各エージェントは、過去に、管理ドメイン内にいたときから、管理サーバと通信を行ったはずである。この様に、ＨＡとＡＡＡ＿ＨＡは、すでに確立しているセキュリティアソシエーションを有している。ＦＡ１とＦＡ２は、ＡＡＡ＿ＦＡ１との間ですでに確立しているセキュリティアソシエーションを有している。ＦＡ３は、ＡＡＡ＿ＦＡ２との間ですでに確立しているセキュリティアソシエーションを有している。第２に、ＭＮは、ＡＡＡ＿ＨＡとのセキュリティアソシエーションを前もって有している。これは、そうでなかったら、ＭＮの認証をＡＡＡ＿ＨＡが行えないからである。なお、ＡＡＡ＿ＨＡがＭＮの認証の責任を有している。第３に、登録プロセスの性質から、ＭＮは、自らが登録しようとしているフォーリンエージェントと、セキュリティアソシエーションを有していることはありえない。最後に、管理サーバＡＡＡ＿ＨＡ、ＡＡＡ＿ＦＡ１、ＡＡＡ＿ＦＡ２間で前もって確立されたセキュリティアソシエーションは必要ない。しかし必要な場合は、管理サーバ同士でのセキュリティアソシエーションを交渉することができなければならない。セキュリティアソシエーションは、仲介ＡＡＡサーバを使用して、もしくは、静的事前手配済みセキュリティアソシエーションを共有する事で、２つのサーバ間で確立しても良い。
【００３２】
本発明においては、エージェントＨＡ、ＦＡ１、ＦＡ２、ＦＡ３から送信されたエージェント広告メッセージは、正しいものであるとＭＮに証明することができる。エージェント広告メッセージの認証は、公開鍵暗号法を使用して、デジタル署名−デジタル証明書を用いて実行される。モバイルＩＰでは、エージェント広告を、モビリティエージェント拡張をした修正ＩＣＭＰルータ広告として定義している（図５参照）。広告には付随している拡張部がある。図３に示された例では、ＨＡ、ＦＡ１、ＦＡ２、ＦＡ３は、ＭＮが証明を行うことができる特別な形式でエージェント広告を送信している。さらに詳しくは、各エージェントメッセージは、送信側エージェントのプライベートキーでデジタル署名されて、デジタル証明書と付加される。このデジタル証明書は、送信側エージェントの管理サーバがそのサーバのプライベートキーで署名したものであり、送信側エージェントの公開鍵を含んでいる。この特別なエージェント広告は、「認証されたエージェント広告（ＡＳＰ）」と呼ばれ、次のように表される。
ＡＳＰ＝ＳＰ‖ｓｉｇSK-FA（ＳＰ）‖ｃｅｒｔAAA_FA（ＦＡ）
ここで、ｓｉｇSK-FA（ＳＰ）は、フォーリンエージェントＦＡのプライベートキー（ＳＫ−ＦＡ）で署名されている、フォーリンエージェントＦＡから来たエージェント広告メッセージ（ＳＰ）である。そして、ｃｅｒｔAAA_FA（ＦＡ）は、ＦＡの証明書であり、ＦＡの管理サーバＡＡＡ＿ＦＡのプライベートキーで署名されていて、ＦＡの公開鍵を含んでいる。
【００３３】
ＡＳＰを受信したＭＮがＦＡの管理サーバＡＡＡ＿ＦＡの公開鍵を持っていれば、ＭＮは付加されてきた証明書を復号化して、その中からＦＡの公開鍵を取り出す。ＦＡの公開鍵を使用して、ＭＮはエージェント広告メッセージを復号化することができる。この様に、ＦＡの管理サーバの公開鍵によって、エージェント広告メッセージが信頼でき完全なものであると、ＭＮは確かめることができ、また、メッセージを送ってきたフォーリンエージェントＦＡの身元が正しい物と確かめる事ができる。一方、ＭＮがＦＡの管理サーバＡＡＡ＿ＦＡの公開鍵を持っていなければ、ＭＮは広告メッセージの信頼性と完全性、さらにメッセージを送ってくるＦＡの身元に関して警戒しなければならない。そして、ＭＮは、近隣に確かな広告メッセージを送ってくる他のＦＡが利用可能であれば、そのＦＡに登録するのを避けるべきである。
図６は、本発明の実施例による認証プロセスを示すフローチャートである。
【００３４】
（ステップ６１）
ステップ６１において、ＭＮは近隣のエージェントからエージェント広告を受信する。図３で、ＭＮは始め開始位置Ａにいて、目的地Ｃへと移動していく。位置Ａでは、ＭＮはＦＡ１に登録している。よって、ＭＮがＦＡ１からの広告メッセージを復号化しＦＡ１に登録するのに必要であるＡＡＡ＿ＦＡ１の公開鍵を、ＭＮは有していると想定される。図３に示されるように、ＭＮは、位置Ａから移動し始め、位置Ｃに向かって、ＦＡ１によるサブネットワークを横切る。位置Ａと位置Ｃの間で、Ｌ２ハンドオフが起こり、ＭＮはＦＡ１との接続を失う。位置Ｃでは、ＦＡ２とＦＡ３によるサブネットワークが重なり合っている。言い換えると、これら２つのエージェントからのエージェント広告が位置Ｃに届く。本実施形態のＭＮはマルチリンク可能であると仮定されていて、ＭＮは位置Ｃに着いた時、ＭＮはＦＡ２とＦＡ３の両方からのエージェント広告を受信することができる。ＭＮは、レイヤ３に関して、シングルリンク可能であっても良いし、マルチリンク可能であっても良い。シングルリンク可能なＭＮは、１つのサブネットワーク内の１または複数のエージェントから１または複数のエージェント広告を受信することができる。このようなＭＮが、複数のサブネットワークが重なり合っている地点にいる場合、ＭＮは、この複数のサブネットワークのうちの１つのサブネットワーク内に位置する１または複数のエージェントから１または複数のエージェント広告を受信することができる。サブネットワークの選択は、ＭＮのレイヤ２で発生する。一方、マルチリンク可能なＭＮは、重なりあっている全てのサブネットワーク内のエージェントからエージェント広告を受信することが出来る。このようなＭＮは、そのレイヤ２内で行われた選択に基づいて、複数のサブネットワークの１つ内に位置するエージェントに接続することになる。
【００３５】
ＭＮが位置Ｃに着くと、ＭＮは、ＦＡ１によるサブネットワークを離れたことを知り、さらにＦＡ２とＦＡ３による２つのサブネットワークへ接続可能な地域に入ったことを知る。ＭＮは、ＦＡ２とＦＡ３のどちらに登録するかを決めなければならない。ＦＡ２は定期的に、自身の認証されているエージェント広告（ＡＳＰFA2）を送信しているが、このエージェント広告は次の様に示される。
ＡＳＰFA2＝ＳＰ‖ｓｉｇSK-FA2（ＳＰ）‖ｃｅｒｔAAA_FA1（ＦＡ１）
既に述べた様に、ＡＳＰFA2を復号化するために、ＭＮはＡＡＡ＿ＦＡ１の公開鍵が必要である。同様に、ＦＡ３は、自身の認証されているエージェント広告を定期的に送信している。このエージェント広告は次の様に示される。
ＡＳＰFA3＝ＳＰ‖ｓｉｇSK-FA3（ＳＰ）‖ｃｅｒｔAAA_FA2（ＦＡ２）
ＡＳＰFA3を復号化するために、ＭＮはＡＡＡ＿ＦＡ２の公開鍵が必要である。
【００３６】
（ステップ６２）
ステップ６２で、ＭＮは受信したエージェント広告の認証を試みる。ＭＮがＡＳＰFA2とＡＳＰFA3を受信すると、ＭＮは内部キャッシュを、ＡＡＡ＿ＦＡ１またはＡＡＡ＿ＦＡ２、もしくは両方の公開鍵があるかどうかを調べる。上で仮定したように、ＭＮは同じ管理ドメイン内に位置するＦＡ１に前に登録しているので、ＭＮはＡＡＡ＿ＦＡ１の公開鍵を持っている。ＡＡＡ＿ＦＡ１の公開鍵を使用して、ＭＮはＡＳＰFA2を認証する事ができる。ＡＳＰFA2を認証は２段階のプロセスである。最初に、ＭＮは、ＡＳＰFA2を送信しているＦＡ２を認証する。ＭＮはＦＡ２の証明書をＡＳＰFA2の証明書拡張部から取り出し、ＡＡＡ＿ＦＡ１の公開鍵を使ってこの証明書が正しい物であるか確認する。ＭＮが証明書を正しい物と確認したら、ＭＮが信頼しているＡＡＡ＿ＦＡ１によってＦＡ２がＭＮに認証されたので、ＭＮはＦＡ２を信頼する。第２に、ＡＳＰFA2が正しい物であるかを認証する。証明書が正しいと確認するとすぐに、ＭＮは、証明書から得たＦＡ２の公開鍵を使い、署名拡張部のデジタル署名が正しいものであるかを確かめる。ＭＮがデジタル署名を正しい物と確認したら、ＦＡ２によって広告の正しさがＭＮに保証されたので、ＭＮは受信した広告ＡＳＰFA2を信頼する。
【００３７】
（ステップ６３）
ステップ６３で、ＭＮは登録するエージェントを１つ選択する。基本的に、エージェントの選択はポリシー決定である。この様に、エージェントの選択は、ＭＮがある特定のエージェントの認証に成功したかどうかを考慮するだけでによるべきではなく、他の複数の要素（例えば、エージェントからの信号の強度や信号対雑音比）によってなされるべきである。これらの要素が考慮されるべきであり、これらの要素を他のある要素よりも重んじるのはポリシー決定である。この様に、ネットワークがどの様に設計されているかに基づいて、以下のようなケースもある。つまり、広告が認証されていないエージェントが、他のエージェントより信号強度で強ければ、広告が認証されているエージェントを抑えて、選択されるケースである。
【００３８】
ＭＮがＦＡ２からの広告を認証したと仮定する。もしＭＮがＡＡＡ＿ＦＡ２の公開鍵を持っていなくてＦＡ３からの広告を認証出来なければ、ＭＮはＦＡ２に登録するのがよりよいだろう。ＭＮがたまたまＡＡＡ＿ＦＡ２の公開鍵を持っているが、ＦＡ３からの広告を認証できない場合も同じようにするのがよい。しかしながら、上述したように、ＦＡ２かＦＡ３のエージェントどちらを選択すべきかは、完全にポリシー決定であり、他の要素を考慮にいれて決定すべきである。
【００３９】
ＭＮがＦＡ２からの広告を認証したと仮定する。またＭＮがＡＡＡ＿ＦＡ２の公開鍵を持っていて、ＦＡ３からの広告も認証するとする。ＦＡ２とＦＡ３は両方共、身元の正しさの点で利用できる。よって決定は、２つのエージェントの信号強度のような他の要素に基づくべきである。
【００４０】
ＭＮがＡＡＡ＿ＦＡ１やＡＡＡ＿ＦＡ２の公開鍵を持っていなくて、ＦＡ２とＦＡ３の両方の広告を認証できないとする。この時、現在行われているデータ通信の途絶を防ぐために、ＭＮは１つのエージェントを選択し、そこに登録を行うべきである。この決定は他の要素に基づくべきである。
【００４１】
（ステップ６４）
ＭＮが広告ＡＳＰFA2の認証に成功したので、ＦＡ２が選択されたとする（ステップ６３）。ＭＮはするとＦＡ２へ登録する。本発明の実施形態による登録プロセスは、基本的にＩＥＴＦの「モバイルＩＰ拡張、認証とアカウンティング要件」と題されたＲＦＣ２９７７と「ダイアメタモバイルＩＰ拡張（Ｄｉａｍｅｔｅｒ Ｍｏｂｉｌｅ ＩＰ Ｅｘｔｅｎｓｉｏｎｓ）」と題されたインターネットドラフト（ｄｒａｆｔ−ｃａｌｈｏｕｎ−ｄｉａｍｅｔｅｒ−ｍｏｂｉｌｅｉｐ−１２．ｔｘｔ）にしたがっている。これら２つの文書は参照として本明細書に組み込まれる。図７は、本発明の実施形態による登録プロセスを示すフローチャートであり、ここでは広告の正当性が確認されている。図７に示される様に、階層的に経路が形成されて、ダイアメタメッセージがこの階層的な経路を、ＭＮの登録を行うために送られる。上で仮定されたように、ＭＮとＦＡ２を除いて経路上のどの２つのエンティティもお互いに、安全に通信を行うためにセキュリティアソシエーションを確立しているか、必要な時に確立できる。このようなセキュリティアソシエーションは、例えば、手動でもしくは動的に分配された共通鍵や公開鍵を使用するなど、認証方法はどんなのでも良い。
【００４２】
既に述べた様に、ＭＮはＦＡ２からのエージェント広告を認証している。ＭＮは、次に登録要求（ＭＩＰ＿Ｒｅｇ＿Ｒｅｑｕｅｓｔ）をＦＡ２に送る（ステップ７１）。この要求には、ＭＮのホームアドレス、ＭＮのホームエージェント（ＨＡ）のアドレス、そしてＭＮの身元証明（例えば、ネットワークアクセス識別子：ＮＡＩ）が含まれている。ＦＡ２は、この要求をダイアメタメッセージ（Ｄｉａｍｅｔｅｒ Ｍｅｓｓａｇｅ）の形式に変更して、ローカル管理サーバＡＡＡ＿ＦＡ１に送信する（ステップ７２）。ＦＡ２からこの登録要求を受信するとすぐに、ＡＡＡ＿ＦＡ１はＭＮのホーム管理サーバを確定し、この登録要求をＡＡＡ＿ＨＡに転送する（ステップ７３）。ＡＡＡ＿ＨＡは、ＭＮの身元確認を行う。ＡＡＡ＿ＨＡがＭＮの身元を確認できなかったら、ＡＡＡ＿ＨＡはＡＡＡ＿ＦＡ１にエラーメッセージを返す。しかし、ＡＡＡ＿ＨＡがＭＮの身元を確認した場合は、ＡＡＡ＿ＨＡはＨＡにこの登録要求を送る（ステップ７４）。
【００４３】
ＨＡは、ＡＡＡ＿ＨＡから登録要求を受信するとすぐに、キャッシュ内にＭＮのバインディング情報を保存する。バインディング情報にはＭＮの現時点の接続点、すなわちＭＮの気付アドレスを含む。ＨＡは次に登録返答を作成し、ＡＡＡ＿ＨＡに送る（ステップ７５）。ＡＡＡ＿ＨＡは、登録返答をＡＡＡ＿ＦＡ１に転送する（ステップ７６）。ＡＡＡ＿ＦＡ１は、今度はこの登録返答をＦＡ２に転送する（ステップ７７）。ＡＡＡ＿ＦＡ１からの返答は、ＦＡ２にとって、ＭＮのネットワークアクセスがＦＡ２を介して認証されたと言うことを表している。ＦＡ２は、返答をＭＮに転送する（ステップ７８）。ＭＮが返答を受け取った時、登録プロセスが終わる。
【００４４】
（ステップ６５）
ステップ６３において、ＭＮがＡＡＡ＿ＦＡ２の公開鍵を持っていなくて広告ＡＳＰFA3を認証できないにもかかわらず、ＭＮはＦＡ３に登録すべきであると判定されたと仮定する。この場合、ＭＮは、ＦＡ３からのエージェント広告の認証をしようとせずに、図８に示された登録プロセスに従ってＦＡ３に登録する処理を行う。図８に示された登録プロセスには、図７で既に説明をした基本登録プロセスを含まれ、さらに、ＭＮがＡＡＡ＿ＦＡ２の公開鍵を取得する追加のプロセスが含まれている。基本登録プロセスの詳細を、繰り返して説明することは省略する。図８を参照して、追加の登録プロセスのみ説明する。
【００４５】
ＭＮは、ＡＡＡ＿ＦＡ２の証明書（ＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿Ｒｅｑｕｅｓｔ）を要求する要求を作成し、登録要求に付加する。ＭＮは次に、この要求をＦＡ３に送る（ステップ８１）。ステップ８２において、ＦＡ３は、ＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿Ｒｅｑｕｅｓｔを登録要求とともにＡＡＡ＿ＦＡ２に転送する。ＡＡＡ＿ＦＡ２は、ＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿ＲｅｑｕｅｓｔをＦＡ３から受信するとすぐに、自分の公開鍵（ＡＡＡ＿ＦＡ２’ｓＰｕｂ＿Ｋｅｙ）をＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿Ｒｅｑｕｅｓｔに入れて、ＡＡＡ＿ＨＡに登録要求とともに送る（ステップ８３）。ＡＡＡ＿ＨＡは、ＡＡＡ＿ＦＡ２の公開鍵が入っていて、ＡＡＡ＿ＨＡのプライベートキーで署名された証明書を作成する。ＡＡＡ＿ＨＡは、返答（ＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿Ｒｅｐｌｙ）を作成して、返答の中に証明書を入れる。ＡＡＡ＿ＨＡは、それから、ＨＡから登録返答を待つ。
【００４６】
ＡＡＡ＿ＨＡがＨＡから登録返答を受信したら、ＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿Ｒｅｐｌｙを登録返答に付加してＡＡＡ＿ＦＡ２に送る（ステップ８４）。ＡＡＡ＿ＦＡ２から、ＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿ＲｅｐｌｙがＦＡ３に転送され（ステップ８５）、ＭＮに送られる（ステップ８６）。ＭＮはＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿Ｒｅｐｌｙを受信するとすぐに、ＭＮはＡＡＡ＿ＨＡの公開鍵を使用して、この要求内にある証明書を復号化してＡＡＡ＿ＦＡ２の公開鍵を取り出す。ＭＮはＡＡＡ＿ＨＡによるドメインから発信しているので、ＭＮはＡＡＡ＿ＨＡの公開鍵をもっているはずである。ＭＮが証明書の復号化に成功したら、ＭＮはＡＡＡ＿ＦＡ２を信頼しその公開鍵を受け取っても良い、これはＡＡＡ＿ＦＡ２が、ＭＮが信頼するＡＡＡ＿ＨＡの公開鍵によって、ＭＮに本物であると認証されたからである。ＭＮはＡＡＡ＿ＦＡ２の公開鍵を、将来の使用の為にキャッシュの中に保存する。
【００４７】
ＭＮのキャッシュ内に保存されたＡＡＡ＿ＦＡ２の公開鍵は、生存期間があり、この生存期間が来たら無効になる。しかし、生存期間内では、公開鍵は再使用できる。このようなことが起こるのは、例えば、ＭＮがＡＡＡ＿ＦＡ２によるドメイン内に入った後、ＭＮが接続点を変更する移動をドメイン内で行った時、または、ＭＮがドメインを出たあと、またそのドメインに入った時である。このことが、ＭＮのキャッシュ内に保存されているＡＡＡ＿ＦＡ２の生存期間内に起これば、ＭＮは新しいエージェントからのエージェント広告をこの公開鍵を使用して復号化することができ、図７に示される登録プロセスに従って、新しいエージェントに登録することができる。
【００４８】
図９は、本発明の他の実施形態を示すフローチャートである。ステップ９１において、ＭＮは多数のフォーリンエージェントからエージェント広告を受信する。ＭＮはどの広告も認証できないと仮定する。言い換えると、周囲の管理ドメインは全て、ＭＮにとって初めてのものであり、ＭＮは周囲のドメイン内の管理サーバの公開鍵をどれも持っていない。進行中のデータ通信が中断するのを防ぐために、ＭＮは１つのフォーリンエージェントを選択して、それに登録を進めなければならない。この選択は、確実で信頼できるフォーリンエージェントが安定したエージェント広告を送信しているとの仮定に基づいている。「安定した」とは広告に含まれているパラメータが時間とともに変化しないと言う意味である。このパラメータには、気付アドレス、ＲＦＣ２００２によって規定されているソースアドレス、そして証明書や鍵などの本発明によって追加された識別子が含まれている。
【００４９】
信頼できるエージェントは同じエージェント広告を一貫して流し続けていて、悪意のあるエージェントは定期的にパラメータを変更したエージェント広告を送信し、できるだけ多くのモバイルノードをひきつけようをしている、と仮定する。このような悪意のあるエージェントを特定するために、ＭＮはエージェント広告をある期間受信して（ステップ９１）、受信した広告を、その中に含まれているパラメータの一貫性の順にグループに、ＭＮ内の並べ替え手段を使用して並べ替える（ステップ９２）。ステップ９３において、ＭＮは、最も一貫していると位置付けられた広告のグループを選択する。ＭＮは次に、そのグループの中から、信号強度が最高かパケット遅延の最低の広告を１つ選択する。これら２回の選択はＭＮ内の選択手段が行う。ステップ９４において、選択されたエージェント広告を送信していたエージェントに、ＭＮは、送信手段を使用して登録要求を送信して登録を試みる。ＭＮがそのエージェントに登録できなかった場合は（ステップ９５）、ＭＮは、そのグループ内の全てのエージェント広告を捨ててステップ９３に戻る。ステップ９３において、ＭＮは、第２番目に一貫していると位置付けられた広告のグループを選び、そのグループから、上述の方法と同じように、１つの広告を選択する。ステップ９４で、選択された広告のエージェントにＭＮは登録しようとする。ＭＮは、このプロセスを登録に成功するまで続ける。この方法では、ＭＮが悪意のあるエージェントに登録しようとするのを防ぐ事はないが、登録試行が失敗に終わる回数を減らすことが期待できる。
【００５０】
本発明の好適な実施形態を説明したが、以上の説明は例示のためであり、本発明を限定しようとするためのものではない。当業者であれば、発明の新規性と有利な特徴を保ちながら、発明の精神から逸脱せずに変更や追加ができることを理解できるであろう。以上から、本発明の範囲は、正しく理解された特許請求の範囲のみによって決まる。
【００５１】
【発明の効果】
以上説明したように、本発明によれば、ネットワークへのアクセスを安全に素早く行うことができる。
【図面の簡単な説明】
【図１】 本発明の用途として意図している第３世代無線モバイルアクセスＩＰネットワークを例示している図である。
【図２】 第３世代無線モバイルアクセスデータネットワークにおけるモバイルノードのハンドオフのプロセスを簡単に示した図である。
【図３】 ＡＡＡプロトコルに基づいた本発明による第３世代無線モバイルアクセスデータネットワークを簡単に示した図である。
【図４】 図３に示されたネットワーク内の内在しているセキュリティモデルの図であり、破線はネットワーク内に仮定されているセキュリティアソシエーションである。
【図５】 本発明で使用されるモバイルＩＰ広告を示す図である。
【図６】 本発明の実施例によるエージェント認証プロセスを示すフローチャートである。
【図７】 本発明による登録プロセスを示すフローチャートであり、ここではモバイルノードがエージェントからの広告を認証している。
【図８】 本発明による登録プロセスを示すフローチャートであり、ここではモバイルノードがエージェントからの広告を認証していない。
【図９】 本発明によるエージェントを選択するプロセスを示すフローチャートであり、ここではモバイルノードが近隣のエージェントを認証できない。
【符号の説明】
１００・・・無線モバイルアクセスＩＰネットワーク、１２０・・・コアネットワーク、１３０・・・ゲートルータ、１３５・・・モバイルノード、１４０・・・ＩＰモバイルバックボーン、１４５・・・サーバ、１５０・・・基地局ネットワーク、ＭＮ・・・モバイルノード、ＨＡ・・・ホームエージェント、ＦＡ１、ＦＡ２、ＦＡ３・・・フォーリンエージェント、ＡＡＡ＿ＨＡ・・・ホーム管理サーバ、ＡＡＡ＿ＦＡ１、ＡＡＡ＿ＦＡ２・・・フォーリン管理サーバ。
【発明の属する技術分野】
本発明は、モバイルノードに接続を提供するネットワークの認証の為のプロトコルに関する。本発明によるセキュリティプロトコルは、ＡＡＡフレームワークに基づいているとともに、認証メカニズムに公開鍵方式の暗号化方式を使用する。
【０００２】
【従来の技術】
パーソナルコミュニケーションデバイスへの依存が急速に進んでいるので、世界中で無線通信への需要が拡大している。無線の役割が、ほんの数年前の音声と呼び出し無線サービス以上に大きくなっている。世界的データネットワークの標準化の為に認められた機関であるインターネット協会の国際電気通信連合（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ（ＩＴＵ））は最近、国際移動体通信２０００規格（ＩＭＴ−２０００）を発表した。この規格では、いわゆる第３世代とそれ以降（すなわち第３．５世代、第４世代）のデータネットワークを提案しているが、このデータネットワークには、セルラ方式電話、携帯情報端末（ＰＤＡ）、ハンドヘルドコンピュータなどの無線式移動体端末による広範囲にわたるモバイルアクセスが含まれている。第３世代とそれ以降の世代のネットワークでは、モバイルノードは、ネットワークリソースへの接続を維持しながら、あるネットワークから他のネットワークへとネットワークへの接続点を変更しながら移動することができる。このために、このようなデータネットワークは、ローミングしているモバイルノードをアドレス指定するモビリティサポートと、ネットワークを越えてローミングをしているモバイルノードにデータパケットをダイナミックに再ルーティングすることと、一番重要なのだが、そのようなローミングしているモバイルノードとモバイルノードが訪れたネットワークの間の認証とを提供するように設計されていなければならない。
【０００３】
インターネットアーキテクチャの発展とインターネットのスムーズな運営に関心を有している、ネットワーク設計者、事業者、ベンダー、さらに研究者の国際的なコミュニティである、インターネット技術標準化委員会（ＩＥＴＦ：ＴｈｅＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｎｅｒｉｎｇ Ｔａｓｋ ｆｏｒｃｅ）は、モビリティへの対応に関するいくつかの基準を提案した。これらには、モバイルＩＰバージョン４（ＩＰｖ４）とも呼ばれているＩＥＴＦによるＲＦＣ２００２や、モバイルＩＰバージョン６と呼ばれている「ＩＰｖ６におけるモビリティサポート」と言う題の文書「ドラフト−ｉｅｔｆ−モバイルＩＰｖ６−１３：ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｉｐｖ６−１３」などのＩＰモビリティサポートの為に提案中標準が含まれている。両文書は、参照として本明細書に組み込む。
【０００４】
モバイルＩＰｖ４とＩＰｖ６で決められたプロトコル処理によれば、モバイルノードは、ネットワークリソースへの接続を保ちながら、あるネットワークから他のネットワークに接続ポイントを変更しながら移動することができる。この処理は、「レイヤ３（Ｌ３）ハンドオフ」と呼ばれ、レイヤ２（Ｌ２）ハンドオフとは区別されるべきである。ここでレイヤ２ハンドオフとは、モバイルノードが同一のネットワーク内で、リンク層の接続をあるアクセスポイントから他のアクセスポイントに変更することを言う。Ｌ３ハンドオフでは必ずＬ２ハンドオフが伴うが、逆は必ずしもそうでない。モバイルＩＰｖ４とＩＰｖ６は、Ｌ３ハンドオフの処理に使用されるメカニズムを提供している。モバイルＩＰｖ４とＩＰｖ６両方において、ハンドオフ処理はモバイルノードがハンドオフされる次のエージェントやルータを探す処理から始まる。モバイルＩＰｖ４において、この処理は、「エージェントディスカバリ」と呼ばれ、接続を提供するモビリティエージェントをモバイルノードが探す処理である。
【０００５】
モビリティエージェントは定期的に自分自身の存在を示す広告（ａｄｖｅｒｔｉｓｅ）をしている。モバイルノードは、近くのモビリティエージェントからの広告メッセージを受信して、自分自身が接続しているエージェントや自分自身がハンドオフされうるエージェント候補を見つけることができる。モバイルノードは、エージェントソリシテーションを送信することで、近くのエージェントにエージェント広告（Ａｄｖｅｒｔｉｓｅｍｅｎｔ）を要求しても良い。モバイルＩＰｖ６では、同じ処理が「近隣ディスカバリー：Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ」と呼ばれている。近隣ディスカバリーでは、ルータがルータ広告（Ａｄｖｅｒｔｉｓｅｍｅｎｔ）を使って接続を提供している。モバイルノードは、ルータソリシテーションを送信することで、近くのルータにルータ広告（Ａｄｖｅｒｔｉｓｅｍｅｎｔ）を要求しても良い。
【０００６】
Ｌ３ハンドオフの処理で一番重要なのは登録である。モバイルノードは常に、「ホームアドレス」によりそのアドレスを指定することができる。このホームアドレスとは、ホームリンク上のホームエージェントによってモバイルノードに割り当てられたＩＰアドレスか、またはモバイルノード自身で決めたＩＰアドレスである。ホームリンクから離れたフォーリンリンク上にモバイルノードがある時は、モバイルノードは、モバイルノードがその時点でインターネットに接続しているポイントを示す気付アドレスによって、アドレス設定されている。モバイルＩＰｖ４では、気付アドレスはフォーリンエージェントのアドレスであり、ホームから離れたところにあるモバイルノードは、気付アドレスをホームエージェントに登録する。登録要求を受けたホームエージェントは、モバイルノード宛のパケットを調べて、そのパケットをモバイルノードの気付アドレス宛に転送する。モバイルＩＰｖ６では、ホームから離れたモバイルノードは、ホームルータと通信相手ノードとにバインディング更新要求を送る。バインディング更新要求を受けた通信相手ノードは、ホームルータを通すルートでなく、モバイルノードに直接パケットを送信する。
【０００７】
【非特許文献】
シー・パーキンス（Ｃ．Ｐｅｒｋｉｎｓ）編、「ＲＦＣ２００２」、インターネット技術標準化委員会（ＩＥＴＦ：Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｎｅｒｉｎｇ Ｔａｓｋ ｆｏｒｃｅ）、１９９６年１０月
【０００８】
【発明が解決しようとする課題】
ここで、モバイルノードが、第１のネットワークから第２のネットワークへとハンドオフしようとする時に、重大なセキュリティの問題が出てくる。つまり、第２のネットワークは、モバイルノードに対して安全であると認証されなければならないのである。これによりモバイルノードが悪意のある環境で動作することのないようにしなければならない。例えば、モバイルノードがあるネットワークから他のネットワークに移動する時に、連続した良好なサービスをユーザに提供する為に、素早いハンドオフが必要である。しかし、問題のあるフォーリンエージェントやルータがあって、問題のある広告メッセージを送信することで、モバイルノードが素早いハンドオフを行うのを妨げようとしていると言われている。問題のある広告メッセージとして、モバイルノードをだますための誤った情報を入れたものがあり、これにより、モバイルノードは、その広告を出しているフォーリンエージェントを他のエージェントよりも接続すべき相手だ（実際はそうではないのだが）と誤って判断してしまう。悪意のあるエージェントやルータに登録するように誘い込まれたモバイルノードは、何度も登録を試みようとしても登録できないという結果になるだろう。もしモバイルノードが、そのようなフォーリンエージェントやルータに登録できても、モバイルノードは貧弱な接続性やサービスを受けることになるであろう。
【０００９】
現在、多くの認証方法が実施され、様々なアクセス技術のために導入されている。これには、例えばＰＰＰと８０２．１ネットワーク（無線ＬＡＮ）の認証がある。しかし、これらはリンク層の方法であり、特定のアクセス技術にしか適用できないので、万能な解決方法ではない。この点で、ネットワーク層の解決法が好ましいのは明らかである。ネットワーク層の解決法は、その下のリンク層でどんなアクセス技術が使われていようが有効であろう。ＩＰｓｅｃ認証サービスはＬ３の方法であるが、Ｌ３ハンドオフの場合は、ネットワークとモバイルノードがお互いに認証するための、実行可能な解決法にはなりえない。ＩＰｓｅｃ認証は、２つの要素間で前もって存在するセキュリティアソシエーションを前提にしている。あるフォーリンエージェントやルータが、広告を受信した各モバイルノードとセキュリティアソシエーションをするだろうと仮定することは出来ないし、あるいは、モバイルノードが、広告を送信している近くのフォーリンエージェントやルータ全てとセキュリティアソシエーションをするだろうと仮定することも出来ない。
【００１０】
【課題を解決するための手段】
本発明において、接続を提供するモビリティエージェントは、モバイルノードが認証できる形式で広告メッセージを送信する。本発明によれば、ネットワークは管理ドメインを有していて、この管理ドメインの各々は、管理サーバと最低１つのモビリティエージェントを有している。モビリティエージェントは、信頼されたエンティティが認証した広告メッセージを用いて接続を提供し、これにより、モバイルノードがメッセージの正当性を確かめることができる。
【００１１】
信頼されたエンティティは、広告を送信しているモビリティエージェントが属するドメインにサービスを提供している管理サーバでも良い。広告メッセージは、広告を送信しているモビリティエージェントのプライベートキーによって署名されていて、証明書（広告を送信しているモビリティエージェントの公開鍵を含んでいて、信頼された管理サーバのプライベートキーによって署名されている）を同封していても良い。このように、モバイルノードが信頼された管理サーバの公開鍵を持っていれば、モバイルノードは、メッセージの正当性を確かめることができる。
【００１２】
モバイルノードが広告メッセージを受信し、その広告の認証に成功したら、モバイルノードは、認証した広告から１つを選択し、選択した広告を送信したモビリティエージェントに登録する。モビリティエージェントの選択は、広告を送信しているモビリティエージェントの接続性による。
【００１３】
モバイルノードが、広告を送信しているモビリティエージェントのどれも認証できない場合でも、モバイルノードは、広告を送信しているモビリティエージェントから１つを選択し、その選択された１つに登録を進める。この登録プロセスを通して、モバイルノードは、信頼された管理サーバの公開鍵を取得する。信頼された管理サーバの公開鍵は、モバイルノードの認証に責任を有するホーム管理サーバによって認証される。モバイルノードが信頼するホーム管理サーバによって認証されたので、信頼された管理サーバの公開鍵の正しさも、モバイルノードは信頼することができる。
【００１４】
本発明は、受信した広告メッセージのどれもモバイルノードが認証できない場合に、１つのモビリティエージェントを選択する独特な方法を提供する。モバイルノードは、始め、ある期間内に受信した広告メッセージをグループに並べ替える。この並び替えは、メッセージ内に含まれているパラメータの一貫性の順にしても良い。モバイルノードは、次に、広告メッセージのグループのうち１つを選択する、そしてその選択したグループから１つの広告メッセージを選択する。このプロセスの間、パラメータの一貫性が高い順に、グループの選択を行っても良い。そして、広告メッセージの選択は、メッセージを送信しているモビリティエージェントへの接続性に基づいて行われる。そして、モバイルノードは、選択されたメッセージを送信しているモビリティエージェントに登録する。選択された広告を送信しているモビリティエージェントへの登録が失敗した場合、モバイルノードは、選択したグループの広告を全て廃棄し、次に高い一貫性を有する他のグループを選択する。モバイルノードは、モビリティエージェントに登録できるまで、このプロセスを繰り返す。
【００１５】
【発明の実施の形態】
以下に図面を参照しながら、本発明による好適な実施形態を説明する。ここで同一の要素は同一の符号で表される。ここでの実施例の記載は、例示を意図したものであり、発明の範囲を限定するものではない。
【００１６】
図１は、本発明の用途として意図している第３世代無線モバイルアクセスＩＰネットワーク１００を例示している図である。説明上、データネットワーク１００は、無線モバイルアクセスネットワークの為のＩＴＵのＩＭＴ−２０００基準と仕様に準拠していると仮定する。更に、データネットワーク１００は、ＩＥＴＦの提案されたモバイルＩＰｖ４とＩＰｖ６に拠ったモバイルＩＰサポートを実装していると仮定する。無線モバイルアクセスＩＰネットワーク１００は、固定接続点またはリンクなどの多くの固定ノード（図示せず）を有するＩＰデータネットワーク１２０をそのコアとして有している。
【００１７】
インターネットのプロトコルに従って、デジタルデータはネットワーク内やネットワークを越えて伝送される。コアネットワーク１２０上には、ゲートルータ１３０の集合がある。このゲートルータ１３０の集合は、ＩＰモバイルバックボーン１４０を形成し、インターネット標準のアドレス・ルーティングプロトコルに従って、このネットワークに接続している出所元ノードと宛先ノードの間でのデータパケット伝送をする。ＩＰモバイルバックボーン１４０を形成しているゲートルータ１３０は、それ自身がコアネットワーク１２０のノードであり、コアネットワーク１２０を超えて通信をするために、他と重複しないＩＰアドレスを有している。
【００１８】
ゲートルータ１３０の各々にはサーバ１４５が接続されている。このサーバ１４５も他と重複しないＩＰアドレスを有していて、ホームエージェント（ＨＡ）やフォーリンエージェント（ＦＡ）として機能することができ、モバイルＩＰｖ４で規定されているように、モバイルノード１３５のコアネットワーク１２０へのインターフェースとして働き結びつける。モバイルＩＰｖ６では、これらのサーバ１４５は、モバイルノード１３５にＩＰ接続を提供するホームルータやフォーリンルータとして働く。ネットワーク１２０には、モバイルＩＰｖ４かモバイルＩＰｖ６かのどちらかを実装するネットワークがあっても良い。よって、本出願の全般にわたり、「エージェント」と言う語は、「アクセスルータ」または「ルータ」と言う語と交換して使われうる。同じように、「エージェントディスカバリ」は「近隣ディスカバリ」と、「エージェントソリシテーション」は「ルータソリシテーション」と、「登録要求」は「バインディング更新要求」と、交換して使われうる。
【００１９】
モバイルノードは、セル式ハンドセット、セル式電話、ハンドヘルドコンピュータ、パーソナル情報機器、無線データターミナルのような通信端末であり、無線を使用していても良い。モバイルノード１３５の各々にはホームサブネットワークが割り当てられている。各モバイルノードはホームエージェントルータを有していて、このホームエージェントルータは、実際はホームサブネットワークのセンタサーバである。各モバイルノード１３５にとっては、ホームエージェントがネットワーク１２０への元々の接続点であり、各モバイルノードは、ホームサブネットワークにおいて、ホームエージェントから割り当てられたホームアドレスかモバイルノード自身で選んだホームアドレスにより、アドレス指定される。他のエージェント１４５はフォーリンエージェントかルータとして機能することができる。モバイルノード１３５がフォーリンエージェントのサブネットワークに入って来た時は、フォーリンエージェント１４５はモバイルノード１３５にネットワークアクセスを提供しても良い。モバイルノードがホームから離れてフォーリンサブネットワーク上にある時は、モバイルノードは、気付アドレスによってアドレス設定されている。この気付アドレスは、そのモバイルノードがいるフォーリンサブネットワークのアドレスであり、モバイルノードがその時点でインターネットに接続しているポイントを示している。モバイルノード１３５がホームサブネットワークから離れて稼動している時、モバイルノードのホームエージェント１４５は、登録プロセスを通してモバイルノード１３５の現在地情報を保持している。
【００２０】
各エージェント１４５は基地局ネットワーク１５０を有している。この基地局ネットワーク１５０を通して、モバイルノード１３５はエージェントやルータ１４５と通信を行う。基地局ネットワーク１５０の各々には複数の基地局すなわちアクセスポイント（ＡＰ）１５５がある。モバイルノード１３５とＡＰはＣＤＭＡやＷ−ＣＤＭＡまたは他の公知のデジタルデータ通信技術を使用して、お互いに通信を行う。ＡＰネットワーク１５０やＡＰ１５５の構成と設備と機能とは従来のものであり標準のものである。同様に、無線モバイルノード機器１３５とＡＰ１５５が使用するＣＤＭＡやＷ−ＣＤＭＡまたは他のデジタルデータ通信技術は標準のものである。本発明の理解には、これらの詳細な説明は必要ないので、省略する。
【００２１】
データネットワーク１００全体の中で、２種類のモビリティハンドオフが考慮されている。レイヤ２（Ｌ２）ハンドオフとはモバイルノードが同一のＡＰネットワーク１５０内で位置を変更することを言い、モバイルノードのネットワークリンクは変わらず、モバイルノードの接続点が、あるＡＰ１５５から他のＡＰ１５５に変わる。Ｌ２ハンドオフは無線セル方式通信ネットワークにおいてよく知られている。例えば、モバイルノード１３５がＡＰネットワーク１５０内を移動する間のＡＰ間の通信ハンドオフを見つけたり処理したりする為に、レイヤ２信号やビーコンシグナルをモニターすることは良く知られている。レイヤ３（Ｌ３）ハンドオフは、あるサブネットワークから他のサブネットワークへ接続点を変更することを言う。言い換えれば、モバイルノードは、あるサブネットワークを離れ、他のエージェント１４５配下の他のサブネットワークへと入る。Ｌ３ハンドオフにおいて、モバイルノードは、サブネットサーバ間でネットワークへの接続点を変更する時期を知るために、近くのエージェントからの信号をモニターしている。
【００２２】
図２は、第３世代無線モバイルアクセスデータネットワークにおけるモバイルノードのＬ３ハンドオフを簡単に示した図である。図２において、ネットワーク１００は、コアネットワーク１２０と、コアネットワーク１２０に接続されたエージェント１４５とを有している。エージェント１４５にはホームエージェントＨＡとフォーリンエージェントＦＡ１、ＦＡ２、ＦＡ３とが含まれる。モバイルノード（ＭＮ）１３５にとって、ホームエージェントＨＡがネットワーク１２０への元々の接続点である。フォーリンエージェントＦＡ１、ＦＡ２、ＦＡ３は、モバイルノードＭＮ１３５が各々のサブネットワークに入って来た時に、ＭＮ１３５に各々のネットワークアクセスポイントを提供しても良い。図２に示される例において、ＭＮ１３５は元々開始位置Ａにいて中間位置Ｂを経由して位置Ｃに移動する。開始位置Ａにおいて、ＭＮ１３５はＦＡ１配下のフォーリンサブネットワークで動作していて、ＦＡ１を経由してネットワーク１２０に接続している。一方、位置ＣはＦＡ２配下のフォーリンサブネットワーク内に位置ある。このとき、ＭＮ１３５がＦＡ１配下のサブネットワークを横切って、ＦＡ２配下のサブネットワークに入ると、Ｌ３ハンドオフがＭＮ１３５に発生して、ＭＮ１３５はネットワーク接続をＦＡ１経由からＦＡ２経由へと変更する。
【００２３】
ＭＮ１３５の移動はディスカバリメカニズムにより検出される。このメカニズムは、モバイルＩＰｖ４でのエージェントディスカバリかモバイルＩＰｖ６の近隣ディスカバリでも良い。ディスカバリメカニズムに従って、ＦＡ１、ＦＡ２、ＦＡ３は、モバイルＩＰｖ４の場合はエージェント広告で、モバイルＩＰｖ６の場合はルータ広告を用いて、定期的に存在を広告する。ＭＮ１３５は、モバイルＩＰｖ４の場合エージェントソリシテーションを、モバイルＩＰｖ６の場合ルータソリシテーションを送信することで、これらの広告メッセージをフォーリンエージェント１４５に要求しても良い。ＭＮ１３５は受信部を使用して、これらの広告を受信すれば、ＭＮ１３５は現在どのサブネットワーク内にいるか決定できる。開始位置Ａにおいて、ＭＮ１３５はエージェント広告をＦＡ１だけから受信するが、このエージェント広告は、ＦＡ１配下のフォーリンサブネットワーク上にＭＮ１３５がいると伝えている。ＭＮ１３５が中間位置Ｂに到達し、位置Ｃへと移動するにつれて、ＦＡ２からの広告がＭＮ１３５に着きはじめる。従って、ＭＮ１３５は、自身がＦＡ１のサブネットワークを離れ、ＦＡ２配下のサブネットワークに入りつつあるとわかる。
【００２４】
ＭＮ１３５が中間位置Ｂを通った後に、Ｌ２ハンドオフが発生する時がきて、ＭＮ１３５は、ＦＡ１によるサブネットワーク内のＡＰ１５５のうちの１つから、ＦＡ２によるサブネットワーク内のＡＰ１５５のうちの１つへと、Ｌ２接続を変更する。Ｌ２ハンドオフが終了した後、ＦＡ２からの広告メッセージのみがＭＮ１３５に届く。ＭＮ１３５に届く広告メッセージに基いて、ＭＮ１３５はＦＡ２配下のサブネットワーク内で動作しているのだとわかる。ＭＮ１３５は次に、ＦＡ２を通してＨＡに登録要求またはバインディング更新を送ることで、登録プロセスを始める。登録要求またはバインディング更新には、気付アドレスが含まれている。この気付アドレスは、ＭＮ１３５がＦＡ２からの広告メッセージから得たＦＡ２のサブネットワークのアドレスである。ＨＡにおいて、ＭＮ１３５の身元が証明されたら、ＨＡはＭＮ１３５の気付アドレスを記憶し、ＦＡ２に返事を出す。ＦＡ２はこの返事を処理して、ＭＮ１３５に送る。この返事は、ＭＮ１３５が本物であるとＦＡ２に証明し、ＭＮ１３５とＦＡ２の間の接続確立に許可を与える。この登録プロセスの後、ＭＮ１３５はＦＡ１からＦＡ２へのＬ３ハンドオフを終える。
【００２５】
モバイルデータ通信の人気が上がるにつれ、モバイルノードを誘導し登録をさせようとする好ましくないモビリティエージェントが増えてくる。しかし、これらのエージェントは、実際のところは、質の低い接続性やサービスを提供し、モバイルノードが素早いハンドオフを行うのを邪魔しているだけである。これらの好ましくないモビリティエージェントが増えるにつれ、モバイルＩＰ登録プロセスがこれらの好ましくないエージェントで始まる前に、このような悪意のあるエージェントを特定しようとする必要性が出てきた。本発明によれば、モビリティエージェントを認証するためのセキュリティプロトコルを提供され、モバイルノードは、このような悪意のあるエージェントを特定できるようになり、それらにハンドオフするよう誘導されないようになる。
【００２６】
本発明のセキュリティメカニズムは、ＡＡＡプロトコルに基づいている。ＲＡＤＩＵＳやＤＩＡＭＥＴＥＲのようなＡＡＡプロトコルは、現在インターネットにおいて使用されていて、認証、許可、アカウンティングサービスをダイアルアップユーザに提供している。このようなＡＡＡ管理サービス、特にＡＡＡサーバによって提供されている認証サービスは、モバイルＩＰを使用したモバイルノードにとって重要である。モバイルＩＰとは、モバイルノードがあるネットワークから他のネットワークに移動できるようにしている技術である。ＡＡＡプロトコルでは、ある共通の管理のもとで動作している１つまたは複数のネットワークからなる管理ドメインを定義している。この様に、ＡＡＡ管理ドメインの定義のされ方によって、モバイルノードの移動が、あるネットワークから同じ管理ドメイン内のネットワークへのものになったり、異なった管理ドメインのネットワークへのものになったりする。
【００２７】
しかし、モバイルノードのモバイルＩＰの移動をＡＡＡ管理ドメインにマッピングすることで、モバイルＩＰを実装しているモバイルノードにとって、ＡＡＡ管理サービスが利用可能になる。実際、モバイルＩＰはＡＡＡインフラストラクチャ上に、基礎的フレームワークにほとんど変更を加えずに実装できる。例えば、ＡＡＡプロトコルのクライアントは、モバイルＩＰのモバイルノードであるとみなされる。モバイルＩＰのモビリティエージェントは、ＡＡＡプロトコルのアテンダントにぴったり当てはまる。ＡＡＡメッセージを理解できる様に、モバイルノード、モビリティエージェントやルータのようなモバイルエンティティの機能を増やすことで、ＡＡＡインフラストラクチャ上にモバイルＩＰを実装することが可能となる。
【００２８】
普通、ＡＡＡ認証メカニズムは次のように働く。まず、第１のＡＡＡエンティティが通信相手としたい第２のエンティティに証明書を送る、そして第２のエンティティが第１のエンティティの証明書を正しいと確認したら、通信が認められる。ＡＡＡサーバは鍵配布センタとして働き、ＡＡＡエンティティの要求により、２つのＡＡＡエンティティ間の証明書の正しさを証明するのに使われる鍵を生成し配布する。ＡＡＡプロトコルは、他の鍵アルゴリズムと一緒に動くように設計されている。鍵アルゴリズムの中には、公開鍵インフラストラクチャがあることを前提にしているものもあり、また他方には共通鍵の配布によっているものもある。本発明の説明では、公開鍵インフラストラクチャを採用しているネットワークを使う。しかしながら、当業者は本発明の実装には他の鍵アルゴリズムでも良いと理解するであろう。
【００２９】
本発明の登録プロセスを、図３を参照してさらに説明する。図３は、ＡＡＡプロトコルに基づいた本発明による第３世代とそれ以降の無線モバイルアクセスデータネットワークを簡単に示した図である。このネットワーク内で、本発明による登録プロセスが実施される。図２に示すネットワークと同様に、図３のネットワークはモバイルＩＰｖ４かＩＰｖ６を実装している。本実施形態のネットワークは、ＡＡＡプロトコルを使用していて、それゆえに複数の管理サーバを有している。これら管理サーバはそれぞれ管理ドメインを作っている。ＡＡＡプロトコルに応じて、各管理サーバは、モバイルノードへのサービスのために、認証をし、許可をし、そしてアカウンティング情報を集める。
【００３０】
簡略化の為に、図３には３つの管理サーバＡＡＡ＿ＨＡ、ＡＡＡ＿ＦＡ１、ＡＡＡ＿ＦＡ２、のみが示されている。サーバＡＡＡ＿ＨＡは、ホーム管理サーバであり、モバイルノードＭＮの認証をになっている。多くの場合、サーバＡＡＡ＿ＨＡによる管理ドメインからモバイルノードが発呼し、そしてホーム管理ドメインはホームエージェントＨＡとＨＡによるサブネットワークを含む。言い換えると、多くの場合、ＭＮへの認証サービスと登録サービスは同一のドメインで行われる。しかしながら、認証サービスと登録サービスは同一のドメインで行われなくてもよいことに注意すべきである。すなわち、ホームエージェントＨＡは、ホームドメインとは違う管理ドメイン内にあっても良い。このような状況は次のようなばあいに起こる。つまり、ＭＮが、ある管理ドメイン内にあるＩＳＰに登録されていて、クレジットカード会社が他のドメインでＭＮの認証を行う場合である。サーバＡＡＡ＿ＦＡ１はフォーリン管理サーバであり、フォーリンエージェントＦＡ１とＦＡ２によるサブネットワークを含む管理ドメインを作っている。言い換えると、フォーリンエージェントＦＡ１とＦＡ２は共通の管理下にある。サーバＡＡＡ＿ＦＡ２もフォーリン管理サーバであり、フォーリンエージェントＦＡ３によるサブネットワークを含む管理ドメインを作っている。
【００３１】
図３に示すネットワークにはセキュリティモデルが内在する。図４は、そのような内在するセキュリティモデルを示していて、点線でエンティティ間のセキュリティアソシエーション（ＳＡ）を示している。第１に、ＨＡ、ＦＡ１、ＦＡ２、ＦＡ３はそれぞれ、それらの管理サーバとセキュリティアソシエーションを確立していると仮定する。各エージェントは、過去に、管理ドメイン内にいたときから、管理サーバと通信を行ったはずである。この様に、ＨＡとＡＡＡ＿ＨＡは、すでに確立しているセキュリティアソシエーションを有している。ＦＡ１とＦＡ２は、ＡＡＡ＿ＦＡ１との間ですでに確立しているセキュリティアソシエーションを有している。ＦＡ３は、ＡＡＡ＿ＦＡ２との間ですでに確立しているセキュリティアソシエーションを有している。第２に、ＭＮは、ＡＡＡ＿ＨＡとのセキュリティアソシエーションを前もって有している。これは、そうでなかったら、ＭＮの認証をＡＡＡ＿ＨＡが行えないからである。なお、ＡＡＡ＿ＨＡがＭＮの認証の責任を有している。第３に、登録プロセスの性質から、ＭＮは、自らが登録しようとしているフォーリンエージェントと、セキュリティアソシエーションを有していることはありえない。最後に、管理サーバＡＡＡ＿ＨＡ、ＡＡＡ＿ＦＡ１、ＡＡＡ＿ＦＡ２間で前もって確立されたセキュリティアソシエーションは必要ない。しかし必要な場合は、管理サーバ同士でのセキュリティアソシエーションを交渉することができなければならない。セキュリティアソシエーションは、仲介ＡＡＡサーバを使用して、もしくは、静的事前手配済みセキュリティアソシエーションを共有する事で、２つのサーバ間で確立しても良い。
【００３２】
本発明においては、エージェントＨＡ、ＦＡ１、ＦＡ２、ＦＡ３から送信されたエージェント広告メッセージは、正しいものであるとＭＮに証明することができる。エージェント広告メッセージの認証は、公開鍵暗号法を使用して、デジタル署名−デジタル証明書を用いて実行される。モバイルＩＰでは、エージェント広告を、モビリティエージェント拡張をした修正ＩＣＭＰルータ広告として定義している（図５参照）。広告には付随している拡張部がある。図３に示された例では、ＨＡ、ＦＡ１、ＦＡ２、ＦＡ３は、ＭＮが証明を行うことができる特別な形式でエージェント広告を送信している。さらに詳しくは、各エージェントメッセージは、送信側エージェントのプライベートキーでデジタル署名されて、デジタル証明書と付加される。このデジタル証明書は、送信側エージェントの管理サーバがそのサーバのプライベートキーで署名したものであり、送信側エージェントの公開鍵を含んでいる。この特別なエージェント広告は、「認証されたエージェント広告（ＡＳＰ）」と呼ばれ、次のように表される。
ＡＳＰ＝ＳＰ‖ｓｉｇSK-FA（ＳＰ）‖ｃｅｒｔAAA_FA（ＦＡ）
ここで、ｓｉｇSK-FA（ＳＰ）は、フォーリンエージェントＦＡのプライベートキー（ＳＫ−ＦＡ）で署名されている、フォーリンエージェントＦＡから来たエージェント広告メッセージ（ＳＰ）である。そして、ｃｅｒｔAAA_FA（ＦＡ）は、ＦＡの証明書であり、ＦＡの管理サーバＡＡＡ＿ＦＡのプライベートキーで署名されていて、ＦＡの公開鍵を含んでいる。
【００３３】
ＡＳＰを受信したＭＮがＦＡの管理サーバＡＡＡ＿ＦＡの公開鍵を持っていれば、ＭＮは付加されてきた証明書を復号化して、その中からＦＡの公開鍵を取り出す。ＦＡの公開鍵を使用して、ＭＮはエージェント広告メッセージを復号化することができる。この様に、ＦＡの管理サーバの公開鍵によって、エージェント広告メッセージが信頼でき完全なものであると、ＭＮは確かめることができ、また、メッセージを送ってきたフォーリンエージェントＦＡの身元が正しい物と確かめる事ができる。一方、ＭＮがＦＡの管理サーバＡＡＡ＿ＦＡの公開鍵を持っていなければ、ＭＮは広告メッセージの信頼性と完全性、さらにメッセージを送ってくるＦＡの身元に関して警戒しなければならない。そして、ＭＮは、近隣に確かな広告メッセージを送ってくる他のＦＡが利用可能であれば、そのＦＡに登録するのを避けるべきである。
図６は、本発明の実施例による認証プロセスを示すフローチャートである。
【００３４】
（ステップ６１）
ステップ６１において、ＭＮは近隣のエージェントからエージェント広告を受信する。図３で、ＭＮは始め開始位置Ａにいて、目的地Ｃへと移動していく。位置Ａでは、ＭＮはＦＡ１に登録している。よって、ＭＮがＦＡ１からの広告メッセージを復号化しＦＡ１に登録するのに必要であるＡＡＡ＿ＦＡ１の公開鍵を、ＭＮは有していると想定される。図３に示されるように、ＭＮは、位置Ａから移動し始め、位置Ｃに向かって、ＦＡ１によるサブネットワークを横切る。位置Ａと位置Ｃの間で、Ｌ２ハンドオフが起こり、ＭＮはＦＡ１との接続を失う。位置Ｃでは、ＦＡ２とＦＡ３によるサブネットワークが重なり合っている。言い換えると、これら２つのエージェントからのエージェント広告が位置Ｃに届く。本実施形態のＭＮはマルチリンク可能であると仮定されていて、ＭＮは位置Ｃに着いた時、ＭＮはＦＡ２とＦＡ３の両方からのエージェント広告を受信することができる。ＭＮは、レイヤ３に関して、シングルリンク可能であっても良いし、マルチリンク可能であっても良い。シングルリンク可能なＭＮは、１つのサブネットワーク内の１または複数のエージェントから１または複数のエージェント広告を受信することができる。このようなＭＮが、複数のサブネットワークが重なり合っている地点にいる場合、ＭＮは、この複数のサブネットワークのうちの１つのサブネットワーク内に位置する１または複数のエージェントから１または複数のエージェント広告を受信することができる。サブネットワークの選択は、ＭＮのレイヤ２で発生する。一方、マルチリンク可能なＭＮは、重なりあっている全てのサブネットワーク内のエージェントからエージェント広告を受信することが出来る。このようなＭＮは、そのレイヤ２内で行われた選択に基づいて、複数のサブネットワークの１つ内に位置するエージェントに接続することになる。
【００３５】
ＭＮが位置Ｃに着くと、ＭＮは、ＦＡ１によるサブネットワークを離れたことを知り、さらにＦＡ２とＦＡ３による２つのサブネットワークへ接続可能な地域に入ったことを知る。ＭＮは、ＦＡ２とＦＡ３のどちらに登録するかを決めなければならない。ＦＡ２は定期的に、自身の認証されているエージェント広告（ＡＳＰFA2）を送信しているが、このエージェント広告は次の様に示される。
ＡＳＰFA2＝ＳＰ‖ｓｉｇSK-FA2（ＳＰ）‖ｃｅｒｔAAA_FA1（ＦＡ１）
既に述べた様に、ＡＳＰFA2を復号化するために、ＭＮはＡＡＡ＿ＦＡ１の公開鍵が必要である。同様に、ＦＡ３は、自身の認証されているエージェント広告を定期的に送信している。このエージェント広告は次の様に示される。
ＡＳＰFA3＝ＳＰ‖ｓｉｇSK-FA3（ＳＰ）‖ｃｅｒｔAAA_FA2（ＦＡ２）
ＡＳＰFA3を復号化するために、ＭＮはＡＡＡ＿ＦＡ２の公開鍵が必要である。
【００３６】
（ステップ６２）
ステップ６２で、ＭＮは受信したエージェント広告の認証を試みる。ＭＮがＡＳＰFA2とＡＳＰFA3を受信すると、ＭＮは内部キャッシュを、ＡＡＡ＿ＦＡ１またはＡＡＡ＿ＦＡ２、もしくは両方の公開鍵があるかどうかを調べる。上で仮定したように、ＭＮは同じ管理ドメイン内に位置するＦＡ１に前に登録しているので、ＭＮはＡＡＡ＿ＦＡ１の公開鍵を持っている。ＡＡＡ＿ＦＡ１の公開鍵を使用して、ＭＮはＡＳＰFA2を認証する事ができる。ＡＳＰFA2を認証は２段階のプロセスである。最初に、ＭＮは、ＡＳＰFA2を送信しているＦＡ２を認証する。ＭＮはＦＡ２の証明書をＡＳＰFA2の証明書拡張部から取り出し、ＡＡＡ＿ＦＡ１の公開鍵を使ってこの証明書が正しい物であるか確認する。ＭＮが証明書を正しい物と確認したら、ＭＮが信頼しているＡＡＡ＿ＦＡ１によってＦＡ２がＭＮに認証されたので、ＭＮはＦＡ２を信頼する。第２に、ＡＳＰFA2が正しい物であるかを認証する。証明書が正しいと確認するとすぐに、ＭＮは、証明書から得たＦＡ２の公開鍵を使い、署名拡張部のデジタル署名が正しいものであるかを確かめる。ＭＮがデジタル署名を正しい物と確認したら、ＦＡ２によって広告の正しさがＭＮに保証されたので、ＭＮは受信した広告ＡＳＰFA2を信頼する。
【００３７】
（ステップ６３）
ステップ６３で、ＭＮは登録するエージェントを１つ選択する。基本的に、エージェントの選択はポリシー決定である。この様に、エージェントの選択は、ＭＮがある特定のエージェントの認証に成功したかどうかを考慮するだけでによるべきではなく、他の複数の要素（例えば、エージェントからの信号の強度や信号対雑音比）によってなされるべきである。これらの要素が考慮されるべきであり、これらの要素を他のある要素よりも重んじるのはポリシー決定である。この様に、ネットワークがどの様に設計されているかに基づいて、以下のようなケースもある。つまり、広告が認証されていないエージェントが、他のエージェントより信号強度で強ければ、広告が認証されているエージェントを抑えて、選択されるケースである。
【００３８】
ＭＮがＦＡ２からの広告を認証したと仮定する。もしＭＮがＡＡＡ＿ＦＡ２の公開鍵を持っていなくてＦＡ３からの広告を認証出来なければ、ＭＮはＦＡ２に登録するのがよりよいだろう。ＭＮがたまたまＡＡＡ＿ＦＡ２の公開鍵を持っているが、ＦＡ３からの広告を認証できない場合も同じようにするのがよい。しかしながら、上述したように、ＦＡ２かＦＡ３のエージェントどちらを選択すべきかは、完全にポリシー決定であり、他の要素を考慮にいれて決定すべきである。
【００３９】
ＭＮがＦＡ２からの広告を認証したと仮定する。またＭＮがＡＡＡ＿ＦＡ２の公開鍵を持っていて、ＦＡ３からの広告も認証するとする。ＦＡ２とＦＡ３は両方共、身元の正しさの点で利用できる。よって決定は、２つのエージェントの信号強度のような他の要素に基づくべきである。
【００４０】
ＭＮがＡＡＡ＿ＦＡ１やＡＡＡ＿ＦＡ２の公開鍵を持っていなくて、ＦＡ２とＦＡ３の両方の広告を認証できないとする。この時、現在行われているデータ通信の途絶を防ぐために、ＭＮは１つのエージェントを選択し、そこに登録を行うべきである。この決定は他の要素に基づくべきである。
【００４１】
（ステップ６４）
ＭＮが広告ＡＳＰFA2の認証に成功したので、ＦＡ２が選択されたとする（ステップ６３）。ＭＮはするとＦＡ２へ登録する。本発明の実施形態による登録プロセスは、基本的にＩＥＴＦの「モバイルＩＰ拡張、認証とアカウンティング要件」と題されたＲＦＣ２９７７と「ダイアメタモバイルＩＰ拡張（Ｄｉａｍｅｔｅｒ Ｍｏｂｉｌｅ ＩＰ Ｅｘｔｅｎｓｉｏｎｓ）」と題されたインターネットドラフト（ｄｒａｆｔ−ｃａｌｈｏｕｎ−ｄｉａｍｅｔｅｒ−ｍｏｂｉｌｅｉｐ−１２．ｔｘｔ）にしたがっている。これら２つの文書は参照として本明細書に組み込まれる。図７は、本発明の実施形態による登録プロセスを示すフローチャートであり、ここでは広告の正当性が確認されている。図７に示される様に、階層的に経路が形成されて、ダイアメタメッセージがこの階層的な経路を、ＭＮの登録を行うために送られる。上で仮定されたように、ＭＮとＦＡ２を除いて経路上のどの２つのエンティティもお互いに、安全に通信を行うためにセキュリティアソシエーションを確立しているか、必要な時に確立できる。このようなセキュリティアソシエーションは、例えば、手動でもしくは動的に分配された共通鍵や公開鍵を使用するなど、認証方法はどんなのでも良い。
【００４２】
既に述べた様に、ＭＮはＦＡ２からのエージェント広告を認証している。ＭＮは、次に登録要求（ＭＩＰ＿Ｒｅｇ＿Ｒｅｑｕｅｓｔ）をＦＡ２に送る（ステップ７１）。この要求には、ＭＮのホームアドレス、ＭＮのホームエージェント（ＨＡ）のアドレス、そしてＭＮの身元証明（例えば、ネットワークアクセス識別子：ＮＡＩ）が含まれている。ＦＡ２は、この要求をダイアメタメッセージ（Ｄｉａｍｅｔｅｒ Ｍｅｓｓａｇｅ）の形式に変更して、ローカル管理サーバＡＡＡ＿ＦＡ１に送信する（ステップ７２）。ＦＡ２からこの登録要求を受信するとすぐに、ＡＡＡ＿ＦＡ１はＭＮのホーム管理サーバを確定し、この登録要求をＡＡＡ＿ＨＡに転送する（ステップ７３）。ＡＡＡ＿ＨＡは、ＭＮの身元確認を行う。ＡＡＡ＿ＨＡがＭＮの身元を確認できなかったら、ＡＡＡ＿ＨＡはＡＡＡ＿ＦＡ１にエラーメッセージを返す。しかし、ＡＡＡ＿ＨＡがＭＮの身元を確認した場合は、ＡＡＡ＿ＨＡはＨＡにこの登録要求を送る（ステップ７４）。
【００４３】
ＨＡは、ＡＡＡ＿ＨＡから登録要求を受信するとすぐに、キャッシュ内にＭＮのバインディング情報を保存する。バインディング情報にはＭＮの現時点の接続点、すなわちＭＮの気付アドレスを含む。ＨＡは次に登録返答を作成し、ＡＡＡ＿ＨＡに送る（ステップ７５）。ＡＡＡ＿ＨＡは、登録返答をＡＡＡ＿ＦＡ１に転送する（ステップ７６）。ＡＡＡ＿ＦＡ１は、今度はこの登録返答をＦＡ２に転送する（ステップ７７）。ＡＡＡ＿ＦＡ１からの返答は、ＦＡ２にとって、ＭＮのネットワークアクセスがＦＡ２を介して認証されたと言うことを表している。ＦＡ２は、返答をＭＮに転送する（ステップ７８）。ＭＮが返答を受け取った時、登録プロセスが終わる。
【００４４】
（ステップ６５）
ステップ６３において、ＭＮがＡＡＡ＿ＦＡ２の公開鍵を持っていなくて広告ＡＳＰFA3を認証できないにもかかわらず、ＭＮはＦＡ３に登録すべきであると判定されたと仮定する。この場合、ＭＮは、ＦＡ３からのエージェント広告の認証をしようとせずに、図８に示された登録プロセスに従ってＦＡ３に登録する処理を行う。図８に示された登録プロセスには、図７で既に説明をした基本登録プロセスを含まれ、さらに、ＭＮがＡＡＡ＿ＦＡ２の公開鍵を取得する追加のプロセスが含まれている。基本登録プロセスの詳細を、繰り返して説明することは省略する。図８を参照して、追加の登録プロセスのみ説明する。
【００４５】
ＭＮは、ＡＡＡ＿ＦＡ２の証明書（ＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿Ｒｅｑｕｅｓｔ）を要求する要求を作成し、登録要求に付加する。ＭＮは次に、この要求をＦＡ３に送る（ステップ８１）。ステップ８２において、ＦＡ３は、ＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿Ｒｅｑｕｅｓｔを登録要求とともにＡＡＡ＿ＦＡ２に転送する。ＡＡＡ＿ＦＡ２は、ＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿ＲｅｑｕｅｓｔをＦＡ３から受信するとすぐに、自分の公開鍵（ＡＡＡ＿ＦＡ２’ｓＰｕｂ＿Ｋｅｙ）をＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿Ｒｅｑｕｅｓｔに入れて、ＡＡＡ＿ＨＡに登録要求とともに送る（ステップ８３）。ＡＡＡ＿ＨＡは、ＡＡＡ＿ＦＡ２の公開鍵が入っていて、ＡＡＡ＿ＨＡのプライベートキーで署名された証明書を作成する。ＡＡＡ＿ＨＡは、返答（ＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿Ｒｅｐｌｙ）を作成して、返答の中に証明書を入れる。ＡＡＡ＿ＨＡは、それから、ＨＡから登録返答を待つ。
【００４６】
ＡＡＡ＿ＨＡがＨＡから登録返答を受信したら、ＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿Ｒｅｐｌｙを登録返答に付加してＡＡＡ＿ＦＡ２に送る（ステップ８４）。ＡＡＡ＿ＦＡ２から、ＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿ＲｅｐｌｙがＦＡ３に転送され（ステップ８５）、ＭＮに送られる（ステップ８６）。ＭＮはＡＡＡ＿ＦＡ２＿Ｃｅｒｔ＿Ｒｅｐｌｙを受信するとすぐに、ＭＮはＡＡＡ＿ＨＡの公開鍵を使用して、この要求内にある証明書を復号化してＡＡＡ＿ＦＡ２の公開鍵を取り出す。ＭＮはＡＡＡ＿ＨＡによるドメインから発信しているので、ＭＮはＡＡＡ＿ＨＡの公開鍵をもっているはずである。ＭＮが証明書の復号化に成功したら、ＭＮはＡＡＡ＿ＦＡ２を信頼しその公開鍵を受け取っても良い、これはＡＡＡ＿ＦＡ２が、ＭＮが信頼するＡＡＡ＿ＨＡの公開鍵によって、ＭＮに本物であると認証されたからである。ＭＮはＡＡＡ＿ＦＡ２の公開鍵を、将来の使用の為にキャッシュの中に保存する。
【００４７】
ＭＮのキャッシュ内に保存されたＡＡＡ＿ＦＡ２の公開鍵は、生存期間があり、この生存期間が来たら無効になる。しかし、生存期間内では、公開鍵は再使用できる。このようなことが起こるのは、例えば、ＭＮがＡＡＡ＿ＦＡ２によるドメイン内に入った後、ＭＮが接続点を変更する移動をドメイン内で行った時、または、ＭＮがドメインを出たあと、またそのドメインに入った時である。このことが、ＭＮのキャッシュ内に保存されているＡＡＡ＿ＦＡ２の生存期間内に起これば、ＭＮは新しいエージェントからのエージェント広告をこの公開鍵を使用して復号化することができ、図７に示される登録プロセスに従って、新しいエージェントに登録することができる。
【００４８】
図９は、本発明の他の実施形態を示すフローチャートである。ステップ９１において、ＭＮは多数のフォーリンエージェントからエージェント広告を受信する。ＭＮはどの広告も認証できないと仮定する。言い換えると、周囲の管理ドメインは全て、ＭＮにとって初めてのものであり、ＭＮは周囲のドメイン内の管理サーバの公開鍵をどれも持っていない。進行中のデータ通信が中断するのを防ぐために、ＭＮは１つのフォーリンエージェントを選択して、それに登録を進めなければならない。この選択は、確実で信頼できるフォーリンエージェントが安定したエージェント広告を送信しているとの仮定に基づいている。「安定した」とは広告に含まれているパラメータが時間とともに変化しないと言う意味である。このパラメータには、気付アドレス、ＲＦＣ２００２によって規定されているソースアドレス、そして証明書や鍵などの本発明によって追加された識別子が含まれている。
【００４９】
信頼できるエージェントは同じエージェント広告を一貫して流し続けていて、悪意のあるエージェントは定期的にパラメータを変更したエージェント広告を送信し、できるだけ多くのモバイルノードをひきつけようをしている、と仮定する。このような悪意のあるエージェントを特定するために、ＭＮはエージェント広告をある期間受信して（ステップ９１）、受信した広告を、その中に含まれているパラメータの一貫性の順にグループに、ＭＮ内の並べ替え手段を使用して並べ替える（ステップ９２）。ステップ９３において、ＭＮは、最も一貫していると位置付けられた広告のグループを選択する。ＭＮは次に、そのグループの中から、信号強度が最高かパケット遅延の最低の広告を１つ選択する。これら２回の選択はＭＮ内の選択手段が行う。ステップ９４において、選択されたエージェント広告を送信していたエージェントに、ＭＮは、送信手段を使用して登録要求を送信して登録を試みる。ＭＮがそのエージェントに登録できなかった場合は（ステップ９５）、ＭＮは、そのグループ内の全てのエージェント広告を捨ててステップ９３に戻る。ステップ９３において、ＭＮは、第２番目に一貫していると位置付けられた広告のグループを選び、そのグループから、上述の方法と同じように、１つの広告を選択する。ステップ９４で、選択された広告のエージェントにＭＮは登録しようとする。ＭＮは、このプロセスを登録に成功するまで続ける。この方法では、ＭＮが悪意のあるエージェントに登録しようとするのを防ぐ事はないが、登録試行が失敗に終わる回数を減らすことが期待できる。
【００５０】
本発明の好適な実施形態を説明したが、以上の説明は例示のためであり、本発明を限定しようとするためのものではない。当業者であれば、発明の新規性と有利な特徴を保ちながら、発明の精神から逸脱せずに変更や追加ができることを理解できるであろう。以上から、本発明の範囲は、正しく理解された特許請求の範囲のみによって決まる。
【００５１】
【発明の効果】
以上説明したように、本発明によれば、ネットワークへのアクセスを安全に素早く行うことができる。
【図面の簡単な説明】
【図１】 本発明の用途として意図している第３世代無線モバイルアクセスＩＰネットワークを例示している図である。
【図２】 第３世代無線モバイルアクセスデータネットワークにおけるモバイルノードのハンドオフのプロセスを簡単に示した図である。
【図３】 ＡＡＡプロトコルに基づいた本発明による第３世代無線モバイルアクセスデータネットワークを簡単に示した図である。
【図４】 図３に示されたネットワーク内の内在しているセキュリティモデルの図であり、破線はネットワーク内に仮定されているセキュリティアソシエーションである。
【図５】 本発明で使用されるモバイルＩＰ広告を示す図である。
【図６】 本発明の実施例によるエージェント認証プロセスを示すフローチャートである。
【図７】 本発明による登録プロセスを示すフローチャートであり、ここではモバイルノードがエージェントからの広告を認証している。
【図８】 本発明による登録プロセスを示すフローチャートであり、ここではモバイルノードがエージェントからの広告を認証していない。
【図９】 本発明によるエージェントを選択するプロセスを示すフローチャートであり、ここではモバイルノードが近隣のエージェントを認証できない。
【符号の説明】
１００・・・無線モバイルアクセスＩＰネットワーク、１２０・・・コアネットワーク、１３０・・・ゲートルータ、１３５・・・モバイルノード、１４０・・・ＩＰモバイルバックボーン、１４５・・・サーバ、１５０・・・基地局ネットワーク、ＭＮ・・・モバイルノード、ＨＡ・・・ホームエージェント、ＦＡ１、ＦＡ２、ＦＡ３・・・フォーリンエージェント、ＡＡＡ＿ＨＡ・・・ホーム管理サーバ、ＡＡＡ＿ＦＡ１、ＡＡＡ＿ＦＡ２・・・フォーリン管理サーバ。
Claims (21)
- 少なくとも１つの管理サーバによりサービスが提供されるドメイン内に属する通信端末であって、
ネットワークへのアクセスを提供するモビリティエージェントから、広告メッセージを受信する受信部と、
信頼されたエンティティによって認証された広告メッセージを認証する手段と、
前記受信部にて受信した複数の広告メッセージのいずれについても認証に失敗した場合、所定の期間に前記受信部にて蓄積された複数の広告メッセージの属性に基づき、当該広告メッセージの送信元である複数のモビリティエージェントから選択すべき一のモビリティエージェントを決定する手段と、
該決定した一のモビリティエージェントに対して登録処理を行う登録手段と、
を有することを特徴とする通信端末。 - 前記所定期間に蓄積された複数の広告メッセージを各広告メッセージの属性に基づいてグループに区分する手段と、
前記属性に基づき、該区分されたグループのうち１つのグループを選択する第１選択手段と、
該選択されたグループにおいて１つの広告メッセージを選択する第２選択手段と、
を有し、
前記登録手段は、前記選択された広告メッセージの送信元のモビリティエージェントを特定して登録要求を送信する
ことを特徴とする請求項１に記載の通信端末。 - 前記広告メッセージの属性は、当該広告メッセージに内包されたパラメータの一貫性を表す指標を含む
ことを特徴とする請求項１に記載の通信端末。 - 前記登録手段は、当該登録処理に失敗した場合、該選択されたグループを廃棄し、前記第１選択手段および前記第２選択手段を用いて、他の一のモビリティエージェントを選択する
ことを特徴とする請求項２に記載の通信端末。 - 前記第１選択手段は、より高い一貫性をもつグループを優先的に選択する
ことを特徴とする請求項２に記載の通信端末。 - 前記第２選択手段は、前記広告メッセージの送信元のモビリティエージェントの接続性に基づいて選択を行う
ことを特徴とする請求項２に記載の通信端末。 - 前記登録手段は、該決定したモビリティエージェントに対して登録を行う際、信頼された管理サーバの公開鍵を有する証明書を要求する手段を有する
ことを特徴とする請求項１に記載の通信端末。 - 前記信頼されている管理サーバの公開鍵は、第２の信頼されている管理サーバによって署名された証明書に含まれている
ことを特徴とする請求項７に記載の通信端末。 - 前記第２の信頼されている管理サーバは、前記通信端末の認証に関し全ての責任を有している管理サーバである
ことを特徴とする請求項８に記載の通信端末。 - 前記第２の信頼されている管理サーバは、前記通信端末が発信をする管理ドメインにサービスを提供している管理サーバである
ことを特徴とする請求項９に記載の通信端末。 - モビリティエージェントを少なくとも１つ有する管理ドメインを形成する管理サーバを含む通信ネットワーク内において、通信端末が接続地点を一のモビリティエージェントから他のモビリティエージェントに変更した場合に実施される登録プロセスであって、
モビリティエージェントが、信頼されたエンティティが認証した広告メッセージによって接続を提供する過程と、
前記通信端末が、広告メッセージを受信して認証する過程と、
前記通信端末が、受信した複数の広告メッセージのいずれについても認証に失敗した場合、所定の期間に受信した複数の広告メッセージの属性に基づき、当該広告メッセージの送信元である複数のモビリティエージェントから選択すべき一のモビリティエージェントを決定する過程と、
前記通信端末が、該決定した一のモビリティエージェントに対して登録処理を行う登録過程と、
を有することを特徴とする登録プロセス。 - 前記広告メッセージは、当該広告メッセージを送信している前記モビリティエージェントのプライベートキーによって署名されていて、前記広告メッセージを送信している前記モビリティエージェントの公開鍵を持ち、前記信頼された管理サーバのプライベートキーによって署名されている証明書を同封している
ことを特徴とする請求項１１に記載の登録プロセス。 - 前記所定期間に受信した広告メッセージを当該メッセージの属性に基づいてグループに区分する過程と、
前記属性に基づき、該区分されたグループから１つのグループを選択する第１選択過程と、
該選択されたグループにおいて１つの広告メッセージを選択する第２選択過程と、
を更に有し、
前記登録過程において、該選択された広告メッセージの送信元であるモビリティエージェントを特定して登録要求を送信する
ことを特徴とする請求項１１に記載の登録プロセス。 - 前記広告メッセージの属性は、当該メッセージに内包されるパラメータの一貫性を表す指標である
ことを特徴とする請求項１１に記載の登録プロセス。 - 前記登録過程において前記登録処理に失敗した場合、前記第１選択過程において選択されたグループを廃棄するとともに他の一のモビリティエージェントを選択する
ことを特徴とする請求項１３に記載の登録プロセス。 - 前記第１選択過程において、より高い一貫性をもつグループが優先的に選択される
ことを特徴とする請求項１３に記載の登録プロセス。 - 前記第２選択過程において、前記広告メッセージの送信元であるモビリティエージェントの接続性に基づいて選択を行う
ことを特徴とする請求項１３に記載の登録プロセス。 - 前記登録過程において、該決定したモビリティエージェントに登録を行う際、信頼された管理サーバの公開鍵を有する証明書を要求する
ことを特徴とする請求項１１に記載の登録プロセス。 - 前記信頼されている管理サーバの公開鍵は、第２の信頼されている管理サーバによって署名された証明書に含まれている
ことを特徴とする請求項１８に記載の登録プロセス。 - 前記第２の信頼されている管理サーバは、前記通信端末の認証に関し全ての責任を有している管理サーバである
ことを特徴とする請求項１９に記載の登録プロセス。 - 前記第２の信頼されている管理サーバは、前記通信端末が発信をする管理ドメインにサービスを提供している管理サーバである
ことを特徴とする請求項２０に記載の登録プロセス。
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US33239601P | 2001-11-09 | 2001-11-09 | |
| US60/332396 | 2001-11-09 | ||
| US10/146,548 US7577425B2 (en) | 2001-11-09 | 2002-05-15 | Method for securing access to mobile IP network |
| US10/146548 | 2002-05-15 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003234740A JP2003234740A (ja) | 2003-08-22 |
| JP3831331B2 true JP3831331B2 (ja) | 2006-10-11 |
Family
ID=27791282
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002325168A Expired - Fee Related JP3831331B2 (ja) | 2001-11-09 | 2002-11-08 | モバイルｉｐネットワークへのアクセスを安全にする方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3831331B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108259527A (zh) * | 2016-12-28 | 2018-07-06 | 华为技术有限公司 | 基于代理的业务处理方法、装置及网元设备 |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7286671B2 (en) | 2001-11-09 | 2007-10-23 | Ntt Docomo Inc. | Secure network access method |
| WO2005091666A1 (ja) * | 2004-03-17 | 2005-09-29 | Ip Talk Corporation | 無線通信端末及び無線通信方法 |
| FI20050491A0 (fi) * | 2005-05-09 | 2005-05-09 | Nokia Corp | Järjestelmä varmenteiden toimittamiseksi viestintäjärjestelmässä |
| WO2008035492A1 (fr) * | 2006-09-19 | 2008-03-27 | Nec Corporation | routeur d'accès, serveur dhcp, système d'envoi de publicité de routeur, et son procédé, routeur d'ancrage et programme |
| JP2008211446A (ja) * | 2007-02-26 | 2008-09-11 | Nippon Telegr & Teleph Corp <Ntt> | 通信システムおよび通信方法 |
| US8533455B2 (en) * | 2007-05-30 | 2013-09-10 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for combining internet protocol authentication and mobility signaling |
| US8413243B2 (en) * | 2008-02-08 | 2013-04-02 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for use in a communications network |
| CN101286844B (zh) | 2008-05-29 | 2010-05-12 | 西安西电捷通无线网络通信有限公司 | 一种支持快速切换的实体双向鉴别方法 |
| CN103312670A (zh) | 2012-03-12 | 2013-09-18 | 西安西电捷通无线网络通信股份有限公司 | 一种认证方法及系统 |
| CN103312499B (zh) | 2012-03-12 | 2018-07-03 | 西安西电捷通无线网络通信股份有限公司 | 一种身份认证方法及系统 |
-
2002
- 2002-11-08 JP JP2002325168A patent/JP3831331B2/ja not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108259527A (zh) * | 2016-12-28 | 2018-07-06 | 华为技术有限公司 | 基于代理的业务处理方法、装置及网元设备 |
| US11019508B2 (en) | 2016-12-28 | 2021-05-25 | Huawei Technologies Co., Ltd. | Proxy-based service processing method and apparatus, and network element device |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003234740A (ja) | 2003-08-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7577425B2 (en) | Method for securing access to mobile IP network | |
| US10069803B2 (en) | Method for secure network based route optimization in mobile networks | |
| JP5503620B2 (ja) | 通信システムおよびアクセスネットワーク情報転送マネージャ | |
| US7286671B2 (en) | Secure network access method | |
| US20020147820A1 (en) | Method for implementing IP security in mobile IP networks | |
| CN104080084B (zh) | 运行并行pana会话的方法以及系统 | |
| US8442006B2 (en) | Wireless LAN mobility | |
| WO2007052904A1 (en) | Method and apparatus for supporting fast mobility ip with link identifier prefix in wireless communication system | |
| US7187931B2 (en) | Handover of mobile node to a new access router | |
| JP3831331B2 (ja) | モバイルｉｐネットワークへのアクセスを安全にする方法 | |
| US8619701B2 (en) | Method of facilitating handoff for CDMA networks using IP protocols | |
| KR100737140B1 (ko) | 이동통신에서의 인터넷 프로토콜 가상 사설망 서비스처리장치 및 방법 | |
| Vogt | A comprehensive and efficient handoff procedure for IPv6 mobility support | |
| Arkko et al. | Quick NAP-secure and efficient network access protocol | |
| KR101291190B1 (ko) | 2 네트워크 서비스 공급자들간 네트워크 자원을 공유하는방법 | |
| Ma et al. | Role of mobile IPv6 for mobile networks and its remaining issues | |
| Chen et al. | Secure, QoS-enabled Mobility Support in All-IP Networks | |
| Bor | UNIFIED LOCAL, MOEILITY MIAN AGEN/IENT | |
| Rónai et al. | IST-2001-35125 (OverDRiVE) D07 | |
| Komarova et al. | Secure User’s Mobility: the current situation | |
| Zhang | End to end architecture and mechanisms for mobile and wireless communications in the Internet | |
| Komarova et al. | Wireless Network Architecture to Support Mobile Users. | |
| Goswami | IP and Mobility | |
| Banh | Quantification, characterisation and impact evaluation of mobile IPv6 hand off times | |
| Ghebretensaé et al. | Solution for session continuity between heterogeneous networks including FWA access capability in a single operator scenario |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050916 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051025 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20051130 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060125 |
|
| 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: 20060711 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060713 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090721 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100721 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110721 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110721 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120721 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120721 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130721 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| 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 |