(57)【特許請求の範囲】
【請求項１】
モバイルクライアントが、自身の身元証明書を含む請求メッセージを送信する送信ステップと、
信用できる実体が、前記身元証明書を確認する確認ステップと、
前記身元証明書が正常に確認された場合のみ、アクセスルータが通知メッセージを返信する返信ステップと、
を具備することを特徴とする認証過程。
【請求項２】
前記信用できる実体が、前記モバイルクライアントと前記信用できる実体との間に位置するアクセスルータを、前記モバイルクライアントに対し認証することを特徴とする請求項１に記載の認証過程。
【請求項３】
各々少なくとも１の管理サーバにより管理され、各々少なくとも１のアクセスルータを備えた複数の管理ドメインを有する通信ネットワークにおいて、前記送信ステップ、前記確認ステップ、および前記返信ステップを行うことを特徴とする請求項１に記載の認証過程。
【請求項４】
前記信用できる実体が、前記モバイルクライアントが属するホームドメインを管理するサーバであることを特徴とする請求項３に記載の認証過程。
【請求項５】
前記信用できる実体が、前記モバイルクライアントが訪問するフォーリンドメインを管理するサーバであることを特徴とする請求項３に記載の認証過程。
【請求項６】
前記信用できる実体は、前記モバイルクライアントから前記請求メッセージを受信するアクセスルータであることを特徴とする請求項３に記載の認証過程。
【請求項７】
前記通知メッセージは、前記モバイルクライアントが前記アクセスルータを認証するための、前記アクセスルータの身元証明書を含むことを特徴とする請求項１に記載の認証過程。
【請求項８】
モビリティサービングノードが、前記アクセスルータの前記身元証明書を含む通知メッセージを自発的に送信するステップと、
前記モバイルクライアントが、前記身元証明書を確認するステップと、
前記モバイルクライアントが前記身元証明書を確認できない場合、前記送信ステップ、前記確認ステップ、および前記返信ステップを行うステップと、
を具備することを特徴とする請求項１に記載の認証過程。
【請求項９】
前記モバイルクライアントが前記アクセスルータと通信中、前記送信ステップ、前記確認ステップ、および前記返信ステップを行い、前記モバイルクライアントに対し前記アクセスルータを再認証し、
前記アクセスルータからの前記通知メッセージが、前記アクセスルータの前記身元証明書を含むことを特徴とする請求項１に記載の認証過程。
【請求項１０】
前記モバイルクライアントと通信中に、前記アクセスルータは、前記送信ステップ、前記確認ステップ、および前記返信ステップの実行を開始するため有効期間があらかじめ決められた基準値より短い通知メッセージを送信し、前記アクセスルータに対し前記モバイルクライアントを再認証することを特徴とする請求項１に記載の認証過程。
【請求項１１】
データ通信には、ＩＰｖ４が用いられることを特徴とする請求項１に記載の認証過程。
【請求項１２】
データ通信には、ＩＰｖ６が用いられることを特徴とする請求項１に記載の認証過程。
【請求項１３】
非対称鍵アルゴリズムを用いて、前記確認が行われることを特徴とする請求項１に記載の認証過程。
【請求項１４】
対称鍵アルゴリズムを用いて、前記確認が行われることを特徴とする請求項１に記載の認証過程。
【請求項１５】
少なくとも前記請求メッセージおよび前記通知メッセージのうちいずれか１は、チャレンジを含むことを特徴とする請求項１に記載の認証過程。
【請求項１６】
モバイルクライアントの身元証明書を含む請求メッセージを送信する送信部と、
アクセスルータから通知メッセージを受信する受信部と、
を具備し、
前記身元証明書が正常に確認された場合のみ、前記モバイルクライアントは前記通知メッセージを受信することを特徴とするモバイルクライアント。
【請求項１７】
前記通知メッセージは、前記アクセスルータの身元証明書を含み、
前記モバイルクライアントは、前記身元証明書を確認する機能を有することを特徴とする請求項１６に記載のモバイルクライアント。
【請求項１８】
前記モバイルクライアントが前記アクセスルータと通信中、前記送信部は前記アクセスルータに対し前記請求メッセージを送信し、前記アクセスルータを再認証することを特徴とする請求項１６に記載のモバイルクライアント。
【請求項１９】
データ通信には、ＩＰｖ４が用いられることを特徴とする請求項１６に記載のモバイルクライアント。
【請求項２０】
データ通信には、ＩＰｖ６が用いられることを特徴とする請求項１６に記載のモバイルクライアント。
【請求項２１】
非対称鍵アルゴリズムを用いて、前記確認が行われることを特徴とする請求項１６に記載のモバイルクライアント。
【請求項２２】
対称鍵アルゴリズムを用いて、前記確認が行われることを特徴とする請求項１６に記載のモバイルクライアント。
【請求項２３】
少なくとも前記請求メッセージおよび前記通知メッセージのうちいずれか１は、チャレンジを含むことを特徴とする請求項１６に記載のモバイルクライアント。
【請求項２４】
各々少なくとも１つの管理サーバにより管理され、各々少なくとも１つのアクセスルータを備えた複数の管理ドメインを有するＡＡＡネットワークであって、
自身の身元証明書を含む請求メッセージを送信するモバイルクライアントと、
前記身元証明書を確認する信用できる実体と、
前記身元証明書が正常に確認された場合のみ、通知メッセージを返信するアクセスルータと、
を具備することを特徴とするＡＡＡネットワーク。
【請求項２５】
前記信用できる実体が、前記モバイルクライアントと前記信用できる実体との間に位置するアクセスルータを、前記モバイルクライアントに対し認証することを特徴とする請求項２４に記載のＡＡＡネットワーク。
【請求項２６】
前記信用できる実体が、前記モバイルクライアントが属するホームドメインを管理するサーバであることを特徴とする請求項２４に記載のＡＡＡネットワーク。
【請求項２７】
前記信用できる実体が、前記モバイルクライアントが訪問するフォーリンドメインを管理するサーバであることを特徴とする請求項２４に記載のＡＡＡネットワーク。
【請求項２８】
前記信用できる実体は、前記モバイルクライアントから前記請求メッセージを受信するアクセスルータであることを特徴とする請求項２４に記載のＡＡＡネットワーク。
【請求項２９】
前記通知メッセージは、前記モバイルクライアントが前記アクセスルータを認証するための、前記アクセスルータの身元証明書を含むことを特徴とする請求項２４に記載のＡＡＡネットワーク。
【請求項３０】
前記アクセスルータは、自身の身元証明書を含む通知メッセージを自発的に送信し、
前記モバイルクライアントは前記身元証明書を確認できない場合、前記請求メッセージを送信することを特徴とする請求項２４に記載のＡＡＡネットワーク。
【請求項３１】
前記アクセスルータと通信中、前記モバイルクライアントは前記請求メッセージを送信し、
前記アクセスルータは、前記モバイルクライアントが前記アクセスルータを認証するための、自身の身元証明書を含む通知メッセージを送信することを特徴とする請求項２４に記載のＡＡＡネットワーク。
【請求項３２】
前記モバイルクライアントと通信中に、前記アクセスルータは有効期間があらかじめ決められた基準値より短い通知メッセージを送信し、前記モバイルクライアントに前記請求メッセージを送信させることを特徴とする請求項２４に記載のＡＡＡネットワーク。
【請求項３３】
データ通信には、ＩＰｖ４が用いられることを特徴とする請求項２４に記載のＡＡＡネットワーク。
【請求項３４】
データ通信には、ＩＰｖ６が用いられることを特徴とする請求項２４に記載のＡＡＡネットワーク。
【請求項３５】
非対称鍵アルゴリズムを用いて、前記確認が行われることを特徴とする請求項２４に記載のＡＡＡネットワーク。
【請求項３６】
対称鍵アルゴリズムを用いて、前記確認が行われることを特徴とする請求項２４に記載のＡＡＡネットワーク。
【請求項３７】
少なくとも前記請求メッセージおよび前記通知メッセージのうちいずれか１は、チャレンジを含むことを特徴とする請求項２４に記載のＡＡＡネットワーク。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本出願は、２００１年１１月９日に提出された「ルータ検出およびＡＡＡを用いた安全なネットワークアクセス（Ｓｅｃｕｒｅ  Ｎｅｔｗｏｒｋ  Ａｃｃｅｓｓ  Ｕｓｉｎｇ  Ｒｏｕｔｅｒ  Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  ＡＡＡ）」と題する米国仮出願６０／３４５、９６７に関して優先権を主張する。なお、この仮出願は、本明細書において参照として援用される。
また、本出願では、２００２年５月１５日に提出された「モバイルＩＰネットワークへのアクセスを安全にする方法（ＭＥＴＨＯＤ  ＦＯＲ  ＳＥＣＵＲＩＮＧ  ＡＣＣＥＳＳ  ＴＯ  ＭＯＢＩＬＥ  ＩＰ  ＮＥＴＷＯＲＫ）」と題する米国出願１０／１４６、５４８、および２００１年１１月９日に提出された「モバイルＩＰ登録（ＭＯＢＩＬＥ  ＩＰ  ＲＥＧＩＳＴＲＡＴＩＯＮ）」と題する米国仮出願６０／３３２、３９６が、相互に参照される。なお、これらの出願は、本明細書において参照として援用される。
本発明は、クライアントがネットワークにアクセスする接続サービスを要求する場合、およびルータがネットワーク接続を提供する場合に、クライアントおよびアクセスルータを相互に認証する双方向セキュリティプロトコルに関する。本発明にかかるセキュリティプロトコルは、ＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（認証）、Ａｕｔｈｏｒｉｚａｔｉｏｎ（認可）  ａｎｄ  Ａｃｃｏｕｎｔｉｎｇ（課金））に基づき、その実行において、ルータ検出（Ｒｏｕｔｅｒ  Ｄｉｓｃｏｖｅｒｙ）がキャリアとして用いられる。
【０００２】
【従来の技術】
携帯電話機、ＰＤＡ（ｐｅｒｓｏｎａｌ  ｄｉｇｉｔａｌ  ａｓｓｉｓｔａｎｔ）等の全世界的にルーティング可能なＩＰ対応装置の普及とともに、公開アクセスＩＰネットワークが広く張りめぐらされている。とりわけ、近年の携帯無線技術の進歩および携帯電話システムの成長率は、場所に拘束されない通信に対する、市場の巨大な需要を示している。無線通信の役割は、ごく数年前の従来の音声および呼び出しモバイル無線サービスを大幅に越えた。最近、ネットワークの世界標準規格に関する公認の機関である国際電気通信連合（ＩＴＵ）は、国際移動通信規格（ＩＭＴ−２０００）を発表した。この標準規格では、携帯電話機、ＰＤＡ、携帯型コンピュータ等の無線モバイルクライアントによる広範囲なモバイルアクセスを可能にするいわゆる第３世代（３Ｇ）ネットワークを提案している。この第３世代ネットワークでは、モバイルクライアント、または移動クライアントはネットワーク資源へのアクセスを維持しながら自由に移動し、接続ポイントをある基地局から別の基地局へ変更することができる。３Ｇネットワークには、リンク層（レイヤ２）におけるモビリティを提供するものがある。しかし、将来のネットワーク（いわゆる４Ｇ）は、ＩＰ層（レイヤ３）におけるモビリティを提供すると予想されている。
【０００３】
インターネットアーキテクチャの進化およびインターネットの円滑な運用に関わる、ネットワークの設計者、運用者、供給業者、研究者からなる国際団体であるインターネット技術特別調査委員会（ＩＥＴＦ）は、ＩＰ層におけるモビリティ支援のための標準規格をいくつか提案している。これら提案された標準規格には、ＩＥＴＦのＲＦＣ２００２（別名、モバイルＩＰバージョン４（ＩＰｖ４））や「ＩＰｖ６におけるモビリティ支援」と題された草案「ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｉｐｖ６−１７」（別名、モバイルＩＰバージョン６）のようなモビリティ支援のための標準規格がある。この２つの標準規格は、本願明細書において参照として援用される。ＩＰｖ４およびＩＰｖ６で定義されるプロトコル運用によると、クライアントは、ネットワーク資源へのアクセスを維持しながらネットワーク上を移動し、接続ポイントをあるアクセスルータから別のアクセスルータへ変更することが可能になる。通常、この処理は、「レイヤ３（Ｌ３）ハンドオフ」と呼ばれる。
【０００４】
Ｌ３ハンドオフ処理をおこなう目的は、登録処理をつうじて移動クライアントのパケットルーティング情報を更新することである。クライアントは、「ホームアドレス」により、常に指定することができる。ここで、「ホームアドレス」とは、ホームネットワーク上のアクセスルータ（ホームルータ）により割り当てられるＩＰアドレス、またはクライアント自身により選択されたＩＰアドレスのことである。しかしながら、クライアントがフォーリンネットワーク上にあってホームネットワークから離れている場合、クライアントには、現在のネットワークへの接続ポイントを示す気付けアドレスが設定される。この気付けアドレスは、フォーリンネットワーク上のアクセスルータ（フォーリンルータ）のアドレスであり、ホームネットワークから離れて動作するクライアントは、この気付けアドレスをホームルータに登録する。そして、登録要求を受信したホームルータは、クライアント宛のパケットを途中で回収し、クライアントの気付けアドレスへ転送する。モバイルＩＰｖ６では、ホームネットワークから離れたクライアントは、ホームルータおよび通信中の相手先ノードに対し対応更新（ｂｉｎｄｉｎｇ  ｕｐｄａｔｅ）を送信する。相手先ノードは、クライアントのようなモバイルクライアントであってもよいし、クライアントにデータを提供するサーバであってもよい。そして、対応更新を受信した相手先ノードは、ホームルータを介さずクライアントに対しパケットを直接転送する。
【０００５】
【発明が解決しようとする課題】
移動クライアントが、訪問したネットワークにおいてネットワーク接続を要求する場合、セキュリティ上の重大な問題が生じる。クライアントは、ネットワークアクセスが許可される前に、常に認証されなければならない。認証されないクライアントは、不正ＩＤまたは盗難ＩＤを用いて無料でネットワーク資源にアクセスしようとする不正利用者かもしれない。また、そのようなクライアントは、ネットワークの秩序ある運用を乱すためだけに、ネットワークアクセスを要求する悪意をもったノードかもしれない。同様に、クライアントは、自己にネットワーク接続を提供しているアクセスルータを認証したいと思うかもしれない。アクセスルータは、クライアントの通信を盗聴したり、どこかへ転送したり、ただ中断するだけの不正なルータかもしれない。現在、さまざまなアクセス技術で、数多くの認証メカニズムが実行、採用されている。例として、ＰＰＰおよび８０２．１１ネットワークの認証がある。これらのネットワークを利用する場合、リンク層で認証メカニズムが提供されるため、その認証メカニズムの適用範囲が特定のアクセス技術に限られてしまう、という欠点があった。従って、アクセス技術を選ばない認証メカニズムの提供が求められている。
【０００６】
【課題を解決するための手段】
上記の事情に鑑み、本発明は、ネットワーク層における認証メカニズムを用いることにより、アクセス技術を選ばない安全なネットワークアクセス方法を提供する。本発明は、モバイルクライアントにネットワークアクセスを許可する前に、モバイルクライアントおよびアクセスルータを互いに認証するネットワーク層プロトコルを提供する。本発明は、ルータ検出をキャリアとして用い、認証プロトコルを実行する。本発明の実施形態において、モバイルクライアントは、請求メッセージを送信し、接続サービスを要求する。この請求メッセージは、モバイルクライアントの身元証明書を含んでいる。この請求メッセージを受信したアクセスルータは、身元証明書が確認されるまでこの請求メッセージに対し応答しない。モバイルクライアントの身元証明書が確認されてはじめて、アクセスルータは応答し、モバイルクライアントに対し通知メッセージを返信する。従って、不正なモバイルクライアントのネットワークアクセスを防止できる。
【０００７】
アクセスルータからの通知メッセージは、アクセスルータの身元証明書を含んでいてもよい。このアクセスルータの身元証明書が正常に確認された場合のみ、モバイルクライアントは、このアクセスルータを介してネットワークアクセスを開始する。従って、モバイルクライアントが不正なアクセスルータを介してネットワークアクセスを開始してしまうことを防止できる。
【０００８】
請求および通知メッセージを用いることにより、ネットワークアクセスを安全にする上での利点が得られる。検出メカニズムは、モバイルクライアントとアクセスルータとがオフリンク接続を確立する際の第一歩である。すなわち、検出メカニズムを用いてモバイルクライアントおよびアクセスルータを認証することは、既存のプロトコルにとって無理のない拡張である。モバイルクライアントおよびアクセスルータの認証に検出メカニズムを用いることにより、プロトコル信号数を大幅に節約できる。プロトコル信号数の節約は、通信資源が貴重かつ高価であるモバイル無線ネットワークにとって重要である。検出メカニズムを用いるさらなる利点は、検出メカニズムがＩＰｖ４およびＩＰｖ６両方に共通であることである。従って、検出メカニズムをキャリアとして用い、モバイルクライアントおよびアクセスルータの認証を実行する本発明は、ネットワークがＩＰｖ４とＩＰｖ６とのいずれを用いるかにかかわらず、ネットワークにおいて実行可能である。
【０００９】
本発明にかかる認証プロトコルは、ＡＡＡインフラストラクチャに基づいて、ＡＡＡプロトコルにより提供される認証サービスおよびプロトコル信号を用いてもよい。ＡＡＡプロトコルにおいては、複数のドメインが定められ、各ドメインは少なくとも１つのＡＡＡサーバにより管理される。ＡＡＡサーバは、アテンダント、すなわちアクセスルータを介してモバイルクライアントに対しＡＡＡサービスを提供する。本発明では、請求メッセージに含まれるクライアントの身元証明書を確認するために、信用できる実体が必要である。クライアントが新たなフォーリンドメインに入った場合、信用できる実体は、クライアントのホームドメインを管理するＡＡＡサーバである。従って、この最初の認証過程のためにプロトコル信号がクライアントとホームサーバとの間を往復するため、通信の待ち時間を生じるかもしれない。しかしながら、クライアントがフォーリンドメインにとどまっている限りにおいて、ホームサーバは確認のために用いられない。例えば、クライアントがフォーリンドメイン内でアクセスルータを切り替えた場合は、このフォーリンドメインのサーバが信用できる実体になる。クライアントが同一のアクセスルータに接続を要求する場合、そのアクセスルータでさえも信用できる実体になってもよい。従って、本発明にかかる認証プロトコルに必要なプロトコル信号は、より短い距離を往復することにより、認証プロセスにより生じる通信の遅延が短縮化される。
【００１０】
本発明にかかる認証プロトコルは、対称および非対称鍵暗号方式等のいかなる鍵アルゴリズムを用いても実行可能である。これらの鍵は、本発明の認証過程に伴うプロトコル信号とともに配信されてもよい。これらの鍵が配信されることにより、２つの実体間に新たなセキュリティ関係が確立され、アドレス解決（ＡＲＰ／ＲＡＲＰ）等の近隣検出や実体間の以後の通信のためのプロトコル信号を安全にする。
【００１１】
本発明の別の実施形態においては、アクセスルータは、自らの身元証明書を含む通知メッセージを自発的に送信してもよい。この身元証明書を正常に確認した場合、クライアントは、このアクセスルータをインターネットへのゲートウェイとして使用する。この証明を確認できない場合には、自らの身元証明書を含む請求メッセージを送信することにより、認証過程を開始する。この請求メッセージは、上記で概説したように処理される。
【００１２】
本発明の別の実施形態においては、クライアントは、アクセスルータと通信中に、このアクセスルータに対し請求メッセージを送信してもよい。通信中でさえも、正当な実体が不正な実体と入れ替わる可能性は常にある。この請求メッセージを受けて、アクセスルータが自らの身元証明書を含む通知メッセージを送信し、よって、クライアントは通信中にアクセスルータを再認証できる。同様に、アクセスルータは、通信中のクライアントに対し有効期間の短い通知メッセージを送信してもよい。この通知メッセージに対し、クライアントは自らの身元証明書を含む請求メッセージを送信し、よって、アクセスルータはクライアントを再認証できる。
【００１３】
クライアントからの請求メッセージおよび／またはアクセスルータからの通知メッセージがチャレンジを含み、リプレイ攻撃から防御してもよい。
【００１４】
【発明の実施の形態】
ここで、本発明の好適な実施形態を図面を参照しつつ説明する。この図面において、同様の構成要素には同一の参照符号が付される。本明細書に記載されている実施形態は、性質上、例示的なものすぎず、本発明の範囲を限定するものではない。なお、本実施形態中に記載のネットワークでは、モバイルＩＰが用いられているが、本発明は、より広く、ＩＰｖ４およびＩＰｖ６等のいかなるＩＰベースの通信プロトコルを用いても実行可能である。
【００１５】
図１に、本発明が適用される第３世代の無線モバイルアクセスＩＰに対応したデータ通信ネットワーク１００を示す。本明細書の目的のため、データ通信ネットワーク１００は、無線移動体通信ネットワークに関するＩＭＴ−２０００規格およびＩＴＵの仕様に従うものとする。さらに、データ通信ネットワーク１００は、ＩＥＴＦで提案されているモバイルＩＰｖ４およびモバイルＩＰｖ６規格に従い、モバイルＩＰ支援を実行するものとする。したがって、勿論、本願では、一方のバージョンに特有の用語を他方のバージョンの対応する用語に置き換えて使用してもよい。例えば、「エージェント」という用語は、「アクセスルータ」や、単に「ルータ」という用語に置き換えて使用してもよい。同様に、「エージェント検出」は、「ルータ検出」と、「エージェント請求」は、「ルータ請求」と、「登録要求」は、「対応更新」と、それぞれ置き換えて使用してもよい。
【００１６】
無線モバイルアクセスＩＰに対応したデータ通信ネットワーク１００の中心には、多数の図示せぬ固定ノード、すなわち固定接続ポイントまたはリンクを有する固定ノードＩＰデータネットワークであるコアネットワーク１２０が備えられている。この通信ネットワーク内またはこの通信ネットワークを介し、また、インターネットプロトコルバージョン６（ＩＰｖ６）に従い、デジタルデータの送受信がなされる。上述したように、ＩＰｖ６は通信プロトコルのほんの一例でありＩＰｖ４等の通信プロトコルと置き換えることが可能である。コアネットワーク１２０のいくつかのノードは、図示せぬ従来のルータを有し、このルータは、従来のインターネットアドレッシングおよびルーティングプロトコルに従って中間ノードとして機能し、ネットワークに接続された送信元および送信先ノード間でデータパケットを転送する。
【００１７】
コアネットワーク１２０には、複数のゲートウェイルータ（ＧＲ）１３０が備えられており、これらがＩＰモバイルバックボーンを構成している。このＩＰモバイルバックボーンを構成するゲートウェイルータ１３０は、それ自体がコアネットワーク１２０のノードであり、コアネットワーク１２０を介して相互接続されている。各ゲートウェイ１３０には、モバイルクライアント１３５と通信可能な複数のアクセスルータ１４５が接続されている。このモバイルクライアントとしては、コードレス電話機、携帯電話機、携帯型コンピュータ、個人情報管理機器等の種類の異なるモバイル無線通信装置が利用可能である。アクセスルータ１４５は、ホームルータ（ＨＲ）およびフォーリンルータ（ＦＲ）として機能し、ゲートウェイルータ１３０を介してクライアント１３５をコアネットワーク１２０に接続する。アクセスルータ１４５は、アクセスネットワークのレイヤ３上の実体である。クライアント１３５は、無線アクセスポイント（ＡＰ）１５５を介してアクセスルータ１４５と通信する。このＡＰ１５５は、アクセスネットワークのレイヤ２上の実体である。一群のＡＰ１５５は、図１のサブネットワーク１５０を構成している。各アクセスルータ１４５は、サブネットワーク１５０を管理し、サブネットワーク１５０とデータネットワーク１００との間のインターフェースとしてネットワークリンクを提供する。クライアント１３５およびＡＰは、周知のＣＤＭＡ、Ｗ−ＣＤＭＡ、または同様なデジタルデータ通信技術を用い、互いに通信する。
【００１８】
モバイルＩＰｖ６に従い、各クライアント１３５には、ホームルータであるアクセスルータ１４５を含むホームサブネットワークが割り当てられる。このアクセスルータ１４５は、クライアント１３５の現在位置情報を保持し、クライアント１３５の現在位置にパケットを転送する。その他のアクセスルータ１４５は、フォーリンルータとして機能する。クライアント１３５は、ホームサブネットワークから離れている間、このフォーリンルータに「訪問する」ことができる。クライアント１３５が、任意の時刻にホームルータあるいはフォーリンルータのいずれかと通信する場合、いずれかのルータがネットワークリンクを確立し、クライアント１３５にネットワークアクセスを提供する。ネットワーク上のクライアント１３５およびアクセスルータ１４５は、従来のインターネットプロトコルを用いた従来の固定ノードデータネットワークと同様に、それぞれ一意のＩＰアドレスをもつ。
【００１９】
データ通信ネットワーク１００全体の中で、２つのレベルのハンドオフ過程が考えられる。第１のレベルは、マクロレベルハンドオフまたはレイヤ３ハンドオフであり、クライアントの位置の変化をともなう。この位置の変化とは、クライアントが、あるアクセスルータにより管理される無線サブネットワークから、別のアクセスルータにより管理される無線サブネットワークに移動することである。従って、Ｌ３ハンドオフにより、クライアントのネットワークリンクは必然的に変化する。第２のレベルは、マイクロレベルハンドオフまたはレイヤ２ハンドオフであり、サブネットワーク１５０内でのクライアントの位置変化をともなう。この場合、クライアントの無線リンクは変化するが、ネットワークリンクは変化しない。Ｌ２ハンドオフ処理は、無線携帯通信ネットワークにおいて一般的である。例えば、隣接するＡＰからのビーコン信号の強度を用いて隣接するＡＰの到達可能性を検出することは周知である。
【００２０】
図２は、モバイルＩＰｖ６に従って行われるモバイルクライアントによるＬ３ハンドオフ過程を示す簡略図である。図２において、データ通信ネットワーク１００は、コアネットワーク１２０およびコアネットワーク１２０に接続されるアクセスルータ１４５を含む。クライアント１３５は、初めは出発点Ａに位置し、中間地点Ｂを経由して地点Ｃに移動する。図２において、出発点Ａのクライアント１３５は、フォーリンルータであるアクセスルータ１４５（ＦＲ１）に管理されるフォーリンサブネットワーク内で動作し、ＦＲ１を介してコアネットワーク１２０に接続されている。一方、地点Ｃは、フォーリンルータであるアクセスルータ１４５（ＦＲ２）に管理されるフォーリンサブネットワーク内に位置している。モバイルクライアント１３５は、ＦＲ１に管理されるサブネットワークを通り抜け、ＦＲ２に管理されるサブネットワークに入る。従って、図２において考えられるＬ３ハンドオフは、ネットワークリンクをＦＲ１からＦＲ２へと切り替える際に行われる。
【００２１】
クライアント１３５が、出発点Ａから移動し中間地点Ｂに到着するとき、ある時点でＦＲ１とのさらなる無線通信が失敗し始める。クライアント１３５は、ＦＲ１に管理されるサブネットワーク１５０を離れ、ＦＲ２に管理されるサブネットワーク１５０に入るところである。クライアント１３５が中間地点Ｂを通りすぎ、Ｌ２ハンドオフが行われると、クライアント１３５の無線リンク先は、ＦＲ１に管理されるサブネットワークのＡＰからＦＲ２に管理されるサブネットワークのＡＰに変わる。到着地点Ｃに近づくにつれ、クライアント１３５は、Ｌ３ハンドオフ、すなわちＦＲ２との間でモバイルＩＰ登録をおこなう。この登録過程では、モバイルＩＰｖ６に定められるルータ検出が最初に行われる。このルータ検出により、クライアント１３５は隣接するアクセスルータ１４５を検出し、このアクセスルータ１４５のリンク層アドレスを特定し、このアクセスルータ１４５への経路についての到達可能性情報を保持する。このために、ルータ検出において、一対のＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）パケットタイプ、すなわちルータ請求およびルータ通知が定義される。ルータ請求は、クライアントにより送信され、隣接するアクセスルータにルータ通知の生成および返信を要求するメッセージである。アクセスルータ１４５は、定期的またはクライアント１３５からのルータ請求に対して、ルータ通知を送信することにより、自らの存在を通知する。ルータ通知が含む情報に基づき、クライアント１３５は気付けアドレス（ＣｏＡ）を設定する。
【００２２】
ＦＲ２からルータ通知を受信すると、クライアント１３５はこの通知内の情報に基づいて気付けアドレスを生成、設定する。そして、クライアント１３５は、新しい気付けアドレスおよびクライアント１３５の不変のホームＩＰアドレスを含む対応更新をホームルータに送信することにより、新しい気付けアドレスを登録する。ホームルータは、アドレスの対応情報を記録するキャッシュ内のクライアントのルーティング情報を更新し、その結果、クライアント１３５とＦＲ２との間にＬ３リンクが確立される。以後、クライアント１３５のホームＩＰアドレスに送信されるパケットは、ホームルータにより途中で回収され、ＦＲ２にトンネル送信され、ＦＲ２からクライアント１３５に配信される。パケットの迂回ルーティングにより生ずるパケット遅延を解消するため、以後パケットをクライアント１３５に直接転送可能なあらゆる相手先ノードに対しても、対応更新が送信される。
【００２３】
モバイルデータ通信の人気が高まるにつれ、悪意をもったクライアントがネットワークアクセスを試みる可能性も高くなる。このクライアントは、不正ＩＤまたは盗難ＩＤを用いてネットワーク資源に無料でアクセスしようとする不正利用者かもしれず、ネットワークの秩序ある運用に対する脅威にほかならない。従って、この悪意をもったクライアントをふるい落とすために、ネットワークアクセスを要求するクライアントは、ネットワークアクセスが許可される前に、常に認証されなければならない。同様に、クライアントは、ネットワークアクセスを開始する前に、接続サービスを提供するアクセスルータの認証を望むかもしれない。アクセスルータの中には、クライアントの通信を盗聴したり、どこかへ転送したり、ただ中断するだけの不正なアクセスルータがあるかもしれない。本発明が提供する双方向セキュリティプロトコルでは、クライアントおよびアクセスルータを相互に認証し、その結果、クライアントはゲートウェイとして用いる前に悪意をもったアクセスルータを特定でき、アクセスルータは転送サービスを提供する前に悪意をもったクライアントを特定できる。
【００２４】
本発明にかかるセキュリティメカニズムは、認証、認可、および課金（ＡＡＡ）プロトコルに基づいている。ＲＡＤＩＵＳやＤＩＡＭＥＴＥＲ等のＡＡＡプロトコルは、今日、インターネット上で使用されており、ダイアルアップコンピュータに対して、認証、認可、および課金サービスを提供している。このようなＡＡＡ管理サービス、特にＡＡＡサービスにより提供される認証サービスは、モバイルＩＰにおいても同様に有用である。実際、モバイルＩＰは、基本的な枠組みにほとんど変更を加えないＡＡＡインフラストラクチャ上で実行可能である。例えば、ＡＡＡプロトコルにおけるクライアントは、モバイルＩＰのモバイルノードと考えられ、ＡＡＡプロトコルにおけるアテンダントは、モバイルＩＰのアクセスルータに相当する。モバイルクライアントおよびアクセスルータの機能を向上させ、これらがＡＡＡメッセージを解読可能であれば、ＡＡＡインフラストラクチャ上でモバイルＩＰが実行可能になる。
【００２５】
図３および４は、ネットワークアクセスサービス（ＮＡＳ）およびモバイルＩＰが実行される、一般的ＡＡＡネットワークモデルを示す簡略図である。管理ドメインは、１または共通の管理の下で動作する複数のネットワークからなる。図１に示すデータ通信ネットワーク１００内において、多数の管理ドメインが定義されてもよい。しかし、図の簡略化のため、図３および４に示すＡＡＡネットワークには、２つの管理ドメインのみが示されている、すなわち、広域インターネットにより隔てられたホームドメイン３００およびフォーリンドメイン４００である。各ドメインは、ドメインの構成要素に対しＡＡＡサービスを提供するＡＡＡサーバを備えている。ホームドメイン３００は、ホームサーバＡＡＡＨ３１０により管理されている。フォーリンドメイン４００は、フォーリンサーバＡＡＡＦ４１０により管理されている。各ホームおよびフォーリンドメインは、ドメイン内に配置されるアテンダントをさらに備えている。ただし、図３および４では、フォーリンドメイン４００のみが、２つのアテンダント４２０および４２１を備えている。ＡＡＡプロトコルに従って、アテンダント４２０および４２１は、クライアント３２０とローカルドメイン４００との間のサービスインターフェースを提供する。この実施形態では、クライアント３２０は、ホームドメイン３００からフォーリンドメイン４００に移動し、管理ドメイン４００内のアテンダント４２０または４２１のいずれかからのサービスを望んでいるものとする。上述したように、モバイルＩＰは、図３および４に示すＡＡＡネットワーク上で実行される。モバイルＩＰの場合、アテンダントは、実際上、モバイルクライアントに対しネットワークアクセスサービスを提供するアクセスルータ（ＡＲ）である。従って、「アテンダント」という用語は、「アクセスルータ」または、単に「ＡＲ」という用語と置き換えて使用してもよい。
【００２６】
ＡＡＡプロトコルにより提供される重要なサービスの１つは、認証である。一般的に、ＡＡＡ認証メカニズムは以下のように機能する。ＡＡＡに対応した第１の実体が通信先に望む第２の実体に対し証明書を提示し、第２の実体が第１の実体の証明書を正常に確認可能な場合のみ、２つの実体間の通信が許可される。この証明書は、２つの実体間でセキュリティ関係（ＳＡ）が確立される際に定義される鍵アルゴリズムを用いて確認される。ＡＡＡプロトコルは、異なる鍵アルゴリズムを用いても機能するように設計されている。あるアルゴリズムは、公開鍵インフラストラクチャに基づき、別のアルゴリズムは、対称鍵の配信に基づいている。ＡＡＡサーバは、鍵の配信センターとして機能し、アテンダントやクライアント等のＡＡＡの実体の要求により、ＡＡＡの２つの実体間で提示される証明書を確認するために用いられる鍵を生成、配信する。２つのＡＡＡの実体に対し鍵を配信することにより、これらの間にセキュリティ関係が確立される。説明上、図３および４に示すＡＡＡネットワークでは、対称鍵または共有秘密鍵アルゴリズムが用いられるものとする。対称鍵アルゴリズムは、他の鍵アルゴリズムよりも用い易く、インターネット全体への適応性という問題に解決策を提供する。しかしながら、本発明を実施するにあたり、公開鍵方式等の非対称鍵アルゴリズムや他の鍵アルゴリズムを用いてもよいことは、当業者にとっては明らかであろう。また、認証トークンを用いてもよい。
【００２７】
図３および４に示すＡＡＡネットワークには、暗黙のセキュリティモデルが存在する。図５は、このような暗黙のセキュリティモデルを示しており、矢印は、初めから確立されていると想定されるセキュリティ関係を示す。まず、矢印ＳＡ１が示すように、ＡＡＡＦ４１０とＡＲ４２０および４２１との間にセキュリティ関係が確立されているものとする。ＡＲはＡＡＡＦ４１０に管理されるドメインに位置しており、両者間にはすでに信用が確立されているはずであるので、ＡＲ４２０および４２１とＡＡＡＦ４１０との間にＳＡ１が確立されているものとしてよいであろう。次に、ＡＡＡＨ３１０とＡＡＡＦ４１０との間にセキュリティ関係が確立されているものとする。これらのＡＡＡサーバは、初め、両者間にセキュリティ関係を確立している必要はないが、必要に応じて両者間にセキュリティ関係を確立する能力をもたねばならない。矢印ＳＡ２が示すセキュリティ関係は、２つのＡＡＡサーバ間で直接的に、または仲介ＡＡＡサーバ２００を介して間接的に、確立可能である。最後に、矢印ＳＡ３が示すように、クライアント３２０とＡＡＡＨ３１０との間にセキュリティ関係が確立されているものとする。クライアント３２０は、ＡＡＡＨ３１０が位置するホームドメイン３００からスタートしているので、ＳＡ３が確立されているものとしてよいであろう。従って、ＡＡＡＨ３１０は、最初にクライアントを認証可能な唯一の実体である。
【００２８】
本発明の重要な特徴は、本発明ではルータ検出メカニズムが「キャリア」として用いられ、モバイルＩＰにおいてＡＡＡセキュリティプロトコルを実行する点である。本発明では、ルータ請求およびルータ通知が拡張され、既存のＡＡＡプロトコルにモバイルＩＰ認証機能を付加する。
【００２９】
＜最初のルータ検出（新しいドメインに入る場合）＞
図６は、本発明の実施形態にかかる、ルータ検出プロトコルを用いたネットワークアクセス認証過程を示すフローチャートである。図７は、図６に示す過程の簡略図である。この実施形態では、クライアント３２０は、ＡＲ４２０および４２１、またはＡＡＡＦ４１０のいずれともセキュリティ関係を確立していないものとする。すなわち、クライアント３２０は、以前にフォーリンドメイン４００に訪問したことがないか、もしくは長期間フォーリンドメイン４００から離れていたためＡＲ４２０、ＡＲ４２１、およびＡＡＡＦ４１０との間で以前に確立されたセキュリティ関係が無効になったものとする。
【００３０】
クライアント３２０は、フォーリンドメイン４００に入り、リンクが張られているアクセスルータによるネットワークアクセスを要求する。ステップ５０１において、クライアント３２０は、拡張ルータ請求メッセージ（ＲＳ＋）を送信することによりルータ検出を開始する。これはマルチキャストメッセージであり、クライアントと同じリンク上のすべてのアクセスルータにより受信される。通常のルータ請求メッセージとは異なり、これはクライアントの身元証明書を含む。この身元証明書は、標準のルータ請求パケットの拡張という形で送信される。ＲＳ＋は、標準のルータ請求メッセージ（ＲＳ）と同様の各種構成要素を含む。また、ＲＳ＋は、ネットワークアクセス識別子（ＮＡＩ）またはＩＰアドレスになりうるクライアントの識別子（ｃｌｉｅｎｔ_ｉｄ）と、クライアントの署名とを含む。この署名は、ＡＡＡＨ３１０と共有するクライアントの秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）により暗号化されたＲＳ＋の要約である。従って、ＲＳ＋は以下のように表現される。
ＲＳ  ＋  ｃｌｉｅｎｔ_ｉｄ  ＋  クライアントによる署名
【００３１】
クライアントの共有秘密鍵は、クライアント３２０とＡＡＡＨ３１０との間に確立されるセキュリティ関係ＳＡ３（図５参照）により定義される。従って、ＡＡＡＨ３１０は、クライアントの共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を保有し、ＲＳ＋に格納されたクライアントの署名を確認する。ＡＲ４２０および他のアテンダントは、クライアント３２０からＲＳ＋を受信する。しかしながら、上述したように、ＡＲ４２０はクライアント３２０とセキュリティ関係を確立していないため、クライアント３２０の身元を確認する共有秘密鍵を保有しない。標準のルータ検出メカニズムによると、アクセスルータはルータ請求メッセージに応じてルータ通知メッセージを返信する。しかしながら、本発明では、クライアント３２０が正常に認証されるまで、ＡＲ３２０および他のアクセスルータはルータ通知メッセージを返信しない。
【００３２】
ＡＲ４２０は、クライアント３２０の確認をＡＡＡＦ４１０に委任する。ＡＲ４２０は、ＡＡＡ要求メッセージ（ＡＡＡＲｅｑ）を生成し、ＡＡＡＦ４１０に送信する（ステップ５０３）。このＡＡＡＲｅｑは、クライアント３２０からのＲＳ＋全体のコピーを含む。ＡＲ４２０からＡＡＡＦ４１０へ送信されたＡＡＡＲｅｑは、両者間に確立されたセキュリティ関係ＳＡ１に基づいて保護される。ＡＡＡＲｅｑは、ＲａｄｉｕｓやＤＩＡＭＥＴＥＲ等のＡＡＡプロトコルに従って生成される。ＡＡＡメッセージを生成する際の好適な手順については、「Ｄｉａｍｅｔｅｒ基本プロトコル」と題されたＩＥＴＦの草案「ｄｒａｆｔ−ｉｅｔｆ−ｄｉａｍｅｔｅｒ−０７.ｔｘｔ」および「ＤｉａｍｅｔｅｒモバイルＩＰ拡張仕様」と題されたＩＥＴＦの草案「ｄｒａｆｔ−ｃａｌｈｏｕｎ−ｄｉａｍｅｔｅｒ−ｍｏｂｉｌｅｉｐ−１２.ｔｘｔ」の中で論じられている。なお、この２つの草案は本明細書において参照として援用される。
【００３３】
上述したように、ＡＡＡＦ４１０は、クライアント３２０とセキュリティ関係を確立しておらず、従って、クライアントの身元を確認する共有秘密鍵を保有していない。しかし、ＲＳ＋に格納されたクライアントの識別子により、ＡＡＡＦ４１０はクライアント３２０のホームドメインがホームドメイン３００であることを認識する。そして、ＡＡＡＦ４１０は、ＡＡＡＨ３１０との間に確立されたセキュリティ関係ＳＡ２を使って、ホームドメイン３００に位置するＡＡＡＨ３１０に対しＲＳ＋のコピーとＡＡＡＲｅｑを転送する（ステップ５０５）。
【００３４】
ＡＡＡＦ４１０からＡＡＡＲｅｑを受信すると、ＡＡＡＨ３１０は、クライアントの共有秘密鍵を用いてＡＡＡＲｅｑに格納されたクライアントの署名を復号することにより、クライアント３２０の身元を確認する。クライアントが正当な身元を提示すれば、ＡＡＡＨ３１０はクライアントの身元を正常に確認できるはずである。クライアントの身元を確認できない場合、ＡＡＡＨ３１０はＡＡＡ応答メッセージ（ＡＡＡＲｅｐ）を生成し、ＡＡＡＦ４１０を介してＡＲ４２０に送信する。このＡＡＡＲｅｐは、ＡＡＡＨ３１０がクライアント３２０を認証できない旨を示す認証結果を含む。ＡＡＡＲｅｐも、ＲａｄｉｕｓやＤＩＡＭＥＴＥＲ等のＡＡＡプロトコルに従って生成される。ＡＡＡＲｅｐを受信すると、ＡＲ４２０はクライアント３２０からのルータ請求メッセージを無視し、ルータ通知メッセージを返信しない。従って、認証されないクライアントによるネットワーク資源へのアクセスは防止される。
【００３５】
ＡＡＡＨ３１０がクライアント３２０の身元を正常に確認した場合、ＡＡＡＨ３１０は、ＡＡＡ応答（ＡＡＡＲｅｐ）を生成しＡＡＡＦ４１０に送信することにより、ＡＡＡＦ４１０からのＡＡＡＲｅｑに応答する（ステップ５０７）。このＡＡＡＲｅｐは、２つの共有秘密鍵を含む。これらのうち一方は、クライアント３２０とＡＲ４２０との間で用いられ、他方は、クライアント３２０とＡＡＡＦ４１０との間で用いられる。これらの共有秘密鍵はＡＡＡＨ３１０により生成され、ＡＡＡＦ４１０、ＡＲ４２０、およびクライアント３２０に配信され、クライアント３２０とＡＡＡＦ４１０との間およびクライアント３２０とＡＲ４２０との間にセキュリティ関係を確立する。これらの共有秘密鍵である（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）は、それぞれ複製される。複製された共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）は、これらの真実性および機密性を守るため、クライアント３２０と共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を用いてＡＡＡＦ４１０により暗号化され、クライアント３２０に配信される。元の鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）は復号化され、ＡＲ４２０およびＡＡＡＦ４１０にそれぞれ配信される。従って、ＡＡＡＨ３１０からＡＡＡＦ４１０に送信されるＡＡＡＲｅｐは、以下のように表現される。
ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ  ＋  ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ  ＋  ＡＡＡＨにより暗号化された（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ  ＋  ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）
【００３６】
ＡＡＡＨ３１０からのＡＡＡＲｅｐにより、ＡＡＡＦ４１０はクライアント３２０が信用できることを認識する。そして、ＡＡＡＦ４１０は、ＡＡＡＲｅｐから復号化された共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を抽出し、キャッシュに格納する。この抽出された共有秘密鍵は、クライアント３２０からのメッセージを認証するため、ＡＡＡＦ４１０により用いられる。そして、ＡＡＡＦ４１０は、ＡＡＡＲｅｐをＡＲ４２０に転送する（ステップ５０９）。ＡＡＡＦ４１０からのＡＡＡＲｅｐにより、ＡＲ４２０はクライアント３２０の身元が正常に認証されたことを認識する。そして、ＡＲ４２０は、ＡＡＡＲｅｐから復号化された共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を抽出し、キャッシュに格納する。この共有秘密鍵は、クライアント３２０からのメッセージを認証するため、ＡＲ４２０により用いられる。そして、ＡＲ４２０は、拡張ルータ通知（ＲＡ＋）を生成し、クライアント３２０に送信する（ステップ５１１）。このＲＡ＋は、標準のルータ通知メッセージ（ＲＡ）、ＡＲ４２０の識別子（ＡＲ_ｉｄ）、および共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）により暗号化された共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を含む。このＲＡ＋は、さらにＡＲ４２０の署名を含む。この署名は、ＡＲ４２０がＡＡＡＦ４１０から受信した共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）により暗号化されたＲＡ＋の要約である。従って、このＲＡ＋は以下のように表現される。
ＲＡ  ＋  ＡＲ_ｉｄ  ＋  ＡＡＡＨにより暗号化された（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ  ＋  ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）  ＋  ＡＲによる署名
【００３７】
ＡＲ４２０からＲＡ＋を受信すると、クライアント３２０は受信したＲＡ＋を認証する。まず、クライアント３２０は、ＡＡＡＨ３１０と共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を用いて、共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を復号化する。これらの秘密鍵が正常に復号化された場合、これらの鍵はクライアント３２０が信用するＡＡＡＨ３１０により証明されることから、クライアント３２０はこれらの秘密鍵を信用できる。次に、クライアント３２０は、復号化された秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を用いて、ＡＲ４２０の署名を復号化する。署名が正常に復号化された場合、ＡＲ４２０の身元はクライアント３２０が信用する秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）により確認されることから、クライアント３２０はＡＲ４２０を信用できる。また、署名が正常に復号化されることにより、クライアント３２０に対しＲＡ＋の信頼性が保証される。クライアント３２０およびＡＲ４２０に配信される共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）により、クライアント３２０とＡＲ４２０との間に新しいセキュリティ関係ＳＡ４（図８参照）が確立される。クライアント３２０およびＡＡＡＦ４１０に配信される共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）により、クライアント３２０とＡＡＡＦ４１０との間に新しいセキュリティ関係ＳＡ５が確立される。
【００３８】
ＡＲ４２０の署名を認証できない場合、クライアント３２０はＡＲ４２０からのＲＡ＋を無視し、認証可能な証明書を含む他のアクセスルータからのＲＡ＋を待つ。従って、クライアント３２０が不正なアクセスルータを介してネットワークアクセスを開始してしまうことを防止できる。
【００３９】
図６および７に示す認証過程は、長時間を要し、かなりの通信待ち時間を生じるであろう。この通信待ち時間は、主にＡＡＡメッセージがＡＡＡＦ４１０とＡＡＡＨ３１０とを隔てる広域インターネットを行き来するために要する時間である。ＡＡＡメッセージがＡＡＡＦ４１０あるいはＡＡＡＨ３１０に送信される場合、常に、いくらかの待ち時間を伴う。図６および７に示す最初の認証過程では、これら遠く離れたサーバと通信しなければならない。しかしながら、もしＡＲ４２０およびＡＡＡＦ４１０がＡＡＡＦ４１０あるいはＡＡＡＨ３１０によらずにクライアントを認証できれば、認証メカニズムに伴う待ち時間が短縮化される。
【００４０】
＜以降のルータ検出（同一ドメイン内で、新しいアクセスルータを検出する場合）＞
クライアント３２０は、ドメイン４００内を移動し、クライアント３２０の身元を認証していない別のアクセスルータと接続してもよい。図９は、本発明の別の実施形態に基づき、このような場合に行われる認証ルータ検出を示すフローチャートである。図１０は、図９に示す過程の簡略図である。図９および１０において、図６および７に示すＡＲ４２０との最初の認証過程を経た後、クライアント３２０は、ＡＲ４２０に管理されるサブネットワークを離れ、ＡＲ４２１に管理されるサブネットワークに入るものとする。ＡＲ４２１を介してネットワークにアクセスするため、クライアント３２０はＲＳ＋を再び送信する（ステップ７０１）。今回送信されるＲＳ＋は、図６および７に示す最初の認証過程で用いられたものと同様のメッセージを含み、以下のように表現される。
ＲＳ  ＋  ｃｌｉｅｎｔ_ｉｄ  ＋  クライアントによる署名
【００４１】
しかしながら、本実施形態のＲＳ＋に含まれる署名は、共有鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）により暗号化されるため、ＡＲ４２１は署名を確認することができない。そこで、ＡＲ４２１は、ＡＡＡＲｅｑを生成しＡＡＡＦ４１０に送信することにより、クライアント３２０の確認をＡＡＡＦ４１０に委任する（ステップ７０３）。ＡＲ４２１からのＡＡＡＲｅｑは、ＲＳ＋全体のコピーを含む。ＡＡＡＦ４１０は、図６および７に示す先の認証過程において共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を取得しているため、クライアント３２０の身元を認識できるはずである。ＡＡＡＦ４１０は、ＡＡＡＨ３１０によることなく、共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）でクライアント３２０の署名を復号化することにより、クライアント３２０の身元を確認する。クライアント３２０の署名を確認できない場合、ＡＡＡＦ４１０は、ＡＡＡＲｅｑを生成し、ＡＲ４２１に送信する（ステップ７０５）。これにより、ＡＲ４２１に対し、クライアント３２０が信用できない旨を知らせる。ＡＲ４２１は、クライアント３２０からのＲＳ＋を無視する。クライアント３２０の署名が正常に確認された場合、ＡＡＡＦ４１０は、クライアント３２０とＡＲ４２１との間で共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）を生成する。この秘密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）は、複製される。複製により２つとなった秘密鍵の一方はそのまま暗号化されず、他方は共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）により暗号化される。ＡＡＡＦ４１０は、暗号化されていない鍵と暗号化された鍵とをＡＡＡＲｅｑに格納し、ＡＲ４２１に送信する（ステップ７０５）。従って、ＡＡＡＦ４１０からＡＲ４２１に送信されるＡＡＡＲｅｐは、以下のように表現される。
ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ  ＋  ＡＡＡＦにより暗号化された（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）
【００４２】
ＡＡＡＦ４１０からのＡＡＡＲｅｐにより、ＡＲ４２１はクライアント３２０が信用できることを認識する。そして、ＡＲ４２１は復号化された秘密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）を抽出し、キャッシュに格納する。この格納された秘密鍵は、クライアント３２０からの以後のメッセージを認証するため、ＡＲ４２１により用いられる。ＡＲ４２１は、ＲＡ＋を生成し、クライアント３２０に送信する（ステップ７０７）。ＡＲ４２１からのＲＡ＋は、以下のように表現される。
ＲＡ  ＋  ＡＲ_ｉｄ  ＋  ＡＡＡＦにより暗号化された（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）  ＋  ＡＲによる署名
【００４３】
ＡＲ４２１からＲＡ＋を受信すると、クライアント３２０は、共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を用いて復号化し、秘密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）を抽出する。もしこの鍵が正常に復号化されたら、クライアント３２０はこの鍵を信用できる。クライアント３２０は、共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）を用いてＡＲ４２１の署名を復号化することにより、ＲＡ＋を認証する。署名が正常に復号化された場合、クライアント３２０はＡＲ４２１およびＲＡ＋の真実性を信用できる。クライアント３２０およびＡＲ４２１に配信される共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）により、両者間に新しいセキュリティ関係が確立される。署名を復号化できない場合、クライアントはＡＲ４２１からのＲＡ＋を無視し、認証可能な署名を含む他のアクセスルータからのＲＡ＋を待つ。
【００４４】
図９および１０に示す、以降の認証過程は、図６および７に示す認証過程と比較して迅速に行われる。これは、図９および１０に示す認証過程では、ＡＡＡＨ３１０とメッセージをやり取りする必要がなく、従って、プロトコル信号がより短い距離を往復するためである。
【００４５】
＜以降のルータ検出（同一アクセスルータを検出する場合）＞
各ＲＡ＋には、有効期間がある。従って、同一のアクセスルータに接続している場合でも、先のＲＡ＋の有効期間が経過する前に、クライアントは同一のアクセスルータとの認証過程を経なければならない。この場合、図１１および１２に示すように、本発明にかかる認証過程において、プロトコル信号は最短距離を往復する。図１１および１２では、クライアント３２０は、ステップ８０１においてＲＳ＋をＡＲ４２０に送信する。ＲＳ＋は、以下のように表現される。
ＲＳ  ＋  ｃｌｉｅｎｔ_ｉｄ  ＋  クライアントによる署名
【００４６】
署名は、図６および７に示す最初の認証過程においてクライアント３２０が取得した共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）により暗号化される。ＡＲ４２０は、クライアント３２０と同一の鍵を共有しているため、クライアント３２０の身元を認識できるはずである。ＡＲ４２０は、ＡＡＡＦ４１０によらずに、共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を用いて署名を復号化することにより、クライアント３２０の身元を確認する。クライアント３２０の身元を確認できない場合、ＡＲ４２０はＲＳ＋を無視する。クライアント３２０の身元を正常に確認した場合、ＡＲ４２０は、ＲＡ＋を生成し、クライアント３２０に送信する。本実施形態のＲＡ＋は、以下のように表現される。
ＲＡ  ＋  ＡＲ_ｉｄ  ＋  ＡＲによる署名
【００４７】
従って、クライアント３２０とＡＲ４２０との通信は、プロトコル信号が最短距離を往復するため最速の認証メカニズムである。
【００４８】
＜非請求ルータ通知＞
アクセスルータは、認証可能なＲＳ＋の受信を待つのではなく、ＲＡ＋を定期的に送信してもよい。図１３において、ＡＲ４２０および４２１はＲＡ＋を定期的に送信するものとする。ＲＡ＋は、以下のように表現される。
ＲＡ  ＋  ＡＲ_ｉｄ  ＋  ＡＲによる署名
【００４９】
ＡＲ４２０から送信されるＲＡ＋は、ＲＡとＡＲ４２０の署名とを含む。ＡＲ４２１から送信されるＲＡ＋は、ＲＡとＡＲ４２１の署名とを含む。クライアント３２０は、図６および７に示すＡＲ４２０との最初の認証過程を以前に経ているものとする。先の認証過程を通じて、クライアント３２０とＡＲ４２０との間、およびクライアント３２０とＡＡＡＦ４１０との間には、セキュリティ関係が確立されている。ＡＲ４２０からのＲＡ＋がクライアント３２０に到達していれば、クライアント３２０はＲＡ＋を認証できるはずである。従って、クライアント３２０は、ＡＲ４２０を介して安全にネットワークアクセスを開始できる。受信するいかなるＲＡ＋も認識できない場合、クライアントは、ＲＳ＋を送信することにより、図６および７に示す最初の認証過程を経なければならない。
【００５０】
＜再認証＞
通信中のクライアントおよびＡＲのどちらも常に、本発明の認証過程を開始し、互いに再認証してよい。これは、通信中でさえも悪意をもった実体が正当な実体と入れ替わる可能性が常にあるという理由から重要である。クライアントは、ＡＲとの通信中、ＲＳ＋を送信することにより、いつでもこの過程を開始してよい。ＡＲは、クライアントによる再認証に対しＲＡ＋をクライアントに返信することにより、ＲＳ＋に応答できるはずである。同様に、ＡＲは、クライアントを収容している間、クライアントを再認証できる。ＡＲは、有効期間の非常に短いユニキャストルータ通知メッセージをクライアントに送信することにより、クライアントの再認証を開始する。このルータ通知メッセージは有効期間が非常に短いことから、クライアントは、ＡＲがまもなくクライアントへの接続サービスを停止することを認識する。クライアントは、ＲＳ＋を送信し同一リンク上の利用可能な他のアクセスルータを検出することにより、このようなルータ通知メッセージに応答する。そして、ＡＲは、クライアントから送信されたＲＳ＋を認証する。
【００５１】
＜旧プロトコルとの相互運用＞
ネットワーク全体において、本発明にかかる拡張ルータ検出メカニズムをサポートできるドメインと、標準のルータ検出メカニズムのみをサポートできるドメインとが混在してもよい。従って、標準のルータ検出メカニズムのみをサポートするクライアントが、本発明にかかる拡張ルータ検出メカニズムをサポートするドメインに移動する場合があってもよいし、また、拡張ルータ検出メカニズムをサポートするクライアントが、標準のルータ検出メカニズムのみをサポートするドメインに移動する場合があってもよい。どちらの場合も、本発明にかかる認証プロトコルは、標準のルータ検出メカニズムの運用の妨げとはならない。
【００５２】
まず、拡張ルータ検出メカニズムをサポートするクライアントが、標準のルータ検出メカニズムのみをサポートするドメイン内において接続サービスを受けようとする場合、クライアントはＲＳ＋を送信する。しかしながら、隣接するアクセスルータは、ＲＳ＋に加えられた新しい拡張部分を認識できず、従って、この拡張部分を無視する。アクセスルータは、ＲＳ＋をｒとして処理し、ＲＡを返信する。ここで、この「認証されていない」ルータ通知メッセージを用いるか否かはクライアント次第である。
【００５３】
次に、標準のルータ検出メカニズムのみをサポートするクライアントが、本発明にかかる拡張ルータ検出メカニズムをサポートするドメイン内において接続サービスを受けようとする場合、クライアントは、いかなる新しい拡張をも含まないＲＳを送信する。このような「認証されない」ルータ請求メッセージを受信した場合、ＲＡ＋を返信するか、あるいは全く応答しないかは、隣接するアクセスルータ次第である。
【００５４】
どちらの場合であっても、本発明にかかる拡張ルータ検出メカニズムをサポートするクライアントおよびＡＲは、通信相手が拡張ルータ検出メカニズムをサポートできるか、または標準のルータ検出メカニズムのみをサポートできるのかを検出し、それに応じて応答できる。認証されていないメッセージに対し応答するか、または受け取るかは、ネットワークの設計方針次第である。
【００５５】
＜リプレイ攻撃に対する防御＞
リプレイ攻撃とは、盗難パスワードの単なる再利用である。パスワード送信中にクラッカーがそのパスワードを盗聴できれば、クラッカーはそれ以降いつでも使用できるパスワードのコピーを手に入れることになる。たとえパスワードが暗号化されてやり取りされていたとしても、クラッカーは、以前に取得した通信を単に再実行することにより、ログインできるかもしれない。本発明にかかる認証プロトコルは、チャレンジに関する拡張を加えることにより、リプレイ攻撃に対する防御を設けることができる。
【００５６】
図１４は、チャレンジ方式を用いてリプレイ攻撃に対する防御を設ける本発明の実施形態を示すフローチャートである。図１４においては、クライアント３２０は、ＡＲ４２０またはＡＡＡＦ４１０と通信したことがなく、従って、図６および７に示す最初の認証過程を経なければならないものとする。まず、クライアント３２０は、ＲＳを送信する（ステップ１００１）。ＡＲ４２０は、ＲＳを受信するが、ＲＳを送信したクライアントの身元が認証されるまで信用できない。ＲＳを送信したクライアントは、クライアント３２０との過去の通信を盗聴し、クライアント３２０の識別情報を盗み、偽造ＩＤを使ってネットワークにアクセスする悪意をもったノードかもしれない。
【００５７】
クライアント３２０からのＲＳに対する返信として、ＡＲ４２０は、クライアントの身元およびＲＳの真実性を確認する（ステップ１００３）。具体的には、ステップ１００３において、ＡＲ４２０は、チャレンジに関する拡張とＲＡをクライアント３２０に送信する。このチャレンジに関する拡張は、ＡＲ４２０により生成された乱数を含む。ＡＲ４２０からのＲＡをきっかけとして、クライアント３２０は、拡張ルータ請求メッセージ（ＲＳ*）を生成、送信する（ステップ１００５）。ＲＳ*は、ＲＳと、クライアントの識別子、すなわちクライアントのＩＰアドレスまたはＮＡＩと、秘密鍵の要求とを含む。この秘密鍵は、ＡＲ４２０と共有され、ＡＲ４２０とのセキュリティ関係を確立する。ＲＳ*は、さらに２つのチャレンジに関する拡張を含む。一方のチャレンジに関する拡張は、ステップ１００３においてクライアントがＡＲ４２０から受信したチャレンジのコピーを含み、他方のチャレンジに関する拡張は、クライアント自身により生成された乱数を含む。最後に、ＲＳ*は、クライアント３２０とＡＡＡＨ３１０との間で共有される秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を用いて暗号化されるクライアント３２０の署名を含んだ認証拡張を含む。従って、本実施形態において、ＲＳ*は以下のように表現される。
ＲＳ  ＋  ｃｌｉｅｎｔ_ｉｄ  ＋  ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ_ｒｅｑｕｅｓｔ  ＋  Ｃｈａｌ_ＡＲ  ＋  Ｃｈａｌ_ｃｌｉｅｎｔ  ＋  クライアントによる署名
【００５８】
クライアント３２０からＲＳ*を受信すると、ＡＲ４２０は、チャレンジに関する拡張（Ｃｈａｌ_ＡＲ）をチェックし、この拡張に含まれる乱数がステップ１００３においてクライアントに送信した乱数と同一であるかを調べる。乱数が同一の場合、ＲＳ*は、事実上、ステップ１００３においてＡＲ４２０がクライアント３２０に送信したチャレンジに対する応答であるといえる。乱数が一致しない場合、おそらくＲＳ*は、盗難ＩＤを使ってクライアント３２０だと偽る悪意をもったノードからのものであるため、ＡＲ４２０はこのＲＳ*を無視しなければならない。乱数が一致した場合、以降の認証過程は、図６および７において述べた過程と同様である。
【００５９】
クライアント３２０の身元がＡＡＡＨ３１０により正常に確認された場合、ＡＲ４２０は、拡張ルータ通知メッセージ（ＲＡ*）を生成し、クライアント３２０に対し送信する（ステップ１００７）。本実施形態において、ＲＡ*は、ＲＡと、クライアント３２０とＡＲ４２０との間で共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）とを含む。この秘密鍵は、ＡＡＡＨ３１０により生成されたものである。上述したように、この鍵は、クライアント３２０とＡＡＡＨ３１０との間で共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を用いて暗号化される。ＲＡは、さらに２つのチャレンジに関する拡張を含む。一方のチャレンジに関する拡張は、ステップ１００５のおいてＡＲ４２０がクライアントから受信した乱数のコピーを含み、他方のチャレンジに関する拡張は、ＡＲ４２０により生成されクライアント３２０とＡＲ４２０との間の次回の通信で用いられる新しい乱数を含む。ＲＡ*は、新しく配信された共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を用いて暗号化されたＡＲ４２０の署名を含んだ認証拡張も含む。従って、本実施形態のＲＡ*は、以下のように表現される。
ＲＡ  ＋  ＡＲ_ｉｄ＋ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ_ｒｅｐｌｙ  ＋  Ｃｈａｌ_ｃｌｉｅｎｔ  ＋  Ｃｈａｌ_ＡＲ  ＋  ＡＲによる署名
【００６０】
ＡＲ４２０からＲＡ*を受信すると、クライアント３２０は、チャレンジに関する拡張（Ｃｈａｌ_ｃｌｉｅｎｔ）をチェックし、この拡張に含まれる乱数がステップ１００５においてＡＲ４２０に送信した乱数と同一であるかを調べる。乱数が一致しない場合、悪意をもったアクセスルータが盗難ＩＤを使ってＡＲ４２０だと偽っているかもしれないため、クライアント３２０はこのＲＡ*を無視しなければならない。乱数が一致した場合、クライアント３２０は、チャレンジに関する拡張（Ｃｈａｌ_ＡＲ）から乱数を抽出し、ＡＲ４２０との以後の通信のためキャッシュに格納する。そして、クライアント３２０は、ＡＡＡＨ３１０と共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を用いて鍵応答（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ_ｒｅｐｌｙ）を復号化し、ＡＲ４２０と共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を抽出する。この抽出された共有秘密鍵を用いて、クライアントはＡＲ４２０の署名を確認する。
【００６１】
図１４に示す最初の認証過程を実行後、すなわちクライアント３２０とＡＲ４２０との間でセキュリティ関係が確立された後、クライアント３２０およびＡＲ４２０は、互いに再認証してもよい。図１５に、このような再認証過程の一例を示す。再認証過程において、まず、クライアント３２０がＲＳ*を送信する（ステップ１１０１）。これに対する返信として、ＡＲ４２０は、ＲＡ*を送信する（ステップ１１０３）。クライアント３２０とＡＲ４２０との間でセキュリティ関係が既に確立されているので、ＲＳ*は以下のように表現される。
ＲＳ  ＋  ｃｌｉｅｎｔ_ｉｄ  ＋  Ｃｈａｌ_ＡＲ  ＋  Ｃｈａｌ_ｃｌｉｅｎｔ  ＋  クライアントによる署名
【００６２】
ＲＳ*のチャレンジに関する拡張（Ｃｈａｌ_ＡＲ）は、ステップ１００７においてコピーされた乱数を含む。チャレンジに関する拡張（Ｃｈａｌ_ｃｌｉｅｎｔ）は、クライアントにより生成された新しい乱数を含む。
【００６３】
ＲＡ*は、以下のように表現される。
ＲＡ  ＋  ＡＲ_ｉｄ  ＋  Ｃｈａｌ_ｃｌｉｅｎｔ  ＋  Ｃｈａｌ_ＡＲ  ＋ＡＲによる署名
【００６４】
ＲＡ*のチャレンジに関する拡張（Ｃｈａｌ_ｃｌｉｅｎｔ）は、ステップ１１０１においてコピーされた乱数を含む。チャレンジに関する拡張（Ｃｈａｌ_ＡＲ）は、ＡＲにより生成された新しい乱数を含む。
【００６５】
＜非対称鍵方式を用いた認証＞
上述した実施形態においては、対称鍵方式、すなわち共有秘密鍵アルゴリズムを用いるＡＡＡインフラストラクチャに基づいた、本発明にかかる認証プロトコルについて説明した。本発明にかかる認証プロトコルが公開鍵アルゴリズム等の非対称鍵方式を採用しても機能することは、当業者にとって明らかである。図１６を参照して、いかに本発明にかかる認証プロトコルが公開鍵アルゴリズムを用いて機能するかについて説明する。図１６において、クライアント３２０が以前に訪問したことのないドメイン４００に入ったものとする。従って、クライアント３２０は、最初の認証過程を経なければならない。
（１）クライアント３２０は、ＲＳ＋を送信することにより、ルータ検出を開始する。本実施形態において、ＲＳ＋は、ＲＳを含む。また、ＲＳ＋は、クライアント３２０の識別子とクライアント３２０の署名とを含む。この署名は、クライアント３２０の秘密鍵を用いて暗号化されたＲＳ＋の要約である。従って、ＲＳ＋は、以下のように表現される。
ＲＳ  ＋  ｃｌｉｅｎｔ_ｉｄ  ＋  クライアントによる署名
【００６６】
クライアント３２０の秘密鍵は、クライアント３２０とＡＡＡＨ３１０との間に確立されるセキュリティ関係ＳＡ３（図５参照）により定義される。従って、ＡＡＡＨ３１０は、クライアント３２０の公開鍵を保有し、ＲＳ＋に格納されたクライアント３２０の証明書を確認する。図１６に示す設定では、ＡＡＡＨ３１０が、クライアントの署名を確認できる唯一の実体である。
（２）ＡＲ４２０は、クライアント３２０からＲＳ＋を受信するが、クライアント３２０の署名を復号化する公開鍵を保有しないため、署名を確認できない。そこで、ＡＲ４２０は、ＡＡＡＲｅｑを生成し、ＲＳ＋全体のコピーとともにＡＡＡＦ４１０に送信する。
（３）ＡＡＡＦ４１０は、クライアント３２０の公開鍵を保有せず、クライアント３２０の署名を確認できない。そこで、ＡＡＡＦ４１０は、自身の公開鍵をＡＡＡＲｅｑに格納し、ＡＡＡＨ３１０に転送する。
（４）ＡＡＡＦ４１０からＡＡＡＲｅｑを受信すると、ＡＡＡＨ３１０は、クライアント３２０の公開鍵を用いてＡＡＡＲｅｑに格納されたクライアント３２０の署名を復号化することにより、クライアント３２０の身元を確認する。クライアント３２０の署名を正常に確認した場合、ＡＡＡＨ３１０は、ＡＡＡＲｅｐを生成しＡＡＡＦ４１０に送信することにより、ＡＡＡＲｅｑに応答する。このＡＡＡＲｅｐは、クライアント３２０の公開鍵（ＰＫ）とＡＡＡＦ４１０の証明書とを含む。ＡＡＡＦ４１０の証明書は、ＡＡＡＲｅｑからＡＡＡＦ４１０の公開鍵を抽出し、これを暗号化することにより生成される。なお、暗号化する際、既に確立されたセキュリティ関係ＳＡ３により定義されるＡＡＡＨ３１０の秘密鍵が用いられる。従って、ＡＡＡＨ３１０からＡＡＡＦ４１０に送信されるＡＡＡＲｅｐは、以下のように表現される。
クライアントのＰＫ  ＋  ＡＡＡＨにより証明されたＡＡＡＦ
（５）ＡＡＡＦ４１０は、ＡＡＡＲｅｑからクライアント３２０の公開鍵を抽出し、キャッシュに格納する。この抽出された公開鍵は、クライアント３２０からのメッセージを認証するために、ＡＡＡＦ４１０により用いられる。ＡＡＡＦ４１０は、ＡＲ４２０の証明書を生成し、ＡＡＡＲｅｐにこの証明書を格納し、ＡＡＡＲｅｐをＡＲ４２０に送信する。ＡＲ４２０の証明書は、ＡＡＡＦ４１０の秘密鍵により証明されたＡＲ４２０の公開鍵（ＰＫ）を含む。従って、ＡＡＡＦ４１０からＡＲ４２０に送信されるＡＡＡＲｅｐは、以下のように表現される。
クライアントのＰＫ  ＋  ＡＡＡＦにより証明されたＡＲ  ＋  ＡＡＡＨにより証明されたＡＡＡＦ
（６）ＡＡＡＦ４１０からＡＡＡＲｅｐを受信すると、ＡＲ４２０は、クライアント３２０の公開鍵を抽出し、キャッシュに格納する。クライアント３２０の公開鍵は、クライアント３２０からのメッセージを認証するために、ＡＲ４２０により用いられる。ＡＲ４２０は、ＲＡ＋を生成し、クライアント３２０に送信する。このＲＡ＋は、ＲＡと、ＡＡＡＦ４１０により生成されたＡＲ４２０の証明書と、ＡＡＡＨ３１０により生成されたＡＡＡＦ４１０の証明書とを含む。従って、ＲＡ＋は、以下のように表現される。
ＲＡ  ＋  ＡＲ_ｉｄ  ＋  ＡＡＡＦにより証明されたＡＲ  ＋  ＡＡＡＨにより証明されたＡＡＡＦ  ＋  ＡＲによる署名
【００６７】
ＡＲ４２０からＲＡ＋を受信すると、クライアント３２０は、受信したＲＡ＋を認証する。クライアント３２０は、まずＡＡＡＨ３１０の公開鍵を用いてＡＡＡＦ４１０の証明書を復号化し、ＡＡＡＦ４１０の公開鍵を抽出する。この公開鍵は、クライアント３２０とＡＡＡＨ３１０との間に確立されているセキュリティ関係ＳＡ３に由来する。証明書が正常に復号化された場合、クライアント３２０は抽出されたＡＡＡＦ４１０の公開鍵を信用できる。これは、この鍵がクライアント３２０が信用するＡＡＡＨ３１０により証明されたためである。次に、クライアント３２０は、抽出されたＡＡＡＦ４１０の公開鍵を用いてＡＲ４２０の証明書を復号化し、ＡＲ４２０の公開鍵を抽出する。証明書が正常に復号化された場合、クライアント３２０は、ＡＲ４２０の公開鍵を信用できる。これは、この鍵がクライアント３２０が信用するＡＡＡＦ４１０により証明されたためである。クライアント３２０に配信されたＡＲ４２０およびＡＡＡＦ４１０の公開鍵を用いて、クライアント３２０とＡＲ４２０との間およびクライアント３２０とＡＡＡＦ４１０との間に新しいセキュリティ関係ＳＡ４およびＳＡ５（図８参照）が確立される。
【００６８】
以上本発明の好適な実施形態を説明してきたが、これらは、性質上、例示的なものにすぎず、本発明の範囲を限定するものではない。本発明の斬新かつ有利な特徴を保ちつつ、且つ本発明の趣旨を逸脱せずに、種々の変形および追加を加えてもよいことは、当業者にとって明らかである。従って、本発明の範囲は、正しく解釈された添付の請求の範囲によってのみ定義される。
【００６９】
【発明の効果】
以上説明したように、本発明によれば、クライアントとアクセスルータとが相互に認証することにより、不正なクライアントまたは不正なアクセスルータによる通信を防止できる。
また、本発明によれば、ネットワーク層において認証メカニズムが実行されるため適用可能なアクセス技術が限定されない。
さらに、本発明は、既存の通信プロトコルにおいて広く用いられているルータ検出が認証プロトコルのキャリアとして用いられるので、既存の通信プロトコルへの導入が容易である。
【図面の簡単な説明】
【図１】  本発明が適用される第３世代の無線移動体アクセスＩＰに対応するデータ通信ネットワークの一例を示す図である。
【図２】  図１に示すデータ通信ネットワークにおいて行われる標準的なモバイルクライアントによるＬ３ハンドオフ処理を示す簡略図である。
【図３】  本発明にかかる認証プロトコルが実行される一般的ＡＡＡネットワークモデルを示す簡略図である。
【図４】  本発明にかかる認証プロトコルが実行される一般的ＡＡＡネットワークモデルを示す簡略図である。
【図５】  図３および４に示すネットワークにおいて、既に確立されている暗黙のセキュリティモデルを示す図である。
【図６】  モバイルクライアントの身元がホームサーバにより確認される本発明の実施形態にかかる、ルータ検出メカニズムを用いた認証プロトコルを示すフローチャートである。
【図７】  図６に示す過程の簡略図である。
【図８】  図６および７に示す認証プロトコル実施後、クライアントとアクセスルータとの間（ＳＡ４）およびクライアントとＡＡＡＦとの間（ＳＡ５）に確立される新しいセキュリティ関係を示す図である。
【図９】  モバイルクライアントの身元がフォーリンサーバにより確認される本発明の別の実施形態にかかる、認証プロトコルを示すフローチャートである。
【図１０】  図９に示す過程の簡略図である。
【図１１】  クライアントおよびアクセスルータが再認証される本発明の別の実施形態にかかる、認証プロトコルを示すフローチャートである。
【図１２】  図１１に示す過程の簡略図である。
【図１３】  アクセスルータがルータ通知を自ら送信する本発明の別の実施形態を示す簡略図である。
【図１４】  請求および通知メッセージがチャレンジを含みリプレイ攻撃に対し防御を設ける本発明の実施形態にかかる、ルータ検出メカニズムを用いた認証プロトコルを示すフローチャートである。
【図１５】  クライアントおよびアクセスルータが再認証される、図１４に示す本発明の実施形態において行われる認証プロトコルの別の例である。
【図１６】  非対称鍵アルゴリズムが用いられる本発明の実施形態にかかる、ルータ検出メカニズムを用いた認証プロトコルを示すフローチャートである。
【符号の説明】
１００  データ通信ネットワーク
１２０  コアネットワーク
１３０  ゲートウェイルータ
１３５、３２０  クライアント
１４０  ＩＰモバイルバックボーン
１４５、４２０、４２１  アクセスルータ
１５０  サブネットワーク
１５５  無線アクセスポイント
２００  仲介サーバ
３００  ホームドメイン
３１０  ホームサーバ
４００  フォーリンドメイン
４１０  フォーリンサーバ
【図１】
0003822555.tif 000002
【図２】
0003822555.tif 000003
【図３】
0003822555.tif 000004
【図４】
0003822555.tif 000005
【図５】
0003822555.tif 000006
【図６】
0003822555.tif 000007
【図７】
0003822555.tif 000008
【図８】
0003822555.tif 000009
【図９】
0003822555.tif 000010
【図１０】
0003822555.tif 000011
【図１１】
0003822555.tif 000012
【図１２】
0003822555.tif 000013
【図１３】
0003822555.tif 000014
【図１４】
0003822555.tif 000015
【図１５】
0003822555.tif 000016
【図１６】
0003822555.tif 000017