ＥＡＰ拡張（ＥＡＰ−ＥＸＴ）のためのＥＡＰメソッド
【課題】ＥＡＰ機能を拡張するために使用されるＥＡＰメソッドを提供する。
【解決手段】拡張機能はチャネル結合及び再認証を含む。ＥＡＰメソッドはその内部の複数のＥＡＰメソッドの順序実行を可能にもする。
【解決手段】拡張機能はチャネル結合及び再認証を含む。ＥＡＰメソッドはその内部の複数のＥＡＰメソッドの順序実行を可能にもする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線ネットワーク、幾つかの好適実施形態では、ピアとサーバとの間で一貫性維持のために照合されるパラメータをチャネル結合するシステム及び方法に関する。
【背景技術】
【０００２】
ネットワーク及びインターネット（登録商標）プロトコル
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業及び個人へのアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。
【０００３】
ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。
【０００４】
ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれる構成要素に分割される。各パケットは、独立のデータ単位として扱われる。
【０００５】
インターネットなどのネットワークを介した各点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク中の２点間の通信プロセスを７つの階層に分け、各層（レイヤ）は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。７つの機能層を提供するプログラミング及び／又はハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰ及び／又は他のトランスポート及びネットワークプロトコル、並びに他のソフトウェア及びハードウェアの組み合わせである。
【０００６】
通常、上位４層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位３層は、メッセージが装置（ＩＰホスト装置など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。ＯＳＩモデルの各層を以下に列記する。第７層（すなわち、アプリケーション層）は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証及びプライバシが考慮され、データ構文に対する制約条件が識別される層である。第６層（すなわち、プレゼンテーション層）は、例えば、着信及び発信データをあるプレゼンテーション形式から別の形式に変換する層である。第５層（すなわち、セッション層）は、例えば、アプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了させる層である。第４層（すなわち、トランスポート層）は、例えば、エンドツーエンド制御及び誤りチェックなどを管理する層である。第３層（すなわち、ネットワーク層）は、例えば、経路指定や転送などを処理する層である。第２層（すなわち、データリンク層）は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識及び管理などを提供する層である。米国電気電子技術者協会（ＩＥＥＥ）では、データリンク層を、物理層との間のデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うＬＬＣ（論理リンク制御）層という、２つのさらなる副層（サブレイヤ）に細分する。第１層（すなわち、物理層）は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。ＩＥＥＥでは、物理層を、ＰＬＣＰ（物理層収束手順）副層とＰＭＤ（物理媒体依存）副層とに細分する。
【０００７】
無線ネットワーク：
無線ネットワークは、例えば、セルラ及び無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び／又はデータの高速無線伝送を確保するデジタルシステムを含むことができる。一般的なモバイル機器は、次の構成要素の一部又は全部、即ち送受信機（すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機）、アンテナ、プロセッサ、１つ又は複数の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、デジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）及び／又は同種のものを含む。
【０００８】
モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いることができる。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含めることができる。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ標準が存在する。
【０００９】
一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、及び他のモバイル機器の間のリンク、並びにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の名称概念に従って名称付けできる。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）又は一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名称を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器は、ＩＰアドレス及びＩＰ（ネットワーク）名を備えることができる。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、ＢＤＮ、ＢＤＡ、ＩＰアドレス及びＩＰ名などを含むことができる。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名称を指す。
【００１０】
ＩＥＥＥ標準であるＩＥＥＥ８０２．１１は、無線ＬＡＮ及び機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含めることができ、カードなどの別個のハードウェアをインストールすることもできる。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であるか、移動局（ＳＴＡ）であるか、ブリッジであるか、ＰＣＭＣＩＡカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべき要素を含む。
【００１１】
更に、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）が利用できる。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含むことができ、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレス、及びＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を持つことができる。
【００１２】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Wireless Fidelity）機器、ＧＰＲＳ（汎用パケット無線システム）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（移動通信用グローバルシステム）機器、ＥＤＧＥ（Enhanced Data for GSM Evolution）機器、ＴＤＭＡ型（時分割多重接続）機器、又はＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含めることができる。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、ＩＥＥＥ ＭＡＣアドレスを含む、様々な種類のアドレスを含むことができる。
【００１３】
また、無線ネットワークは、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、及び他のモバイルネットワークシステムにおいて見られるメソッド及びプロトコルも関与できる。モバイルＩＰでは、これに、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、これらの一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメントリクエスト（ＲＦＣ）３３４４を参照されたい。（注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。）モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワーク及びこれのサブネット内の機器の現在位置を識別する気付アドレス（ＣｏＡ）を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。
【００１４】
（例えば、モバイルＩＰ外部などの）基本的なＩＰ経路指定において、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、及び／又は転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。一般的なモバイルＩＰ通信の場合、ユーザが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスク及びデフォルトのルータを用いて再構成する必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。
【００１５】
メディア独立の事前認証：
メディア独立の事前認証（ＭＰＡ）は、任意のリンク層を介して、任意のモビリティ管理プロトコルと共に動作する、モバイル支援型の、安全なハンドオーバ最適化方式である。ＭＰＡを用いれば、移動ノードは、候補ターゲットネットワーク（ＣＴＮ）のＩＰアドレスと他の構成パラメータを安全に獲得することができるだけでなく、ＣＴＮに実際に接続する前に、獲得したＩＰアドレスを使ってＩＰパケットを送受信することもできる。これは、移動ノードが、リンク層におけるハンドオーバを実行する前に、任意のモビリティ管理プロトコルの対応付け更新を完了し、新しい気付アドレス（ＣｏＡ）を使用することを可能にする。
【００１６】
ＭＰＡは、任意のリンク層を介して、モバイルＩＰｖ４、モバイルＩＰｖ６、ＭＯＢＩＫＥ、ＨＩＰ、ＳＩＰモビリティなどを含む任意のモビリティ管理プロトコルと共に動作する。ＭＰＡでは、ＩＥＥＥ８０２．１１ｉ事前認証の概念が、上位層で動作するように拡張され、移動端末がそこに移動できるネットワークからのＩＰアドレスの早期獲得と、移動端末がまだ現在のネットワークに接続されている間にネットワークへの事前対応型ハンドオーバとを実行する追加機構を組み込んでいる。
【００１７】
ＭＰＡをサポートする移動ノード（ＭＮ）は、認証エージェント（ＡＡ）との事前認証プロセスを開始する。正常な認証により、ＰＡＮＡ認証エージェント（ＰＡＡ）が、ＡＡとセキュリティアソシエーションを確立することが可能になる。これが、ＩＰアドレスと他の構成パラメータを移動ノードに安全に配信するための構成プロトコルを安全に実行するのに使用される構成エージェント（ＣＡ）と、移動ノードへの事前対応型ハンドオーバトンネルを確立するためのトンネル管理プロトコルを安全に実行するアクセスルータ（ＡＲ）に加わる。この全プロセスが、ＭＮが現在の接続点に接続されるときに実行される。これは、参照によりこれの開示が本明細書に組み込まれる、２００６年３月の「draft-ohba-mobopts-mpa-framework-02.txt」と、２００６年１０月２２日の「draft-ohba-mobopts-mpa-framework-03.txt」で詳細に説明されている。
【００１８】
安全なネットワークアクセスサービスを提供することは、クライアントとアクセスネットワークの認証と許可に基づくアクセス制御を必要とする。クライアントからネットワークへの認証は、実行点を通るトラフィックフローを規制するのに必要とされるパラメータを提供する。クライアントとアクセスネットワークの間で認証メソッドを搬送するプロトコルが必要とされる。
【００１９】
ＰＡＮＡは、ネットワークアクセス認証メソッドのためのリンク層不可知トランスポートを提供する。拡張可能認証プロトコル（ＥＡＰ）［参照により全体が本明細書に組み込まれるRFC3748を参照］は、かかる認証メソッドを提供する。これに関して、ＰＡＮＡは、様々な認証メソッドを搬送することのできるＥＡＰを搬送する。ＩＰより上でのＥＡＰのトランスポートを可能にすることによって、ＥＡＰメソッドとして伝えることができる任意の認証メソッドがＰＡＮＡに利用でき、故に任意のリンク層技術に利用できる。
【００２０】
ＰＡＮＡプロトコル[I-D.ietf-pana-pana]は、アクセスネットワーク内のＰａＣ（ＰＡＮＡクライアント）とＰＡＡ（ＰＡＮＡ認証エージェント）の間でＥＡＰメッセージを伝送する。ＰａＣがモバイル機器であり、これのアプリケーションを実行する間に、あるアクセスネットワークから別のアクセスネットワークに移動することができる場合、このＰａＣが、ハンドオーバ期間中にアプリケーションの性能を低下させずに、シームレスにハンドオーバを行うことは重要である。ＰａＣが新しいアクセスネットワーク内のＰＡＡとＰＡＮＡセッションを確立することをハンドオーバが必要とするとき、ＰＡＮＡセッションを確立する信号は、できるだけ速く完了されるべきである。
【００２１】
ＰＡＮＡプロトコルは、ネットワークアクセスサービスのための認証と許可を行うために、クライアント（ＰａＣ）とサーバ（ＰＡＡ）の間で実行される。このプロトコルのメッセージングは、一連のリクエストとレスポンスを伴い、これらのうちのいくつかが、どちらかの側によって開始できる。各メッセージは、ペイロード内でゼロ以上のＡＶＰを伝送することができる。ＰＡＮＡの主要ペイロードは、認証を実行するＥＡＰである。ＰＡＮＡは、ＰａＣとＰＡＡが、ＥＡＰセッションを確立するのに役立つ。
【００２２】
他の背景情報としてProtocol for Carrying Authentication for Network Access (PANA), Internet Draft of the PANA Working Group of the I.E.T.F., document no. draft-ietf-pana-pana-12, dated August 24, 2006, to D. Forsberg, Y. Ohba, et al.を参照する。この文献の全開示はここに全て開示されているように参照により本明細書に援用される。
【００２３】
ＥＡＰ
（以下に引用する）Aboba, RFC 3748を参照すると、拡張認証プロトコル（ＥＡＰ）の具体的態様が説明されている。ＥＡＰは複数の認証メソッドをサポートする認証フレームワークである。ＥＡＰは一般的にはＩＰを必要としない、ポイントツーポイントプロトコル（ＰＰＰ）又はＩＥＥＥ８０２のような複数のデータリンク層上で直接に実行する。ＥＡＰは二重削除及び再送信のため独自のサポートを備えているが、下位層順の保証に依存する。断片化はＥＡＰ自体内でサポートされないが、個々のＥＡＰメソッドがこれをサポートできる。
【００２４】
ＥＡＰは切換回路だけでなく、専用リンクに使用でき、無線リンクだけでなく有線であってもよい。今まで、ＥＡＰはＰＰＰ[RFC1661]を用いて切換回路又はダイアルアップネットワークを介して接続するホスト及びルータによって実現されていた。それはまたＩＥＥＥ ８０２［ＩＥＥＥ−８０２］を用いてスイッチ及びアクセスポイントによっても実現されていた。ＩＥＥＥ ８０２有線媒体に関するＥＡＰカプセル化が[IEEE-802.1X]に説明されており、ＩＥＥＥ無線ＬＡＮｓに関するカプセル化は[IEEE-802.11i]に開示されている。
【００２５】
ＥＡＰアーチテクチャの利点の１つはその柔軟性にある。ＥＡＰは、特定の認証機構を選択するために用いられ、その際、Authenticatorが使用すべき特定の認証メソッドを決定するためにピアに対しより多くの情報を要求する。各新しい認証メソッドをサポートするために更新されることをAuthenticatorが必要とすることなく、ＥＡＰは幾つか又は全てのメソッドおよびピアに対するパススルーとして動作するAuthenticatorによって、幾つか又は全ての認証メソッドを実施できるバックエンド認証サーバの使用を可能にする。
【００２６】
この後者の引用文献の中で、Authenticatorがパススルーとして動作するか否かに関係なくAuthenticatorの要求が適用される。要求がAuthenticator又はバックエンド認証サーバのいずれかに適用されることを意味している場合、ＥＡＰ認証が終了される場所に依存して、用語「ＥＡＰサーバ」が使用されている。
【００２７】
ＥＡＰはメッセージの再送信をサポートする一方で、それは下位層によって提供される順序付け保証を仮定し、故にメッセージの到達順序に異常のある受信はサポートされない。
【００２８】
ＥＡＰはメッセージの断片化（フラグメンテーション）及び再構築（リアセンブリ）をサポートしないので、最小ＥＡＰ ＭＴＵより大きなペイロードを生成するＥＡＰ認証メソッドは断片化サポートを提供する必要がある。
【００２９】
ＥＡＰ−ＴＬＳのような認証メソッドはメッセージの断片化及び再構築を提供するが、この後者の引用文献で定義されたＥＡＰメソッドは行わない。その結果、ＥＡＰパケットサイズがリンクのＥＡＰ ＭＴＵを越えれば、これらのメソッドは困難に合うことになる。
【００３０】
ＥＡＰ認証はサーバ（Authenticator）によって初期化されるが、多くの認証プロトコルはクライアント（ピア）によって初期化される。その結果、ＥＡＰを通過するために１つ又は２つの追加メッセージ（多くとも１往復）を追加することが認証アルゴリズムに必要となるかもしれない。
【００３１】
証明利用認証がサポートされる場合、追加往復の数は証明書連鎖（certificate chains）の断片化によりかなり多くなるかもしれない。一般的に、断片化ＥＰＡパケットは断片があるだけ多くの往復で送る必要がある。例えば、サイズが１４９６０オクテットの証明連鎖は１４９６オクテットＥＡＰ ＭＴＵで１０往復する必要がある。ＥＡＰが重大なパケットロスを起こす下位層上で動作する場合、又はAuthenticatorと認証サーバとの接続が重要なパケットロスを起こす場合、多くの往復を必要とするＥＡＰメソッドは困難に直面することもある。これらの状況において、少ない往復を用いたＥＡＰメソッドの使用が望まれる。
【００３２】
ＥＡＰ認証交換は次のように処理される。即ち、
［１］Authenticatorはピアを認証するためリクエスト（Request）を送る。リクエストは要求されているものを示すタイプフィールドを有する。リクエストタイプの例は識別、ＭＤ５−チャレンジなどを含む。ＭＤ５−チャレンジタイプはＣＨＡＰ認証プロトコルに密接に対応する［RFC1994参照］。一般的には、Authenticatorは初期認証リクエストを送ることになるが、初期認証リクエストは必要とされなく、バイパスされないこともある。例えば、識別はピアが接続されているポート（専用回線、専用スイッチ又はダイアルアップポート）によって決定される場合、又は識別が（ＭＤ５−チャレンジレスポンスなどのネームフィールドにおいて、呼出局識別又はＭＡＣアドレスを介して）他のメソッドで得られる場合には要求されないこともある。
【００３３】
［２］ピアは有効リクエストに答えてレスポンスパケット（Response packet）を送る。リクエストパケットと同様に、レスポンスパケットはリクエストのタイプフィールドに対応するタイプフィールドを含む。
【００３４】
［３］Authenticatorは追加リクエストパケットを送り、ピアはレスポンスで答える。リクエスト及びレスポンスのシーケンスは必要なだけ継続する。ＥＡＰは‘横並び（lock step）’プロトコルであり、故に、初期リクエスト以外は、新たなリクエストは有効なレスポンスを受理する前に送ることができない。Authenticatorはリクエストを再送信する責任がある。適正数の再送信の後には、AuthenticatorはＥＡＰ対話を終了しなくてはならない。Authenticatorは再送信したとき、又はピアからのレスポンスが得られないときには成功又は失敗パケットを送る必要がない。
【００３５】
［４］対話はAuthenticatorがピア（１以上のリクエストに対して受入れがたいレスポンス）を認証できなくなるまで続けられる。この場合、Authenticatorの実行にはＥＡＰ失敗（コード４）を送信する必要がある。あるいは、認証対話は認証が成功したことをAuthenticatorが決定するまで継続する。この場合、AuthenticatorはＥＡＰ成功（コード３）を送信する必要がある。
【００３６】
他の利点では、ＥＡＰプロトコルは特定のものを事前取り決めする必要が無く多くの認証機構をサポートできる。更に、ネットワークアクセスサーバ（ＮＡＳ）装置（例えば、スイッチ又はアクセスポイント）は各認証メソッドを理解する必要が無く、バックエンド認証サーバに対するパススルーエージェントとして動作できる。パススルーのためのサポートは随意的である。Authenticatorは局所ピアを認証でき、更に、同時に非局所ピア及び局所的には実行しない認証メソッドに対するパススルーとして作用する。更に、バックエンド認証サーバからAuthenticatorを分離することによって証明管理及びネットワークアクセスポリシー決定を簡単にする。
【００３７】
概念的に、ＥＡＰ実施は次の要素からなる。
【００３８】
［ａ］下位層。下位層はピアとAuthenticatorとの間でＥＡＰを送受信する義務がある。ＥＡＰはＰＰＰ，有線ＩＥＥＥ８０２ラン［IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11], UDP (L2TP [RFC2661]及びIKEv2参照）及びＴＣＰを含む各種下位層上で実行していた。
【００３９】
［ｂ］ＥＡＰ層。ＥＡＰ層は下位層を介してＥＡＰパケットを送受信し、二重検出及び再送信を実行し、ＥＡＰメッセージをＥＡＰピア及びAuthenticator層に搬送し及びAuthenticator層から受信する。
【００４０】
［ｃ］ＥＡＰピア及びAuthenticator層。コードフィールドに基づいて、ＥＡＰ層は入力ＥＡＰパケットをＥＡＰピア及びAuthenticator層に分離する。一般的には、所定ホストでのＥＡＰ実行はピア又はAuthenticator機能のいずれかをサポートすることになるが、ホストがＥＡＰピア及びAuthenticatorの両方として作用することを可能にする。そのような実行においては、ＥＡＰ及びAuthenticator層の両方が存在することになる。
【００４１】
［ｄ］ＥＡＰメソッド層。ＥＡＰメソッドはAuthenticatorアルゴリズムを実行し、ＥＡＰピア及びAuthenticator層を介してＥＡＰメッセージを送受信する。断片化のサポートはＥＡＰ自体によっては得られないが、これはＥＡＰメソッドの責任である。
【００４２】
以後の参考文献はここに参照として引用される次の定義を説明している。
【００４３】
Authenticator
ＥＡＰ認証を初期化するリンクの終端。Authenticatorという用語は[IEEE-802.1X]に使用され、この明細書では同様の意味を有する。
【００４４】
ピア
Authenticatorに応答するリンクの終端。[IEEE-802.1X]では、この終端はSupplicantとして知られている。
【００４５】
バックエンド認証サーバ
バックエンド認証サーバは認証サービスをAuthenticatorに提供する個人である。使用時には、このサーバは一般的にはAuthenticatorのためにＥＡＰメソッドを実行する。この専門用語は[IEEE-802.1X]に使用されている。
【００４６】
ＡＡＡ
ＥＡＰサポートを持つ認証、許可、及び課金（ＡＡＡ）プロトコルはＲＡＤＩＵＳ及びダイアミタ（Diameter）を含む。この明細書では、用語“ＡＡＡサーバ”及び“バックエンド認証サーバ”は交換可能に使用される。
【００４７】
ＥＡＰサーバ又はサーバ
ピアによってＥＡＰ認証メソッドを終了する個人バックエンド認証サーバが使用されない場合には、ＥＡＰサーバはAuthenticatorの一部である。Authenticatorがパススルーモードで行動する場合、ＥＡＰサーバはバックエンド認証サーバに設けられる。
【００４８】
成功した認証
この明細書の内容では、「成功した認証」はＥＡＰメッセージの交換であり、その結果Authenticatorはピアによってアクセスできることを決定し、ピアがこのアクセスを使用することを決定する。Authenticatorの決定は一般的には認証及び許可面の両方を含み、ピアはAuthenticatorに首尾良く証明できるが、アクセスは政策的理由によりAuthenticatorによって拒絶されるかもしれない。
【００４９】
マスタセッションキー（ＭＳＫ）
ＥＡＰピアとサーバ間で得られ、ＥＡＰ法によって転送されるキーイングマテリアル。ＭＳＫは長さが少なくとも６４オクテットである。既存の実施では、ＥＡＰサーバとして作用するＡＡＡサーバはＭＳＫをAuthenticatorに搬送する。
【００５０】
拡張マスタセッションキー（ＥＭＳＫ）：
ＥＡＰクライアントとサーバ間で得られ、ＥＡＰ法によって転送される追加キーイングマテリアル。ＥＭＳＫは長さが少なくとも６４オクテットである。ＥＭＳＫはAuthenticator又は任意の他の第三者によっては共有されない。ＥＭＳＫはまだ定義されていない将来の使用のために予約される。
【００５１】
ＥＡＰ拡張
参考のため、出願人はthttp://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-04.txtのサイトに掲載されているEAP Extensions for EAP Reauthentication Protocol (ERP), IETF Internet Draft, August 24, 2007, of V. Narayanan, et alを参照する。この参考文献は次のようにＥＡＰ再認証プロトコルのためのＥＡＰ拡張を説明している。拡張可能認証プロトコルは２つのグループを認証するメソッドの搬送のための総括フレームワークであり、認証は一方向又は相互のいずれかである。第１目的はネットワークアクセス制御であり、キー生成メソッドはアクセス制御を実施するために推奨される。ＥＡＰキーイング階層は２つのキーを定義する。これらのキーはトップレベルで、即ちマスタキーセッション（ＭＳＫ）及び拡張ＭＳＫ（ＥＭＳＫ）で得られる。最も一般的な展開シナリオにおいては、ピア及びサーバはAuthenticatorとして知られている第三者を介して互いに認証する。Authenticator又はAuthenticatorによって管理される個人はアクセス制御を実施する。成功した認証後には、サーバはＭＳＫをAuthenticatorに搬送し、Authenticator及びピアはＭＳＫを認証キー又はキー導出キーとして用いて一時セッションキー（ＴＳＫ）を取得し、単位パケットアクセス実施のためにＴＳＫを使用する。ピアがあるAuthenticatorから他のAuthenticatorに移動するときは、完全ＥＡＰ認証を避けることが望ましい。ＥＡＰメソッドの他の実施を伴う完全ＥＡＰ交換は完了するためにいくつかの往復及びかなりの時間を取り、ハンドオフ時間に遅延が生じる。幾つかのＥＡＰ法は計算オーバヘッドを減じることによって再認証を最適化するために初期認証から状態の使用を特定し、メソッド特定再認証は殆どのケースでは少なくとも２往復する。多くのメソッドは再認証のためにサポートを提供しないことに注意することが重要でもある。故に、個々のメソッドにおけるよりもＥＡＰにおいて効果的な再認証サポートを持つのが良い。
【００５２】
Authenticator間で共有するキーは時々ハンドオフタイムを低減するため現実的な解決法として使用される。その場合、Authenticatorの譲歩は他のAuthenticatorを介して確立されるＥＡＰセッションの譲歩となる。要するに、再びＥＡＰメソッドを実行することを必要としないでピアとAuthenticator間にフレッシュキーを確立することを可能にする有効ＥＡＰ再認証機構を設計する必要がある。この明細書はＥＡＰを用いて有効再認証のためにＥＡＰ再認証拡張（ＥＲＸ）を特定している。ＥＲＸに基づくＥＡＰ再認証プロトコル（ＥＲＰ）はピアに対するＥＡＰメソッド非依存再認証をサポートする。このピアは以前に実行されたＥＡＰ認証からの有効な残りキーマテリアルを有する。プロトコル及びＥＡＰ再認証に必要なキー階層がこの明細書に記載されている。
【００５３】
次の背景参考文献は個々に参照としてここに援用される。
【先行技術文献】
【非特許文献】
【００５４】
【非特許文献１】Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (ここでは[RFC2119]と称する).
【非特許文献２】Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)," RFC 3748, June 2004 (ここでは[RFC3748]と称する).
【非特許文献３】Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-16 (work in progress), January 2007 (ここでは[I-D.ietf-eap-keying]と称する); 及び [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-15 (work in progress), October 2006.
【非特許文献４】Narayanan, V. and L. Dondeti, "Problem Statement on EAP Efficient Re-authentication and Key Management", draft-vidya-eap-reauth-ps-00 (work in progress), October 2006 (ここでは[I-D.vidya-eap-reauth-ps]と称する).
【非特許文献５】Ohba, Y., "Channel Binding Mechanism based on Parameter Binding in Key Derivation", draft-ohba-eap-channel-binding-02 (work in progress), December 2006 (ここでは[I-D.ohba-eap-channel-binding]と称する).
【非特許文献６】Salowey, J., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", draft-salowey-eap-emsk-deriv-01 (work in progress), June 2006 (ここでは[I-D.salowey-eap-emsk-deriv]と称する).
【非特許文献７】National Institute of Standards and Technology, "Secure Hash Standard", August 2002 (ここでは[sha256]と称する).
【非特許文献８】Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", http://tools.ietf.org/html/draft-arkko-eap-service-identity-auth-04, October 2005 (ここでは[arkko-eap-service-identity-auth]と称する).
【非特許文献９】Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005 (ここでは[RFC4306]と称する).
【非特許文献１０】Narayanan, V. and L. Dondeti, "EAP Re-authentication Extensions", draft-ietf-hokey-erx-02 (work in progress), July 2007 (ここでは[I-D.ietf-hokey-erx]と称する).
【非特許文献１１】Salowey, J., "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-01 (work in progress), June 2007 (ここでは[I-D.ietf-hokey-emsk-hierarchy]と称する). 各種方式及び方法は知られているが、改良された方式及び方法の必要性がある。
【発明の概要】
【発明が解決しようとする課題】
【００５５】
本発明は背景技術における各種制限及び欠陥を解消する。本出願は以下に述べるように下記のような発明セットを含む、複数の発明を盛り込んでいる。
【課題を解決するための手段】
【００５６】
発明セット♯１：
幾つかの実施形態によると、クライアントとサーバ間のメソッドの認証方法はａ）クライアントとサーバ間に認証機構を有さないメソッドを採用すること、及びｂ）クライアントを認証するために前記メソッドに内部認証メソッドを当てにさせることを含む。好ましくは、メソッドは内部に第２ＥＡＰを持つ認証機構を有さない第１ＥＡＰメソッドであり、第２ＥＡＰはクライアントを認証するために使用される。
【００５７】
発明セット♯２：
幾つかの他の実施形態によると、ＥＡＰ拡張機能性に関する能力を交渉するためＥＡＰピア及びＥＡＰサーバのためのメソッドは、サーバと拡張機能性に関するクライアントとの能力交換を提供するＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）を採用することを含み、拡張機能性は認証機構を持たなく少なくとも１つのＥＡＰメソッドはＥＡＰピアを認証するためのＥＡＰ拡張メソッド以内で実行する。幾つかの実施形態では、本方法は内部ＥＡＰメソッドにキーイングマテリアルを生成させること、外部ＥＡＰ拡張メソッドのメッセージをＡＵＴＨ ＴＬＶでサポートすることを更に含む。幾つかの実施形態では、本方法は外部ＥＡＰ拡張メッセージのＡＵＴＨ ＴＬＶｓは最近成功した内部メソッドのＥＡＰキーイングマテリアルから生成されるＥＡＰ拡張キー（ＥＡＰ−ＥＸＴ−ＫＥＹ）を用いて計算されることを更に含む。幾つかの実施形態では、本方法はＥＡＰ拡張キーがＥＡＰ−ＥＸＴメッセージをサポートする完全性のためのＡＵＴＨ ＴＬＶｓを計算するために使用されることを更に含む。幾つかの他の実施形態では、本方法はＥＡＰ拡張キーが使用特定ルートキー導出アルゴリズムを使用して内部ＥＡＰメソッドによって生成されるＥＭＳＫから得られることを更に含む。幾つかの実施形態では、本方法はＥＡＰ拡張メソッドが再認証機構に使用されたＥＡＰメソッドによって要求される事前共有キーとして使用されるＥＡＰ再認証キーを定義することを更に含む。幾つかの実施形態では、本方法はＥＡＰ再認証キーが使用特定ルートキー導出アルゴリズムを用いるＥＡＰ拡張メソッドから排出されるＥＭＳＫから得られることを更に含む。幾つかの実施形態では、本方法は最終メッセージであることを示すために設定できるビット、エラーを示すために設定できる他のビット、複数のビットのバージョンフィールド、将来の拡張のための複数のビットの予約フィールド及び各々が特定の能力に対応する複数のビットの能力フィールドとともに共通ＥＡＰフィールドを含むメッセージフォーマットを用いることを更に含む。幾つかの実施形態では、本方法はサーバ及び拡張機能に関するクライアントとの能力交換は能力ビットの設定によって行われることを更に含む。幾つかの実施形態では、本方法は送信者がチャネル結合機構をサポートすることを能力ビットが示すことを更に含む。幾つかの実施形態では、本方法では能力ビットは送信者が再認証をサポートすることを示すことを更に含む。幾つかの実施形態では、本方法は送信者が再認証をサポートしていることを示す能力ビットが最終リクエスト／ＥＸＴメッセージに設定されるときを更に含み、メッセージがサーバＩＤ ＴＬＶ及びピアＩＤ ＴＬＶを含む。幾つかの実施形態では、本方法は送信サポート再認証が最終リクエスト／ＥＸＴメッセージ及びレスポンス／ＥＸＴメッセージ交換に設定されることを能力ビットが示すとき、ＥＡＰピア及びＥＡＰサーバがＥＡＰ再認証キーを発生することを更に含み、サーバＩＤ及びサーバＩＤに含まれるピアＩＤ並びにピアＩＤ ＴＬＶｓ及びＥＡＰ再認証キーは再認証ＥＡＰメソッドに使用される。幾つかの実施形態では、本方法はＥＡＰ拡張メソッド内で順次実行される複数の内部ＥＡＰメソッドを採用すること及びシーケンスの内部ＥＡＰ法がキーイングマテリアルを生成する毎に新たなＥＡＰ拡張キーを生成することを更に含む。幾つかの実施形態では、本方法はａ）ＥＡＰサーバが少なくとも１つの能力ビットセットでＥＡＰリクエスト／ＥＸＴメッセージを送信し、ｂ）ＥＡＰピアはＥＡＰリクエスト／ＥＸＴメッセージを受信し、少なくとも１つの能力ビットセットでＥＡＰレスポンス／ＥＸＴメッセージを送信することを更に含む。幾つかの実施形態では、本方法はｃ）ＥＡＰ−レスポンス／Ｅｘｔメッセージを受信し、Ｆ−ビットセット、少なくとも１つの能力ビットセット、ピアＩＤ ＴＬＶ，サーバＩＤ ＴＬＶ及びＡＵＴＨ ＴＬＶを持つＥＡＰリクエスト／ＥＸＴメセージを送信すること、ｄ）ＥＡＰピアが上記ｃ）のＥＡＰリクエスト／Ｅｘｔメッセージを受信し、Ｆ−ビットセット，少なくとも１つの能力ビットセット及びＡＵＴＨ ＴＬＶを有するＥＡＰレスポンス／ＥＸＴメッセージを送信すること、ｅ）ＥＡＰ−サーバがｄ）のＥＡＰレスポンス／ＥＸＴメッセージ受信し、ＥＡＰ−成功メッセージを送信することを更に含む。幾つかの実施形態では、本方法はピア又はサーバがエラーを検出する場合のエラーを示すビットセット及びＡＵＴＨ ＴＬＶによってＥＡＰピア又はＥＡＰサーバのいずれかにＥＡＰ拡張メッセージを送信させることを更に含む。幾つかの実施形態において、本方法は能力情報が攻撃者によって攻撃されるのを避けるためにキーイングマテリアルの生成後にサポートメッセージ交換を行うことを更に含む。幾つかの実施形態では、本方法はＥＡＰ拡張メソッド以内に多くのＥＡＰメソッドを順序付けることを更に含む。幾つかの実施形態では、本方法はシーケンスにおいて先に成功した内部メソッドによって生成されるキーを用いる外部ＥＡＰ拡張メソッドと共に各内部ＥＡＰメソッドをサポートすることによって暗号結合を作成し、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルを最後に搬送することを更に含む。
【００５８】
発明セット＃３：
幾つかの他の実施形態によると、プロセッサ、メモリ、デジタルデータ記憶装置、及びデータメッセージを無線で送受信するための少なくとも１つの無線インターフェースを含む無線移動局が設けられ、無線モバイル装置はＥＡＰピアとして動作するようにプログラムされている。無線モバイル装置はｉ）ＥＡＰサーバから少なくとも１つの能力ビットセットによってＥＡＰリクエスト／ＥＸＴメッセージを受信し、ｉｉ）少なくとも１つの能力ビットセットによってＥＡＰレスポンス／ＥＸＴメッセージを送信するようにプログラムされる。
【００５９】
発明セット＃４：
幾つかの他の実施形態によると、無線ネットワーク用のＥＡＰサーバがＥＡＰピアによってＥＡＰ認証メソッドを終了する。ＥＡＰサーバはａ）少なくとも１つの能力ビットセットによってＥＡＰリクエスト／ＥＸＴメッセージをＥＡＰピアに送信し、ｂ）少なくとも１つの能力ビットセットによってＥＡＰレスポンス／ＥＸＴメッセージをＥＡＰピアから受信する。
【００６０】
上記及び／又は他の発明、態様、特徴及び／又は種々実施形態の利点は添付図面と関連して以下の説明を鑑みて更に理解されるであろう。種々実施形態は異なる態様、特徴及び／又は適用できる場合の利点を含める及び／又は除外することができる。更に、種々の実施形態は適用できる場合に他の実施形態の１以上の態様又は特徴を組み合わすことができる。特定の実施形態の態様、特徴及び／又は利点の説明は他の実施形態又は請求項を限定するように解釈されるべきでない。
【図面の簡単な説明】
【００６１】
【図１】幾つかの実施形態に従った単一内部メソッドによってＥＡＰサーバとＥＡＰピアとの間の具体的なＥＡＰ−ＥＸＴメッセージシーケンスを示す図である。
【図２】幾つかの実施形態に従った複数の内部メソッドによってＥＡＰサーバとＥＡＰピアとの間の具体的なＥＡＰ−ＥＸＴメッセージシーケンスを示す図である。
【図３Ａ】幾つかの模範的実施形態に従った具体的メッセージフォーマットを示す図である。
【図３Ｂ】幾つかの模範的実施形態に従った具体的能力フィールドを示す図である。
【図３Ｃ】幾つかの模範的実施形態に従った具体的ＴＬＶフォーマットを示す図である。
【図４】幾つかの追加の実施形態に従った単一内部メソッドによってＥＡＰサーバとＥＡＰピアとの間の具体的なＥＡＰ−ＥＸＴメッセージシーケンスを示す図である。
【図５】幾つかの追加の実施形態に従った複数の内部メソッドによってＥＡＰサーバとＥＡＰピアとの間の具体的なＥＡＰ−ＥＸＴメッセージシーケンスを示す図である。
【図６Ａ】幾つかの追加の模範的実施形態に従った具体的メッセージフォーマットを示す図である。
【図６Ｂ】幾つかの追加の模範的実施形態に従った具体的能力フィールドを示す図である。
【図６Ｃ】幾つかの追加の模範的実施形態に従った具体的ＴＬＶフォーマットを示す図である。
【図７Ａ】暗号アルゴリズムＴＬＶを示す図である。
【図７Ｂ】完全性アルゴリズムＴＬＶを示す図である。
【発明を実施するための形態】
【００６２】
本発明の好適な実施形態は添付図面に一例として示され、限定されない。
【００６３】
本発明は多くの異なる形態で実施できるが、多数の具体的実施形態は本開示がここに記載された種々の発明の原理の例を提供するよう考えられるべきであり、そのような例は個々に記載され及び／又はここに説明されていると言う了解の下で説明されている。
【００６４】
１．序論
ＥＡＰ（拡張可能認証プロトコル）は“ＥＡＰメソッド”[RFC3748]として知られている多くの認証アルゴリズムをサポートする認証プロトコルである。ＥＡＰでは、ＥＡＰピア及びＥＡＰサーバはＥＡＰキーイングマテリアル、即ち、ＭＳＫ（マスタセッションキー）及びＥＭＳＫ（拡張マスタセッションキー）を生成する。ＭＳＫの生成、搬送及び使用の詳しいフレームワークは［I-D.ietf-eap-keying］に記載されている。
【００６５】
ＥＭＳＫ用法の１つが再認証である場合にＥＭＳＫ（拡張マスタセッションキー）の幾つかの用法を定義することによってＥＡＰ[RFC3748]の拡張機能がある。ＥＡＰの他の拡張機能は［I-D.ohba-eap-channel-binding］に定義されているチャネル結合方式である。チャネル結合に関する追加の背景文献として、２００６年４月２０日にY. Ohbaによって出願された、CHANNEL BINDING MECHANISM BASED PARAMETER BINDING IN KEY DERIVATIONと名称付けられた同時継続の出願番号１１／３７９，５６８の全開示が全体として参照することによって本明細書に援用される。ＥＡＰの拡張機能をサポートする実施は拡張機能をサポートしない実施と相互運用する必要があり、故に、前者の実施は後者の実施と通信するとき拡張機能を無効にするので、ＥＡＰピアに対する機構が必要となり、ＥＡＰの拡張機能に関して能力を取り決めるＥＡＰサーバが必要となる。
【００６６】
ＥＡＰ機能を拡張するために２つの基本的な方法がある。１つの方法は既存の方法、即ち、リクエスト、レスポンス、成功及び失敗に加えて拡張ＥＡＰ機能を実現するために新たなＥＡＰコードを定義することである。しかしながら、この方法はＲＦＣ３７４８への変更を必要とし、下位層プロトコルへの変更も必要とするかもしれない。他の方法は拡張機能を実現するために新たなＥＡＰメソッドを定義することである。この明細書は後者の方法が既存のＥＡＰ展開への攻撃を参照にするために後者の方法と取る。
【００６７】
この明細書はＥＡＰ−ＥＸＴ、ＥＡＰ機能を拡張するＥＡＰメソッドを説明している。幾つかの好適実施形態では、拡張ＥＡＰ機能はチャネル結合及び再認証を含む。また、ＥＡＰ−ＥＸＴメソッドはその内部の多くのＥＡＰメソッドの順序づけを可能にする。
【００６８】
２．ＥＡＰ−ＥＸＴ概要
好適実施形態では、ＥＡＰ−ＥＸＴは能力交換を提供する。この点について、メッセージ内のビットは能力の表示に使用できる。幾つかの実施形態では、１ビット（Ｒ−ビット）は再認証能力に使用される。幾つかの実施形態では、１ビット（Ｃ−ビット）はチャネル結合能力を示すために使用される。
【００６９】
ＥＡＰ−ＥＸＴが使用されるとき、サーバが第１のＥＡＰリクエストを送る前にサーバにピアの識別が知られれば先のＥＡＰ−識別交換が省略できる。この点について、ピアの識別をサーバに提供する、例えば、Authenticatorとサーバとの間でピアの識別を転送する幾つかのアウトバンド（outband）機構がある。
【００７０】
ＥＡＰ−ＥＸＴにおいて、チャネル結合及び再認証のような拡張ＥＡＰ能力はピア及びサーバ間で交換される。同時に、少なくとも１つのＥＡＰメソッド（例えば、ＥＡＰ−ＴＬＳ）はピアを認証するためのＥＡＰ−ＥＸＴ内で実行される。内部メソッドがＥＡＰキーイングマテリアルを生成するまで、ＡＵＴＨ ＴＬＶは含まれず、能力はサポートされない。故に、１つの内部ＥＡＰメソッドだけがあれば、ＡＵＴＨ ＴＬＶを有するがメソッドＴＬＶを有さない追加のＥＡＰ−ＥＸＴがＥＡＰ成功又はＥＡＰ失敗メッセージを送る前に実行される。
【００７１】
内部ＥＡＰメソッドはＥＡＰキーイングマテリアルを生成した後、ＥＡＰ−ＥＸＴメッセージはＡＵＴＨ ＴＬＶによってサポートする必要がある。ＥＡＰ−ＥＸＴメッセージの中のＡＵＴＨ ＴＬＶｓは最後に成功した内部メソッドのＥＡＰキーイングマテリアルから生成されるＥＡＰ−ＥＸＴ−ＫＥＹを用いて計算する必要がある。これはＥＡＰ−ＥＸＴ内部で順次実行される複数の内部ＥＡＰメソッドがあれば、新たなＥＡＰ−ＥＸＴ−ＫＥＹがシーケンスの内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを生成する毎に生成されることを意味する。任意の内部ＥＡＰメソッドはＥＡＰキーイングマテリアルを生成できる用になる必要がある。
【００７２】
成功したＥＡＰ−ＥＸＴ実行の最後に、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルはＥＡＰ層に転送される。Ｆ−ビットはＥＸＰ−ＥＸＴ交換の終了を示すために使用される。
【００７３】
図１は単一の内部ＥＡＰメソッドを持つＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。図２は複数の内部ＥＡＰメソッドを有するＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。
【００７４】
３．エラー処理
エラーは複数の理由、例えば、内部ＥＡＰメソッド認証の失敗又は異常、未知、紛失ＥＡＰ−ＥＸＴ ＴＬＶにより生じるかもしれない。エラーはピア又はサーバのいずれかによって検出できる。エラーを起こしたＥＡＰ−ＥＸＴメッセージは誤りメッセージと見なされる。Ｅ−ビットセットを持つＥＡＰ−ＥＸＴメッセージはエラー表示のために使用される。これらのメッセージはエラー表示と見なされる。エラー表示はＡＵＴＨ ＴＬＶを含める必要があり、他のＴＬＶｓを含めるべきでない。
【００７５】
有効ＡＵＴＨ ＴＬＶを持たない（間違ったエラー表示を含む）どんな間違いメッセージも静かに破棄さする必要がある。
【００７６】
有効ＡＵＴＨ ＴＬＶを持つ間違いリクエストに対して、ピアはエラー表示レスポンスを送る。有効ＡＵＴＨ ＴＬＶを伴わない間違いレスポンスに対して、サーバはエラー表示リクエストを送り、このリクエストはエラー表示レスポンスでピアによって応答される。サーバは有効ＡＵＴＨ ＴＬＶ．を伴うエラー表示レスポンスに応答してＥＡＰ失敗メッセージを送り返す。
【００７７】
４．完全性サポートキー
ＥＡＰ−ＥＸＴは２種類のキー、即ち、１）ＥＡＰ−ＥＸＴ−ＫＥＹ及び２）ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹを定義する。
【００７８】
４．１． ＥＡＰ−ＥＸＴ−ＫＥＹは完全性サポートＥＡＰ−ＥＸＴメッセージのためにＡＵＴＨ ＴＬＶｓの計算に使用される。ＨＭＡＣ−ＳＨＡ−２５６（上記文献に含まれる参考[sha256]を参照）は完全性アルゴリズムに使用されると、ＥＡＰ−ＥＸＴ−ＫＥＹの長さは３２オクテットである。ＥＡＰ−ＥＸＴ−ＫＥＹは次のように定義されるＵＳＲＫ（Usage Specific Root Key）導出アルゴリズムを用いて内部ＥＡＰメソッドによって生成されるＥＭＳＫから得られる（例えば、上記に参照することによって援用される文献[I-D.salowey-eap-emsk-deriv]を参照）。
【００７９】
ＥＡＰ−ＥＸＴ−ＫＥＹ ＝ ＫＤＦ （EMSK, "EAP-EXT-Integrity-Key", length）．
ＫＤＦでは、ＥＡＰ−ＥＸＴ−ＫＥＹは上記に参照することによって援用される文献［I-D.salowey-eap-emsk-deriv］に特定されているデフォルトＰＲＦを用いる。
【００８０】
４．２． ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹ
ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは再認証機構に使用されるＥＡＰメソッドによって要求される事前共有キーとして使用される。ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹの長さは再認証機構に依存する。ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは上記で援用される文献［I-D.salowey-eap-emsk-deriv］に次のように定義されるＵＳＲＫ導出アルゴリズムを用いてＥＡＰ−ＥＸＴから転送されるＥＭＳＫから得られる。
【００８１】
ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹ ＝ ＫＤＦ（EMSK, "EAP-EXT-Reauthentication-Key", length）
５． メッセージフォーマット
ＥＡＰ−ＥＸＴは（ＩＡＮＡによって割り当てられるべき）ＥＡＰ Ｔｙｐｅ Ｘを用いる。[RFC3748]に定義された共通ＥＡＰフィールド（例えば、コード、識別子、長さ及び種類）を含むメッセージフォーマットは図３（Ａ）に示される。
【００８２】
Ｆ：
このビットはこれが送信者からの最後のＥＡＰ−ＥＸＴメッセージであることを示すように設定する必要がある。そうでなければ、このビットは設定する必要がない。
【００８３】
このビットはメッセージがエラー表示であるときに設定される。このビットが設定されると、Ｆビットも設定する必要がある。エラー表に関する詳細な説明のセクション３を参照。
【００８４】
バージョン：
この８ビットフィールドはＥＡＰ−ＥＸＴメソッドのバージョンを示す。この明細書はバージョン１を定義している。
【００８５】
予約（Reserved）：
６ビットフィールドは将来の拡張のために予約される。このフィールドは送信者によってゼロに設定する必要があり、受信者はこのフィールドを無視する必要がある。
【００８６】
能力（Capabilities）
能力フィールドが処理するこのフィールドは拡張ＥＡＰ能力を含む。能力は図３（Ｂ）に示されるフォーマットを処理する。
【００８７】
各ビットは特定能力に対応する。各ビットの意味は次の通りである。
【００８８】
Ｃ：
このビットは送信者がＭＳＫのための［I-D.ohba-eap-channel-binding］に定義されるチャネル結合機構をサポートすることを示すために設定される。このビットはリクエスト及びレスポンスの両方に対して設定され、ＥＡＰ−ＥＸＴメソッドが首尾よく完了すると、ピア及びサーバはチャネル結合機構を可能にする必要がある。ｐｒｆ＋用デフォルトハッシュアルゴリズム（default hash algorithm）はＡＵＴＨ＿ＨＭＡＣ＿ＳＨＡ１＿１６０である。
【００８９】
Ｒ：
このビットは送信者が再認証ＥＡＰメソッドをサポートすることを示すために設定される。このビットは最後のリクエスト／ＥＸＴメッセージに設定されると（即ち、Ｆビットを有するリクエスト／ＥＸＴが設定されると）、メッセージはサーバＩＤ ＴＬＶ及びピアＩＤ ＴＬＶを含める必要があり、Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＡＶＰを含めることができる。このビットが最後のリクエスト／ＥＸＴ及びレスポンス／ＥＸＴメッセージ交換に設定されると、ピア及びサーバはＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹを発生する必要がある。サーバＩＤ及びピアＩＤはサーバＩＤ及びピアＩＤ ＴＬＶｓに含められ、ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは再認証ＥＡＰメソッドに使用される。デフォルト再認証機構はこの明細書に基づく従来技術のそれらによって選択できる。
【００９０】
他のビットは将来の使用のために予約され、送信者によってゼロに設定する必要があり、受信者によって無視される必要がある。
【００９１】
ＴＬＶ：
ゼロ、１以上のＴＬＶｓ（Type-Length-Value's）。そのＴＬＶフォーマットは図３（Ｃ）に示される。
【００９２】
タイプ：
このフィールドはこのＴＬＶのタイプを示す。
【００９３】
長さ：
このフィールドは種類及びＴＬＶの長さフィールドを含めて、オクテットでこのＴＬＶの長さを示す。
【００９４】
値
このフィールドはＴＬＶタイプに特定されるデータを含む。
【００９５】
６． ＥＡＰ−ＥＸＴ ＴＬＶｓ
後続ＴＬＶｓが定義される。
【００９６】
６．１．メソッドＴＬＶ
メソッドＴＬＶ（タイプ１）はタイプフィールドから開始するＥＡＰメソッドペイロードを含む。
【００９７】
６．２． ＡＵＴＨ ＴＬＶ
ＡＵＴＨ ＴＬＶ（タイプ２）はＥＡＰ−ＥＸＴメッセージをサポートするために使用される完全性データを含む。ＥＡＰ−ＥＸＴ−ＫＥＹはＡＵＴＨ ＴＬＶｓを計算するために使用される。
【００９８】
ＴＬＶ値フィールドはこのフィールドを含む全体のＥＡＰメッセージわたって計算される。完全性データを計算する前に、このフィールドは全てゼロに初期化する必要がある。このフィールドの長さは使用時に完全性アルゴリズムに依存する。完全性チェックが失敗すると、メッセージは静かに破棄する必要がある。デフォルト完全性アルゴリズムはＨＭＡＣ−ＳＨＡ−２５６である（例えば、上記で援用されている文献[sha256]を参照）。
【００９９】
６．３． ピアＩＤ ＴＬＶ
ピアＩＤ ＴＬＶ（タイプ３）は再認証に使用されるピアの識別を含む。
【０１００】
６．４． サーバＩＤ ＴＬＶ
サーバＩＤ ＴＬＶ（タイプ４）は再認証に使用されるサーバの識別を含む。
【０１０１】
６．５． Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＴＬＶ
Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＴＬＶ（タイプ５）はＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹの寿命を秒単位で含む。
【０１０２】
７． 安全性考慮
内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを送る前に能力交換はサポートされない。故に、ＥＡＰキーイングマテリアルの作成後の追加サポートメッセージ交換は能力情報がピア及びサーバによって検出されないで攻撃者によって変更されるのを避けるために義務付けられる。
【０１０３】
ＥＡＰ−ＥＸＴはその中の多くのＥＡＰメソッドの順序付けを可能にする。複数の入れ子又は順序認証メソッドを暗号的に結合しないでそれらで構成される複合認証メソッドが介入者攻撃に対して無防備さを有する。ＥＡＰ−ＥＸＴはシーケンスにおいて前に成功した内部メソッドによって生成されるキーを用いて外部ＥＡＰメソッド（即ち、ＥＡＰ−ＥＸＴ）と共に各内部ＥＡＰメソッドをサポートし、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルを最終的に転送することによって必要暗号化的結合を作ることができる。暗号化結合を達成するために、ＥＡＰ−ＥＸＴはＥＡＰキーイングマテリアルを生成できる内部ＥＡＰメソッドを必要とする。
【０１０４】
追加ＥＡＰ−ＥＸＴ実施形態
詳細説明の残りは幾つかの内容において上記オリジナル実施形態を越える幾つかの変形例を有する追加のＥＡＰ−ＥＸＴ実施形態について述べる。上記から分かるように、これらの追加実施形態は上述した先の実施形態に多くの点で類似している。これらの実施形態では、拡張機能、例えば、ＨＯＫＥＹ再認証（例えば［I-D.ietf-hokey-erx］参照）及びＭＳＫチャネル結合［I-D.ietf-eap-keying］がＥＡＰ機能を拡張することによってサポートできる。上記で説明したように、ＥＡＰ機能を拡張するために２つの方法がある。１つの方法は既存のもの、即ち、リクエスト、レスポンス、成功及び失敗に加えて拡張ＥＡＰ機能を実現するため新ＥＡＰコードを定義することである。しかしながら、この方法は［ＲＦＣ３７４８］に変更を要求し、Authenticator及び下位層プロトコルに変更を要求することもできる。他の方法は拡張機能を実現するための新たなＥＡＰメソッドを定義することである。両方法について、これら延長機能は下位互換性であることが望まれるかもしれない。そのような場合、ＥＡＰピアとＥＡＰサーバとの間で拡張機能に関する能力を取り決める機構が必要となるかもしれない。
【０１０５】
これらの追加実施形態では、ＥＡＰ機能を拡張するために使用されるＥＡＰメソッドが説明される。拡張機能は、例えば、ＨＯＫＥＹ再認証及びＭＳＫチャネル結合を含む。これらの実施形態での提案ＥＡＰメソッド（ＥＡＰ−ＥＸＴ）は再度それ自体内で多くのＥＡＰメソッドの順序付けをも可能にする。更に、これらの実施形態の中で、ＥＡＰ−ＥＸＴは内部メソッド実施がＭＳＫを生成するがＥＭＳＫ を生成しない場合にＭＳＫ及びＥＭＳＫを発生できる。
【０１０６】
ＥＡＰ−ＥＸＴ概要
ＥＡＰ−ＥＸＴは能力交換を提供する。１ビット（Ｒビット）はＨＯＫＥＹ再認証能力を示すために使用される。１ビット（Ｃビット）はチャネル結合能力を示すために使用される。
【０１０７】
ＥＡＰ−ＥＸＴが使用されるとき、先のＥＡＰ識別交換はサーバがＥＡＰリクエストを送る前にピアの識別がサーバに知られていれば省略できる。ピアの識別を提供する、例えば、Authenticatorとサーバとの間でピアの識別を転送するための帯域外機構が使用できる。
【０１０８】
ＥＡＰ−ＥＸＴにおいて、ＨＯＫＥＹ再認証及びＭＳＫチャネル結合のような拡張ＥＡＰ能力がピアとサーバ間で交換される。同時に、少なくとも１つのＥＡＰメソッド（例えば、ＥＡＰ−ＴＬＳ）がピアを認証するためにＥＡＰ−ＥＸＴ内で実行される。１つ以上の内部メソッドはメソッドＴＬＶｓ（Type-Length-Values）で行われる。内部メソッドがＥＡＰキーイングマテリアルを生成するまで、ＡＵＴＨ ＴＬＶは含まれなく、能力はサポートされない。故に、内部ＥＡＰメソッドだけ存在すれば、ＡＵＴＨ ＴＬＶを持つ追加ＥＡＰ−ＥＸＴ交換は内部メソッドの完了後及びＥＡＰ成功又はＥＡＰ失敗メッセージを送る前に行う必要がある。
【０１０９】
内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを発生した後、ＥＡＰ−ＥＸＴメッセージはＡＵＴＨ ＴＬＶによってサポートする必要がある。ＥＡＰ−ＥＸＴメッセージのＡＵＴＨ ＴＬＶｓは最後に成功した内部メソッドのＥＡＰキーイングマテリアルから生成されるＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹを用いて計算する必要がある。これはＥＡＰ−ＥＸＴ内で順次実行される多くの内部ＥＡＰメソッドがあれば、新たなＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹはシーケンスのうちの内部ＥＡＰがＥＡＰキーイングマテリアルを発生する毎に生成されることを意味する。任意の内部ＥＡＰメソッドはＥＡＰキーイングマテリアルを生成可能にする必要がある。
【０１１０】
成功したＥＡＰ−ＥＸＴの実行の終わりに、ＥＡＰキーイングマテリアルが最後に成功した内部ＥＡＰメソッドによって生成されるＭＳＫから得られ、ＥＡＰ層に転送される。ＥＡＰキーイングマテリアル及びＵＳＲＫｓ（Usage Specific Root Keys）［I-D.ietf-hokey-emsk-hierarchy］を得るために使用される仮想ランダム関数がＰＲＦ ＴＬＶｓを用いてＥＡＰ−ＥＸＴ内で交渉できる。ＦビットはＥＸＰ−ＥＸＴ交換の終了を示すために使用される。
【０１１１】
図４は単一内部ＥＡＰメソッド及びＰＲＦ取り決めを持つＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。図５は複数の内部ＥＡＰメソッドを持つがＰＲＦ交渉を持たないＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。
【０１１２】
エラー取り扱い
上述したオリジナル実施形態でエラー取り扱いに関する検討がここに援用される。
【０１１３】
キー
幾つかの実施形態では、ＥＡＰ−ＥＸＴは次のタイプのキーを定義する。
【０１１４】
ａ．ＥＡＰ−ＥＸＴ から転送されるＭＳＫ及びＥＭＳＫ
ＥＡＰ−ＥＸＴ から転送される６４オクテットＭＳＫ及び６４オクテットＥＭＳＫのセットはＭＳＫ＿ｉから得られ、ＭＳＫは次の方法で［I-D.ietf-hokey-emsk-hierarchy］に定義されたＫＤＦを用いて、最後に成功した内部ＥＡＰメソッドによって生成される。
【０１１５】
(MSK, EMSK) = KDF(MSK_i, "EAP-EXT-EAP-Keying-Material", 128)
ｂ． ＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹ：
ＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹはＥＡＰ−ＥＸＴメッセージを安全にサポートするためにＡＵＴＨ ＴＬＶｓを算出するために用いられる。ＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹはＥＡＰ−ＥＸＴ内だけで使用され、決して転送されない。ＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹは次のように[RFC4306]で定義されたｐｒｆ＋を用いて、最後に成功した内部ＥＡＰメソッド（ＭＳＫ＿ｉ）によって生成されるＭＳＫから求められる。
【０１１６】
EAP-EXT-AUTH-KEY = prf+(MSK_i, "EAP-EXT-認証キー"，長さ）
ｐｒｆ＋用デフォルトハッシュアルゴリズムはＰＲＦ＿ＨＭＡＣ＿ＳＨＡ２＿２５６である。
【０１１７】
フィールド長はＥＡＰ−ＥＸＴ交換中にＥＡＰサーバによって選択される完全性アルゴリズムに依存することになる。ＨＭＡＣ−ＳＨＡ−２５６[sha256]が完全性アルゴリズムに使用されると、長さ＝３２である。
【０１１８】
ｃ． ＥＡＰ−ＥＸＴ−ＥＮＣ−ＫＥＹ：
ＥＡＰ−ＥＸＴ−ＥＮＣ−ＫＥＹは暗号化ＴＬＶｓの内容を暗号化するために使用される。それはＭＳＫ＿ｉから得られ、ＭＳＫは次のように［I-D.ietf-hokey-emsk-hierarchy］で定義されるＫＤＦを用いて、最後に成功した内部ＥＡＰメソッドによって生成される。
【０１１９】
EAP-EXT-ENC-KEY = prf+(MSK_i, "EAP-EXT-Encryption-Key",長さ）；
ＥＡＰ−ＥＸＴ−ＥＮＣ−ＫＥＹを生成するために使用されるＰＲＦはＥＡＰ−ＥＸＴ交換中にＥＡＰサーバによって選択される完全性アルゴリズムによって決定される。ｐｒｆ＋用デフォルトハッシュアルゴリズムはＰＲＦ＿ＨＭＡＣ＿ＳＨＡ２＿２５６である。
【０１２０】
フィールド長はＥＡＰ−ＥＸＴ交換中に取り決められる取り決め暗号化アルゴリズムに依存する。例えば、ＡＥＳ−ＣＢＣ−１２８が使用されるときは、長さ＝１６である。
【０１２１】
ｄ． ＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹ：
ＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹはＨＯＫＥＹ再認証機構［I-D.ietf-hokey-erx］に必要な事前共通キーとして使用される。ＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹの長さはＨＯＫＥＹ再認証機構に依存する。ＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹは次のように［I-D.ietf-hokey-emsk-hierarchy］で定義されるＵＳＲＫ導出アルゴリズムを用いてＥＡＰ−ＥＸＴから転送されるＥＭＳＫから求められる。
【０１２２】
ＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹ ＝ ＫＤＦ（EMSK, "EAP-EXT-再認証キー"，長さ）
メッセージフォーマット
ＥＡＰ−ＥＸＴは（ＩＡＮＡによって割り当てられる）ＥＡＰ Ｔｙｐｅ ＸＸを使用する。[RFC3748]で定義される共通ＥＡＰフィールド（即ち、コード、識別子、長さ及びタイプ）を含むメッセージフォーマットは図６（Ａ）に示される。
【０１２３】
Ｆ：
このビットはこれが送信者からの最後のＥＡＰ−ＥＸＴメッセージであることを示すように設定する必要がある。
【０１２４】
Ｅ：
このビットはメッセージがエラー表示であるときに設定される。このビットが設定されるとき、Ｆビットも設定する必要がある。エラー表示の詳細な説明を以下に示す。
【０１２５】
バージョン
８ビットフィールドはＥＡＰ−ＥＸＴメソッドのバージョンを示す。この明細書はバージョン１を定義する。
【０１２６】
予約
この６ビットフィールドは将来の拡張のために予約される。このフィールドは送信者によってゼロに設定する必要があり、受信者はこのフィールドを無視する必要がある。
【０１２７】
能力
能力フィールドは拡張ＥＡＰ能力を含む。能力フィールドは（図３（Ｂ）と同様であり）幾つかの実施形態において図６（Ｂ）に示されるようなフォーマットを持っている。ここでは、各ビットは特定の能力に対応する。各ビットの意味は次の通りである。
【０１２８】
Ｒ：
このビットは送信者がＨＯＫＥＹ再認証［I-D.ietf-hokey-erx］をサポートすることを示すように設定される。このビットは最後のリクエスト／ＥＸＴメッセージに設定される（即ち、Ｆビットを有するリクエスト／ＥＸＴが設定される）と、メッセージはサーバＩＤ ＴＬＶ及びピアＩＤ ＴＬＶを含める必要があり、Reauth-Key-Lifetime AVPを含めることができる。このビットは最後のリクエスト／ＥＸＴ及びレスポンス／ＥＸＴ交換に設定されると、ピア及びサーバはＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹを生成する必要がある。サーバＩＤ及びピアＩＤはサーバＩＤ及びピアＩＤ ＴＬＶｓに含まれ、ＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹはＨＯＫＥＹ再認証に使用される。
【０１２９】
Ｃ：
このビットは送信者がＭＳＫ用チャネル結合機構をサポートしていることを示すように設定される。このビットはリクエスト／ＥＸＴメッセージに設定されると、１つのチャネル結合機構（Channel-Binding-Mechanism）ＴＬＶもサーバによってサポートされる１つ以上のチャネル結合機構を示すように含める必要がある。ピアがサーバによってサポートされる１つ以上のチャネル結合機構の１つをサポートし、可能にしたければ、それはこのビットセットを持つレスポンス／ＥＸＴメッセージ及び選択チャネル結合機構を含む１つのチャネル結合機構ＴＬＶを送信する。このビットが１つのチャネル結合機構の成功した交渉によって最後のリクエスト／ＥＸＴ及びレスポンス／ＥＸＴ交換に設定され、ＥＡＰ−ＥＸＴメソッドが首尾よく完了すれば、ピア及びサーバは取り決めチャネル結合機構を可能にする必要がある。
【０１３０】
他のビットは将来の使用のために予約され、送信者によってゼロに設定する必要があり、受信者によって無視される必要がある。
【０１３１】
ＴＬＶ：
ゼロ、１以上のＴＬＶｓ（Type-Length-Value's）。そのＴＬＶフォーマットは図３（Ｃ）に示される実施形態と同様である図６（Ｃ）に示されるようである。
【０１３２】
タイプ：
このフィールドはこのＴＬＶのタイプを示す。
【０１３３】
長さ：
このフィールドはＴＬＶのタイプ及び長さフィールドを含めてこのＴＬＶの長さをオクテットで示す。
【０１３４】
値：
このフィールドはＴＬＶタイプに特定するデータを含む。
【０１３５】
ＥＡＰ−ＥＸＴ ＴＬＶｓ：
これらの実施形態では、次のＴＬＶｓが定義される。
【０１３６】
ａ． メソッドＴＬＶ
メソッドＴＬＶ（タイプ１）はタイプフィールドから開始するＥＡＰメソッドペイロードを含む。
【０１３７】
ｂ． ＡＵＴＨ ＴＬＶ
ＡＵＴＨ ＴＬＶ（タイプ２）はＥＡＰ−ＥＸＴメッセージをサポートするために使用される完全性データを含む。ＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹはＡＵＴＨ ＴＬＶｓを計算するために使用される。ＴＬＶ値フィールドはこのフィールドを含む全体のＥＡＰメッセージにわたり計算される。完全性データを計算する前に、このフィールドは全てゼロに初期化する必要がある。このフィールドの長さは使用時に完全性アルゴリズムに依存する。完全性チェックが失敗すると、メッセージは静かに破棄する必要がある。デフォルト完全性アルゴリズムはＨＭＡＣ−ＳＨＡ−２５６［ｓｈａ２５６］である。
【０１３８】
ｃ． ピアＩＤ ＴＬＶ
ピアＩＤ ＴＬＶ（タイプ３）はＨＯＫＥＹ再認証に使用されるピアの識別を含む。
【０１３９】
ｄ． サーバＩＤ ＴＬＶ
サーバＩＤ ＴＬＶ（タイプ４）はＨＯＫＥＹ再認証に使用されるサーバの識別を含む。
【０１４０】
ｅ． Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＴＬＶ
Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＴＬＶ（タイプ５）は秒単位でＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹの寿命を含む。
【０１４１】
ｆ． ＰＲＦ ＴＬＶ
ＰＲＦ ＴＬＶ（タイプ６）は[I-D.ietf-hokey-emsk-hierarchy]で定義される１以上の１−オクテット数を含む。このＴＬＶがリクエストに運び込まれると、それはサーバによってサポートされる１以上のＰＲＦ数を示す。
【０１４２】
このＴＬＶがリクエスト／ＥＸＴメッセージに運び込まれると、対応するレスポンス／ＥＸＴメッセージがこのＴＬＶを含むことができる。レスポンス／ＥＸＴ内のＰＲＦ ＴＬＶはリクエスト／ＥＸＴメッセージのＰＲＦ数の中の、ピアによってサポート及び選択される１つのＰＲＦ数を正確に含める必要がある。ＰＲＦ数が上述されたＰＲＦ ＴＬＶ交換を用いて首尾よく取り決められれば、取り決められた数がＥＡＰ−ＥＸＴ及びＵＳＲＫｓによって転送されるＥＡＰキーイングマテリアルを得るためにＫＤＦに使用される。そうでなければ、[I-D.ietf-hokey-emsk-hierarchy]で特定されたデフォルトＰＲＦがＫＤＦに使用される。
【０１４３】
ｇ． チャネル結合機構ＴＬＶ
チャネル結合機構ＴＬＶ（タイプ７）１以上の１−オクテットチャネル結合機構数を含む。このＴＬＶがリクエスト／ＥＸＴメッセージに運び込まれると、それはサーバによってサポートされる１以上のチャネル結合機構数を示す。このＴＬＶがリクエスト／ＥＸＴメッセージに運び込まれると、対応するレスポンス／ＥＸＴメッセージはこのＴＬＶを含めることができる。レスポンス／ＥＸＴメッセージのチャネル結合機構ＴＬＶはリクエスト／ＥＸＴメッセージのチャネル結合機構数の内の、ピアによってサポートされ、選択される１つのチャネル結合機構数を正確に含める必要がある。チャネル結合機構は上述したチャネル結合機構ＴＬＶ交換を用いて首尾よく取り決められれば、取り決めチャネル結合機構が可能となる。
【０１４４】
以下のチャネル結合機構数はこの明細書において定義されている。即ち、機構1 - [I-D.ohba-eap-channel-binding]及び機構2 - [arkko-eap-service-identity-auth]。
【０１４５】
チャネル結合機構１について、ｐｒｆ＋用デフォルトハッシュアルゴリズムはＰＲＦ＿ＨＭＡＣ＿ＳＨＡ２＿２５６である。
【０１４６】
チャネル結合機構２について、追加チャネル結合データＴＬＶがリクエスト及びレスポンスに運び込まれる。
【０１４７】
ｈ． チャネル結合データＴＬＶ
チャネル結合データＴＬＶ（タイプ８）は[arkko-eap-service-identity-auth]に使用されるオクテットストリングデータを含む。
【０１４８】
ｉ． 暗号化アルゴリズムＴＬＶ
暗号化アルゴリズムＴＬＶは暗号化ＴＬＶｓを暗号化するために使用される暗号化アルゴリズムの取り決めを可能にする。このＴＬＶはリクエスト／ＥＸＴに運び込まれると、それはＥＡＰサーバによってサポートされる暗号化アルゴリズムを示す。このＴＬＶがリクエスト／ＥＸＴメッセージに運び込まれると、対応するレスポンス／ＥＸＴメッセージはこのＴＬＶを含むことができる。レスポンス／ＥＸＴメッセージの暗号化アルゴリズムＴＬＶはリクエスト／ＥＸＴメッセージに含まれる暗号化アルゴリズムＴＬＶのオプション内の、ピアによってサポートされ、選択された１つの暗号化アルゴリズム数を正確に含める必要がある。ＥＡＰサーバはデフォルト暗号化アルゴリズム（ＡＥＳ−ＣＢＣ−１２８）を使用するためＥＡＰピアを強制できることに留意する。そのような場合、ＥＡＰピアはリクエスト／ＥＸＴメッセージに暗号化アルゴリズムＴＬＶを含めなく、同様に、ＥＡＰピアはレスポンス／ＥＸＴメッセージにもそれを含めない。参考のため、図７（Ａ）は暗号化アルゴリズムＴＬＶを示している。
【０１４９】
それは次のように定義された１以上の１−オクテット数を含む。
【０１５０】
０ 予約
１ ＡＥＳ−ＣＢＣ−１２８（デフォルト）
２ ＡＥＳ−ＣＢＣ−２５６
３ ３ＤＥＳ
４ ＩＤＥＡ
アルゴリズムは暗号化アルゴリズムＴＬＶを用いて首尾よく交渉できなければ、デフォルト暗号化アルゴリズムが代わりに使用される。
【０１５１】
ｊ． 完全性アルゴリズムＴＬＶ
ＥＡＰ−ＥＸＴメソッドは簡単にするために及び競り下げ攻撃（bidding-down attacks）を避けるために完全性アルゴリズム取り決めを可能にしない。しかしながら、ＥＡＰサーバは異なる完全性アルゴリズムから選択でき、完全性アルゴリズムＴＬＶを介してこの選択についてＥＡＰピアに知らせる。ＥＡＰサーバがこのＴＬＶを含んでいなければ、デフォルト値がＨＭＡＣ−ＳＨＡ−２５６となる。参考のため、図７（Ｂ）は完全性アルゴリズムＴＬＶを示している。
【０１５２】
それは次のリストに定義された１以上の１−オクテット数を含む。
【０１５３】
０ 予約
１ ＨＭＡＣ−ＳＨＡ−１
２ ＨＭＡＣ−ＳＨＡ−２２４
３ ＨＭＡＣ−ＳＨＡ−２５６（デフォルト）
４ ＨＭＡＣ−ＳＨＡ−３８４
５ ＨＭＡＣ−ＳＨＡ−５１２
ｋ． 暗号化ＴＬＶ
暗号化ＴＬＶ（タイプ１０）はＥＡＰ−ＥＸＴ−ＥＮＣ−ＫＥＹによって暗号化された１以上の標準文字を含む。このフィールドの長さは使用時に暗号化アルゴリズムに依存する。図７（Ｃ）を参照する。
【０１５４】
それは次のように定義された１以上の１−オクテット数を含む。
【０１５５】
タイプ：
（１０） 暗号化ＴＬＶ
長さ：
４＋ＩＶ長＋暗号化データ長．
ＩＶ：
ＩＶは最初が最上位ビットであるランダムビットのオクテットストリングである。ＩＶの長さは使用時の暗号化アルゴリズムに依存する。例えば、ＡＥＳ−ＣＢＣ−１２８について、ＩＶは１６バイト（１２８ビット）である。
【０１５６】
暗号化データ
可変長の暗号化ＴＬＶ。暗号化データはＥＡＰ−ＥＸＴ−ＥＮＣ−ＫＥによって暗号化された１以上の標準文字ＴＬＶｓから成る。暗号化アルゴリズム及び標準文字データの長さに依存して、暫定データが暗号化動作の以前に標準文字データに加算できる。
【０１５７】
セキュリティ上の配慮
内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを転送する前の能力交換はサポートされない。故に、ＥＡＰキーイングマテリアルの生成後の追加サポートメッセージ交換はピア及びサーバによって検出されないで能力情報が攻撃者によって変更されることを回避するために義務付けられる。
【０１５８】
ＥＡＰ−ＥＸＴはその内部の複数のＥＡＰメソッドの順序付けを可能にする。複数の入れ子又は順序付けられた認証メソッドを暗号的に結合しないでそれらにより構成される組合せ認証メソッドはman-in-the-middle攻撃に対しては脆弱である。ＥＡＰ−ＥＸＴはシーケンス内での先に成功した内部メソッドによって生成されるキーによって外部ＥＡＰメソッド（即ち、ＥＡＰ−ＥＸＴ）と共に各内部ＥＡＰメソッドをサポートし、最後に成功した内部ＥＡＰメソッドによって生成されるキーから得られるＥＡＰキーイングマテリアルを転送することによって必要暗号化結合を作ることができる。暗号化結合を達成するために、ＥＡＰ−ＥＸＴはＥＡＰキーイングマテリアル生成できる内部ＥＡＰメソッドを必要とする。
【０１５９】
このメソッドは内部メソッドのＭＳＫから算出されるＭＳＫ及びＥＭＳＫを転送する。故に、転送されたＭＳＫ及びＥＭＳＫの全体の長さは内部メソッドのＭＳＫの長さと同じである。
【０１６０】
本発明の広い範囲
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適合及び／又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、ａ）「〜の手段」又は「〜のステップ」が明記されている、ｂ）対応する機能が明記されている、及びｃ）構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の１つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり）、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び／又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「ｅ．ｇ．」という省略用語が用いられ得る。
【技術分野】
【０００１】
本発明は、無線ネットワーク、幾つかの好適実施形態では、ピアとサーバとの間で一貫性維持のために照合されるパラメータをチャネル結合するシステム及び方法に関する。
【背景技術】
【０００２】
ネットワーク及びインターネット（登録商標）プロトコル
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業及び個人へのアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。
【０００３】
ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。
【０００４】
ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれる構成要素に分割される。各パケットは、独立のデータ単位として扱われる。
【０００５】
インターネットなどのネットワークを介した各点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク中の２点間の通信プロセスを７つの階層に分け、各層（レイヤ）は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。７つの機能層を提供するプログラミング及び／又はハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰ及び／又は他のトランスポート及びネットワークプロトコル、並びに他のソフトウェア及びハードウェアの組み合わせである。
【０００６】
通常、上位４層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位３層は、メッセージが装置（ＩＰホスト装置など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。ＯＳＩモデルの各層を以下に列記する。第７層（すなわち、アプリケーション層）は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証及びプライバシが考慮され、データ構文に対する制約条件が識別される層である。第６層（すなわち、プレゼンテーション層）は、例えば、着信及び発信データをあるプレゼンテーション形式から別の形式に変換する層である。第５層（すなわち、セッション層）は、例えば、アプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了させる層である。第４層（すなわち、トランスポート層）は、例えば、エンドツーエンド制御及び誤りチェックなどを管理する層である。第３層（すなわち、ネットワーク層）は、例えば、経路指定や転送などを処理する層である。第２層（すなわち、データリンク層）は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識及び管理などを提供する層である。米国電気電子技術者協会（ＩＥＥＥ）では、データリンク層を、物理層との間のデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うＬＬＣ（論理リンク制御）層という、２つのさらなる副層（サブレイヤ）に細分する。第１層（すなわち、物理層）は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。ＩＥＥＥでは、物理層を、ＰＬＣＰ（物理層収束手順）副層とＰＭＤ（物理媒体依存）副層とに細分する。
【０００７】
無線ネットワーク：
無線ネットワークは、例えば、セルラ及び無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び／又はデータの高速無線伝送を確保するデジタルシステムを含むことができる。一般的なモバイル機器は、次の構成要素の一部又は全部、即ち送受信機（すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機）、アンテナ、プロセッサ、１つ又は複数の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、デジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）及び／又は同種のものを含む。
【０００８】
モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いることができる。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含めることができる。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ標準が存在する。
【０００９】
一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、及び他のモバイル機器の間のリンク、並びにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の名称概念に従って名称付けできる。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）又は一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名称を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器は、ＩＰアドレス及びＩＰ（ネットワーク）名を備えることができる。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、ＢＤＮ、ＢＤＡ、ＩＰアドレス及びＩＰ名などを含むことができる。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名称を指す。
【００１０】
ＩＥＥＥ標準であるＩＥＥＥ８０２．１１は、無線ＬＡＮ及び機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含めることができ、カードなどの別個のハードウェアをインストールすることもできる。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であるか、移動局（ＳＴＡ）であるか、ブリッジであるか、ＰＣＭＣＩＡカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべき要素を含む。
【００１１】
更に、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）が利用できる。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含むことができ、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレス、及びＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を持つことができる。
【００１２】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Wireless Fidelity）機器、ＧＰＲＳ（汎用パケット無線システム）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（移動通信用グローバルシステム）機器、ＥＤＧＥ（Enhanced Data for GSM Evolution）機器、ＴＤＭＡ型（時分割多重接続）機器、又はＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含めることができる。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、ＩＥＥＥ ＭＡＣアドレスを含む、様々な種類のアドレスを含むことができる。
【００１３】
また、無線ネットワークは、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、及び他のモバイルネットワークシステムにおいて見られるメソッド及びプロトコルも関与できる。モバイルＩＰでは、これに、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、これらの一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメントリクエスト（ＲＦＣ）３３４４を参照されたい。（注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。）モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワーク及びこれのサブネット内の機器の現在位置を識別する気付アドレス（ＣｏＡ）を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。
【００１４】
（例えば、モバイルＩＰ外部などの）基本的なＩＰ経路指定において、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、及び／又は転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。一般的なモバイルＩＰ通信の場合、ユーザが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスク及びデフォルトのルータを用いて再構成する必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。
【００１５】
メディア独立の事前認証：
メディア独立の事前認証（ＭＰＡ）は、任意のリンク層を介して、任意のモビリティ管理プロトコルと共に動作する、モバイル支援型の、安全なハンドオーバ最適化方式である。ＭＰＡを用いれば、移動ノードは、候補ターゲットネットワーク（ＣＴＮ）のＩＰアドレスと他の構成パラメータを安全に獲得することができるだけでなく、ＣＴＮに実際に接続する前に、獲得したＩＰアドレスを使ってＩＰパケットを送受信することもできる。これは、移動ノードが、リンク層におけるハンドオーバを実行する前に、任意のモビリティ管理プロトコルの対応付け更新を完了し、新しい気付アドレス（ＣｏＡ）を使用することを可能にする。
【００１６】
ＭＰＡは、任意のリンク層を介して、モバイルＩＰｖ４、モバイルＩＰｖ６、ＭＯＢＩＫＥ、ＨＩＰ、ＳＩＰモビリティなどを含む任意のモビリティ管理プロトコルと共に動作する。ＭＰＡでは、ＩＥＥＥ８０２．１１ｉ事前認証の概念が、上位層で動作するように拡張され、移動端末がそこに移動できるネットワークからのＩＰアドレスの早期獲得と、移動端末がまだ現在のネットワークに接続されている間にネットワークへの事前対応型ハンドオーバとを実行する追加機構を組み込んでいる。
【００１７】
ＭＰＡをサポートする移動ノード（ＭＮ）は、認証エージェント（ＡＡ）との事前認証プロセスを開始する。正常な認証により、ＰＡＮＡ認証エージェント（ＰＡＡ）が、ＡＡとセキュリティアソシエーションを確立することが可能になる。これが、ＩＰアドレスと他の構成パラメータを移動ノードに安全に配信するための構成プロトコルを安全に実行するのに使用される構成エージェント（ＣＡ）と、移動ノードへの事前対応型ハンドオーバトンネルを確立するためのトンネル管理プロトコルを安全に実行するアクセスルータ（ＡＲ）に加わる。この全プロセスが、ＭＮが現在の接続点に接続されるときに実行される。これは、参照によりこれの開示が本明細書に組み込まれる、２００６年３月の「draft-ohba-mobopts-mpa-framework-02.txt」と、２００６年１０月２２日の「draft-ohba-mobopts-mpa-framework-03.txt」で詳細に説明されている。
【００１８】
安全なネットワークアクセスサービスを提供することは、クライアントとアクセスネットワークの認証と許可に基づくアクセス制御を必要とする。クライアントからネットワークへの認証は、実行点を通るトラフィックフローを規制するのに必要とされるパラメータを提供する。クライアントとアクセスネットワークの間で認証メソッドを搬送するプロトコルが必要とされる。
【００１９】
ＰＡＮＡは、ネットワークアクセス認証メソッドのためのリンク層不可知トランスポートを提供する。拡張可能認証プロトコル（ＥＡＰ）［参照により全体が本明細書に組み込まれるRFC3748を参照］は、かかる認証メソッドを提供する。これに関して、ＰＡＮＡは、様々な認証メソッドを搬送することのできるＥＡＰを搬送する。ＩＰより上でのＥＡＰのトランスポートを可能にすることによって、ＥＡＰメソッドとして伝えることができる任意の認証メソッドがＰＡＮＡに利用でき、故に任意のリンク層技術に利用できる。
【００２０】
ＰＡＮＡプロトコル[I-D.ietf-pana-pana]は、アクセスネットワーク内のＰａＣ（ＰＡＮＡクライアント）とＰＡＡ（ＰＡＮＡ認証エージェント）の間でＥＡＰメッセージを伝送する。ＰａＣがモバイル機器であり、これのアプリケーションを実行する間に、あるアクセスネットワークから別のアクセスネットワークに移動することができる場合、このＰａＣが、ハンドオーバ期間中にアプリケーションの性能を低下させずに、シームレスにハンドオーバを行うことは重要である。ＰａＣが新しいアクセスネットワーク内のＰＡＡとＰＡＮＡセッションを確立することをハンドオーバが必要とするとき、ＰＡＮＡセッションを確立する信号は、できるだけ速く完了されるべきである。
【００２１】
ＰＡＮＡプロトコルは、ネットワークアクセスサービスのための認証と許可を行うために、クライアント（ＰａＣ）とサーバ（ＰＡＡ）の間で実行される。このプロトコルのメッセージングは、一連のリクエストとレスポンスを伴い、これらのうちのいくつかが、どちらかの側によって開始できる。各メッセージは、ペイロード内でゼロ以上のＡＶＰを伝送することができる。ＰＡＮＡの主要ペイロードは、認証を実行するＥＡＰである。ＰＡＮＡは、ＰａＣとＰＡＡが、ＥＡＰセッションを確立するのに役立つ。
【００２２】
他の背景情報としてProtocol for Carrying Authentication for Network Access (PANA), Internet Draft of the PANA Working Group of the I.E.T.F., document no. draft-ietf-pana-pana-12, dated August 24, 2006, to D. Forsberg, Y. Ohba, et al.を参照する。この文献の全開示はここに全て開示されているように参照により本明細書に援用される。
【００２３】
ＥＡＰ
（以下に引用する）Aboba, RFC 3748を参照すると、拡張認証プロトコル（ＥＡＰ）の具体的態様が説明されている。ＥＡＰは複数の認証メソッドをサポートする認証フレームワークである。ＥＡＰは一般的にはＩＰを必要としない、ポイントツーポイントプロトコル（ＰＰＰ）又はＩＥＥＥ８０２のような複数のデータリンク層上で直接に実行する。ＥＡＰは二重削除及び再送信のため独自のサポートを備えているが、下位層順の保証に依存する。断片化はＥＡＰ自体内でサポートされないが、個々のＥＡＰメソッドがこれをサポートできる。
【００２４】
ＥＡＰは切換回路だけでなく、専用リンクに使用でき、無線リンクだけでなく有線であってもよい。今まで、ＥＡＰはＰＰＰ[RFC1661]を用いて切換回路又はダイアルアップネットワークを介して接続するホスト及びルータによって実現されていた。それはまたＩＥＥＥ ８０２［ＩＥＥＥ−８０２］を用いてスイッチ及びアクセスポイントによっても実現されていた。ＩＥＥＥ ８０２有線媒体に関するＥＡＰカプセル化が[IEEE-802.1X]に説明されており、ＩＥＥＥ無線ＬＡＮｓに関するカプセル化は[IEEE-802.11i]に開示されている。
【００２５】
ＥＡＰアーチテクチャの利点の１つはその柔軟性にある。ＥＡＰは、特定の認証機構を選択するために用いられ、その際、Authenticatorが使用すべき特定の認証メソッドを決定するためにピアに対しより多くの情報を要求する。各新しい認証メソッドをサポートするために更新されることをAuthenticatorが必要とすることなく、ＥＡＰは幾つか又は全てのメソッドおよびピアに対するパススルーとして動作するAuthenticatorによって、幾つか又は全ての認証メソッドを実施できるバックエンド認証サーバの使用を可能にする。
【００２６】
この後者の引用文献の中で、Authenticatorがパススルーとして動作するか否かに関係なくAuthenticatorの要求が適用される。要求がAuthenticator又はバックエンド認証サーバのいずれかに適用されることを意味している場合、ＥＡＰ認証が終了される場所に依存して、用語「ＥＡＰサーバ」が使用されている。
【００２７】
ＥＡＰはメッセージの再送信をサポートする一方で、それは下位層によって提供される順序付け保証を仮定し、故にメッセージの到達順序に異常のある受信はサポートされない。
【００２８】
ＥＡＰはメッセージの断片化（フラグメンテーション）及び再構築（リアセンブリ）をサポートしないので、最小ＥＡＰ ＭＴＵより大きなペイロードを生成するＥＡＰ認証メソッドは断片化サポートを提供する必要がある。
【００２９】
ＥＡＰ−ＴＬＳのような認証メソッドはメッセージの断片化及び再構築を提供するが、この後者の引用文献で定義されたＥＡＰメソッドは行わない。その結果、ＥＡＰパケットサイズがリンクのＥＡＰ ＭＴＵを越えれば、これらのメソッドは困難に合うことになる。
【００３０】
ＥＡＰ認証はサーバ（Authenticator）によって初期化されるが、多くの認証プロトコルはクライアント（ピア）によって初期化される。その結果、ＥＡＰを通過するために１つ又は２つの追加メッセージ（多くとも１往復）を追加することが認証アルゴリズムに必要となるかもしれない。
【００３１】
証明利用認証がサポートされる場合、追加往復の数は証明書連鎖（certificate chains）の断片化によりかなり多くなるかもしれない。一般的に、断片化ＥＰＡパケットは断片があるだけ多くの往復で送る必要がある。例えば、サイズが１４９６０オクテットの証明連鎖は１４９６オクテットＥＡＰ ＭＴＵで１０往復する必要がある。ＥＡＰが重大なパケットロスを起こす下位層上で動作する場合、又はAuthenticatorと認証サーバとの接続が重要なパケットロスを起こす場合、多くの往復を必要とするＥＡＰメソッドは困難に直面することもある。これらの状況において、少ない往復を用いたＥＡＰメソッドの使用が望まれる。
【００３２】
ＥＡＰ認証交換は次のように処理される。即ち、
［１］Authenticatorはピアを認証するためリクエスト（Request）を送る。リクエストは要求されているものを示すタイプフィールドを有する。リクエストタイプの例は識別、ＭＤ５−チャレンジなどを含む。ＭＤ５−チャレンジタイプはＣＨＡＰ認証プロトコルに密接に対応する［RFC1994参照］。一般的には、Authenticatorは初期認証リクエストを送ることになるが、初期認証リクエストは必要とされなく、バイパスされないこともある。例えば、識別はピアが接続されているポート（専用回線、専用スイッチ又はダイアルアップポート）によって決定される場合、又は識別が（ＭＤ５−チャレンジレスポンスなどのネームフィールドにおいて、呼出局識別又はＭＡＣアドレスを介して）他のメソッドで得られる場合には要求されないこともある。
【００３３】
［２］ピアは有効リクエストに答えてレスポンスパケット（Response packet）を送る。リクエストパケットと同様に、レスポンスパケットはリクエストのタイプフィールドに対応するタイプフィールドを含む。
【００３４】
［３］Authenticatorは追加リクエストパケットを送り、ピアはレスポンスで答える。リクエスト及びレスポンスのシーケンスは必要なだけ継続する。ＥＡＰは‘横並び（lock step）’プロトコルであり、故に、初期リクエスト以外は、新たなリクエストは有効なレスポンスを受理する前に送ることができない。Authenticatorはリクエストを再送信する責任がある。適正数の再送信の後には、AuthenticatorはＥＡＰ対話を終了しなくてはならない。Authenticatorは再送信したとき、又はピアからのレスポンスが得られないときには成功又は失敗パケットを送る必要がない。
【００３５】
［４］対話はAuthenticatorがピア（１以上のリクエストに対して受入れがたいレスポンス）を認証できなくなるまで続けられる。この場合、Authenticatorの実行にはＥＡＰ失敗（コード４）を送信する必要がある。あるいは、認証対話は認証が成功したことをAuthenticatorが決定するまで継続する。この場合、AuthenticatorはＥＡＰ成功（コード３）を送信する必要がある。
【００３６】
他の利点では、ＥＡＰプロトコルは特定のものを事前取り決めする必要が無く多くの認証機構をサポートできる。更に、ネットワークアクセスサーバ（ＮＡＳ）装置（例えば、スイッチ又はアクセスポイント）は各認証メソッドを理解する必要が無く、バックエンド認証サーバに対するパススルーエージェントとして動作できる。パススルーのためのサポートは随意的である。Authenticatorは局所ピアを認証でき、更に、同時に非局所ピア及び局所的には実行しない認証メソッドに対するパススルーとして作用する。更に、バックエンド認証サーバからAuthenticatorを分離することによって証明管理及びネットワークアクセスポリシー決定を簡単にする。
【００３７】
概念的に、ＥＡＰ実施は次の要素からなる。
【００３８】
［ａ］下位層。下位層はピアとAuthenticatorとの間でＥＡＰを送受信する義務がある。ＥＡＰはＰＰＰ，有線ＩＥＥＥ８０２ラン［IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11], UDP (L2TP [RFC2661]及びIKEv2参照）及びＴＣＰを含む各種下位層上で実行していた。
【００３９】
［ｂ］ＥＡＰ層。ＥＡＰ層は下位層を介してＥＡＰパケットを送受信し、二重検出及び再送信を実行し、ＥＡＰメッセージをＥＡＰピア及びAuthenticator層に搬送し及びAuthenticator層から受信する。
【００４０】
［ｃ］ＥＡＰピア及びAuthenticator層。コードフィールドに基づいて、ＥＡＰ層は入力ＥＡＰパケットをＥＡＰピア及びAuthenticator層に分離する。一般的には、所定ホストでのＥＡＰ実行はピア又はAuthenticator機能のいずれかをサポートすることになるが、ホストがＥＡＰピア及びAuthenticatorの両方として作用することを可能にする。そのような実行においては、ＥＡＰ及びAuthenticator層の両方が存在することになる。
【００４１】
［ｄ］ＥＡＰメソッド層。ＥＡＰメソッドはAuthenticatorアルゴリズムを実行し、ＥＡＰピア及びAuthenticator層を介してＥＡＰメッセージを送受信する。断片化のサポートはＥＡＰ自体によっては得られないが、これはＥＡＰメソッドの責任である。
【００４２】
以後の参考文献はここに参照として引用される次の定義を説明している。
【００４３】
Authenticator
ＥＡＰ認証を初期化するリンクの終端。Authenticatorという用語は[IEEE-802.1X]に使用され、この明細書では同様の意味を有する。
【００４４】
ピア
Authenticatorに応答するリンクの終端。[IEEE-802.1X]では、この終端はSupplicantとして知られている。
【００４５】
バックエンド認証サーバ
バックエンド認証サーバは認証サービスをAuthenticatorに提供する個人である。使用時には、このサーバは一般的にはAuthenticatorのためにＥＡＰメソッドを実行する。この専門用語は[IEEE-802.1X]に使用されている。
【００４６】
ＡＡＡ
ＥＡＰサポートを持つ認証、許可、及び課金（ＡＡＡ）プロトコルはＲＡＤＩＵＳ及びダイアミタ（Diameter）を含む。この明細書では、用語“ＡＡＡサーバ”及び“バックエンド認証サーバ”は交換可能に使用される。
【００４７】
ＥＡＰサーバ又はサーバ
ピアによってＥＡＰ認証メソッドを終了する個人バックエンド認証サーバが使用されない場合には、ＥＡＰサーバはAuthenticatorの一部である。Authenticatorがパススルーモードで行動する場合、ＥＡＰサーバはバックエンド認証サーバに設けられる。
【００４８】
成功した認証
この明細書の内容では、「成功した認証」はＥＡＰメッセージの交換であり、その結果Authenticatorはピアによってアクセスできることを決定し、ピアがこのアクセスを使用することを決定する。Authenticatorの決定は一般的には認証及び許可面の両方を含み、ピアはAuthenticatorに首尾良く証明できるが、アクセスは政策的理由によりAuthenticatorによって拒絶されるかもしれない。
【００４９】
マスタセッションキー（ＭＳＫ）
ＥＡＰピアとサーバ間で得られ、ＥＡＰ法によって転送されるキーイングマテリアル。ＭＳＫは長さが少なくとも６４オクテットである。既存の実施では、ＥＡＰサーバとして作用するＡＡＡサーバはＭＳＫをAuthenticatorに搬送する。
【００５０】
拡張マスタセッションキー（ＥＭＳＫ）：
ＥＡＰクライアントとサーバ間で得られ、ＥＡＰ法によって転送される追加キーイングマテリアル。ＥＭＳＫは長さが少なくとも６４オクテットである。ＥＭＳＫはAuthenticator又は任意の他の第三者によっては共有されない。ＥＭＳＫはまだ定義されていない将来の使用のために予約される。
【００５１】
ＥＡＰ拡張
参考のため、出願人はthttp://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-04.txtのサイトに掲載されているEAP Extensions for EAP Reauthentication Protocol (ERP), IETF Internet Draft, August 24, 2007, of V. Narayanan, et alを参照する。この参考文献は次のようにＥＡＰ再認証プロトコルのためのＥＡＰ拡張を説明している。拡張可能認証プロトコルは２つのグループを認証するメソッドの搬送のための総括フレームワークであり、認証は一方向又は相互のいずれかである。第１目的はネットワークアクセス制御であり、キー生成メソッドはアクセス制御を実施するために推奨される。ＥＡＰキーイング階層は２つのキーを定義する。これらのキーはトップレベルで、即ちマスタキーセッション（ＭＳＫ）及び拡張ＭＳＫ（ＥＭＳＫ）で得られる。最も一般的な展開シナリオにおいては、ピア及びサーバはAuthenticatorとして知られている第三者を介して互いに認証する。Authenticator又はAuthenticatorによって管理される個人はアクセス制御を実施する。成功した認証後には、サーバはＭＳＫをAuthenticatorに搬送し、Authenticator及びピアはＭＳＫを認証キー又はキー導出キーとして用いて一時セッションキー（ＴＳＫ）を取得し、単位パケットアクセス実施のためにＴＳＫを使用する。ピアがあるAuthenticatorから他のAuthenticatorに移動するときは、完全ＥＡＰ認証を避けることが望ましい。ＥＡＰメソッドの他の実施を伴う完全ＥＡＰ交換は完了するためにいくつかの往復及びかなりの時間を取り、ハンドオフ時間に遅延が生じる。幾つかのＥＡＰ法は計算オーバヘッドを減じることによって再認証を最適化するために初期認証から状態の使用を特定し、メソッド特定再認証は殆どのケースでは少なくとも２往復する。多くのメソッドは再認証のためにサポートを提供しないことに注意することが重要でもある。故に、個々のメソッドにおけるよりもＥＡＰにおいて効果的な再認証サポートを持つのが良い。
【００５２】
Authenticator間で共有するキーは時々ハンドオフタイムを低減するため現実的な解決法として使用される。その場合、Authenticatorの譲歩は他のAuthenticatorを介して確立されるＥＡＰセッションの譲歩となる。要するに、再びＥＡＰメソッドを実行することを必要としないでピアとAuthenticator間にフレッシュキーを確立することを可能にする有効ＥＡＰ再認証機構を設計する必要がある。この明細書はＥＡＰを用いて有効再認証のためにＥＡＰ再認証拡張（ＥＲＸ）を特定している。ＥＲＸに基づくＥＡＰ再認証プロトコル（ＥＲＰ）はピアに対するＥＡＰメソッド非依存再認証をサポートする。このピアは以前に実行されたＥＡＰ認証からの有効な残りキーマテリアルを有する。プロトコル及びＥＡＰ再認証に必要なキー階層がこの明細書に記載されている。
【００５３】
次の背景参考文献は個々に参照としてここに援用される。
【先行技術文献】
【非特許文献】
【００５４】
【非特許文献１】Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (ここでは[RFC2119]と称する).
【非特許文献２】Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)," RFC 3748, June 2004 (ここでは[RFC3748]と称する).
【非特許文献３】Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-16 (work in progress), January 2007 (ここでは[I-D.ietf-eap-keying]と称する); 及び [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-15 (work in progress), October 2006.
【非特許文献４】Narayanan, V. and L. Dondeti, "Problem Statement on EAP Efficient Re-authentication and Key Management", draft-vidya-eap-reauth-ps-00 (work in progress), October 2006 (ここでは[I-D.vidya-eap-reauth-ps]と称する).
【非特許文献５】Ohba, Y., "Channel Binding Mechanism based on Parameter Binding in Key Derivation", draft-ohba-eap-channel-binding-02 (work in progress), December 2006 (ここでは[I-D.ohba-eap-channel-binding]と称する).
【非特許文献６】Salowey, J., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", draft-salowey-eap-emsk-deriv-01 (work in progress), June 2006 (ここでは[I-D.salowey-eap-emsk-deriv]と称する).
【非特許文献７】National Institute of Standards and Technology, "Secure Hash Standard", August 2002 (ここでは[sha256]と称する).
【非特許文献８】Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", http://tools.ietf.org/html/draft-arkko-eap-service-identity-auth-04, October 2005 (ここでは[arkko-eap-service-identity-auth]と称する).
【非特許文献９】Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005 (ここでは[RFC4306]と称する).
【非特許文献１０】Narayanan, V. and L. Dondeti, "EAP Re-authentication Extensions", draft-ietf-hokey-erx-02 (work in progress), July 2007 (ここでは[I-D.ietf-hokey-erx]と称する).
【非特許文献１１】Salowey, J., "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-01 (work in progress), June 2007 (ここでは[I-D.ietf-hokey-emsk-hierarchy]と称する). 各種方式及び方法は知られているが、改良された方式及び方法の必要性がある。
【発明の概要】
【発明が解決しようとする課題】
【００５５】
本発明は背景技術における各種制限及び欠陥を解消する。本出願は以下に述べるように下記のような発明セットを含む、複数の発明を盛り込んでいる。
【課題を解決するための手段】
【００５６】
発明セット♯１：
幾つかの実施形態によると、クライアントとサーバ間のメソッドの認証方法はａ）クライアントとサーバ間に認証機構を有さないメソッドを採用すること、及びｂ）クライアントを認証するために前記メソッドに内部認証メソッドを当てにさせることを含む。好ましくは、メソッドは内部に第２ＥＡＰを持つ認証機構を有さない第１ＥＡＰメソッドであり、第２ＥＡＰはクライアントを認証するために使用される。
【００５７】
発明セット♯２：
幾つかの他の実施形態によると、ＥＡＰ拡張機能性に関する能力を交渉するためＥＡＰピア及びＥＡＰサーバのためのメソッドは、サーバと拡張機能性に関するクライアントとの能力交換を提供するＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）を採用することを含み、拡張機能性は認証機構を持たなく少なくとも１つのＥＡＰメソッドはＥＡＰピアを認証するためのＥＡＰ拡張メソッド以内で実行する。幾つかの実施形態では、本方法は内部ＥＡＰメソッドにキーイングマテリアルを生成させること、外部ＥＡＰ拡張メソッドのメッセージをＡＵＴＨ ＴＬＶでサポートすることを更に含む。幾つかの実施形態では、本方法は外部ＥＡＰ拡張メッセージのＡＵＴＨ ＴＬＶｓは最近成功した内部メソッドのＥＡＰキーイングマテリアルから生成されるＥＡＰ拡張キー（ＥＡＰ−ＥＸＴ−ＫＥＹ）を用いて計算されることを更に含む。幾つかの実施形態では、本方法はＥＡＰ拡張キーがＥＡＰ−ＥＸＴメッセージをサポートする完全性のためのＡＵＴＨ ＴＬＶｓを計算するために使用されることを更に含む。幾つかの他の実施形態では、本方法はＥＡＰ拡張キーが使用特定ルートキー導出アルゴリズムを使用して内部ＥＡＰメソッドによって生成されるＥＭＳＫから得られることを更に含む。幾つかの実施形態では、本方法はＥＡＰ拡張メソッドが再認証機構に使用されたＥＡＰメソッドによって要求される事前共有キーとして使用されるＥＡＰ再認証キーを定義することを更に含む。幾つかの実施形態では、本方法はＥＡＰ再認証キーが使用特定ルートキー導出アルゴリズムを用いるＥＡＰ拡張メソッドから排出されるＥＭＳＫから得られることを更に含む。幾つかの実施形態では、本方法は最終メッセージであることを示すために設定できるビット、エラーを示すために設定できる他のビット、複数のビットのバージョンフィールド、将来の拡張のための複数のビットの予約フィールド及び各々が特定の能力に対応する複数のビットの能力フィールドとともに共通ＥＡＰフィールドを含むメッセージフォーマットを用いることを更に含む。幾つかの実施形態では、本方法はサーバ及び拡張機能に関するクライアントとの能力交換は能力ビットの設定によって行われることを更に含む。幾つかの実施形態では、本方法は送信者がチャネル結合機構をサポートすることを能力ビットが示すことを更に含む。幾つかの実施形態では、本方法では能力ビットは送信者が再認証をサポートすることを示すことを更に含む。幾つかの実施形態では、本方法は送信者が再認証をサポートしていることを示す能力ビットが最終リクエスト／ＥＸＴメッセージに設定されるときを更に含み、メッセージがサーバＩＤ ＴＬＶ及びピアＩＤ ＴＬＶを含む。幾つかの実施形態では、本方法は送信サポート再認証が最終リクエスト／ＥＸＴメッセージ及びレスポンス／ＥＸＴメッセージ交換に設定されることを能力ビットが示すとき、ＥＡＰピア及びＥＡＰサーバがＥＡＰ再認証キーを発生することを更に含み、サーバＩＤ及びサーバＩＤに含まれるピアＩＤ並びにピアＩＤ ＴＬＶｓ及びＥＡＰ再認証キーは再認証ＥＡＰメソッドに使用される。幾つかの実施形態では、本方法はＥＡＰ拡張メソッド内で順次実行される複数の内部ＥＡＰメソッドを採用すること及びシーケンスの内部ＥＡＰ法がキーイングマテリアルを生成する毎に新たなＥＡＰ拡張キーを生成することを更に含む。幾つかの実施形態では、本方法はａ）ＥＡＰサーバが少なくとも１つの能力ビットセットでＥＡＰリクエスト／ＥＸＴメッセージを送信し、ｂ）ＥＡＰピアはＥＡＰリクエスト／ＥＸＴメッセージを受信し、少なくとも１つの能力ビットセットでＥＡＰレスポンス／ＥＸＴメッセージを送信することを更に含む。幾つかの実施形態では、本方法はｃ）ＥＡＰ−レスポンス／Ｅｘｔメッセージを受信し、Ｆ−ビットセット、少なくとも１つの能力ビットセット、ピアＩＤ ＴＬＶ，サーバＩＤ ＴＬＶ及びＡＵＴＨ ＴＬＶを持つＥＡＰリクエスト／ＥＸＴメセージを送信すること、ｄ）ＥＡＰピアが上記ｃ）のＥＡＰリクエスト／Ｅｘｔメッセージを受信し、Ｆ−ビットセット，少なくとも１つの能力ビットセット及びＡＵＴＨ ＴＬＶを有するＥＡＰレスポンス／ＥＸＴメッセージを送信すること、ｅ）ＥＡＰ−サーバがｄ）のＥＡＰレスポンス／ＥＸＴメッセージ受信し、ＥＡＰ−成功メッセージを送信することを更に含む。幾つかの実施形態では、本方法はピア又はサーバがエラーを検出する場合のエラーを示すビットセット及びＡＵＴＨ ＴＬＶによってＥＡＰピア又はＥＡＰサーバのいずれかにＥＡＰ拡張メッセージを送信させることを更に含む。幾つかの実施形態において、本方法は能力情報が攻撃者によって攻撃されるのを避けるためにキーイングマテリアルの生成後にサポートメッセージ交換を行うことを更に含む。幾つかの実施形態では、本方法はＥＡＰ拡張メソッド以内に多くのＥＡＰメソッドを順序付けることを更に含む。幾つかの実施形態では、本方法はシーケンスにおいて先に成功した内部メソッドによって生成されるキーを用いる外部ＥＡＰ拡張メソッドと共に各内部ＥＡＰメソッドをサポートすることによって暗号結合を作成し、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルを最後に搬送することを更に含む。
【００５８】
発明セット＃３：
幾つかの他の実施形態によると、プロセッサ、メモリ、デジタルデータ記憶装置、及びデータメッセージを無線で送受信するための少なくとも１つの無線インターフェースを含む無線移動局が設けられ、無線モバイル装置はＥＡＰピアとして動作するようにプログラムされている。無線モバイル装置はｉ）ＥＡＰサーバから少なくとも１つの能力ビットセットによってＥＡＰリクエスト／ＥＸＴメッセージを受信し、ｉｉ）少なくとも１つの能力ビットセットによってＥＡＰレスポンス／ＥＸＴメッセージを送信するようにプログラムされる。
【００５９】
発明セット＃４：
幾つかの他の実施形態によると、無線ネットワーク用のＥＡＰサーバがＥＡＰピアによってＥＡＰ認証メソッドを終了する。ＥＡＰサーバはａ）少なくとも１つの能力ビットセットによってＥＡＰリクエスト／ＥＸＴメッセージをＥＡＰピアに送信し、ｂ）少なくとも１つの能力ビットセットによってＥＡＰレスポンス／ＥＸＴメッセージをＥＡＰピアから受信する。
【００６０】
上記及び／又は他の発明、態様、特徴及び／又は種々実施形態の利点は添付図面と関連して以下の説明を鑑みて更に理解されるであろう。種々実施形態は異なる態様、特徴及び／又は適用できる場合の利点を含める及び／又は除外することができる。更に、種々の実施形態は適用できる場合に他の実施形態の１以上の態様又は特徴を組み合わすことができる。特定の実施形態の態様、特徴及び／又は利点の説明は他の実施形態又は請求項を限定するように解釈されるべきでない。
【図面の簡単な説明】
【００６１】
【図１】幾つかの実施形態に従った単一内部メソッドによってＥＡＰサーバとＥＡＰピアとの間の具体的なＥＡＰ−ＥＸＴメッセージシーケンスを示す図である。
【図２】幾つかの実施形態に従った複数の内部メソッドによってＥＡＰサーバとＥＡＰピアとの間の具体的なＥＡＰ−ＥＸＴメッセージシーケンスを示す図である。
【図３Ａ】幾つかの模範的実施形態に従った具体的メッセージフォーマットを示す図である。
【図３Ｂ】幾つかの模範的実施形態に従った具体的能力フィールドを示す図である。
【図３Ｃ】幾つかの模範的実施形態に従った具体的ＴＬＶフォーマットを示す図である。
【図４】幾つかの追加の実施形態に従った単一内部メソッドによってＥＡＰサーバとＥＡＰピアとの間の具体的なＥＡＰ−ＥＸＴメッセージシーケンスを示す図である。
【図５】幾つかの追加の実施形態に従った複数の内部メソッドによってＥＡＰサーバとＥＡＰピアとの間の具体的なＥＡＰ−ＥＸＴメッセージシーケンスを示す図である。
【図６Ａ】幾つかの追加の模範的実施形態に従った具体的メッセージフォーマットを示す図である。
【図６Ｂ】幾つかの追加の模範的実施形態に従った具体的能力フィールドを示す図である。
【図６Ｃ】幾つかの追加の模範的実施形態に従った具体的ＴＬＶフォーマットを示す図である。
【図７Ａ】暗号アルゴリズムＴＬＶを示す図である。
【図７Ｂ】完全性アルゴリズムＴＬＶを示す図である。
【発明を実施するための形態】
【００６２】
本発明の好適な実施形態は添付図面に一例として示され、限定されない。
【００６３】
本発明は多くの異なる形態で実施できるが、多数の具体的実施形態は本開示がここに記載された種々の発明の原理の例を提供するよう考えられるべきであり、そのような例は個々に記載され及び／又はここに説明されていると言う了解の下で説明されている。
【００６４】
１．序論
ＥＡＰ（拡張可能認証プロトコル）は“ＥＡＰメソッド”[RFC3748]として知られている多くの認証アルゴリズムをサポートする認証プロトコルである。ＥＡＰでは、ＥＡＰピア及びＥＡＰサーバはＥＡＰキーイングマテリアル、即ち、ＭＳＫ（マスタセッションキー）及びＥＭＳＫ（拡張マスタセッションキー）を生成する。ＭＳＫの生成、搬送及び使用の詳しいフレームワークは［I-D.ietf-eap-keying］に記載されている。
【００６５】
ＥＭＳＫ用法の１つが再認証である場合にＥＭＳＫ（拡張マスタセッションキー）の幾つかの用法を定義することによってＥＡＰ[RFC3748]の拡張機能がある。ＥＡＰの他の拡張機能は［I-D.ohba-eap-channel-binding］に定義されているチャネル結合方式である。チャネル結合に関する追加の背景文献として、２００６年４月２０日にY. Ohbaによって出願された、CHANNEL BINDING MECHANISM BASED PARAMETER BINDING IN KEY DERIVATIONと名称付けられた同時継続の出願番号１１／３７９，５６８の全開示が全体として参照することによって本明細書に援用される。ＥＡＰの拡張機能をサポートする実施は拡張機能をサポートしない実施と相互運用する必要があり、故に、前者の実施は後者の実施と通信するとき拡張機能を無効にするので、ＥＡＰピアに対する機構が必要となり、ＥＡＰの拡張機能に関して能力を取り決めるＥＡＰサーバが必要となる。
【００６６】
ＥＡＰ機能を拡張するために２つの基本的な方法がある。１つの方法は既存の方法、即ち、リクエスト、レスポンス、成功及び失敗に加えて拡張ＥＡＰ機能を実現するために新たなＥＡＰコードを定義することである。しかしながら、この方法はＲＦＣ３７４８への変更を必要とし、下位層プロトコルへの変更も必要とするかもしれない。他の方法は拡張機能を実現するために新たなＥＡＰメソッドを定義することである。この明細書は後者の方法が既存のＥＡＰ展開への攻撃を参照にするために後者の方法と取る。
【００６７】
この明細書はＥＡＰ−ＥＸＴ、ＥＡＰ機能を拡張するＥＡＰメソッドを説明している。幾つかの好適実施形態では、拡張ＥＡＰ機能はチャネル結合及び再認証を含む。また、ＥＡＰ−ＥＸＴメソッドはその内部の多くのＥＡＰメソッドの順序づけを可能にする。
【００６８】
２．ＥＡＰ−ＥＸＴ概要
好適実施形態では、ＥＡＰ−ＥＸＴは能力交換を提供する。この点について、メッセージ内のビットは能力の表示に使用できる。幾つかの実施形態では、１ビット（Ｒ−ビット）は再認証能力に使用される。幾つかの実施形態では、１ビット（Ｃ−ビット）はチャネル結合能力を示すために使用される。
【００６９】
ＥＡＰ−ＥＸＴが使用されるとき、サーバが第１のＥＡＰリクエストを送る前にサーバにピアの識別が知られれば先のＥＡＰ−識別交換が省略できる。この点について、ピアの識別をサーバに提供する、例えば、Authenticatorとサーバとの間でピアの識別を転送する幾つかのアウトバンド（outband）機構がある。
【００７０】
ＥＡＰ−ＥＸＴにおいて、チャネル結合及び再認証のような拡張ＥＡＰ能力はピア及びサーバ間で交換される。同時に、少なくとも１つのＥＡＰメソッド（例えば、ＥＡＰ−ＴＬＳ）はピアを認証するためのＥＡＰ−ＥＸＴ内で実行される。内部メソッドがＥＡＰキーイングマテリアルを生成するまで、ＡＵＴＨ ＴＬＶは含まれず、能力はサポートされない。故に、１つの内部ＥＡＰメソッドだけがあれば、ＡＵＴＨ ＴＬＶを有するがメソッドＴＬＶを有さない追加のＥＡＰ−ＥＸＴがＥＡＰ成功又はＥＡＰ失敗メッセージを送る前に実行される。
【００７１】
内部ＥＡＰメソッドはＥＡＰキーイングマテリアルを生成した後、ＥＡＰ−ＥＸＴメッセージはＡＵＴＨ ＴＬＶによってサポートする必要がある。ＥＡＰ−ＥＸＴメッセージの中のＡＵＴＨ ＴＬＶｓは最後に成功した内部メソッドのＥＡＰキーイングマテリアルから生成されるＥＡＰ−ＥＸＴ−ＫＥＹを用いて計算する必要がある。これはＥＡＰ−ＥＸＴ内部で順次実行される複数の内部ＥＡＰメソッドがあれば、新たなＥＡＰ−ＥＸＴ−ＫＥＹがシーケンスの内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを生成する毎に生成されることを意味する。任意の内部ＥＡＰメソッドはＥＡＰキーイングマテリアルを生成できる用になる必要がある。
【００７２】
成功したＥＡＰ−ＥＸＴ実行の最後に、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルはＥＡＰ層に転送される。Ｆ−ビットはＥＸＰ−ＥＸＴ交換の終了を示すために使用される。
【００７３】
図１は単一の内部ＥＡＰメソッドを持つＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。図２は複数の内部ＥＡＰメソッドを有するＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。
【００７４】
３．エラー処理
エラーは複数の理由、例えば、内部ＥＡＰメソッド認証の失敗又は異常、未知、紛失ＥＡＰ−ＥＸＴ ＴＬＶにより生じるかもしれない。エラーはピア又はサーバのいずれかによって検出できる。エラーを起こしたＥＡＰ−ＥＸＴメッセージは誤りメッセージと見なされる。Ｅ−ビットセットを持つＥＡＰ−ＥＸＴメッセージはエラー表示のために使用される。これらのメッセージはエラー表示と見なされる。エラー表示はＡＵＴＨ ＴＬＶを含める必要があり、他のＴＬＶｓを含めるべきでない。
【００７５】
有効ＡＵＴＨ ＴＬＶを持たない（間違ったエラー表示を含む）どんな間違いメッセージも静かに破棄さする必要がある。
【００７６】
有効ＡＵＴＨ ＴＬＶを持つ間違いリクエストに対して、ピアはエラー表示レスポンスを送る。有効ＡＵＴＨ ＴＬＶを伴わない間違いレスポンスに対して、サーバはエラー表示リクエストを送り、このリクエストはエラー表示レスポンスでピアによって応答される。サーバは有効ＡＵＴＨ ＴＬＶ．を伴うエラー表示レスポンスに応答してＥＡＰ失敗メッセージを送り返す。
【００７７】
４．完全性サポートキー
ＥＡＰ−ＥＸＴは２種類のキー、即ち、１）ＥＡＰ−ＥＸＴ−ＫＥＹ及び２）ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹを定義する。
【００７８】
４．１． ＥＡＰ−ＥＸＴ−ＫＥＹは完全性サポートＥＡＰ−ＥＸＴメッセージのためにＡＵＴＨ ＴＬＶｓの計算に使用される。ＨＭＡＣ−ＳＨＡ−２５６（上記文献に含まれる参考[sha256]を参照）は完全性アルゴリズムに使用されると、ＥＡＰ−ＥＸＴ−ＫＥＹの長さは３２オクテットである。ＥＡＰ−ＥＸＴ−ＫＥＹは次のように定義されるＵＳＲＫ（Usage Specific Root Key）導出アルゴリズムを用いて内部ＥＡＰメソッドによって生成されるＥＭＳＫから得られる（例えば、上記に参照することによって援用される文献[I-D.salowey-eap-emsk-deriv]を参照）。
【００７９】
ＥＡＰ−ＥＸＴ−ＫＥＹ ＝ ＫＤＦ （EMSK, "EAP-EXT-Integrity-Key", length）．
ＫＤＦでは、ＥＡＰ−ＥＸＴ−ＫＥＹは上記に参照することによって援用される文献［I-D.salowey-eap-emsk-deriv］に特定されているデフォルトＰＲＦを用いる。
【００８０】
４．２． ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹ
ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは再認証機構に使用されるＥＡＰメソッドによって要求される事前共有キーとして使用される。ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹの長さは再認証機構に依存する。ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは上記で援用される文献［I-D.salowey-eap-emsk-deriv］に次のように定義されるＵＳＲＫ導出アルゴリズムを用いてＥＡＰ−ＥＸＴから転送されるＥＭＳＫから得られる。
【００８１】
ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹ ＝ ＫＤＦ（EMSK, "EAP-EXT-Reauthentication-Key", length）
５． メッセージフォーマット
ＥＡＰ−ＥＸＴは（ＩＡＮＡによって割り当てられるべき）ＥＡＰ Ｔｙｐｅ Ｘを用いる。[RFC3748]に定義された共通ＥＡＰフィールド（例えば、コード、識別子、長さ及び種類）を含むメッセージフォーマットは図３（Ａ）に示される。
【００８２】
Ｆ：
このビットはこれが送信者からの最後のＥＡＰ−ＥＸＴメッセージであることを示すように設定する必要がある。そうでなければ、このビットは設定する必要がない。
【００８３】
このビットはメッセージがエラー表示であるときに設定される。このビットが設定されると、Ｆビットも設定する必要がある。エラー表に関する詳細な説明のセクション３を参照。
【００８４】
バージョン：
この８ビットフィールドはＥＡＰ−ＥＸＴメソッドのバージョンを示す。この明細書はバージョン１を定義している。
【００８５】
予約（Reserved）：
６ビットフィールドは将来の拡張のために予約される。このフィールドは送信者によってゼロに設定する必要があり、受信者はこのフィールドを無視する必要がある。
【００８６】
能力（Capabilities）
能力フィールドが処理するこのフィールドは拡張ＥＡＰ能力を含む。能力は図３（Ｂ）に示されるフォーマットを処理する。
【００８７】
各ビットは特定能力に対応する。各ビットの意味は次の通りである。
【００８８】
Ｃ：
このビットは送信者がＭＳＫのための［I-D.ohba-eap-channel-binding］に定義されるチャネル結合機構をサポートすることを示すために設定される。このビットはリクエスト及びレスポンスの両方に対して設定され、ＥＡＰ−ＥＸＴメソッドが首尾よく完了すると、ピア及びサーバはチャネル結合機構を可能にする必要がある。ｐｒｆ＋用デフォルトハッシュアルゴリズム（default hash algorithm）はＡＵＴＨ＿ＨＭＡＣ＿ＳＨＡ１＿１６０である。
【００８９】
Ｒ：
このビットは送信者が再認証ＥＡＰメソッドをサポートすることを示すために設定される。このビットは最後のリクエスト／ＥＸＴメッセージに設定されると（即ち、Ｆビットを有するリクエスト／ＥＸＴが設定されると）、メッセージはサーバＩＤ ＴＬＶ及びピアＩＤ ＴＬＶを含める必要があり、Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＡＶＰを含めることができる。このビットが最後のリクエスト／ＥＸＴ及びレスポンス／ＥＸＴメッセージ交換に設定されると、ピア及びサーバはＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹを発生する必要がある。サーバＩＤ及びピアＩＤはサーバＩＤ及びピアＩＤ ＴＬＶｓに含められ、ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは再認証ＥＡＰメソッドに使用される。デフォルト再認証機構はこの明細書に基づく従来技術のそれらによって選択できる。
【００９０】
他のビットは将来の使用のために予約され、送信者によってゼロに設定する必要があり、受信者によって無視される必要がある。
【００９１】
ＴＬＶ：
ゼロ、１以上のＴＬＶｓ（Type-Length-Value's）。そのＴＬＶフォーマットは図３（Ｃ）に示される。
【００９２】
タイプ：
このフィールドはこのＴＬＶのタイプを示す。
【００９３】
長さ：
このフィールドは種類及びＴＬＶの長さフィールドを含めて、オクテットでこのＴＬＶの長さを示す。
【００９４】
値
このフィールドはＴＬＶタイプに特定されるデータを含む。
【００９５】
６． ＥＡＰ−ＥＸＴ ＴＬＶｓ
後続ＴＬＶｓが定義される。
【００９６】
６．１．メソッドＴＬＶ
メソッドＴＬＶ（タイプ１）はタイプフィールドから開始するＥＡＰメソッドペイロードを含む。
【００９７】
６．２． ＡＵＴＨ ＴＬＶ
ＡＵＴＨ ＴＬＶ（タイプ２）はＥＡＰ−ＥＸＴメッセージをサポートするために使用される完全性データを含む。ＥＡＰ−ＥＸＴ−ＫＥＹはＡＵＴＨ ＴＬＶｓを計算するために使用される。
【００９８】
ＴＬＶ値フィールドはこのフィールドを含む全体のＥＡＰメッセージわたって計算される。完全性データを計算する前に、このフィールドは全てゼロに初期化する必要がある。このフィールドの長さは使用時に完全性アルゴリズムに依存する。完全性チェックが失敗すると、メッセージは静かに破棄する必要がある。デフォルト完全性アルゴリズムはＨＭＡＣ−ＳＨＡ−２５６である（例えば、上記で援用されている文献[sha256]を参照）。
【００９９】
６．３． ピアＩＤ ＴＬＶ
ピアＩＤ ＴＬＶ（タイプ３）は再認証に使用されるピアの識別を含む。
【０１００】
６．４． サーバＩＤ ＴＬＶ
サーバＩＤ ＴＬＶ（タイプ４）は再認証に使用されるサーバの識別を含む。
【０１０１】
６．５． Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＴＬＶ
Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＴＬＶ（タイプ５）はＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹの寿命を秒単位で含む。
【０１０２】
７． 安全性考慮
内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを送る前に能力交換はサポートされない。故に、ＥＡＰキーイングマテリアルの作成後の追加サポートメッセージ交換は能力情報がピア及びサーバによって検出されないで攻撃者によって変更されるのを避けるために義務付けられる。
【０１０３】
ＥＡＰ−ＥＸＴはその中の多くのＥＡＰメソッドの順序付けを可能にする。複数の入れ子又は順序認証メソッドを暗号的に結合しないでそれらで構成される複合認証メソッドが介入者攻撃に対して無防備さを有する。ＥＡＰ−ＥＸＴはシーケンスにおいて前に成功した内部メソッドによって生成されるキーを用いて外部ＥＡＰメソッド（即ち、ＥＡＰ−ＥＸＴ）と共に各内部ＥＡＰメソッドをサポートし、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルを最終的に転送することによって必要暗号化的結合を作ることができる。暗号化結合を達成するために、ＥＡＰ−ＥＸＴはＥＡＰキーイングマテリアルを生成できる内部ＥＡＰメソッドを必要とする。
【０１０４】
追加ＥＡＰ−ＥＸＴ実施形態
詳細説明の残りは幾つかの内容において上記オリジナル実施形態を越える幾つかの変形例を有する追加のＥＡＰ−ＥＸＴ実施形態について述べる。上記から分かるように、これらの追加実施形態は上述した先の実施形態に多くの点で類似している。これらの実施形態では、拡張機能、例えば、ＨＯＫＥＹ再認証（例えば［I-D.ietf-hokey-erx］参照）及びＭＳＫチャネル結合［I-D.ietf-eap-keying］がＥＡＰ機能を拡張することによってサポートできる。上記で説明したように、ＥＡＰ機能を拡張するために２つの方法がある。１つの方法は既存のもの、即ち、リクエスト、レスポンス、成功及び失敗に加えて拡張ＥＡＰ機能を実現するため新ＥＡＰコードを定義することである。しかしながら、この方法は［ＲＦＣ３７４８］に変更を要求し、Authenticator及び下位層プロトコルに変更を要求することもできる。他の方法は拡張機能を実現するための新たなＥＡＰメソッドを定義することである。両方法について、これら延長機能は下位互換性であることが望まれるかもしれない。そのような場合、ＥＡＰピアとＥＡＰサーバとの間で拡張機能に関する能力を取り決める機構が必要となるかもしれない。
【０１０５】
これらの追加実施形態では、ＥＡＰ機能を拡張するために使用されるＥＡＰメソッドが説明される。拡張機能は、例えば、ＨＯＫＥＹ再認証及びＭＳＫチャネル結合を含む。これらの実施形態での提案ＥＡＰメソッド（ＥＡＰ−ＥＸＴ）は再度それ自体内で多くのＥＡＰメソッドの順序付けをも可能にする。更に、これらの実施形態の中で、ＥＡＰ−ＥＸＴは内部メソッド実施がＭＳＫを生成するがＥＭＳＫ を生成しない場合にＭＳＫ及びＥＭＳＫを発生できる。
【０１０６】
ＥＡＰ−ＥＸＴ概要
ＥＡＰ−ＥＸＴは能力交換を提供する。１ビット（Ｒビット）はＨＯＫＥＹ再認証能力を示すために使用される。１ビット（Ｃビット）はチャネル結合能力を示すために使用される。
【０１０７】
ＥＡＰ−ＥＸＴが使用されるとき、先のＥＡＰ識別交換はサーバがＥＡＰリクエストを送る前にピアの識別がサーバに知られていれば省略できる。ピアの識別を提供する、例えば、Authenticatorとサーバとの間でピアの識別を転送するための帯域外機構が使用できる。
【０１０８】
ＥＡＰ−ＥＸＴにおいて、ＨＯＫＥＹ再認証及びＭＳＫチャネル結合のような拡張ＥＡＰ能力がピアとサーバ間で交換される。同時に、少なくとも１つのＥＡＰメソッド（例えば、ＥＡＰ−ＴＬＳ）がピアを認証するためにＥＡＰ−ＥＸＴ内で実行される。１つ以上の内部メソッドはメソッドＴＬＶｓ（Type-Length-Values）で行われる。内部メソッドがＥＡＰキーイングマテリアルを生成するまで、ＡＵＴＨ ＴＬＶは含まれなく、能力はサポートされない。故に、内部ＥＡＰメソッドだけ存在すれば、ＡＵＴＨ ＴＬＶを持つ追加ＥＡＰ−ＥＸＴ交換は内部メソッドの完了後及びＥＡＰ成功又はＥＡＰ失敗メッセージを送る前に行う必要がある。
【０１０９】
内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを発生した後、ＥＡＰ−ＥＸＴメッセージはＡＵＴＨ ＴＬＶによってサポートする必要がある。ＥＡＰ−ＥＸＴメッセージのＡＵＴＨ ＴＬＶｓは最後に成功した内部メソッドのＥＡＰキーイングマテリアルから生成されるＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹを用いて計算する必要がある。これはＥＡＰ−ＥＸＴ内で順次実行される多くの内部ＥＡＰメソッドがあれば、新たなＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹはシーケンスのうちの内部ＥＡＰがＥＡＰキーイングマテリアルを発生する毎に生成されることを意味する。任意の内部ＥＡＰメソッドはＥＡＰキーイングマテリアルを生成可能にする必要がある。
【０１１０】
成功したＥＡＰ−ＥＸＴの実行の終わりに、ＥＡＰキーイングマテリアルが最後に成功した内部ＥＡＰメソッドによって生成されるＭＳＫから得られ、ＥＡＰ層に転送される。ＥＡＰキーイングマテリアル及びＵＳＲＫｓ（Usage Specific Root Keys）［I-D.ietf-hokey-emsk-hierarchy］を得るために使用される仮想ランダム関数がＰＲＦ ＴＬＶｓを用いてＥＡＰ−ＥＸＴ内で交渉できる。ＦビットはＥＸＰ−ＥＸＴ交換の終了を示すために使用される。
【０１１１】
図４は単一内部ＥＡＰメソッド及びＰＲＦ取り決めを持つＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。図５は複数の内部ＥＡＰメソッドを持つがＰＲＦ交渉を持たないＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。
【０１１２】
エラー取り扱い
上述したオリジナル実施形態でエラー取り扱いに関する検討がここに援用される。
【０１１３】
キー
幾つかの実施形態では、ＥＡＰ−ＥＸＴは次のタイプのキーを定義する。
【０１１４】
ａ．ＥＡＰ−ＥＸＴ から転送されるＭＳＫ及びＥＭＳＫ
ＥＡＰ−ＥＸＴ から転送される６４オクテットＭＳＫ及び６４オクテットＥＭＳＫのセットはＭＳＫ＿ｉから得られ、ＭＳＫは次の方法で［I-D.ietf-hokey-emsk-hierarchy］に定義されたＫＤＦを用いて、最後に成功した内部ＥＡＰメソッドによって生成される。
【０１１５】
(MSK, EMSK) = KDF(MSK_i, "EAP-EXT-EAP-Keying-Material", 128)
ｂ． ＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹ：
ＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹはＥＡＰ−ＥＸＴメッセージを安全にサポートするためにＡＵＴＨ ＴＬＶｓを算出するために用いられる。ＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹはＥＡＰ−ＥＸＴ内だけで使用され、決して転送されない。ＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹは次のように[RFC4306]で定義されたｐｒｆ＋を用いて、最後に成功した内部ＥＡＰメソッド（ＭＳＫ＿ｉ）によって生成されるＭＳＫから求められる。
【０１１６】
EAP-EXT-AUTH-KEY = prf+(MSK_i, "EAP-EXT-認証キー"，長さ）
ｐｒｆ＋用デフォルトハッシュアルゴリズムはＰＲＦ＿ＨＭＡＣ＿ＳＨＡ２＿２５６である。
【０１１７】
フィールド長はＥＡＰ−ＥＸＴ交換中にＥＡＰサーバによって選択される完全性アルゴリズムに依存することになる。ＨＭＡＣ−ＳＨＡ−２５６[sha256]が完全性アルゴリズムに使用されると、長さ＝３２である。
【０１１８】
ｃ． ＥＡＰ−ＥＸＴ−ＥＮＣ−ＫＥＹ：
ＥＡＰ−ＥＸＴ−ＥＮＣ−ＫＥＹは暗号化ＴＬＶｓの内容を暗号化するために使用される。それはＭＳＫ＿ｉから得られ、ＭＳＫは次のように［I-D.ietf-hokey-emsk-hierarchy］で定義されるＫＤＦを用いて、最後に成功した内部ＥＡＰメソッドによって生成される。
【０１１９】
EAP-EXT-ENC-KEY = prf+(MSK_i, "EAP-EXT-Encryption-Key",長さ）；
ＥＡＰ−ＥＸＴ−ＥＮＣ−ＫＥＹを生成するために使用されるＰＲＦはＥＡＰ−ＥＸＴ交換中にＥＡＰサーバによって選択される完全性アルゴリズムによって決定される。ｐｒｆ＋用デフォルトハッシュアルゴリズムはＰＲＦ＿ＨＭＡＣ＿ＳＨＡ２＿２５６である。
【０１２０】
フィールド長はＥＡＰ−ＥＸＴ交換中に取り決められる取り決め暗号化アルゴリズムに依存する。例えば、ＡＥＳ−ＣＢＣ−１２８が使用されるときは、長さ＝１６である。
【０１２１】
ｄ． ＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹ：
ＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹはＨＯＫＥＹ再認証機構［I-D.ietf-hokey-erx］に必要な事前共通キーとして使用される。ＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹの長さはＨＯＫＥＹ再認証機構に依存する。ＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹは次のように［I-D.ietf-hokey-emsk-hierarchy］で定義されるＵＳＲＫ導出アルゴリズムを用いてＥＡＰ−ＥＸＴから転送されるＥＭＳＫから求められる。
【０１２２】
ＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹ ＝ ＫＤＦ（EMSK, "EAP-EXT-再認証キー"，長さ）
メッセージフォーマット
ＥＡＰ−ＥＸＴは（ＩＡＮＡによって割り当てられる）ＥＡＰ Ｔｙｐｅ ＸＸを使用する。[RFC3748]で定義される共通ＥＡＰフィールド（即ち、コード、識別子、長さ及びタイプ）を含むメッセージフォーマットは図６（Ａ）に示される。
【０１２３】
Ｆ：
このビットはこれが送信者からの最後のＥＡＰ−ＥＸＴメッセージであることを示すように設定する必要がある。
【０１２４】
Ｅ：
このビットはメッセージがエラー表示であるときに設定される。このビットが設定されるとき、Ｆビットも設定する必要がある。エラー表示の詳細な説明を以下に示す。
【０１２５】
バージョン
８ビットフィールドはＥＡＰ−ＥＸＴメソッドのバージョンを示す。この明細書はバージョン１を定義する。
【０１２６】
予約
この６ビットフィールドは将来の拡張のために予約される。このフィールドは送信者によってゼロに設定する必要があり、受信者はこのフィールドを無視する必要がある。
【０１２７】
能力
能力フィールドは拡張ＥＡＰ能力を含む。能力フィールドは（図３（Ｂ）と同様であり）幾つかの実施形態において図６（Ｂ）に示されるようなフォーマットを持っている。ここでは、各ビットは特定の能力に対応する。各ビットの意味は次の通りである。
【０１２８】
Ｒ：
このビットは送信者がＨＯＫＥＹ再認証［I-D.ietf-hokey-erx］をサポートすることを示すように設定される。このビットは最後のリクエスト／ＥＸＴメッセージに設定される（即ち、Ｆビットを有するリクエスト／ＥＸＴが設定される）と、メッセージはサーバＩＤ ＴＬＶ及びピアＩＤ ＴＬＶを含める必要があり、Reauth-Key-Lifetime AVPを含めることができる。このビットは最後のリクエスト／ＥＸＴ及びレスポンス／ＥＸＴ交換に設定されると、ピア及びサーバはＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹを生成する必要がある。サーバＩＤ及びピアＩＤはサーバＩＤ及びピアＩＤ ＴＬＶｓに含まれ、ＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹはＨＯＫＥＹ再認証に使用される。
【０１２９】
Ｃ：
このビットは送信者がＭＳＫ用チャネル結合機構をサポートしていることを示すように設定される。このビットはリクエスト／ＥＸＴメッセージに設定されると、１つのチャネル結合機構（Channel-Binding-Mechanism）ＴＬＶもサーバによってサポートされる１つ以上のチャネル結合機構を示すように含める必要がある。ピアがサーバによってサポートされる１つ以上のチャネル結合機構の１つをサポートし、可能にしたければ、それはこのビットセットを持つレスポンス／ＥＸＴメッセージ及び選択チャネル結合機構を含む１つのチャネル結合機構ＴＬＶを送信する。このビットが１つのチャネル結合機構の成功した交渉によって最後のリクエスト／ＥＸＴ及びレスポンス／ＥＸＴ交換に設定され、ＥＡＰ−ＥＸＴメソッドが首尾よく完了すれば、ピア及びサーバは取り決めチャネル結合機構を可能にする必要がある。
【０１３０】
他のビットは将来の使用のために予約され、送信者によってゼロに設定する必要があり、受信者によって無視される必要がある。
【０１３１】
ＴＬＶ：
ゼロ、１以上のＴＬＶｓ（Type-Length-Value's）。そのＴＬＶフォーマットは図３（Ｃ）に示される実施形態と同様である図６（Ｃ）に示されるようである。
【０１３２】
タイプ：
このフィールドはこのＴＬＶのタイプを示す。
【０１３３】
長さ：
このフィールドはＴＬＶのタイプ及び長さフィールドを含めてこのＴＬＶの長さをオクテットで示す。
【０１３４】
値：
このフィールドはＴＬＶタイプに特定するデータを含む。
【０１３５】
ＥＡＰ−ＥＸＴ ＴＬＶｓ：
これらの実施形態では、次のＴＬＶｓが定義される。
【０１３６】
ａ． メソッドＴＬＶ
メソッドＴＬＶ（タイプ１）はタイプフィールドから開始するＥＡＰメソッドペイロードを含む。
【０１３７】
ｂ． ＡＵＴＨ ＴＬＶ
ＡＵＴＨ ＴＬＶ（タイプ２）はＥＡＰ−ＥＸＴメッセージをサポートするために使用される完全性データを含む。ＥＡＰ−ＥＸＴ−ＡＵＴＨ−ＫＥＹはＡＵＴＨ ＴＬＶｓを計算するために使用される。ＴＬＶ値フィールドはこのフィールドを含む全体のＥＡＰメッセージにわたり計算される。完全性データを計算する前に、このフィールドは全てゼロに初期化する必要がある。このフィールドの長さは使用時に完全性アルゴリズムに依存する。完全性チェックが失敗すると、メッセージは静かに破棄する必要がある。デフォルト完全性アルゴリズムはＨＭＡＣ−ＳＨＡ−２５６［ｓｈａ２５６］である。
【０１３８】
ｃ． ピアＩＤ ＴＬＶ
ピアＩＤ ＴＬＶ（タイプ３）はＨＯＫＥＹ再認証に使用されるピアの識別を含む。
【０１３９】
ｄ． サーバＩＤ ＴＬＶ
サーバＩＤ ＴＬＶ（タイプ４）はＨＯＫＥＹ再認証に使用されるサーバの識別を含む。
【０１４０】
ｅ． Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＴＬＶ
Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＴＬＶ（タイプ５）は秒単位でＨＯＫＥＹ−ＲＥＡＵＴＨ−ＫＥＹの寿命を含む。
【０１４１】
ｆ． ＰＲＦ ＴＬＶ
ＰＲＦ ＴＬＶ（タイプ６）は[I-D.ietf-hokey-emsk-hierarchy]で定義される１以上の１−オクテット数を含む。このＴＬＶがリクエストに運び込まれると、それはサーバによってサポートされる１以上のＰＲＦ数を示す。
【０１４２】
このＴＬＶがリクエスト／ＥＸＴメッセージに運び込まれると、対応するレスポンス／ＥＸＴメッセージがこのＴＬＶを含むことができる。レスポンス／ＥＸＴ内のＰＲＦ ＴＬＶはリクエスト／ＥＸＴメッセージのＰＲＦ数の中の、ピアによってサポート及び選択される１つのＰＲＦ数を正確に含める必要がある。ＰＲＦ数が上述されたＰＲＦ ＴＬＶ交換を用いて首尾よく取り決められれば、取り決められた数がＥＡＰ−ＥＸＴ及びＵＳＲＫｓによって転送されるＥＡＰキーイングマテリアルを得るためにＫＤＦに使用される。そうでなければ、[I-D.ietf-hokey-emsk-hierarchy]で特定されたデフォルトＰＲＦがＫＤＦに使用される。
【０１４３】
ｇ． チャネル結合機構ＴＬＶ
チャネル結合機構ＴＬＶ（タイプ７）１以上の１−オクテットチャネル結合機構数を含む。このＴＬＶがリクエスト／ＥＸＴメッセージに運び込まれると、それはサーバによってサポートされる１以上のチャネル結合機構数を示す。このＴＬＶがリクエスト／ＥＸＴメッセージに運び込まれると、対応するレスポンス／ＥＸＴメッセージはこのＴＬＶを含めることができる。レスポンス／ＥＸＴメッセージのチャネル結合機構ＴＬＶはリクエスト／ＥＸＴメッセージのチャネル結合機構数の内の、ピアによってサポートされ、選択される１つのチャネル結合機構数を正確に含める必要がある。チャネル結合機構は上述したチャネル結合機構ＴＬＶ交換を用いて首尾よく取り決められれば、取り決めチャネル結合機構が可能となる。
【０１４４】
以下のチャネル結合機構数はこの明細書において定義されている。即ち、機構1 - [I-D.ohba-eap-channel-binding]及び機構2 - [arkko-eap-service-identity-auth]。
【０１４５】
チャネル結合機構１について、ｐｒｆ＋用デフォルトハッシュアルゴリズムはＰＲＦ＿ＨＭＡＣ＿ＳＨＡ２＿２５６である。
【０１４６】
チャネル結合機構２について、追加チャネル結合データＴＬＶがリクエスト及びレスポンスに運び込まれる。
【０１４７】
ｈ． チャネル結合データＴＬＶ
チャネル結合データＴＬＶ（タイプ８）は[arkko-eap-service-identity-auth]に使用されるオクテットストリングデータを含む。
【０１４８】
ｉ． 暗号化アルゴリズムＴＬＶ
暗号化アルゴリズムＴＬＶは暗号化ＴＬＶｓを暗号化するために使用される暗号化アルゴリズムの取り決めを可能にする。このＴＬＶはリクエスト／ＥＸＴに運び込まれると、それはＥＡＰサーバによってサポートされる暗号化アルゴリズムを示す。このＴＬＶがリクエスト／ＥＸＴメッセージに運び込まれると、対応するレスポンス／ＥＸＴメッセージはこのＴＬＶを含むことができる。レスポンス／ＥＸＴメッセージの暗号化アルゴリズムＴＬＶはリクエスト／ＥＸＴメッセージに含まれる暗号化アルゴリズムＴＬＶのオプション内の、ピアによってサポートされ、選択された１つの暗号化アルゴリズム数を正確に含める必要がある。ＥＡＰサーバはデフォルト暗号化アルゴリズム（ＡＥＳ−ＣＢＣ−１２８）を使用するためＥＡＰピアを強制できることに留意する。そのような場合、ＥＡＰピアはリクエスト／ＥＸＴメッセージに暗号化アルゴリズムＴＬＶを含めなく、同様に、ＥＡＰピアはレスポンス／ＥＸＴメッセージにもそれを含めない。参考のため、図７（Ａ）は暗号化アルゴリズムＴＬＶを示している。
【０１４９】
それは次のように定義された１以上の１−オクテット数を含む。
【０１５０】
０ 予約
１ ＡＥＳ−ＣＢＣ−１２８（デフォルト）
２ ＡＥＳ−ＣＢＣ−２５６
３ ３ＤＥＳ
４ ＩＤＥＡ
アルゴリズムは暗号化アルゴリズムＴＬＶを用いて首尾よく交渉できなければ、デフォルト暗号化アルゴリズムが代わりに使用される。
【０１５１】
ｊ． 完全性アルゴリズムＴＬＶ
ＥＡＰ−ＥＸＴメソッドは簡単にするために及び競り下げ攻撃（bidding-down attacks）を避けるために完全性アルゴリズム取り決めを可能にしない。しかしながら、ＥＡＰサーバは異なる完全性アルゴリズムから選択でき、完全性アルゴリズムＴＬＶを介してこの選択についてＥＡＰピアに知らせる。ＥＡＰサーバがこのＴＬＶを含んでいなければ、デフォルト値がＨＭＡＣ−ＳＨＡ−２５６となる。参考のため、図７（Ｂ）は完全性アルゴリズムＴＬＶを示している。
【０１５２】
それは次のリストに定義された１以上の１−オクテット数を含む。
【０１５３】
０ 予約
１ ＨＭＡＣ−ＳＨＡ−１
２ ＨＭＡＣ−ＳＨＡ−２２４
３ ＨＭＡＣ−ＳＨＡ−２５６（デフォルト）
４ ＨＭＡＣ−ＳＨＡ−３８４
５ ＨＭＡＣ−ＳＨＡ−５１２
ｋ． 暗号化ＴＬＶ
暗号化ＴＬＶ（タイプ１０）はＥＡＰ−ＥＸＴ−ＥＮＣ−ＫＥＹによって暗号化された１以上の標準文字を含む。このフィールドの長さは使用時に暗号化アルゴリズムに依存する。図７（Ｃ）を参照する。
【０１５４】
それは次のように定義された１以上の１−オクテット数を含む。
【０１５５】
タイプ：
（１０） 暗号化ＴＬＶ
長さ：
４＋ＩＶ長＋暗号化データ長．
ＩＶ：
ＩＶは最初が最上位ビットであるランダムビットのオクテットストリングである。ＩＶの長さは使用時の暗号化アルゴリズムに依存する。例えば、ＡＥＳ−ＣＢＣ−１２８について、ＩＶは１６バイト（１２８ビット）である。
【０１５６】
暗号化データ
可変長の暗号化ＴＬＶ。暗号化データはＥＡＰ−ＥＸＴ−ＥＮＣ−ＫＥによって暗号化された１以上の標準文字ＴＬＶｓから成る。暗号化アルゴリズム及び標準文字データの長さに依存して、暫定データが暗号化動作の以前に標準文字データに加算できる。
【０１５７】
セキュリティ上の配慮
内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを転送する前の能力交換はサポートされない。故に、ＥＡＰキーイングマテリアルの生成後の追加サポートメッセージ交換はピア及びサーバによって検出されないで能力情報が攻撃者によって変更されることを回避するために義務付けられる。
【０１５８】
ＥＡＰ−ＥＸＴはその内部の複数のＥＡＰメソッドの順序付けを可能にする。複数の入れ子又は順序付けられた認証メソッドを暗号的に結合しないでそれらにより構成される組合せ認証メソッドはman-in-the-middle攻撃に対しては脆弱である。ＥＡＰ−ＥＸＴはシーケンス内での先に成功した内部メソッドによって生成されるキーによって外部ＥＡＰメソッド（即ち、ＥＡＰ−ＥＸＴ）と共に各内部ＥＡＰメソッドをサポートし、最後に成功した内部ＥＡＰメソッドによって生成されるキーから得られるＥＡＰキーイングマテリアルを転送することによって必要暗号化結合を作ることができる。暗号化結合を達成するために、ＥＡＰ−ＥＸＴはＥＡＰキーイングマテリアル生成できる内部ＥＡＰメソッドを必要とする。
【０１５９】
このメソッドは内部メソッドのＭＳＫから算出されるＭＳＫ及びＥＭＳＫを転送する。故に、転送されたＭＳＫ及びＥＭＳＫの全体の長さは内部メソッドのＭＳＫの長さと同じである。
【０１６０】
本発明の広い範囲
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適合及び／又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、ａ）「〜の手段」又は「〜のステップ」が明記されている、ｂ）対応する機能が明記されている、及びｃ）構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の１つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり）、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び／又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「ｅ．ｇ．」という省略用語が用いられ得る。
【特許請求の範囲】
【請求項１】
クライアントとサーバ間のメソッドの認証のための方法であって、
ａ）クライアントとサーバ間に認証機構を持たないメソッドを採用すること、
ｂ）前記クライアントを認証するために前記メソッドを内部認証メソッドに依存させること、
を含む方法。
【請求項２】
前記メソッドは第１のＥＡＰメソッドであり、この第１のＥＡＰメソッドは前記クライアントを認証するために使用される第２のＥＡＰメソッドを内部に持つ認証機構を有さない、請求項１の方法。
【請求項３】
ＥＡＰ拡張機能性に関する能力を交渉するＥＡＰピア及びＥＡＰサーバのための方法であって、前記サーバと前記拡張機能性に関する前記クライアントとの能力交換を提供するＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）を採用することを含み、前記拡張機能性は認証機構を持たなく、そして少なくとも１つのＥＡＰメソッドは前記ＥＡＰピアを認証するための前記ＥＡＰ拡張メソッド内で実行される、方法。
【請求項４】
前記内部ＥＡＰメソッドにキーイングマテリアルを生成させること、前記外部ＥＡＰ拡張メソッドのメッセージをＡＵＴＨ ＴＬＶでサポートすることを更に含む、請求項３の方法。
【請求項５】
外部ＥＡＰ拡張メッセージのＡＵＴＨ ＴＬＶｓは最近成功した内部メソッドのＥＡＰキーイングマテリアルから生成されるＥＡＰ拡張キー（ＥＡＰ−ＥＸＴ−ＫＥＹ）を用いて計算される、請求項４の方法。
【請求項６】
前記ＥＡＰ拡張キーはＥＡＰ−ＥＸＴメッセージをサポートするためのＡＵＴＨ ＴＬＶｓを計算するために使用される、請求項５の方法。
【請求項７】
前記ＥＡＰ拡張キーは使用特定ルートキー導出アルゴリズムを使用して内部ＥＡＰメソッドによって生成されるＥＭＳＫから得られる、請求項６の方法。
【請求項８】
前記ＥＡＰ拡張メソッドは再認証に使用されるＥＡＰメソッドによって事前共有キーとして使用されるＥＡＰ再認証キーを定義する、請求項３の方法。
【請求項９】
前記ＥＡＰ再認証キーは使用特定ルートキー導出アルゴリズムを用いて前記ＥＡＰ拡張メソッドから転送されたＥＭＳＫから得られる、請求項８の方法。
【請求項１０】
前記ＥＡＰ拡張メソッドは、最終メッセージであることを示すために設定できるビット、エラーを示すために設定できる他のビット、複数のビットのバージョンフィールド、将来の拡張のための複数のビットの予約フィールド及び各々が特定の能力に対応する複数のビットの能力フィールドとともに共通ＥＡＰフィールドを含むメッセージフォーマットを用いる、請求項３の方法。
【請求項１１】
前記サーバと前記拡張機能に関する前記クライアントとの前記能力交換は能力ビットの設定によって得られることを更に含む、請求項３の方法。
【請求項１２】
前記能力ビットは送信者がチャネル結合機構をサポートすることを示す、請求項１１の方法。
【請求項１３】
前記能力ビットは送信者が再認証をサポートすることを示す、請求項１１の方法。
【請求項１４】
能力ビットはいつ送信者が再認証をサポートしていることを示すかが最終リクエスト／ＥＸＴメッセージに設定され、このメッセージはサーバ−ＩＤ ＴＬＶ及びピア−ＩＤ ＴＬＶを含む、請求項１３の方法。
【請求項１５】
能力ビットはいつ送信者が再認証をサポートしていることを示すかが最終リクエスト／ＥＸＴ及びレスポンス／ＥＸＴメッセージ交換に設定され、前記ＥＡＰピア及び前記ＥＡＰサーバはＥＡＰ再認証キーを発生し、前記サーバＩＤ及び前記ピアＩＤ ＴＬＶｓに含まれる前記サーバＩＤ及び前記ピアＩＤ並びに前記ＥＡＰ再認証キーは再認証ＥＡＰメソッドに使用される、請求項１３の方法。
【請求項１６】
前記ＥＡＰ拡張メソッド内で順次実行される複数の内部ＥＡＰメソッドを採用すること及び順次の内部ＥＡＰメソッドがキーイングマテリアルを生成する毎に新ＥＡＰ拡張キーを生成することを更に含む、請求項５の方法。
【請求項１７】
ａ）前記ＥＡＰサーバは少なくとも１つの能力ビットを設定したＥＡＰ−リクエスト／ＥＸＴメッセージを送信し、ｂ）前記ＥＡＰピアは前記ＥＡＰ−リクエスト／ＥＸＴメッセージを受信し、少なくとも１つの能力ビットを設定したＥＡＰ−レスポンス／ＥＸＴメッセージを送ることを含む、請求項３の方法。
【請求項１８】
ｃ）前記サーバはＥＡＰ−レスポンス／ＥＸＴメッセージを受信し、Ｆビット及び少なくとも１つの能力ビットを設定し、かつ、ピア−ID TLV，サーバ−ID TLV，及びAUTH TLVを持つＥＡＰ−リクエスト／ＥＸＴメッセージを送り、
ｄ）前記ＥＡＰピアは上記ｃ）の前記ＥＡＰリクエスト／Ｅｘｔメッセージを受信し、Ｆビットセット、少なくとも１つの能力ビットを設定し、かつＡＵＴＨ ＴＬＶを持つＥＡＰ−レスポンス／ＥＸＴメッセージを送り、
ｅ）前記ＥＡＰサーバはｄ）の前記ＥＡＰ−レスポンス／ＥＸＴメッセージを受信し、ＥＡＰサクセスメッセージを送信することを含む、請求項７の方法。
【請求項１９】
前記ＥＡＰピア又は前記ＥＡＰサーバのいずれかに前記ピア又は前記サーバがエラーを検出する場合にエラーを示すビットを設定し、かつＡＵＴＨ ＴＬＶを持つＥＡＰ拡張メッセージを送信させることを更に含む、請求項３の方法。
【請求項２０】
能力情報が攻撃者によって攻撃されるのを回避するためにキーイングマテリアルの作成後に完全性をサポートしたメッセージ交換を行うことを更に含む、請求項３の方法。
【請求項２１】
前記ＥＡＰ拡張メソッドの中の複数のＥＡＰメソッドを順序付けることを更に含む、請求項２０の方法。
【請求項２２】
シーケンスの中の先に成功した内部メソッドによって生成されるキーを用いて外部ＥＡＰ拡張メソッドと共に各内部ＥＡＰメソッドに対して完全性をサポートすることによって暗号化結合を作成し、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルを転送することを更に含む、請求項２１の方法。
【請求項２３】
ａ）プロセッサ、メモリ、デジタルデータ記憶装置及びデータメッセージを無線送受信する少なくとも１つの無線インターフェースと、
ｂ）ＥＡＰピアとして動作するようにプログラムされている無線モバイル装置と、
を具備し、
前記無線モバイル装置は
ｉ）ＥＡＰサーバから少なくとも１つの能力ビットを設定したＥＡＰリクエスト／ＥＸＴメッセージを受信し、
ｉｉ）少なくとも１つの能力ビットを設定したＥＡＰレスポンス／ＥＸＴメッセージを送信するようにプログラムされる、無線モバイルステーション。
【請求項２４】
ＥＡＰピアを用いてＥＡＰ認証メソッドを終了する無線ネットワークのためのＥＡＰサーバであって、
ａ）少なくとも１つの能力ビットを設定したＥＡＰリクエスト／ＥＸＴメッセージをＥＡＰピアに送信し、
ｂ）少なくとも１つの能力ビットを設定したＥＡＰレスポンス／ＥＸＴメッセージを前記ＥＡＰピアから受信するよう構成される、ＥＡＰサーバ。
【請求項１】
クライアントとサーバ間のメソッドの認証のための方法であって、
ａ）クライアントとサーバ間に認証機構を持たないメソッドを採用すること、
ｂ）前記クライアントを認証するために前記メソッドを内部認証メソッドに依存させること、
を含む方法。
【請求項２】
前記メソッドは第１のＥＡＰメソッドであり、この第１のＥＡＰメソッドは前記クライアントを認証するために使用される第２のＥＡＰメソッドを内部に持つ認証機構を有さない、請求項１の方法。
【請求項３】
ＥＡＰ拡張機能性に関する能力を交渉するＥＡＰピア及びＥＡＰサーバのための方法であって、前記サーバと前記拡張機能性に関する前記クライアントとの能力交換を提供するＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）を採用することを含み、前記拡張機能性は認証機構を持たなく、そして少なくとも１つのＥＡＰメソッドは前記ＥＡＰピアを認証するための前記ＥＡＰ拡張メソッド内で実行される、方法。
【請求項４】
前記内部ＥＡＰメソッドにキーイングマテリアルを生成させること、前記外部ＥＡＰ拡張メソッドのメッセージをＡＵＴＨ ＴＬＶでサポートすることを更に含む、請求項３の方法。
【請求項５】
外部ＥＡＰ拡張メッセージのＡＵＴＨ ＴＬＶｓは最近成功した内部メソッドのＥＡＰキーイングマテリアルから生成されるＥＡＰ拡張キー（ＥＡＰ−ＥＸＴ−ＫＥＹ）を用いて計算される、請求項４の方法。
【請求項６】
前記ＥＡＰ拡張キーはＥＡＰ−ＥＸＴメッセージをサポートするためのＡＵＴＨ ＴＬＶｓを計算するために使用される、請求項５の方法。
【請求項７】
前記ＥＡＰ拡張キーは使用特定ルートキー導出アルゴリズムを使用して内部ＥＡＰメソッドによって生成されるＥＭＳＫから得られる、請求項６の方法。
【請求項８】
前記ＥＡＰ拡張メソッドは再認証に使用されるＥＡＰメソッドによって事前共有キーとして使用されるＥＡＰ再認証キーを定義する、請求項３の方法。
【請求項９】
前記ＥＡＰ再認証キーは使用特定ルートキー導出アルゴリズムを用いて前記ＥＡＰ拡張メソッドから転送されたＥＭＳＫから得られる、請求項８の方法。
【請求項１０】
前記ＥＡＰ拡張メソッドは、最終メッセージであることを示すために設定できるビット、エラーを示すために設定できる他のビット、複数のビットのバージョンフィールド、将来の拡張のための複数のビットの予約フィールド及び各々が特定の能力に対応する複数のビットの能力フィールドとともに共通ＥＡＰフィールドを含むメッセージフォーマットを用いる、請求項３の方法。
【請求項１１】
前記サーバと前記拡張機能に関する前記クライアントとの前記能力交換は能力ビットの設定によって得られることを更に含む、請求項３の方法。
【請求項１２】
前記能力ビットは送信者がチャネル結合機構をサポートすることを示す、請求項１１の方法。
【請求項１３】
前記能力ビットは送信者が再認証をサポートすることを示す、請求項１１の方法。
【請求項１４】
能力ビットはいつ送信者が再認証をサポートしていることを示すかが最終リクエスト／ＥＸＴメッセージに設定され、このメッセージはサーバ−ＩＤ ＴＬＶ及びピア−ＩＤ ＴＬＶを含む、請求項１３の方法。
【請求項１５】
能力ビットはいつ送信者が再認証をサポートしていることを示すかが最終リクエスト／ＥＸＴ及びレスポンス／ＥＸＴメッセージ交換に設定され、前記ＥＡＰピア及び前記ＥＡＰサーバはＥＡＰ再認証キーを発生し、前記サーバＩＤ及び前記ピアＩＤ ＴＬＶｓに含まれる前記サーバＩＤ及び前記ピアＩＤ並びに前記ＥＡＰ再認証キーは再認証ＥＡＰメソッドに使用される、請求項１３の方法。
【請求項１６】
前記ＥＡＰ拡張メソッド内で順次実行される複数の内部ＥＡＰメソッドを採用すること及び順次の内部ＥＡＰメソッドがキーイングマテリアルを生成する毎に新ＥＡＰ拡張キーを生成することを更に含む、請求項５の方法。
【請求項１７】
ａ）前記ＥＡＰサーバは少なくとも１つの能力ビットを設定したＥＡＰ−リクエスト／ＥＸＴメッセージを送信し、ｂ）前記ＥＡＰピアは前記ＥＡＰ−リクエスト／ＥＸＴメッセージを受信し、少なくとも１つの能力ビットを設定したＥＡＰ−レスポンス／ＥＸＴメッセージを送ることを含む、請求項３の方法。
【請求項１８】
ｃ）前記サーバはＥＡＰ−レスポンス／ＥＸＴメッセージを受信し、Ｆビット及び少なくとも１つの能力ビットを設定し、かつ、ピア−ID TLV，サーバ−ID TLV，及びAUTH TLVを持つＥＡＰ−リクエスト／ＥＸＴメッセージを送り、
ｄ）前記ＥＡＰピアは上記ｃ）の前記ＥＡＰリクエスト／Ｅｘｔメッセージを受信し、Ｆビットセット、少なくとも１つの能力ビットを設定し、かつＡＵＴＨ ＴＬＶを持つＥＡＰ−レスポンス／ＥＸＴメッセージを送り、
ｅ）前記ＥＡＰサーバはｄ）の前記ＥＡＰ−レスポンス／ＥＸＴメッセージを受信し、ＥＡＰサクセスメッセージを送信することを含む、請求項７の方法。
【請求項１９】
前記ＥＡＰピア又は前記ＥＡＰサーバのいずれかに前記ピア又は前記サーバがエラーを検出する場合にエラーを示すビットを設定し、かつＡＵＴＨ ＴＬＶを持つＥＡＰ拡張メッセージを送信させることを更に含む、請求項３の方法。
【請求項２０】
能力情報が攻撃者によって攻撃されるのを回避するためにキーイングマテリアルの作成後に完全性をサポートしたメッセージ交換を行うことを更に含む、請求項３の方法。
【請求項２１】
前記ＥＡＰ拡張メソッドの中の複数のＥＡＰメソッドを順序付けることを更に含む、請求項２０の方法。
【請求項２２】
シーケンスの中の先に成功した内部メソッドによって生成されるキーを用いて外部ＥＡＰ拡張メソッドと共に各内部ＥＡＰメソッドに対して完全性をサポートすることによって暗号化結合を作成し、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルを転送することを更に含む、請求項２１の方法。
【請求項２３】
ａ）プロセッサ、メモリ、デジタルデータ記憶装置及びデータメッセージを無線送受信する少なくとも１つの無線インターフェースと、
ｂ）ＥＡＰピアとして動作するようにプログラムされている無線モバイル装置と、
を具備し、
前記無線モバイル装置は
ｉ）ＥＡＰサーバから少なくとも１つの能力ビットを設定したＥＡＰリクエスト／ＥＸＴメッセージを受信し、
ｉｉ）少なくとも１つの能力ビットを設定したＥＡＰレスポンス／ＥＸＴメッセージを送信するようにプログラムされる、無線モバイルステーション。
【請求項２４】
ＥＡＰピアを用いてＥＡＰ認証メソッドを終了する無線ネットワークのためのＥＡＰサーバであって、
ａ）少なくとも１つの能力ビットを設定したＥＡＰリクエスト／ＥＸＴメッセージをＥＡＰピアに送信し、
ｂ）少なくとも１つの能力ビットを設定したＥＡＰレスポンス／ＥＸＴメッセージを前記ＥＡＰピアから受信するよう構成される、ＥＡＰサーバ。
【図１】
【図２】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７Ａ】
【図７Ｂ】
【図２】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７Ａ】
【図７Ｂ】
【公表番号】特表２０１０−５０２０４０（Ｐ２０１０−５０２０４０Ａ）
【公表日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【出願番号】特願２００９−５０９２０６（Ｐ２００９−５０９２０６）
【出願日】平成１９年１２月５日（２００７．１２．５）
【国際出願番号】ＰＣＴ／ＪＰ２００７／０７３９０１
【国際公開番号】ＷＯ２００８／０７２６４６
【国際公開日】平成２０年６月１９日（２００８．６．１９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（５０４４７３６７０）テルコーディア・テクノロジーズ・インコーポレーテッド (72)
【Ｆターム（参考）】
【公表日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【出願日】平成１９年１２月５日（２００７．１２．５）
【国際出願番号】ＰＣＴ／ＪＰ２００７／０７３９０１
【国際公開番号】ＷＯ２００８／０７２６４６
【国際公開日】平成２０年６月１９日（２００８．６．１９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（５０４４７３６７０）テルコーディア・テクノロジーズ・インコーポレーテッド (72)
【Ｆターム（参考）】
[ Back to top ]