JP2003218954A

JP2003218954A - 安全なネットワークアクセス方法

Info

Publication number: JP2003218954A
Application number: JP2002324920A
Authority: JP
Inventors: Alper E Yegin; イーヤインアルパー; Xiaoning He; ハションニン; Carl Williams; ウィリアムスカール
Original assignee: Docomo Communications Labs USA Inc
Current assignee: Docomo Innovations Inc
Priority date: 2001-11-09
Filing date: 2002-11-08
Publication date: 2003-07-31
Anticipated expiration: 2022-11-08
Also published as: JP3822555B2

Abstract

(57)【要約】【課題】モバイルクライアントおよびアクセスルータ
を互いに認証するネットワーク層プロトコルを提供す
る。【解決手段】モバイルクライアント３２０は、請求メ
ッセージ（ＲＳ＋）を送信し、接続サービスを要求す
る。この請求メッセージ（ＲＳ＋）は、モバイルクライ
アント３２０の身元証明書を含んでいる。この請求メッ
セージ（ＲＳ＋）を受信したアクセスルータ４２０は、
身元証明書が確認されるまでこの請求メッセージ（ＲＳ
＋）に対し応答しない。モバイルクライアント３２０の
身元証明書が確認されてはじめて、アクセスルータ４２
０は応答し、モバイルクライアント３２０に対し通知メ
ッセージ（ＲＡ＋）を返信する。従って、不正なモバイ
ルクライアントのネットワークアクセスを防止できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本出願は、２００１年１１月
９日に提出された「ルータ検出およびＡＡＡを用いた安
全なネットワークアクセス（ＳｅｃｕｒｅＮｅｔｗｏ
ｒｋＡｃｃｅｓｓＵｓｉｎｇＲｏｕｔｅｒＤｉ
ｓｃｏｖｅｒｙａｎｄＡＡＡ）」と題する米国仮出
願６０／３４５、９６７に関して優先権を主張する。な
お、この仮出願は、本明細書において参照として援用さ
れる。また、本出願では、２００２年５月１５日に提出
された「モバイルＩＰネットワークへのアクセスを安全
にする方法（ＭＥＴＨＯＤＦＯＲＳＥＣＵＲＩＮＧ
ＡＣＣＥＳＳＴＯＭＯＢＩＬＥＩＰＮＥＴＷ
ＯＲＫ）」と題する米国出願１０／１４６、５４８、お
よび２００１年１１月９日に提出された「モバイルＩＰ
登録（ＭＯＢＩＬＥＩＰＲＥＧＩＳＴＲＡＴＩＯ
Ｎ）」と題する米国仮出願６０／３３２、３９６が、相
互に参照される。なお、これらの出願は、本明細書にお
いて参照として援用される。本発明は、クライアントが
ネットワークにアクセスする接続サービスを要求する場
合、およびルータがネットワーク接続を提供する場合
に、クライアントおよびアクセスルータを相互に認証す
る双方向セキュリティプロトコルに関する。本発明にか
かるセキュリティプロトコルは、ＡＡＡ（Ａｕｔｈｅｎ
ｔｉｃａｔｉｏｎ（認証）、Ａｕｔｈｏｒｉｚａｔｉｏ
ｎ（認可）ａｎｄＡｃｃｏｕｎｔｉｎｇ（課金））
に基づき、その実行において、ルータ検出（Ｒｏｕｔｅ
ｒＤｉｓｃｏｖｅｒｙ）がキャリアとして用いられ
る。

【０００２】

【従来の技術】携帯電話機、ＰＤＡ（ｐｅｒｓｏｎａｌ
ｄｉｇｉｔａｌａｓｓｉｓｔａｎｔ）等の全世界的
にルーティング可能なＩＰ対応装置の普及とともに、公
開アクセスＩＰネットワークが広く張りめぐらされてい
る。とりわけ、近年の携帯無線技術の進歩および携帯電
話システムの成長率は、場所に拘束されない通信に対す
る、市場の巨大な需要を示している。無線通信の役割
は、ごく数年前の従来の音声および呼び出しモバイル無
線サービスを大幅に越えた。最近、ネットワークの世界
標準規格に関する公認の機関である国際電気通信連合
（ＩＴＵ）は、国際移動通信規格（ＩＭＴ−２０００）
を発表した。この標準規格では、携帯電話機、ＰＤＡ、
携帯型コンピュータ等の無線モバイルクライアントによ
る広範囲なモバイルアクセスを可能にするいわゆる第３
世代（３Ｇ）ネットワークを提案している。この第３世
代ネットワークでは、モバイルクライアント、または移
動クライアントはネットワーク資源へのアクセスを維持
しながら自由に移動し、接続ポイントをある基地局から
別の基地局へ変更することができる。３Ｇネットワーク
には、リンク層（レイヤ２）におけるモビリティを提供
するものがある。しかし、将来のネットワーク（いわゆ
る４Ｇ）は、ＩＰ層（レイヤ３）におけるモビリティを
提供すると予想されている。

【０００３】インターネットアーキテクチャの進化およ
びインターネットの円滑な運用に関わる、ネットワーク
の設計者、運用者、供給業者、研究者からなる国際団体
であるインターネット技術特別調査委員会（ＩＥＴＦ）
は、ＩＰ層におけるモビリティ支援のための標準規格を
いくつか提案している。これら提案された標準規格に
は、ＩＥＴＦのＲＦＣ２００２（別名、モバイルＩＰバ
ージョン４（ＩＰｖ４））や「ＩＰｖ６におけるモビリ
ティ支援」と題された草案「ｄｒａｆｔ−ｉｅｔｆ−ｍ
ｏｂｉｌｅｉｐ−ｉｐｖ６−１７」（別名、モバイルＩ
Ｐバージョン６）のようなモビリティ支援のための標準
規格がある。この２つの標準規格は、本願明細書におい
て参照として援用される。ＩＰｖ４およびＩＰｖ６で定
義されるプロトコル運用によると、クライアントは、ネ
ットワーク資源へのアクセスを維持しながらネットワー
ク上を移動し、接続ポイントをあるアクセスルータから
別のアクセスルータへ変更することが可能になる。通
常、この処理は、「レイヤ３（Ｌ３）ハンドオフ」と呼
ばれる。

【０００４】Ｌ３ハンドオフ処理をおこなう目的は、登
録処理をつうじて移動クライアントのパケットルーティ
ング情報を更新することである。クライアントは、「ホ
ームアドレス」により、常に指定することができる。こ
こで、「ホームアドレス」とは、ホームネットワーク上
のアクセスルータ（ホームルータ）により割り当てられ
るＩＰアドレス、またはクライアント自身により選択さ
れたＩＰアドレスのことである。しかしながら、クライ
アントがフォーリンネットワーク上にあってホームネッ
トワークから離れている場合、クライアントには、現在
のネットワークへの接続ポイントを示す気付けアドレス
が設定される。この気付けアドレスは、フォーリンネッ
トワーク上のアクセスルータ（フォーリンルータ）のア
ドレスであり、ホームネットワークから離れて動作する
クライアントは、この気付けアドレスをホームルータに
登録する。そして、登録要求を受信したホームルータ
は、クライアント宛のパケットを途中で回収し、クライ
アントの気付けアドレスへ転送する。モバイルＩＰｖ６
では、ホームネットワークから離れたクライアントは、
ホームルータおよび通信中の相手先ノードに対し対応更
新（ｂｉｎｄｉｎｇｕｐｄａｔｅ）を送信する。相手先
ノードは、クライアントのようなモバイルクライアント
であってもよいし、クライアントにデータを提供するサ
ーバであってもよい。そして、対応更新を受信した相手
先ノードは、ホームルータを介さずクライアントに対し
パケットを直接転送する。

【０００５】

【発明が解決しようとする課題】移動クライアントが、
訪問したネットワークにおいてネットワーク接続を要求
する場合、セキュリティ上の重大な問題が生じる。クラ
イアントは、ネットワークアクセスが許可される前に、
常に認証されなければならない。認証されないクライア
ントは、不正ＩＤまたは盗難ＩＤを用いて無料でネット
ワーク資源にアクセスしようとする不正利用者かもしれ
ない。また、そのようなクライアントは、ネットワーク
の秩序ある運用を乱すためだけに、ネットワークアクセ
スを要求する悪意をもったノードかもしれない。同様
に、クライアントは、自己にネットワーク接続を提供し
ているアクセスルータを認証したいと思うかもしれな
い。アクセスルータは、クライアントの通信を盗聴した
り、どこかへ転送したり、ただ中断するだけの不正なル
ータかもしれない。現在、さまざまなアクセス技術で、
数多くの認証メカニズムが実行、採用されている。例と
して、ＰＰＰおよび８０２．１１ネットワークの認証が
ある。これらのネットワークを利用する場合、リンク層
で認証メカニズムが提供されるため、その認証メカニズ
ムの適用範囲が特定のアクセス技術に限られてしまう、
という欠点があった。従って、アクセス技術を選ばない
認証メカニズムの提供が求められている。

【０００６】

【課題を解決するための手段】上記の事情に鑑み、本発
明は、ネットワーク層における認証メカニズムを用いる
ことにより、アクセス技術を選ばない安全なネットワー
クアクセス方法を提供する。本発明は、モバイルクライ
アントにネットワークアクセスを許可する前に、モバイ
ルクライアントおよびアクセスルータを互いに認証する
ネットワーク層プロトコルを提供する。本発明は、ルー
タ検出をキャリアとして用い、認証プロトコルを実行す
る。本発明の実施形態において、モバイルクライアント
は、請求メッセージを送信し、接続サービスを要求す
る。この請求メッセージは、モバイルクライアントの身
元証明書を含んでいる。この請求メッセージを受信した
アクセスルータは、身元証明書が確認されるまでこの請
求メッセージに対し応答しない。モバイルクライアント
の身元証明書が確認されてはじめて、アクセスルータは
応答し、モバイルクライアントに対し通知メッセージを
返信する。従って、不正なモバイルクライアントのネッ
トワークアクセスを防止できる。

【０００７】アクセスルータからの通知メッセージは、
アクセスルータの身元証明書を含んでいてもよい。この
アクセスルータの身元証明書が正常に確認された場合の
み、モバイルクライアントは、このアクセスルータを介
してネットワークアクセスを開始する。従って、モバイ
ルクライアントが不正なアクセスルータを介してネット
ワークアクセスを開始してしまうことを防止できる。

