JP3822555B2

JP3822555B2 - Secure network access method

Info

Publication number: JP3822555B2
Application number: JP2002324920A
Authority: JP
Inventors: イーヤインアルパー; ハションニン; ウィリアムスカール
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2001-11-09
Filing date: 2002-11-08
Publication date: 2006-09-20
Anticipated expiration: 2022-11-08
Also published as: JP2003218954A

Description

【０００１】
【発明の属する技術分野】
本出願は、２００１年１１月９日に提出された「ルータ検出およびＡＡＡを用いた安全なネットワークアクセス（ＳｅｃｕｒｅＮｅｔｗｏｒｋＡｃｃｅｓｓＵｓｉｎｇＲｏｕｔｅｒＤｉｓｃｏｖｅｒｙａｎｄＡＡＡ）」と題する米国仮出願６０／３４５、９６７に関して優先権を主張する。なお、この仮出願は、本明細書において参照として援用される。
また、本出願では、２００２年５月１５日に提出された「モバイルＩＰネットワークへのアクセスを安全にする方法（ＭＥＴＨＯＤＦＯＲＳＥＣＵＲＩＮＧＡＣＣＥＳＳＴＯＭＯＢＩＬＥＩＰＮＥＴＷＯＲＫ）」と題する米国出願１０／１４６、５４８、および２００１年１１月９日に提出された「モバイルＩＰ登録（ＭＯＢＩＬＥＩＰＲＥＧＩＳＴＲＡＴＩＯＮ）」と題する米国仮出願６０／３３２、３９６が、相互に参照される。なお、これらの出願は、本明細書において参照として援用される。
本発明は、クライアントがネットワークにアクセスする接続サービスを要求する場合、およびルータがネットワーク接続を提供する場合に、クライアントおよびアクセスルータを相互に認証する双方向セキュリティプロトコルに関する。本発明にかかるセキュリティプロトコルは、ＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（認証）、Ａｕｔｈｏｒｉｚａｔｉｏｎ（認可）ａｎｄＡｃｃｏｕｎｔｉｎｇ（課金））に基づき、その実行において、ルータ検出（ＲｏｕｔｅｒＤｉｓｃｏｖｅｒｙ）がキャリアとして用いられる。
【０００２】
【従来の技術】
携帯電話機、ＰＤＡ（ｐｅｒｓｏｎａｌｄｉｇｉｔａｌａｓｓｉｓｔａｎｔ）等の全世界的にルーティング可能なＩＰ対応装置の普及とともに、公開アクセスＩＰネットワークが広く張りめぐらされている。とりわけ、近年の携帯無線技術の進歩および携帯電話システムの成長率は、場所に拘束されない通信に対する、市場の巨大な需要を示している。無線通信の役割は、ごく数年前の従来の音声および呼び出しモバイル無線サービスを大幅に越えた。最近、ネットワークの世界標準規格に関する公認の機関である国際電気通信連合（ＩＴＵ）は、国際移動通信規格（ＩＭＴ−２０００）を発表した。この標準規格では、携帯電話機、ＰＤＡ、携帯型コンピュータ等の無線モバイルクライアントによる広範囲なモバイルアクセスを可能にするいわゆる第３世代（３Ｇ）ネットワークを提案している。この第３世代ネットワークでは、モバイルクライアント、または移動クライアントはネットワーク資源へのアクセスを維持しながら自由に移動し、接続ポイントをある基地局から別の基地局へ変更することができる。３Ｇネットワークには、リンク層（レイヤ２）におけるモビリティを提供するものがある。しかし、将来のネットワーク（いわゆる４Ｇ）は、ＩＰ層（レイヤ３）におけるモビリティを提供すると予想されている。
【０００３】
インターネットアーキテクチャの進化およびインターネットの円滑な運用に関わる、ネットワークの設計者、運用者、供給業者、研究者からなる国際団体であるインターネット技術特別調査委員会（ＩＥＴＦ）は、ＩＰ層におけるモビリティ支援のための標準規格をいくつか提案している。これら提案された標準規格には、ＩＥＴＦのＲＦＣ２００２（別名、モバイルＩＰバージョン４（ＩＰｖ４））や「ＩＰｖ６におけるモビリティ支援」と題された草案「ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｉｐｖ６−１７」（別名、モバイルＩＰバージョン６）のようなモビリティ支援のための標準規格がある。この２つの標準規格は、本願明細書において参照として援用される。ＩＰｖ４およびＩＰｖ６で定義されるプロトコル運用によると、クライアントは、ネットワーク資源へのアクセスを維持しながらネットワーク上を移動し、接続ポイントをあるアクセスルータから別のアクセスルータへ変更することが可能になる。通常、この処理は、「レイヤ３（Ｌ３）ハンドオフ」と呼ばれる。
【０００４】
Ｌ３ハンドオフ処理をおこなう目的は、登録処理をつうじて移動クライアントのパケットルーティング情報を更新することである。クライアントは、「ホームアドレス」により、常に指定することができる。ここで、「ホームアドレス」とは、ホームネットワーク上のアクセスルータ（ホームルータ）により割り当てられるＩＰアドレス、またはクライアント自身により選択されたＩＰアドレスのことである。しかしながら、クライアントがフォーリンネットワーク上にあってホームネットワークから離れている場合、クライアントには、現在のネットワークへの接続ポイントを示す気付けアドレスが設定される。この気付けアドレスは、フォーリンネットワーク上のアクセスルータ（フォーリンルータ）のアドレスであり、ホームネットワークから離れて動作するクライアントは、この気付けアドレスをホームルータに登録する。そして、登録要求を受信したホームルータは、クライアント宛のパケットを途中で回収し、クライアントの気付けアドレスへ転送する。モバイルＩＰｖ６では、ホームネットワークから離れたクライアントは、ホームルータおよび通信中の相手先ノードに対し対応更新（ｂｉｎｄｉｎｇｕｐｄａｔｅ）を送信する。相手先ノードは、クライアントのようなモバイルクライアントであってもよいし、クライアントにデータを提供するサーバであってもよい。そして、対応更新を受信した相手先ノードは、ホームルータを介さずクライアントに対しパケットを直接転送する。
【０００５】
【発明が解決しようとする課題】
移動クライアントが、訪問したネットワークにおいてネットワーク接続を要求する場合、セキュリティ上の重大な問題が生じる。クライアントは、ネットワークアクセスが許可される前に、常に認証されなければならない。認証されないクライアントは、不正ＩＤまたは盗難ＩＤを用いて無料でネットワーク資源にアクセスしようとする不正利用者かもしれない。また、そのようなクライアントは、ネットワークの秩序ある運用を乱すためだけに、ネットワークアクセスを要求する悪意をもったノードかもしれない。同様に、クライアントは、自己にネットワーク接続を提供しているアクセスルータを認証したいと思うかもしれない。アクセスルータは、クライアントの通信を盗聴したり、どこかへ転送したり、ただ中断するだけの不正なルータかもしれない。現在、さまざまなアクセス技術で、数多くの認証メカニズムが実行、採用されている。例として、ＰＰＰおよび８０２．１１ネットワークの認証がある。これらのネットワークを利用する場合、リンク層で認証メカニズムが提供されるため、その認証メカニズムの適用範囲が特定のアクセス技術に限られてしまう、という欠点があった。従って、アクセス技術を選ばない認証メカニズムの提供が求められている。
【０００６】
【課題を解決するための手段】
上記の事情に鑑み、本発明は、ネットワーク層における認証メカニズムを用いることにより、アクセス技術を選ばない安全なネットワークアクセス方法を提供する。本発明は、モバイルクライアントにネットワークアクセスを許可する前に、モバイルクライアントおよびアクセスルータを互いに認証するネットワーク層プロトコルを提供する。本発明は、ルータ検出をキャリアとして用い、認証プロトコルを実行する。本発明の実施形態において、モバイルクライアントは、請求メッセージを送信し、接続サービスを要求する。この請求メッセージは、モバイルクライアントの身元証明書を含んでいる。この請求メッセージを受信したアクセスルータは、身元証明書が確認されるまでこの請求メッセージに対し応答しない。モバイルクライアントの身元証明書が確認されてはじめて、アクセスルータは応答し、モバイルクライアントに対し通知メッセージを返信する。従って、不正なモバイルクライアントのネットワークアクセスを防止できる。
【０００７】
アクセスルータからの通知メッセージは、アクセスルータの身元証明書を含んでいてもよい。このアクセスルータの身元証明書が正常に確認された場合のみ、モバイルクライアントは、このアクセスルータを介してネットワークアクセスを開始する。従って、モバイルクライアントが不正なアクセスルータを介してネットワークアクセスを開始してしまうことを防止できる。
【０００８】
請求および通知メッセージを用いることにより、ネットワークアクセスを安全にする上での利点が得られる。検出メカニズムは、モバイルクライアントとアクセスルータとがオフリンク接続を確立する際の第一歩である。すなわち、検出メカニズムを用いてモバイルクライアントおよびアクセスルータを認証することは、既存のプロトコルにとって無理のない拡張である。モバイルクライアントおよびアクセスルータの認証に検出メカニズムを用いることにより、プロトコル信号数を大幅に節約できる。プロトコル信号数の節約は、通信資源が貴重かつ高価であるモバイル無線ネットワークにとって重要である。検出メカニズムを用いるさらなる利点は、検出メカニズムがＩＰｖ４およびＩＰｖ６両方に共通であることである。従って、検出メカニズムをキャリアとして用い、モバイルクライアントおよびアクセスルータの認証を実行する本発明は、ネットワークがＩＰｖ４とＩＰｖ６とのいずれを用いるかにかかわらず、ネットワークにおいて実行可能である。
【０００９】
本発明にかかる認証プロトコルは、ＡＡＡインフラストラクチャに基づいて、ＡＡＡプロトコルにより提供される認証サービスおよびプロトコル信号を用いてもよい。ＡＡＡプロトコルにおいては、複数のドメインが定められ、各ドメインは少なくとも１つのＡＡＡサーバにより管理される。ＡＡＡサーバは、アテンダント、すなわちアクセスルータを介してモバイルクライアントに対しＡＡＡサービスを提供する。本発明では、請求メッセージに含まれるクライアントの身元証明書を確認するために、信用できる実体が必要である。クライアントが新たなフォーリンドメインに入った場合、信用できる実体は、クライアントのホームドメインを管理するＡＡＡサーバである。従って、この最初の認証過程のためにプロトコル信号がクライアントとホームサーバとの間を往復するため、通信の待ち時間を生じるかもしれない。しかしながら、クライアントがフォーリンドメインにとどまっている限りにおいて、ホームサーバは確認のために用いられない。例えば、クライアントがフォーリンドメイン内でアクセスルータを切り替えた場合は、このフォーリンドメインのサーバが信用できる実体になる。クライアントが同一のアクセスルータに接続を要求する場合、そのアクセスルータでさえも信用できる実体になってもよい。従って、本発明にかかる認証プロトコルに必要なプロトコル信号は、より短い距離を往復することにより、認証プロセスにより生じる通信の遅延が短縮化される。
【００１０】
本発明にかかる認証プロトコルは、対称および非対称鍵暗号方式等のいかなる鍵アルゴリズムを用いても実行可能である。これらの鍵は、本発明の認証過程に伴うプロトコル信号とともに配信されてもよい。これらの鍵が配信されることにより、２つの実体間に新たなセキュリティ関係が確立され、アドレス解決（ＡＲＰ／ＲＡＲＰ）等の近隣検出や実体間の以後の通信のためのプロトコル信号を安全にする。
【００１１】
本発明の別の実施形態においては、アクセスルータは、自らの身元証明書を含む通知メッセージを自発的に送信してもよい。この身元証明書を正常に確認した場合、クライアントは、このアクセスルータをインターネットへのゲートウェイとして使用する。この証明を確認できない場合には、自らの身元証明書を含む請求メッセージを送信することにより、認証過程を開始する。この請求メッセージは、上記で概説したように処理される。
【００１２】
本発明の別の実施形態においては、クライアントは、アクセスルータと通信中に、このアクセスルータに対し請求メッセージを送信してもよい。通信中でさえも、正当な実体が不正な実体と入れ替わる可能性は常にある。この請求メッセージを受けて、アクセスルータが自らの身元証明書を含む通知メッセージを送信し、よって、クライアントは通信中にアクセスルータを再認証できる。同様に、アクセスルータは、通信中のクライアントに対し有効期間の短い通知メッセージを送信してもよい。この通知メッセージに対し、クライアントは自らの身元証明書を含む請求メッセージを送信し、よって、アクセスルータはクライアントを再認証できる。
【００１３】
クライアントからの請求メッセージおよび／またはアクセスルータからの通知メッセージがチャレンジを含み、リプレイ攻撃から防御してもよい。
【００１４】
【発明の実施の形態】
ここで、本発明の好適な実施形態を図面を参照しつつ説明する。この図面において、同様の構成要素には同一の参照符号が付される。本明細書に記載されている実施形態は、性質上、例示的なものすぎず、本発明の範囲を限定するものではない。なお、本実施形態中に記載のネットワークでは、モバイルＩＰが用いられているが、本発明は、より広く、ＩＰｖ４およびＩＰｖ６等のいかなるＩＰベースの通信プロトコルを用いても実行可能である。
【００１５】
図１に、本発明が適用される第３世代の無線モバイルアクセスＩＰに対応したデータ通信ネットワーク１００を示す。本明細書の目的のため、データ通信ネットワーク１００は、無線移動体通信ネットワークに関するＩＭＴ−２０００規格およびＩＴＵの仕様に従うものとする。さらに、データ通信ネットワーク１００は、ＩＥＴＦで提案されているモバイルＩＰｖ４およびモバイルＩＰｖ６規格に従い、モバイルＩＰ支援を実行するものとする。したがって、勿論、本願では、一方のバージョンに特有の用語を他方のバージョンの対応する用語に置き換えて使用してもよい。例えば、「エージェント」という用語は、「アクセスルータ」や、単に「ルータ」という用語に置き換えて使用してもよい。同様に、「エージェント検出」は、「ルータ検出」と、「エージェント請求」は、「ルータ請求」と、「登録要求」は、「対応更新」と、それぞれ置き換えて使用してもよい。
【００１６】
無線モバイルアクセスＩＰに対応したデータ通信ネットワーク１００の中心には、多数の図示せぬ固定ノード、すなわち固定接続ポイントまたはリンクを有する固定ノードＩＰデータネットワークであるコアネットワーク１２０が備えられている。この通信ネットワーク内またはこの通信ネットワークを介し、また、インターネットプロトコルバージョン６（ＩＰｖ６）に従い、デジタルデータの送受信がなされる。上述したように、ＩＰｖ６は通信プロトコルのほんの一例でありＩＰｖ４等の通信プロトコルと置き換えることが可能である。コアネットワーク１２０のいくつかのノードは、図示せぬ従来のルータを有し、このルータは、従来のインターネットアドレッシングおよびルーティングプロトコルに従って中間ノードとして機能し、ネットワークに接続された送信元および送信先ノード間でデータパケットを転送する。
【００１７】
コアネットワーク１２０には、複数のゲートウェイルータ（ＧＲ）１３０が備えられており、これらがＩＰモバイルバックボーンを構成している。このＩＰモバイルバックボーンを構成するゲートウェイルータ１３０は、それ自体がコアネットワーク１２０のノードであり、コアネットワーク１２０を介して相互接続されている。各ゲートウェイ１３０には、モバイルクライアント１３５と通信可能な複数のアクセスルータ１４５が接続されている。このモバイルクライアントとしては、コードレス電話機、携帯電話機、携帯型コンピュータ、個人情報管理機器等の種類の異なるモバイル無線通信装置が利用可能である。アクセスルータ１４５は、ホームルータ（ＨＲ）およびフォーリンルータ（ＦＲ）として機能し、ゲートウェイルータ１３０を介してクライアント１３５をコアネットワーク１２０に接続する。アクセスルータ１４５は、アクセスネットワークのレイヤ３上の実体である。クライアント１３５は、無線アクセスポイント（ＡＰ）１５５を介してアクセスルータ１４５と通信する。このＡＰ１５５は、アクセスネットワークのレイヤ２上の実体である。一群のＡＰ１５５は、図１のサブネットワーク１５０を構成している。各アクセスルータ１４５は、サブネットワーク１５０を管理し、サブネットワーク１５０とデータネットワーク１００との間のインターフェースとしてネットワークリンクを提供する。クライアント１３５およびＡＰは、周知のＣＤＭＡ、Ｗ−ＣＤＭＡ、または同様なデジタルデータ通信技術を用い、互いに通信する。
【００１８】
モバイルＩＰｖ６に従い、各クライアント１３５には、ホームルータであるアクセスルータ１４５を含むホームサブネットワークが割り当てられる。このアクセスルータ１４５は、クライアント１３５の現在位置情報を保持し、クライアント１３５の現在位置にパケットを転送する。その他のアクセスルータ１４５は、フォーリンルータとして機能する。クライアント１３５は、ホームサブネットワークから離れている間、このフォーリンルータに「訪問する」ことができる。クライアント１３５が、任意の時刻にホームルータあるいはフォーリンルータのいずれかと通信する場合、いずれかのルータがネットワークリンクを確立し、クライアント１３５にネットワークアクセスを提供する。ネットワーク上のクライアント１３５およびアクセスルータ１４５は、従来のインターネットプロトコルを用いた従来の固定ノードデータネットワークと同様に、それぞれ一意のＩＰアドレスをもつ。
【００１９】
データ通信ネットワーク１００全体の中で、２つのレベルのハンドオフ過程が考えられる。第１のレベルは、マクロレベルハンドオフまたはレイヤ３ハンドオフであり、クライアントの位置の変化をともなう。この位置の変化とは、クライアントが、あるアクセスルータにより管理される無線サブネットワークから、別のアクセスルータにより管理される無線サブネットワークに移動することである。従って、Ｌ３ハンドオフにより、クライアントのネットワークリンクは必然的に変化する。第２のレベルは、マイクロレベルハンドオフまたはレイヤ２ハンドオフであり、サブネットワーク１５０内でのクライアントの位置変化をともなう。この場合、クライアントの無線リンクは変化するが、ネットワークリンクは変化しない。Ｌ２ハンドオフ処理は、無線携帯通信ネットワークにおいて一般的である。例えば、隣接するＡＰからのビーコン信号の強度を用いて隣接するＡＰの到達可能性を検出することは周知である。
【００２０】
図２は、モバイルＩＰｖ６に従って行われるモバイルクライアントによるＬ３ハンドオフ過程を示す簡略図である。図２において、データ通信ネットワーク１００は、コアネットワーク１２０およびコアネットワーク１２０に接続されるアクセスルータ１４５を含む。クライアント１３５は、初めは出発点Ａに位置し、中間地点Ｂを経由して地点Ｃに移動する。図２において、出発点Ａのクライアント１３５は、フォーリンルータであるアクセスルータ１４５（ＦＲ１）に管理されるフォーリンサブネットワーク内で動作し、ＦＲ１を介してコアネットワーク１２０に接続されている。一方、地点Ｃは、フォーリンルータであるアクセスルータ１４５（ＦＲ２）に管理されるフォーリンサブネットワーク内に位置している。モバイルクライアント１３５は、ＦＲ１に管理されるサブネットワークを通り抜け、ＦＲ２に管理されるサブネットワークに入る。従って、図２において考えられるＬ３ハンドオフは、ネットワークリンクをＦＲ１からＦＲ２へと切り替える際に行われる。
【００２１】
クライアント１３５が、出発点Ａから移動し中間地点Ｂに到着するとき、ある時点でＦＲ１とのさらなる無線通信が失敗し始める。クライアント１３５は、ＦＲ１に管理されるサブネットワーク１５０を離れ、ＦＲ２に管理されるサブネットワーク１５０に入るところである。クライアント１３５が中間地点Ｂを通りすぎ、Ｌ２ハンドオフが行われると、クライアント１３５の無線リンク先は、ＦＲ１に管理されるサブネットワークのＡＰからＦＲ２に管理されるサブネットワークのＡＰに変わる。到着地点Ｃに近づくにつれ、クライアント１３５は、Ｌ３ハンドオフ、すなわちＦＲ２との間でモバイルＩＰ登録をおこなう。この登録過程では、モバイルＩＰｖ６に定められるルータ検出が最初に行われる。このルータ検出により、クライアント１３５は隣接するアクセスルータ１４５を検出し、このアクセスルータ１４５のリンク層アドレスを特定し、このアクセスルータ１４５への経路についての到達可能性情報を保持する。このために、ルータ検出において、一対のＩＣＭＰ（ＩｎｔｅｒｎｅｔＣｏｎｔｒｏｌＭｅｓｓａｇｅＰｒｏｔｏｃｏｌ）パケットタイプ、すなわちルータ請求およびルータ通知が定義される。ルータ請求は、クライアントにより送信され、隣接するアクセスルータにルータ通知の生成および返信を要求するメッセージである。アクセスルータ１４５は、定期的またはクライアント１３５からのルータ請求に対して、ルータ通知を送信することにより、自らの存在を通知する。ルータ通知が含む情報に基づき、クライアント１３５は気付けアドレス（ＣｏＡ）を設定する。
【００２２】
ＦＲ２からルータ通知を受信すると、クライアント１３５はこの通知内の情報に基づいて気付けアドレスを生成、設定する。そして、クライアント１３５は、新しい気付けアドレスおよびクライアント１３５の不変のホームＩＰアドレスを含む対応更新をホームルータに送信することにより、新しい気付けアドレスを登録する。ホームルータは、アドレスの対応情報を記録するキャッシュ内のクライアントのルーティング情報を更新し、その結果、クライアント１３５とＦＲ２との間にＬ３リンクが確立される。以後、クライアント１３５のホームＩＰアドレスに送信されるパケットは、ホームルータにより途中で回収され、ＦＲ２にトンネル送信され、ＦＲ２からクライアント１３５に配信される。パケットの迂回ルーティングにより生ずるパケット遅延を解消するため、以後パケットをクライアント１３５に直接転送可能なあらゆる相手先ノードに対しても、対応更新が送信される。
【００２３】
モバイルデータ通信の人気が高まるにつれ、悪意をもったクライアントがネットワークアクセスを試みる可能性も高くなる。このクライアントは、不正ＩＤまたは盗難ＩＤを用いてネットワーク資源に無料でアクセスしようとする不正利用者かもしれず、ネットワークの秩序ある運用に対する脅威にほかならない。従って、この悪意をもったクライアントをふるい落とすために、ネットワークアクセスを要求するクライアントは、ネットワークアクセスが許可される前に、常に認証されなければならない。同様に、クライアントは、ネットワークアクセスを開始する前に、接続サービスを提供するアクセスルータの認証を望むかもしれない。アクセスルータの中には、クライアントの通信を盗聴したり、どこかへ転送したり、ただ中断するだけの不正なアクセスルータがあるかもしれない。本発明が提供する双方向セキュリティプロトコルでは、クライアントおよびアクセスルータを相互に認証し、その結果、クライアントはゲートウェイとして用いる前に悪意をもったアクセスルータを特定でき、アクセスルータは転送サービスを提供する前に悪意をもったクライアントを特定できる。
【００２４】
本発明にかかるセキュリティメカニズムは、認証、認可、および課金（ＡＡＡ）プロトコルに基づいている。ＲＡＤＩＵＳやＤＩＡＭＥＴＥＲ等のＡＡＡプロトコルは、今日、インターネット上で使用されており、ダイアルアップコンピュータに対して、認証、認可、および課金サービスを提供している。このようなＡＡＡ管理サービス、特にＡＡＡサービスにより提供される認証サービスは、モバイルＩＰにおいても同様に有用である。実際、モバイルＩＰは、基本的な枠組みにほとんど変更を加えないＡＡＡインフラストラクチャ上で実行可能である。例えば、ＡＡＡプロトコルにおけるクライアントは、モバイルＩＰのモバイルノードと考えられ、ＡＡＡプロトコルにおけるアテンダントは、モバイルＩＰのアクセスルータに相当する。モバイルクライアントおよびアクセスルータの機能を向上させ、これらがＡＡＡメッセージを解読可能であれば、ＡＡＡインフラストラクチャ上でモバイルＩＰが実行可能になる。
【００２５】
図３および４は、ネットワークアクセスサービス（ＮＡＳ）およびモバイルＩＰが実行される、一般的ＡＡＡネットワークモデルを示す簡略図である。管理ドメインは、１または共通の管理の下で動作する複数のネットワークからなる。図１に示すデータ通信ネットワーク１００内において、多数の管理ドメインが定義されてもよい。しかし、図の簡略化のため、図３および４に示すＡＡＡネットワークには、２つの管理ドメインのみが示されている、すなわち、広域インターネットにより隔てられたホームドメイン３００およびフォーリンドメイン４００である。各ドメインは、ドメインの構成要素に対しＡＡＡサービスを提供するＡＡＡサーバを備えている。ホームドメイン３００は、ホームサーバＡＡＡＨ３１０により管理されている。フォーリンドメイン４００は、フォーリンサーバＡＡＡＦ４１０により管理されている。各ホームおよびフォーリンドメインは、ドメイン内に配置されるアテンダントをさらに備えている。ただし、図３および４では、フォーリンドメイン４００のみが、２つのアテンダント４２０および４２１を備えている。ＡＡＡプロトコルに従って、アテンダント４２０および４２１は、クライアント３２０とローカルドメイン４００との間のサービスインターフェースを提供する。この実施形態では、クライアント３２０は、ホームドメイン３００からフォーリンドメイン４００に移動し、管理ドメイン４００内のアテンダント４２０または４２１のいずれかからのサービスを望んでいるものとする。上述したように、モバイルＩＰは、図３および４に示すＡＡＡネットワーク上で実行される。モバイルＩＰの場合、アテンダントは、実際上、モバイルクライアントに対しネットワークアクセスサービスを提供するアクセスルータ（ＡＲ）である。従って、「アテンダント」という用語は、「アクセスルータ」または、単に「ＡＲ」という用語と置き換えて使用してもよい。
【００２６】
ＡＡＡプロトコルにより提供される重要なサービスの１つは、認証である。一般的に、ＡＡＡ認証メカニズムは以下のように機能する。ＡＡＡに対応した第１の実体が通信先に望む第２の実体に対し証明書を提示し、第２の実体が第１の実体の証明書を正常に確認可能な場合のみ、２つの実体間の通信が許可される。この証明書は、２つの実体間でセキュリティ関係（ＳＡ）が確立される際に定義される鍵アルゴリズムを用いて確認される。ＡＡＡプロトコルは、異なる鍵アルゴリズムを用いても機能するように設計されている。あるアルゴリズムは、公開鍵インフラストラクチャに基づき、別のアルゴリズムは、対称鍵の配信に基づいている。ＡＡＡサーバは、鍵の配信センターとして機能し、アテンダントやクライアント等のＡＡＡの実体の要求により、ＡＡＡの２つの実体間で提示される証明書を確認するために用いられる鍵を生成、配信する。２つのＡＡＡの実体に対し鍵を配信することにより、これらの間にセキュリティ関係が確立される。説明上、図３および４に示すＡＡＡネットワークでは、対称鍵または共有秘密鍵アルゴリズムが用いられるものとする。対称鍵アルゴリズムは、他の鍵アルゴリズムよりも用い易く、インターネット全体への適応性という問題に解決策を提供する。しかしながら、本発明を実施するにあたり、公開鍵方式等の非対称鍵アルゴリズムや他の鍵アルゴリズムを用いてもよいことは、当業者にとっては明らかであろう。また、認証トークンを用いてもよい。
【００２７】
図３および４に示すＡＡＡネットワークには、暗黙のセキュリティモデルが存在する。図５は、このような暗黙のセキュリティモデルを示しており、矢印は、初めから確立されていると想定されるセキュリティ関係を示す。まず、矢印ＳＡ１が示すように、ＡＡＡＦ４１０とＡＲ４２０および４２１との間にセキュリティ関係が確立されているものとする。ＡＲはＡＡＡＦ４１０に管理されるドメインに位置しており、両者間にはすでに信用が確立されているはずであるので、ＡＲ４２０および４２１とＡＡＡＦ４１０との間にＳＡ１が確立されているものとしてよいであろう。次に、ＡＡＡＨ３１０とＡＡＡＦ４１０との間にセキュリティ関係が確立されているものとする。これらのＡＡＡサーバは、初め、両者間にセキュリティ関係を確立している必要はないが、必要に応じて両者間にセキュリティ関係を確立する能力をもたねばならない。矢印ＳＡ２が示すセキュリティ関係は、２つのＡＡＡサーバ間で直接的に、または仲介ＡＡＡサーバ２００を介して間接的に、確立可能である。最後に、矢印ＳＡ３が示すように、クライアント３２０とＡＡＡＨ３１０との間にセキュリティ関係が確立されているものとする。クライアント３２０は、ＡＡＡＨ３１０が位置するホームドメイン３００からスタートしているので、ＳＡ３が確立されているものとしてよいであろう。従って、ＡＡＡＨ３１０は、最初にクライアントを認証可能な唯一の実体である。
【００２８】
本発明の重要な特徴は、本発明ではルータ検出メカニズムが「キャリア」として用いられ、モバイルＩＰにおいてＡＡＡセキュリティプロトコルを実行する点である。本発明では、ルータ請求およびルータ通知が拡張され、既存のＡＡＡプロトコルにモバイルＩＰ認証機能を付加する。
【００２９】
＜最初のルータ検出（新しいドメインに入る場合）＞
図６は、本発明の実施形態にかかる、ルータ検出プロトコルを用いたネットワークアクセス認証過程を示すフローチャートである。図７は、図６に示す過程の簡略図である。この実施形態では、クライアント３２０は、ＡＲ４２０および４２１、またはＡＡＡＦ４１０のいずれともセキュリティ関係を確立していないものとする。すなわち、クライアント３２０は、以前にフォーリンドメイン４００に訪問したことがないか、もしくは長期間フォーリンドメイン４００から離れていたためＡＲ４２０、ＡＲ４２１、およびＡＡＡＦ４１０との間で以前に確立されたセキュリティ関係が無効になったものとする。
【００３０】
クライアント３２０は、フォーリンドメイン４００に入り、リンクが張られているアクセスルータによるネットワークアクセスを要求する。ステップ５０１において、クライアント３２０は、拡張ルータ請求メッセージ（ＲＳ＋）を送信することによりルータ検出を開始する。これはマルチキャストメッセージであり、クライアントと同じリンク上のすべてのアクセスルータにより受信される。通常のルータ請求メッセージとは異なり、これはクライアントの身元証明書を含む。この身元証明書は、標準のルータ請求パケットの拡張という形で送信される。ＲＳ＋は、標準のルータ請求メッセージ（ＲＳ）と同様の各種構成要素を含む。また、ＲＳ＋は、ネットワークアクセス識別子（ＮＡＩ）またはＩＰアドレスになりうるクライアントの識別子（ｃｌｉｅｎｔ_ｉｄ）と、クライアントの署名とを含む。この署名は、ＡＡＡＨ３１０と共有するクライアントの秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）により暗号化されたＲＳ＋の要約である。従って、ＲＳ＋は以下のように表現される。
ＲＳ＋ｃｌｉｅｎｔ_ｉｄ＋クライアントによる署名
【００３１】
クライアントの共有秘密鍵は、クライアント３２０とＡＡＡＨ３１０との間に確立されるセキュリティ関係ＳＡ３（図５参照）により定義される。従って、ＡＡＡＨ３１０は、クライアントの共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を保有し、ＲＳ＋に格納されたクライアントの署名を確認する。ＡＲ４２０および他のアテンダントは、クライアント３２０からＲＳ＋を受信する。しかしながら、上述したように、ＡＲ４２０はクライアント３２０とセキュリティ関係を確立していないため、クライアント３２０の身元を確認する共有秘密鍵を保有しない。標準のルータ検出メカニズムによると、アクセスルータはルータ請求メッセージに応じてルータ通知メッセージを返信する。しかしながら、本発明では、クライアント３２０が正常に認証されるまで、ＡＲ３２０および他のアクセスルータはルータ通知メッセージを返信しない。
【００３２】
ＡＲ４２０は、クライアント３２０の確認をＡＡＡＦ４１０に委任する。ＡＲ４２０は、ＡＡＡ要求メッセージ（ＡＡＡＲｅｑ）を生成し、ＡＡＡＦ４１０に送信する（ステップ５０３）。このＡＡＡＲｅｑは、クライアント３２０からのＲＳ＋全体のコピーを含む。ＡＲ４２０からＡＡＡＦ４１０へ送信されたＡＡＡＲｅｑは、両者間に確立されたセキュリティ関係ＳＡ１に基づいて保護される。ＡＡＡＲｅｑは、ＲａｄｉｕｓやＤＩＡＭＥＴＥＲ等のＡＡＡプロトコルに従って生成される。ＡＡＡメッセージを生成する際の好適な手順については、「Ｄｉａｍｅｔｅｒ基本プロトコル」と題されたＩＥＴＦの草案「ｄｒａｆｔ−ｉｅｔｆ−ｄｉａｍｅｔｅｒ−０７.ｔｘｔ」および「ＤｉａｍｅｔｅｒモバイルＩＰ拡張仕様」と題されたＩＥＴＦの草案「ｄｒａｆｔ−ｃａｌｈｏｕｎ−ｄｉａｍｅｔｅｒ−ｍｏｂｉｌｅｉｐ−１２.ｔｘｔ」の中で論じられている。なお、この２つの草案は本明細書において参照として援用される。
【００３３】
上述したように、ＡＡＡＦ４１０は、クライアント３２０とセキュリティ関係を確立しておらず、従って、クライアントの身元を確認する共有秘密鍵を保有していない。しかし、ＲＳ＋に格納されたクライアントの識別子により、ＡＡＡＦ４１０はクライアント３２０のホームドメインがホームドメイン３００であることを認識する。そして、ＡＡＡＦ４１０は、ＡＡＡＨ３１０との間に確立されたセキュリティ関係ＳＡ２を使って、ホームドメイン３００に位置するＡＡＡＨ３１０に対しＲＳ＋のコピーとＡＡＡＲｅｑを転送する（ステップ５０５）。
【００３４】
ＡＡＡＦ４１０からＡＡＡＲｅｑを受信すると、ＡＡＡＨ３１０は、クライアントの共有秘密鍵を用いてＡＡＡＲｅｑに格納されたクライアントの署名を復号することにより、クライアント３２０の身元を確認する。クライアントが正当な身元を提示すれば、ＡＡＡＨ３１０はクライアントの身元を正常に確認できるはずである。クライアントの身元を確認できない場合、ＡＡＡＨ３１０はＡＡＡ応答メッセージ（ＡＡＡＲｅｐ）を生成し、ＡＡＡＦ４１０を介してＡＲ４２０に送信する。このＡＡＡＲｅｐは、ＡＡＡＨ３１０がクライアント３２０を認証できない旨を示す認証結果を含む。ＡＡＡＲｅｐも、ＲａｄｉｕｓやＤＩＡＭＥＴＥＲ等のＡＡＡプロトコルに従って生成される。ＡＡＡＲｅｐを受信すると、ＡＲ４２０はクライアント３２０からのルータ請求メッセージを無視し、ルータ通知メッセージを返信しない。従って、認証されないクライアントによるネットワーク資源へのアクセスは防止される。
【００３５】
ＡＡＡＨ３１０がクライアント３２０の身元を正常に確認した場合、ＡＡＡＨ３１０は、ＡＡＡ応答（ＡＡＡＲｅｐ）を生成しＡＡＡＦ４１０に送信することにより、ＡＡＡＦ４１０からのＡＡＡＲｅｑに応答する（ステップ５０７）。このＡＡＡＲｅｐは、２つの共有秘密鍵を含む。これらのうち一方は、クライアント３２０とＡＲ４２０との間で用いられ、他方は、クライアント３２０とＡＡＡＦ４１０との間で用いられる。これらの共有秘密鍵はＡＡＡＨ３１０により生成され、ＡＡＡＦ４１０、ＡＲ４２０、およびクライアント３２０に配信され、クライアント３２０とＡＡＡＦ４１０との間およびクライアント３２０とＡＲ４２０との間にセキュリティ関係を確立する。これらの共有秘密鍵である（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）は、それぞれ複製される。複製された共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）は、これらの真実性および機密性を守るため、クライアント３２０と共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を用いてＡＡＡＦ４１０により暗号化され、クライアント３２０に配信される。元の鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）は復号化され、ＡＲ４２０およびＡＡＡＦ４１０にそれぞれ配信される。従って、ＡＡＡＨ３１０からＡＡＡＦ４１０に送信されるＡＡＡＲｅｐは、以下のように表現される。
ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ＋ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ＋ＡＡＡＨにより暗号化された（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ＋ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）
【００３６】
ＡＡＡＨ３１０からのＡＡＡＲｅｐにより、ＡＡＡＦ４１０はクライアント３２０が信用できることを認識する。そして、ＡＡＡＦ４１０は、ＡＡＡＲｅｐから復号化された共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を抽出し、キャッシュに格納する。この抽出された共有秘密鍵は、クライアント３２０からのメッセージを認証するため、ＡＡＡＦ４１０により用いられる。そして、ＡＡＡＦ４１０は、ＡＡＡＲｅｐをＡＲ４２０に転送する（ステップ５０９）。ＡＡＡＦ４１０からのＡＡＡＲｅｐにより、ＡＲ４２０はクライアント３２０の身元が正常に認証されたことを認識する。そして、ＡＲ４２０は、ＡＡＡＲｅｐから復号化された共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を抽出し、キャッシュに格納する。この共有秘密鍵は、クライアント３２０からのメッセージを認証するため、ＡＲ４２０により用いられる。そして、ＡＲ４２０は、拡張ルータ通知（ＲＡ＋）を生成し、クライアント３２０に送信する（ステップ５１１）。このＲＡ＋は、標準のルータ通知メッセージ（ＲＡ）、ＡＲ４２０の識別子（ＡＲ_ｉｄ）、および共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）により暗号化された共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を含む。このＲＡ＋は、さらにＡＲ４２０の署名を含む。この署名は、ＡＲ４２０がＡＡＡＦ４１０から受信した共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）により暗号化されたＲＡ＋の要約である。従って、このＲＡ＋は以下のように表現される。
ＲＡ＋ＡＲ_ｉｄ＋ＡＡＡＨにより暗号化された（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ＋ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）＋ＡＲによる署名
【００３７】
ＡＲ４２０からＲＡ＋を受信すると、クライアント３２０は受信したＲＡ＋を認証する。まず、クライアント３２０は、ＡＡＡＨ３１０と共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を用いて、共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を復号化する。これらの秘密鍵が正常に復号化された場合、これらの鍵はクライアント３２０が信用するＡＡＡＨ３１０により証明されることから、クライアント３２０はこれらの秘密鍵を信用できる。次に、クライアント３２０は、復号化された秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を用いて、ＡＲ４２０の署名を復号化する。署名が正常に復号化された場合、ＡＲ４２０の身元はクライアント３２０が信用する秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）により確認されることから、クライアント３２０はＡＲ４２０を信用できる。また、署名が正常に復号化されることにより、クライアント３２０に対しＲＡ＋の信頼性が保証される。クライアント３２０およびＡＲ４２０に配信される共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）により、クライアント３２０とＡＲ４２０との間に新しいセキュリティ関係ＳＡ４（図８参照）が確立される。クライアント３２０およびＡＡＡＦ４１０に配信される共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）により、クライアント３２０とＡＡＡＦ４１０との間に新しいセキュリティ関係ＳＡ５が確立される。
【００３８】
ＡＲ４２０の署名を認証できない場合、クライアント３２０はＡＲ４２０からのＲＡ＋を無視し、認証可能な証明書を含む他のアクセスルータからのＲＡ＋を待つ。従って、クライアント３２０が不正なアクセスルータを介してネットワークアクセスを開始してしまうことを防止できる。
【００３９】
図６および７に示す認証過程は、長時間を要し、かなりの通信待ち時間を生じるであろう。この通信待ち時間は、主にＡＡＡメッセージがＡＡＡＦ４１０とＡＡＡＨ３１０とを隔てる広域インターネットを行き来するために要する時間である。ＡＡＡメッセージがＡＡＡＦ４１０あるいはＡＡＡＨ３１０に送信される場合、常に、いくらかの待ち時間を伴う。図６および７に示す最初の認証過程では、これら遠く離れたサーバと通信しなければならない。しかしながら、もしＡＲ４２０およびＡＡＡＦ４１０がＡＡＡＦ４１０あるいはＡＡＡＨ３１０によらずにクライアントを認証できれば、認証メカニズムに伴う待ち時間が短縮化される。
【００４０】
＜以降のルータ検出（同一ドメイン内で、新しいアクセスルータを検出する場合）＞
クライアント３２０は、ドメイン４００内を移動し、クライアント３２０の身元を認証していない別のアクセスルータと接続してもよい。図９は、本発明の別の実施形態に基づき、このような場合に行われる認証ルータ検出を示すフローチャートである。図１０は、図９に示す過程の簡略図である。図９および１０において、図６および７に示すＡＲ４２０との最初の認証過程を経た後、クライアント３２０は、ＡＲ４２０に管理されるサブネットワークを離れ、ＡＲ４２１に管理されるサブネットワークに入るものとする。ＡＲ４２１を介してネットワークにアクセスするため、クライアント３２０はＲＳ＋を再び送信する（ステップ７０１）。今回送信されるＲＳ＋は、図６および７に示す最初の認証過程で用いられたものと同様のメッセージを含み、以下のように表現される。
ＲＳ＋ｃｌｉｅｎｔ_ｉｄ＋クライアントによる署名
【００４１】
しかしながら、本実施形態のＲＳ＋に含まれる署名は、共有鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）により暗号化されるため、ＡＲ４２１は署名を確認することができない。そこで、ＡＲ４２１は、ＡＡＡＲｅｑを生成しＡＡＡＦ４１０に送信することにより、クライアント３２０の確認をＡＡＡＦ４１０に委任する（ステップ７０３）。ＡＲ４２１からのＡＡＡＲｅｑは、ＲＳ＋全体のコピーを含む。ＡＡＡＦ４１０は、図６および７に示す先の認証過程において共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を取得しているため、クライアント３２０の身元を認識できるはずである。ＡＡＡＦ４１０は、ＡＡＡＨ３１０によることなく、共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）でクライアント３２０の署名を復号化することにより、クライアント３２０の身元を確認する。クライアント３２０の署名を確認できない場合、ＡＡＡＦ４１０は、ＡＡＡＲｅｑを生成し、ＡＲ４２１に送信する（ステップ７０５）。これにより、ＡＲ４２１に対し、クライアント３２０が信用できない旨を知らせる。ＡＲ４２１は、クライアント３２０からのＲＳ＋を無視する。クライアント３２０の署名が正常に確認された場合、ＡＡＡＦ４１０は、クライアント３２０とＡＲ４２１との間で共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）を生成する。この秘密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）は、複製される。複製により２つとなった秘密鍵の一方はそのまま暗号化されず、他方は共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）により暗号化される。ＡＡＡＦ４１０は、暗号化されていない鍵と暗号化された鍵とをＡＡＡＲｅｑに格納し、ＡＲ４２１に送信する（ステップ７０５）。従って、ＡＡＡＦ４１０からＡＲ４２１に送信されるＡＡＡＲｅｐは、以下のように表現される。
ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ＋ＡＡＡＦにより暗号化された（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）
【００４２】
ＡＡＡＦ４１０からのＡＡＡＲｅｐにより、ＡＲ４２１はクライアント３２０が信用できることを認識する。そして、ＡＲ４２１は復号化された秘密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）を抽出し、キャッシュに格納する。この格納された秘密鍵は、クライアント３２０からの以後のメッセージを認証するため、ＡＲ４２１により用いられる。ＡＲ４２１は、ＲＡ＋を生成し、クライアント３２０に送信する（ステップ７０７）。ＡＲ４２１からのＲＡ＋は、以下のように表現される。
ＲＡ＋ＡＲ_ｉｄ＋ＡＡＡＦにより暗号化された（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）＋ＡＲによる署名
【００４３】
ＡＲ４２１からＲＡ＋を受信すると、クライアント３２０は、共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を用いて復号化し、秘密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）を抽出する。もしこの鍵が正常に復号化されたら、クライアント３２０はこの鍵を信用できる。クライアント３２０は、共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）を用いてＡＲ４２１の署名を復号化することにより、ＲＡ＋を認証する。署名が正常に復号化された場合、クライアント３２０はＡＲ４２１およびＲＡ＋の真実性を信用できる。クライアント３２０およびＡＲ４２１に配信される共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）により、両者間に新しいセキュリティ関係が確立される。署名を復号化できない場合、クライアントはＡＲ４２１からのＲＡ＋を無視し、認証可能な署名を含む他のアクセスルータからのＲＡ＋を待つ。
【００４４】
図９および１０に示す、以降の認証過程は、図６および７に示す認証過程と比較して迅速に行われる。これは、図９および１０に示す認証過程では、ＡＡＡＨ３１０とメッセージをやり取りする必要がなく、従って、プロトコル信号がより短い距離を往復するためである。
【００４５】
＜以降のルータ検出（同一アクセスルータを検出する場合）＞
各ＲＡ＋には、有効期間がある。従って、同一のアクセスルータに接続している場合でも、先のＲＡ＋の有効期間が経過する前に、クライアントは同一のアクセスルータとの認証過程を経なければならない。この場合、図１１および１２に示すように、本発明にかかる認証過程において、プロトコル信号は最短距離を往復する。図１１および１２では、クライアント３２０は、ステップ８０１においてＲＳ＋をＡＲ４２０に送信する。ＲＳ＋は、以下のように表現される。
ＲＳ＋ｃｌｉｅｎｔ_ｉｄ＋クライアントによる署名
【００４６】
署名は、図６および７に示す最初の認証過程においてクライアント３２０が取得した共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）により暗号化される。ＡＲ４２０は、クライアント３２０と同一の鍵を共有しているため、クライアント３２０の身元を認識できるはずである。ＡＲ４２０は、ＡＡＡＦ４１０によらずに、共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を用いて署名を復号化することにより、クライアント３２０の身元を確認する。クライアント３２０の身元を確認できない場合、ＡＲ４２０はＲＳ＋を無視する。クライアント３２０の身元を正常に確認した場合、ＡＲ４２０は、ＲＡ＋を生成し、クライアント３２０に送信する。本実施形態のＲＡ＋は、以下のように表現される。
ＲＡ＋ＡＲ_ｉｄ＋ＡＲによる署名
【００４７】
従って、クライアント３２０とＡＲ４２０との通信は、プロトコル信号が最短距離を往復するため最速の認証メカニズムである。
【００４８】
＜非請求ルータ通知＞
アクセスルータは、認証可能なＲＳ＋の受信を待つのではなく、ＲＡ＋を定期的に送信してもよい。図１３において、ＡＲ４２０および４２１はＲＡ＋を定期的に送信するものとする。ＲＡ＋は、以下のように表現される。
ＲＡ＋ＡＲ_ｉｄ＋ＡＲによる署名
【００４９】
ＡＲ４２０から送信されるＲＡ＋は、ＲＡとＡＲ４２０の署名とを含む。ＡＲ４２１から送信されるＲＡ＋は、ＲＡとＡＲ４２１の署名とを含む。クライアント３２０は、図６および７に示すＡＲ４２０との最初の認証過程を以前に経ているものとする。先の認証過程を通じて、クライアント３２０とＡＲ４２０との間、およびクライアント３２０とＡＡＡＦ４１０との間には、セキュリティ関係が確立されている。ＡＲ４２０からのＲＡ＋がクライアント３２０に到達していれば、クライアント３２０はＲＡ＋を認証できるはずである。従って、クライアント３２０は、ＡＲ４２０を介して安全にネットワークアクセスを開始できる。受信するいかなるＲＡ＋も認識できない場合、クライアントは、ＲＳ＋を送信することにより、図６および７に示す最初の認証過程を経なければならない。
【００５０】
＜再認証＞
通信中のクライアントおよびＡＲのどちらも常に、本発明の認証過程を開始し、互いに再認証してよい。これは、通信中でさえも悪意をもった実体が正当な実体と入れ替わる可能性が常にあるという理由から重要である。クライアントは、ＡＲとの通信中、ＲＳ＋を送信することにより、いつでもこの過程を開始してよい。ＡＲは、クライアントによる再認証に対しＲＡ＋をクライアントに返信することにより、ＲＳ＋に応答できるはずである。同様に、ＡＲは、クライアントを収容している間、クライアントを再認証できる。ＡＲは、有効期間の非常に短いユニキャストルータ通知メッセージをクライアントに送信することにより、クライアントの再認証を開始する。このルータ通知メッセージは有効期間が非常に短いことから、クライアントは、ＡＲがまもなくクライアントへの接続サービスを停止することを認識する。クライアントは、ＲＳ＋を送信し同一リンク上の利用可能な他のアクセスルータを検出することにより、このようなルータ通知メッセージに応答する。そして、ＡＲは、クライアントから送信されたＲＳ＋を認証する。
【００５１】
＜旧プロトコルとの相互運用＞
ネットワーク全体において、本発明にかかる拡張ルータ検出メカニズムをサポートできるドメインと、標準のルータ検出メカニズムのみをサポートできるドメインとが混在してもよい。従って、標準のルータ検出メカニズムのみをサポートするクライアントが、本発明にかかる拡張ルータ検出メカニズムをサポートするドメインに移動する場合があってもよいし、また、拡張ルータ検出メカニズムをサポートするクライアントが、標準のルータ検出メカニズムのみをサポートするドメインに移動する場合があってもよい。どちらの場合も、本発明にかかる認証プロトコルは、標準のルータ検出メカニズムの運用の妨げとはならない。
【００５２】
まず、拡張ルータ検出メカニズムをサポートするクライアントが、標準のルータ検出メカニズムのみをサポートするドメイン内において接続サービスを受けようとする場合、クライアントはＲＳ＋を送信する。しかしながら、隣接するアクセスルータは、ＲＳ＋に加えられた新しい拡張部分を認識できず、従って、この拡張部分を無視する。アクセスルータは、ＲＳ＋をｒとして処理し、ＲＡを返信する。ここで、この「認証されていない」ルータ通知メッセージを用いるか否かはクライアント次第である。
【００５３】
次に、標準のルータ検出メカニズムのみをサポートするクライアントが、本発明にかかる拡張ルータ検出メカニズムをサポートするドメイン内において接続サービスを受けようとする場合、クライアントは、いかなる新しい拡張をも含まないＲＳを送信する。このような「認証されない」ルータ請求メッセージを受信した場合、ＲＡ＋を返信するか、あるいは全く応答しないかは、隣接するアクセスルータ次第である。
【００５４】
どちらの場合であっても、本発明にかかる拡張ルータ検出メカニズムをサポートするクライアントおよびＡＲは、通信相手が拡張ルータ検出メカニズムをサポートできるか、または標準のルータ検出メカニズムのみをサポートできるのかを検出し、それに応じて応答できる。認証されていないメッセージに対し応答するか、または受け取るかは、ネットワークの設計方針次第である。
【００５５】
＜リプレイ攻撃に対する防御＞
リプレイ攻撃とは、盗難パスワードの単なる再利用である。パスワード送信中にクラッカーがそのパスワードを盗聴できれば、クラッカーはそれ以降いつでも使用できるパスワードのコピーを手に入れることになる。たとえパスワードが暗号化されてやり取りされていたとしても、クラッカーは、以前に取得した通信を単に再実行することにより、ログインできるかもしれない。本発明にかかる認証プロトコルは、チャレンジに関する拡張を加えることにより、リプレイ攻撃に対する防御を設けることができる。
【００５６】
図１４は、チャレンジ方式を用いてリプレイ攻撃に対する防御を設ける本発明の実施形態を示すフローチャートである。図１４においては、クライアント３２０は、ＡＲ４２０またはＡＡＡＦ４１０と通信したことがなく、従って、図６および７に示す最初の認証過程を経なければならないものとする。まず、クライアント３２０は、ＲＳを送信する（ステップ１００１）。ＡＲ４２０は、ＲＳを受信するが、ＲＳを送信したクライアントの身元が認証されるまで信用できない。ＲＳを送信したクライアントは、クライアント３２０との過去の通信を盗聴し、クライアント３２０の識別情報を盗み、偽造ＩＤを使ってネットワークにアクセスする悪意をもったノードかもしれない。
【００５７】
クライアント３２０からのＲＳに対する返信として、ＡＲ４２０は、クライアントの身元およびＲＳの真実性を確認する（ステップ１００３）。具体的には、ステップ１００３において、ＡＲ４２０は、チャレンジに関する拡張とＲＡをクライアント３２０に送信する。このチャレンジに関する拡張は、ＡＲ４２０により生成された乱数を含む。ＡＲ４２０からのＲＡをきっかけとして、クライアント３２０は、拡張ルータ請求メッセージ（ＲＳ*）を生成、送信する（ステップ１００５）。ＲＳ*は、ＲＳと、クライアントの識別子、すなわちクライアントのＩＰアドレスまたはＮＡＩと、秘密鍵の要求とを含む。この秘密鍵は、ＡＲ４２０と共有され、ＡＲ４２０とのセキュリティ関係を確立する。ＲＳ*は、さらに２つのチャレンジに関する拡張を含む。一方のチャレンジに関する拡張は、ステップ１００３においてクライアントがＡＲ４２０から受信したチャレンジのコピーを含み、他方のチャレンジに関する拡張は、クライアント自身により生成された乱数を含む。最後に、ＲＳ*は、クライアント３２０とＡＡＡＨ３１０との間で共有される秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を用いて暗号化されるクライアント３２０の署名を含んだ認証拡張を含む。従って、本実施形態において、ＲＳ*は以下のように表現される。
ＲＳ＋ｃｌｉｅｎｔ_ｉｄ＋ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ_ｒｅｑｕｅｓｔ＋Ｃｈａｌ_ＡＲ＋Ｃｈａｌ_ｃｌｉｅｎｔ＋クライアントによる署名
【００５８】
クライアント３２０からＲＳ*を受信すると、ＡＲ４２０は、チャレンジに関する拡張（Ｃｈａｌ_ＡＲ）をチェックし、この拡張に含まれる乱数がステップ１００３においてクライアントに送信した乱数と同一であるかを調べる。乱数が同一の場合、ＲＳ*は、事実上、ステップ１００３においてＡＲ４２０がクライアント３２０に送信したチャレンジに対する応答であるといえる。乱数が一致しない場合、おそらくＲＳ*は、盗難ＩＤを使ってクライアント３２０だと偽る悪意をもったノードからのものであるため、ＡＲ４２０はこのＲＳ*を無視しなければならない。乱数が一致した場合、以降の認証過程は、図６および７において述べた過程と同様である。
【００５９】
クライアント３２０の身元がＡＡＡＨ３１０により正常に確認された場合、ＡＲ４２０は、拡張ルータ通知メッセージ（ＲＡ*）を生成し、クライアント３２０に対し送信する（ステップ１００７）。本実施形態において、ＲＡ*は、ＲＡと、クライアント３２０とＡＲ４２０との間で共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）とを含む。この秘密鍵は、ＡＡＡＨ３１０により生成されたものである。上述したように、この鍵は、クライアント３２０とＡＡＡＨ３１０との間で共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を用いて暗号化される。ＲＡは、さらに２つのチャレンジに関する拡張を含む。一方のチャレンジに関する拡張は、ステップ１００５のおいてＡＲ４２０がクライアントから受信した乱数のコピーを含み、他方のチャレンジに関する拡張は、ＡＲ４２０により生成されクライアント３２０とＡＲ４２０との間の次回の通信で用いられる新しい乱数を含む。ＲＡ*は、新しく配信された共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を用いて暗号化されたＡＲ４２０の署名を含んだ認証拡張も含む。従って、本実施形態のＲＡ*は、以下のように表現される。
ＲＡ＋ＡＲ_ｉｄ＋ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ_ｒｅｐｌｙ＋Ｃｈａｌ_ｃｌｉｅｎｔ＋Ｃｈａｌ_ＡＲ＋ＡＲによる署名
【００６０】
ＡＲ４２０からＲＡ*を受信すると、クライアント３２０は、チャレンジに関する拡張（Ｃｈａｌ_ｃｌｉｅｎｔ）をチェックし、この拡張に含まれる乱数がステップ１００５においてＡＲ４２０に送信した乱数と同一であるかを調べる。乱数が一致しない場合、悪意をもったアクセスルータが盗難ＩＤを使ってＡＲ４２０だと偽っているかもしれないため、クライアント３２０はこのＲＡ*を無視しなければならない。乱数が一致した場合、クライアント３２０は、チャレンジに関する拡張（Ｃｈａｌ_ＡＲ）から乱数を抽出し、ＡＲ４２０との以後の通信のためキャッシュに格納する。そして、クライアント３２０は、ＡＡＡＨ３１０と共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を用いて鍵応答（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ_ｒｅｐｌｙ）を復号化し、ＡＲ４２０と共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を抽出する。この抽出された共有秘密鍵を用いて、クライアントはＡＲ４２０の署名を確認する。
【００６１】
図１４に示す最初の認証過程を実行後、すなわちクライアント３２０とＡＲ４２０との間でセキュリティ関係が確立された後、クライアント３２０およびＡＲ４２０は、互いに再認証してもよい。図１５に、このような再認証過程の一例を示す。再認証過程において、まず、クライアント３２０がＲＳ*を送信する（ステップ１１０１）。これに対する返信として、ＡＲ４２０は、ＲＡ*を送信する（ステップ１１０３）。クライアント３２０とＡＲ４２０との間でセキュリティ関係が既に確立されているので、ＲＳ*は以下のように表現される。
ＲＳ＋ｃｌｉｅｎｔ_ｉｄ＋Ｃｈａｌ_ＡＲ＋Ｃｈａｌ_ｃｌｉｅｎｔ＋クライアントによる署名
【００６２】
ＲＳ*のチャレンジに関する拡張（Ｃｈａｌ_ＡＲ）は、ステップ１００７においてコピーされた乱数を含む。チャレンジに関する拡張（Ｃｈａｌ_ｃｌｉｅｎｔ）は、クライアントにより生成された新しい乱数を含む。
【００６３】
ＲＡ*は、以下のように表現される。
ＲＡ＋ＡＲ_ｉｄ＋Ｃｈａｌ_ｃｌｉｅｎｔ＋Ｃｈａｌ_ＡＲ＋ＡＲによる署名
【００６４】
ＲＡ*のチャレンジに関する拡張（Ｃｈａｌ_ｃｌｉｅｎｔ）は、ステップ１１０１においてコピーされた乱数を含む。チャレンジに関する拡張（Ｃｈａｌ_ＡＲ）は、ＡＲにより生成された新しい乱数を含む。
【００６５】
＜非対称鍵方式を用いた認証＞
上述した実施形態においては、対称鍵方式、すなわち共有秘密鍵アルゴリズムを用いるＡＡＡインフラストラクチャに基づいた、本発明にかかる認証プロトコルについて説明した。本発明にかかる認証プロトコルが公開鍵アルゴリズム等の非対称鍵方式を採用しても機能することは、当業者にとって明らかである。図１６を参照して、いかに本発明にかかる認証プロトコルが公開鍵アルゴリズムを用いて機能するかについて説明する。図１６において、クライアント３２０が以前に訪問したことのないドメイン４００に入ったものとする。従って、クライアント３２０は、最初の認証過程を経なければならない。
（１）クライアント３２０は、ＲＳ＋を送信することにより、ルータ検出を開始する。本実施形態において、ＲＳ＋は、ＲＳを含む。また、ＲＳ＋は、クライアント３２０の識別子とクライアント３２０の署名とを含む。この署名は、クライアント３２０の秘密鍵を用いて暗号化されたＲＳ＋の要約である。従って、ＲＳ＋は、以下のように表現される。
ＲＳ＋ｃｌｉｅｎｔ_ｉｄ＋クライアントによる署名
【００６６】
クライアント３２０の秘密鍵は、クライアント３２０とＡＡＡＨ３１０との間に確立されるセキュリティ関係ＳＡ３（図５参照）により定義される。従って、ＡＡＡＨ３１０は、クライアント３２０の公開鍵を保有し、ＲＳ＋に格納されたクライアント３２０の証明書を確認する。図１６に示す設定では、ＡＡＡＨ３１０が、クライアントの署名を確認できる唯一の実体である。
（２）ＡＲ４２０は、クライアント３２０からＲＳ＋を受信するが、クライアント３２０の署名を復号化する公開鍵を保有しないため、署名を確認できない。そこで、ＡＲ４２０は、ＡＡＡＲｅｑを生成し、ＲＳ＋全体のコピーとともにＡＡＡＦ４１０に送信する。
（３）ＡＡＡＦ４１０は、クライアント３２０の公開鍵を保有せず、クライアント３２０の署名を確認できない。そこで、ＡＡＡＦ４１０は、自身の公開鍵をＡＡＡＲｅｑに格納し、ＡＡＡＨ３１０に転送する。
（４）ＡＡＡＦ４１０からＡＡＡＲｅｑを受信すると、ＡＡＡＨ３１０は、クライアント３２０の公開鍵を用いてＡＡＡＲｅｑに格納されたクライアント３２０の署名を復号化することにより、クライアント３２０の身元を確認する。クライアント３２０の署名を正常に確認した場合、ＡＡＡＨ３１０は、ＡＡＡＲｅｐを生成しＡＡＡＦ４１０に送信することにより、ＡＡＡＲｅｑに応答する。このＡＡＡＲｅｐは、クライアント３２０の公開鍵（ＰＫ）とＡＡＡＦ４１０の証明書とを含む。ＡＡＡＦ４１０の証明書は、ＡＡＡＲｅｑからＡＡＡＦ４１０の公開鍵を抽出し、これを暗号化することにより生成される。なお、暗号化する際、既に確立されたセキュリティ関係ＳＡ３により定義されるＡＡＡＨ３１０の秘密鍵が用いられる。従って、ＡＡＡＨ３１０からＡＡＡＦ４１０に送信されるＡＡＡＲｅｐは、以下のように表現される。
クライアントのＰＫ＋ＡＡＡＨにより証明されたＡＡＡＦ
（５）ＡＡＡＦ４１０は、ＡＡＡＲｅｑからクライアント３２０の公開鍵を抽出し、キャッシュに格納する。この抽出された公開鍵は、クライアント３２０からのメッセージを認証するために、ＡＡＡＦ４１０により用いられる。ＡＡＡＦ４１０は、ＡＲ４２０の証明書を生成し、ＡＡＡＲｅｐにこの証明書を格納し、ＡＡＡＲｅｐをＡＲ４２０に送信する。ＡＲ４２０の証明書は、ＡＡＡＦ４１０の秘密鍵により証明されたＡＲ４２０の公開鍵（ＰＫ）を含む。従って、ＡＡＡＦ４１０からＡＲ４２０に送信されるＡＡＡＲｅｐは、以下のように表現される。
クライアントのＰＫ＋ＡＡＡＦにより証明されたＡＲ＋ＡＡＡＨにより証明されたＡＡＡＦ
（６）ＡＡＡＦ４１０からＡＡＡＲｅｐを受信すると、ＡＲ４２０は、クライアント３２０の公開鍵を抽出し、キャッシュに格納する。クライアント３２０の公開鍵は、クライアント３２０からのメッセージを認証するために、ＡＲ４２０により用いられる。ＡＲ４２０は、ＲＡ＋を生成し、クライアント３２０に送信する。このＲＡ＋は、ＲＡと、ＡＡＡＦ４１０により生成されたＡＲ４２０の証明書と、ＡＡＡＨ３１０により生成されたＡＡＡＦ４１０の証明書とを含む。従って、ＲＡ＋は、以下のように表現される。
ＲＡ＋ＡＲ_ｉｄ＋ＡＡＡＦにより証明されたＡＲ＋ＡＡＡＨにより証明されたＡＡＡＦ＋ＡＲによる署名
【００６７】
ＡＲ４２０からＲＡ＋を受信すると、クライアント３２０は、受信したＲＡ＋を認証する。クライアント３２０は、まずＡＡＡＨ３１０の公開鍵を用いてＡＡＡＦ４１０の証明書を復号化し、ＡＡＡＦ４１０の公開鍵を抽出する。この公開鍵は、クライアント３２０とＡＡＡＨ３１０との間に確立されているセキュリティ関係ＳＡ３に由来する。証明書が正常に復号化された場合、クライアント３２０は抽出されたＡＡＡＦ４１０の公開鍵を信用できる。これは、この鍵がクライアント３２０が信用するＡＡＡＨ３１０により証明されたためである。次に、クライアント３２０は、抽出されたＡＡＡＦ４１０の公開鍵を用いてＡＲ４２０の証明書を復号化し、ＡＲ４２０の公開鍵を抽出する。証明書が正常に復号化された場合、クライアント３２０は、ＡＲ４２０の公開鍵を信用できる。これは、この鍵がクライアント３２０が信用するＡＡＡＦ４１０により証明されたためである。クライアント３２０に配信されたＡＲ４２０およびＡＡＡＦ４１０の公開鍵を用いて、クライアント３２０とＡＲ４２０との間およびクライアント３２０とＡＡＡＦ４１０との間に新しいセキュリティ関係ＳＡ４およびＳＡ５（図８参照）が確立される。
【００６８】
以上本発明の好適な実施形態を説明してきたが、これらは、性質上、例示的なものにすぎず、本発明の範囲を限定するものではない。本発明の斬新かつ有利な特徴を保ちつつ、且つ本発明の趣旨を逸脱せずに、種々の変形および追加を加えてもよいことは、当業者にとって明らかである。従って、本発明の範囲は、正しく解釈された添付の請求の範囲によってのみ定義される。
【００６９】
【発明の効果】
以上説明したように、本発明によれば、クライアントとアクセスルータとが相互に認証することにより、不正なクライアントまたは不正なアクセスルータによる通信を防止できる。
また、本発明によれば、ネットワーク層において認証メカニズムが実行されるため適用可能なアクセス技術が限定されない。
さらに、本発明は、既存の通信プロトコルにおいて広く用いられているルータ検出が認証プロトコルのキャリアとして用いられるので、既存の通信プロトコルへの導入が容易である。
【図面の簡単な説明】
【図１】本発明が適用される第３世代の無線移動体アクセスＩＰに対応するデータ通信ネットワークの一例を示す図である。
【図２】図１に示すデータ通信ネットワークにおいて行われる標準的なモバイルクライアントによるＬ３ハンドオフ処理を示す簡略図である。
【図３】本発明にかかる認証プロトコルが実行される一般的ＡＡＡネットワークモデルを示す簡略図である。
【図４】本発明にかかる認証プロトコルが実行される一般的ＡＡＡネットワークモデルを示す簡略図である。
【図５】図３および４に示すネットワークにおいて、既に確立されている暗黙のセキュリティモデルを示す図である。
【図６】モバイルクライアントの身元がホームサーバにより確認される本発明の実施形態にかかる、ルータ検出メカニズムを用いた認証プロトコルを示すフローチャートである。
【図７】図６に示す過程の簡略図である。
【図８】図６および７に示す認証プロトコル実施後、クライアントとアクセスルータとの間（ＳＡ４）およびクライアントとＡＡＡＦとの間（ＳＡ５）に確立される新しいセキュリティ関係を示す図である。
【図９】モバイルクライアントの身元がフォーリンサーバにより確認される本発明の別の実施形態にかかる、認証プロトコルを示すフローチャートである。
【図１０】図９に示す過程の簡略図である。
【図１１】クライアントおよびアクセスルータが再認証される本発明の別の実施形態にかかる、認証プロトコルを示すフローチャートである。
【図１２】図１１に示す過程の簡略図である。
【図１３】アクセスルータがルータ通知を自ら送信する本発明の別の実施形態を示す簡略図である。
【図１４】請求および通知メッセージがチャレンジを含みリプレイ攻撃に対し防御を設ける本発明の実施形態にかかる、ルータ検出メカニズムを用いた認証プロトコルを示すフローチャートである。
【図１５】クライアントおよびアクセスルータが再認証される、図１４に示す本発明の実施形態において行われる認証プロトコルの別の例である。
【図１６】非対称鍵アルゴリズムが用いられる本発明の実施形態にかかる、ルータ検出メカニズムを用いた認証プロトコルを示すフローチャートである。
【符号の説明】
１００データ通信ネットワーク
１２０コアネットワーク
１３０ゲートウェイルータ
１３５、３２０クライアント
１４０ＩＰモバイルバックボーン
１４５、４２０、４２１アクセスルータ
１５０サブネットワーク
１５５無線アクセスポイント
２００仲介サーバ
３００ホームドメイン
３１０ホームサーバ
４００フォーリンドメイン
４１０フォーリンサーバ[0001]
BACKGROUND OF THE INVENTION
This application is prioritized with respect to US Provisional Application 60 / 345,967, filed November 9, 2001, entitled “Secure Network Access Using Router Discovery and AAA”. Insist. This provisional application is incorporated herein by reference.
Also, in this application, US application 10 / 146,548, entitled “METHOD FOR SECURING ACCESS TO MOBILE IP NETWORK”, filed May 15, 2002, and US Provisional Application 60 / 332,396, entitled “MOBILE IP REGISTRATION”, filed on November 9, 2001, is cross-referenced. Note that these applications are incorporated herein by reference.
The present invention relates to a bidirectional security protocol that authenticates a client and an access router to each other when the client requests a connection service to access the network and when the router provides a network connection. The security protocol according to the present invention is based on AAA (Authentication, Authentication, and Accounting), and router detection (Router Discovery) is used as a carrier in its execution.
[0002]
[Prior art]
With the widespread use of globally routable IP compatible devices such as mobile phones and PDAs (Personal Digital Assistants), public access IP networks have been widely spread. In particular, recent advances in mobile radio technology and the growth rate of mobile phone systems represent a huge market demand for location-independent communications. The role of wireless communication has greatly surpassed traditional voice and call mobile wireless services only a few years ago. Recently, the International Telecommunications Union (ITU), an accredited body for global network standards, has announced the International Mobile Communications Standard (IMT-2000). This standard proposes a so-called third generation (3G) network that enables a wide range of mobile access by wireless mobile clients such as mobile phones, PDAs, and portable computers. In this third generation network, mobile clients or mobile clients can move freely while maintaining access to network resources and change the connection point from one base station to another. Some 3G networks provide mobility at the link layer (layer 2). However, future networks (so-called 4G) are expected to provide mobility at the IP layer (layer 3).
[0003]
The Internet Engineering Task Force (IETF), an international organization of network designers, operators, suppliers, and researchers involved in the evolution of the Internet architecture and the smooth operation of the Internet, supports mobility at the IP layer. Several standards are proposed. These proposed standards include IETF RFC 2002 (also known as Mobile IP version 4 (IPv4)) and the draft “draft-ietf-mobileip-ipv6-17” (also known as mobile support in IPv6). There are standards for mobility support such as IP version 6). These two standards are incorporated herein by reference. According to the protocol operation defined in IPv4 and IPv6, the client can move on the network while maintaining access to the network resources, and change the connection point from one access router to another. This process is usually referred to as “Layer 3 (L3) handoff”.
[0004]
The purpose of performing the L3 handoff process is to update the packet routing information of the mobile client through the registration process. The client can always specify the “home address”. Here, the “home address” is an IP address assigned by an access router (home router) on the home network or an IP address selected by the client itself. However, if the client is on a foreign network and is away from the home network, the care-of address indicating the connection point to the current network is set for the client. This care-of address is the address of an access router (foreign router) on the foreign network, and a client operating away from the home network registers this care-of address with the home router. The home router that has received the registration request collects the packet addressed to the client on the way and transfers it to the care-of address of the client. In Mobile IPv6, a client away from the home network transmits a binding update to the home router and a communicating partner node. The counterpart node may be a mobile client such as a client or a server that provides data to the client. Then, the correspondent node that has received the correspondence update directly transfers the packet to the client without going through the home router.
[0005]
[Problems to be solved by the invention]
A serious security problem arises when a mobile client requests a network connection in the visited network. A client must always be authenticated before network access is granted. Unauthenticated clients may be unauthorized users who attempt to access network resources free of charge using unauthorized IDs or stolen IDs. Such a client may also be a malicious node that requires network access only to disrupt the orderly operation of the network. Similarly, a client may wish to authenticate an access router that is providing network connectivity to itself. An access router may be a rogue router that sniffs client traffic, forwards it somewhere, or just interrupts it. Currently, a number of authentication mechanisms are implemented and adopted by various access technologies. Examples are PPP and 802.11 network authentication. When these networks are used, since an authentication mechanism is provided in the link layer, there is a drawback in that the application range of the authentication mechanism is limited to a specific access technology. Accordingly, there is a demand for providing an authentication mechanism that does not select any access technology.
[0006]
[Means for Solving the Problems]
In view of the above circumstances, the present invention provides a secure network access method that does not select an access technology by using an authentication mechanism in the network layer. The present invention provides a network layer protocol that authenticates a mobile client and an access router with each other before allowing the mobile client to access the network. The present invention implements an authentication protocol using router detection as a carrier. In an embodiment of the present invention, the mobile client sends a billing message and requests a connection service. The billing message includes the mobile client's identity certificate. The access router that has received the request message does not respond to the request message until the identity certificate is confirmed. Only after the mobile client's identity certificate is confirmed, the access router responds and returns a notification message to the mobile client. Therefore, unauthorized mobile client network access can be prevented.
[0007]
The notification message from the access router may include the access router's identity certificate. Only when the access router's identity certificate is successfully confirmed, the mobile client initiates network access via the access router. Therefore, it is possible to prevent the mobile client from starting network access via an unauthorized access router.
[0008]
By using billing and notification messages, there are advantages in securing network access. The detection mechanism is the first step in establishing an off-link connection between the mobile client and the access router. That is, authenticating mobile clients and access routers using a detection mechanism is a natural extension to existing protocols. By using a detection mechanism for authentication of mobile clients and access routers, the number of protocol signals can be saved significantly. Saving the number of protocol signals is important for mobile wireless networks where communication resources are valuable and expensive. A further advantage of using a detection mechanism is that the detection mechanism is common to both IPv4 and IPv6. Thus, the present invention that uses the detection mechanism as a carrier and performs authentication of mobile clients and access routers can be performed in a network regardless of whether the network uses IPv4 or IPv6.
[0009]
The authentication protocol according to the present invention may use an authentication service and a protocol signal provided by the AAA protocol based on the AAA infrastructure. In the AAA protocol, a plurality of domains are defined, and each domain is managed by at least one AAA server. The AAA server provides AAA services to mobile clients via an attendant, that is, an access router. In the present invention, a trusted entity is required to verify the client identity certificate included in the billing message. When a client enters a new foreign domain, the trusted entity is the AAA server that manages the client's home domain. Therefore, communication latency may occur because the protocol signal goes back and forth between the client and the home server for this initial authentication process. However, as long as the client remains in the foreign domain, the home server is not used for verification. For example, when a client switches access routers in a foreign domain, the foreign domain server becomes a trusted entity. If a client requests a connection to the same access router, even that access router may become a trusted entity. Accordingly, the protocol signal necessary for the authentication protocol according to the present invention is reciprocated over a shorter distance, thereby reducing the communication delay caused by the authentication process.
[0010]
The authentication protocol according to the present invention can be executed using any key algorithm such as symmetric and asymmetric key cryptosystems. These keys may be distributed along with protocol signals associated with the authentication process of the present invention. By distributing these keys, a new security relationship is established between the two entities, and protocol signals for neighbor detection such as address resolution (ARP / RARP) and subsequent communication between the entities are secured. .
[0011]
In another embodiment of the invention, the access router may voluntarily send a notification message that includes its identity certificate. If the identity certificate is successfully confirmed, the client uses this access router as a gateway to the Internet. If this proof cannot be confirmed, the authentication process is started by sending a billing message containing its identity certificate. This solicitation message is processed as outlined above.
[0012]
In another embodiment of the invention, the client may send a billing message to the access router while communicating with the access router. There is always the possibility that a legitimate entity will be replaced by an unauthorized entity, even during communication. In response to this solicitation message, the access router sends a notification message containing its identity certificate so that the client can re-authenticate the access router during communication. Similarly, the access router may send a notification message with a short validity period to the communicating client. In response to this notification message, the client sends a solicitation message containing its identity certificate so that the access router can re-authenticate the client.
[0013]
A solicitation message from the client and / or a notification message from the access router may include a challenge to protect against replay attacks.
[0014]
DETAILED DESCRIPTION OF THE INVENTION
A preferred embodiment of the present invention will now be described with reference to the drawings. In this drawing, similar constituent elements are denoted by the same reference numerals. The embodiments described herein are merely exemplary in nature and are not intended to limit the scope of the invention. In the network described in this embodiment, mobile IP is used. However, the present invention is more widely applicable to any IP-based communication protocol such as IPv4 and IPv6.
[0015]
FIG. 1 shows a data communication network 100 compatible with a third generation wireless mobile access IP to which the present invention is applied. For purposes of this specification, the data communication network 100 shall conform to the IMT-2000 standard and ITU specifications for wireless mobile communication networks. Furthermore, it is assumed that the data communication network 100 performs mobile IP support in accordance with the mobile IPv4 and mobile IPv6 standards proposed by the IETF. Thus, of course, in this application, terms specific to one version may be used in place of corresponding terms in the other version. For example, the term “agent” may be used in place of the term “access router” or simply “router”. Similarly, “agent detection” may be used as “router detection”, “agent request” as “router request”, and “registration request” as “correspondence update”.
[0016]
At the center of the data communication network 100 corresponding to the wireless mobile access IP is provided a core network 120 which is a fixed node IP data network having a number of fixed nodes (not shown), that is, fixed connection points or links. Digital data is transmitted and received within or through this communication network and in accordance with Internet Protocol version 6 (IPv6). As described above, IPv6 is only an example of a communication protocol and can be replaced with a communication protocol such as IPv4. Some nodes of the core network 120 have a conventional router (not shown), which acts as an intermediate node according to conventional Internet addressing and routing protocols, between source and destination nodes connected to the network Transfer the data packet with.
[0017]
The core network 120 includes a plurality of gateway routers (GR) 130, which constitute an IP mobile backbone. The gateway router 130 that constitutes the IP mobile backbone is itself a node of the core network 120 and is interconnected via the core network 120. Each gateway 130 is connected to a plurality of access routers 145 that can communicate with the mobile client 135. As this mobile client, different types of mobile wireless communication devices such as cordless phones, mobile phones, portable computers, personal information management devices, and the like can be used. The access router 145 functions as a home router (HR) and a foreign router (FR), and connects the client 135 to the core network 120 via the gateway router 130. The access router 145 is an entity on layer 3 of the access network. Client 135 communicates with access router 145 via a wireless access point (AP) 155. This AP 155 is an entity on layer 2 of the access network. A group of APs 155 constitutes the sub-network 150 in FIG. Each access router 145 manages the subnetwork 150 and provides a network link as an interface between the subnetwork 150 and the data network 100. Client 135 and AP communicate with each other using well-known CDMA, W-CDMA, or similar digital data communication techniques.
[0018]
In accordance with Mobile IPv6, each client 135 is assigned a home subnetwork including an access router 145 which is a home router. The access router 145 holds the current position information of the client 135 and transfers the packet to the current position of the client 135. The other access router 145 functions as a foreign router. Client 135 can “visit” this foreign router while away from the home subnetwork. When the client 135 communicates with either the home router or the foreign router at any time, either router establishes a network link and provides network access to the client 135. Each of the client 135 and the access router 145 on the network has a unique IP address as in the conventional fixed node data network using the conventional Internet protocol.
[0019]
Within the entire data communications network 100, two levels of handoff processes are possible. The first level is a macro level handoff or a layer 3 handoff, with a change in client location. This change in position means that a client moves from a radio subnetwork managed by one access router to a radio subnetwork managed by another access router. Thus, L3 handoff necessarily changes the client's network link. The second level is a micro-level handoff or a layer 2 handoff, which involves a change in client location within the subnetwork 150. In this case, the client radio link changes, but the network link does not change. L2 handoff processing is common in wireless mobile communication networks. For example, it is well known to detect the reachability of an adjacent AP using the strength of a beacon signal from the adjacent AP.
[0020]
FIG. 2 is a simplified diagram illustrating an L3 handoff process by a mobile client performed according to Mobile IPv6. In FIG. 2, the data communication network 100 includes a core network 120 and an access router 145 connected to the core network 120. The client 135 is initially located at the departure point A and moves to the point C via the intermediate point B. In FIG. 2, the client 135 at the starting point A operates in the foreign subnetwork managed by the access router 145 (FR1), which is a foreign router, and is connected to the core network 120 via FR1. On the other hand, the point C is located in the foreign subnetwork managed by the access router 145 (FR2) which is a foreign router. The mobile client 135 passes through the sub-network managed by FR1 and enters the sub-network managed by FR2. Therefore, the L3 handoff considered in FIG. 2 is performed when the network link is switched from FR1 to FR2.
[0021]
When client 135 moves from departure point A and arrives at intermediate point B, at some point further wireless communication with FR1 begins to fail. The client 135 is leaving the subnetwork 150 managed by FR1 and entering the subnetwork 150 managed by FR2. When the client 135 passes the intermediate point B and the L2 handoff is performed, the wireless link destination of the client 135 is changed from the AP of the subnetwork managed by FR1 to the AP of the subnetwork managed by FR2. As the arrival point C is approached, the client 135 performs mobile IP registration with the L3 handoff, that is, FR2. In this registration process, router detection defined in Mobile IPv6 is first performed. By this router detection, the client 135 detects the adjacent access router 145, specifies the link layer address of the access router 145, and retains reachability information about the route to the access router 145. For this purpose, a pair of ICMP (Internet Control Message Protocol) packet types, ie router billing and router advertisement, are defined in router detection. A router solicitation is a message that is sent by a client and requests a neighboring access router to generate and return a router advertisement. The access router 145 notifies its presence by sending a router notification periodically or in response to a router request from the client 135. Based on information included in the router advertisement, the client 135 sets a care-of address (CoA).
[0022]
When the router notification is received from FR2, the client 135 generates and sets a care-of address based on the information in the notification. The client 135 then registers a new care-of address by sending a corresponding update that includes the new care-of address and the unchanged home IP address of the client 135 to the home router. The home router updates the routing information of the client in the cache that records the address correspondence information, and as a result, the L3 link is established between the client 135 and FR2. Thereafter, a packet transmitted to the home IP address of the client 135 is collected on the way by the home router, tunneled to FR2, and distributed from FR2 to the client 135. In order to eliminate the packet delay caused by the detour routing of the packet, the correspondence update is transmitted to any destination node that can directly transfer the packet to the client 135 thereafter.
[0023]
As the popularity of mobile data communication increases, the likelihood of malicious clients attempting network access increases. This client may be an unauthorized user who tries to access network resources free of charge using an unauthorized ID or theft ID, and is nothing but a threat to the orderly operation of the network. Therefore, to screen out this malicious client, a client requesting network access must always be authenticated before network access is granted. Similarly, a client may wish to authenticate an access router that provides a connection service before initiating network access. Some access routers may be rogue access routers that sniff client traffic, forward it somewhere, or just interrupt it. In the bidirectional security protocol provided by the present invention, the client and the access router are mutually authenticated, so that the client can identify a malicious access router before using it as a gateway, and the access router can provide a forwarding service. Can identify malicious clients.
[0024]
The security mechanism according to the present invention is based on the authentication, authorization and accounting (AAA) protocol. AAA protocols such as RADIUS and DIAMETER are in use today on the Internet and provide authentication, authorization, and billing services for dial-up computers. Such an AAA management service, in particular, an authentication service provided by an AAA service is also useful in mobile IP. In fact, Mobile IP can run on an AAA infrastructure that makes little changes to the basic framework. For example, a client in the AAA protocol is considered a mobile node of Mobile IP, and an attendant in the AAA protocol corresponds to a mobile IP access router. If the capabilities of the mobile client and access router are improved and they can decrypt AAA messages, then Mobile IP can be run on the AAA infrastructure.
[0025]
3 and 4 are simplified diagrams illustrating a general AAA network model in which Network Access Service (NAS) and Mobile IP are implemented. The management domain consists of a plurality of networks operating under one or common management. A number of management domains may be defined in the data communication network 100 shown in FIG. However, for simplicity of illustration, only two administrative domains are shown in the AAA network shown in FIGS. 3 and 4, namely a home domain 300 and a foreign domain 400 separated by a wide area Internet. Each domain includes an AAA server that provides AAA services to domain components. Home domain 300 is managed by home server AAAH 310. The foreign domain 400 is managed by the foreign server AAAF410. Each home and foreign domain further comprises an attendant disposed within the domain. However, in FIGS. 3 and 4, only the foreign domain 400 includes two attendants 420 and 421. According to the AAA protocol, attendants 420 and 421 provide a service interface between the client 320 and the local domain 400. In this embodiment, it is assumed that the client 320 moves from the home domain 300 to the foreign domain 400 and desires a service from either the attendant 420 or 421 in the management domain 400. As described above, Mobile IP is performed on the AAA network shown in FIGS. In the case of mobile IP, the attendant is actually an access router (AR) that provides network access services to mobile clients. Thus, the term “attendant” may be used interchangeably with the term “access router” or simply “AR”.
[0026]
One important service provided by the AAA protocol is authentication. In general, the AAA authentication mechanism works as follows. Only when the first entity corresponding to AAA presents a certificate to the second entity desired by the communication destination, and the second entity can normally confirm the certificate of the first entity, between the two entities Communication is allowed. This certificate is verified using a key algorithm defined when a security relationship (SA) is established between the two entities. The AAA protocol is designed to work with different key algorithms. One algorithm is based on public key infrastructure and another algorithm is based on symmetric key distribution. The AAA server functions as a key distribution center, and generates and distributes a key used for confirming a certificate presented between two AAA entities in response to a request of an AAA entity such as an attendant or a client. By distributing keys to two AAA entities, a security relationship is established between them. For purposes of explanation, it is assumed that a symmetric key or shared secret key algorithm is used in the AAA network shown in FIGS. Symmetric key algorithms are easier to use than other key algorithms and provide a solution to the problem of adaptability to the entire Internet. However, it will be apparent to those skilled in the art that an asymmetric key algorithm such as a public key method or other key algorithms may be used to implement the present invention. An authentication token may be used.
[0027]
An implicit security model exists in the AAA network shown in FIGS. FIG. 5 shows such an implicit security model, where the arrows indicate the security relationships that are assumed to be established from the beginning. First, as shown by the arrow SA1, it is assumed that a security relationship is established between the AAAF 410 and the ARs 420 and 421. Since the AR is located in a domain managed by the AAAF 410 and trust should have already been established between them, SA1 may be established between the AR 420 and 421 and the AAAF 410. . Next, it is assumed that a security relationship is established between AAAH 310 and AAAF 410. These AAA servers do not need to establish a security relationship between them at first, but must have the ability to establish a security relationship between them as needed. The security relationship indicated by the arrow SA2 can be established directly between the two AAA servers or indirectly through the intermediary AAA server 200. Finally, it is assumed that a security relationship is established between the client 320 and the AAAH 310 as indicated by an arrow SA3. Since the client 320 starts from the home domain 300 where the AAAH 310 is located, it may be assumed that SA3 has been established. Accordingly, AAAH 310 is the only entity that can initially authenticate the client.
[0028]
An important feature of the present invention is that the router detection mechanism is used as a “carrier” in the present invention to implement the AAA security protocol in Mobile IP. In the present invention, router billing and router advertisement are extended to add a mobile IP authentication function to the existing AAA protocol.
[0029]
<First router detection (when entering a new domain)>
FIG. 6 is a flowchart illustrating a network access authentication process using a router detection protocol according to an embodiment of the present invention. FIG. 7 is a simplified diagram of the process shown in FIG. In this embodiment, it is assumed that the client 320 has not established a security relationship with any of the ARs 420 and 421 or the AAAF 410. That is, since the client 320 has not visited the foreign domain 400 before or has been away from the foreign domain 400 for a long time, the previously established security relationship with the AR 420, AR 421, and AAAF 410 is invalidated. Shall be.
[0030]
The client 320 enters the foreign domain 400 and requests network access by a linked access router. In step 501, client 320 initiates router discovery by sending an extended router solicitation message (RS +). This is a multicast message and is received by all access routers on the same link as the client. Unlike a normal router solicitation message, this includes the client's identity certificate. This identity certificate is sent in the form of an extension of the standard router solicitation packet. RS + includes various components similar to standard router solicitation messages (RS). The RS + includes a client identifier (client_id) that can be a network access identifier (NAI) or an IP address, and a client signature. This signature is a summary of RS + encrypted with the client's private key shared with AAAH 310 (client-AAAH_key). Therefore, RS + is expressed as follows.
RS + client_id + client signature
[0031]
The shared secret key of the client is defined by the security relationship SA3 (see FIG. 5) established between the client 320 and the AAAH 310. Accordingly, the AAAH 310 holds the client's shared secret key (client-AAAH_key) and confirms the client's signature stored in RS +. AR 420 and other attendants receive RS + from client 320. However, as described above, since the AR 420 has not established a security relationship with the client 320, the AR 420 does not have a shared secret key for confirming the identity of the client 320. According to the standard router detection mechanism, the access router returns a router advertisement message in response to the router solicitation message. However, in the present invention, the AR 320 and other access routers do not send back router advertisement messages until the client 320 is successfully authenticated.
[0032]
The AR 420 delegates the confirmation of the client 320 to the AAAF 410. The AR 420 generates an AAA request message (AAAReq) and transmits it to the AAAF 410 (step 503). This AAAReq contains a copy of the entire RS + from the client 320. AAAAreq transmitted from the AR 420 to the AAAF 410 is protected based on the security relationship SA1 established between the two. AAAReq is generated according to AAA protocols such as Radius and DIAMETER. For the preferred procedure for generating AAA messages, see the IETF draft “draft-ietf-diameter-07.txt” entitled “Diameter Basic Protocol” and the IETF “Diameter Mobile IP Extension Specification”. Discussed in the draft "draft-calhoun-diameter-mobileip-12.txt". These two drafts are incorporated herein by reference.
[0033]
As described above, AAAF 410 has not established a security relationship with client 320, and therefore does not have a shared secret key that confirms the identity of the client. However, the AAAF 410 recognizes that the home domain of the client 320 is the home domain 300 based on the client identifier stored in the RS +. Then, the AAAF 410 transfers a copy of RS + and AAARQ to the AAAH 310 located in the home domain 300 using the security relationship SA2 established with the AAAH 310 (step 505).
[0034]
Upon receiving AAAA Req from AAAF 410, AAAH 310 verifies the identity of client 320 by decrypting the client's signature stored in AAAReq using the client's shared secret key. If the client presents a valid identity, the AAAH 310 should be able to confirm the client's identity normally. If the client's identity cannot be confirmed, the AAAH 310 generates an AAA response message (AAARep) and sends it to the AR 420 via the AAAF 410. This AAARep includes an authentication result indicating that the AAAH 310 cannot authenticate the client 320. AAARep is also generated according to AAA protocols such as Radius and DIAMETER. Upon receiving AAARep, AR 420 ignores the router solicitation message from client 320 and does not return a router advertisement message. Therefore, access to network resources by unauthenticated clients is prevented.
[0035]
If the AAAH 310 confirms the identity of the client 320 normally, the AAAH 310 responds to the AAAReq from the AAAF 410 by generating an AAA response (AAAA Rep) and sending it to the AAAF 410 (step 507). This AAARep includes two shared secret keys. One of these is used between the client 320 and the AR 420, and the other is used between the client 320 and the AAAF 410. These shared secret keys are generated by AAAH 310 and distributed to AAAF 410, AR 420, and client 320 to establish security relationships between client 320 and AAAF 410 and between client 320 and AR 420. These shared secret keys (client-AR_key) and (client-AAAF_key) are respectively copied. The duplicated shared secret key (client-AR_key) and (client-AAAF_key) are encrypted by AAAF 410 using the secret key (client-AAAF_key) shared with client 320 to protect their authenticity and confidentiality. Distributed to the client 320. The original keys (client-AR_key) and (client-AAAF_key) are decrypted and delivered to AR 420 and AAAF 410, respectively. Accordingly, AAARe transmitted from AAAH 310 to AAAF 410 is expressed as follows.
client-AR_key + client-AAAF_key + AAAH encrypted (client-AR_key + client-AAAF_key)
[0036]
By AAARep from AAAH 310, AAAF 410 recognizes that client 320 can be trusted. Then, the AAAF 410 extracts the shared secret key (client-AAAF_key) decrypted from AAARep and stores it in the cache. The extracted shared secret key is used by the AAAF 410 to authenticate the message from the client 320. Then, AAAF 410 transfers AAARep to AR 420 (step 509). From AAAAp 410 from AAAF 410, AR 420 recognizes that the identity of client 320 has been successfully authenticated. Then, the AR 420 extracts the shared secret key (client-AR_key) decrypted from AAARep and stores it in the cache. This shared secret key is used by the AR 420 to authenticate the message from the client 320. Then, the AR 420 generates an extended router notification (RA +) and transmits it to the client 320 (step 511). This RA + includes a standard router advertisement message (RA), an AR420 identifier (AR_id), and a shared secret key (client-AR_key) and (client-AAAF_key) encrypted with the shared secret key (client-AAAF_key). . This RA + further includes the signature of AR420. This signature is a summary of RA + encrypted by the shared secret key (client-AR_key) received by the AR 420 from the AAAF 410. Therefore, this RA + is expressed as follows.
RA + AR_id + AAAH encrypted (client-AR_key + client-AAAF_key) + signature by AR
[0037]
When receiving RA + from the AR 420, the client 320 authenticates the received RA +. First, the client 320 decrypts the shared secret key (client-AR_key) and (client-AAAF_key) using the secret key (client-AAAH_key) shared with the AAAH 310. If these private keys are successfully decrypted, they can be trusted by the AAAH 310 that the client 320 trusts so that the client 320 can trust these private keys. Next, the client 320 decrypts the signature of the AR 420 using the decrypted secret key (client-AR_key). When the signature is successfully decrypted, the identity of the AR 420 is confirmed by the secret key (client-AR_key) that the client 320 trusts, so that the client 320 can trust the AR 420. Further, the reliability of RA + is guaranteed for the client 320 by successfully decrypting the signature. A new security relationship SA4 (see FIG. 8) is established between the client 320 and the AR 420 by the shared secret key (client-AR_key) distributed to the client 320 and the AR 420. A new security relationship SA5 is established between the client 320 and the AAAF 410 by the shared secret key (client-AAAF_key) distributed to the client 320 and the AAAF 410.
[0038]
If the AR 420 signature cannot be authenticated, the client 320 ignores the RA + from the AR 420 and waits for the RA + from another access router that contains an authenticable certificate. Therefore, it is possible to prevent the client 320 from starting network access via an unauthorized access router.
[0039]
The authentication process shown in FIGS. 6 and 7 will take a long time and will result in significant communication latency. This communication waiting time is mainly the time required for the AAA message to travel back and forth across the wide area Internet that separates the AAAF 410 and the AAAH 310. When an AAA message is sent to AAAF 410 or AAAH 310, there is always some latency. The initial authentication process shown in FIGS. 6 and 7 must communicate with these remote servers. However, if AR 420 and AAAF 410 can authenticate the client without relying on AAAF 410 or AAAH 310, the latency associated with the authentication mechanism is reduced.
[0040]
<Following router detection (when detecting a new access router in the same domain)>
The client 320 may move within the domain 400 and connect to another access router that has not authenticated the identity of the client 320. FIG. 9 is a flowchart illustrating authentication router detection performed in such a case, according to another embodiment of the present invention. FIG. 10 is a simplified diagram of the process shown in FIG. 9 and 10, it is assumed that the client 320 leaves the sub-network managed by the AR 420 and enters the sub-network managed by the AR 421 after undergoing the initial authentication process with the AR 420 shown in FIGS. In order to access the network via the AR 421, the client 320 transmits RS + again (step 701). RS + transmitted this time includes a message similar to that used in the initial authentication process shown in FIGS. 6 and 7, and is expressed as follows.
RS + client_id + client signature
[0041]
However, since the signature included in the RS + of the present embodiment is encrypted with the shared key (client-AAAF_key), the AR 421 cannot confirm the signature. Therefore, the AR 421 delegates the confirmation of the client 320 to the AAAF 410 by generating AAAReq and transmitting it to the AAAF 410 (step 703). AAAReq from AR421 contains a copy of the entire RS +. The AAAF 410 has acquired the shared secret key (client-AAAF_key) in the previous authentication process shown in FIGS. 6 and 7, and should be able to recognize the identity of the client 320. The AAAF 410 confirms the identity of the client 320 by decrypting the signature of the client 320 with the shared secret key (client-AAAF_key) without using the AAAH 310. If the signature of the client 320 cannot be confirmed, the AAAF 410 generates AAARQ and transmits it to the AR 421 (step 705). This notifies the AR 421 that the client 320 cannot be trusted. The AR 421 ignores RS + from the client 320. When the signature of the client 320 is confirmed normally, the AAAF 410 generates a secret key (client-AR2_key) shared between the client 320 and the AR 421. This secret key (client-AR2_key) is duplicated. One of the two secret keys resulting from the duplication is not encrypted as it is, and the other is encrypted with the shared secret key (client-AAAF_key). The AAAF 410 stores the unencrypted key and the encrypted key in AAAReq and transmits them to the AR 421 (step 705). Therefore, AAARep transmitted from AAAF 410 to AR 421 is expressed as follows.
client-AR2_key + encrypted by AAAF (client-AR2_key)
[0042]
With AAARep from AAAF 410, AR 421 recognizes that client 320 can be trusted. Then, the AR 421 extracts the decrypted secret key (client-AR2_key) and stores it in the cache. This stored secret key is used by the AR 421 to authenticate subsequent messages from the client 320. The AR 421 generates RA + and transmits it to the client 320 (step 707). RA + from AR421 is expressed as follows.
RA + AR_id + (client-AR2_key) encrypted by AAAF + signature by AR
[0043]
Upon receiving RA + from the AR 421, the client 320 decrypts using the shared secret key (client-AAAF_key) and extracts the secret key (client-AR2_key). If this key is successfully decrypted, the client 320 can trust this key. The client 320 authenticates RA + by decrypting the signature of the AR 421 using the shared secret key (client-AR2_key). If the signature is successfully decrypted, the client 320 can trust the authenticity of AR421 and RA +. The shared secret key (client-AR2_key) distributed to the client 320 and the AR 421 establishes a new security relationship between them. If the signature cannot be decrypted, the client ignores RA + from AR 421 and waits for RA + from another access router containing an authenticable signature.
[0044]
The subsequent authentication process shown in FIGS. 9 and 10 is performed faster than the authentication process shown in FIGS. This is because in the authentication process shown in FIGS. 9 and 10, there is no need to exchange messages with the AAAH 310, and the protocol signal travels a shorter distance.
[0045]
<Following router detection (when detecting the same access router)>
Each RA + has a validity period. Therefore, even when connected to the same access router, the client must go through an authentication process with the same access router before the validity period of the previous RA + elapses. In this case, as shown in FIGS. 11 and 12, in the authentication process according to the present invention, the protocol signal reciprocates the shortest distance. 11 and 12, client 320 sends RS + to AR 420 in step 801. RS + is expressed as follows.
RS + client_id + client signature
[0046]
The signature is encrypted with the shared secret key (client-AR_key) acquired by the client 320 in the first authentication process shown in FIGS. Since the AR 420 shares the same key as the client 320, the AR 420 should be able to recognize the identity of the client 320. The AR 420 confirms the identity of the client 320 by decrypting the signature using the shared secret key (client-AR_key) without using the AAAF 410. If the identity of the client 320 cannot be confirmed, the AR 420 ignores RS +. When the identity of the client 320 is confirmed normally, the AR 420 generates RA + and transmits it to the client 320. RA + in this embodiment is expressed as follows.
Signature by RA + AR_id + AR
[0047]
Therefore, communication between the client 320 and the AR 420 is the fastest authentication mechanism because the protocol signal travels the shortest distance.
[0048]
<Unsolicited router notification>
The access router may periodically transmit RA + instead of waiting for reception of authenticable RS +. In FIG. 13, it is assumed that ARs 420 and 421 periodically transmit RA +. RA + is expressed as follows.
Signature by RA + AR_id + AR
[0049]
The RA + transmitted from the AR 420 includes the RA and the AR 420 signature. The RA + transmitted from the AR 421 includes the RA and the AR 421 signature. Assume that the client 320 has undergone the first authentication process with the AR 420 shown in FIGS. 6 and 7 before. Through the above authentication process, a security relationship is established between the client 320 and the AR 420 and between the client 320 and the AAAF 410. If RA + from AR 420 has reached client 320, client 320 should be able to authenticate RA +. Thus, the client 320 can initiate network access securely via the AR 420. If any RA + received is not recognized, the client must go through the initial authentication process shown in FIGS. 6 and 7 by sending RS +.
[0050]
<Re-authentication>
Both the communicating client and the AR may always initiate the authentication process of the present invention and re-authenticate to each other. This is important because there is always a possibility that a malicious entity can be replaced by a legitimate entity even during communication. The client may initiate this process at any time by sending RS + during communication with the AR. The AR should be able to respond to RS + by returning RA + to the client for re-authentication by the client. Similarly, the AR can re-authenticate the client while accommodating the client. The AR initiates client re-authentication by sending a unicast router advertisement message with a very short validity period to the client. Since this router advertisement message has a very short validity period, the client recognizes that the AR will soon stop connecting to the client. The client responds to such a router advertisement message by sending RS + and detecting other available access routers on the same link. Then, the AR authenticates the RS + transmitted from the client.
[0051]
<Interoperability with old protocol>
In the entire network, a domain that can support the extended router detection mechanism according to the present invention and a domain that can support only the standard router detection mechanism may be mixed. Therefore, a client that supports only the standard router detection mechanism may move to a domain that supports the extended router detection mechanism according to the present invention, and a client that supports the extended router detection mechanism may You may move to a domain that supports only the router discovery mechanism. In either case, the authentication protocol according to the present invention does not interfere with the operation of the standard router detection mechanism.
[0052]
First, when a client that supports the extended router detection mechanism tries to receive a connection service in a domain that supports only the standard router detection mechanism, the client transmits RS +. However, neighboring access routers cannot recognize the new extension added to RS + and therefore ignore this extension. The access router processes RS + as r and returns RA. Here, it is up to the client to use this “unauthenticated” router advertisement message.
[0053]
Next, if a client that supports only the standard router discovery mechanism attempts to receive a connection service in a domain that supports the enhanced router discovery mechanism according to the present invention, the client will receive an RS that does not contain any new extensions. Send. When such an “unauthenticated” router solicitation message is received, it is up to the neighboring access router to return RA + or not respond at all.
[0054]
In either case, the client and AR that support the extended router detection mechanism according to the present invention detect whether the communication partner can support the extended router detection mechanism or only the standard router detection mechanism. Can respond accordingly. It is up to the network design policy to respond to or receive unauthenticated messages.
[0055]
<Defense against replay attacks>
A replay attack is simply reuse of a stolen password. If a cracker can eavesdrop on the password while sending it, the cracker will get a copy of the password that can be used anytime thereafter. Even if the password is encrypted and exchanged, the cracker may be able to log in by simply re-executing the previously acquired communication. The authentication protocol according to the present invention can provide protection against replay attacks by adding extensions related to challenges.
[0056]
FIG. 14 is a flowchart illustrating an embodiment of the present invention that provides defense against replay attacks using a challenge scheme. In FIG. 14, it is assumed that the client 320 has never communicated with the AR 420 or the AAAF 410 and therefore has to go through the initial authentication process shown in FIGS. First, the client 320 transmits an RS (step 1001). The AR 420 receives the RS, but cannot trust until the identity of the client that sent the RS is authenticated. The client that transmitted the RS may be a malicious node that eavesdrops on past communication with the client 320, steals the identification information of the client 320, and accesses the network using the forged ID.
[0057]
As a reply to the RS from the client 320, the AR 420 confirms the identity of the client and the authenticity of the RS (step 1003). Specifically, in step 1003, the AR 420 transmits the extension related to the challenge and the RA to the client 320. The extension for this challenge includes a random number generated by AR 420. In response to the RA from the AR 420, the client 320 generates and transmits an extended router solicitation message (RS *) (step 1005). RS * includes RS, client identifier, ie client IP address or NAI, and secret key request. This secret key is shared with the AR 420 and establishes a security relationship with the AR 420. RS * also includes extensions for two challenges. The extension for one challenge includes a copy of the challenge that the client received from the AR 420 at step 1003, and the extension for the other challenge includes a random number generated by the client itself. Finally, RS * includes an authentication extension that includes the signature of client 320 that is encrypted using a secret key (client-AAAH_key) shared between client 320 and AAAH 310. Therefore, in the present embodiment, RS * is expressed as follows.
RS + client_id + client-AR_key_request + Chal_AR + Chal_client + client signature
[0058]
Upon receiving RS * from the client 320, the AR 420 checks the extension for the challenge (Chal_AR) to see if the random number included in this extension is the same as the random number sent to the client in step 1003. If the random numbers are the same, the RS * is effectively a response to the challenge that the AR 420 sent to the client 320 in step 1003. If the random numbers do not match, the AR 420 must ignore this RS * because the RS * is probably from a malicious node that pretends to be the client 320 using the theft ID. When the random numbers match, the subsequent authentication process is the same as the process described in FIGS.
[0059]
When the identity of the client 320 is normally confirmed by the AAAH 310, the AR 420 generates an extended router notification message (RA *) and transmits it to the client 320 (step 1007). In the present embodiment, RA * includes RA and a secret key (client-AR_key) shared between the client 320 and the AR 420. This secret key is generated by the AAAH 310. As described above, this key is encrypted using a secret key (client-AAAH_key) shared between the client 320 and the AAAH 310. The RA further includes extensions for two challenges. The extension for one challenge includes a copy of the random number that the AR 420 received from the client in step 1005, and the extension for the other challenge is a new one generated by the AR 420 and used in the next communication between the client 320 and the AR 420. Contains a random number. The RA * also includes an authentication extension that includes the AR 420 signature encrypted using the newly distributed shared secret key (client-AR_key). Therefore, RA * of this embodiment is expressed as follows.
RA + AR_id + client-AR_key_reply + Chal_client + Chal_AR + Signature by AR
[0060]
Upon receipt of RA * from the AR 420, the client 320 checks the extension (Chal_client) for the challenge and checks whether the random number included in this extension is the same as the random number transmitted to the AR 420 in step 1005. If the random numbers do not match, the client 320 must ignore this RA * because a malicious access router may pretend to be an AR 420 using a theft ID. If the random numbers match, the client 320 extracts the random number from the extension related to the challenge (Chal_AR) and stores it in the cache for subsequent communication with the AR 420. Then, the client 320 decrypts the key response (client-AR_key_reply) using the secret key (client-AAAH_key) shared with the AAAH 310, and extracts the secret key (client-AR_key) shared with the AR 420. Using this extracted shared secret key, the client verifies the signature of AR420.
[0061]
After performing the initial authentication process shown in FIG. 14, ie, after the security relationship is established between client 320 and AR 420, client 320 and AR 420 may re-authenticate to each other. FIG. 15 shows an example of such a re-authentication process. In the re-authentication process, first, the client 320 transmits RS * (step 1101). In response to this, AR 420 transmits RA * (step 1103). Since a security relationship has already been established between the client 320 and the AR 420, RS * is expressed as follows.
RS + client_id + Chal_AR + Chal_client + client signature
[0062]
The extension for the RS * challenge (Chal_AR) includes the random number copied in step 1007. The challenge extension (Chal_client) includes a new random number generated by the client.
[0063]
RA * is expressed as follows.
Signature by RA + AR_id + Chal_client + Chal_AR + AR
[0064]
The extension for the RA * challenge (Chal_client) includes the random number copied in step 1101. The challenge extension (Chal_AR) contains a new random number generated by the AR.
[0065]
<Authentication using asymmetric key method>
In the above-described embodiment, the authentication protocol according to the present invention based on the AAA infrastructure using the symmetric key method, that is, the shared secret key algorithm has been described. It will be apparent to those skilled in the art that the authentication protocol according to the present invention functions even when an asymmetric key scheme such as a public key algorithm is employed. With reference to FIG. 16, how the authentication protocol according to the present invention functions using a public key algorithm will be described. In FIG. 16, it is assumed that the client 320 has entered a domain 400 that has not been visited before. Therefore, the client 320 has to go through an initial authentication process.
(1) The client 320 starts router detection by transmitting RS +. In the present embodiment, RS + includes RS. RS + includes the identifier of the client 320 and the signature of the client 320. This signature is a summary of RS + encrypted using the client 320's private key. Therefore, RS + is expressed as follows.
RS + client_id + client signature
[0066]
The secret key of the client 320 is defined by the security relationship SA3 (see FIG. 5) established between the client 320 and the AAAH 310. Therefore, AAAH 310 holds the public key of client 320 and confirms the certificate of client 320 stored in RS +. In the setting shown in FIG. 16, AAAH 310 is the only entity that can confirm the signature of the client.
(2) The AR 420 receives the RS + from the client 320, but does not have a public key for decrypting the signature of the client 320, and therefore cannot confirm the signature. Therefore, the AR 420 generates AAAReq and transmits it to the AAAF 410 together with a copy of the entire RS +.
(3) The AAAF 410 does not hold the public key of the client 320 and cannot confirm the signature of the client 320. Therefore, AAAF 410 stores its public key in AAARaq and transfers it to AAAH 310.
(4) Upon receiving AAAReq from AAAF 410, AAAH 310 verifies the identity of client 320 by decrypting the signature of client 320 stored in AAAReq using the public key of client 320. If the signature of client 320 is confirmed normally, AAAH 310 responds to AAAReq by generating AAARep and sending it to AAAF 410. This AAARep includes the public key (PK) of the client 320 and the certificate of the AAAF 410. The AAAF 410 certificate is generated by extracting the AAAF 410 public key from AAAA Req and encrypting it. When encryption is performed, the AAAH 310 private key defined by the already established security relationship SA3 is used. Accordingly, AAARe transmitted from AAAH 310 to AAAF 410 is expressed as follows.
AAAF certified by the client's PK + AAAH
(5) The AAAF 410 extracts the public key of the client 320 from AAAAreq and stores it in the cache. The extracted public key is used by the AAAF 410 to authenticate the message from the client 320. The AAAF 410 generates a certificate for the AR 420, stores the certificate in AAARep, and transmits AAARep to the AR 420. The AR 420 certificate includes the AR 420 public key (PK) certified by the AAAF 410 private key. Accordingly, AAARep transmitted from the AAAF 410 to the AR 420 is expressed as follows.
AAAF certified by AR + AAAH proved by client's PK + AAAF
(6) Upon receiving AAARep from AAAF 410, AR 420 extracts the public key of client 320 and stores it in the cache. The public key of client 320 is used by AR 420 to authenticate messages from client 320. The AR 420 generates RA + and transmits it to the client 320. This RA + includes the RA, the certificate of AR420 generated by AAAF410, and the certificate of AAAF410 generated by AAAH310. Therefore, RA + is expressed as follows.
RA + AR_id + ARAF certified by AAAF + AAAF + AR certified by AAAH
[0067]
Upon receiving RA + from the AR 420, the client 320 authenticates the received RA +. First, the client 320 decrypts the AAAF 410 certificate using the AAAH 310 public key, and extracts the AAAF 410 public key. This public key is derived from the security relationship SA3 established between the client 320 and the AAAH 310. If the certificate is successfully decrypted, the client 320 can trust the extracted AAAF 410 public key. This is because this key has been certified by the AAAH 310 that the client 320 trusts. Next, the client 320 decrypts the AR 420 certificate using the extracted AAAF 410 public key, and extracts the AR 420 public key. If the certificate is successfully decrypted, the client 320 can trust the AR 420 public key. This is because this key was certified by the AAAF 410 that the client 320 trusts. Using the AR 420 and AAAF 410 public keys distributed to the client 320, new security relationships SA 4 and SA 5 (see FIG. 8) are established between the client 320 and the AR 420 and between the client 320 and the AAAF 410.
[0068]
The preferred embodiments of the present invention have been described above, but these are merely exemplary in nature and do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications and additions can be made while maintaining the novel and advantageous features of the invention and without departing from the spirit of the invention. Accordingly, the scope of the invention is defined only by the appended claims, as interpreted correctly.
[0069]
【The invention's effect】
As described above, according to the present invention, communication between an unauthorized client or an unauthorized access router can be prevented by mutually authenticating the client and the access router.
Further, according to the present invention, since an authentication mechanism is executed in the network layer, applicable access technologies are not limited.
Furthermore, since the router detection widely used in the existing communication protocol is used as an authentication protocol carrier, the present invention can be easily introduced into the existing communication protocol.
[Brief description of the drawings]
FIG. 1 is a diagram showing an example of a data communication network corresponding to a third generation wireless mobile access IP to which the present invention is applied.
FIG. 2 is a simplified diagram illustrating an L3 handoff process by a standard mobile client performed in the data communication network shown in FIG.
FIG. 3 is a simplified diagram illustrating a general AAA network model in which an authentication protocol according to the present invention is implemented.
FIG. 4 is a simplified diagram illustrating a general AAA network model in which an authentication protocol according to the present invention is implemented.
FIG. 5 is a diagram showing an implicit security model already established in the networks shown in FIGS. 3 and 4;
FIG. 6 is a flowchart illustrating an authentication protocol using a router detection mechanism according to an embodiment of the present invention in which the identity of a mobile client is confirmed by a home server.
7 is a simplified diagram of the process shown in FIG.
FIG. 8 is a diagram showing new security relationships established between the client and the access router (SA4) and between the client and AAAF (SA5) after the authentication protocol shown in FIGS. 6 and 7 is implemented.
FIG. 9 is a flowchart illustrating an authentication protocol according to another embodiment of the invention in which the identity of the mobile client is verified by a foreign server.
FIG. 10 is a simplified diagram of the process shown in FIG. 9;
FIG. 11 is a flow chart illustrating an authentication protocol according to another embodiment of the present invention in which the client and access router are re-authenticated.
12 is a simplified diagram of the process shown in FIG.
FIG. 13 is a simplified diagram illustrating another embodiment of the present invention in which an access router sends a router advertisement itself.
FIG. 14 is a flowchart illustrating an authentication protocol using a router detection mechanism according to an embodiment of the present invention in which billing and notification messages include challenges and provide protection against replay attacks.
FIG. 15 is another example of an authentication protocol performed in the embodiment of the present invention shown in FIG. 14 in which the client and access router are re-authenticated.
FIG. 16 is a flowchart illustrating an authentication protocol using a router detection mechanism according to an embodiment of the present invention in which an asymmetric key algorithm is used.
[Explanation of symbols]
100 Data communication network
120 core network
130 Gateway router
135, 320 clients
140 IP Mobile Backbone
145, 420, 421 Access router
150 subnetwork
155 Wireless access point
200 Mediation server
300 Home Domain
310 Home server
400 foreign domains
410 Foreign Server

