異種ＩＰネットワークにおける認証のための装置および方法
本発明は、少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてアクセスネットワークタイプを判定し、少なくともユーザＩＤを含む開始メッセージを作成し、前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するよう構成されるモバイル機器と、カプセル化されたメッセージを前記モバイル機器から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するためのアクセスコントローラを備える、ネットワークサービスを認証および認可するためのシステムを提案する。本発明は、それに付随するネットワークサービスを認証および認可するための方法、加入者機器およびルータ機器も提案する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークサービスを認証および認可するためのシステムおよび方法に関する。
【背景技術】
【０００２】
今後の３Ｇ（第三世代）システムアーキテクチャにおいて、例えばＣＤＭＡ２０００（符号分割多元接続バージョン２０００）、携帯電話以外のＩＰベースのネットワーク、８０２．１１ワイヤレスＬＡＮ（ローカルエリアネットワーク）、ブルートゥース（登録商標）、イーサネット（登録商標）等、多数の異なるネットワークアクセス方法によりネットワークサービスが供給される可能性がある。しかし、３ＧＰＰ２においてモバイル機器が現在アクセスできるのは、ＣＤＭＡ２０００アクセス方法を使用するネットワークサービスのみである。従って、より確実かつ効果的にネットワークサービスを供給するためには、異なるアクセスネットワークがサービスを認可できるよう、モバイル機器に異なるタイプのアクセスネットワークを通じて認証する能力を持たせる必要がある。
【０００３】
いかなる種類のネットワークアクセス技術においても、ユーザ（端末）を認証するためのひとつの普遍的な認証プロセスはない。また、このことがマルチアクセスシナリオにおけるアクセスおよびセッションの可動性を難しくしている。一般的なＩＰネットワーク、携帯電話または携帯電話以外において同じ権限を使用するサービスプロビジョニングを可能にするため、ネットワークおよび移動局の間でメッセージ交換が必要とされている。しかし、ＣＤＭＡ２０００携帯電話ネットワークを使用していない場合、端末はオペレータのネットワークでそれ自体を認証しサービスを受けるために、いくつかの別の方法を使用しなければならないという問題がある。
【０００４】
ＳＩＭ（加入者識別モジュール）カードがＧＳＭ（グローバルシステムフォーモバイルコミュニケーションズ）ネットワークにおけるユーザＩＤを保持するのと同様に、ＣＤＭＡネットワークにおいて、携帯電話を使用するためのユーザＩＤを保持するＲ‐ＵＩＭチップを使用する際にも、同様の問題が生じる。Ｒ‐ＵＩＭについては、３ＧＧＰ２文書Ｃ．Ｓ００２３‐０に記載されている。
【０００５】
例えば、端末がＷＬＡＮ（ワイヤレスＬＡＮ）またはブルートゥース（登録商標）無線をインターネットなどへの接続に使用している場合、およびＲ‐ＵＩＭモジュールから同じ登録ＩＤを使用している場合、これを実現するには携帯電話以外の個別プロトコルが必要であり、本出願はこの問題に取り組むものである。
【発明の開示】
【０００６】
従って、本発明の第一の目的は、モバイル機器に異なる種類のアクセスネットワークを介して認証を行う可能性を提供することにある。
【０００７】
この目的は、次のようなシステムによって解決される。このシステムは、ネットワークサービスを認証および認可するためのシステムであって、該システムはモバイル機器を有し、
該モバイル機器は、少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてネットワークアクセスタイプを判定し、
少なくともユーザＩＤを含む開始メッセージを作成し、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するよう構成され、
さらに該システムは、カプセル化された前記メッセージを前記モバイル機器から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別される認証サーバに転送するアクセスコントローラをさらに備えるシステムである。
【０００８】
あるいは、上記目的は、ネットワークサービスを認証および認可するための方法であって、前記ネットワークはモバイル機器および認証制御機能を備え、
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けて前記モバイル機器によりネットワークアクセスタイプを判定するステップと、
少なくともユーザＩＤを含む開始メッセージを作成するステップと、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するステップと、
アクセスコントローラにより、カプセル化されたメッセージを前記モバイル機器から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するステップと、を含む方法により解決される。
【０００９】
このように、本発明によると、モバイル機器はネットワークアクセスタイプに関する情報を受信する（この情報メッセージはモバイル機器に送信される明示的メッセージであってよく、ネットワークにおいて一般的に利用可能な情報であってもよい）。モバイル機器はユーザＩＤを含む開始メッセージを作成し、認証メッセージ内のそれをアクセスコントローラへ送信する。アクセスコントローラは開始メッセージを評価し、それを的確な認証サーバへ転送する。
【００１０】
従って、モバイル機器は、認証メッセージを的確な認証サーバへ転送するひとつのコントローラだけをアドレス指定する必要がある。すなわち、モバイル機器は、どのようにして認証サーバに達するかを見極める必要がない。
【００１１】
さらに、異なるサービスのための複数の認証サーバが提供されてもよい。上述した従来技術によると、モバイル機器は複数の認証メッセージを、そのサービスが使用されるすべての異なる認証サーバに送信しなければならないことになる。それとは対照的に、本発明によれば、モバイル機器は、複数の認証サーバに対応する認証メッセージがカプセル化されるひとつの開始メッセージを送信するだけでよい。
【００１２】
従って、認証手順は簡略化される。加えて、複数のサービスが使用される場合であっても、単一の開始メッセージしか必要とされないため、ネットワークのトラフィック負荷は軽減される。
【００１３】
さらに、情報メッセージであって、ルータ通知を含む情報メッセージを発行するためのルータが提供されてもよい。
【００１４】
情報メッセージは拡張認証プロトコル（ＥＡＰ）サポートを示してもよい。
【００１５】
情報メッセージはモバイル機器がネットワークに入る際に発行されてもよい。
【００１６】
開始メッセージは、クライアント識別子オプションメッセージおよび拡張認証プロトコルサポート識別子オプションメッセージを含んでよく、前記メッセージは、クライアントタイプ、ユーザＩＤ、コアＩＰネットワーク内のクライアントをアドレス指定する方法に関わる情報（以下、「コアアドレス情報」という）のうち少なくともひとつに関する情報を含む。
【００１７】
モバイル機器およびアクセスネットワークの間のプロトコルは、ＵＤＰ、ＩＣＭＰ、ＩＣＭＰｖ６等のネットワーク層プロトコルまたはＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、およびブルートゥースプロファイル等のリンク層プロトコルのうち少なくともひとつを備えてよい。
【００１８】
適用される認証機構は、拡張認証プロトコル（ＥＡＰ）を備えてよい。
【００１９】
適用される認証機構は、携帯電話認証および音声暗号化（ＣＡＶＥ）アルゴリズムを適用するリムーバブルユーザ識別モジュール（Ｒ−ＵＩＭ）を使用する認証機構、または、ＡＫＡアルゴリズムを適用するＵＳＩＭを使用する認証機構であってよい。
【００２０】
本発明はまた、ネットワークサービスを認証および認可するためのシステムであって、モバイル機器手段であって、少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてネットワークアクセスタイプを判定し、少なくともユーザＩＤを含む開始メッセージを作成し、前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するための前記モバイル機器手段と、カプセル化されたメッセージを前記モバイル機器手段から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するためのアクセスコントローラとを備えるシステムも提案する。
【００２１】
さらに、本発明は、ネットワークサービスを認証および認可するためのシステムであって、前記ネットワークはモバイル機器および認証制御機能を備え、前記モバイル機器は、
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けて前記モバイル機器によりネットワークアクセスタイプを判定するための判定手段と、
少なくともユーザＩＤを含む開始メッセージを作成するための作成手段と、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するためのカプセル化手段と、
カプセル化されたメッセージを前記モバイル機器から読み出すための読み出し手段および前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するための転送手段を備えるアクセスコントローラ手段とを備える、システムを提案する。
【００２２】
これに関して、アクセスコントローラにより読み出されるメッセージは、別のタイプのメッセージ内においてカプセル化され、よってそのアクセスコントローラが認証サーバに送信することが知られている。
【００２３】
本発明は、アクセスコントロール機器であって、
認証メッセージがカプセル化される開始メッセージを受信するための受信手段と、
カプセル化されたメッセージを読み出すための処理手段と、
前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するための転送手段とを備えるアクセスコントロール機器も提案する。
【００２４】
また、この場合、アクセスコントローラにより読み出されるメッセージは、認証サーバに送信するため別のタイプのメッセージ内にカプセル化されてよい。
【００２５】
さらに、本発明は、加入者機器であって、
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてネットワークアクセスタイプを判定するための判定手段と、
少なくともユーザＩＤを含む開始メッセージを作成するための作成手段と、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するためのカプセル化手段と、
前記開始メッセージをアクセスコントロール機器に送信するための送信手段とを備える、加入者機器を提案する。
【００２６】
また本発明は、ルータ機器であって、少なくともひとつのネットワークアクセスタイプを示す情報メッセージを作成するための作成手段と、前記情報メッセージを加入者機器に送信するための送信手段とを備えるルータ機器を提案する。
【好適な実施形態の詳細な説明】
【００２７】
上述のように、本発明に従ってネットワークサービスを認証および認可するためのシステムが提供され、このシステムは、ネットワークアクセスタイプおよび拡張認証プロトコルサポートを示すルータ通知を発行するためのルータと、前記ルータ通知を受けてネットワークアクセスタイプを判定し、クライアントタイプ、ユーザＩＤおよびコアアドレス情報を備えたクライアント識別子オプションメッセージおよびＥＡＰ（拡張認証プロトコル）識別子オプションメッセージを含む開始メッセージを作成し、さらに前記ルータ通知内において識別されるアクセスネットワークと互換性がある、例えばＵＤＰ、ＩＣＭＰｖ６（インターネットコントロールメッセージプロトコルバージョン６（ＩＰｖ６用））等のＩＰｖ４またはＩＰｖ６プロトコル、もしくはＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、または適合するブルートゥースプロファイル等のリンク層プロトコルに前記開始メッセージをカプセル化するモバイル機器と、カプセル化されたメッセージを前記モバイル機器から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するためのアクセスコントローラとを備える。
【００２８】
数種の認証機構が使用されてもよい。以下の好適な実施形態の説明において、ＵＳＩＭ（汎用加入者識別モジュール）を使用するＥＡＰ‐ＡＫＡ（認証とキー合致）認証機構（第一の実施形態）およびＣＡＶＥ（携帯電話認証および音声暗号化）アルゴリズムを適用するＲ‐ＵＩＭ（リムーバブルユーザ識別モジュール）を使用する認証機構（第二の実施形態）が例として挙げられる。
【００２９】
第一の実施形態は、ＣＤＭＡ２０００携帯電話および携帯電話以外のパケットデータネットワークの併用に関し、特にユーザ認証およびＥＡＰ‐ＡＫＡ仕様を複数タイプのアクセスネットワークにわたって通信する際に汎用加入者識別モジュール（ＵＳＩＭ）を使用するサービスの認可に関する。この性能は、他の携帯電話環境における同様の方法と同じ方式で、ノンデータ認証のためのキーインフラストラクチャを活用するキー管理を自動化するのに有効である。ユーザ認証およびサービス認可を行うことにより、携帯電話オペレータはユーザに様々なアクセスネットワークタイプを提供すると同時に、統一サービスプロビジョニング、ユーザ基準のネットワークアクセス管理およびローミング認可を維持し、現存する認可／アカウンティング／請求インフラストラクチャからこれらすべてを活用することができる。要約すると、利点は複数のアクセス方法に使用するスマートカードベースのＣＤＭＡ２０００認証の統合であるといえる。
【００３０】
この実施形態は、ＷＬＡＮ／ＣＤＭＡ２０００ユーザのためのネットワークアクセス、モビリティシ・グナリング、およびその他のサービス認可を説明する。特に、第一の実施形態によると、モビリティ・マネジメント・シグナリング保護と同様に、ＷＬＡＮからのネットワーク認可がＡＡＡｖ６（Ｉｐｖ６用認証、認可およびアカウンティング）、ＥＡＰ‐ＡＫＡ（拡張認証プロトコル認証とキー合致）、および、提示されている方法のためのＣＤＭＡ２０００仕様の多元接続アーキテクチャと同様に、ＲＡＤＩＵＳプロトコルを使用する多元接続スキームが提供される。
【００３１】
上述したように、第一の実施形態によると、解決すべき問題は、ＣＤＭＡ２０００携帯電話ネットワークを使用していない場合、端末はオペレータのネットワークでそれ自体を認証しサービスを受けるために、いくつかの別の方法を使用しなければならないということである。本実施形態によると、この問題は、以下に詳しく説明するように、ユーザがユーザＩＤを保持するＵＳＩＭを有する限り、任意のアクセス技術およびコア技術を実行するために、ＥＡＰ‐ＡＫＡ仕様を使用してユーザを認証する方法を定義することにより克服される。
【００３２】
第一の実施形態によると、ＥＡＰ‐ＡＫＡ認証機構（例えば、J.Arkko・H.Haverinen著、EAP AKA Authentication（作業中）、インターネットドラフト（draft-arkko-pppext-eap-aka-10.txt）、インターネットエンジニアリングタスクフォース（２００３年６月）で定義されているようなもの）は、任意のネットワークアクセス技術を使用するネットワークに対しユーザを認証するために適用される。従って、端末、ＵＳＩＭ（汎用加入者識別モジュール）、アクセスコントローラ、認証ゲートウェイ、およびＣＤＭＡ２０００ネットワークの認証センター（ＡｕＣ／ＨＬＲ（ホームロケーションレジスタ、ＡｕＣはＨＬＲ内に位置する））のエンティティを伴う（がこれらに限定されない）多方面増加インターアクションによる相互認証、ネットワーク認可、およびサービスプロビジョニングが実現する。以下、これがどのようにして実現し得るのか、詳しく説明する。
【００３３】
図１は、ＣＤＭＡ２０００マルチアクセスネットワーク参照モデルを示し、これにはアクセスコントローラ（ＡＣ）および認証サーバ（ＡＳ）も提供される。
【００３４】
図１の左上部分に、訪問アクセスプロバイダネットワーク（特に、サービングネットワーク）が示されている。ソース無線ネットワーク（ＲＮ）はＲＡＮ‐ＰＤＳＮインターフェイス（Ｒ‐Ｐインターフェイス）を経由しサービングＰＤＳＮに接続されている。Ａ１０およびＡ１１は、ＣＤＭＡ２０００において定義される制御メッセージのためのインターフェイスである。ＰＤＳＮ（パケットデータサービングネットワーク）はフォーリンエージェントとしての役割を果たし、インターネット、イントラネットおよびワイヤレスアプリケーションプロトコル（ＷＡＰ）へのアクセスを移動局等に提供する。ソースＲＮは、インターフェイスＡ１を経由し移動通信交換局（ＭＳＣ）にも接続されている。
【００３５】
ＭＳＣはＳＳ７ネットワークを経由し移動局のホームアクセスプロバイダネットワークに接続されている。ホームアクセスプロバイダネットワークは、ホームロケーションレジスタ（ＨＬＲ）および認証センター（ＡｕＣ）を備え、以下に説明する実施形態によるとこれは必要なものである。
【００３６】
図１の左中部分に、ターゲットの訪問アクセスプロバイダネットワークが示されており、これに移動局が接続されてもよい。ターゲット訪問アクセスプロバイダネットワークは、ターゲットＲＮおよびターゲットＰＤＳＮを備え、これらはＲ‐Ｐインターフェイスによってサービング訪問アクセスプロバイダネットワーク内と同様に接続されている。双方のＰＤＳＮは、ＩＰネットワーク（インターネットプロトコルバージョン４（Ｉｐｖ４）および／またはインターネットプロトコルバージョン６（Ｉｐｖ６））にも接続されている。この接続のために、ＣＤＭＡ２０００においてインターフェイスＰｉが定義されている。サービングＰＤＳＮは、ＡＡＡＬ（ローカルＡＡＡ（認証、認可およびアカウンティング））サーバにも接続されており、このサーバはＩＰネットワークにもアクセスできる。
【００３７】
図１の右側に、上述したホームアクセスプロバイダネットワーク、ＩＰネットワークに接続されＡＡＡＨ（ホームＡＡＡ）を備えるホームＩＰネットワーク、およびＡＡＡサーバを備えるブローカーネットワークが示されている。さらに、ホームエージェント（ＨＡ）が図解されており、これはホームＩＰネットワーク、プライベートネットワーク、またはホームアクセスプロバイダネットワーク内に配置されてもよい。
【００３８】
移動局に対する追加のアクセスの可能性が図１の左下部分に示されており、ここで追加のターゲット訪問アクセスプロバイダネットワークが図解されている。これは以下に説明する実施形態のシナリオである。ここで移動局は、ターゲットＷＬＡＮ（ワイヤレスローカルエリアネットワーク）に接続されている。ＷＬＡＮは、ＩＰインターフェイスを経由して、後に詳細を説明するアクセスコントローラ（ＡＣ）に接続されている。ＡＣは、アクセスサーバ（ＡＳ）に接続されており、これがＩＰネットワークおよびホームアクセスプロバイダネットワーク、特にホームアクセスプロバイダネットワークのＡｕＣへの接続を提供する。
【００３９】
以下に説明する実施形態に記載の新しい機能性（すなわち、新しい機能性を備えた機器）は、斜線で塗りつぶしたボックスで示されている。換言すれば、これらの新しい機能性はＡＣおよびＡＳにあるということである。さらに、任意でホームＩＰネットワークのＡＡＡＨ内にＡＳが提供されてもよい。
【００４０】
端末は、携帯電話ネットワークおよびＯＷＬＡＮ（オペレータワイヤレスＬＡＮ）アクセスネットワークの一部であるＩＰネットワークを含む、あらゆる種類のＩＰネットワークにアクセス可能である必要がある機器である。端末は、ＵＳＩＭを有することにより、ＡＫＡアルゴリズムを実行できることも必要である。また、ＩＰｖ６プロトコルを実行する必要もある。ＭＩＰｖ６が使用される場合、このプロセスは、ホームエージェントと端末の間のセキュリティアソシエーションを動的に作成するために利用されることもできる。ＥＡＰ‐ＡＫＡ仕様は、ＡＫＡ認証がＥＡＰメッセージを使用してどのように実行されるかを示す。この実施形態に従って、この仕様がアクセス技術にかかわらず、どのように認証に使用されることができるかを説明する。
【００４１】
端末がこの機能性を実行できるネットワークに入る際、例えばルータまたはエージェント通知オプション等、サポートの指示を含むルータ通知（ＲＡ）を、このタイプのＡＡＡ（認証、認可およびアカウンティング）サポートを示すローカルＡＣ（アクセスコントローラ）から受信する。これは、本実施形態に従って認証、キー生成、およびサービスプロビジョニングを指示する。
【００４２】
ＥＡＰメッセージは、端末とユーザのＩＰネットワークへのアクセス制御に関与するネットワーク要素であるアクセスコントローラとの間で交換される際に、ＡＡＡｖ６メッセージまたはＷＬＡＮリンク層（ＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、適合するブルートゥースプロファイルメッセージ、ＰＰＰ ＥＡＰカプセル化、または任意の適合するｌａｓｔ−ｈｏｐ ＰＡＮＡプロトコルメッセージ等において、将来標準化されるとして）のいずれかにおいてカプセル化される。ＡＡＡｖ６が使用される場合、初期のＥＡＰ／ＡＫＡ ＩＤメッセージは、ＡＡＡｖ６メッセージ内のＥＡＰ ＩＤオプションに加わる。
【００４３】
アクセスコントローラと認証サーバの間で、ＥＡＰメッセージがＤｉａｍｅｔｅｒまたはＲａｄｉｕｓのようなコアネットワークプロトコルに運ばれる。ＡＣは、それをＩＭＳＩ（国際移動電話加入者識別番号）およびアドレス体系から割り当てることにより認証サーバのＩＰアドレスを決定する。認証サーバは、ＭＳＣを経由しＨＬＲ／認証センター（ＡｕＣ）に達する論理インターフェイスを有する。これは、ＭＡＰプロトコル（ＳＳ７ネットワーク）とＩＰで使用される認証プロトコルの間のゲートウェイとしての役割を果たす。
【００４４】
以下、本実施形態に従ってＯＷＬＡＮネットワークにおいてユーザを認証するためのシナリオを、メッセージフローを用いて説明する。
【００４５】
１．端末がアクセス要求メッセージ（ＡＡＡｖ６リクエストメッセージまたはネットワークアクセスを要求するその他任意のメッセージであってもよい）をアクセスコントローラに送信する。このメッセージにはＥＡＰ応答／ＡＫＡ ＩＤメッセージが組み込まれている。また、このメッセージ内にはユーザＮＡＩを回送するための供給も必要である。
【００４６】
２．アクセスコントローラが、コアネットワークにおいて認証サーバ（ＡＳ）に送信されたＥＡＰメッセージをフェッチし、それを要求メッセージ（Ｄｉａｍｅｔｅｒ ＡＡ要求メッセージまたはＲａｄｉｕｓアクセス要求メッセージであってもよい）に入れる。例えば、ＤｉａｍｅｔｅｒにおいてＥＡＰメッセージはＥＡＰペイロードＡＶＰにあるであろう。アクセスコントローラは、ユーザＮＡＩのアドレス体系部分に基づいて、要求がどのＡＳに行くべきかを割り出す。
【００４７】
３．メッセージを受信すると、ＡＳは、第一に、ユーザのための認証情報を有するＡｕＣを識別する。これは、ユーザＮＡＩのユーザ部分に基づいていてもよい。例えば、使用されるユーザＮＡＩがＩＭＳＩ＠アドレスの体系の形をとる場合、ＩＭＳＩは、ユーザＨＬＲ／ＡｕＣを識別するために使用されることができる。ＡＳは、ＡｕＣからＵＭＴＳ認証クインテットを要求する。このクインテットは、５つの値、すなわち、ａ）ネットワークチャレンジＲＡＮＤ、ｂ）予測されるユーザ応答ＸＲＥＳ、ｃ）暗号解読キーＣＫ、ｄ）完全性キーＩＫ、および、ｅ）ネットワーク認証トークンＡＵＴＮから成る。ＡＳは、これらの値を得ると、ＡＴ＿ＲＡＮＤ属性（乱数）、ＡＴ＿ＡＵＴＮ（認可ベクトル）、およびＡＴ＿ＭＡＣ（メッセージ認証コード）を作成する。後の使用のために、ＡＳは、値ＡＴ＿ＲＥＳを計算し格納する。ＡＳは、ＡＴ＿ＲＡＮＤ値・ＡＴ＿ＡＵＴＮ値・およびＡＴ＿ＭＡＣ値を含むＥＡＰ要求／ＡＫＡ／チャレンジメッセージを作成する。最後にＡＳは、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージをその中に含むメッセージおよびユーザを（ユーザ名属性において）識別するＮＡＩをＡＣへ送信する。メッセージはＤｉａｍｅｔｅｒ ＡＡ回答メッセージまたはＲａｄｉｕｓアクセスチャレンジメッセージであってもよい。Ｄｉａｍｅｔｅｒメッセージである場合、ＥＡＰメッセージはＥＡＰペイロードＡＶＰに運ばれる。
【００４８】
４．ＡＣが、ＥＡＰ要求／ＡＫＡ／チャレンジを含む端末に、メッセージを送信する。これは、ＡＡＡｖ６メッセージまたは端末とアクセスコントローラとの間で使用する、その他任意のネットワークアクセスプロトコルであってよい。
【００４９】
５．端末はこのメッセージを受信すると、第一に、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージを抽出する。次いでＡＫＡを使用してＡＴ＿ＲＥＳ値を計算し、ＥＡＰ要求／ＡＫＡ／チャレンジ内でＡＫＡに対するインプットとして受信したＡＴ＿ＲＡＮＤ値およびＡＴ＿ＭＡＣ値を得る。また端末は、ＡＴ＿ＡＵＴＮ値を計算し、それをＥＡＰ要求／ＡＫＡ／チャレンジにおいて受信したＡＴ＿ＡＵＴＮと比較する。これらの値が一致した場合、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージは認証に成功し、そうでない場合、このメッセージの認証は失敗する。値が一致していた場合、端末は、メッセージ（ＡＡＡｖ６）を作成し、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージを含むＡＣへ送信する。ＥＡＰ要求／ＡＫＡ／チャレンジメッセージは、計算されたＡＴ＿ＲＥＳ値を含む。
【００５０】
６．ＡＣは、再度要求メッセージを送信する（Ｄｉａｍｅｔｅｒ ＡＡ要求／Ｒａｄｉｕｓアクセス要求）。このときメッセージは、ＥＡＰ要求／ＡＫＡ／チャレンジを含む。
【００５１】
７．ＡＳはこのメッセージを受信すると、先に計算しておいたＡＴ＿ＲＥＳ値を受信したＥＡＰメッセージ内のＡＴ＿ＲＥＳ値と比較する。値が一致する場合、ＡＫＡ認証は成功し、そうでない場合、認証は失敗する。結果に応じて、アクセス認可またはアクセス拒否メッセージのいずれかを送信する（Ｒａｄｉｕｓの場合）。Ｄｉａｍｅｔｅｒであれば、結果コードＡＶＰ内の結果とともにＡＡ回答メッセージを送信する。
【００５２】
８．このメッセージを受けて、ＡＣは、認証が成功したか否かを知る。ＡＣは適切な応答メッセージを端末に送信する。端末がこのメッセージを受信すると、ＯＷＬＡＮアクセスネットワーク認証は完了する。認証が成功した場合、ＡＣは、認証された端末から送信されたパケットを通過させることを認可するフィルタリングルールを適用しなければならない。
【００５３】
次に、図２Ａおよび２Ｂに示すシグナルフロー図を参照し、上述の手順をもう少し詳しく説明する。シグナルフロー図は、端末（端末機すなわちＵＥ）、認証センター（ＡＣ）および認証サーバ（ＡＳ）の間で交換される信号を図解したものである。
【００５４】
ステップ２‐Ａにおいて、端末は、ＡＣからルータ通知（非請求または応答型）を受信する。ルータ通知（ＲＡ）は、ローカルチャレンジを含むＡＡＡチャレンジオプションを含む。メッセージを送信する前に、端末は割り当てられたＩＰアドレスを取得していなければならない（例えばＤＨＣＰ（動的ホスト構成プロトコル）サーバからのＩＰｖ４の場合。ＩＰｖ６アドレスの場合、自動構成アドレスであってもよい）。
【００５５】
ステップ２‐Ｂにおいて、端末は、ルータ通知におけるＡＡＡフラグの存在により、ＡＡＡアクセス認証を実行する必要があることを推論する。端末は、ＡＡＡ要求メッセージを（ＲＱ１に指示されて）ＡＣへ送信することにより、認証シーケンスを開始する。ＡＡＡ要求は、ＥＡＰ ＩＤメッセージを運ぶオプションと同様に、ＡＡＡクライアント識別子オプション（シグナルフロー図ではｃＩＤとして示される）を含む。ＡＡＡクライアント識別子オプションおよびＥＡＰ ＩＤメッセージは双方ともユーザのＮＡＩ（ＩＭＳＩ＠アドレス体系）を含む。
【００５６】
ステップ２‐Ｃにおいて、ＡＣは、ＡＡＡクライアント識別子オプションに含まれるＮＡＩからＡＳのアドレスを（必要な場合はＤＮＳを使用して）導出し、ＡＡＡ要求メッセージ（ＡＲ）をＡＳに送信する。ＡＲは、ステップＢのＡＡＡクライアント識別子オプション内で受信したＥＡＰ ＩＤメッセージ（ＥＡＰペイロード属性において）およびＮＡＩ（ユーザ名属性において）を含む。
【００５７】
ステップ２‐Ｄにおいて、ＡＳは、ステップ２‐ＣにおけるＡＲメッセージを受けて、以下を実行する。
・ ＮＡＩのＩＭＳＩ部分に基づき、ＡＳは、ユーザのための認証情報を有するＡｕＣを識別する。
・ ＵＭＴＳ認証クインテットを要求し、ＡｕＣから得る。このクインテットは、５つの値、すなわち、ａ）ネットワークチャレンジＲＡＮＤ、ｂ）予測されるユーザ応答ＸＲＥＳ、ｃ）暗号解読キーＣＫ、ｄ）完全性キーＩＫ、およびｅ）ネットワーク認証トークンＡＵＴＮから成る。
・ ＡＴ＿ＲＡＮＤ属性（乱数）、ＡＴ＿ＡＵＴＮ（認可ベクトル）、およびＡＴ＿ＭＡＣ（メッセージ認証コード）を計算する。
・ 後の使用のために、値ＡＴ＿ＲＥＳを計算し格納する（ＸＲＥＳから導出）。
・ ＡＴ＿ＲＡＮＤ値、ＡＴ＿ＡＵＴＮ値、およびＡＴ＿ＭＡＣ値を含む、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージを作成する。
・ ＥＡＰ要求／ＡＫＡ／チャレンジ（３ＧＰＰ２におけるベンダー固有属性）およびユーザを（ユーザ名属性において）識別するＮＡＩを含む、アクセスチャレンジ（ＡＡ）メッセージをＡＣへ送信する。
【００５８】
ステップ２‐Ｅにおいて、ＡＣは、ＡＡＡｖ６組み込みデータオプション、ＮＡＩを含むＡＡＡクライアント識別子オプション、およびＡＡＡｖ６チャレンジオプション内にＥＡＰ要求（シグナルフロー図ではＥＲｐ）／ＡＫＡ／チャレンジを含むＡＡＡ応答メッセージ（ＲＰ２）を端末へ送信する。ＡＡＡｖ６チャレンジオプションは、ＡＣにより設定されたローカルチャレンジ値を含む。
【００５９】
ステップ２‐Ｆにおいて、端末は、ステップ２‐ＥにおけるＡＡＡ応答を受けて、以下を実行する。
・ ＡＫＡを使用してＡＴ＿ＲＥＳ値を計算し、ＥＡＰ要求／ＡＫＡ／チャレンジ内でＡＫＡに対するインプットとして受信したＡＴ＿ＲＡＮＤ値およびＡＴ＿ＭＡＣ値を得る。
・ ＡＫＡにおいて指定されたように値ＡＴ＿ＡＵＴＮを計算する。
・ 計算したＡＴ＿ＡＵＴＮ値を、ＥＡＰ要求／ＡＫＡ／チャレンジにおいて受信した値と比較する。値が一致した場合、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージは認証に成功し、そうでない場合、このメッセージの認証は失敗する。
・ ＡＡＡ要求メッセージ（ＲＱ３）を、ＡＣへ送信する。ＡＡＡ要求メッセージ（ＲＱ３）は、ＡＡＡｖ６チャレンジオプション内にローカルチャレンジと、ＡＡＡクライアント識別子オプション（ＩＭＳＩ＠アドレス体系の形のＮＡＩ）と、ＡＡＡｖ６組み込みデータオプション内にＥＡＰ応答（ＥＲ）／ＡＫＡ／チャレンジメッセージとを含む。ＥＡＰ応答／ＡＫＡ／チャレンジは、計算されたＡＴ＿ＲＥＳ値を含む。
【００６０】
ステップ２‐Ｇにおいて、ＡＣは、ＡＡＡ要求（ＡＲ）メッセージをＡＳ（ＮＡＩにより識別される）へ送信する。ＡＲメッセージは、ＡＡＡ要求のＡＡＡクライアント識別子オプションにおいて受信したＥＡＰ要求／ＡＫＡ／チャレンジ（３ＧＰＰ２におけるベンダー固有属性）およびＮＡＩを（ユーザ名属性において）含む。
【００６１】
ステップ２‐Ｈにおいて、ＡＳはステップ２‐ＧにおけるＡＲメッセージを受けて、以下を実行する。
・ ステップＤにおいて計算されたＡＴ＿ＲＥＳ値を、ＥＡＰ応答／ＡＫＡ／チャレンジに含まれるＡＴ＿ＲＥＳ値と比較する。値が一致する場合、ＡＫＡ認証は成功であり、そうでない場合、認証は失敗する。
・ 認証が成功の場合、ユーザを（ユーザ名属性において）識別するＮＡＩを含むＡＡメッセージをＡＣへ送信する。認証が失敗した場合、アクセス拒否メッセージをＡＣへ送信する。
【００６２】
ステップ２‐Ｉにおいて、ＡＣは、ステップ２‐ＨにおけるＡＡメッセージを受けて、ＡＫＡ認証が成功したことを知る。ＡＣはＡＡＡ応答メッセージ（図２ＡにおいてＲＰ３により示される）をＳＵＣＣＥＳＳ（値０）を示すように設定されたコードフィールドとともに端末へ送信する。端末がこのメッセージを受信すると、ＯＷＬＡＮアクセスネットワーク認証は完了する。
【００６３】
認証が成功した場合、ＡＣは、認証された端末から送信されたパケットを通過させることを認可するフィルタリングルールを適用しなければならない。
【００６４】
以下、第一の実施形態に記載のモビリティバインディングのために、どのようにして汎用の認証確立が行われるかを説明する。
【００６５】
１．シーケンスが、要求メッセージ（ＡＡＡｖ６、ＷＬＡＮリンク層またはその他任意のネットワークアクセスプロトコル）をホームエージェント（ＨＡ）へ送信する端末から開始する。要求は、組み込みＥＡＰ応答／ＡＫＡ／ＩＤメッセージと同様にユーザ（ＩＭＳＩ＠アドレス体系）のＮＡＩを含む。
【００６６】
２．ＨＡが、ＥＡＰメッセージを取りに行き、それをコアネットワークにおいて認証サーバ（ＡＳ）に送信された要求メッセージ（Ｄｉａｍｅｔｅｒ ＡＡＡ要求メッセージまたはＲａｄｉｕｓアクセス要求メッセージであってもよい）に入れる。例えば、Ｄｉａｍｅｔｅｒにおいて、ＥＡＰメッセージはＥＡＰペイロードＡＶＰにあるであろう。ＮＡＩのアドレス体系部分はＡＳが存在するドメインを示すため、ＨＡは、ユーザＮＡＩのアドレス体系部分に基づいて、要求がどのＡＳに行くべきかを割り出す。
【００６７】
３．メッセージを受信すると、ＡＳは、第一にユーザのための認証情報を有するＡｕＣを識別する。これは、ユーザＮＡＩのユーザ部分に基づいていてもよい。例えば、使用されるユーザＮＡＩがＩＭＳＩ＠アドレス体系の形をとる場合、ＩＭＳＩは、ユーザＨＬＲ／ＡｕＣを識別するために使用されることができる。ＩＭＳＩは、ＡｕＣからＵＭＴＳ認証クインテットを要求する。このクインテットは、５つの値、すなわち、ａ）ネットワークチャレンジＲＡＮＤ、ｂ）予測されるユーザ応答ＸＲＥＳ、ｃ）暗号解読キーＣＫ、ｄ）完全性キーＩＫ、および、ｅ）ネットワーク認証トークンＡＵＴＮから成る。これらの値を得ると、ＡＳは、ＡＴ＿ＲＡＮＤ属性（乱数）、ＡＴ＿ＡＵＴＮ（認可ベクトル）、およびＡＴ＿ＭＡＣ（メッセージ認証コード）を作成する。後の使用のために、値ＡＴ＿ＲＥＳおよびセッションキーＫを計算し格納する。ＡＴ＿ＲＡＮＤ値、ＡＴ＿ＡＵＴＮ値およびＡＴ＿ＭＡＣ値を含むＥＡＰ要求／ＡＫＡ／チャレンジメッセージを作成する。最後にＡＳは、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージをその中に含むメッセージおよびユーザを（ユーザ名属性において）識別するＮＡＩを、ＨＡへ送信する。メッセージはＤｉａｍｅｔｅｒ ＡＡ回答メッセージまたはＲａｄｉｕｓアクセスチャレンジメッセージであってもよい。Ｄｉａｍｅｔｅｒメッセージである場合、ＥＡＰメッセージはＥＡＰペイロードＡＶＰに運ばれる。
【００６８】
４．ＨＡが、メッセージをＥＡＰ要求／ＡＫＡ／チャレンジを含む端末に送信する。これは、ＡＡＡｖ６メッセージまたは端末とアクセスコントローラとの間で使用する、その他任意のネットワークアクセスプロトコルであってよい。
【００６９】
５．端末は、このメッセージを受信すると、まずＥＡＰ要求／ＡＫＡ／チャレンジメッセージを抽出する。次いでＡＫＡを使用してＡＴ＿ＲＥＳ値を計算し、ＥＡＰ要求／ＡＫＡ／チャレンジ内でＡＫＡに対するインプットとして受信した、ＡＴ＿ＲＡＮＤ値およびＡＴ＿ＭＡＣ値を得る。次いで値Ｋを計算する。またＡＴ＿ＡＵＴＮ値を計算し、それをＥＡＰ要求／ＡＫＡ／チャレンジにおいて受信したＡＴ＿ＡＵＴＮと比較する。これらの値が一致した場合、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージは認証に成功し、そうでない場合、このメッセージの認証は失敗する。値が一致していた場合、端末はメッセージ（ＡＡＡｖ６）を作成し、ＥＡＰ応答／ＡＫＡ／チャレンジメッセージを含むＨＡへ送信する。ＥＡＰ応答／ＡＫＡ／チャレンジメッセージは計算されたＡＴ＿ＲＥＳ値を含む。端末は、今後のセキュリティアソシエーション（ＳＡ）に使用するため、値ＫをＨＡとともに格納する。
【００７０】
６．ＨＡは再度要求メッセージを送信する（Ｄｉａｍｅｔｅｒ ＡＡ要求／Ｒａｄｉｕｓアクセス要求）。このときメッセージはＥＡＰ応答／ＡＫＡ／チャレンジを含む。
【００７１】
７．ＡＳは、このメッセージを受信すると、先に計算しておいたＡＴ＿ＲＥＳ値を受信したＥＡＰメッセージ内のＡＴ＿ＲＥＳ値と比較する。値が一致する場合、ＡＫＡ認証は成功し、そうでない場合、認証は失敗する。結果に応じて、アクセス認可またはアクセス拒否メッセージのいずれかを送信する（Ｒａｄｉｕｓの場合）。Ｄｉａｍｅｔｅｒであれば、結果コードＡＶＰ内の結果とともにＡＡ回答メッセージを送信する。また、ＢＵ認証キーを搬送するのに必要なため、鍵配送ＡＶＰをＨＡおよびＢＵ認証キーの関連存続期間を有する認可存続期間ＡＶＰへ送信する。
【００７２】
８．このメッセージを受けて、ＨＡは認証が成功したか否かを知る。ＨＡは、対応付け更新（Ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）を認証する目的で、端末を使用しセキュリティアソシエーションを作成する。認証キーＫをこのＳＡに関連付け、メッセージ内において受信された際にその存続期間を初期化する。ＨＡは、適切な応答メッセージを端末に送信する。端末がこのメッセージを受信すると、ＢＵ認証キー確立は完了する。
【００７３】
以下、図３Ａおよび３Ｂに示すシグナルフロー図を参照し、上述の手順をもう少し詳しく説明する。
【００７４】
ステップ３‐Ａにおいて、端末は、そのＨＡがＡＫＡ認証を実行できるという知識を自動的に受信する。以下のメッセージを送信する前に、端末は割り当てられたＩＰｖ４アドレスを、例えばＤＨＣＰを使用して取得していなければならない。
【００７５】
ステップ３‐Ｂにおいて、端末はそのホームネットワークによるその静的知識により、結合認証を実行する必要があることを推論する。端末は、ＡＡＡ要求メッセージを（図３ＡのＲＱ１に指示されて）ＨＡへ送信することにより認証シーケンスを開始する。ＡＡＡ要求は、ＥＡＰ応答およびＥＡＰ ＩＤメッセージ（ＥＲｓ／ＥＡＰ ＩＤ）を運ぶオプションと同様にＡＡＡクライアント識別子オプション（ｃＩＤ）を含む。ＡＡＡクライアント識別子オプションおよびＥＡＰ ＩＤメッセージは双方ともユーザのＮＡＩ（ＩＭＳＩ＠アドレス体系）を含む。
【００７６】
ステップ３‐Ｃにおいて、ＨＡは、ＡＡＡクライアント識別子オプションに含まれるＮＡＩからＡＳのアドレスを（必要な場合はダイナミックネームサーバ（ＤＮＳ）を使用して）導出し、ＡＡＡ要求メッセージ（ＡＲ）をＡＳに送信する。ＡＲは、ステップＢのＡＡＡクライアント識別子オプション内で受信したＥＡＰ ＩＤメッセージ（ＥＡＰペイロード属性において）およびＮＡＩ（ユーザ名属性において）を含む。
【００７７】
ステップ３‐Ｄにおいて、ＡＳは、ステップ３‐ＢにおけるＡＲメッセージを受けて、以下を実行する。
・ ＥＡＰ応答／ＩＤの理由フィールドから、この手順で確立されたセッションキーがクライアントアテンダント認証に使用されることを認識する（そのため、後にキーをアテンダントとしての役割を果たすもの以外のＨＡに送信する必要がない）。
・ ＮＡＩのＩＭＳＩ部分に基づき、ユーザのための認証情報を有するＡｕＣを識別する。
・ ＵＭＴＳ認証クインテットを要求し、ＡｕＣから得る。
・ ＡＴ＿ＲＡＮＤ属性（乱数）、ＡＴ＿ＡＵＴＮ（認可ベクトル）、およびＡＴ＿ＭＡＣ（メッセージ認証コード）を計算する。
・ 後の使用のために、値ＡＴ＿ＲＥＳおよびＫを計算し格納する。
・ ＡＴ＿ＲＡＮＤ値、ＡＴ＿ＡＵＴＮ値、およびＡＴ＿ＭＡＣ値を含む、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージを作成する。
・ ＥＡＰ要求／ＡＫＡ／チャレンジ（３ＧＰＰ２におけるベンダー固有属性）およびユーザを（ユーザ名属性において）識別するＮＡＩを含むアクセスチャレンジ（ＡＣ）メッセージを、ＨＡへ送信する。
【００７８】
ステップ３‐Ｅにおいて、ＨＡは、ＡＡＡｖ６組み込みデータオプション、ＮＡＩを含むＡＡＡクライアント識別子オプション、およびＡＡＡｖ６チャレンジオプション内にＥＡＰ要求／ＡＫＡ／チャレンジを含むＡＡＡ応答メッセージ（図ではＲＰ２で示される）を端末へ送信する。ＡＡＡクライアント識別子オプションはユーザを識別するＮＡＩを、ＡＡＡｖ６チャレンジオプションはＨＡにより設定されたローカルチャレンジ値を含む。
【００７９】
ステップ３‐Ｆにおいて、端末は、ステップ３‐ＥにおけるＡＡＡ応答を受けて、以下を実行する。
・ ＡＫＡを使用してＡＴ＿ＲＥＳ値およびＫ値を計算し、ＥＡＰ要求／ＡＫＡ／チャレンジ内で、ＡＫＡに対するインプットとして受信したＡＴ＿ＲＡＮＤ値を得る。
・ 計算したＡＴ＿ＡＵＴＮ値を、ＥＡＰ要求／ＡＫＡ／チャレンジにおいて受信した値と比較する。値が一致した場合、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージは認証に成功し、そうでない場合、このメッセージの認証は失敗する。
・ セキュリティアソシエーションに使用するため、キーＫをＨＡとともに格納する。
・ 更新の必要がある際に推論できるよう、セキュリティアソシエーションの存続期間をＨＡとともに格納する。
・ ＡＡＡｖ６チャレンジオプションにローカルチャレンジを含み、ＡＡＡｖ６組み込みデータオプションにＡＡＡクライアント識別子オプション（ＩＭＳＩ＠アドレス体系の形のＮＡＩ）およびＥＡＰ応答（ＥＲ）／ＡＫＡ／チャレンジメッセージを含む、ＡＡＡ要求メッセージ（ＲＱ３）をＨＡへ送信する。ＥＡＰ応答／ＡＫＡ／チャレンジは、計算されたＳＲＥＳ値を含む。
【００８０】
ステップ３‐Ｇにおいて、ＨＡは、ＡＲメッセージを（ＮＡＩにより識別された）ＡＳへ送信する。ＡＲメッセージは、ＡＡＡ要求のＡＡＡクライアント識別子オプションにおいて受信したＥＡＰ応答／ＡＫＡ／チャレンジ（３ＧＰＰ２におけるベンダー固有属性）およびＮＡＩを（ユーザ名属性において）を含む。
【００８１】
ステップ３‐Ｈにおいて、ＡＳはステップ３‐ＦにおけるＡＲメッセージを受けて、以下を実行する。
・ ステップ３‐Ｃにおいて計算されたＡＴ＿ＲＥＳ値を、ＥＡＰ応答／ＡＫＡ／チャレンジに含まれるＡＴ＿ＲＥＳ値と比較する。値が一致する場合、ＡＫＡ認証は成功であり、そうでない場合、認証は失敗する。
・ ＡＡメッセージをＨＡへ送信する。ＡＡメッセージは、ベンダー固有属性におけるＢＵ認証キーと、ユーザ名属性においてユーザを識別するＮＡＩと、および別のベンダー固有属性におけるＢＵ認証キー存続期間とを含む。キー存続期間フィールドは、ＡＳによって例えば値２５９２００（３日間）に設定される。
【００８２】
ステップ３‐Ｉにおいて、ＨＡは、端末とともに対応付け更新を認証するためにセキュリティアソシエーションを作成または更新し、キーＫを認証キーとしてそれに関連付け、キー存続期間属性において受信した値に従ってＳＡの存続期間を初期化する。次いでＨＡは、ＡＡＡ汎用キー応答オプションおよびＳＵＣＣＥＳＳ（値０）を示すよう設定されたコードフィールドを含むＡＡＡ応答メッセージ（ＲＰ３）を、端末に送信する。ＡＡＡ汎用キー応答オプションはキーＫを含まないが、存続期間フィールドはキー存続期間属性において受信した値に設定され、キーＳＰＩフィールドの値はＨＡと端末の間のセキュリティアソシエーションを示すように設定される。端末がこのメッセージを受信すると、汎用ＢＵ認証キー確立は完了する。
【００８３】
ステップ３‐Ｊにおいて、端末は、Ｍｏｂｉｌｅ ＩＰｖ４アプリケーションに対し、ＢＳＡのものを使用して、キー材料から作成されたように、Ｍｏｂｉｌｅ‐Ｈｏｍｅ認証拡張をＭｏｂｉｌｅ ＩＰｖ４登録要求（ＲＲＥＱ）の中へ形成するだろう。ＨＡは、ＲＲＥＱのメッセージ認証を実行する際、対応するＢＳＡをＭＮ‐ＨＡ認証拡張に対し自動的に適用するであろう。
【００８４】
Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに対しては、ＩＰＳｅｃセキュリティアソシエーションを入力されたＲ‐ＵＩＭが送信パケットに自動的に適用されるよう、端末がＩＰＳｅｃ保護の対応付け更新をＨＡに送信するだろう。ＨＡがパケットを受信すると、そのＩＰＳｅｃモジュールは、ＳＡが着信するモビリティヘッダーパケットにもう適用できることを自動的に知る。このパケットはＭｏｂｉｌｅ ＩＰｖ６ ＨＯＴＩまたは対応付け更新メッセージであってよい。
【００８５】
ステップ３‐Ｋにおいて、ＨＡは、Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに対し、受信したキー材料から作成されるように、Ｍｏｂｉｌｅ‐Ｈｏｍｅ認証拡張を、ＢＳＡのものを使用して、構築されたＭｏｂｉｌｅ ＩＰｖ４登録応答（ＲＲＥＰ）へ適用するだろう。次いで端末は、ＲＲＥＰのメッセージ認証を実行する際、対応するＢＳＡをＭＮ‐ＨＡ認証拡張に対し自動的に適用するであろう。
【００８６】
Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに対しては、ＨＡのＩＰＳｅｃモジュールはＳＡが入力されたＲ−ＵＩＭを使用して送信されたＢＡｃｋメッセージを自動的に保護するであろう。次いで、ＩＰＳｅｃで保護されたＨＡのモビリティヘッダーパケットを受信すると、端末は、自動的にＩＰＳｅｃセキュリティアソシエーションが入力されたＲ‐ＵＩＭを、ステップＮで使用されたものと逆方向に適用する。
【００８７】
これは、モビリティシ・グナリング保護アプリケーションプロトコルのフローをうまく完了させる。Ｍｏｂｉｌｅ ＩＰ／ＩＰｖ６ホーム登録以外のアプリケーションでは、この種の手順を任意のＩＰｓｅｃＳＡを入力するために使用することができる。
【００８８】
以下、本発明の第二の実施形態を説明する。
【００８９】
第一の実施形態と同様に、第二の実施形態は、ＣＤＭＡ２０００携帯電話および携帯電話以外のパケットデータネットワークを併用する領域を対象とし、特にユーザ認証および複数タイプのアクセスネットワークにわたって通信する際に、リムーバブルユーザ識別モジュール（Ｒ−ＵＩＭ）を使用するサービスの認可に関する。現在、携帯電話以外のＩＰネットワーク上でＲ−ＵＩＭ認証を行うためのプロトコルは存在しないが、この機能は、他の携帯電話環境における同様の方法と同じ方式で、ノンデータ認証のための現存するキーインフラストラクチャを活用するキー管理を自動化するのに有効である。ユーザ認証およびサービス認可を行うことにより、携帯電話オペレータは、現存する認可／アカウンティング／請求インフラストラクチャからこれらすべてを活用しながら、ユーザに様々なアクセスネットワークタイプを提供すると同時に、統一されたサービスやユーザ基準のネットワークアクセス管理、およびローミング認可を供給しつづけることができる。利点を要約すると、複数のアクセス方法のためのスマートカードをベースとしたＣＤＭＡ２０００認証の統合であるといえる。
【００９０】
第二の実施形態によると、異なるリンク層のＩＰにおよぶ様々なプロトコルがＲ‐ＵＩＭに基づくマルチアクセス認証および鍵配送機構に結合されている。このシステムは、異なる段階において様々なカプセル化メッセージを使用することにより、端末装置およびオペレータネットワークの双方が、ＩＰに基づく携帯電話以外または携帯電話のパケットデータサービスのためにＣＤＭＡ２０００ ＣＡＶＥ（携帯電話認証および音声暗号化）アルゴリズムを実行することができるよう、ネットワーク要素にデータ交換をさせる。交換されたデータおよびＣＡＶＥアルゴリズムの結果を使用することにより、端末およびアクセスネットワークは、相互に認証し合い、ネットワークアクセス認可またはローミングシグナリング認証のメッセージ保護等、期間限定アプリケーションのためのセキュアキーを導出することができる。ＣＡＶＥアルゴリズムについては、例えば１９９７年の「Ｃｅｌｌｕｌａｒ Ｒａｄｉｏ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｉｎｔｅｒｓｙｓｔｅｍ Ｏｐｅｒａｔｉｏｎｓ」、ＡＮＳＩ−ＴＩＡ／ＥＩＡ−４１においてさらに説明されていることが知られている。
【００９１】
端末は、ＣＤＭＡ２０００、８０２．１１ワイヤレスＬＡＮ、ブルートゥース（登録商標）、またはイーサネット（登録商標）を含む異種ネットワークタイプにおいてｍ、ＩＰに基づいて認証されたセッションを実行することができる。アクセスネットワークは、ポイントツーポイントまたはポイントツーマルチポイントであってよい。
【００９２】
端末は、この方法をＭｏｂｉｌｅ Ｉｐｖ６によって実行してもよいし、モビリティサポートなしにＩＰｖ６アクセスだけによって実行してもよい。
【００９３】
携帯電話以外の場合、本第二の実施形態によると、モバイル装置およびオペレータネットワークが任意のＩＰ利用可能なネットワーク上で互いに通信を行い、安全に証明書を交換し、サービスプロビジョニングを確立するために、使用されるネットワークの基本的特性にかかわらず、同一の方法が提供される。この方法は、説明のとおり、この方法を使用することで、オペレータが各技術を改革する必要はないが、リンク層固有の機構が使用されていないときにこのより一般的な方法を活用できるよう、登録ＩＤを共有することだけにより、現存するＣＤＭＡ２０００方式に関係している。わずかなネットワーク要素を加えることにより、本発明において述べられるように、オペレータは現存するネットワーク要素をほとんど、あるいはまったく変化させずに、それらの現存するＣＤＭＡ２０００サービスインフラストラクチャを活用することができる。
【００９４】
以下、第二の実施形態に記載の手順をもう少し詳しく説明する。
【００９５】
この実施形態は、携帯電話またはその他のモバイル機器（これまで「ＭＥ」または「モバイル装置」と称してきた）を対象とし、これらは通常ワイヤレスリンク上でＩＰに基づく通信機能を有すると共に、Ｒ‐ＵＩＭモジュールを有する。この実施形態は、固定機器の起動時に使用されることもできるが、モバイル機器に使用されるのが最も有効である。この実施形態により、第一の実施形態と同様、ＭＥ・Ｒ‐ＵＩＭ（その内蔵プロセッサ、不揮発性メモリ、およびプライベートデータの長所およびアルゴリズムにより、個別エンティティとみなされる）・アクセスコントローラ・認証ゲートウェイ・およびＣＤＭＡ２０００ネットワークの認証センター（ＡｕＣ／ＨＬＲ（ホームロケーションレジスタ）のエンティティを伴う（がこれらに限定されない）、複数の構成要素が連動することによる相互認証やネットワーク認可、およびサービスプロビジョニングが実現できる。
【００９６】
ＭＥが、ＧＲＡＳＰ（汎用Ｒ‐ＵＩＭ認証およびサービスプロビジョニング、本第二の実施形態に記載されているプロトコル例）機能を使用できるネットワークに入る際、ＭＥは、例えばこのタイプのＡＡＡサポートを示すローカルＡＣからのルータまたはエージェント通知オプション等、ＧＲＡＳＰサポート指示を含むルータ通知を受信する。これは、本発明に記載されているように、認証、キー生成、およびサービスプロビジョニングを開始する。次に、ＭＥが、クライアント識別子オプションおよびＥＡＰ ＩＤオプションを含むＥＡＰ Ｒ‐ＵＩＭ／開始メッセージでＡＣに応答する。いずれのオプションも、ＭＥ起動時に、Ｒ‐ＵＩＭ内のユーザのＩＭＳＩから構成されるユーザＩＤ（ＩＭＳＩ＠アドレス体系）と、Ｒ‐ＵＩＭまたはＭＥの不揮発性メモリ内の予備ファイルに含まれるアドレス体系とを含む。このＩＤ ＥＡＰメッセージは、ＩＰ／ＩＰｖ６においてアクセスリンクＡＡＡメッセージとしてカプセル化される。アクセスリンクＡＡＡメッセージは、将来標準化されるものとして、ＩＰｖ４またはＩＰｖ６それぞれの付録Ａ中の最もよい実施事例に記載されているように、例えばＵＤＰまたはＩＣＭｖ６メッセージ、ＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、または適合するブルートゥースプロファイルメッセージ等のリンク層カプセル化、ＰＰＰ ＥＡＰカプセル化、または任意の適合するｌａｓｔ−ｈｏｐ ＰＡＮＡプロトコルメッセージ内等にあってよい。
【００９７】
ＡＣは、それをＩＭＳＩおよびアドレス体系から割り当てることにより、認証サーバのＩＰアドレスを決定し、例えばＲＡＤＩＵＳまたはＤＩＡＭＥＴＥＲ等その他任意のコアＡＡＡプロトコルを使用して、カプセル化輸送のためにＡＡＡメッセージをＩＰコアに転送する。このメッセージはその後ＡＳに受信され、ＡＳは次いでＡｕＣ／ＨＬＲに連絡する。
【００９８】
ＡＳは、ＳＳ７または音声回路認証を模倣したＡ１メッセージングを使用することにより、直接またはサービングＭＳＣを経由してＡｕＣ／ＨＬＲと通信を行うＡＡＡサーバであってよい。換言すると、ＡＳは、ＡｕＣ／ＨＬＲと通信を行うための機能性を有するということになる。この構造上の選択により、現存するＣＤＭＡネットワークは修正されないままでよく、ＡＳを加える必要があるだけである。これは非侵害的オーバーレイアプローチである。
【００９９】
あるいは、より密接な統合を伴うアプローチは、ＣＤＭＡ２０００ネットワークに変化をもたらすであろう。ＡＳは、ＣＤＭＡ２０００パケットコアネットワーク内の標準に修正されたホームＡＡＡサーバ（ＡＡＡＨ）へ認証を転送する、ＰＤＳＮ内のＡＡＡ（ＲＡＤＩＵＳ）クライアント／ブローカーであってよい。後者は、ＡＡＡＨがＡｕＣ／ＨＬＲと通信を行うための機能性を有することを要求するが、これはＣＤＭＡ２０００パケットコアに対する修正である。後者の構造上の選択は、それらの認証がＰＤＳＮにおけるＰＰＰセッションの終わりに終了し、ＡＡＡＨサーバとのＲＡＤＩＵＳメッセージ交換をもたらすため、現在ＥＡＰ‐ＣＨＡＰまたはＥＡＰ‐ＰＡＰで行われているように、ＰＤＳＮを経由してＲ‐ＵＩＭ認証を本来のＣＤＭＡ２０００パケットデータセッションに使用する可能性を与えるであろう。換言すれば、後者の代替は、携帯電話以外のＲ‐ＵＩＭ認証をＰＤＳＮ経由でまたは直接ホームＡＡＡサーバへ仲介し、または、拡張ＰＤＳＮ ＲＡＤＩＵＳクライアント機能を使用して携帯電話ＰＰＰ‐Ｒ‐ＵＩＭ認証を同じ終点へ転送するであろう。この拡張は、ＥＡＰ‐Ｒ‐ＵＩＭ性能およびＲＡＤＩＵＳメッセージへのマッピングであり、潜在的に上述の方法のための携帯電話以外のＲＡＤＩＵＳメッセージ再利用であろう。
【０１００】
ＡＳは、登録を受信すると、ＡｕＣからの無作為化されたキーイングマテリアル検索をＲＡＮＤまたはＲＡＮＤＵ（実行される認証の大域的または固有の性質による）の形で開始し、この無作為情報を、クライアントＩＤオプションをＡＡＡ回答（ＲＡＤＩＵＳ上で輸送される）内に含むＥＡＰ Ｒ‐ＵＩＭ／チャレンジメッセージの形でチャレンジとしてＭＥに返す。
【０１０１】
ＭＥは、ＡＳから無作為チャレンジ（ＲＡＮＤ）を受信したら、そのものを認証しセッションのための暗号化キーを生成するためのＣＡＶＥアルゴリズムを実行できる状態となる。ＭＥは、ＲｕｎＣａｖｅアルゴリズムを開始させるコマンドをＲ‐ＵＩＭに送信し、必要ならばこのＲ‐ＵＩＭに対し、ＥＳＮ（電話の電子シリアル番号、決定済みおよびＭＥ起動時）・ＲＡＮＤ／ＲＡＮＤＵ・ランドタイプ（固有または大域的、何が供給されるかにより異なる）・およびＰＩＮ番号を提供する。次いでＭＥは、Ｇｅｔ Ｒｅｓｐｏｎｓｅを実行して、Ｒ‐ＵＩＭにアウトプットＡＵＴＨＲまたはＡＵＴＨＵ（大域的または固有のチャレンジ応答）をＭＥへ回送させる。
【０１０２】
ＭＥはチャレンジ応答を受信した後、上述したものと同様のパケットでそれをＡＣへ送信するが、このチャレンジ応答は、ローカルチャレンジ、クライアントＩＤおよびチャレンジ応答マテリアルを含む組み込みデータオプションを伴うＥＡＰ／Ｒ‐ＵＩＭ／開始メッセージである。その後ＡＣは、前のステップでしたように、ＡＳのアドレスを調べ、メッセージをＲＡＤＩＵＳ経由で転送する。ＡＳはメッセージを受け取り、ＩＤサブオプションにおいて受信したＩＭＳＩおよびアドレス体系に基づいてマッピング検索を行うことで、どちらのＡｕＣ／ＨＬＲに連絡するか判断し、ＩＭＳＩ＠アドレス体系に基づいて、その格納されたセッション状態の検索も行う。ＡＳは、ＡｕＣ／ＨＬＲからＣＡＶＥ証明書を検索し、ＣＡＶＥアルゴリズムを実行し、ＭＥから受信した応答をＡｕＣ／ＨＬＲから受信した応答と比較することで、クライアントの信頼性検証を進める。
【０１０３】
ＭＥおよびＡｕＣ／ＨＬＲから受信した応答が等しい場合、ＡＳは、セッションキーおよびサクセスコードを別のＥＡＰメッセージ内のＡＣに送り返す。このＥＡＰメッセージを受けて、ＡＣは、ＭＥへのアクセスを承諾し、セッションキーをセッションの間使用するため保存する。これは、例えばＡＣにおけるコアＡＡＡクライアント機能性によって起こる。ＡＣは、ＭＥにネットワークへのアクセスを承諾するため、ＩＰｓｅｃセキュリティアソシエーションをＭＥによってＡＣ内に入力し、またはファイアウォールルールを作成する。
【０１０４】
次いでＡＣは、前述したようにｌａｓｔ‐ｈｏｐ ＡＡＡプロトコル（例えばＩＣＭｖ６）に組み込み、キーサブオプションを除去して、メッセージをＭＥに送り返す。従って、キーがｌａｓｔ‐ｈｏｐ上に送られることはなく、安全でない可能性があり、ＭＥはＲ‐ＵＩＭにおいてそのＭＥが導出したキーを使用し、ＡＣはＲＡＤＩＵＳを経由してＡＳからキーを送り返す。
【０１０５】
次に、図４Ａおよび４Ｂに示すシグナルフロー図を参照し、上述の手順をもう少し詳しく説明する。図２Ａおよび２Ｂに関連して記載した省略等を再度説明しないため、このシグナルフローは、図２Ａおよび２Ｂに示したものと類似していることに注意されたい。
【０１０６】
ステップ４‐Ａにおいて、端末は、ＡＣからルータ通知（非請求または応答型）を受信する。ルータ通知（ＲＡ）は、ＡＡＡサポートを示すフラグを含む。メッセージを送信する前に、端末は割り当てられたＩＰｖ４アドレスを、例えばＤＨＣＰを使用して取得していなければならない。
【０１０７】
ステップ４‐Ｂにおいて、端末は、ルータ通知におけるＡＡＡフラグの存在から、ＡＡＡアクセス認証を実行する必要があることを推論する。端末は、ＡＡＡ要求メッセージ（ＲＱ１）をＡＣへ送信することにより認証シーケンスを開始する。ＡＡＡ要求は、ＥＡＰ応答およびＥＡＰ ＩＤメッセージを運ぶオプションと同様にＡＡＡクライアント識別子オプションを含む。ＡＡＡクライアント識別子オプションおよびＥＡＰ ＩＤメッセージは双方ともユーザのＮＡＩ（ＩＭＳＩ＠アドレス体系）を含む。
【０１０８】
ステップ４‐Ｃにおいて、ＡＣは、ＡＡＡクライアント識別子オプションに含まれるＮＡＩからＡＳのアドレスを（必要な場合はＤＮＳを使用して）導出し、ＡＡＡ要求メッセージ（ＡＲ）をＡＳに送信する。ＡＲは、ステップＢのＡＡＡクライアント識別子オプション内で受信したＥＡＰ ＩＤメッセージ（ＥＡＰペイロード属性において）およびＮＡＩ（ユーザ名属性において）を含む。
【０１０９】
ステップ４‐Ｄにおいて、ＡＳは、ステップ４‐ＣにおけるＡＲメッセージを受けて、以下を実行する。
・ Ｒ‐ＵＩＭ認証手順の開始を示すＥＡＰ要求／Ｒ‐ＵＩＭ／要求開始メッセージを作成する。
・ ＥＡＰ要求／Ｒ‐ＵＩＭ／開始（ＥＡＰペイロード属性において）およびユーザを（ユーザ名属性において）識別するＮＡＩを含むＡＡＡ回答（ＡＡ）メッセージをＡＣへ送信する。
【０１１０】
ステップ４‐Ｅにおいて、ＡＣは、組み込みデータオプションにＥＡＰ要求／Ｒ‐ＵＩＭ／開始を含むと共にＡＡＡクライアント識別子オプション含む、ＡＡＡ応答メッセージ（ＲＰ１）を端末へ送信する。ＡＡＡクライアント識別子オプションは、ユーザを識別するＮＡＩを含む。
【０１１１】
ステップ４‐Ｆにおいて、端末は、ＮＡＩ（ＩＭＳＩ＠アドレス体系）を含むＡＡＡクライアント識別子オプションおよびＥＡＰ応答／Ｒ‐ＵＩＭ／開始メッセージを運搬するＡＡＡ組み込みデータオプションを含むＡＡＡ要求メッセージ（ＲＱ１）を送信する。ＥＡＰ応答／Ｒ‐ＵＩＭ／開始メッセージの理由フィールドは、セッションキーがいかなる場合でも使用されないことを示す０（ゼロ）に設定される（ＣＡＶＥ認証のみ実行される）。
【０１１２】
ステップ４‐Ｇにおいて、ＡＣは、ＡＡＡクライアント識別子オプションに含まれるＮＡＩからＡＳのアドレスを（必要な場合はＤＮＳを使用して）導出し、ＡＡＡ要求メッセージ（ＡＲ）をＡＳに送信する。ＡＲは、ステップ４‐ＦのＡＡＡクライアント識別子オプション内で受信したような、ＥＡＰ応答／Ｒ‐ＵＩＭ／開始メッセージおよびＮＡＩを（ベンダー固有Ｒａｄｉｕｓ属性フィールドにおいて）含む。
【０１１３】
ステップ４‐Ｈにおいて、ＡＳは、ステップＧにおけるＡＲメッセージを受けて、以下を実行する。
・ ＮＡＩのＩＭＳＩ部分に基づき、ＡＳはユーザのための認証情報を有するＡｕＣを識別する。
・ Ｃａｖｅ認証トリプレットを要求し、ＡｕＣから得る。
・ 例えば、このＥＡＰ‐Ｒ‐ＵＩＭのために、Ｈ．Ｈａｖｅｒｉｎｅｎの「ＥＡＰ ＳＩＭ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（作業中）」インターネットドラフト（ｄｒａｆｔ−ｈａｖｅｒｉｎｅｎ−ｐｐｐｅｘｔ−ｅａｐ−ｓｉｍ−１０．ｔｘｔ）、インターネットエンジニアリングタスクフォース（２００３年２月）に明記されている、値ＭＡＣ＿ＲＡＮＤおよびＭＡＣ＿ＡＵＴＨＲを、ＡＴ ＲＡＮＤおよびＡＴ ＭＡＣとして計算する。
・ 後の使用のために、値ＭＡＣ＿ＡＵＴＨＲを格納する。
・ ＭＡＣ＿ＲＡＮＤ値および２つのＲＡＮＤ値（認証トリプレットから得たもの）を含むＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジメッセージを作成する。
・ ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジと、（ベンダー固有Ｒａｄｉｕｓ属性フィールドにおいて）ユーザを識別するＮＡＩとを含む、ＡＡＡ回答（ＡＡ）メッセージをＡＣへ送信する。
【０１１４】
ステップ４‐Ｉにおいて、ＡＣは、ＡＡＡ組み込みデータオプションにＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジを含むＡＡＡ応答メッセージ（ＲＰ２）、ＮＡＩを含むＡＡＡクライアント識別子オプションを送信する。
【０１１５】
ステップ４‐Ｊにおいて、端末はステップ４‐ＩにおけるＡＡＡ応答を受けて、以下を実行する。
・ Ｒ‐ＵＩＭを使用してＡＵＴＨＲ／ＡＵＴＨＵＩの２つの値を計算し、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジ内でＲ‐ＵＩＭモジュールに対するインプットとして受信した２つのＲＮＡＤ値を得る。
・ 例えば、上記で参照した文書Ｈ．Ｈａｖｅｒｉｎｅｎの「ＥＡＰ ＳＩＭ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（作業中）」インターネットドラフト（ｄｒａｆｔ−ｈａｖｅｒｉｎｅｎ−ｐｐｐｅｘｔ−ｅａｐ−ｓｉｍ−１０．ｔｘｔ）、インターネットエンジニアリングタスクフォース（２００３年２月）に明記されている、値ＭＡＣ＿ＲＡＮＤおよびＭＡＣ＿ＡＵＴＨＲを、ＡＴ＿ＲＡＮＤおよびＡＴ＿ＭＡＣとして計算する。
・ ＭＡＣ＿ＲＡＮＤ値を、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジ内で受信した値と比較する。値が一致する場合、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジメッセージの認証は成功であり、そうでない場合、そのメッセージの認証は失敗する。
・ ＡＡＡクライアント識別子オプション（ＩＭＳＩ＠アドレス体系の形をとるＮＡＩ）を含むと共にＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジをＡＡＡ組み込みデータオプションに含むＡＡＡ要求メッセージ（ＲＰ３）をＡＣへ送信する。ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジメッセージは、計算されたＭＡＣ＿ＡＵＴＨＲ値を含む。
【０１１６】
ステップ４‐Ｋにおいて、ＡＣは、ＡＲメッセージを（ＮＡＩにより識別された）ＡＳに送信する。ＡＲメッセージは、ＡＡＡ要求のＡＡＡクライアント識別子オプションにおいて受信したものとして、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジおよびＮＡＩを、（ベンダー固有Ｒａｄｉｕｓ属性フィールドにおいて）含む。
【０１１７】
ステップ４‐Ｌにおいて、ＡＳは、ステップＫにおけるＡＲメッセージを受けて、以下を実行する。
・ ステップ４‐Ｄにおいて計算されたＭＡＣ＿ＡＵＴＨＲ値を、ＥＡＰ応答／Ｒ‐ＵＩＭ／チャレンジに含まれるＭＡＣ＿ＡＵＴＨＲ値と比較する。値が一致する場合、ＣＡＶＥ認証は成功であり、そうでない場合、認証は失敗する。
・ ユーザを（Ｒａｄｉｕｓ属性フィールドにおいて）識別するＮＡＩおよび認証の成功（ＡＡにおける応答メッセージ属性）または失敗（アクセス拒否メッセージにおける応答メッセージ属性）を示す結果コードを含むＡＡメッセージをＡＣへ送信する。
【０１１８】
ステップ４‐Ｍにおいて、ＡＣは、ステップ４‐ＬにおけるＡＡメッセージを受けて、ＣＡＶＥ認証が成功したか否かを知る。認証が成功した場合、ＡＣは、ＡＡＡ応答メッセージを、ＳＵＣＣＥＳＳ（値０）を示すように設定されたコードフィールドとともに端末へ送信する。端末がこのメッセージを受信すると、ＯＷＬＡＮアクセスネットワーク認証は完了する。
【０１１９】
認証が成功した場合、ＡＣは、認証された端末から送信されたパケットを通過させることを認可するフィルタリングルールを適用しなければならない。代替として、以下のＭｏｂｉｌｅ ＩＰ／ＩＰｖ６アプリケーションのために説明するのと同種のキーイング機構を使用することにより、ネットワークアクセスＩＰｓｅｃエントリーまたは端末とこのアプリケーション（または別のアプリケーションコード）を有するＡＣの間に作成されたエントリーペアがあってもよい。
【０１２０】
第二の実施形態による第二の事例において、ＭＳやＨＡ、ＡＳの間のシグナリングフローを、アクセスリンクシグナリング（ＮＡＡＰ、ＰＰＰ‐ＬＣＰ等）、コアリンクシグナリング（ＲａｄｉｕｓまたはＤＩＡＭＥＴＥＲ）、およびエンドツーエンドシグナリングとして、ＥＡＰ‐Ｒ‐ＵＩＭを使用して説明する。結合したシグナリングを図５Ａおよび５Ｂに示す。
【０１２１】
ステップ５‐Ａにおいて、端末はそのＨＡがＲ‐ＵＩＭ認証を実行できるという知識を自動的に受信する。以下のメッセージを送信する前に、端末は割り当てられたＩＰｖ４アドレスを、例えばＤＨＣＰを使用して取得していなければならない。
【０１２２】
ステップ５‐Ｂにおいて、端末はそのホームネットワークによるその静的知識により、結合認証を実行する必要があることを推論する。端末は、ＡＡＡ要求メッセージ（ＲＱ１）をＨＡへ送信することにより、認証シーケンスを開始する。ＡＡＡ要求は、ＥＡＰ ＩＤメッセージを運ぶオプションと同様に、ＡＡＡクライアント識別子オプションをも含む。ＡＡＡクライアント識別子オプションおよびＥＡＰ ＩＤメッセージは、双方ともユーザのＮＡＩ（ＩＭＳＩ＠アドレス体系）を含む。
【０１２３】
ステップ５‐Ｃにおいて、ＨＡは、ＡＡＡクライアント識別子オプションに含まれるＮＡＩからＡＳのアドレスを（必要な場合はＤＮＳを使用して）導出し、ＡＡＡ要求（ＡＲ）メッセージをＡＳに送信する。ＡＲは、ステップ５‐ＢのＡＡＡクライアント識別子オプション内で受信したＥＡＰ ＩＤメッセージ（ＥＡＰペイロード属性において）およびＮＡＩ（ユーザ名属性において）を含む。
【０１２４】
ステップ５‐Ｄにおいて、ＡＳは、ステップＣにおけるＡＲメッセージを受けて、以下を実行する。
・ Ｒ‐ＵＩＭ認証手順の開始を示すＥＡＰ要求／Ｒ‐ＵＩＭ／要求開始メッセージを作成する。これを実行するため、ＡＳはＡｕＣ（認証センター）とも連絡する。
・ ＥＡＰ要求‐ＵＩＭ／開始（ＥＡＰペイロード属性において）と、ユーザを（ユーザ名属性において）識別するＮＡＩとを含むＡＡＡ回答（ＡＡ）メッセージを、ＨＡへ送信する。
【０１２５】
ステップ５‐Ｅにおいて、ＨＡは、組み込みデータオプションにＥＡＰ要求／Ｒ‐ＵＩＭ／開始を含むと共にＡＡＡクライアント識別子オプション含む、ＡＡＡ応答メッセージ（ＲＰ１）を端末へ送信する。ＡＡＡクライアント識別子オプションはユーザを識別するＮＡＩを含む。
【０１２６】
ステップ５‐Ｆにおいて、端末は、ＮＡＩ（ＩＭＳＩ＠アドレス体系）を含むＡＡＡクライアント識別子オプションおよびＥＡＰ応答／Ｒ‐ＵＩＭ／開始メッセージを運ぶＡＡＡ組み込みデータオプションを含むＡＡＡ要求メッセージ（ＲＱ２）を送信する。ＥＡＰ応答／Ｒ‐ＵＩＭ／開始の理由フィールドは、セッションキーがホーム登録保護に使用されることを示す２（バイナリ１０）に設定される（ＣＡＶＥ認証はステップＩの後に実行され、ステップＭの後、保護モビリティヘッダーのためＨＡによりＩｐｓｅｃセキュリティアソシエーションが作成される）。
【０１２７】
ステップ５‐Ｇにおいて、ＨＡは、ＡＡＡクライアント識別子オプションに含まれるＮＡＩからＡＳのアドレスを（必要な場合はＤＮＳを使用して）導出し、ＡＡＡ要求（ＡＲ）メッセージをＡＳに送信する。ＡＲは、ステップＦのＡＡＡクライアント識別子オプション内で受信したような、ＥＡＰ応答／Ｒ‐ＵＩＭ／開始メッセージおよびＮＡＩを（ベンダー固有Ｒａｄｉｕｓ属性フィールドにおいて）含む。
【０１２８】
ステップ５‐Ｈにおいて、ＡＳは、ステップＧにおけるＡＲメッセージを受けて、以下を実行する。
・ ＮＡＩのＩＭＳＩ部分に基づき、ＡＳはユーザのための認証情報を有するＡｕＣを識別する。
・ 必要な数だけのＣａｖｅ認証トリプレットを要求し、ＡｕＣから得る。これは、ＣＡＶＥアルゴリズムのキー長さおよび使用されるＩＰｓｅｃサイファプロファイルＩＤ（ＩＫＥ（インターネットキーエクスチェンジ）バージョン２において定義されているもののひとつ）により決定される。このプロファイルＩＤはＥＡＰパケットで通信される。
・ 例えば、このＥＡＰ‐Ｒ‐ＵＩＭのために、上記で参照した文書Ｈ．Ｈａｖｅｒｉｎｅｎの「ＥＡＰ ＳＩＭ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（作業中）」インターネットドラフト（ｄｒａｆｔ−ｈａｖｅｒｉｎｅｎ−ｐｐｐｅｘｔ−ｅａｐ−ｓｉｍ−１０．ｔｘｔ）、インターネットエンジニアリングタスクフォース（２００３年２月）に明記されている、値ＭＡＣ＿ＲＡＮＤおよびＭＡＣ＿ＡＵＴＨＲを、ＡＴ＿ＲＡＮＤおよびＡＴ＿ＭＡＣとして計算する。
・ 後の使用のために、値ＭＡＣ＿ＡＵＴＨＲを格納する。
・ ＭＡＣ＿ＲＡＮＤ値および２つのＲＡＮＤ値（認証トリプレットから得たもの）を含むＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジメッセージを作成する。
・ ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジおよびユーザを（ベンダー固有Ｒａｄｉｕｓ属性フィールドにおいて）識別するＮＡＩを含む、ＡＡＡ回答（ＡＡ）メッセージをＨＡへ送信する。
【０１２９】
ステップ５‐Ｉにおいて、ＨＡは、ＡＡＡ組み込みデータオプションにＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジを含むＡＡＡ応答メッセージ（ＲＰ２）、ＮＡＩを含むＡＡＡクライアント識別子オプションを送信する。
【０１３０】
ステップ５‐Ｊにおいて、端末は、ステップ５‐ＩにおけるＡＡＡ応答を受けて、以下を実行する。
・ Ｒ‐ＵＩＭを使用してＡＵＴＨＲ／ＡＵＴＨＵの２つの値を計算し、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジ内でＲ‐ＵＩＭモジュールにおけるＲｕｎ＿ＣＡＶＥアルゴリズムに対するインプットとして受信した２つのＲＮＡＤ値を得る。
・ 例えば、上記で参照した文書Ｈ．Ｈａｖｅｒｉｎｅｎの「ＥＡＰ ＳＩＭＡｕｔｈｅｎｔｉｃａｔｉｏｎ（作業中）」インターネットドラフト（ｄｒａｆｔ−ｈａｖｅｒｉｎｅｎ−ｐｐｐｅｘｔ−ｅａｐ−ｓｉｍ−１０．ｔｘｔ）、インターネットエンジニアリングタスクフォース（２００３年２月）に明記されている、値ＭＡＣ＿ＲＡＮＤおよびＭＡＣ＿ＡＵＴＨＲを、ＡＴ＿ＲＡＮＤおよびＡＴ＿ＭＡＣとして計算する。
・ ＭＡＣ＿ＲＡＮＤ値を、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジ内で受信した値と比較する。値が一致する場合、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジメッセージの認証は成功であり、そうでない場合、そのメッセージの認証は失敗する。
・ ＡＡＡクライアント識別子オプション（ＩＭＳＩ＠アドレス体系の形をとるＮＡＩ）およびＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジをＡＡＡ組み込みデータオプションに含むＡＡＡ要求メッセージ（ＲＱ３）をＨＡへ送信する。ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジメッセージは、計算されたＭＡＣ＿ＡＵＴＨＲ値を含む。
【０１３１】
ステップ５‐Ｋにおいて、ＨＡは、ＡＲメッセージを（ＮＡＩにより識別された）ＡＳに送信する。ＡＲメッセージは、ＡＡＡ要求のＡＡＡクライアント識別子オプションにおいて受信したものとしてＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジおよびＮＡＩを（ベンダー固有Ｒａｄｉｕｓ属性フィールドにおいて）含む。
【０１３２】
ステップ５‐Ｌにおいて、ＡＳは、ステップＫにおけるＡＲメッセージを受けて、以下を実行する。
・ ステップ５‐Ｄにおいて計算されたＭＡＣ＿ＡＵＴＨＲ値を、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジに含まれるＭＡＣ＿ＡＵＴＨＲ値と比較する。値が一致する場合、ＣＡＶＥ認証は成功であり、そうでない場合、認証は失敗する。
・ ユーザを（Ｒａｄｉｕｓ属性フィールドにおいて）識別するＮＡＩ，認証の成功（ＡＡにおける応答メッセージ属性）または失敗（アクセス拒否メッセージにおける応答メッセージ属性）を示す結果コード，およびキー応答（サイファプロファイルＩＤ，キー，存続期間）を含む、ＡＡメッセージをＨＡへ送信する。
【０１３３】
ステップ５‐Ｍにおいて、ＨＡは、ステップ５‐ＬにおけるＡＡメッセージを受けて、ＣＡＶＥ認証が成功したか否かを知る。認証が成功した場合、ＨＡはＡＡＡ応答メッセージ（ＲＰ３）をＳＵＣＣＥＳＳ（値０）を示すように設定されたコードフィールドとともに端末へ送信する。端末がこのメッセージを受信すると、ＯＷＬＡＮホーム登録認証およびキーイングは終了である。Ｒ‐ＵＩＭ認証が成功した場合、ＨＡは、
【０１３４】
・ Ｍｏｂｉｌｅ ＩＰｖ４アプリケーションに関しては、Ｒｕｎ＿ＣＡＶＥアルゴリズムをＲＵＩＭのために実行した際に得られたキー材料から適切なＭｏｂｉｌｅ ＩＰｖ４状態へのＭＮ‐ＨＡ認証拡張に使用されるバインディングセキュリティアソシエーション（ＢＳＡ）を必ず入力する。
・ Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに関しては、Ｒｕｎ＿ＣＡＶＥアルゴリズムをＲ‐ＵＩＭにおいて実行した際に得られたキー材料からＳＡＤＢのための２つのＩＰＳｅｃセキュリティアソシエーションを必ず入力する。これらのＳＡ（セキュリティアソシエーション）は、着信および発信登録（ＭＩＰｖ４）またはモビリティヘッダー（ＭＩＰｖ６）パケットのために、端末および使用されるＩＰｓｅｃサイファプロファイルＩＤにより識別されるようなその他のパラメータによって構成されている。この可能性のある作用は、ＩＰｓｅｃモジュールのＰｆｋｅｙインターフェイスを使用し、従ってＲ‐ＵＩＭキーイングデーモンとＩＰｓｅｃモジュールとの間にいかなる特別なインターフェイスも必要としない。
【０１３５】
ステップ５Ｎにおいて、端末は、Ｍｏｂｉｌｅ ＩＰｖ４アプリケーションに関し、キー材料から作成されるように、ＢＳＡのものを使用して、Ｍｏｂｉｌｅ‐Ｈｏｍｅ認証拡張をＭｏｂｉｌｅ ＩＰｖ４登録要求（ＲＲＥＱ）の中へ形成するであろう。ＨＡは、ＲＲＥＱのメッセージ認証を実行する際、対応するＢＳＡをＭＮ‐ＨＡ認証拡張に対して自動的に適用するであろう。
【０１３６】
さらにステップ５‐Ｎにおいて、Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに関しては、ＩＰＳｅｃセキュリティアソシエーションが入力されたＲ‐ＵＩＭが、送信されたパケットに自動的に適用されるよう、端末がＩＰＳｅｃで保護された対応付け更新をＨＡへ送信するであろう。ＨＡがパケットを受信すると、そのＩＰＳｅｃモジュールはＳＡがもう着信するモビリティヘッダーパケットに適用できることを自動的に知る。このパケットはＭｏｂｉｌｅ ＩＰｖ６ ＨＯＴＩ（ホーム試験開始）または対応付け更新（ＢＵ）メッセージであってよい。
【０１３７】
ステップ５‐Ｏにおいて、ＨＡは、Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに対し、受信したキー材料から作成されるように、Ｍｏｂｉｌｅ‐Ｈｏｍｅ認証拡張を、ＢＳＡのものを使用して、構築されたＭｏｂｉｌｅ ＩＰｖ４登録応答（ＲＲＥＰ）へ適用するだろう。次いで端末は、ＲＲＥＰのメッセージ認証を実行する際、対応するＢＳＡをＭＮ‐ＨＡ認証拡張に対し自動的に適用するであろう。
【０１３８】
さらに、Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに関しては、ステップ５‐Ｏにおいて、ＨＡのＩＰＳｅｃモジュールは、ＳＡが入力されたＲ−ＵＩＭを使用して送信されたＢａｃｋ（結合確認）メッセージを自動的に保護するであろう。次いで、ＩＰＳｅｃで保護されたモビリティヘッダーパケットをＨＡから受信すると、端末は自動的にＩＰＳｅｃセキュリティアソシエーションが入力されたＲ‐ＵＩＭを、ステップＮで使用されたものと逆方向に適用する。
【０１３９】
これは、モビリティシ・グナリング保護アプリケーションプロトコルのフローをうまく完了させる。Ｍｏｂｉｌｅ ＩＰ／ＩＰｖ６ホーム登録以外のアプリケーションでは、この種の手順を任意のＩＰｓｅｃＳＡを入力するために使用することができる。
【０１４０】
本発明は、上記の実施形態において説明したように、交換にかかわる様々なネットワークエンティティを実行することによって、ソフトウェアまたは組み込みハードウェアシステム、またはチップ要素において実施されることができる。端末における実装の重要な機能性は、標準Ｒ‐ＵＩＭ機能のためのＡＰＩへのアクセス、およびカプセル化されたアドレスを含む任意ＩＰパケットを構成するための能力である。アクセスコントローラにおいて、重要な機能はパケットカプセル化および、ＵＤＰまたはＩＣＭＰｖ６等のアクセスＡＡＡメッセージおよびＲＡＤＩＵＳまたはＤＩＡＭＥＴＥＲメッセージ等のコアＡＡＡメッセージへのカプセル開放、例えばＮＡＳＲＥＱアプリケーションから（例えば、Ｐ．Ｃａｌｈｏｕｎ、Ｗ．Ｂｕｌｌｅｙ、Ａ．Ｒｕｂｅｎｓ、Ｊ．Ｈａａｇ、Ｇ．Ｚｏｒｎ．Ｄｉａｍｅｔｅｒ ＮＡＳＲＥＱ Ａｐｐｌｉｃａｔｉｏｎ（進行中）、インターネットドラフト（ｄｒａｆｔ−ｉｅｔｆ−ａａａ−ｄｉａｍｅｔｅｒ−ｎａｓｒｅｑ−０８．ｔｘｔ）、インターネットエンジニアリングタスクフォース（２００１年１１月）に記載されているように）適合することによるものである。また、本発明は、この方法のためのアクセス認証サービスポイントがどこに位置するかに応じて、アクセスルータ、ネットワークサーバ、またはＰＤＳＮの汎用パケットフィルタリング機能を再利用する可能性がある。
【０１４１】
第二の実施形態の実装における最良の形態の概要を図１に示す。最良の形態では、ネットワークやＲ‐ＵＩＭハードウェア（第二の実施形態の場合）とのインターフェイスを備えるモバイル機器において、端末機能性を実装することであろう。この機能性は、ＩＰアクセスルータ、アクセスサーバ、またはモバイル機器が無線ネットワークを通じて接続されている基地局によって、ＧＲＡＳＰプロトコルメッセージを送受信するであろう。モバイル機器は、入力情報（チャレンジまたはＲＡＮＤ）を認証アルゴリズムに提供するネットワーク要素からメッセージを受信すると、ＣＡＶＥアルゴリズムを実行するために、Ｒ‐ＵＩＭにアクセスするであろう。これは、局所的に、応答およびネットワークと共有の秘密を生成する。
【０１４２】
ネットワークにおいて、本発明は、カプセル化されたメッセージをモバイル装置から受け取り、オペレータのネットワークに送り返すためにそれらをサーバベースのＲＡＤＩＵＳプロトコルにおいて再カプセル化するような、アクセスルータ／ＷＬＡＮ基地局に追加されるソフトウェアによって実施されることができる。追加のソフトウェアを伴う任意のＭｏｂｉｌｅ ＩＰホームエージェントがオペレータのネットワークに加えられると共に、ＲＡＤＩＵＳとＣＤＭＡ２０００ ＳＳ７メッセージの間のメッセージを翻訳するために、追加的にゲートウェイ（ＡＳまたはＡＡＡＨ）が使用される。このように、ＣＡＶＥプロトコルのセキュリティは、ＭＥおよびＡｕＣ／ＨＬＲの領域に制限され、ＣＤＭＡ２０００ネットワークにおいて現存するインフラストラクチャは認証および認可のため、また場合により請求およびアカウンティングのためにさえ、再利用される。従って、ＩＰまたはＣＤＭＡ２０００ネットワークへの変更は、まったく必要ないか、最小限ですむ。
【０１４３】
機能的な実装は、実装の仕様に応じて、例えばＯＳ（オペレーションシステム）カーネル、ユーザレベルのソフトウェア等、オペレーションシステムの様々な場所で生じる可能性がある。
【０１４４】
以下、図６Ａから６Ｃを参照し関連するネットワーク要素を簡単に説明する。上記の実施形態の説明に必要な手段のみを説明することが知られている。
【０１４５】
図６Ａは、上記の実施形態に記載のアクセスコントローラ（ＡＣ）を示す。アクセスコントローラ１は、上述の開始メッセージが中でカプセル化された認証メッセージを受信する受信手段１ａを備える。さらにアクセスコントローラは処理手段１ｂを備える。処理手段１ｂは、カプセル化された開始メッセージ（例えば、上述のようにクライアントタイプ、ユーザＩＤ、およびコアアドレス情報を含むクライアント識別子オプションメッセージおよびＥＡＰ（拡張認証プロトコル）ＩＤオプションメッセージ）を読み出す。カプセル化されたメッセージは、その後、転送手段１ｃにより、そのカプセル化されたメッセージ内において識別された認証サーバへ転送される。
【０１４６】
図６Ｂはモバイル端末２を示す。モバイル端末は、加入者機器の一例にすぎないことに注意されたい。モバイル端末２は、少なくともひとつのネットワークアクセスタイプを示す情報メッセージ（すなわち上述のルータ通知ＲＡ）を受けて、ネットワークアクセスタイプを判定する、判定手段２ａを備える。さらにモバイル端末３は、上述のような開始メッセージを作成する作成手段２ｂを備える。移動局２のカプセル化手段２ｃは、情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内において、開始メッセージをカプセル化し、移動局２の送信手段２ｄは、開始メッセージをアクセスコントローラへ送信する。
【０１４７】
図６ｃは上記の実施形態において使用されるようなルータ３を示す。ルータ３は、上述した情報メッセージ、すなわちルータ通知を作成する作成手段３ａを備える。ルータ３の送信手段３ｂは、情報メッセージを加入者機器へ送信する。ルータ３およびアクセスコントローラ１はひとつのユニット内に配置されてもよいことが知られている（上述の実施形態に記載のとおり）。
【０１４８】
本発明は、上述の実施形態に限定されるものではなく、特許請求の範囲内において変化してもよい。
【０１４９】
例えば、上記の実施形態は、ＵＳＩＭを使用するＥＡＰ‐ＡＫＡ認証機構およびＣＡＶＥアルゴリズムに基づくＲ‐ＵＩＭを使用する認証が両方使用されるように、自由に結合されることができる。
【０１５０】
モバイル機器およびアクセスネットワークの間のプロトコルはＵＤＰ、ＩＣＭＰ、ＩＣＭＰｖ６等のネットワーク層プロトコルまたはＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、およびブルートゥースプロファイル等のリンク層プロトコルのうち少なくともひとつを備えてよい。
【０１５１】
さらに、上述した実施形態には以下のバリエーションが存在する。
【０１５２】
１．ＥＡＰ‐ＳＩＭ方法の再利用
（例えば上述のように第二の実施形態に関連して）認証機構がＲ‐ＵＩＭを使用する方法は、ＥＡＰ‐ＳＩＭと呼ばれるＳＩＭのための方法と同じプロトコルカプセル化に組み込まれる。この使用法では、ＣＡＶＥアルゴリズムによる、Ｒ‐ＵＩＭに基づく認証の運搬のためのＥＡＰ‐ＳＩＭプロトコルを再利用している。
【０１５３】
ＥＡＰ‐ＳＩＭの代替使用の指示は、ＥＡＰ‐ＳＩＭプロトコルにおいて予備フィールドを使用して示されてよく、あるいは追加の属性であってよく、それをＡＴ‐Ｒ‐ＵＩＭと呼ぶ。
【０１５４】
２．スマートカードアルゴリズムのためのネットワーク側の終端位置
スマートカード（ＣＡＶＥまたはＡＫＡ秘密アルゴリズム）で動作するものに対応するアルゴリズムのネットワーク側の終端ポイントは、原理上、ＨＬＲ／ＡｕＣにあるか、ホームＡＡＡサーバＡＡＡＨ（図１）内で同一場所に位置する可能性がある。前者の場合には、Ｇ＿ｈと呼ばれるインターフェイスが存在し、それによってホームＡＡＡサーバはトリプレット／クインテットを表すダイアログをＧ＿ｈ上の携帯電話ネットワークプロトコルを使用して関連するスマートカードアルゴリズムに伝播する。
【０１５５】
さらに、モバイル端末または機器は、加入者端末の一例にすぎないことが知られている。「モバイル」という用語は、モバイル端末が無線リンクを経由してネットワークに接続されていることだけを意味するのではなく、例えば固定ケーブルを経由して異なるネットワークアクセス手段に接続される可能性がある端末をも意味する。例えばこれは、ホテルの部屋や電車等の中で固定ネットワークに接続される可能性のあるコンピュータのような、固定ネットワーク端末に接続可能なコンピュータを含んでよい。
【図面の簡単な説明】
【０１５６】
【図１】本発明の実施形態に従うＣＤＭＡ２０００マルチアクセスネットワーク参照モデルを示す。
【図２Ａ】本発明の第一の実施形態に従ったシグナルフローを示す。
【図２Ｂ】本発明の第一の実施形態に従ったシグナルフローを示す。
【図３Ａ】本発明の第一の実施形態の第二例に従ったシグナルフローを示す。
【図３Ｂ】本発明の第一の実施形態の第二例に従ったシグナルフローを示す。
【図４Ａ】本発明の第二の実施形態の第一例に従ったシグナルフローを示す。
【図４Ｂ】本発明の第二の実施形態の第一例に従ったシグナルフローを示す。
【図５Ａ】本発明の第二の実施形態の第二例に従ったシグナルフローを示す。
【図５Ｂ】本発明の第二の実施形態の第二例に従ったシグナルフローを示す。
【図６】図６Ａ〜Ｃは、それぞれ本発明の実施形態に従って使用可能なアクセスコントローラ、移動局、ルータを示す。
【技術分野】
【０００１】
本発明は、ネットワークサービスを認証および認可するためのシステムおよび方法に関する。
【背景技術】
【０００２】
今後の３Ｇ（第三世代）システムアーキテクチャにおいて、例えばＣＤＭＡ２０００（符号分割多元接続バージョン２０００）、携帯電話以外のＩＰベースのネットワーク、８０２．１１ワイヤレスＬＡＮ（ローカルエリアネットワーク）、ブルートゥース（登録商標）、イーサネット（登録商標）等、多数の異なるネットワークアクセス方法によりネットワークサービスが供給される可能性がある。しかし、３ＧＰＰ２においてモバイル機器が現在アクセスできるのは、ＣＤＭＡ２０００アクセス方法を使用するネットワークサービスのみである。従って、より確実かつ効果的にネットワークサービスを供給するためには、異なるアクセスネットワークがサービスを認可できるよう、モバイル機器に異なるタイプのアクセスネットワークを通じて認証する能力を持たせる必要がある。
【０００３】
いかなる種類のネットワークアクセス技術においても、ユーザ（端末）を認証するためのひとつの普遍的な認証プロセスはない。また、このことがマルチアクセスシナリオにおけるアクセスおよびセッションの可動性を難しくしている。一般的なＩＰネットワーク、携帯電話または携帯電話以外において同じ権限を使用するサービスプロビジョニングを可能にするため、ネットワークおよび移動局の間でメッセージ交換が必要とされている。しかし、ＣＤＭＡ２０００携帯電話ネットワークを使用していない場合、端末はオペレータのネットワークでそれ自体を認証しサービスを受けるために、いくつかの別の方法を使用しなければならないという問題がある。
【０００４】
ＳＩＭ（加入者識別モジュール）カードがＧＳＭ（グローバルシステムフォーモバイルコミュニケーションズ）ネットワークにおけるユーザＩＤを保持するのと同様に、ＣＤＭＡネットワークにおいて、携帯電話を使用するためのユーザＩＤを保持するＲ‐ＵＩＭチップを使用する際にも、同様の問題が生じる。Ｒ‐ＵＩＭについては、３ＧＧＰ２文書Ｃ．Ｓ００２３‐０に記載されている。
【０００５】
例えば、端末がＷＬＡＮ（ワイヤレスＬＡＮ）またはブルートゥース（登録商標）無線をインターネットなどへの接続に使用している場合、およびＲ‐ＵＩＭモジュールから同じ登録ＩＤを使用している場合、これを実現するには携帯電話以外の個別プロトコルが必要であり、本出願はこの問題に取り組むものである。
【発明の開示】
【０００６】
従って、本発明の第一の目的は、モバイル機器に異なる種類のアクセスネットワークを介して認証を行う可能性を提供することにある。
【０００７】
この目的は、次のようなシステムによって解決される。このシステムは、ネットワークサービスを認証および認可するためのシステムであって、該システムはモバイル機器を有し、
該モバイル機器は、少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてネットワークアクセスタイプを判定し、
少なくともユーザＩＤを含む開始メッセージを作成し、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するよう構成され、
さらに該システムは、カプセル化された前記メッセージを前記モバイル機器から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別される認証サーバに転送するアクセスコントローラをさらに備えるシステムである。
【０００８】
あるいは、上記目的は、ネットワークサービスを認証および認可するための方法であって、前記ネットワークはモバイル機器および認証制御機能を備え、
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けて前記モバイル機器によりネットワークアクセスタイプを判定するステップと、
少なくともユーザＩＤを含む開始メッセージを作成するステップと、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するステップと、
アクセスコントローラにより、カプセル化されたメッセージを前記モバイル機器から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するステップと、を含む方法により解決される。
【０００９】
このように、本発明によると、モバイル機器はネットワークアクセスタイプに関する情報を受信する（この情報メッセージはモバイル機器に送信される明示的メッセージであってよく、ネットワークにおいて一般的に利用可能な情報であってもよい）。モバイル機器はユーザＩＤを含む開始メッセージを作成し、認証メッセージ内のそれをアクセスコントローラへ送信する。アクセスコントローラは開始メッセージを評価し、それを的確な認証サーバへ転送する。
【００１０】
従って、モバイル機器は、認証メッセージを的確な認証サーバへ転送するひとつのコントローラだけをアドレス指定する必要がある。すなわち、モバイル機器は、どのようにして認証サーバに達するかを見極める必要がない。
【００１１】
さらに、異なるサービスのための複数の認証サーバが提供されてもよい。上述した従来技術によると、モバイル機器は複数の認証メッセージを、そのサービスが使用されるすべての異なる認証サーバに送信しなければならないことになる。それとは対照的に、本発明によれば、モバイル機器は、複数の認証サーバに対応する認証メッセージがカプセル化されるひとつの開始メッセージを送信するだけでよい。
【００１２】
従って、認証手順は簡略化される。加えて、複数のサービスが使用される場合であっても、単一の開始メッセージしか必要とされないため、ネットワークのトラフィック負荷は軽減される。
【００１３】
さらに、情報メッセージであって、ルータ通知を含む情報メッセージを発行するためのルータが提供されてもよい。
【００１４】
情報メッセージは拡張認証プロトコル（ＥＡＰ）サポートを示してもよい。
【００１５】
情報メッセージはモバイル機器がネットワークに入る際に発行されてもよい。
【００１６】
開始メッセージは、クライアント識別子オプションメッセージおよび拡張認証プロトコルサポート識別子オプションメッセージを含んでよく、前記メッセージは、クライアントタイプ、ユーザＩＤ、コアＩＰネットワーク内のクライアントをアドレス指定する方法に関わる情報（以下、「コアアドレス情報」という）のうち少なくともひとつに関する情報を含む。
【００１７】
モバイル機器およびアクセスネットワークの間のプロトコルは、ＵＤＰ、ＩＣＭＰ、ＩＣＭＰｖ６等のネットワーク層プロトコルまたはＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、およびブルートゥースプロファイル等のリンク層プロトコルのうち少なくともひとつを備えてよい。
【００１８】
適用される認証機構は、拡張認証プロトコル（ＥＡＰ）を備えてよい。
【００１９】
適用される認証機構は、携帯電話認証および音声暗号化（ＣＡＶＥ）アルゴリズムを適用するリムーバブルユーザ識別モジュール（Ｒ−ＵＩＭ）を使用する認証機構、または、ＡＫＡアルゴリズムを適用するＵＳＩＭを使用する認証機構であってよい。
【００２０】
本発明はまた、ネットワークサービスを認証および認可するためのシステムであって、モバイル機器手段であって、少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてネットワークアクセスタイプを判定し、少なくともユーザＩＤを含む開始メッセージを作成し、前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するための前記モバイル機器手段と、カプセル化されたメッセージを前記モバイル機器手段から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するためのアクセスコントローラとを備えるシステムも提案する。
【００２１】
さらに、本発明は、ネットワークサービスを認証および認可するためのシステムであって、前記ネットワークはモバイル機器および認証制御機能を備え、前記モバイル機器は、
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けて前記モバイル機器によりネットワークアクセスタイプを判定するための判定手段と、
少なくともユーザＩＤを含む開始メッセージを作成するための作成手段と、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するためのカプセル化手段と、
カプセル化されたメッセージを前記モバイル機器から読み出すための読み出し手段および前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するための転送手段を備えるアクセスコントローラ手段とを備える、システムを提案する。
【００２２】
これに関して、アクセスコントローラにより読み出されるメッセージは、別のタイプのメッセージ内においてカプセル化され、よってそのアクセスコントローラが認証サーバに送信することが知られている。
【００２３】
本発明は、アクセスコントロール機器であって、
認証メッセージがカプセル化される開始メッセージを受信するための受信手段と、
カプセル化されたメッセージを読み出すための処理手段と、
前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するための転送手段とを備えるアクセスコントロール機器も提案する。
【００２４】
また、この場合、アクセスコントローラにより読み出されるメッセージは、認証サーバに送信するため別のタイプのメッセージ内にカプセル化されてよい。
【００２５】
さらに、本発明は、加入者機器であって、
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてネットワークアクセスタイプを判定するための判定手段と、
少なくともユーザＩＤを含む開始メッセージを作成するための作成手段と、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するためのカプセル化手段と、
前記開始メッセージをアクセスコントロール機器に送信するための送信手段とを備える、加入者機器を提案する。
【００２６】
また本発明は、ルータ機器であって、少なくともひとつのネットワークアクセスタイプを示す情報メッセージを作成するための作成手段と、前記情報メッセージを加入者機器に送信するための送信手段とを備えるルータ機器を提案する。
【好適な実施形態の詳細な説明】
【００２７】
上述のように、本発明に従ってネットワークサービスを認証および認可するためのシステムが提供され、このシステムは、ネットワークアクセスタイプおよび拡張認証プロトコルサポートを示すルータ通知を発行するためのルータと、前記ルータ通知を受けてネットワークアクセスタイプを判定し、クライアントタイプ、ユーザＩＤおよびコアアドレス情報を備えたクライアント識別子オプションメッセージおよびＥＡＰ（拡張認証プロトコル）識別子オプションメッセージを含む開始メッセージを作成し、さらに前記ルータ通知内において識別されるアクセスネットワークと互換性がある、例えばＵＤＰ、ＩＣＭＰｖ６（インターネットコントロールメッセージプロトコルバージョン６（ＩＰｖ６用））等のＩＰｖ４またはＩＰｖ６プロトコル、もしくはＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、または適合するブルートゥースプロファイル等のリンク層プロトコルに前記開始メッセージをカプセル化するモバイル機器と、カプセル化されたメッセージを前記モバイル機器から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するためのアクセスコントローラとを備える。
【００２８】
数種の認証機構が使用されてもよい。以下の好適な実施形態の説明において、ＵＳＩＭ（汎用加入者識別モジュール）を使用するＥＡＰ‐ＡＫＡ（認証とキー合致）認証機構（第一の実施形態）およびＣＡＶＥ（携帯電話認証および音声暗号化）アルゴリズムを適用するＲ‐ＵＩＭ（リムーバブルユーザ識別モジュール）を使用する認証機構（第二の実施形態）が例として挙げられる。
【００２９】
第一の実施形態は、ＣＤＭＡ２０００携帯電話および携帯電話以外のパケットデータネットワークの併用に関し、特にユーザ認証およびＥＡＰ‐ＡＫＡ仕様を複数タイプのアクセスネットワークにわたって通信する際に汎用加入者識別モジュール（ＵＳＩＭ）を使用するサービスの認可に関する。この性能は、他の携帯電話環境における同様の方法と同じ方式で、ノンデータ認証のためのキーインフラストラクチャを活用するキー管理を自動化するのに有効である。ユーザ認証およびサービス認可を行うことにより、携帯電話オペレータはユーザに様々なアクセスネットワークタイプを提供すると同時に、統一サービスプロビジョニング、ユーザ基準のネットワークアクセス管理およびローミング認可を維持し、現存する認可／アカウンティング／請求インフラストラクチャからこれらすべてを活用することができる。要約すると、利点は複数のアクセス方法に使用するスマートカードベースのＣＤＭＡ２０００認証の統合であるといえる。
【００３０】
この実施形態は、ＷＬＡＮ／ＣＤＭＡ２０００ユーザのためのネットワークアクセス、モビリティシ・グナリング、およびその他のサービス認可を説明する。特に、第一の実施形態によると、モビリティ・マネジメント・シグナリング保護と同様に、ＷＬＡＮからのネットワーク認可がＡＡＡｖ６（Ｉｐｖ６用認証、認可およびアカウンティング）、ＥＡＰ‐ＡＫＡ（拡張認証プロトコル認証とキー合致）、および、提示されている方法のためのＣＤＭＡ２０００仕様の多元接続アーキテクチャと同様に、ＲＡＤＩＵＳプロトコルを使用する多元接続スキームが提供される。
【００３１】
上述したように、第一の実施形態によると、解決すべき問題は、ＣＤＭＡ２０００携帯電話ネットワークを使用していない場合、端末はオペレータのネットワークでそれ自体を認証しサービスを受けるために、いくつかの別の方法を使用しなければならないということである。本実施形態によると、この問題は、以下に詳しく説明するように、ユーザがユーザＩＤを保持するＵＳＩＭを有する限り、任意のアクセス技術およびコア技術を実行するために、ＥＡＰ‐ＡＫＡ仕様を使用してユーザを認証する方法を定義することにより克服される。
【００３２】
第一の実施形態によると、ＥＡＰ‐ＡＫＡ認証機構（例えば、J.Arkko・H.Haverinen著、EAP AKA Authentication（作業中）、インターネットドラフト（draft-arkko-pppext-eap-aka-10.txt）、インターネットエンジニアリングタスクフォース（２００３年６月）で定義されているようなもの）は、任意のネットワークアクセス技術を使用するネットワークに対しユーザを認証するために適用される。従って、端末、ＵＳＩＭ（汎用加入者識別モジュール）、アクセスコントローラ、認証ゲートウェイ、およびＣＤＭＡ２０００ネットワークの認証センター（ＡｕＣ／ＨＬＲ（ホームロケーションレジスタ、ＡｕＣはＨＬＲ内に位置する））のエンティティを伴う（がこれらに限定されない）多方面増加インターアクションによる相互認証、ネットワーク認可、およびサービスプロビジョニングが実現する。以下、これがどのようにして実現し得るのか、詳しく説明する。
【００３３】
図１は、ＣＤＭＡ２０００マルチアクセスネットワーク参照モデルを示し、これにはアクセスコントローラ（ＡＣ）および認証サーバ（ＡＳ）も提供される。
【００３４】
図１の左上部分に、訪問アクセスプロバイダネットワーク（特に、サービングネットワーク）が示されている。ソース無線ネットワーク（ＲＮ）はＲＡＮ‐ＰＤＳＮインターフェイス（Ｒ‐Ｐインターフェイス）を経由しサービングＰＤＳＮに接続されている。Ａ１０およびＡ１１は、ＣＤＭＡ２０００において定義される制御メッセージのためのインターフェイスである。ＰＤＳＮ（パケットデータサービングネットワーク）はフォーリンエージェントとしての役割を果たし、インターネット、イントラネットおよびワイヤレスアプリケーションプロトコル（ＷＡＰ）へのアクセスを移動局等に提供する。ソースＲＮは、インターフェイスＡ１を経由し移動通信交換局（ＭＳＣ）にも接続されている。
【００３５】
ＭＳＣはＳＳ７ネットワークを経由し移動局のホームアクセスプロバイダネットワークに接続されている。ホームアクセスプロバイダネットワークは、ホームロケーションレジスタ（ＨＬＲ）および認証センター（ＡｕＣ）を備え、以下に説明する実施形態によるとこれは必要なものである。
【００３６】
図１の左中部分に、ターゲットの訪問アクセスプロバイダネットワークが示されており、これに移動局が接続されてもよい。ターゲット訪問アクセスプロバイダネットワークは、ターゲットＲＮおよびターゲットＰＤＳＮを備え、これらはＲ‐Ｐインターフェイスによってサービング訪問アクセスプロバイダネットワーク内と同様に接続されている。双方のＰＤＳＮは、ＩＰネットワーク（インターネットプロトコルバージョン４（Ｉｐｖ４）および／またはインターネットプロトコルバージョン６（Ｉｐｖ６））にも接続されている。この接続のために、ＣＤＭＡ２０００においてインターフェイスＰｉが定義されている。サービングＰＤＳＮは、ＡＡＡＬ（ローカルＡＡＡ（認証、認可およびアカウンティング））サーバにも接続されており、このサーバはＩＰネットワークにもアクセスできる。
【００３７】
図１の右側に、上述したホームアクセスプロバイダネットワーク、ＩＰネットワークに接続されＡＡＡＨ（ホームＡＡＡ）を備えるホームＩＰネットワーク、およびＡＡＡサーバを備えるブローカーネットワークが示されている。さらに、ホームエージェント（ＨＡ）が図解されており、これはホームＩＰネットワーク、プライベートネットワーク、またはホームアクセスプロバイダネットワーク内に配置されてもよい。
【００３８】
移動局に対する追加のアクセスの可能性が図１の左下部分に示されており、ここで追加のターゲット訪問アクセスプロバイダネットワークが図解されている。これは以下に説明する実施形態のシナリオである。ここで移動局は、ターゲットＷＬＡＮ（ワイヤレスローカルエリアネットワーク）に接続されている。ＷＬＡＮは、ＩＰインターフェイスを経由して、後に詳細を説明するアクセスコントローラ（ＡＣ）に接続されている。ＡＣは、アクセスサーバ（ＡＳ）に接続されており、これがＩＰネットワークおよびホームアクセスプロバイダネットワーク、特にホームアクセスプロバイダネットワークのＡｕＣへの接続を提供する。
【００３９】
以下に説明する実施形態に記載の新しい機能性（すなわち、新しい機能性を備えた機器）は、斜線で塗りつぶしたボックスで示されている。換言すれば、これらの新しい機能性はＡＣおよびＡＳにあるということである。さらに、任意でホームＩＰネットワークのＡＡＡＨ内にＡＳが提供されてもよい。
【００４０】
端末は、携帯電話ネットワークおよびＯＷＬＡＮ（オペレータワイヤレスＬＡＮ）アクセスネットワークの一部であるＩＰネットワークを含む、あらゆる種類のＩＰネットワークにアクセス可能である必要がある機器である。端末は、ＵＳＩＭを有することにより、ＡＫＡアルゴリズムを実行できることも必要である。また、ＩＰｖ６プロトコルを実行する必要もある。ＭＩＰｖ６が使用される場合、このプロセスは、ホームエージェントと端末の間のセキュリティアソシエーションを動的に作成するために利用されることもできる。ＥＡＰ‐ＡＫＡ仕様は、ＡＫＡ認証がＥＡＰメッセージを使用してどのように実行されるかを示す。この実施形態に従って、この仕様がアクセス技術にかかわらず、どのように認証に使用されることができるかを説明する。
【００４１】
端末がこの機能性を実行できるネットワークに入る際、例えばルータまたはエージェント通知オプション等、サポートの指示を含むルータ通知（ＲＡ）を、このタイプのＡＡＡ（認証、認可およびアカウンティング）サポートを示すローカルＡＣ（アクセスコントローラ）から受信する。これは、本実施形態に従って認証、キー生成、およびサービスプロビジョニングを指示する。
【００４２】
ＥＡＰメッセージは、端末とユーザのＩＰネットワークへのアクセス制御に関与するネットワーク要素であるアクセスコントローラとの間で交換される際に、ＡＡＡｖ６メッセージまたはＷＬＡＮリンク層（ＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、適合するブルートゥースプロファイルメッセージ、ＰＰＰ ＥＡＰカプセル化、または任意の適合するｌａｓｔ−ｈｏｐ ＰＡＮＡプロトコルメッセージ等において、将来標準化されるとして）のいずれかにおいてカプセル化される。ＡＡＡｖ６が使用される場合、初期のＥＡＰ／ＡＫＡ ＩＤメッセージは、ＡＡＡｖ６メッセージ内のＥＡＰ ＩＤオプションに加わる。
【００４３】
アクセスコントローラと認証サーバの間で、ＥＡＰメッセージがＤｉａｍｅｔｅｒまたはＲａｄｉｕｓのようなコアネットワークプロトコルに運ばれる。ＡＣは、それをＩＭＳＩ（国際移動電話加入者識別番号）およびアドレス体系から割り当てることにより認証サーバのＩＰアドレスを決定する。認証サーバは、ＭＳＣを経由しＨＬＲ／認証センター（ＡｕＣ）に達する論理インターフェイスを有する。これは、ＭＡＰプロトコル（ＳＳ７ネットワーク）とＩＰで使用される認証プロトコルの間のゲートウェイとしての役割を果たす。
【００４４】
以下、本実施形態に従ってＯＷＬＡＮネットワークにおいてユーザを認証するためのシナリオを、メッセージフローを用いて説明する。
【００４５】
１．端末がアクセス要求メッセージ（ＡＡＡｖ６リクエストメッセージまたはネットワークアクセスを要求するその他任意のメッセージであってもよい）をアクセスコントローラに送信する。このメッセージにはＥＡＰ応答／ＡＫＡ ＩＤメッセージが組み込まれている。また、このメッセージ内にはユーザＮＡＩを回送するための供給も必要である。
【００４６】
２．アクセスコントローラが、コアネットワークにおいて認証サーバ（ＡＳ）に送信されたＥＡＰメッセージをフェッチし、それを要求メッセージ（Ｄｉａｍｅｔｅｒ ＡＡ要求メッセージまたはＲａｄｉｕｓアクセス要求メッセージであってもよい）に入れる。例えば、ＤｉａｍｅｔｅｒにおいてＥＡＰメッセージはＥＡＰペイロードＡＶＰにあるであろう。アクセスコントローラは、ユーザＮＡＩのアドレス体系部分に基づいて、要求がどのＡＳに行くべきかを割り出す。
【００４７】
３．メッセージを受信すると、ＡＳは、第一に、ユーザのための認証情報を有するＡｕＣを識別する。これは、ユーザＮＡＩのユーザ部分に基づいていてもよい。例えば、使用されるユーザＮＡＩがＩＭＳＩ＠アドレスの体系の形をとる場合、ＩＭＳＩは、ユーザＨＬＲ／ＡｕＣを識別するために使用されることができる。ＡＳは、ＡｕＣからＵＭＴＳ認証クインテットを要求する。このクインテットは、５つの値、すなわち、ａ）ネットワークチャレンジＲＡＮＤ、ｂ）予測されるユーザ応答ＸＲＥＳ、ｃ）暗号解読キーＣＫ、ｄ）完全性キーＩＫ、および、ｅ）ネットワーク認証トークンＡＵＴＮから成る。ＡＳは、これらの値を得ると、ＡＴ＿ＲＡＮＤ属性（乱数）、ＡＴ＿ＡＵＴＮ（認可ベクトル）、およびＡＴ＿ＭＡＣ（メッセージ認証コード）を作成する。後の使用のために、ＡＳは、値ＡＴ＿ＲＥＳを計算し格納する。ＡＳは、ＡＴ＿ＲＡＮＤ値・ＡＴ＿ＡＵＴＮ値・およびＡＴ＿ＭＡＣ値を含むＥＡＰ要求／ＡＫＡ／チャレンジメッセージを作成する。最後にＡＳは、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージをその中に含むメッセージおよびユーザを（ユーザ名属性において）識別するＮＡＩをＡＣへ送信する。メッセージはＤｉａｍｅｔｅｒ ＡＡ回答メッセージまたはＲａｄｉｕｓアクセスチャレンジメッセージであってもよい。Ｄｉａｍｅｔｅｒメッセージである場合、ＥＡＰメッセージはＥＡＰペイロードＡＶＰに運ばれる。
【００４８】
４．ＡＣが、ＥＡＰ要求／ＡＫＡ／チャレンジを含む端末に、メッセージを送信する。これは、ＡＡＡｖ６メッセージまたは端末とアクセスコントローラとの間で使用する、その他任意のネットワークアクセスプロトコルであってよい。
【００４９】
５．端末はこのメッセージを受信すると、第一に、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージを抽出する。次いでＡＫＡを使用してＡＴ＿ＲＥＳ値を計算し、ＥＡＰ要求／ＡＫＡ／チャレンジ内でＡＫＡに対するインプットとして受信したＡＴ＿ＲＡＮＤ値およびＡＴ＿ＭＡＣ値を得る。また端末は、ＡＴ＿ＡＵＴＮ値を計算し、それをＥＡＰ要求／ＡＫＡ／チャレンジにおいて受信したＡＴ＿ＡＵＴＮと比較する。これらの値が一致した場合、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージは認証に成功し、そうでない場合、このメッセージの認証は失敗する。値が一致していた場合、端末は、メッセージ（ＡＡＡｖ６）を作成し、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージを含むＡＣへ送信する。ＥＡＰ要求／ＡＫＡ／チャレンジメッセージは、計算されたＡＴ＿ＲＥＳ値を含む。
【００５０】
６．ＡＣは、再度要求メッセージを送信する（Ｄｉａｍｅｔｅｒ ＡＡ要求／Ｒａｄｉｕｓアクセス要求）。このときメッセージは、ＥＡＰ要求／ＡＫＡ／チャレンジを含む。
【００５１】
７．ＡＳはこのメッセージを受信すると、先に計算しておいたＡＴ＿ＲＥＳ値を受信したＥＡＰメッセージ内のＡＴ＿ＲＥＳ値と比較する。値が一致する場合、ＡＫＡ認証は成功し、そうでない場合、認証は失敗する。結果に応じて、アクセス認可またはアクセス拒否メッセージのいずれかを送信する（Ｒａｄｉｕｓの場合）。Ｄｉａｍｅｔｅｒであれば、結果コードＡＶＰ内の結果とともにＡＡ回答メッセージを送信する。
【００５２】
８．このメッセージを受けて、ＡＣは、認証が成功したか否かを知る。ＡＣは適切な応答メッセージを端末に送信する。端末がこのメッセージを受信すると、ＯＷＬＡＮアクセスネットワーク認証は完了する。認証が成功した場合、ＡＣは、認証された端末から送信されたパケットを通過させることを認可するフィルタリングルールを適用しなければならない。
【００５３】
次に、図２Ａおよび２Ｂに示すシグナルフロー図を参照し、上述の手順をもう少し詳しく説明する。シグナルフロー図は、端末（端末機すなわちＵＥ）、認証センター（ＡＣ）および認証サーバ（ＡＳ）の間で交換される信号を図解したものである。
【００５４】
ステップ２‐Ａにおいて、端末は、ＡＣからルータ通知（非請求または応答型）を受信する。ルータ通知（ＲＡ）は、ローカルチャレンジを含むＡＡＡチャレンジオプションを含む。メッセージを送信する前に、端末は割り当てられたＩＰアドレスを取得していなければならない（例えばＤＨＣＰ（動的ホスト構成プロトコル）サーバからのＩＰｖ４の場合。ＩＰｖ６アドレスの場合、自動構成アドレスであってもよい）。
【００５５】
ステップ２‐Ｂにおいて、端末は、ルータ通知におけるＡＡＡフラグの存在により、ＡＡＡアクセス認証を実行する必要があることを推論する。端末は、ＡＡＡ要求メッセージを（ＲＱ１に指示されて）ＡＣへ送信することにより、認証シーケンスを開始する。ＡＡＡ要求は、ＥＡＰ ＩＤメッセージを運ぶオプションと同様に、ＡＡＡクライアント識別子オプション（シグナルフロー図ではｃＩＤとして示される）を含む。ＡＡＡクライアント識別子オプションおよびＥＡＰ ＩＤメッセージは双方ともユーザのＮＡＩ（ＩＭＳＩ＠アドレス体系）を含む。
【００５６】
ステップ２‐Ｃにおいて、ＡＣは、ＡＡＡクライアント識別子オプションに含まれるＮＡＩからＡＳのアドレスを（必要な場合はＤＮＳを使用して）導出し、ＡＡＡ要求メッセージ（ＡＲ）をＡＳに送信する。ＡＲは、ステップＢのＡＡＡクライアント識別子オプション内で受信したＥＡＰ ＩＤメッセージ（ＥＡＰペイロード属性において）およびＮＡＩ（ユーザ名属性において）を含む。
【００５７】
ステップ２‐Ｄにおいて、ＡＳは、ステップ２‐ＣにおけるＡＲメッセージを受けて、以下を実行する。
・ ＮＡＩのＩＭＳＩ部分に基づき、ＡＳは、ユーザのための認証情報を有するＡｕＣを識別する。
・ ＵＭＴＳ認証クインテットを要求し、ＡｕＣから得る。このクインテットは、５つの値、すなわち、ａ）ネットワークチャレンジＲＡＮＤ、ｂ）予測されるユーザ応答ＸＲＥＳ、ｃ）暗号解読キーＣＫ、ｄ）完全性キーＩＫ、およびｅ）ネットワーク認証トークンＡＵＴＮから成る。
・ ＡＴ＿ＲＡＮＤ属性（乱数）、ＡＴ＿ＡＵＴＮ（認可ベクトル）、およびＡＴ＿ＭＡＣ（メッセージ認証コード）を計算する。
・ 後の使用のために、値ＡＴ＿ＲＥＳを計算し格納する（ＸＲＥＳから導出）。
・ ＡＴ＿ＲＡＮＤ値、ＡＴ＿ＡＵＴＮ値、およびＡＴ＿ＭＡＣ値を含む、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージを作成する。
・ ＥＡＰ要求／ＡＫＡ／チャレンジ（３ＧＰＰ２におけるベンダー固有属性）およびユーザを（ユーザ名属性において）識別するＮＡＩを含む、アクセスチャレンジ（ＡＡ）メッセージをＡＣへ送信する。
【００５８】
ステップ２‐Ｅにおいて、ＡＣは、ＡＡＡｖ６組み込みデータオプション、ＮＡＩを含むＡＡＡクライアント識別子オプション、およびＡＡＡｖ６チャレンジオプション内にＥＡＰ要求（シグナルフロー図ではＥＲｐ）／ＡＫＡ／チャレンジを含むＡＡＡ応答メッセージ（ＲＰ２）を端末へ送信する。ＡＡＡｖ６チャレンジオプションは、ＡＣにより設定されたローカルチャレンジ値を含む。
【００５９】
ステップ２‐Ｆにおいて、端末は、ステップ２‐ＥにおけるＡＡＡ応答を受けて、以下を実行する。
・ ＡＫＡを使用してＡＴ＿ＲＥＳ値を計算し、ＥＡＰ要求／ＡＫＡ／チャレンジ内でＡＫＡに対するインプットとして受信したＡＴ＿ＲＡＮＤ値およびＡＴ＿ＭＡＣ値を得る。
・ ＡＫＡにおいて指定されたように値ＡＴ＿ＡＵＴＮを計算する。
・ 計算したＡＴ＿ＡＵＴＮ値を、ＥＡＰ要求／ＡＫＡ／チャレンジにおいて受信した値と比較する。値が一致した場合、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージは認証に成功し、そうでない場合、このメッセージの認証は失敗する。
・ ＡＡＡ要求メッセージ（ＲＱ３）を、ＡＣへ送信する。ＡＡＡ要求メッセージ（ＲＱ３）は、ＡＡＡｖ６チャレンジオプション内にローカルチャレンジと、ＡＡＡクライアント識別子オプション（ＩＭＳＩ＠アドレス体系の形のＮＡＩ）と、ＡＡＡｖ６組み込みデータオプション内にＥＡＰ応答（ＥＲ）／ＡＫＡ／チャレンジメッセージとを含む。ＥＡＰ応答／ＡＫＡ／チャレンジは、計算されたＡＴ＿ＲＥＳ値を含む。
【００６０】
ステップ２‐Ｇにおいて、ＡＣは、ＡＡＡ要求（ＡＲ）メッセージをＡＳ（ＮＡＩにより識別される）へ送信する。ＡＲメッセージは、ＡＡＡ要求のＡＡＡクライアント識別子オプションにおいて受信したＥＡＰ要求／ＡＫＡ／チャレンジ（３ＧＰＰ２におけるベンダー固有属性）およびＮＡＩを（ユーザ名属性において）含む。
【００６１】
ステップ２‐Ｈにおいて、ＡＳはステップ２‐ＧにおけるＡＲメッセージを受けて、以下を実行する。
・ ステップＤにおいて計算されたＡＴ＿ＲＥＳ値を、ＥＡＰ応答／ＡＫＡ／チャレンジに含まれるＡＴ＿ＲＥＳ値と比較する。値が一致する場合、ＡＫＡ認証は成功であり、そうでない場合、認証は失敗する。
・ 認証が成功の場合、ユーザを（ユーザ名属性において）識別するＮＡＩを含むＡＡメッセージをＡＣへ送信する。認証が失敗した場合、アクセス拒否メッセージをＡＣへ送信する。
【００６２】
ステップ２‐Ｉにおいて、ＡＣは、ステップ２‐ＨにおけるＡＡメッセージを受けて、ＡＫＡ認証が成功したことを知る。ＡＣはＡＡＡ応答メッセージ（図２ＡにおいてＲＰ３により示される）をＳＵＣＣＥＳＳ（値０）を示すように設定されたコードフィールドとともに端末へ送信する。端末がこのメッセージを受信すると、ＯＷＬＡＮアクセスネットワーク認証は完了する。
【００６３】
認証が成功した場合、ＡＣは、認証された端末から送信されたパケットを通過させることを認可するフィルタリングルールを適用しなければならない。
【００６４】
以下、第一の実施形態に記載のモビリティバインディングのために、どのようにして汎用の認証確立が行われるかを説明する。
【００６５】
１．シーケンスが、要求メッセージ（ＡＡＡｖ６、ＷＬＡＮリンク層またはその他任意のネットワークアクセスプロトコル）をホームエージェント（ＨＡ）へ送信する端末から開始する。要求は、組み込みＥＡＰ応答／ＡＫＡ／ＩＤメッセージと同様にユーザ（ＩＭＳＩ＠アドレス体系）のＮＡＩを含む。
【００６６】
２．ＨＡが、ＥＡＰメッセージを取りに行き、それをコアネットワークにおいて認証サーバ（ＡＳ）に送信された要求メッセージ（Ｄｉａｍｅｔｅｒ ＡＡＡ要求メッセージまたはＲａｄｉｕｓアクセス要求メッセージであってもよい）に入れる。例えば、Ｄｉａｍｅｔｅｒにおいて、ＥＡＰメッセージはＥＡＰペイロードＡＶＰにあるであろう。ＮＡＩのアドレス体系部分はＡＳが存在するドメインを示すため、ＨＡは、ユーザＮＡＩのアドレス体系部分に基づいて、要求がどのＡＳに行くべきかを割り出す。
【００６７】
３．メッセージを受信すると、ＡＳは、第一にユーザのための認証情報を有するＡｕＣを識別する。これは、ユーザＮＡＩのユーザ部分に基づいていてもよい。例えば、使用されるユーザＮＡＩがＩＭＳＩ＠アドレス体系の形をとる場合、ＩＭＳＩは、ユーザＨＬＲ／ＡｕＣを識別するために使用されることができる。ＩＭＳＩは、ＡｕＣからＵＭＴＳ認証クインテットを要求する。このクインテットは、５つの値、すなわち、ａ）ネットワークチャレンジＲＡＮＤ、ｂ）予測されるユーザ応答ＸＲＥＳ、ｃ）暗号解読キーＣＫ、ｄ）完全性キーＩＫ、および、ｅ）ネットワーク認証トークンＡＵＴＮから成る。これらの値を得ると、ＡＳは、ＡＴ＿ＲＡＮＤ属性（乱数）、ＡＴ＿ＡＵＴＮ（認可ベクトル）、およびＡＴ＿ＭＡＣ（メッセージ認証コード）を作成する。後の使用のために、値ＡＴ＿ＲＥＳおよびセッションキーＫを計算し格納する。ＡＴ＿ＲＡＮＤ値、ＡＴ＿ＡＵＴＮ値およびＡＴ＿ＭＡＣ値を含むＥＡＰ要求／ＡＫＡ／チャレンジメッセージを作成する。最後にＡＳは、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージをその中に含むメッセージおよびユーザを（ユーザ名属性において）識別するＮＡＩを、ＨＡへ送信する。メッセージはＤｉａｍｅｔｅｒ ＡＡ回答メッセージまたはＲａｄｉｕｓアクセスチャレンジメッセージであってもよい。Ｄｉａｍｅｔｅｒメッセージである場合、ＥＡＰメッセージはＥＡＰペイロードＡＶＰに運ばれる。
【００６８】
４．ＨＡが、メッセージをＥＡＰ要求／ＡＫＡ／チャレンジを含む端末に送信する。これは、ＡＡＡｖ６メッセージまたは端末とアクセスコントローラとの間で使用する、その他任意のネットワークアクセスプロトコルであってよい。
【００６９】
５．端末は、このメッセージを受信すると、まずＥＡＰ要求／ＡＫＡ／チャレンジメッセージを抽出する。次いでＡＫＡを使用してＡＴ＿ＲＥＳ値を計算し、ＥＡＰ要求／ＡＫＡ／チャレンジ内でＡＫＡに対するインプットとして受信した、ＡＴ＿ＲＡＮＤ値およびＡＴ＿ＭＡＣ値を得る。次いで値Ｋを計算する。またＡＴ＿ＡＵＴＮ値を計算し、それをＥＡＰ要求／ＡＫＡ／チャレンジにおいて受信したＡＴ＿ＡＵＴＮと比較する。これらの値が一致した場合、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージは認証に成功し、そうでない場合、このメッセージの認証は失敗する。値が一致していた場合、端末はメッセージ（ＡＡＡｖ６）を作成し、ＥＡＰ応答／ＡＫＡ／チャレンジメッセージを含むＨＡへ送信する。ＥＡＰ応答／ＡＫＡ／チャレンジメッセージは計算されたＡＴ＿ＲＥＳ値を含む。端末は、今後のセキュリティアソシエーション（ＳＡ）に使用するため、値ＫをＨＡとともに格納する。
【００７０】
６．ＨＡは再度要求メッセージを送信する（Ｄｉａｍｅｔｅｒ ＡＡ要求／Ｒａｄｉｕｓアクセス要求）。このときメッセージはＥＡＰ応答／ＡＫＡ／チャレンジを含む。
【００７１】
７．ＡＳは、このメッセージを受信すると、先に計算しておいたＡＴ＿ＲＥＳ値を受信したＥＡＰメッセージ内のＡＴ＿ＲＥＳ値と比較する。値が一致する場合、ＡＫＡ認証は成功し、そうでない場合、認証は失敗する。結果に応じて、アクセス認可またはアクセス拒否メッセージのいずれかを送信する（Ｒａｄｉｕｓの場合）。Ｄｉａｍｅｔｅｒであれば、結果コードＡＶＰ内の結果とともにＡＡ回答メッセージを送信する。また、ＢＵ認証キーを搬送するのに必要なため、鍵配送ＡＶＰをＨＡおよびＢＵ認証キーの関連存続期間を有する認可存続期間ＡＶＰへ送信する。
【００７２】
８．このメッセージを受けて、ＨＡは認証が成功したか否かを知る。ＨＡは、対応付け更新（Ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）を認証する目的で、端末を使用しセキュリティアソシエーションを作成する。認証キーＫをこのＳＡに関連付け、メッセージ内において受信された際にその存続期間を初期化する。ＨＡは、適切な応答メッセージを端末に送信する。端末がこのメッセージを受信すると、ＢＵ認証キー確立は完了する。
【００７３】
以下、図３Ａおよび３Ｂに示すシグナルフロー図を参照し、上述の手順をもう少し詳しく説明する。
【００７４】
ステップ３‐Ａにおいて、端末は、そのＨＡがＡＫＡ認証を実行できるという知識を自動的に受信する。以下のメッセージを送信する前に、端末は割り当てられたＩＰｖ４アドレスを、例えばＤＨＣＰを使用して取得していなければならない。
【００７５】
ステップ３‐Ｂにおいて、端末はそのホームネットワークによるその静的知識により、結合認証を実行する必要があることを推論する。端末は、ＡＡＡ要求メッセージを（図３ＡのＲＱ１に指示されて）ＨＡへ送信することにより認証シーケンスを開始する。ＡＡＡ要求は、ＥＡＰ応答およびＥＡＰ ＩＤメッセージ（ＥＲｓ／ＥＡＰ ＩＤ）を運ぶオプションと同様にＡＡＡクライアント識別子オプション（ｃＩＤ）を含む。ＡＡＡクライアント識別子オプションおよびＥＡＰ ＩＤメッセージは双方ともユーザのＮＡＩ（ＩＭＳＩ＠アドレス体系）を含む。
【００７６】
ステップ３‐Ｃにおいて、ＨＡは、ＡＡＡクライアント識別子オプションに含まれるＮＡＩからＡＳのアドレスを（必要な場合はダイナミックネームサーバ（ＤＮＳ）を使用して）導出し、ＡＡＡ要求メッセージ（ＡＲ）をＡＳに送信する。ＡＲは、ステップＢのＡＡＡクライアント識別子オプション内で受信したＥＡＰ ＩＤメッセージ（ＥＡＰペイロード属性において）およびＮＡＩ（ユーザ名属性において）を含む。
【００７７】
ステップ３‐Ｄにおいて、ＡＳは、ステップ３‐ＢにおけるＡＲメッセージを受けて、以下を実行する。
・ ＥＡＰ応答／ＩＤの理由フィールドから、この手順で確立されたセッションキーがクライアントアテンダント認証に使用されることを認識する（そのため、後にキーをアテンダントとしての役割を果たすもの以外のＨＡに送信する必要がない）。
・ ＮＡＩのＩＭＳＩ部分に基づき、ユーザのための認証情報を有するＡｕＣを識別する。
・ ＵＭＴＳ認証クインテットを要求し、ＡｕＣから得る。
・ ＡＴ＿ＲＡＮＤ属性（乱数）、ＡＴ＿ＡＵＴＮ（認可ベクトル）、およびＡＴ＿ＭＡＣ（メッセージ認証コード）を計算する。
・ 後の使用のために、値ＡＴ＿ＲＥＳおよびＫを計算し格納する。
・ ＡＴ＿ＲＡＮＤ値、ＡＴ＿ＡＵＴＮ値、およびＡＴ＿ＭＡＣ値を含む、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージを作成する。
・ ＥＡＰ要求／ＡＫＡ／チャレンジ（３ＧＰＰ２におけるベンダー固有属性）およびユーザを（ユーザ名属性において）識別するＮＡＩを含むアクセスチャレンジ（ＡＣ）メッセージを、ＨＡへ送信する。
【００７８】
ステップ３‐Ｅにおいて、ＨＡは、ＡＡＡｖ６組み込みデータオプション、ＮＡＩを含むＡＡＡクライアント識別子オプション、およびＡＡＡｖ６チャレンジオプション内にＥＡＰ要求／ＡＫＡ／チャレンジを含むＡＡＡ応答メッセージ（図ではＲＰ２で示される）を端末へ送信する。ＡＡＡクライアント識別子オプションはユーザを識別するＮＡＩを、ＡＡＡｖ６チャレンジオプションはＨＡにより設定されたローカルチャレンジ値を含む。
【００７９】
ステップ３‐Ｆにおいて、端末は、ステップ３‐ＥにおけるＡＡＡ応答を受けて、以下を実行する。
・ ＡＫＡを使用してＡＴ＿ＲＥＳ値およびＫ値を計算し、ＥＡＰ要求／ＡＫＡ／チャレンジ内で、ＡＫＡに対するインプットとして受信したＡＴ＿ＲＡＮＤ値を得る。
・ 計算したＡＴ＿ＡＵＴＮ値を、ＥＡＰ要求／ＡＫＡ／チャレンジにおいて受信した値と比較する。値が一致した場合、ＥＡＰ要求／ＡＫＡ／チャレンジメッセージは認証に成功し、そうでない場合、このメッセージの認証は失敗する。
・ セキュリティアソシエーションに使用するため、キーＫをＨＡとともに格納する。
・ 更新の必要がある際に推論できるよう、セキュリティアソシエーションの存続期間をＨＡとともに格納する。
・ ＡＡＡｖ６チャレンジオプションにローカルチャレンジを含み、ＡＡＡｖ６組み込みデータオプションにＡＡＡクライアント識別子オプション（ＩＭＳＩ＠アドレス体系の形のＮＡＩ）およびＥＡＰ応答（ＥＲ）／ＡＫＡ／チャレンジメッセージを含む、ＡＡＡ要求メッセージ（ＲＱ３）をＨＡへ送信する。ＥＡＰ応答／ＡＫＡ／チャレンジは、計算されたＳＲＥＳ値を含む。
【００８０】
ステップ３‐Ｇにおいて、ＨＡは、ＡＲメッセージを（ＮＡＩにより識別された）ＡＳへ送信する。ＡＲメッセージは、ＡＡＡ要求のＡＡＡクライアント識別子オプションにおいて受信したＥＡＰ応答／ＡＫＡ／チャレンジ（３ＧＰＰ２におけるベンダー固有属性）およびＮＡＩを（ユーザ名属性において）を含む。
【００８１】
ステップ３‐Ｈにおいて、ＡＳはステップ３‐ＦにおけるＡＲメッセージを受けて、以下を実行する。
・ ステップ３‐Ｃにおいて計算されたＡＴ＿ＲＥＳ値を、ＥＡＰ応答／ＡＫＡ／チャレンジに含まれるＡＴ＿ＲＥＳ値と比較する。値が一致する場合、ＡＫＡ認証は成功であり、そうでない場合、認証は失敗する。
・ ＡＡメッセージをＨＡへ送信する。ＡＡメッセージは、ベンダー固有属性におけるＢＵ認証キーと、ユーザ名属性においてユーザを識別するＮＡＩと、および別のベンダー固有属性におけるＢＵ認証キー存続期間とを含む。キー存続期間フィールドは、ＡＳによって例えば値２５９２００（３日間）に設定される。
【００８２】
ステップ３‐Ｉにおいて、ＨＡは、端末とともに対応付け更新を認証するためにセキュリティアソシエーションを作成または更新し、キーＫを認証キーとしてそれに関連付け、キー存続期間属性において受信した値に従ってＳＡの存続期間を初期化する。次いでＨＡは、ＡＡＡ汎用キー応答オプションおよびＳＵＣＣＥＳＳ（値０）を示すよう設定されたコードフィールドを含むＡＡＡ応答メッセージ（ＲＰ３）を、端末に送信する。ＡＡＡ汎用キー応答オプションはキーＫを含まないが、存続期間フィールドはキー存続期間属性において受信した値に設定され、キーＳＰＩフィールドの値はＨＡと端末の間のセキュリティアソシエーションを示すように設定される。端末がこのメッセージを受信すると、汎用ＢＵ認証キー確立は完了する。
【００８３】
ステップ３‐Ｊにおいて、端末は、Ｍｏｂｉｌｅ ＩＰｖ４アプリケーションに対し、ＢＳＡのものを使用して、キー材料から作成されたように、Ｍｏｂｉｌｅ‐Ｈｏｍｅ認証拡張をＭｏｂｉｌｅ ＩＰｖ４登録要求（ＲＲＥＱ）の中へ形成するだろう。ＨＡは、ＲＲＥＱのメッセージ認証を実行する際、対応するＢＳＡをＭＮ‐ＨＡ認証拡張に対し自動的に適用するであろう。
【００８４】
Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに対しては、ＩＰＳｅｃセキュリティアソシエーションを入力されたＲ‐ＵＩＭが送信パケットに自動的に適用されるよう、端末がＩＰＳｅｃ保護の対応付け更新をＨＡに送信するだろう。ＨＡがパケットを受信すると、そのＩＰＳｅｃモジュールは、ＳＡが着信するモビリティヘッダーパケットにもう適用できることを自動的に知る。このパケットはＭｏｂｉｌｅ ＩＰｖ６ ＨＯＴＩまたは対応付け更新メッセージであってよい。
【００８５】
ステップ３‐Ｋにおいて、ＨＡは、Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに対し、受信したキー材料から作成されるように、Ｍｏｂｉｌｅ‐Ｈｏｍｅ認証拡張を、ＢＳＡのものを使用して、構築されたＭｏｂｉｌｅ ＩＰｖ４登録応答（ＲＲＥＰ）へ適用するだろう。次いで端末は、ＲＲＥＰのメッセージ認証を実行する際、対応するＢＳＡをＭＮ‐ＨＡ認証拡張に対し自動的に適用するであろう。
【００８６】
Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに対しては、ＨＡのＩＰＳｅｃモジュールはＳＡが入力されたＲ−ＵＩＭを使用して送信されたＢＡｃｋメッセージを自動的に保護するであろう。次いで、ＩＰＳｅｃで保護されたＨＡのモビリティヘッダーパケットを受信すると、端末は、自動的にＩＰＳｅｃセキュリティアソシエーションが入力されたＲ‐ＵＩＭを、ステップＮで使用されたものと逆方向に適用する。
【００８７】
これは、モビリティシ・グナリング保護アプリケーションプロトコルのフローをうまく完了させる。Ｍｏｂｉｌｅ ＩＰ／ＩＰｖ６ホーム登録以外のアプリケーションでは、この種の手順を任意のＩＰｓｅｃＳＡを入力するために使用することができる。
【００８８】
以下、本発明の第二の実施形態を説明する。
【００８９】
第一の実施形態と同様に、第二の実施形態は、ＣＤＭＡ２０００携帯電話および携帯電話以外のパケットデータネットワークを併用する領域を対象とし、特にユーザ認証および複数タイプのアクセスネットワークにわたって通信する際に、リムーバブルユーザ識別モジュール（Ｒ−ＵＩＭ）を使用するサービスの認可に関する。現在、携帯電話以外のＩＰネットワーク上でＲ−ＵＩＭ認証を行うためのプロトコルは存在しないが、この機能は、他の携帯電話環境における同様の方法と同じ方式で、ノンデータ認証のための現存するキーインフラストラクチャを活用するキー管理を自動化するのに有効である。ユーザ認証およびサービス認可を行うことにより、携帯電話オペレータは、現存する認可／アカウンティング／請求インフラストラクチャからこれらすべてを活用しながら、ユーザに様々なアクセスネットワークタイプを提供すると同時に、統一されたサービスやユーザ基準のネットワークアクセス管理、およびローミング認可を供給しつづけることができる。利点を要約すると、複数のアクセス方法のためのスマートカードをベースとしたＣＤＭＡ２０００認証の統合であるといえる。
【００９０】
第二の実施形態によると、異なるリンク層のＩＰにおよぶ様々なプロトコルがＲ‐ＵＩＭに基づくマルチアクセス認証および鍵配送機構に結合されている。このシステムは、異なる段階において様々なカプセル化メッセージを使用することにより、端末装置およびオペレータネットワークの双方が、ＩＰに基づく携帯電話以外または携帯電話のパケットデータサービスのためにＣＤＭＡ２０００ ＣＡＶＥ（携帯電話認証および音声暗号化）アルゴリズムを実行することができるよう、ネットワーク要素にデータ交換をさせる。交換されたデータおよびＣＡＶＥアルゴリズムの結果を使用することにより、端末およびアクセスネットワークは、相互に認証し合い、ネットワークアクセス認可またはローミングシグナリング認証のメッセージ保護等、期間限定アプリケーションのためのセキュアキーを導出することができる。ＣＡＶＥアルゴリズムについては、例えば１９９７年の「Ｃｅｌｌｕｌａｒ Ｒａｄｉｏ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｉｎｔｅｒｓｙｓｔｅｍ Ｏｐｅｒａｔｉｏｎｓ」、ＡＮＳＩ−ＴＩＡ／ＥＩＡ−４１においてさらに説明されていることが知られている。
【００９１】
端末は、ＣＤＭＡ２０００、８０２．１１ワイヤレスＬＡＮ、ブルートゥース（登録商標）、またはイーサネット（登録商標）を含む異種ネットワークタイプにおいてｍ、ＩＰに基づいて認証されたセッションを実行することができる。アクセスネットワークは、ポイントツーポイントまたはポイントツーマルチポイントであってよい。
【００９２】
端末は、この方法をＭｏｂｉｌｅ Ｉｐｖ６によって実行してもよいし、モビリティサポートなしにＩＰｖ６アクセスだけによって実行してもよい。
【００９３】
携帯電話以外の場合、本第二の実施形態によると、モバイル装置およびオペレータネットワークが任意のＩＰ利用可能なネットワーク上で互いに通信を行い、安全に証明書を交換し、サービスプロビジョニングを確立するために、使用されるネットワークの基本的特性にかかわらず、同一の方法が提供される。この方法は、説明のとおり、この方法を使用することで、オペレータが各技術を改革する必要はないが、リンク層固有の機構が使用されていないときにこのより一般的な方法を活用できるよう、登録ＩＤを共有することだけにより、現存するＣＤＭＡ２０００方式に関係している。わずかなネットワーク要素を加えることにより、本発明において述べられるように、オペレータは現存するネットワーク要素をほとんど、あるいはまったく変化させずに、それらの現存するＣＤＭＡ２０００サービスインフラストラクチャを活用することができる。
【００９４】
以下、第二の実施形態に記載の手順をもう少し詳しく説明する。
【００９５】
この実施形態は、携帯電話またはその他のモバイル機器（これまで「ＭＥ」または「モバイル装置」と称してきた）を対象とし、これらは通常ワイヤレスリンク上でＩＰに基づく通信機能を有すると共に、Ｒ‐ＵＩＭモジュールを有する。この実施形態は、固定機器の起動時に使用されることもできるが、モバイル機器に使用されるのが最も有効である。この実施形態により、第一の実施形態と同様、ＭＥ・Ｒ‐ＵＩＭ（その内蔵プロセッサ、不揮発性メモリ、およびプライベートデータの長所およびアルゴリズムにより、個別エンティティとみなされる）・アクセスコントローラ・認証ゲートウェイ・およびＣＤＭＡ２０００ネットワークの認証センター（ＡｕＣ／ＨＬＲ（ホームロケーションレジスタ）のエンティティを伴う（がこれらに限定されない）、複数の構成要素が連動することによる相互認証やネットワーク認可、およびサービスプロビジョニングが実現できる。
【００９６】
ＭＥが、ＧＲＡＳＰ（汎用Ｒ‐ＵＩＭ認証およびサービスプロビジョニング、本第二の実施形態に記載されているプロトコル例）機能を使用できるネットワークに入る際、ＭＥは、例えばこのタイプのＡＡＡサポートを示すローカルＡＣからのルータまたはエージェント通知オプション等、ＧＲＡＳＰサポート指示を含むルータ通知を受信する。これは、本発明に記載されているように、認証、キー生成、およびサービスプロビジョニングを開始する。次に、ＭＥが、クライアント識別子オプションおよびＥＡＰ ＩＤオプションを含むＥＡＰ Ｒ‐ＵＩＭ／開始メッセージでＡＣに応答する。いずれのオプションも、ＭＥ起動時に、Ｒ‐ＵＩＭ内のユーザのＩＭＳＩから構成されるユーザＩＤ（ＩＭＳＩ＠アドレス体系）と、Ｒ‐ＵＩＭまたはＭＥの不揮発性メモリ内の予備ファイルに含まれるアドレス体系とを含む。このＩＤ ＥＡＰメッセージは、ＩＰ／ＩＰｖ６においてアクセスリンクＡＡＡメッセージとしてカプセル化される。アクセスリンクＡＡＡメッセージは、将来標準化されるものとして、ＩＰｖ４またはＩＰｖ６それぞれの付録Ａ中の最もよい実施事例に記載されているように、例えばＵＤＰまたはＩＣＭｖ６メッセージ、ＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、または適合するブルートゥースプロファイルメッセージ等のリンク層カプセル化、ＰＰＰ ＥＡＰカプセル化、または任意の適合するｌａｓｔ−ｈｏｐ ＰＡＮＡプロトコルメッセージ内等にあってよい。
【００９７】
ＡＣは、それをＩＭＳＩおよびアドレス体系から割り当てることにより、認証サーバのＩＰアドレスを決定し、例えばＲＡＤＩＵＳまたはＤＩＡＭＥＴＥＲ等その他任意のコアＡＡＡプロトコルを使用して、カプセル化輸送のためにＡＡＡメッセージをＩＰコアに転送する。このメッセージはその後ＡＳに受信され、ＡＳは次いでＡｕＣ／ＨＬＲに連絡する。
【００９８】
ＡＳは、ＳＳ７または音声回路認証を模倣したＡ１メッセージングを使用することにより、直接またはサービングＭＳＣを経由してＡｕＣ／ＨＬＲと通信を行うＡＡＡサーバであってよい。換言すると、ＡＳは、ＡｕＣ／ＨＬＲと通信を行うための機能性を有するということになる。この構造上の選択により、現存するＣＤＭＡネットワークは修正されないままでよく、ＡＳを加える必要があるだけである。これは非侵害的オーバーレイアプローチである。
【００９９】
あるいは、より密接な統合を伴うアプローチは、ＣＤＭＡ２０００ネットワークに変化をもたらすであろう。ＡＳは、ＣＤＭＡ２０００パケットコアネットワーク内の標準に修正されたホームＡＡＡサーバ（ＡＡＡＨ）へ認証を転送する、ＰＤＳＮ内のＡＡＡ（ＲＡＤＩＵＳ）クライアント／ブローカーであってよい。後者は、ＡＡＡＨがＡｕＣ／ＨＬＲと通信を行うための機能性を有することを要求するが、これはＣＤＭＡ２０００パケットコアに対する修正である。後者の構造上の選択は、それらの認証がＰＤＳＮにおけるＰＰＰセッションの終わりに終了し、ＡＡＡＨサーバとのＲＡＤＩＵＳメッセージ交換をもたらすため、現在ＥＡＰ‐ＣＨＡＰまたはＥＡＰ‐ＰＡＰで行われているように、ＰＤＳＮを経由してＲ‐ＵＩＭ認証を本来のＣＤＭＡ２０００パケットデータセッションに使用する可能性を与えるであろう。換言すれば、後者の代替は、携帯電話以外のＲ‐ＵＩＭ認証をＰＤＳＮ経由でまたは直接ホームＡＡＡサーバへ仲介し、または、拡張ＰＤＳＮ ＲＡＤＩＵＳクライアント機能を使用して携帯電話ＰＰＰ‐Ｒ‐ＵＩＭ認証を同じ終点へ転送するであろう。この拡張は、ＥＡＰ‐Ｒ‐ＵＩＭ性能およびＲＡＤＩＵＳメッセージへのマッピングであり、潜在的に上述の方法のための携帯電話以外のＲＡＤＩＵＳメッセージ再利用であろう。
【０１００】
ＡＳは、登録を受信すると、ＡｕＣからの無作為化されたキーイングマテリアル検索をＲＡＮＤまたはＲＡＮＤＵ（実行される認証の大域的または固有の性質による）の形で開始し、この無作為情報を、クライアントＩＤオプションをＡＡＡ回答（ＲＡＤＩＵＳ上で輸送される）内に含むＥＡＰ Ｒ‐ＵＩＭ／チャレンジメッセージの形でチャレンジとしてＭＥに返す。
【０１０１】
ＭＥは、ＡＳから無作為チャレンジ（ＲＡＮＤ）を受信したら、そのものを認証しセッションのための暗号化キーを生成するためのＣＡＶＥアルゴリズムを実行できる状態となる。ＭＥは、ＲｕｎＣａｖｅアルゴリズムを開始させるコマンドをＲ‐ＵＩＭに送信し、必要ならばこのＲ‐ＵＩＭに対し、ＥＳＮ（電話の電子シリアル番号、決定済みおよびＭＥ起動時）・ＲＡＮＤ／ＲＡＮＤＵ・ランドタイプ（固有または大域的、何が供給されるかにより異なる）・およびＰＩＮ番号を提供する。次いでＭＥは、Ｇｅｔ Ｒｅｓｐｏｎｓｅを実行して、Ｒ‐ＵＩＭにアウトプットＡＵＴＨＲまたはＡＵＴＨＵ（大域的または固有のチャレンジ応答）をＭＥへ回送させる。
【０１０２】
ＭＥはチャレンジ応答を受信した後、上述したものと同様のパケットでそれをＡＣへ送信するが、このチャレンジ応答は、ローカルチャレンジ、クライアントＩＤおよびチャレンジ応答マテリアルを含む組み込みデータオプションを伴うＥＡＰ／Ｒ‐ＵＩＭ／開始メッセージである。その後ＡＣは、前のステップでしたように、ＡＳのアドレスを調べ、メッセージをＲＡＤＩＵＳ経由で転送する。ＡＳはメッセージを受け取り、ＩＤサブオプションにおいて受信したＩＭＳＩおよびアドレス体系に基づいてマッピング検索を行うことで、どちらのＡｕＣ／ＨＬＲに連絡するか判断し、ＩＭＳＩ＠アドレス体系に基づいて、その格納されたセッション状態の検索も行う。ＡＳは、ＡｕＣ／ＨＬＲからＣＡＶＥ証明書を検索し、ＣＡＶＥアルゴリズムを実行し、ＭＥから受信した応答をＡｕＣ／ＨＬＲから受信した応答と比較することで、クライアントの信頼性検証を進める。
【０１０３】
ＭＥおよびＡｕＣ／ＨＬＲから受信した応答が等しい場合、ＡＳは、セッションキーおよびサクセスコードを別のＥＡＰメッセージ内のＡＣに送り返す。このＥＡＰメッセージを受けて、ＡＣは、ＭＥへのアクセスを承諾し、セッションキーをセッションの間使用するため保存する。これは、例えばＡＣにおけるコアＡＡＡクライアント機能性によって起こる。ＡＣは、ＭＥにネットワークへのアクセスを承諾するため、ＩＰｓｅｃセキュリティアソシエーションをＭＥによってＡＣ内に入力し、またはファイアウォールルールを作成する。
【０１０４】
次いでＡＣは、前述したようにｌａｓｔ‐ｈｏｐ ＡＡＡプロトコル（例えばＩＣＭｖ６）に組み込み、キーサブオプションを除去して、メッセージをＭＥに送り返す。従って、キーがｌａｓｔ‐ｈｏｐ上に送られることはなく、安全でない可能性があり、ＭＥはＲ‐ＵＩＭにおいてそのＭＥが導出したキーを使用し、ＡＣはＲＡＤＩＵＳを経由してＡＳからキーを送り返す。
【０１０５】
次に、図４Ａおよび４Ｂに示すシグナルフロー図を参照し、上述の手順をもう少し詳しく説明する。図２Ａおよび２Ｂに関連して記載した省略等を再度説明しないため、このシグナルフローは、図２Ａおよび２Ｂに示したものと類似していることに注意されたい。
【０１０６】
ステップ４‐Ａにおいて、端末は、ＡＣからルータ通知（非請求または応答型）を受信する。ルータ通知（ＲＡ）は、ＡＡＡサポートを示すフラグを含む。メッセージを送信する前に、端末は割り当てられたＩＰｖ４アドレスを、例えばＤＨＣＰを使用して取得していなければならない。
【０１０７】
ステップ４‐Ｂにおいて、端末は、ルータ通知におけるＡＡＡフラグの存在から、ＡＡＡアクセス認証を実行する必要があることを推論する。端末は、ＡＡＡ要求メッセージ（ＲＱ１）をＡＣへ送信することにより認証シーケンスを開始する。ＡＡＡ要求は、ＥＡＰ応答およびＥＡＰ ＩＤメッセージを運ぶオプションと同様にＡＡＡクライアント識別子オプションを含む。ＡＡＡクライアント識別子オプションおよびＥＡＰ ＩＤメッセージは双方ともユーザのＮＡＩ（ＩＭＳＩ＠アドレス体系）を含む。
【０１０８】
ステップ４‐Ｃにおいて、ＡＣは、ＡＡＡクライアント識別子オプションに含まれるＮＡＩからＡＳのアドレスを（必要な場合はＤＮＳを使用して）導出し、ＡＡＡ要求メッセージ（ＡＲ）をＡＳに送信する。ＡＲは、ステップＢのＡＡＡクライアント識別子オプション内で受信したＥＡＰ ＩＤメッセージ（ＥＡＰペイロード属性において）およびＮＡＩ（ユーザ名属性において）を含む。
【０１０９】
ステップ４‐Ｄにおいて、ＡＳは、ステップ４‐ＣにおけるＡＲメッセージを受けて、以下を実行する。
・ Ｒ‐ＵＩＭ認証手順の開始を示すＥＡＰ要求／Ｒ‐ＵＩＭ／要求開始メッセージを作成する。
・ ＥＡＰ要求／Ｒ‐ＵＩＭ／開始（ＥＡＰペイロード属性において）およびユーザを（ユーザ名属性において）識別するＮＡＩを含むＡＡＡ回答（ＡＡ）メッセージをＡＣへ送信する。
【０１１０】
ステップ４‐Ｅにおいて、ＡＣは、組み込みデータオプションにＥＡＰ要求／Ｒ‐ＵＩＭ／開始を含むと共にＡＡＡクライアント識別子オプション含む、ＡＡＡ応答メッセージ（ＲＰ１）を端末へ送信する。ＡＡＡクライアント識別子オプションは、ユーザを識別するＮＡＩを含む。
【０１１１】
ステップ４‐Ｆにおいて、端末は、ＮＡＩ（ＩＭＳＩ＠アドレス体系）を含むＡＡＡクライアント識別子オプションおよびＥＡＰ応答／Ｒ‐ＵＩＭ／開始メッセージを運搬するＡＡＡ組み込みデータオプションを含むＡＡＡ要求メッセージ（ＲＱ１）を送信する。ＥＡＰ応答／Ｒ‐ＵＩＭ／開始メッセージの理由フィールドは、セッションキーがいかなる場合でも使用されないことを示す０（ゼロ）に設定される（ＣＡＶＥ認証のみ実行される）。
【０１１２】
ステップ４‐Ｇにおいて、ＡＣは、ＡＡＡクライアント識別子オプションに含まれるＮＡＩからＡＳのアドレスを（必要な場合はＤＮＳを使用して）導出し、ＡＡＡ要求メッセージ（ＡＲ）をＡＳに送信する。ＡＲは、ステップ４‐ＦのＡＡＡクライアント識別子オプション内で受信したような、ＥＡＰ応答／Ｒ‐ＵＩＭ／開始メッセージおよびＮＡＩを（ベンダー固有Ｒａｄｉｕｓ属性フィールドにおいて）含む。
【０１１３】
ステップ４‐Ｈにおいて、ＡＳは、ステップＧにおけるＡＲメッセージを受けて、以下を実行する。
・ ＮＡＩのＩＭＳＩ部分に基づき、ＡＳはユーザのための認証情報を有するＡｕＣを識別する。
・ Ｃａｖｅ認証トリプレットを要求し、ＡｕＣから得る。
・ 例えば、このＥＡＰ‐Ｒ‐ＵＩＭのために、Ｈ．Ｈａｖｅｒｉｎｅｎの「ＥＡＰ ＳＩＭ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（作業中）」インターネットドラフト（ｄｒａｆｔ−ｈａｖｅｒｉｎｅｎ−ｐｐｐｅｘｔ−ｅａｐ−ｓｉｍ−１０．ｔｘｔ）、インターネットエンジニアリングタスクフォース（２００３年２月）に明記されている、値ＭＡＣ＿ＲＡＮＤおよびＭＡＣ＿ＡＵＴＨＲを、ＡＴ ＲＡＮＤおよびＡＴ ＭＡＣとして計算する。
・ 後の使用のために、値ＭＡＣ＿ＡＵＴＨＲを格納する。
・ ＭＡＣ＿ＲＡＮＤ値および２つのＲＡＮＤ値（認証トリプレットから得たもの）を含むＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジメッセージを作成する。
・ ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジと、（ベンダー固有Ｒａｄｉｕｓ属性フィールドにおいて）ユーザを識別するＮＡＩとを含む、ＡＡＡ回答（ＡＡ）メッセージをＡＣへ送信する。
【０１１４】
ステップ４‐Ｉにおいて、ＡＣは、ＡＡＡ組み込みデータオプションにＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジを含むＡＡＡ応答メッセージ（ＲＰ２）、ＮＡＩを含むＡＡＡクライアント識別子オプションを送信する。
【０１１５】
ステップ４‐Ｊにおいて、端末はステップ４‐ＩにおけるＡＡＡ応答を受けて、以下を実行する。
・ Ｒ‐ＵＩＭを使用してＡＵＴＨＲ／ＡＵＴＨＵＩの２つの値を計算し、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジ内でＲ‐ＵＩＭモジュールに対するインプットとして受信した２つのＲＮＡＤ値を得る。
・ 例えば、上記で参照した文書Ｈ．Ｈａｖｅｒｉｎｅｎの「ＥＡＰ ＳＩＭ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（作業中）」インターネットドラフト（ｄｒａｆｔ−ｈａｖｅｒｉｎｅｎ−ｐｐｐｅｘｔ−ｅａｐ−ｓｉｍ−１０．ｔｘｔ）、インターネットエンジニアリングタスクフォース（２００３年２月）に明記されている、値ＭＡＣ＿ＲＡＮＤおよびＭＡＣ＿ＡＵＴＨＲを、ＡＴ＿ＲＡＮＤおよびＡＴ＿ＭＡＣとして計算する。
・ ＭＡＣ＿ＲＡＮＤ値を、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジ内で受信した値と比較する。値が一致する場合、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジメッセージの認証は成功であり、そうでない場合、そのメッセージの認証は失敗する。
・ ＡＡＡクライアント識別子オプション（ＩＭＳＩ＠アドレス体系の形をとるＮＡＩ）を含むと共にＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジをＡＡＡ組み込みデータオプションに含むＡＡＡ要求メッセージ（ＲＰ３）をＡＣへ送信する。ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジメッセージは、計算されたＭＡＣ＿ＡＵＴＨＲ値を含む。
【０１１６】
ステップ４‐Ｋにおいて、ＡＣは、ＡＲメッセージを（ＮＡＩにより識別された）ＡＳに送信する。ＡＲメッセージは、ＡＡＡ要求のＡＡＡクライアント識別子オプションにおいて受信したものとして、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジおよびＮＡＩを、（ベンダー固有Ｒａｄｉｕｓ属性フィールドにおいて）含む。
【０１１７】
ステップ４‐Ｌにおいて、ＡＳは、ステップＫにおけるＡＲメッセージを受けて、以下を実行する。
・ ステップ４‐Ｄにおいて計算されたＭＡＣ＿ＡＵＴＨＲ値を、ＥＡＰ応答／Ｒ‐ＵＩＭ／チャレンジに含まれるＭＡＣ＿ＡＵＴＨＲ値と比較する。値が一致する場合、ＣＡＶＥ認証は成功であり、そうでない場合、認証は失敗する。
・ ユーザを（Ｒａｄｉｕｓ属性フィールドにおいて）識別するＮＡＩおよび認証の成功（ＡＡにおける応答メッセージ属性）または失敗（アクセス拒否メッセージにおける応答メッセージ属性）を示す結果コードを含むＡＡメッセージをＡＣへ送信する。
【０１１８】
ステップ４‐Ｍにおいて、ＡＣは、ステップ４‐ＬにおけるＡＡメッセージを受けて、ＣＡＶＥ認証が成功したか否かを知る。認証が成功した場合、ＡＣは、ＡＡＡ応答メッセージを、ＳＵＣＣＥＳＳ（値０）を示すように設定されたコードフィールドとともに端末へ送信する。端末がこのメッセージを受信すると、ＯＷＬＡＮアクセスネットワーク認証は完了する。
【０１１９】
認証が成功した場合、ＡＣは、認証された端末から送信されたパケットを通過させることを認可するフィルタリングルールを適用しなければならない。代替として、以下のＭｏｂｉｌｅ ＩＰ／ＩＰｖ６アプリケーションのために説明するのと同種のキーイング機構を使用することにより、ネットワークアクセスＩＰｓｅｃエントリーまたは端末とこのアプリケーション（または別のアプリケーションコード）を有するＡＣの間に作成されたエントリーペアがあってもよい。
【０１２０】
第二の実施形態による第二の事例において、ＭＳやＨＡ、ＡＳの間のシグナリングフローを、アクセスリンクシグナリング（ＮＡＡＰ、ＰＰＰ‐ＬＣＰ等）、コアリンクシグナリング（ＲａｄｉｕｓまたはＤＩＡＭＥＴＥＲ）、およびエンドツーエンドシグナリングとして、ＥＡＰ‐Ｒ‐ＵＩＭを使用して説明する。結合したシグナリングを図５Ａおよび５Ｂに示す。
【０１２１】
ステップ５‐Ａにおいて、端末はそのＨＡがＲ‐ＵＩＭ認証を実行できるという知識を自動的に受信する。以下のメッセージを送信する前に、端末は割り当てられたＩＰｖ４アドレスを、例えばＤＨＣＰを使用して取得していなければならない。
【０１２２】
ステップ５‐Ｂにおいて、端末はそのホームネットワークによるその静的知識により、結合認証を実行する必要があることを推論する。端末は、ＡＡＡ要求メッセージ（ＲＱ１）をＨＡへ送信することにより、認証シーケンスを開始する。ＡＡＡ要求は、ＥＡＰ ＩＤメッセージを運ぶオプションと同様に、ＡＡＡクライアント識別子オプションをも含む。ＡＡＡクライアント識別子オプションおよびＥＡＰ ＩＤメッセージは、双方ともユーザのＮＡＩ（ＩＭＳＩ＠アドレス体系）を含む。
【０１２３】
ステップ５‐Ｃにおいて、ＨＡは、ＡＡＡクライアント識別子オプションに含まれるＮＡＩからＡＳのアドレスを（必要な場合はＤＮＳを使用して）導出し、ＡＡＡ要求（ＡＲ）メッセージをＡＳに送信する。ＡＲは、ステップ５‐ＢのＡＡＡクライアント識別子オプション内で受信したＥＡＰ ＩＤメッセージ（ＥＡＰペイロード属性において）およびＮＡＩ（ユーザ名属性において）を含む。
【０１２４】
ステップ５‐Ｄにおいて、ＡＳは、ステップＣにおけるＡＲメッセージを受けて、以下を実行する。
・ Ｒ‐ＵＩＭ認証手順の開始を示すＥＡＰ要求／Ｒ‐ＵＩＭ／要求開始メッセージを作成する。これを実行するため、ＡＳはＡｕＣ（認証センター）とも連絡する。
・ ＥＡＰ要求‐ＵＩＭ／開始（ＥＡＰペイロード属性において）と、ユーザを（ユーザ名属性において）識別するＮＡＩとを含むＡＡＡ回答（ＡＡ）メッセージを、ＨＡへ送信する。
【０１２５】
ステップ５‐Ｅにおいて、ＨＡは、組み込みデータオプションにＥＡＰ要求／Ｒ‐ＵＩＭ／開始を含むと共にＡＡＡクライアント識別子オプション含む、ＡＡＡ応答メッセージ（ＲＰ１）を端末へ送信する。ＡＡＡクライアント識別子オプションはユーザを識別するＮＡＩを含む。
【０１２６】
ステップ５‐Ｆにおいて、端末は、ＮＡＩ（ＩＭＳＩ＠アドレス体系）を含むＡＡＡクライアント識別子オプションおよびＥＡＰ応答／Ｒ‐ＵＩＭ／開始メッセージを運ぶＡＡＡ組み込みデータオプションを含むＡＡＡ要求メッセージ（ＲＱ２）を送信する。ＥＡＰ応答／Ｒ‐ＵＩＭ／開始の理由フィールドは、セッションキーがホーム登録保護に使用されることを示す２（バイナリ１０）に設定される（ＣＡＶＥ認証はステップＩの後に実行され、ステップＭの後、保護モビリティヘッダーのためＨＡによりＩｐｓｅｃセキュリティアソシエーションが作成される）。
【０１２７】
ステップ５‐Ｇにおいて、ＨＡは、ＡＡＡクライアント識別子オプションに含まれるＮＡＩからＡＳのアドレスを（必要な場合はＤＮＳを使用して）導出し、ＡＡＡ要求（ＡＲ）メッセージをＡＳに送信する。ＡＲは、ステップＦのＡＡＡクライアント識別子オプション内で受信したような、ＥＡＰ応答／Ｒ‐ＵＩＭ／開始メッセージおよびＮＡＩを（ベンダー固有Ｒａｄｉｕｓ属性フィールドにおいて）含む。
【０１２８】
ステップ５‐Ｈにおいて、ＡＳは、ステップＧにおけるＡＲメッセージを受けて、以下を実行する。
・ ＮＡＩのＩＭＳＩ部分に基づき、ＡＳはユーザのための認証情報を有するＡｕＣを識別する。
・ 必要な数だけのＣａｖｅ認証トリプレットを要求し、ＡｕＣから得る。これは、ＣＡＶＥアルゴリズムのキー長さおよび使用されるＩＰｓｅｃサイファプロファイルＩＤ（ＩＫＥ（インターネットキーエクスチェンジ）バージョン２において定義されているもののひとつ）により決定される。このプロファイルＩＤはＥＡＰパケットで通信される。
・ 例えば、このＥＡＰ‐Ｒ‐ＵＩＭのために、上記で参照した文書Ｈ．Ｈａｖｅｒｉｎｅｎの「ＥＡＰ ＳＩＭ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（作業中）」インターネットドラフト（ｄｒａｆｔ−ｈａｖｅｒｉｎｅｎ−ｐｐｐｅｘｔ−ｅａｐ−ｓｉｍ−１０．ｔｘｔ）、インターネットエンジニアリングタスクフォース（２００３年２月）に明記されている、値ＭＡＣ＿ＲＡＮＤおよびＭＡＣ＿ＡＵＴＨＲを、ＡＴ＿ＲＡＮＤおよびＡＴ＿ＭＡＣとして計算する。
・ 後の使用のために、値ＭＡＣ＿ＡＵＴＨＲを格納する。
・ ＭＡＣ＿ＲＡＮＤ値および２つのＲＡＮＤ値（認証トリプレットから得たもの）を含むＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジメッセージを作成する。
・ ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジおよびユーザを（ベンダー固有Ｒａｄｉｕｓ属性フィールドにおいて）識別するＮＡＩを含む、ＡＡＡ回答（ＡＡ）メッセージをＨＡへ送信する。
【０１２９】
ステップ５‐Ｉにおいて、ＨＡは、ＡＡＡ組み込みデータオプションにＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジを含むＡＡＡ応答メッセージ（ＲＰ２）、ＮＡＩを含むＡＡＡクライアント識別子オプションを送信する。
【０１３０】
ステップ５‐Ｊにおいて、端末は、ステップ５‐ＩにおけるＡＡＡ応答を受けて、以下を実行する。
・ Ｒ‐ＵＩＭを使用してＡＵＴＨＲ／ＡＵＴＨＵの２つの値を計算し、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジ内でＲ‐ＵＩＭモジュールにおけるＲｕｎ＿ＣＡＶＥアルゴリズムに対するインプットとして受信した２つのＲＮＡＤ値を得る。
・ 例えば、上記で参照した文書Ｈ．Ｈａｖｅｒｉｎｅｎの「ＥＡＰ ＳＩＭＡｕｔｈｅｎｔｉｃａｔｉｏｎ（作業中）」インターネットドラフト（ｄｒａｆｔ−ｈａｖｅｒｉｎｅｎ−ｐｐｐｅｘｔ−ｅａｐ−ｓｉｍ−１０．ｔｘｔ）、インターネットエンジニアリングタスクフォース（２００３年２月）に明記されている、値ＭＡＣ＿ＲＡＮＤおよびＭＡＣ＿ＡＵＴＨＲを、ＡＴ＿ＲＡＮＤおよびＡＴ＿ＭＡＣとして計算する。
・ ＭＡＣ＿ＲＡＮＤ値を、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジ内で受信した値と比較する。値が一致する場合、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジメッセージの認証は成功であり、そうでない場合、そのメッセージの認証は失敗する。
・ ＡＡＡクライアント識別子オプション（ＩＭＳＩ＠アドレス体系の形をとるＮＡＩ）およびＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジをＡＡＡ組み込みデータオプションに含むＡＡＡ要求メッセージ（ＲＱ３）をＨＡへ送信する。ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジメッセージは、計算されたＭＡＣ＿ＡＵＴＨＲ値を含む。
【０１３１】
ステップ５‐Ｋにおいて、ＨＡは、ＡＲメッセージを（ＮＡＩにより識別された）ＡＳに送信する。ＡＲメッセージは、ＡＡＡ要求のＡＡＡクライアント識別子オプションにおいて受信したものとしてＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジおよびＮＡＩを（ベンダー固有Ｒａｄｉｕｓ属性フィールドにおいて）含む。
【０１３２】
ステップ５‐Ｌにおいて、ＡＳは、ステップＫにおけるＡＲメッセージを受けて、以下を実行する。
・ ステップ５‐Ｄにおいて計算されたＭＡＣ＿ＡＵＴＨＲ値を、ＥＡＰ要求／Ｒ‐ＵＩＭ／チャレンジに含まれるＭＡＣ＿ＡＵＴＨＲ値と比較する。値が一致する場合、ＣＡＶＥ認証は成功であり、そうでない場合、認証は失敗する。
・ ユーザを（Ｒａｄｉｕｓ属性フィールドにおいて）識別するＮＡＩ，認証の成功（ＡＡにおける応答メッセージ属性）または失敗（アクセス拒否メッセージにおける応答メッセージ属性）を示す結果コード，およびキー応答（サイファプロファイルＩＤ，キー，存続期間）を含む、ＡＡメッセージをＨＡへ送信する。
【０１３３】
ステップ５‐Ｍにおいて、ＨＡは、ステップ５‐ＬにおけるＡＡメッセージを受けて、ＣＡＶＥ認証が成功したか否かを知る。認証が成功した場合、ＨＡはＡＡＡ応答メッセージ（ＲＰ３）をＳＵＣＣＥＳＳ（値０）を示すように設定されたコードフィールドとともに端末へ送信する。端末がこのメッセージを受信すると、ＯＷＬＡＮホーム登録認証およびキーイングは終了である。Ｒ‐ＵＩＭ認証が成功した場合、ＨＡは、
【０１３４】
・ Ｍｏｂｉｌｅ ＩＰｖ４アプリケーションに関しては、Ｒｕｎ＿ＣＡＶＥアルゴリズムをＲＵＩＭのために実行した際に得られたキー材料から適切なＭｏｂｉｌｅ ＩＰｖ４状態へのＭＮ‐ＨＡ認証拡張に使用されるバインディングセキュリティアソシエーション（ＢＳＡ）を必ず入力する。
・ Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに関しては、Ｒｕｎ＿ＣＡＶＥアルゴリズムをＲ‐ＵＩＭにおいて実行した際に得られたキー材料からＳＡＤＢのための２つのＩＰＳｅｃセキュリティアソシエーションを必ず入力する。これらのＳＡ（セキュリティアソシエーション）は、着信および発信登録（ＭＩＰｖ４）またはモビリティヘッダー（ＭＩＰｖ６）パケットのために、端末および使用されるＩＰｓｅｃサイファプロファイルＩＤにより識別されるようなその他のパラメータによって構成されている。この可能性のある作用は、ＩＰｓｅｃモジュールのＰｆｋｅｙインターフェイスを使用し、従ってＲ‐ＵＩＭキーイングデーモンとＩＰｓｅｃモジュールとの間にいかなる特別なインターフェイスも必要としない。
【０１３５】
ステップ５Ｎにおいて、端末は、Ｍｏｂｉｌｅ ＩＰｖ４アプリケーションに関し、キー材料から作成されるように、ＢＳＡのものを使用して、Ｍｏｂｉｌｅ‐Ｈｏｍｅ認証拡張をＭｏｂｉｌｅ ＩＰｖ４登録要求（ＲＲＥＱ）の中へ形成するであろう。ＨＡは、ＲＲＥＱのメッセージ認証を実行する際、対応するＢＳＡをＭＮ‐ＨＡ認証拡張に対して自動的に適用するであろう。
【０１３６】
さらにステップ５‐Ｎにおいて、Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに関しては、ＩＰＳｅｃセキュリティアソシエーションが入力されたＲ‐ＵＩＭが、送信されたパケットに自動的に適用されるよう、端末がＩＰＳｅｃで保護された対応付け更新をＨＡへ送信するであろう。ＨＡがパケットを受信すると、そのＩＰＳｅｃモジュールはＳＡがもう着信するモビリティヘッダーパケットに適用できることを自動的に知る。このパケットはＭｏｂｉｌｅ ＩＰｖ６ ＨＯＴＩ（ホーム試験開始）または対応付け更新（ＢＵ）メッセージであってよい。
【０１３７】
ステップ５‐Ｏにおいて、ＨＡは、Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに対し、受信したキー材料から作成されるように、Ｍｏｂｉｌｅ‐Ｈｏｍｅ認証拡張を、ＢＳＡのものを使用して、構築されたＭｏｂｉｌｅ ＩＰｖ４登録応答（ＲＲＥＰ）へ適用するだろう。次いで端末は、ＲＲＥＰのメッセージ認証を実行する際、対応するＢＳＡをＭＮ‐ＨＡ認証拡張に対し自動的に適用するであろう。
【０１３８】
さらに、Ｍｏｂｉｌｅ ＩＰｖ６アプリケーションに関しては、ステップ５‐Ｏにおいて、ＨＡのＩＰＳｅｃモジュールは、ＳＡが入力されたＲ−ＵＩＭを使用して送信されたＢａｃｋ（結合確認）メッセージを自動的に保護するであろう。次いで、ＩＰＳｅｃで保護されたモビリティヘッダーパケットをＨＡから受信すると、端末は自動的にＩＰＳｅｃセキュリティアソシエーションが入力されたＲ‐ＵＩＭを、ステップＮで使用されたものと逆方向に適用する。
【０１３９】
これは、モビリティシ・グナリング保護アプリケーションプロトコルのフローをうまく完了させる。Ｍｏｂｉｌｅ ＩＰ／ＩＰｖ６ホーム登録以外のアプリケーションでは、この種の手順を任意のＩＰｓｅｃＳＡを入力するために使用することができる。
【０１４０】
本発明は、上記の実施形態において説明したように、交換にかかわる様々なネットワークエンティティを実行することによって、ソフトウェアまたは組み込みハードウェアシステム、またはチップ要素において実施されることができる。端末における実装の重要な機能性は、標準Ｒ‐ＵＩＭ機能のためのＡＰＩへのアクセス、およびカプセル化されたアドレスを含む任意ＩＰパケットを構成するための能力である。アクセスコントローラにおいて、重要な機能はパケットカプセル化および、ＵＤＰまたはＩＣＭＰｖ６等のアクセスＡＡＡメッセージおよびＲＡＤＩＵＳまたはＤＩＡＭＥＴＥＲメッセージ等のコアＡＡＡメッセージへのカプセル開放、例えばＮＡＳＲＥＱアプリケーションから（例えば、Ｐ．Ｃａｌｈｏｕｎ、Ｗ．Ｂｕｌｌｅｙ、Ａ．Ｒｕｂｅｎｓ、Ｊ．Ｈａａｇ、Ｇ．Ｚｏｒｎ．Ｄｉａｍｅｔｅｒ ＮＡＳＲＥＱ Ａｐｐｌｉｃａｔｉｏｎ（進行中）、インターネットドラフト（ｄｒａｆｔ−ｉｅｔｆ−ａａａ−ｄｉａｍｅｔｅｒ−ｎａｓｒｅｑ−０８．ｔｘｔ）、インターネットエンジニアリングタスクフォース（２００１年１１月）に記載されているように）適合することによるものである。また、本発明は、この方法のためのアクセス認証サービスポイントがどこに位置するかに応じて、アクセスルータ、ネットワークサーバ、またはＰＤＳＮの汎用パケットフィルタリング機能を再利用する可能性がある。
【０１４１】
第二の実施形態の実装における最良の形態の概要を図１に示す。最良の形態では、ネットワークやＲ‐ＵＩＭハードウェア（第二の実施形態の場合）とのインターフェイスを備えるモバイル機器において、端末機能性を実装することであろう。この機能性は、ＩＰアクセスルータ、アクセスサーバ、またはモバイル機器が無線ネットワークを通じて接続されている基地局によって、ＧＲＡＳＰプロトコルメッセージを送受信するであろう。モバイル機器は、入力情報（チャレンジまたはＲＡＮＤ）を認証アルゴリズムに提供するネットワーク要素からメッセージを受信すると、ＣＡＶＥアルゴリズムを実行するために、Ｒ‐ＵＩＭにアクセスするであろう。これは、局所的に、応答およびネットワークと共有の秘密を生成する。
【０１４２】
ネットワークにおいて、本発明は、カプセル化されたメッセージをモバイル装置から受け取り、オペレータのネットワークに送り返すためにそれらをサーバベースのＲＡＤＩＵＳプロトコルにおいて再カプセル化するような、アクセスルータ／ＷＬＡＮ基地局に追加されるソフトウェアによって実施されることができる。追加のソフトウェアを伴う任意のＭｏｂｉｌｅ ＩＰホームエージェントがオペレータのネットワークに加えられると共に、ＲＡＤＩＵＳとＣＤＭＡ２０００ ＳＳ７メッセージの間のメッセージを翻訳するために、追加的にゲートウェイ（ＡＳまたはＡＡＡＨ）が使用される。このように、ＣＡＶＥプロトコルのセキュリティは、ＭＥおよびＡｕＣ／ＨＬＲの領域に制限され、ＣＤＭＡ２０００ネットワークにおいて現存するインフラストラクチャは認証および認可のため、また場合により請求およびアカウンティングのためにさえ、再利用される。従って、ＩＰまたはＣＤＭＡ２０００ネットワークへの変更は、まったく必要ないか、最小限ですむ。
【０１４３】
機能的な実装は、実装の仕様に応じて、例えばＯＳ（オペレーションシステム）カーネル、ユーザレベルのソフトウェア等、オペレーションシステムの様々な場所で生じる可能性がある。
【０１４４】
以下、図６Ａから６Ｃを参照し関連するネットワーク要素を簡単に説明する。上記の実施形態の説明に必要な手段のみを説明することが知られている。
【０１４５】
図６Ａは、上記の実施形態に記載のアクセスコントローラ（ＡＣ）を示す。アクセスコントローラ１は、上述の開始メッセージが中でカプセル化された認証メッセージを受信する受信手段１ａを備える。さらにアクセスコントローラは処理手段１ｂを備える。処理手段１ｂは、カプセル化された開始メッセージ（例えば、上述のようにクライアントタイプ、ユーザＩＤ、およびコアアドレス情報を含むクライアント識別子オプションメッセージおよびＥＡＰ（拡張認証プロトコル）ＩＤオプションメッセージ）を読み出す。カプセル化されたメッセージは、その後、転送手段１ｃにより、そのカプセル化されたメッセージ内において識別された認証サーバへ転送される。
【０１４６】
図６Ｂはモバイル端末２を示す。モバイル端末は、加入者機器の一例にすぎないことに注意されたい。モバイル端末２は、少なくともひとつのネットワークアクセスタイプを示す情報メッセージ（すなわち上述のルータ通知ＲＡ）を受けて、ネットワークアクセスタイプを判定する、判定手段２ａを備える。さらにモバイル端末３は、上述のような開始メッセージを作成する作成手段２ｂを備える。移動局２のカプセル化手段２ｃは、情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内において、開始メッセージをカプセル化し、移動局２の送信手段２ｄは、開始メッセージをアクセスコントローラへ送信する。
【０１４７】
図６ｃは上記の実施形態において使用されるようなルータ３を示す。ルータ３は、上述した情報メッセージ、すなわちルータ通知を作成する作成手段３ａを備える。ルータ３の送信手段３ｂは、情報メッセージを加入者機器へ送信する。ルータ３およびアクセスコントローラ１はひとつのユニット内に配置されてもよいことが知られている（上述の実施形態に記載のとおり）。
【０１４８】
本発明は、上述の実施形態に限定されるものではなく、特許請求の範囲内において変化してもよい。
【０１４９】
例えば、上記の実施形態は、ＵＳＩＭを使用するＥＡＰ‐ＡＫＡ認証機構およびＣＡＶＥアルゴリズムに基づくＲ‐ＵＩＭを使用する認証が両方使用されるように、自由に結合されることができる。
【０１５０】
モバイル機器およびアクセスネットワークの間のプロトコルはＵＤＰ、ＩＣＭＰ、ＩＣＭＰｖ６等のネットワーク層プロトコルまたはＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、およびブルートゥースプロファイル等のリンク層プロトコルのうち少なくともひとつを備えてよい。
【０１５１】
さらに、上述した実施形態には以下のバリエーションが存在する。
【０１５２】
１．ＥＡＰ‐ＳＩＭ方法の再利用
（例えば上述のように第二の実施形態に関連して）認証機構がＲ‐ＵＩＭを使用する方法は、ＥＡＰ‐ＳＩＭと呼ばれるＳＩＭのための方法と同じプロトコルカプセル化に組み込まれる。この使用法では、ＣＡＶＥアルゴリズムによる、Ｒ‐ＵＩＭに基づく認証の運搬のためのＥＡＰ‐ＳＩＭプロトコルを再利用している。
【０１５３】
ＥＡＰ‐ＳＩＭの代替使用の指示は、ＥＡＰ‐ＳＩＭプロトコルにおいて予備フィールドを使用して示されてよく、あるいは追加の属性であってよく、それをＡＴ‐Ｒ‐ＵＩＭと呼ぶ。
【０１５４】
２．スマートカードアルゴリズムのためのネットワーク側の終端位置
スマートカード（ＣＡＶＥまたはＡＫＡ秘密アルゴリズム）で動作するものに対応するアルゴリズムのネットワーク側の終端ポイントは、原理上、ＨＬＲ／ＡｕＣにあるか、ホームＡＡＡサーバＡＡＡＨ（図１）内で同一場所に位置する可能性がある。前者の場合には、Ｇ＿ｈと呼ばれるインターフェイスが存在し、それによってホームＡＡＡサーバはトリプレット／クインテットを表すダイアログをＧ＿ｈ上の携帯電話ネットワークプロトコルを使用して関連するスマートカードアルゴリズムに伝播する。
【０１５５】
さらに、モバイル端末または機器は、加入者端末の一例にすぎないことが知られている。「モバイル」という用語は、モバイル端末が無線リンクを経由してネットワークに接続されていることだけを意味するのではなく、例えば固定ケーブルを経由して異なるネットワークアクセス手段に接続される可能性がある端末をも意味する。例えばこれは、ホテルの部屋や電車等の中で固定ネットワークに接続される可能性のあるコンピュータのような、固定ネットワーク端末に接続可能なコンピュータを含んでよい。
【図面の簡単な説明】
【０１５６】
【図１】本発明の実施形態に従うＣＤＭＡ２０００マルチアクセスネットワーク参照モデルを示す。
【図２Ａ】本発明の第一の実施形態に従ったシグナルフローを示す。
【図２Ｂ】本発明の第一の実施形態に従ったシグナルフローを示す。
【図３Ａ】本発明の第一の実施形態の第二例に従ったシグナルフローを示す。
【図３Ｂ】本発明の第一の実施形態の第二例に従ったシグナルフローを示す。
【図４Ａ】本発明の第二の実施形態の第一例に従ったシグナルフローを示す。
【図４Ｂ】本発明の第二の実施形態の第一例に従ったシグナルフローを示す。
【図５Ａ】本発明の第二の実施形態の第二例に従ったシグナルフローを示す。
【図５Ｂ】本発明の第二の実施形態の第二例に従ったシグナルフローを示す。
【図６】図６Ａ〜Ｃは、それぞれ本発明の実施形態に従って使用可能なアクセスコントローラ、移動局、ルータを示す。
【特許請求の範囲】
【請求項１】
ネットワークサービスを認証および認可するためのシステムであって、該システムはモバイル機器を有し、
該モバイル機器は、少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてネットワークアクセスタイプを判定し、
少なくともユーザＩＤを含む開始メッセージを作成し、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するよう構成され、
さらに該システムは、カプセル化された前記メッセージを前記モバイル機器から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別される認証サーバに転送するアクセスコントローラをさらに備えるシステム。
【請求項２】
前記情報メッセージを発行するためのルータをさらに備え、前記情報メッセージがルータ通知を含む、請求項１に記載のシステム。
【請求項３】
前記情報メッセージが拡張認証プロトコル（ＥＡＰ）サポートを示す、請求項１に記載のシステム。
【請求項４】
前記情報メッセージが、前記モバイル機器がネットワークに入る際に発行される、請求項１に記載のシステム。
【請求項５】
前記開始メッセージが、クライアント識別子オプションメッセージおよび拡張認証プロトコルサポート識別子オプションメッセージを含み、前記メッセージが、クライアントタイプ、ユーザＩＤ、コアアドレス情報のうち少なくともひとつに関する情報を含む、請求項１に記載のシステム。
【請求項６】
前記モバイル機器および前記アクセスネットワークの間のプロトコルが、ＵＤＰ、ＩＣＭＰｖ６、ＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、およびブルートゥースプロファイルのうち少なくともひとつを備える、請求項１に記載のシステム。
【請求項７】
適用される認証機構が拡張認証プロトコル（ＥＡＰ）を備える、請求項１に記載のシステム。
【請求項８】
適用される認証機構が、携帯電話認証および音声暗号化（ＣＡＶＥ）アルゴリズムを適用するリムーバブルユーザ識別モジュール（Ｒ−ＵＩＭ）を使用する認証機構である、請求項１に記載のシステム。
【請求項９】
前記アクセスコントローラが、前記モバイル機器のホームエージェントに提供される、請求項１に記載のシステム。
【請求項１０】
ネットワークサービスを認証または認可するための方法であって、前記ネットワークはモバイル機器および認証制御機能を備え、
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けて前記モバイル機器によりネットワークアクセスタイプを判定するステップと、
少なくともユーザＩＤを含む開始メッセージを作成するステップと、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するステップと、
アクセスコントローラにより、カプセル化されたメッセージを前記モバイル機器から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別される認証サーバに転送するステップと、
を含む方法。
【請求項１１】
前記ネットワークが前記情報メッセージを発行するルータをさらに含み、前記情報メッセージがルータ通知を含む、請求項１０に記載の方法。
【請求項１２】
前記情報メッセージが拡張認証プロトコル（ＥＡＰ）サポートを示す、請求項１０に記載の方法。
【請求項１３】
前記情報メッセージが、前記モバイル機器が前記ネットワークに入る際に発行される、請求項１０に記載の方法。
【請求項１４】
前記開始メッセージが、クライアント識別子オプションメッセージおよび拡張認証プロトコルサポート識別子オプションメッセージを含み、これらがクライアントタイプ、ユーザＩＤ、コアアドレス情報のうち少なくともひとつに関する情報を含む、請求項１０に記載の方法。
【請求項１５】
前記モバイル機器および前記アクセスネットワークの間のプロトコルが、ＵＤＰ、ＩＣＭＰｖ６、ＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、およびブルートゥースプロファイルのうち少なくともひとつを備える、請求項１０に記載の方法。
【請求項１６】
適用される認証機構が拡張認証プロトコル（ＥＡＰ）を備える、請求項１０に記載の方法。
【請求項１７】
適用される認証機構が、携帯電話認証および音声暗号化（ＣＡＶＥ）アルゴリズムを適用するリムーバブルユーザ識別モジュール（Ｒ−ＵＩＭ）を使用する認証機構を備える、請求項１０に記載の方法。
【請求項１８】
前記アクセスコントローラが、前記モバイル機器のホームエージェント（ＨＡ）に提供される、請求項１に記載の方法。
【請求項１９】
ネットワークサービスを認証および認可するためのシステムであって、
モバイル機器手段であって、少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてネットワークアクセスタイプを判定し、少なくともユーザＩＤを含む開始メッセージを作成し、前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するためのモバイル機器手段と、
カプセル化された前記メッセージを前記モバイル機器手段から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するためのアクセスコントローラと、
を備えるシステム。
【請求項２０】
ネットワークサービスを認証および認可するためのシステムであって、前記ネットワークはモバイル機器および認証制御機能を備え、前記モバイル機器は、
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けて前記モバイル機器によりネットワークアクセスタイプを判定するための判定手段と、
少なくともユーザＩＤを含む開始メッセージを作成するための作成手段と、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するためのカプセル化手段と、
カプセル化された前記メッセージを前記モバイル機器から読み出すための読み出し手段、および、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別される認証サーバに転送するための転送手段を備えるアクセスコントローラ手段と、
を備える、システム。
【請求項２１】
アクセスコントロール機器であって、
内部で認証メッセージがカプセル化されている開始メッセージを受信するための受信手段と、
カプセル化されたメッセージを読み出すための処理手段と、
前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別される認証サーバに転送するための転送手段と、
を備えるアクセスコントロール機器。
【請求項２２】
前記開始メッセージが、クライアント識別子オプションメッセージおよび拡張認証プロトコルサポート識別子オプションメッセージを含み、前記メッセージが、クライアントタイプ、ユーザＩＤ、コアアドレス情報のうち少なくともひとつに関する情報を含む、請求項２１に記載のアクセスコントロール機器。
【請求項２３】
前記アクセスコントローラが、前記開始メッセージを送信したモバイル機器のホームエージェントに提供される、請求項２１に記載のアクセスコントロール機器。
【請求項２４】
情報メッセージを、少なくともひとつのネットワークアクセスタイプを示す加入者機器へ送信するための送信手段をさらに備える、請求項２１に記載のアクセスコントロール機器。
【請求項２５】
前記情報メッセージがルータ通知を含む、請求項２４に記載のアクセスコントロール機器。
【請求項２６】
前記情報メッセージが拡張認証プロトコル（ＥＡＰ）サポートを示す、請求項２４に記載のアクセスコントロール機器。
【請求項２７】
前記情報メッセージが、前記モバイル機器がネットワークに入る際に発行される、請求項２４に記載のアクセスコントロール機器。
【請求項２８】
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてネットワークアクセスタイプを判定するための判定手段と、
少なくともユーザＩＤを含む開始メッセージを作成するための作成手段と、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するためのカプセル化手段と、
前記開始メッセージをアクセスコントロール機器に送信するための送信手段と、
を備える加入者機器。
【請求項２９】
前記加入者機器がモバイル機器である、請求項２８に記載の加入者機器。
【請求項３０】
前記情報メッセージが拡張認証プロトコル（ＥＡＰ）サポートを示す、請求項２８に記載の加入者機器。
【請求項３１】
前記情報メッセージが、前記加入者機器がネットワークに入る際に発行される、請求項２８に記載の加入者機器。
【請求項３２】
前記開始メッセージが、クライアント識別子オプションメッセージおよび拡張認証プロトコルサポート識別子オプションメッセージを含み、前記メッセージが、クライアントタイプ、ユーザＩＤ、コアアドレス情報のうち少なくともひとつに関する情報を含む、請求項２８に記載の加入者機器。
【請求項３３】
適用される認証機構が、携帯電話認証および音声暗号化（ＣＡＶＥ）アルゴリズムを適用するリムーバブルユーザ識別モジュール（Ｒ−ＵＩＭ）を使用する認証機構である、請求項２８に記載の加入者機器。
【請求項３４】
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを作成するための作成手段と、
前記情報メッセージを加入者機器に送信するための送信手段と、
を備えるネットワークにおけるルータ機器。
【請求項３５】
前記情報メッセージがルータ通知を含む、請求項３４に記載のルータ機器。
【請求項３６】
前記情報メッセージが拡張認証プロトコル（ＥＡＰ）サポートを示す、請求項３４に記載のルータ機器。
【請求項３７】
前記情報メッセージが、前記モバイル機器がネットワークに入る際に発行される、請求項３４に記載のルータ機器。
【請求項３８】
記ルータ機器がアクセスコントロール機器の一部である、請求項３４に記載のルータ機器。
【請求項１】
ネットワークサービスを認証および認可するためのシステムであって、該システムはモバイル機器を有し、
該モバイル機器は、少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてネットワークアクセスタイプを判定し、
少なくともユーザＩＤを含む開始メッセージを作成し、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するよう構成され、
さらに該システムは、カプセル化された前記メッセージを前記モバイル機器から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別される認証サーバに転送するアクセスコントローラをさらに備えるシステム。
【請求項２】
前記情報メッセージを発行するためのルータをさらに備え、前記情報メッセージがルータ通知を含む、請求項１に記載のシステム。
【請求項３】
前記情報メッセージが拡張認証プロトコル（ＥＡＰ）サポートを示す、請求項１に記載のシステム。
【請求項４】
前記情報メッセージが、前記モバイル機器がネットワークに入る際に発行される、請求項１に記載のシステム。
【請求項５】
前記開始メッセージが、クライアント識別子オプションメッセージおよび拡張認証プロトコルサポート識別子オプションメッセージを含み、前記メッセージが、クライアントタイプ、ユーザＩＤ、コアアドレス情報のうち少なくともひとつに関する情報を含む、請求項１に記載のシステム。
【請求項６】
前記モバイル機器および前記アクセスネットワークの間のプロトコルが、ＵＤＰ、ＩＣＭＰｖ６、ＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、およびブルートゥースプロファイルのうち少なくともひとつを備える、請求項１に記載のシステム。
【請求項７】
適用される認証機構が拡張認証プロトコル（ＥＡＰ）を備える、請求項１に記載のシステム。
【請求項８】
適用される認証機構が、携帯電話認証および音声暗号化（ＣＡＶＥ）アルゴリズムを適用するリムーバブルユーザ識別モジュール（Ｒ−ＵＩＭ）を使用する認証機構である、請求項１に記載のシステム。
【請求項９】
前記アクセスコントローラが、前記モバイル機器のホームエージェントに提供される、請求項１に記載のシステム。
【請求項１０】
ネットワークサービスを認証または認可するための方法であって、前記ネットワークはモバイル機器および認証制御機能を備え、
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けて前記モバイル機器によりネットワークアクセスタイプを判定するステップと、
少なくともユーザＩＤを含む開始メッセージを作成するステップと、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するステップと、
アクセスコントローラにより、カプセル化されたメッセージを前記モバイル機器から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別される認証サーバに転送するステップと、
を含む方法。
【請求項１１】
前記ネットワークが前記情報メッセージを発行するルータをさらに含み、前記情報メッセージがルータ通知を含む、請求項１０に記載の方法。
【請求項１２】
前記情報メッセージが拡張認証プロトコル（ＥＡＰ）サポートを示す、請求項１０に記載の方法。
【請求項１３】
前記情報メッセージが、前記モバイル機器が前記ネットワークに入る際に発行される、請求項１０に記載の方法。
【請求項１４】
前記開始メッセージが、クライアント識別子オプションメッセージおよび拡張認証プロトコルサポート識別子オプションメッセージを含み、これらがクライアントタイプ、ユーザＩＤ、コアアドレス情報のうち少なくともひとつに関する情報を含む、請求項１０に記載の方法。
【請求項１５】
前記モバイル機器および前記アクセスネットワークの間のプロトコルが、ＵＤＰ、ＩＣＭＰｖ６、ＩＥＥＥ８０２．１ｘ、ＩＥＥＥ８０２．１１ｉ、およびブルートゥースプロファイルのうち少なくともひとつを備える、請求項１０に記載の方法。
【請求項１６】
適用される認証機構が拡張認証プロトコル（ＥＡＰ）を備える、請求項１０に記載の方法。
【請求項１７】
適用される認証機構が、携帯電話認証および音声暗号化（ＣＡＶＥ）アルゴリズムを適用するリムーバブルユーザ識別モジュール（Ｒ−ＵＩＭ）を使用する認証機構を備える、請求項１０に記載の方法。
【請求項１８】
前記アクセスコントローラが、前記モバイル機器のホームエージェント（ＨＡ）に提供される、請求項１に記載の方法。
【請求項１９】
ネットワークサービスを認証および認可するためのシステムであって、
モバイル機器手段であって、少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてネットワークアクセスタイプを判定し、少なくともユーザＩＤを含む開始メッセージを作成し、前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するためのモバイル機器手段と、
カプセル化された前記メッセージを前記モバイル機器手段から読み出し、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別された認証サーバに転送するためのアクセスコントローラと、
を備えるシステム。
【請求項２０】
ネットワークサービスを認証および認可するためのシステムであって、前記ネットワークはモバイル機器および認証制御機能を備え、前記モバイル機器は、
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けて前記モバイル機器によりネットワークアクセスタイプを判定するための判定手段と、
少なくともユーザＩＤを含む開始メッセージを作成するための作成手段と、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するためのカプセル化手段と、
カプセル化された前記メッセージを前記モバイル機器から読み出すための読み出し手段、および、前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別される認証サーバに転送するための転送手段を備えるアクセスコントローラ手段と、
を備える、システム。
【請求項２１】
アクセスコントロール機器であって、
内部で認証メッセージがカプセル化されている開始メッセージを受信するための受信手段と、
カプセル化されたメッセージを読み出すための処理手段と、
前記カプセル化されたメッセージを前記カプセル化されたメッセージにおいて識別される認証サーバに転送するための転送手段と、
を備えるアクセスコントロール機器。
【請求項２２】
前記開始メッセージが、クライアント識別子オプションメッセージおよび拡張認証プロトコルサポート識別子オプションメッセージを含み、前記メッセージが、クライアントタイプ、ユーザＩＤ、コアアドレス情報のうち少なくともひとつに関する情報を含む、請求項２１に記載のアクセスコントロール機器。
【請求項２３】
前記アクセスコントローラが、前記開始メッセージを送信したモバイル機器のホームエージェントに提供される、請求項２１に記載のアクセスコントロール機器。
【請求項２４】
情報メッセージを、少なくともひとつのネットワークアクセスタイプを示す加入者機器へ送信するための送信手段をさらに備える、請求項２１に記載のアクセスコントロール機器。
【請求項２５】
前記情報メッセージがルータ通知を含む、請求項２４に記載のアクセスコントロール機器。
【請求項２６】
前記情報メッセージが拡張認証プロトコル（ＥＡＰ）サポートを示す、請求項２４に記載のアクセスコントロール機器。
【請求項２７】
前記情報メッセージが、前記モバイル機器がネットワークに入る際に発行される、請求項２４に記載のアクセスコントロール機器。
【請求項２８】
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを受けてネットワークアクセスタイプを判定するための判定手段と、
少なくともユーザＩＤを含む開始メッセージを作成するための作成手段と、
前記情報メッセージにおいて識別されるアクセスネットワークと互換性がある認証メッセージ内に前記開始メッセージをカプセル化するためのカプセル化手段と、
前記開始メッセージをアクセスコントロール機器に送信するための送信手段と、
を備える加入者機器。
【請求項２９】
前記加入者機器がモバイル機器である、請求項２８に記載の加入者機器。
【請求項３０】
前記情報メッセージが拡張認証プロトコル（ＥＡＰ）サポートを示す、請求項２８に記載の加入者機器。
【請求項３１】
前記情報メッセージが、前記加入者機器がネットワークに入る際に発行される、請求項２８に記載の加入者機器。
【請求項３２】
前記開始メッセージが、クライアント識別子オプションメッセージおよび拡張認証プロトコルサポート識別子オプションメッセージを含み、前記メッセージが、クライアントタイプ、ユーザＩＤ、コアアドレス情報のうち少なくともひとつに関する情報を含む、請求項２８に記載の加入者機器。
【請求項３３】
適用される認証機構が、携帯電話認証および音声暗号化（ＣＡＶＥ）アルゴリズムを適用するリムーバブルユーザ識別モジュール（Ｒ−ＵＩＭ）を使用する認証機構である、請求項２８に記載の加入者機器。
【請求項３４】
少なくともひとつのネットワークアクセスタイプを示す情報メッセージを作成するための作成手段と、
前記情報メッセージを加入者機器に送信するための送信手段と、
を備えるネットワークにおけるルータ機器。
【請求項３５】
前記情報メッセージがルータ通知を含む、請求項３４に記載のルータ機器。
【請求項３６】
前記情報メッセージが拡張認証プロトコル（ＥＡＰ）サポートを示す、請求項３４に記載のルータ機器。
【請求項３７】
前記情報メッセージが、前記モバイル機器がネットワークに入る際に発行される、請求項３４に記載のルータ機器。
【請求項３８】
記ルータ機器がアクセスコントロール機器の一部である、請求項３４に記載のルータ機器。
【図１】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図６】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図６】
【公表番号】特表２００７−５０８６１４（Ｐ２００７−５０８６１４Ａ）
【公表日】平成１９年４月５日（２００７．４．５）
【国際特許分類】
【出願番号】特願２００６−５３０７５４（Ｐ２００６−５３０７５４）
【出願日】平成１６年１０月１２日（２００４．１０．１２）
【国際出願番号】ＰＣＴ／ＩＢ２００４／００３３１３
【国際公開番号】ＷＯ２００５／０３６８５２
【国際公開日】平成１７年４月２１日（２００５．４．２１）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
【公表日】平成１９年４月５日（２００７．４．５）
【国際特許分類】
【出願日】平成１６年１０月１２日（２００４．１０．１２）
【国際出願番号】ＰＣＴ／ＩＢ２００４／００３３１３
【国際公開番号】ＷＯ２００５／０３６８５２
【国際公開日】平成１７年４月２１日（２００５．４．２１）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
[ Back to top ]