【０００８】請求および通知メッセージを用いることに
より、ネットワークアクセスを安全にする上での利点が
得られる。検出メカニズムは、モバイルクライアントと
アクセスルータとがオフリンク接続を確立する際の第一
歩である。すなわち、検出メカニズムを用いてモバイル
クライアントおよびアクセスルータを認証することは、
既存のプロトコルにとって無理のない拡張である。モバ
イルクライアントおよびアクセスルータの認証に検出メ
カニズムを用いることにより、プロトコル信号数を大幅
に節約できる。プロトコル信号数の節約は、通信資源が
貴重かつ高価であるモバイル無線ネットワークにとって
重要である。検出メカニズムを用いるさらなる利点は、
検出メカニズムがＩＰｖ４およびＩＰｖ６両方に共通で
あることである。従って、検出メカニズムをキャリアと
して用い、モバイルクライアントおよびアクセスルータ
の認証を実行する本発明は、ネットワークがＩＰｖ４と
ＩＰｖ６とのいずれを用いるかにかかわらず、ネットワ
ークにおいて実行可能である。

【０００９】本発明にかかる認証プロトコルは、ＡＡＡ
インフラストラクチャに基づいて、ＡＡＡプロトコルに
より提供される認証サービスおよびプロトコル信号を用
いてもよい。ＡＡＡプロトコルにおいては、複数のドメ
インが定められ、各ドメインは少なくとも１つのＡＡＡ
サーバにより管理される。ＡＡＡサーバは、アテンダン
ト、すなわちアクセスルータを介してモバイルクライア
ントに対しＡＡＡサービスを提供する。本発明では、請
求メッセージに含まれるクライアントの身元証明書を確
認するために、信用できる実体が必要である。クライア
ントが新たなフォーリンドメインに入った場合、信用で
きる実体は、クライアントのホームドメインを管理する
ＡＡＡサーバである。従って、この最初の認証過程のた
めにプロトコル信号がクライアントとホームサーバとの
間を往復するため、通信の待ち時間を生じるかもしれな
い。しかしながら、クライアントがフォーリンドメイン
にとどまっている限りにおいて、ホームサーバは確認の
ために用いられない。例えば、クライアントがフォーリ
ンドメイン内でアクセスルータを切り替えた場合は、こ
のフォーリンドメインのサーバが信用できる実体にな
る。クライアントが同一のアクセスルータに接続を要求
する場合、そのアクセスルータでさえも信用できる実体
になってもよい。従って、本発明にかかる認証プロトコ
ルに必要なプロトコル信号は、より短い距離を往復する
ことにより、認証プロセスにより生じる通信の遅延が短
縮化される。

【００１０】本発明にかかる認証プロトコルは、対称お
よび非対称鍵暗号方式等のいかなる鍵アルゴリズムを用
いても実行可能である。これらの鍵は、本発明の認証過
程に伴うプロトコル信号とともに配信されてもよい。こ
れらの鍵が配信されることにより、２つの実体間に新た
なセキュリティ関係が確立され、アドレス解決（ＡＲＰ
／ＲＡＲＰ）等の近隣検出や実体間の以後の通信のため
のプロトコル信号を安全にする。

【００１１】本発明の別の実施形態においては、アクセ
スルータは、自らの身元証明書を含む通知メッセージを
自発的に送信してもよい。この身元証明書を正常に確認
した場合、クライアントは、このアクセスルータをイン
ターネットへのゲートウェイとして使用する。この証明
を確認できない場合には、自らの身元証明書を含む請求
メッセージを送信することにより、認証過程を開始す
る。この請求メッセージは、上記で概説したように処理
される。

【００１２】本発明の別の実施形態においては、クライ
アントは、アクセスルータと通信中に、このアクセスル
ータに対し請求メッセージを送信してもよい。通信中で
さえも、正当な実体が不正な実体と入れ替わる可能性は
常にある。この請求メッセージを受けて、アクセスルー
タが自らの身元証明書を含む通知メッセージを送信し、
よって、クライアントは通信中にアクセスルータを再認
証できる。同様に、アクセスルータは、通信中のクライ
アントに対し有効期間の短い通知メッセージを送信して
もよい。この通知メッセージに対し、クライアントは自
らの身元証明書を含む請求メッセージを送信し、よっ
て、アクセスルータはクライアントを再認証できる。

【００１３】クライアントからの請求メッセージおよび
／またはアクセスルータからの通知メッセージがチャレ
ンジを含み、リプレイ攻撃から防御してもよい。

【００１４】

【発明の実施の形態】ここで、本発明の好適な実施形態
を図面を参照しつつ説明する。この図面において、同様
の構成要素には同一の参照符号が付される。本明細書に
記載されている実施形態は、性質上、例示的なものすぎ
ず、本発明の範囲を限定するものではない。なお、本実
施形態中に記載のネットワークでは、モバイルＩＰが用
いられているが、本発明は、より広く、ＩＰｖ４および
ＩＰｖ６等のいかなるＩＰベースの通信プロトコルを用
いても実行可能である。

【００１５】図１に、本発明が適用される第３世代の無
線モバイルアクセスＩＰに対応したデータ通信ネットワ
ーク１００を示す。本明細書の目的のため、データ通信
ネットワーク１００は、無線移動体通信ネットワークに
関するＩＭＴ−２０００規格およびＩＴＵの仕様に従う
ものとする。さらに、データ通信ネットワーク１００
は、ＩＥＴＦで提案されているモバイルＩＰｖ４および
モバイルＩＰｖ６規格に従い、モバイルＩＰ支援を実行
するものとする。したがって、勿論、本願では、一方の
バージョンに特有の用語を他方のバージョンの対応する
用語に置き換えて使用してもよい。例えば、「エージェ
ント」という用語は、「アクセスルータ」や、単に「ル
ータ」という用語に置き換えて使用してもよい。同様
に、「エージェント検出」は、「ルータ検出」と、「エ
ージェント請求」は、「ルータ請求」と、「登録要求」
は、「対応更新」と、それぞれ置き換えて使用してもよ
い。

【００１６】無線モバイルアクセスＩＰに対応したデー
タ通信ネットワーク１００の中心には、多数の図示せぬ
固定ノード、すなわち固定接続ポイントまたはリンクを
有する固定ノードＩＰデータネットワークであるコアネ
ットワーク１２０が備えられている。この通信ネットワ
ーク内またはこの通信ネットワークを介し、また、イン
ターネットプロトコルバージョン６（ＩＰｖ６）に従
い、デジタルデータの送受信がなされる。上述したよう
に、ＩＰｖ６は通信プロトコルのほんの一例でありＩＰ
ｖ４等の通信プロトコルと置き換えることが可能であ
る。コアネットワーク１２０のいくつかのノードは、図
示せぬ従来のルータを有し、このルータは、従来のイン
ターネットアドレッシングおよびルーティングプロトコ
ルに従って中間ノードとして機能し、ネットワークに接
続された送信元および送信先ノード間でデータパケット
を転送する。

【００１７】コアネットワーク１２０には、複数のゲー
トウェイルータ（ＧＲ）１３０が備えられており、これ
らがＩＰモバイルバックボーンを構成している。このＩ
Ｐモバイルバックボーンを構成するゲートウェイルータ
１３０は、それ自体がコアネットワーク１２０のノード
であり、コアネットワーク１２０を介して相互接続され
ている。各ゲートウェイ１３０には、モバイルクライア
ント１３５と通信可能な複数のアクセスルータ１４５が
接続されている。このモバイルクライアントとしては、
コードレス電話機、携帯電話機、携帯型コンピュータ、
個人情報管理機器等の種類の異なるモバイル無線通信装
置が利用可能である。アクセスルータ１４５は、ホーム
ルータ（ＨＲ）およびフォーリンルータ（ＦＲ）として
機能し、ゲートウェイルータ１３０を介してクライアン
ト１３５をコアネットワーク１２０に接続する。アクセ
スルータ１４５は、アクセスネットワークのレイヤ３上
の実体である。クライアント１３５は、無線アクセスポ
イント（ＡＰ）１５５を介してアクセスルータ１４５と
通信する。このＡＰ１５５は、アクセスネットワークの
レイヤ２上の実体である。一群のＡＰ１５５は、図１の
サブネットワーク１５０を構成している。各アクセスル
ータ１４５は、サブネットワーク１５０を管理し、サブ
ネットワーク１５０とデータネットワーク１００との間
のインターフェースとしてネットワークリンクを提供す
る。クライアント１３５およびＡＰは、周知のＣＤＭ
Ａ、Ｗ−ＣＤＭＡ、または同様なデジタルデータ通信技
術を用い、互いに通信する。

【００１８】モバイルＩＰｖ６に従い、各クライアント
１３５には、ホームルータであるアクセスルータ１４５
を含むホームサブネットワークが割り当てられる。この
アクセスルータ１４５は、クライアント１３５の現在位
置情報を保持し、クライアント１３５の現在位置にパケ
ットを転送する。その他のアクセスルータ１４５は、フ
ォーリンルータとして機能する。クライアント１３５
は、ホームサブネットワークから離れている間、このフ
ォーリンルータに「訪問する」ことができる。クライア
ント１３５が、任意の時刻にホームルータあるいはフォ
ーリンルータのいずれかと通信する場合、いずれかのル
ータがネットワークリンクを確立し、クライアント１３
５にネットワークアクセスを提供する。ネットワーク上
のクライアント１３５およびアクセスルータ１４５は、
従来のインターネットプロトコルを用いた従来の固定ノ
ードデータネットワークと同様に、それぞれ一意のＩＰ
アドレスをもつ。

【００１９】データ通信ネットワーク１００全体の中
で、２つのレベルのハンドオフ過程が考えられる。第１
のレベルは、マクロレベルハンドオフまたはレイヤ３ハ
ンドオフであり、クライアントの位置の変化をともな
う。この位置の変化とは、クライアントが、あるアクセ
スルータにより管理される無線サブネットワークから、
別のアクセスルータにより管理される無線サブネットワ
ークに移動することである。従って、Ｌ３ハンドオフに
より、クライアントのネットワークリンクは必然的に変
化する。第２のレベルは、マイクロレベルハンドオフま
たはレイヤ２ハンドオフであり、サブネットワーク１５
０内でのクライアントの位置変化をともなう。この場
合、クライアントの無線リンクは変化するが、ネットワ
ークリンクは変化しない。Ｌ２ハンドオフ処理は、無線
携帯通信ネットワークにおいて一般的である。例えば、
隣接するＡＰからのビーコン信号の強度を用いて隣接す
るＡＰの到達可能性を検出することは周知である。

【００２０】図２は、モバイルＩＰｖ６に従って行われ
るモバイルクライアントによるＬ３ハンドオフ過程を示
す簡略図である。図２において、データ通信ネットワー
ク１００は、コアネットワーク１２０およびコアネット
ワーク１２０に接続されるアクセスルータ１４５を含
む。クライアント１３５は、初めは出発点Ａに位置し、
中間地点Ｂを経由して地点Ｃに移動する。図２におい
て、出発点Ａのクライアント１３５は、フォーリンルー
タであるアクセスルータ１４５（ＦＲ１）に管理される
フォーリンサブネットワーク内で動作し、ＦＲ１を介し
てコアネットワーク１２０に接続されている。一方、地
点Ｃは、フォーリンルータであるアクセスルータ１４５
（ＦＲ２）に管理されるフォーリンサブネットワーク内
に位置している。モバイルクライアント１３５は、ＦＲ
１に管理されるサブネットワークを通り抜け、ＦＲ２に
管理されるサブネットワークに入る。従って、図２にお
いて考えられるＬ３ハンドオフは、ネットワークリンク
をＦＲ１からＦＲ２へと切り替える際に行われる。