Claims

A sending step in which the mobile client sends a billing message including its identity certificate;
A verification step in which a trusted entity confirms the identity certificate;
A reply step in which the access router sends back a notification message only when the identity certificate is successfully confirmed;
An authentication process characterized by comprising:

The authentication process according to claim 1, wherein the trusted entity authenticates the mobile router with an access router located between the mobile client and the trusted entity.

The transmission step, the confirmation step, and the reply step are performed in a communication network that is managed by at least one management server and includes a plurality of management domains each having at least one access router. 1. The authentication process according to 1.

4. The authentication process according to claim 3, wherein the trusted entity is a server that manages a home domain to which the mobile client belongs.

The authentication process according to claim 3, wherein the trusted entity is a server that manages a foreign domain visited by the mobile client.

4. The authentication process of claim 3, wherein the trusted entity is an access router that receives the billing message from the mobile client.

The authentication process according to claim 1, wherein the notification message includes an identity certificate of the access router for the mobile client to authenticate the access router.

A mobility serving node voluntarily sending a notification message including the identity certificate of the access router;
The mobile client confirming the identity certificate;
If the mobile client is unable to verify the identity certificate, performing the sending step, the confirmation step, and the reply step;
The authentication process according to claim 1, further comprising:

While the mobile client is communicating with the access router, performing the sending step, the confirmation step, and the reply step,
The authentication process according to claim 1, wherein the notification message from the access router includes the identity certificate of the access router.