【００２１】クライアント１３５が、出発点Ａから移動
し中間地点Ｂに到着するとき、ある時点でＦＲ１とのさ
らなる無線通信が失敗し始める。クライアント１３５
は、ＦＲ１に管理されるサブネットワーク１５０を離
れ、ＦＲ２に管理されるサブネットワーク１５０に入る
ところである。クライアント１３５が中間地点Ｂを通り
すぎ、Ｌ２ハンドオフが行われると、クライアント１３
５の無線リンク先は、ＦＲ１に管理されるサブネットワ
ークのＡＰからＦＲ２に管理されるサブネットワークの
ＡＰに変わる。到着地点Ｃに近づくにつれ、クライアン
ト１３５は、Ｌ３ハンドオフ、すなわちＦＲ２との間で
モバイルＩＰ登録をおこなう。この登録過程では、モバ
イルＩＰｖ６に定められるルータ検出が最初に行われ
る。このルータ検出により、クライアント１３５は隣接
するアクセスルータ１４５を検出し、このアクセスルー
タ１４５のリンク層アドレスを特定し、このアクセスル
ータ１４５への経路についての到達可能性情報を保持す
る。このために、ルータ検出において、一対のＩＣＭＰ
（ＩｎｔｅｒｎｅｔＣｏｎｔｒｏｌＭｅｓｓａｇｅ
Ｐｒｏｔｏｃｏｌ）パケットタイプ、すなわちルータ請
求およびルータ通知が定義される。ルータ請求は、クラ
イアントにより送信され、隣接するアクセスルータにル
ータ通知の生成および返信を要求するメッセージであ
る。アクセスルータ１４５は、定期的またはクライアン
ト１３５からのルータ請求に対して、ルータ通知を送信
することにより、自らの存在を通知する。ルータ通知が
含む情報に基づき、クライアント１３５は気付けアドレ
ス（ＣｏＡ）を設定する。

【００２２】ＦＲ２からルータ通知を受信すると、クラ
イアント１３５はこの通知内の情報に基づいて気付けア
ドレスを生成、設定する。そして、クライアント１３５
は、新しい気付けアドレスおよびクライアント１３５の
不変のホームＩＰアドレスを含む対応更新をホームルー
タに送信することにより、新しい気付けアドレスを登録
する。ホームルータは、アドレスの対応情報を記録する
キャッシュ内のクライアントのルーティング情報を更新
し、その結果、クライアント１３５とＦＲ２との間にＬ
３リンクが確立される。以後、クライアント１３５のホ
ームＩＰアドレスに送信されるパケットは、ホームルー
タにより途中で回収され、ＦＲ２にトンネル送信され、
ＦＲ２からクライアント１３５に配信される。パケット
の迂回ルーティングにより生ずるパケット遅延を解消す
るため、以後パケットをクライアント１３５に直接転送
可能なあらゆる相手先ノードに対しても、対応更新が送
信される。

【００２３】モバイルデータ通信の人気が高まるにつ
れ、悪意をもったクライアントがネットワークアクセス
を試みる可能性も高くなる。このクライアントは、不正
ＩＤまたは盗難ＩＤを用いてネットワーク資源に無料で
アクセスしようとする不正利用者かもしれず、ネットワ
ークの秩序ある運用に対する脅威にほかならない。従っ
て、この悪意をもったクライアントをふるい落とすため
に、ネットワークアクセスを要求するクライアントは、
ネットワークアクセスが許可される前に、常に認証され
なければならない。同様に、クライアントは、ネットワ
ークアクセスを開始する前に、接続サービスを提供する
アクセスルータの認証を望むかもしれない。アクセスル
ータの中には、クライアントの通信を盗聴したり、どこ
かへ転送したり、ただ中断するだけの不正なアクセスル
ータがあるかもしれない。本発明が提供する双方向セキ
ュリティプロトコルでは、クライアントおよびアクセス
ルータを相互に認証し、その結果、クライアントはゲー
トウェイとして用いる前に悪意をもったアクセスルータ
を特定でき、アクセスルータは転送サービスを提供する
前に悪意をもったクライアントを特定できる。

【００２４】本発明にかかるセキュリティメカニズム
は、認証、認可、および課金（ＡＡＡ）プロトコルに基
づいている。ＲＡＤＩＵＳやＤＩＡＭＥＴＥＲ等のＡＡ
Ａプロトコルは、今日、インターネット上で使用されて
おり、ダイアルアップコンピュータに対して、認証、認
可、および課金サービスを提供している。このようなＡ
ＡＡ管理サービス、特にＡＡＡサービスにより提供され
る認証サービスは、モバイルＩＰにおいても同様に有用
である。実際、モバイルＩＰは、基本的な枠組みにほと
んど変更を加えないＡＡＡインフラストラクチャ上で実
行可能である。例えば、ＡＡＡプロトコルにおけるクラ
イアントは、モバイルＩＰのモバイルノードと考えら
れ、ＡＡＡプロトコルにおけるアテンダントは、モバイ
ルＩＰのアクセスルータに相当する。モバイルクライア
ントおよびアクセスルータの機能を向上させ、これらが
ＡＡＡメッセージを解読可能であれば、ＡＡＡインフラ
ストラクチャ上でモバイルＩＰが実行可能になる。

【００２５】図３および４は、ネットワークアクセスサ
ービス（ＮＡＳ）およびモバイルＩＰが実行される、一
般的ＡＡＡネットワークモデルを示す簡略図である。管
理ドメインは、１または共通の管理の下で動作する複数
のネットワークからなる。図１に示すデータ通信ネット
ワーク１００内において、多数の管理ドメインが定義さ
れてもよい。しかし、図の簡略化のため、図３および４
に示すＡＡＡネットワークには、２つの管理ドメインの
みが示されている、すなわち、広域インターネットによ
り隔てられたホームドメイン３００およびフォーリンド
メイン４００である。各ドメインは、ドメインの構成要
素に対しＡＡＡサービスを提供するＡＡＡサーバを備え
ている。ホームドメイン３００は、ホームサーバＡＡＡ
Ｈ３１０により管理されている。フォーリンドメイン４
００は、フォーリンサーバＡＡＡＦ４１０により管理さ
れている。各ホームおよびフォーリンドメインは、ドメ
イン内に配置されるアテンダントをさらに備えている。
ただし、図３および４では、フォーリンドメイン４００
のみが、２つのアテンダント４２０および４２１を備え
ている。ＡＡＡプロトコルに従って、アテンダント４２
０および４２１は、クライアント３２０とローカルドメ
イン４００との間のサービスインターフェースを提供す
る。この実施形態では、クライアント３２０は、ホーム
ドメイン３００からフォーリンドメイン４００に移動
し、管理ドメイン４００内のアテンダント４２０または
４２１のいずれかからのサービスを望んでいるものとす
る。上述したように、モバイルＩＰは、図３および４に
示すＡＡＡネットワーク上で実行される。モバイルＩＰ
の場合、アテンダントは、実際上、モバイルクライアン
トに対しネットワークアクセスサービスを提供するアク
セスルータ（ＡＲ）である。従って、「アテンダント」
という用語は、「アクセスルータ」または、単に「Ａ
Ｒ」という用語と置き換えて使用してもよい。

【００２６】ＡＡＡプロトコルにより提供される重要な
サービスの１つは、認証である。一般的に、ＡＡＡ認証
メカニズムは以下のように機能する。ＡＡＡに対応した
第１の実体が通信先に望む第２の実体に対し証明書を提
示し、第２の実体が第１の実体の証明書を正常に確認可
能な場合のみ、２つの実体間の通信が許可される。この
証明書は、２つの実体間でセキュリティ関係（ＳＡ）が
確立される際に定義される鍵アルゴリズムを用いて確認
される。ＡＡＡプロトコルは、異なる鍵アルゴリズムを
用いても機能するように設計されている。あるアルゴリ
ズムは、公開鍵インフラストラクチャに基づき、別のア
ルゴリズムは、対称鍵の配信に基づいている。ＡＡＡサ
ーバは、鍵の配信センターとして機能し、アテンダント
やクライアント等のＡＡＡの実体の要求により、ＡＡＡ
の２つの実体間で提示される証明書を確認するために用
いられる鍵を生成、配信する。２つのＡＡＡの実体に対
し鍵を配信することにより、これらの間にセキュリティ
関係が確立される。説明上、図３および４に示すＡＡＡ
ネットワークでは、対称鍵または共有秘密鍵アルゴリズ
ムが用いられるものとする。対称鍵アルゴリズムは、他
の鍵アルゴリズムよりも用い易く、インターネット全体
への適応性という問題に解決策を提供する。しかしなが
ら、本発明を実施するにあたり、公開鍵方式等の非対称
鍵アルゴリズムや他の鍵アルゴリズムを用いてもよいこ
とは、当業者にとっては明らかであろう。また、認証ト
ークンを用いてもよい。

【００２７】図３および４に示すＡＡＡネットワークに
は、暗黙のセキュリティモデルが存在する。図５は、こ
のような暗黙のセキュリティモデルを示しており、矢印
は、初めから確立されていると想定されるセキュリティ
関係を示す。まず、矢印ＳＡ１が示すように、ＡＡＡＦ
４１０とＡＲ４２０および４２１との間にセキュリティ
関係が確立されているものとする。ＡＲはＡＡＡＦ４１
０に管理されるドメインに位置しており、両者間にはす
でに信用が確立されているはずであるので、ＡＲ４２０
および４２１とＡＡＡＦ４１０との間にＳＡ１が確立さ
れているものとしてよいであろう。次に、ＡＡＡＨ３１
０とＡＡＡＦ４１０との間にセキュリティ関係が確立さ
れているものとする。これらのＡＡＡサーバは、初め、
両者間にセキュリティ関係を確立している必要はない
が、必要に応じて両者間にセキュリティ関係を確立する
能力をもたねばならない。矢印ＳＡ２が示すセキュリテ
ィ関係は、２つのＡＡＡサーバ間で直接的に、または仲
介ＡＡＡサーバ２００を介して間接的に、確立可能であ
る。最後に、矢印ＳＡ３が示すように、クライアント３
２０とＡＡＡＨ３１０との間にセキュリティ関係が確立
されているものとする。クライアント３２０は、ＡＡＡ
Ｈ３１０が位置するホームドメイン３００からスタート
しているので、ＳＡ３が確立されているものとしてよい
であろう。従って、ＡＡＡＨ３１０は、最初にクライア
ントを認証可能な唯一の実体である。

【００２８】本発明の重要な特徴は、本発明ではルータ
検出メカニズムが「キャリア」として用いられ、モバイ
ルＩＰにおいてＡＡＡセキュリティプロトコルを実行す
る点である。本発明では、ルータ請求およびルータ通知
が拡張され、既存のＡＡＡプロトコルにモバイルＩＰ認
証機能を付加する。

【００２９】＜最初のルータ検出（新しいドメインに入
る場合）＞図６は、本発明の実施形態にかかる、ルータ
検出プロトコルを用いたネットワークアクセス認証過程
を示すフローチャートである。図７は、図６に示す過程
の簡略図である。この実施形態では、クライアント３２
０は、ＡＲ４２０および４２１、またはＡＡＡＦ４１０
のいずれともセキュリティ関係を確立していないものと
する。すなわち、クライアント３２０は、以前にフォー
リンドメイン４００に訪問したことがないか、もしくは
長期間フォーリンドメイン４００から離れていたためＡ
Ｒ４２０、ＡＲ４２１、およびＡＡＡＦ４１０との間で
以前に確立されたセキュリティ関係が無効になったもの
とする。

【００３０】クライアント３２０は、フォーリンドメイ
ン４００に入り、リンクが張られているアクセスルータ
によるネットワークアクセスを要求する。ステップ５０
１において、クライアント３２０は、拡張ルータ請求メ
ッセージ（ＲＳ＋）を送信することによりルータ検出を
開始する。これはマルチキャストメッセージであり、ク
ライアントと同じリンク上のすべてのアクセスルータに
より受信される。通常のルータ請求メッセージとは異な
り、これはクライアントの身元証明書を含む。この身元
証明書は、標準のルータ請求パケットの拡張という形で
送信される。ＲＳ＋は、標準のルータ請求メッセージ
（ＲＳ）と同様の各種構成要素を含む。また、ＲＳ＋
は、ネットワークアクセス識別子（ＮＡＩ）またはＩＰ
アドレスになりうるクライアントの識別子（ｃｌｉｅｎ
ｔ_ｉｄ）と、クライアントの署名とを含む。この署名
は、ＡＡＡＨ３１０と共有するクライアントの秘密鍵
（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）により暗号化され
たＲＳ＋の要約である。従って、ＲＳ＋は以下のように
表現される。ＲＳ＋ｃｌｉｅｎｔ_ｉｄ＋クライアントによ
る署名

【００３１】クライアントの共有秘密鍵は、クライアン
ト３２０とＡＡＡＨ３１０との間に確立されるセキュリ
ティ関係ＳＡ３（図５参照）により定義される。従っ
て、ＡＡＡＨ３１０は、クライアントの共有秘密鍵（ｃ
ｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を保有し、ＲＳ＋に格
納されたクライアントの署名を確認する。ＡＲ４２０お
よび他のアテンダントは、クライアント３２０からＲＳ
＋を受信する。しかしながら、上述したように、ＡＲ４
２０はクライアント３２０とセキュリティ関係を確立し
ていないため、クライアント３２０の身元を確認する共
有秘密鍵を保有しない。標準のルータ検出メカニズムに
よると、アクセスルータはルータ請求メッセージに応じ
てルータ通知メッセージを返信する。しかしながら、本
発明では、クライアント３２０が正常に認証されるま
で、ＡＲ３２０および他のアクセスルータはルータ通知
メッセージを返信しない。

【００３２】ＡＲ４２０は、クライアント３２０の確認
をＡＡＡＦ４１０に委任する。ＡＲ４２０は、ＡＡＡ要
求メッセージ（ＡＡＡＲｅｑ）を生成し、ＡＡＡＦ４１
０に送信する（ステップ５０３）。このＡＡＡＲｅｑ
は、クライアント３２０からのＲＳ＋全体のコピーを含
む。ＡＲ４２０からＡＡＡＦ４１０へ送信されたＡＡＡ
Ｒｅｑは、両者間に確立されたセキュリティ関係ＳＡ１
に基づいて保護される。ＡＡＡＲｅｑは、Ｒａｄｉｕｓ
やＤＩＡＭＥＴＥＲ等のＡＡＡプロトコルに従って生成
される。ＡＡＡメッセージを生成する際の好適な手順に
ついては、「Ｄｉａｍｅｔｅｒ基本プロトコル」と題さ
れたＩＥＴＦの草案「ｄｒａｆｔ−ｉｅｔｆ−ｄｉａｍ
ｅｔｅｒ−０７.ｔｘｔ」および「Ｄｉａｍｅｔｅｒモ
バイルＩＰ拡張仕様」と題されたＩＥＴＦの草案「ｄｒ
ａｆｔ−ｃａｌｈｏｕｎ−ｄｉａｍｅｔｅｒ−ｍｏｂｉ
ｌｅｉｐ−１２.ｔｘｔ」の中で論じられている。な
お、この２つの草案は本明細書において参照として援用
される。

【００３３】上述したように、ＡＡＡＦ４１０は、クラ
イアント３２０とセキュリティ関係を確立しておらず、
従って、クライアントの身元を確認する共有秘密鍵を保
有していない。しかし、ＲＳ＋に格納されたクライアン
トの識別子により、ＡＡＡＦ４１０はクライアント３２
０のホームドメインがホームドメイン３００であること
を認識する。そして、ＡＡＡＦ４１０は、ＡＡＡＨ３１
０との間に確立されたセキュリティ関係ＳＡ２を使っ
て、ホームドメイン３００に位置するＡＡＡＨ３１０に
対しＲＳ＋のコピーとＡＡＡＲｅｑを転送する（ステッ
プ５０５）。

【００３４】ＡＡＡＦ４１０からＡＡＡＲｅｑを受信す
ると、ＡＡＡＨ３１０は、クライアントの共有秘密鍵を
用いてＡＡＡＲｅｑに格納されたクライアントの署名を
復号することにより、クライアント３２０の身元を確認
する。クライアントが正当な身元を提示すれば、ＡＡＡ
Ｈ３１０はクライアントの身元を正常に確認できるはず
である。クライアントの身元を確認できない場合、ＡＡ
ＡＨ３１０はＡＡＡ応答メッセージ（ＡＡＡＲｅｐ）を
生成し、ＡＡＡＦ４１０を介してＡＲ４２０に送信す
る。このＡＡＡＲｅｐは、ＡＡＡＨ３１０がクライアン
ト３２０を認証できない旨を示す認証結果を含む。ＡＡ
ＡＲｅｐも、ＲａｄｉｕｓやＤＩＡＭＥＴＥＲ等のＡＡ
Ａプロトコルに従って生成される。ＡＡＡＲｅｐを受信
すると、ＡＲ４２０はクライアント３２０からのルータ
請求メッセージを無視し、ルータ通知メッセージを返信
しない。従って、認証されないクライアントによるネッ
トワーク資源へのアクセスは防止される。

【００３５】ＡＡＡＨ３１０がクライアント３２０の身
元を正常に確認した場合、ＡＡＡＨ３１０は、ＡＡＡ応
答（ＡＡＡＲｅｐ）を生成しＡＡＡＦ４１０に送信する
ことにより、ＡＡＡＦ４１０からのＡＡＡＲｅｑに応答
する（ステップ５０７）。このＡＡＡＲｅｐは、２つの
共有秘密鍵を含む。これらのうち一方は、クライアント
３２０とＡＲ４２０との間で用いられ、他方は、クライ
アント３２０とＡＡＡＦ４１０との間で用いられる。こ
れらの共有秘密鍵はＡＡＡＨ３１０により生成され、Ａ
ＡＡＦ４１０、ＡＲ４２０、およびクライアント３２０
に配信され、クライアント３２０とＡＡＡＦ４１０との
間およびクライアント３２０とＡＲ４２０との間にセキ
ュリティ関係を確立する。これらの共有秘密鍵である
（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および（ｃｌｉｅｎｔ
‐ＡＡＡＦ_ｋｅｙ）は、それぞれ複製される。複製さ
れた共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および
（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）は、これらの真実
性および機密性を守るため、クライアント３２０と共有
する秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を用い
てＡＡＡＦ４１０により暗号化され、クライアント３２
０に配信される。元の鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅ
ｙ）および（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）は復号
化され、ＡＲ４２０およびＡＡＡＦ４１０にそれぞれ配
信される。従って、ＡＡＡＨ３１０からＡＡＡＦ４１０
に送信されるＡＡＡＲｅｐは、以下のように表現され
る。ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ＋ｃｌｉｅｎｔ‐ＡＡ
ＡＦ_ｋｅｙ＋ＡＡＡＨにより暗号化された（ｃｌ
ｉｅｎｔ‐ＡＲ_ｋｅｙ＋ｃｌｉｅｎｔ‐ＡＡＡＦ_
ｋｅｙ）

【００３６】ＡＡＡＨ３１０からのＡＡＡＲｅｐによ
り、ＡＡＡＦ４１０はクライアント３２０が信用できる
ことを認識する。そして、ＡＡＡＦ４１０は、ＡＡＡＲ
ｅｐから復号化された共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡ
ＡＦ_ｋｅｙ）を抽出し、キャッシュに格納する。この
抽出された共有秘密鍵は、クライアント３２０からのメ
ッセージを認証するため、ＡＡＡＦ４１０により用いら
れる。そして、ＡＡＡＦ４１０は、ＡＡＡＲｅｐをＡＲ
４２０に転送する（ステップ５０９）。ＡＡＡＦ４１０
からのＡＡＡＲｅｐにより、ＡＲ４２０はクライアント
３２０の身元が正常に認証されたことを認識する。そし
て、ＡＲ４２０は、ＡＡＡＲｅｐから復号化された共有
秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を抽出し、キャ
ッシュに格納する。この共有秘密鍵は、クライアント３
２０からのメッセージを認証するため、ＡＲ４２０によ
り用いられる。そして、ＡＲ４２０は、拡張ルータ通知
（ＲＡ＋）を生成し、クライアント３２０に送信する
（ステップ５１１）。このＲＡ＋は、標準のルータ通知
メッセージ（ＲＡ）、ＡＲ４２０の識別子（ＡＲ_ｉ
ｄ）、および共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋ
ｅｙ）により暗号化された共有秘密鍵（ｃｌｉｅｎｔ‐
ＡＲ_ｋｅｙ）および（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅ
ｙ）を含む。このＲＡ＋は、さらにＡＲ４２０の署名を
含む。この署名は、ＡＲ４２０がＡＡＡＦ４１０から受
信した共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）によ
り暗号化されたＲＡ＋の要約である。従って、このＲＡ
＋は以下のように表現される。ＲＡ＋ＡＲ_ｉｄ＋ＡＡＡＨにより暗号化され
た（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ＋ｃｌｉｅｎｔ‐
ＡＡＡＦ_ｋｅｙ）＋ＡＲによる署名