During the communication with the mobile client, the access router transmits a notification message whose validity period is shorter than a predetermined reference value to start execution of the transmission step, the confirmation step, and the reply step, and the access router The authentication process according to claim 1, wherein the mobile client is re-authenticated to a router.

The authentication process according to claim 1, wherein IPv4 is used for data communication.

The authentication process according to claim 1, wherein IPv6 is used for data communication.

The authentication process according to claim 1, wherein the confirmation is performed using an asymmetric key algorithm.

The authentication process according to claim 1, wherein the confirmation is performed using a symmetric key algorithm.

The authentication process according to claim 1, wherein at least one of the billing message and the notification message includes a challenge.

A sending unit for sending a billing message including the mobile client's identity certificate;
A receiver for receiving a notification message from the access router;
Comprising
The mobile client is characterized in that the mobile client receives the notification message only when the identity certificate is successfully confirmed.

The notification message includes an identity certificate of the access router;
The mobile client according to claim 16, wherein the mobile client has a function of confirming the identity certificate.

The mobile client according to claim 16, wherein the transmitting unit transmits the billing message to the access router and re-authenticates the access router while the mobile client is communicating with the access router.

The mobile client according to claim 16, wherein IPv4 is used for data communication.

The mobile client according to claim 16, wherein IPv6 is used for data communication.