【００３７】ＡＲ４２０からＲＡ＋を受信すると、クラ
イアント３２０は受信したＲＡ＋を認証する。まず、ク
ライアント３２０は、ＡＡＡＨ３１０と共有する秘密鍵
（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を用いて、共有秘
密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）および（ｃｌｉｅ
ｎｔ‐ＡＡＡＦ_ｋｅｙ）を復号化する。これらの秘密
鍵が正常に復号化された場合、これらの鍵はクライアン
ト３２０が信用するＡＡＡＨ３１０により証明されるこ
とから、クライアント３２０はこれらの秘密鍵を信用で
きる。次に、クライアント３２０は、復号化された秘密
鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を用いて、ＡＲ４２
０の署名を復号化する。署名が正常に復号化された場
合、ＡＲ４２０の身元はクライアント３２０が信用する
秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）により確認され
ることから、クライアント３２０はＡＲ４２０を信用で
きる。また、署名が正常に復号化されることにより、ク
ライアント３２０に対しＲＡ＋の信頼性が保証される。
クライアント３２０およびＡＲ４２０に配信される共有
秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）により、クライ
アント３２０とＡＲ４２０との間に新しいセキュリティ
関係ＳＡ４（図８参照）が確立される。クライアント３
２０およびＡＡＡＦ４１０に配信される共有秘密鍵（ｃ
ｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）により、クライアント
３２０とＡＡＡＦ４１０との間に新しいセキュリティ関
係ＳＡ５が確立される。

【００３８】ＡＲ４２０の署名を認証できない場合、ク
ライアント３２０はＡＲ４２０からのＲＡ＋を無視し、
認証可能な証明書を含む他のアクセスルータからのＲＡ
＋を待つ。従って、クライアント３２０が不正なアクセ
スルータを介してネットワークアクセスを開始してしま
うことを防止できる。

【００３９】図６および７に示す認証過程は、長時間を
要し、かなりの通信待ち時間を生じるであろう。この通
信待ち時間は、主にＡＡＡメッセージがＡＡＡＦ４１０
とＡＡＡＨ３１０とを隔てる広域インターネットを行き
来するために要する時間である。ＡＡＡメッセージがＡ
ＡＡＦ４１０あるいはＡＡＡＨ３１０に送信される場
合、常に、いくらかの待ち時間を伴う。図６および７に
示す最初の認証過程では、これら遠く離れたサーバと通
信しなければならない。しかしながら、もしＡＲ４２０
およびＡＡＡＦ４１０がＡＡＡＦ４１０あるいはＡＡＡ
Ｈ３１０によらずにクライアントを認証できれば、認証
メカニズムに伴う待ち時間が短縮化される。

【００４０】＜以降のルータ検出（同一ドメイン内で、
新しいアクセスルータを検出する場合）＞クライアント
３２０は、ドメイン４００内を移動し、クライアント３
２０の身元を認証していない別のアクセスルータと接続
してもよい。図９は、本発明の別の実施形態に基づき、
このような場合に行われる認証ルータ検出を示すフロー
チャートである。図１０は、図９に示す過程の簡略図で
ある。図９および１０において、図６および７に示すＡ
Ｒ４２０との最初の認証過程を経た後、クライアント３
２０は、ＡＲ４２０に管理されるサブネットワークを離
れ、ＡＲ４２１に管理されるサブネットワークに入るも
のとする。ＡＲ４２１を介してネットワークにアクセス
するため、クライアント３２０はＲＳ＋を再び送信する
（ステップ７０１）。今回送信されるＲＳ＋は、図６お
よび７に示す最初の認証過程で用いられたものと同様の
メッセージを含み、以下のように表現される。ＲＳ＋ｃｌｉｅｎｔ_ｉｄ＋クライアントによ
る署名

【００４１】しかしながら、本実施形態のＲＳ＋に含ま
れる署名は、共有鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅ
ｙ）により暗号化されるため、ＡＲ４２１は署名を確認
することができない。そこで、ＡＲ４２１は、ＡＡＡＲ
ｅｑを生成しＡＡＡＦ４１０に送信することにより、ク
ライアント３２０の確認をＡＡＡＦ４１０に委任する
（ステップ７０３）。ＡＲ４２１からのＡＡＡＲｅｑ
は、ＲＳ＋全体のコピーを含む。ＡＡＡＦ４１０は、図
６および７に示す先の認証過程において共有秘密鍵（ｃ
ｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）を取得しているため、
クライアント３２０の身元を認識できるはずである。Ａ
ＡＡＦ４１０は、ＡＡＡＨ３１０によることなく、共有
秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＦ_ｋｅｙ）でクライア
ント３２０の署名を復号化することにより、クライアン
ト３２０の身元を確認する。クライアント３２０の署名
を確認できない場合、ＡＡＡＦ４１０は、ＡＡＡＲｅｑ
を生成し、ＡＲ４２１に送信する（ステップ７０５）。
これにより、ＡＲ４２１に対し、クライアント３２０が
信用できない旨を知らせる。ＡＲ４２１は、クライアン
ト３２０からのＲＳ＋を無視する。クライアント３２０
の署名が正常に確認された場合、ＡＡＡＦ４１０は、ク
ライアント３２０とＡＲ４２１との間で共有する秘密鍵
（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）を生成する。この秘
密鍵（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）は、複製され
る。複製により２つとなった秘密鍵の一方はそのまま暗
号化されず、他方は共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡ
Ｆ_ｋｅｙ）により暗号化される。ＡＡＡＦ４１０は、
暗号化されていない鍵と暗号化された鍵とをＡＡＡＲｅ
ｑに格納し、ＡＲ４２１に送信する（ステップ７０
５）。従って、ＡＡＡＦ４１０からＡＲ４２１に送信さ
れるＡＡＡＲｅｐは、以下のように表現される。ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ＋ＡＡＡＦにより暗
号化された（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）

【００４２】ＡＡＡＦ４１０からのＡＡＡＲｅｐによ
り、ＡＲ４２１はクライアント３２０が信用できること
を認識する。そして、ＡＲ４２１は復号化された秘密鍵
（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）を抽出し、キャッシ
ュに格納する。この格納された秘密鍵は、クライアント
３２０からの以後のメッセージを認証するため、ＡＲ４
２１により用いられる。ＡＲ４２１は、ＲＡ＋を生成
し、クライアント３２０に送信する（ステップ７０
７）。ＡＲ４２１からのＲＡ＋は、以下のように表現さ
れる。ＲＡ＋ＡＲ_ｉｄ＋ＡＡＡＦにより暗号化され
た（ｃｌｉｅｎｔ‐ＡＲ２_ｋｅｙ）＋ＡＲによる
署名

【００４３】ＡＲ４２１からＲＡ＋を受信すると、クラ
イアント３２０は、共有秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡ
Ｆ_ｋｅｙ）を用いて復号化し、秘密鍵（ｃｌｉｅｎｔ
‐ＡＲ２_ｋｅｙ）を抽出する。もしこの鍵が正常に復
号化されたら、クライアント３２０はこの鍵を信用でき
る。クライアント３２０は、共有秘密鍵（ｃｌｉｅｎｔ
‐ＡＲ２_ｋｅｙ）を用いてＡＲ４２１の署名を復号化
することにより、ＲＡ＋を認証する。署名が正常に復号
化された場合、クライアント３２０はＡＲ４２１および
ＲＡ＋の真実性を信用できる。クライアント３２０およ
びＡＲ４２１に配信される共有秘密鍵（ｃｌｉｅｎｔ‐
ＡＲ２_ｋｅｙ）により、両者間に新しいセキュリティ
関係が確立される。署名を復号化できない場合、クライ
アントはＡＲ４２１からのＲＡ＋を無視し、認証可能な
署名を含む他のアクセスルータからのＲＡ＋を待つ。

【００４４】図９および１０に示す、以降の認証過程
は、図６および７に示す認証過程と比較して迅速に行わ
れる。これは、図９および１０に示す認証過程では、Ａ
ＡＡＨ３１０とメッセージをやり取りする必要がなく、
従って、プロトコル信号がより短い距離を往復するため
である。

【００４５】＜以降のルータ検出（同一アクセスルータ
を検出する場合）＞各ＲＡ＋には、有効期間がある。従
って、同一のアクセスルータに接続している場合でも、
先のＲＡ＋の有効期間が経過する前に、クライアントは
同一のアクセスルータとの認証過程を経なければならな
い。この場合、図１１および１２に示すように、本発明
にかかる認証過程において、プロトコル信号は最短距離
を往復する。図１１および１２では、クライアント３２
０は、ステップ８０１においてＲＳ＋をＡＲ４２０に送
信する。ＲＳ＋は、以下のように表現される。ＲＳ＋ｃｌｉｅｎｔ_ｉｄ＋クライアントによ
る署名

【００４６】署名は、図６および７に示す最初の認証過
程においてクライアント３２０が取得した共有秘密鍵
（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）により暗号化される。
ＡＲ４２０は、クライアント３２０と同一の鍵を共有し
ているため、クライアント３２０の身元を認識できるは
ずである。ＡＲ４２０は、ＡＡＡＦ４１０によらずに、
共有秘密鍵（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を用いて署
名を復号化することにより、クライアント３２０の身元
を確認する。クライアント３２０の身元を確認できない
場合、ＡＲ４２０はＲＳ＋を無視する。クライアント３
２０の身元を正常に確認した場合、ＡＲ４２０は、ＲＡ
＋を生成し、クライアント３２０に送信する。本実施形
態のＲＡ＋は、以下のように表現される。ＲＡ＋ＡＲ_ｉｄ＋ＡＲによる署名

【００４７】従って、クライアント３２０とＡＲ４２０
との通信は、プロトコル信号が最短距離を往復するため
最速の認証メカニズムである。

【００４８】＜非請求ルータ通知＞アクセスルータは、
認証可能なＲＳ＋の受信を待つのではなく、ＲＡ＋を定
期的に送信してもよい。図１３において、ＡＲ４２０お
よび４２１はＲＡ＋を定期的に送信するものとする。Ｒ
Ａ＋は、以下のように表現される。ＲＡ＋ＡＲ_ｉｄ＋ＡＲによる署名

【００４９】ＡＲ４２０から送信されるＲＡ＋は、ＲＡ
とＡＲ４２０の署名とを含む。ＡＲ４２１から送信され
るＲＡ＋は、ＲＡとＡＲ４２１の署名とを含む。クライ
アント３２０は、図６および７に示すＡＲ４２０との最
初の認証過程を以前に経ているものとする。先の認証過
程を通じて、クライアント３２０とＡＲ４２０との間、
およびクライアント３２０とＡＡＡＦ４１０との間に
は、セキュリティ関係が確立されている。ＡＲ４２０か
らのＲＡ＋がクライアント３２０に到達していれば、ク
ライアント３２０はＲＡ＋を認証できるはずである。従
って、クライアント３２０は、ＡＲ４２０を介して安全
にネットワークアクセスを開始できる。受信するいかな
るＲＡ＋も認識できない場合、クライアントは、ＲＳ＋
を送信することにより、図６および７に示す最初の認証
過程を経なければならない。

【００５０】＜再認証＞通信中のクライアントおよびＡ
Ｒのどちらも常に、本発明の認証過程を開始し、互いに
再認証してよい。これは、通信中でさえも悪意をもった
実体が正当な実体と入れ替わる可能性が常にあるという
理由から重要である。クライアントは、ＡＲとの通信
中、ＲＳ＋を送信することにより、いつでもこの過程を
開始してよい。ＡＲは、クライアントによる再認証に対
しＲＡ＋をクライアントに返信することにより、ＲＳ＋
に応答できるはずである。同様に、ＡＲは、クライアン
トを収容している間、クライアントを再認証できる。Ａ
Ｒは、有効期間の非常に短いユニキャストルータ通知メ
ッセージをクライアントに送信することにより、クライ
アントの再認証を開始する。このルータ通知メッセージ
は有効期間が非常に短いことから、クライアントは、Ａ
Ｒがまもなくクライアントへの接続サービスを停止する
ことを認識する。クライアントは、ＲＳ＋を送信し同一
リンク上の利用可能な他のアクセスルータを検出するこ
とにより、このようなルータ通知メッセージに応答す
る。そして、ＡＲは、クライアントから送信されたＲＳ
＋を認証する。

【００５１】＜旧プロトコルとの相互運用＞ネットワー
ク全体において、本発明にかかる拡張ルータ検出メカニ
ズムをサポートできるドメインと、標準のルータ検出メ
カニズムのみをサポートできるドメインとが混在しても
よい。従って、標準のルータ検出メカニズムのみをサポ
ートするクライアントが、本発明にかかる拡張ルータ検
出メカニズムをサポートするドメインに移動する場合が
あってもよいし、また、拡張ルータ検出メカニズムをサ
ポートするクライアントが、標準のルータ検出メカニズ
ムのみをサポートするドメインに移動する場合があって
もよい。どちらの場合も、本発明にかかる認証プロトコ
ルは、標準のルータ検出メカニズムの運用の妨げとはな
らない。

【００５２】まず、拡張ルータ検出メカニズムをサポー
トするクライアントが、標準のルータ検出メカニズムの
みをサポートするドメイン内において接続サービスを受
けようとする場合、クライアントはＲＳ＋を送信する。
しかしながら、隣接するアクセスルータは、ＲＳ＋に加
えられた新しい拡張部分を認識できず、従って、この拡
張部分を無視する。アクセスルータは、ＲＳ＋をｒとし
て処理し、ＲＡを返信する。ここで、この「認証されて
いない」ルータ通知メッセージを用いるか否かはクライ
アント次第である。

【００５３】次に、標準のルータ検出メカニズムのみを
サポートするクライアントが、本発明にかかる拡張ルー
タ検出メカニズムをサポートするドメイン内において接
続サービスを受けようとする場合、クライアントは、い
かなる新しい拡張をも含まないＲＳを送信する。このよ
うな「認証されない」ルータ請求メッセージを受信した
場合、ＲＡ＋を返信するか、あるいは全く応答しないか
は、隣接するアクセスルータ次第である。

【００５４】どちらの場合であっても、本発明にかかる
拡張ルータ検出メカニズムをサポートするクライアント
およびＡＲは、通信相手が拡張ルータ検出メカニズムを
サポートできるか、または標準のルータ検出メカニズム
のみをサポートできるのかを検出し、それに応じて応答
できる。認証されていないメッセージに対し応答する
か、または受け取るかは、ネットワークの設計方針次第
である。

【００５５】＜リプレイ攻撃に対する防御＞リプレイ攻
撃とは、盗難パスワードの単なる再利用である。パスワ
ード送信中にクラッカーがそのパスワードを盗聴できれ
ば、クラッカーはそれ以降いつでも使用できるパスワー
ドのコピーを手に入れることになる。たとえパスワード
が暗号化されてやり取りされていたとしても、クラッカ
ーは、以前に取得した通信を単に再実行することによ
り、ログインできるかもしれない。本発明にかかる認証
プロトコルは、チャレンジに関する拡張を加えることに
より、リプレイ攻撃に対する防御を設けることができ
る。

【００５６】図１４は、チャレンジ方式を用いてリプレ
イ攻撃に対する防御を設ける本発明の実施形態を示すフ
ローチャートである。図１４においては、クライアント
３２０は、ＡＲ４２０またはＡＡＡＦ４１０と通信した
ことがなく、従って、図６および７に示す最初の認証過
程を経なければならないものとする。まず、クライアン
ト３２０は、ＲＳを送信する（ステップ１００１）。Ａ
Ｒ４２０は、ＲＳを受信するが、ＲＳを送信したクライ
アントの身元が認証されるまで信用できない。ＲＳを送
信したクライアントは、クライアント３２０との過去の
通信を盗聴し、クライアント３２０の識別情報を盗み、
偽造ＩＤを使ってネットワークにアクセスする悪意をも
ったノードかもしれない。

【００５７】クライアント３２０からのＲＳに対する返
信として、ＡＲ４２０は、クライアントの身元およびＲ
Ｓの真実性を確認する（ステップ１００３）。具体的に
は、ステップ１００３において、ＡＲ４２０は、チャレ
ンジに関する拡張とＲＡをクライアント３２０に送信す
る。このチャレンジに関する拡張は、ＡＲ４２０により
生成された乱数を含む。ＡＲ４２０からのＲＡをきっか
けとして、クライアント３２０は、拡張ルータ請求メッ
セージ（ＲＳ*）を生成、送信する（ステップ１００
５）。ＲＳ*は、ＲＳと、クライアントの識別子、すな
わちクライアントのＩＰアドレスまたはＮＡＩと、秘密
鍵の要求とを含む。この秘密鍵は、ＡＲ４２０と共有さ
れ、ＡＲ４２０とのセキュリティ関係を確立する。ＲＳ
*は、さらに２つのチャレンジに関する拡張を含む。一
方のチャレンジに関する拡張は、ステップ１００３にお
いてクライアントがＡＲ４２０から受信したチャレンジ
のコピーを含み、他方のチャレンジに関する拡張は、ク
ライアント自身により生成された乱数を含む。最後に、
ＲＳ*は、クライアント３２０とＡＡＡＨ３１０との間
で共有される秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅ
ｙ）を用いて暗号化されるクライアント３２０の署名を
含んだ認証拡張を含む。従って、本実施形態において、
ＲＳ*は以下のように表現される。ＲＳ＋ｃｌｉｅｎｔ_ｉｄ＋ｃｌｉｅｎｔ‐Ａ
Ｒ_ｋｅｙ_ｒｅｑｕｅｓｔ＋Ｃｈａｌ_ＡＲ＋
Ｃｈａｌ_ｃｌｉｅｎｔ＋クライアントによる署名

【００５８】クライアント３２０からＲＳ*を受信する
と、ＡＲ４２０は、チャレンジに関する拡張（Ｃｈａｌ
_ＡＲ）をチェックし、この拡張に含まれる乱数がステ
ップ１００３においてクライアントに送信した乱数と同
一であるかを調べる。乱数が同一の場合、ＲＳ*は、事
実上、ステップ１００３においてＡＲ４２０がクライア
ント３２０に送信したチャレンジに対する応答であると
いえる。乱数が一致しない場合、おそらくＲＳ*は、盗
難ＩＤを使ってクライアント３２０だと偽る悪意をもっ
たノードからのものであるため、ＡＲ４２０はこのＲＳ
*を無視しなければならない。乱数が一致した場合、以
降の認証過程は、図６および７において述べた過程と同
様である。

【００５９】クライアント３２０の身元がＡＡＡＨ３１
０により正常に確認された場合、ＡＲ４２０は、拡張ル
ータ通知メッセージ（ＲＡ*）を生成し、クライアント
３２０に対し送信する（ステップ１００７）。本実施形
態において、ＲＡ*は、ＲＡと、クライアント３２０と
ＡＲ４２０との間で共有する秘密鍵（ｃｌｉｅｎｔ‐Ａ
Ｒ_ｋｅｙ）とを含む。この秘密鍵は、ＡＡＡＨ３１０
により生成されたものである。上述したように、この鍵
は、クライアント３２０とＡＡＡＨ３１０との間で共有
する秘密鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を用い
て暗号化される。ＲＡは、さらに２つのチャレンジに関
する拡張を含む。一方のチャレンジに関する拡張は、ス
テップ１００５のおいてＡＲ４２０がクライアントから
受信した乱数のコピーを含み、他方のチャレンジに関す
る拡張は、ＡＲ４２０により生成されクライアント３２
０とＡＲ４２０との間の次回の通信で用いられる新しい
乱数を含む。ＲＡ*は、新しく配信された共有秘密鍵
（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ）を用いて暗号化された
ＡＲ４２０の署名を含んだ認証拡張も含む。従って、本
実施形態のＲＡ*は、以下のように表現される。ＲＡ＋ＡＲ_ｉｄ＋ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ_ｒ
ｅｐｌｙ＋Ｃｈａｌ_ｃｌｉｅｎｔ＋Ｃｈａｌ_
ＡＲ＋ＡＲによる署名

【００６０】ＡＲ４２０からＲＡ*を受信すると、クラ
イアント３２０は、チャレンジに関する拡張（Ｃｈａｌ
_ｃｌｉｅｎｔ）をチェックし、この拡張に含まれる乱
数がステップ１００５においてＡＲ４２０に送信した乱
数と同一であるかを調べる。乱数が一致しない場合、悪
意をもったアクセスルータが盗難ＩＤを使ってＡＲ４２
０だと偽っているかもしれないため、クライアント３２
０はこのＲＡ*を無視しなければならない。乱数が一致
した場合、クライアント３２０は、チャレンジに関する
拡張（Ｃｈａｌ_ＡＲ）から乱数を抽出し、ＡＲ４２０
との以後の通信のためキャッシュに格納する。そして、
クライアント３２０は、ＡＡＡＨ３１０と共有する秘密
鍵（ｃｌｉｅｎｔ‐ＡＡＡＨ_ｋｅｙ）を用いて鍵応答
（ｃｌｉｅｎｔ‐ＡＲ_ｋｅｙ_ｒｅｐｌｙ）を復号化
し、ＡＲ４２０と共有する秘密鍵（ｃｌｉｅｎｔ‐ＡＲ
_ｋｅｙ）を抽出する。この抽出された共有秘密鍵を用
いて、クライアントはＡＲ４２０の署名を確認する。