The mobile client of claim 16, wherein the confirmation is performed using an asymmetric key algorithm.

The mobile client of claim 16, wherein the confirmation is performed using a symmetric key algorithm.

The mobile client according to claim 16, wherein at least one of the billing message and the notification message includes a challenge.

An AAA network having a plurality of management domains each managed by at least one management server, each having at least one access router,
A mobile client that sends a billing message containing your identity certificate,
A trusted entity that verifies the identity certificate;
An access router that returns a notification message only when the identity certificate is successfully confirmed;
An AAA network comprising:

The AAA network of claim 24, wherein the trusted entity authenticates to the mobile client an access router located between the mobile client and the trusted entity.

The AAA network according to claim 24, wherein the trusted entity is a server that manages a home domain to which the mobile client belongs.

The AAA network of claim 24, wherein the trusted entity is a server that manages a foreign domain visited by the mobile client.

25. The AAA network of claim 24, wherein the trusted entity is an access router that receives the billing message from the mobile client.

25. The AAA network according to claim 24, wherein the notification message includes an identity certificate of the access router for the mobile client to authenticate the access router.

The access router voluntarily sends a notification message containing its identity certificate,
25. The AAA network of claim 24, wherein the mobile client sends the billing message if it cannot verify the identity certificate.

While communicating with the access router, the mobile client sends the billing message;
The AAA network according to claim 24, wherein the access router transmits a notification message including an identity certificate for the mobile client to authenticate the access router.

The communication router according to claim 24, wherein the access router transmits a notification message having a validity period shorter than a predetermined reference value during communication with the mobile client, and causes the mobile client to transmit the billing message. AAA network.

The AAA network according to claim 24, wherein IPv4 is used for data communication.

The AAA network according to claim 24, wherein IPv6 is used for data communication.

The AAA network according to claim 24, wherein the confirmation is performed using an asymmetric key algorithm.

25. The AAA network according to claim 24, wherein the confirmation is performed using a symmetric key algorithm.

The AAA network according to claim 24, wherein at least one of the billing message and the notification message includes a challenge.