【００６１】図１４に示す最初の認証過程を実行後、す
なわちクライアント３２０とＡＲ４２０との間でセキュ
リティ関係が確立された後、クライアント３２０および
ＡＲ４２０は、互いに再認証してもよい。図１５に、こ
のような再認証過程の一例を示す。再認証過程におい
て、まず、クライアント３２０がＲＳ*を送信する（ス
テップ１１０１）。これに対する返信として、ＡＲ４２
０は、ＲＡ*を送信する（ステップ１１０３）。クライ
アント３２０とＡＲ４２０との間でセキュリティ関係が
既に確立されているので、ＲＳ*は以下のように表現さ
れる。ＲＳ＋ｃｌｉｅｎｔ_ｉｄ＋Ｃｈａｌ_ＡＲ＋
Ｃｈａｌ_ｃｌｉｅｎｔ＋クライアントによる署
名

【００６２】ＲＳ*のチャレンジに関する拡張（Ｃｈａ
ｌ_ＡＲ）は、ステップ１００７においてコピーされた
乱数を含む。チャレンジに関する拡張（Ｃｈａｌ_ｃｌ
ｉｅｎｔ）は、クライアントにより生成された新しい乱
数を含む。

【００６３】ＲＡ*は、以下のように表現される。ＲＡ＋ＡＲ_ｉｄ＋Ｃｈａｌ_ｃｌｉｅｎｔ＋
Ｃｈａｌ_ＡＲ＋ＡＲによる署名

【００６４】ＲＡ*のチャレンジに関する拡張（Ｃｈａ
ｌ_ｃｌｉｅｎｔ）は、ステップ１１０１においてコピ
ーされた乱数を含む。チャレンジに関する拡張（Ｃｈａ
ｌ_ＡＲ）は、ＡＲにより生成された新しい乱数を含
む。

【００６５】＜非対称鍵方式を用いた認証＞上述した実
施形態においては、対称鍵方式、すなわち共有秘密鍵ア
ルゴリズムを用いるＡＡＡインフラストラクチャに基づ
いた、本発明にかかる認証プロトコルについて説明し
た。本発明にかかる認証プロトコルが公開鍵アルゴリズ
ム等の非対称鍵方式を採用しても機能することは、当業
者にとって明らかである。図１６を参照して、いかに本
発明にかかる認証プロトコルが公開鍵アルゴリズムを用
いて機能するかについて説明する。図１６において、ク
ライアント３２０が以前に訪問したことのないドメイン
４００に入ったものとする。従って、クライアント３２
０は、最初の認証過程を経なければならない。（１）クライアント３２０は、ＲＳ＋を送信することに
より、ルータ検出を開始する。本実施形態において、Ｒ
Ｓ＋は、ＲＳを含む。また、ＲＳ＋は、クライアント３
２０の識別子とクライアント３２０の署名とを含む。こ
の署名は、クライアント３２０の秘密鍵を用いて暗号化
されたＲＳ＋の要約である。従って、ＲＳ＋は、以下の
ように表現される。ＲＳ＋ｃｌｉｅｎｔ_ｉｄ＋クライアントによ
る署名

【００６６】クライアント３２０の秘密鍵は、クライア
ント３２０とＡＡＡＨ３１０との間に確立されるセキュ
リティ関係ＳＡ３（図５参照）により定義される。従っ
て、ＡＡＡＨ３１０は、クライアント３２０の公開鍵を
保有し、ＲＳ＋に格納されたクライアント３２０の証明
書を確認する。図１６に示す設定では、ＡＡＡＨ３１０
が、クライアントの署名を確認できる唯一の実体であ
る。（２）ＡＲ４２０は、クライアント３２０からＲＳ＋を
受信するが、クライアント３２０の署名を復号化する公
開鍵を保有しないため、署名を確認できない。そこで、
ＡＲ４２０は、ＡＡＡＲｅｑを生成し、ＲＳ＋全体のコ
ピーとともにＡＡＡＦ４１０に送信する。（３）ＡＡＡＦ４１０は、クライアント３２０の公開鍵
を保有せず、クライアント３２０の署名を確認できな
い。そこで、ＡＡＡＦ４１０は、自身の公開鍵をＡＡＡ
Ｒｅｑに格納し、ＡＡＡＨ３１０に転送する。（４）ＡＡＡＦ４１０からＡＡＡＲｅｑを受信すると、
ＡＡＡＨ３１０は、クライアント３２０の公開鍵を用い
てＡＡＡＲｅｑに格納されたクライアント３２０の署名
を復号化することにより、クライアント３２０の身元を
確認する。クライアント３２０の署名を正常に確認した
場合、ＡＡＡＨ３１０は、ＡＡＡＲｅｐを生成しＡＡＡ
Ｆ４１０に送信することにより、ＡＡＡＲｅｑに応答す
る。このＡＡＡＲｅｐは、クライアント３２０の公開鍵
（ＰＫ）とＡＡＡＦ４１０の証明書とを含む。ＡＡＡＦ
４１０の証明書は、ＡＡＡＲｅｑからＡＡＡＦ４１０の
公開鍵を抽出し、これを暗号化することにより生成され
る。なお、暗号化する際、既に確立されたセキュリティ
関係ＳＡ３により定義されるＡＡＡＨ３１０の秘密鍵が
用いられる。従って、ＡＡＡＨ３１０からＡＡＡＦ４１
０に送信されるＡＡＡＲｅｐは、以下のように表現され
る。クライアントのＰＫ＋ＡＡＡＨにより証明されたＡ
ＡＡＦ（５）ＡＡＡＦ４１０は、ＡＡＡＲｅｑからクライアン
ト３２０の公開鍵を抽出し、キャッシュに格納する。こ
の抽出された公開鍵は、クライアント３２０からのメッ
セージを認証するために、ＡＡＡＦ４１０により用いら
れる。ＡＡＡＦ４１０は、ＡＲ４２０の証明書を生成
し、ＡＡＡＲｅｐにこの証明書を格納し、ＡＡＡＲｅｐ
をＡＲ４２０に送信する。ＡＲ４２０の証明書は、ＡＡ
ＡＦ４１０の秘密鍵により証明されたＡＲ４２０の公開
鍵（ＰＫ）を含む。従って、ＡＡＡＦ４１０からＡＲ４
２０に送信されるＡＡＡＲｅｐは、以下のように表現さ
れる。クライアントのＰＫ＋ＡＡＡＦにより証明さ
れたＡＲ＋ＡＡＡＨにより証明されたＡＡＡＦ（６）ＡＡＡＦ４１０からＡＡＡＲｅｐを受信すると、
ＡＲ４２０は、クライアント３２０の公開鍵を抽出し、
キャッシュに格納する。クライアント３２０の公開鍵
は、クライアント３２０からのメッセージを認証するた
めに、ＡＲ４２０により用いられる。ＡＲ４２０は、Ｒ
Ａ＋を生成し、クライアント３２０に送信する。このＲ
Ａ＋は、ＲＡと、ＡＡＡＦ４１０により生成されたＡＲ
４２０の証明書と、ＡＡＡＨ３１０により生成されたＡ
ＡＡＦ４１０の証明書とを含む。従って、ＲＡ＋は、以
下のように表現される。ＲＡ＋ＡＲ_ｉｄ＋ＡＡＡＦにより証明された
ＡＲ＋ＡＡＡＨにより証明されたＡＡＡＦ＋Ａ
Ｒによる署名

【００６７】ＡＲ４２０からＲＡ＋を受信すると、クラ
イアント３２０は、受信したＲＡ＋を認証する。クライ
アント３２０は、まずＡＡＡＨ３１０の公開鍵を用いて
ＡＡＡＦ４１０の証明書を復号化し、ＡＡＡＦ４１０の
公開鍵を抽出する。この公開鍵は、クライアント３２０
とＡＡＡＨ３１０との間に確立されているセキュリティ
関係ＳＡ３に由来する。証明書が正常に復号化された場
合、クライアント３２０は抽出されたＡＡＡＦ４１０の
公開鍵を信用できる。これは、この鍵がクライアント３
２０が信用するＡＡＡＨ３１０により証明されたためで
ある。次に、クライアント３２０は、抽出されたＡＡＡ
Ｆ４１０の公開鍵を用いてＡＲ４２０の証明書を復号化
し、ＡＲ４２０の公開鍵を抽出する。証明書が正常に復
号化された場合、クライアント３２０は、ＡＲ４２０の
公開鍵を信用できる。これは、この鍵がクライアント３
２０が信用するＡＡＡＦ４１０により証明されたためで
ある。クライアント３２０に配信されたＡＲ４２０およ
びＡＡＡＦ４１０の公開鍵を用いて、クライアント３２
０とＡＲ４２０との間およびクライアント３２０とＡＡ
ＡＦ４１０との間に新しいセキュリティ関係ＳＡ４およ
びＳＡ５（図８参照）が確立される。

【００６８】以上本発明の好適な実施形態を説明してき
たが、これらは、性質上、例示的なものにすぎず、本発
明の範囲を限定するものではない。本発明の斬新かつ有
利な特徴を保ちつつ、且つ本発明の趣旨を逸脱せずに、
種々の変形および追加を加えてもよいことは、当業者に
とって明らかである。従って、本発明の範囲は、正しく
解釈された添付の請求の範囲によってのみ定義される。

【００６９】

【発明の効果】以上説明したように、本発明によれば、
クライアントとアクセスルータとが相互に認証すること
により、不正なクライアントまたは不正なアクセスルー
タによる通信を防止できる。また、本発明によれば、ネ
ットワーク層において認証メカニズムが実行されるため
適用可能なアクセス技術が限定されない。さらに、本発
明は、既存の通信プロトコルにおいて広く用いられてい
るルータ検出が認証プロトコルのキャリアとして用いら
れるので、既存の通信プロトコルへの導入が容易であ
る。

【図面の簡単な説明】

【図１】本発明が適用される第３世代の無線移動体ア
クセスＩＰに対応するデータ通信ネットワークの一例を
示す図である。

【図２】図１に示すデータ通信ネットワークにおいて
行われる標準的なモバイルクライアントによるＬ３ハン
ドオフ処理を示す簡略図である。

【図３】本発明にかかる認証プロトコルが実行される
一般的ＡＡＡネットワークモデルを示す簡略図である。

【図４】本発明にかかる認証プロトコルが実行される
一般的ＡＡＡネットワークモデルを示す簡略図である。

【図５】図３および４に示すネットワークにおいて、
既に確立されている暗黙のセキュリティモデルを示す図
である。

【図６】モバイルクライアントの身元がホームサーバ
により確認される本発明の実施形態にかかる、ルータ検
出メカニズムを用いた認証プロトコルを示すフローチャ
ートである。

【図７】図６に示す過程の簡略図である。

【図８】図６および７に示す認証プロトコル実施後、
クライアントとアクセスルータとの間（ＳＡ４）および
クライアントとＡＡＡＦとの間（ＳＡ５）に確立される
新しいセキュリティ関係を示す図である。

【図９】モバイルクライアントの身元がフォーリンサ
ーバにより確認される本発明の別の実施形態にかかる、
認証プロトコルを示すフローチャートである。

【図１０】図９に示す過程の簡略図である。

【図１１】クライアントおよびアクセスルータが再認
証される本発明の別の実施形態にかかる、認証プロトコ
ルを示すフローチャートである。

【図１２】図１１に示す過程の簡略図である。

【図１３】アクセスルータがルータ通知を自ら送信す
る本発明の別の実施形態を示す簡略図である。

【図１４】請求および通知メッセージがチャレンジを
含みリプレイ攻撃に対し防御を設ける本発明の実施形態
にかかる、ルータ検出メカニズムを用いた認証プロトコ
ルを示すフローチャートである。

【図１５】クライアントおよびアクセスルータが再認
証される、図１４に示す本発明の実施形態において行わ
れる認証プロトコルの別の例である。

【図１６】非対称鍵アルゴリズムが用いられる本発明
の実施形態にかかる、ルータ検出メカニズムを用いた認
証プロトコルを示すフローチャートである。

【符号の説明】

１００データ通信ネットワーク１２０コアネットワーク１３０ゲートウェイルータ１３５、３２０クライアント１４０ＩＰモバイルバックボーン１４５、４２０、４２１アクセスルータ１５０サブネットワーク１５５無線アクセスポイント２００仲介サーバ３００ホームドメイン３１０ホームサーバ４００フォーリンドメイン４１０フォーリンサーバ

フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｈ０４Ｑ 7/24 7/26 7/30 (72)発明者アルパーイーヤインアメリカ合衆国、カリフォルニア州 94404、フォスターシティ、♯シー、フォスターシティブールバード 1033 (72)発明者ションニンハアメリカ合衆国、カリフォルニア州 94087、サニーベイル、♯5701、ウエストエルカミノロード 250 (72)発明者カールウィリアムスアメリカ合衆国、カリフォルニア州 94306、パロアルト、♯154、エルカミノロード 3790 Ｆターム(参考） 5J104 AA07 KA04 KA05 MA01 PA02 PA07 5K030 GA15 HA08 HC01 HC09 HD03 LC13 5K033 AA08 DA01 DA06 DA19 DB18 5K067 AA21 BB04 BB21 DD11 DD51 EE02 EE10 EE16 FF02 HH11 HH22

Claims

【特許請求の範囲】

【請求項１】モバイルクライアントが、自身の身元証
明書を含む請求メッセージを送信する送信ステップと、信用できる実体が、前記身元証明書を確認する確認ステ
ップと、前記身元証明書が正常に確認された場合のみ、アクセス
ルータが通知メッセージを返信する返信ステップと、を具備することを特徴とする認証過程。
【請求項２】前記信用できる実体が、前記モバイルク
ライアントと前記信用できる実体との間に位置するあら
ゆる仲介物を、前記モバイルクライアントに対し認証す
ることを特徴とする請求項１に記載の認証過程。
【請求項３】各々少なくとも１の管理サーバにより管
理され、各々少なくとも１のアクセスルータを備えた複
数の管理ドメインを有する通信ネットワークにおいて、
前記送信ステップ、前記確認ステップ、および前記返信
ステップを行うことを特徴とする請求項１に記載の認証
過程。
【請求項４】前記信用できる実体が、前記モバイルク
ライアントが属するホームドメインを管理するサーバで
あることを特徴とする請求項３に記載の認証過程。
【請求項５】前記信用できる実体が、前記モバイルク
ライアントが訪問するフォーリンドメインを管理するサ
ーバであることを特徴とする請求項３に記載の認証過
程。
【請求項６】前記信用できる実体は、前記モバイルク
ライアントから前記請求メッセージを受信するアクセス
ルータであることを特徴とする請求項３に記載の認証過
程。
【請求項７】前記通知メッセージは、前記モバイルク
ライアントが前記アクセスルータを認証するための、前
記アクセスルータの身元証明書を含むことを特徴とする
請求項１に記載の認証過程。
【請求項８】モビリティサービングノードが、前記ア
クセスルータの前記身元証明書を含む通知メッセージを
自発的に送信するステップと、前記モバイルクライアントが、前記身元証明書を確認す
るステップと、前記モバイルクライアントが前記身元証明書を確認でき
ない場合、前記送信ステップ、前記確認ステップ、およ
び前記返信ステップを行うステップと、を具備することを特徴とする請求項１に記載の認証過
程。
【請求項９】前記モバイルクライアントが前記アクセ
スルータと通信中、前記送信ステップ、前記確認ステッ
プ、および前記返信ステップを行い、前記モバイルクラ
イアントに対し前記アクセスルータを再認証し、前記アクセスルータからの前記通知メッセージが、前記
アクセスルータの前記身元証明書を含むことを特徴とす
る請求項１に記載の認証過程。
【請求項１０】前記モバイルクライアントと通信中
に、前記アクセスルータは、前記送信ステップ、前記確
認ステップ、および前記返信ステップの実行を開始する
ため有効期間の短い通知メッセージを送信し、前記アク
セスルータに対し前記モバイルクライアントを再認証す
ることを特徴とする請求項１に記載の認証過程。
【請求項１１】データ通信には、ＩＰｖ４が用いられ
ることを特徴とする請求項１に記載の認証過程。
【請求項１２】データ通信には、ＩＰｖ６が用いられる
ことを特徴とする請求項１に記載の認証過程。
【請求項１３】非対称鍵アルゴリズムを用いて、前記
確認が行われることを特徴とする請求項１に記載の認証
過程。
【請求項１４】対称鍵アルゴリズムを用いて、前記確
認が行われることを特徴とする請求項１に記載の認証過
程。
【請求項１５】少なくとも前記請求メッセージおよび
前記通知メッセージのうちいずれか１は、チャレンジを
含むことを特徴とする請求項１に記載の認証過程。
【請求項１６】モバイルクライアントの身元証明書を
含む請求メッセージを送信する送信部と、アクセスルータから通知メッセージを受信する受信部
と、を具備し、前記身元証明書が正常に確認された場合のみ、前記モバ
イルクライアントは前記通知メッセージを受信すること
を特徴とするモバイルクライアント。
【請求項１７】前記通知メッセージは、前記アクセスル
ータの身元証明書を含み、前記モバイルクライアントは、前記身元証明書を確認す
る機能を有することを特徴とする請求項１６に記載のモ
バイルクライアント。
【請求項１８】前記モバイルクライアントが前記アク
セスルータと通信中、前記送信部は前記アクセスルータ
に対し前記請求メッセージを送信し、前記アクセスルー
タを再認証することを特徴とする請求項１６に記載のモ
バイルクライアント。
【請求項１９】データ通信には、ＩＰｖ４が用いられ
ることを特徴とする請求項１６に記載のモバイルクライ
アント。
【請求項２０】データ通信には、ＩＰｖ６が用いられ
ることを特徴とする請求項１６に記載のモバイルクライ
アント。
【請求項２１】非対称鍵アルゴリズムを用いて、前記
確認が行われることを特徴とする請求項１６に記載のモ
バイルクライアント。
【請求項２２】対称鍵アルゴリズムを用いて、前記確
認が行われることを特徴とする請求項１６に記載のモバ
イルクライアント。
【請求項２３】少なくとも前記請求メッセージおよび
前記通知メッセージのうちいずれか１は、チャレンジを
含むことを特徴とする請求項１６に記載のモバイルクラ
イアント。
【請求項２４】各々少なくとも１つの管理サーバによ
り管理され、各々少なくとも１つのアクセスルータを備
えた複数の管理ドメインを有するＡＡＡネットワークで
あって、自身の身元証明書を含む請求メッセージを送信するモバ
イルクライアントと、前記身元証明書を確認する信用できる実体と、前記身元証明書が正常に確認された場合のみ、通知メッ
セージを返信するアクセスルータと、を具備することを特徴とするＡＡＡネットワーク。
【請求項２５】前記信用できる実体が、前記モバイル
クライアントと前記信用できる実体との間に位置するあ
らゆる仲介物を、前記モバイルクライアントに対し認証
することを特徴とする請求項２４に記載のＡＡＡネット
ワーク。
【請求項２６】前記信用できる実体が、前記モバイル
クライアントが属するホームドメインを管理するサーバ
であることを特徴とする請求項２４に記載のＡＡＡネッ
トワーク。
【請求項２７】前記信用できる実体が、前記モバイル
クライアントが訪問するフォーリンドメインを管理する
サーバであることを特徴とする請求項２４に記載のＡＡ
Ａネットワーク。
【請求項２８】前記信用できる実体は、前記モバイル
クライアントから前記請求メッセージを受信するアクセ
スルータであることを特徴とする請求項２４に記載のＡ
ＡＡネットワーク。
【請求項２９】前記通知メッセージは、前記モバイル
クライアントが前記アクセスルータを認証するための、
前記アクセスルータの身元証明書を含むことを特徴とす
る請求項２４に記載のＡＡＡネットワーク。
【請求項３０】前記アクセスルータは、自身の身元証
明書を含む通知メッセージを自発的に送信し、前記モバイルクライアントは前記身元証明書を確認でき
ない場合、前記請求メッセージを送信することを特徴と
する請求項２４に記載のＡＡＡネットワーク。
【請求項３１】前記アクセスルータと通信中、前記モ
バイルクライアントは前記請求メッセージを送信し、前記アクセスルータは、前記モバイルクライアントが前
記アクセスルータを認証するための、自身の身元証明書
を含む通知メッセージを送信することを特徴とする請求
項２４に記載のＡＡＡネットワーク。
【請求項３２】前記モバイルクライアントと通信中
に、前記アクセスルータは有効期間の短い通知メッセー
ジを送信し、前記モバイルクライアントに前記請求メッ
セージを送信させることを特徴とする請求項２４に記載
のＡＡＡネットワーク。
【請求項３３】データ通信には、ＩＰｖ４が用いられる
ことを特徴とする請求項２４に記載のＡＡＡネットワー
ク。
【請求項３４】データ通信には、ＩＰｖ６が用いられ
ることを特徴とする請求項２４に記載のＡＡＡネットワ
ーク。
【請求項３５】非対称鍵アルゴリズムを用いて、前記
確認が行われることを特徴とする請求項２４に記載のＡ
ＡＡネットワーク。
【請求項３６】対称鍵アルゴリズムを用いて、前記確
認が行われることを特徴とする請求項２４に記載のＡＡ
Ａネットワーク。
【請求項３７】少なくとも前記請求メッセージおよび
前記通知メッセージのうちいずれか１は、チャレンジを
含むことを特徴とする請求項２４に記載のＡＡＡネット
ワーク。